TL;DR: Run anomaly detection on gross spend (before credits and refunds), not net. Credits are accounting events, not usage changes: a $20k credit landing makes net spend crater while nothing about your infrastructure changed. Filter credit line items out of the detection series and the CFO never gets that page again.

```text
ANOMALY: net spend -$14,200 vs expected $38,000 - paging CFO
```

1. Confirm the line item: in Cost Explorer or the CUR, find the credit or refund records for the period. Expected: a service-credit line item roughly equal in size to the 'anomaly'.
2. Switch the detection metric to gross cost before credits. In Cost Explorer use unblended costs excluding credits; in the CUR filter out records whose line-item type is Credit or Refund. Expected: the series no longer craters on credit days.
3. Re-run the detector over the credit month on the gross series. Expected: no anomaly; real usage spikes still get detected.
4. Track credits separately: a simple monthly credits-received summary for finance. Expected: the CFO gets a calm report instead of a page, and nothing is hidden.
5. Fix the routing regardless: anomaly alerts go to the FinOps or on-call channel, never directly to executives. Expected: the paging path is sane even if another false positive slips through.

## Use this when
- Credits or refunds trigger spend alerts
- Net spend goes negative or craters for no infrastructure reason
- Finance or executives get paged by the anomaly detector
- A billing adjustment landed and the detector treated it as a usage change

## Not for this skill when
- The credit reflects a real outage you want to know about (send an informational note, but it is still not a usage anomaly)
- Gross spend moved too (investigate the usage change as its own item)
- You are doing chargeback or showback accounting (net is correct there, just not for anomaly detection)
- The 'credit' is actually a pricing change (that changes future gross spend, model it going forward)

## Variant phrasings
- service credit triggered cost anomaly alert
- negative spend anomaly
- refund flagged as anomaly
- CFO paged by cost detector

## Why it happens
Billing data mixes two different things: what you used (usage) and accounting adjustments (credits, refunds). Detectors built on net spend treat a credit like your infrastructure suddenly cost negative dollars. Credits are lumpy and large, so they always look anomalous to a model trained on smooth usage.

## Edge cases
- Credits applied retroactively can restate past months: pin training data to finalized invoices, not provisional data
- Some credits are usage-tied (for example data-transfer waivers): excluding them can hide real transfer growth, so review credit categories yearly
- Annual commit credits land as big yearly chunks: exclude them by line-item type permanently, not month by month
- CUR credit line items sometimes arrive days after the usage: expect small restatements and do not alert on them
- If credits are large enough to matter for budgets, keep a separate net-spend budget alert with a much wider threshold

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b6F3-vcpz3ckExX362lp9w