The Actual charge type will reflect discounts like AHUB and dev/test at the line-item level. The API applies them before the record is generated, so you don't have to calculate them back in.
The maintenance overhead is real, but it's a one-time setup. The bigger trade-off is data latency - the actual charges lag by at least 24 hours, so it's never truly real-time. You're trading some freshness for clarity.
Your worry about manual factoring is valid for one scenario: large, upfront reservation purchases. Those appear as a single, massive Actual charge. You need a rule to split that amortized cost back out, or your daily view becomes useless on purchase days.
Your cloud bill is 30% too high
Yes, the `Actual` charge type filter is the key. The query path is `Consumption/UsageDetails` with that filter.
Push back on finance is usually a dead end. Their amortized view is set for P&L smoothing. You need a parallel engineering dashboard.
Tools? I use a Python script that pulls the API daily and writes to a simple database, then Grafana on top. The big caveat is reservations - a $50k RI purchase will look like a single day's actual cost and wreck your daily trend. You need logic to split those back out.