Help: Our Azure EA amortization is making actual spend impossible to see.

Finance switched to amortized because they hate spiky charts, not because it reflects reality. The portal and API are serving their needs, not engineering's.

You need the usage details, not the cost aggregates. Export raw usage data via the Usage Details API. It gives you resource-level consumption before any financial smoothing. Write a query that groups by day and meter, then apply the pay-as-you-go rates from your price sheet. It's a hassle, but it's the actual spend.

Pushing back on finance is a political battle you'll probably lose. Better to build your own shadow reporting from the raw data. Just remember, you're now replicating a billing system. Hope your team enjoys that new responsibility.

I've been down this exact path. User1398 is right about the Usage Details API, but you don't need to rebuild a billing system from scratch.

Pull the `Consumption/UsageDetails` API with the `actual` charge type filter. The key is the `properties/chargeType` field. You'll get a mix of "Actual" and "Amortized" rows. Filter for the Actual ones and sum by your resource tags and date. That's your raw spend.

I dropped this into a simple Grafana table for our teams. It's not perfect, but it shows the VM scale-out spikes the same day. The bigger caveat is that "Actual" costs for reservations will look huge upfront, which you might need to annotate for your engineers to avoid panic.

Pushing back on finance is hard once they've standardized on a view. A parallel engineering-facing dashboard is usually the easier win.

Ah, the actual vs. amortized headache. I'm just starting with Azure cost tracking and hit a similar wall.

User474's tip about the `chargeType` filter is super helpful, thanks for that. So you're basically building a separate dashboard just for engineering visibility? That sounds like a lot of extra work to maintain.

A quick follow-up - when you pull the "Actual" charges, does it still properly account for things like Azure Hybrid Benefit or dev/test discounts, or do you have to factor those in manually later? That's my next worry.

It's definitely extra work, but it pays off for us. We started with a simple Power BI dashboard that auto-refreshes daily. It felt like maintenance overhead at first, but now it's just part of our routine data pipeline.

For your question on Azure Hybrid Benefit and discounts: yes, the "Actual" charge type already includes them! The raw usage details reflect the final, discounted rate applied to your billing account at that moment. You don't have to manually factor them in, which is a huge relief.

The bigger gotcha is explaining that initial reservation purchase spike. We added a little note on the dashboard saying "Big one-time charge? Probably a reservation purchase." Stopped a few panicked Slack messages 😅

That note about reservation spikes is a lifesaver. We did the same and it cut down on the support tickets dramatically.

One thing we found helpful was adding a small line graph of the *amortized* view right below the actual spend in our dashboard. It helped teams understand why finance sees a smoother picture and bridged that mental gap a bit. It's a small touch, but it turned a source of confusion into a teaching moment.

The dual-graph approach is brilliant for internal education. We took it a step further by linking each spike in the "actual" view to a drill-down page showing the specific resource. That way, when the amortized view below shows a flat line, they can click through and see exactly what caused the underlying cost event.

It transformed the conversation from "why are the numbers different" to "here's what we bought, and here's how finance accounts for it."

Linking spikes to resource details is clever. That's the kind of operational clarity finance's smoothed reports destroy.

But you're also building a whole parallel accounting UI to compensate for a vendor's reporting failure. The real teaching moment is that Azure's cost tools are built for the CFO, not the engineers actually spending the money.

That's a good point about building a separate UI for engineering. It feels like a workaround, not a fix.

But if the vendor's tools are built for the CFO, maybe that's the real constraint. Engineering visibility becomes a custom job. Do you think there's a world where Azure provides both views natively, or is this just how enterprise billing works?

You're spot on about filtering for the `actual` charge type. That's the crucial first step most folks miss. One thing I'd add is that the API can sometimes return duplicate or ambiguous rows for the same usage event when you're on an Enterprise Agreement, depending on the reporting lag. It's worth adding a deduplication step in your query logic, perhaps based on the `instanceId` and date, to avoid double-counting those small spikes.

The parallel dashboard is indeed the pragmatic path of least resistance. It gives engineering the real-time view they need without demanding finance change their entire reporting structure.

You've hit the classic EA reporting wall. The answer to your first question is the `Consumption/UsageDetails` API with a filter on `properties/chargeType eq 'Actual'`. That gives you the raw, daily, pre-amortization numbers.

For tools, you're looking at a custom dashboard. I built ours in Grafana, pulling that API feed. It shows the VM scale-out spikes exactly as you described. It's extra work, but pushing back on finance's amortized view is usually a non-starter once they're locked in.

The real gotcha isn't the query - it's handling reservation purchases. They'll show as massive one-day "Actual" charges. You'll need to annotate those or your engineers will panic when they see the graph 📈.

That drill-down is such a smart layer to add. It moves from explaining the accounting concept to providing tangible, actionable data. I've seen that kind of linking cut down clarification requests by half.

One caveat we ran into: make sure your drill-down logic can handle deleted resources gracefully. If someone spins up a test VM for a day and deletes it, your link might break unless you're snapshotting that metadata somewhere. We had to cache resource names and IDs at the time of the cost event.

It really does reframe the question, doesn't it? Instead of confusion, you get conversations about whether a specific spike was justified.

You're absolutely right about caching the metadata. We learned that the hard way after a month of dead links. The API gives you a resource URI at the time of billing, but that doesn't guarantee it still exists when someone clicks.

Our fix was to append resource tags and the friendly name to the cost record as it's ingested. Simple key-value store lookup. It's extra overhead, but the alternative is explaining to a director why their fifty-thousand-dollar spike is now labeled "ResourceNotFound".

It does reframe the conversation, but it also creates a new data lineage problem. Now you're not just tracking cost, you're preserving a historical snapshot of your resource catalog. Feels like you're building a shadow CMDB just to understand your own bill.

The shadow CMDB point is so real. We ended up with the same issue, and it forced us to document a retention policy for that cached metadata. How long do you keep a snapshot of a deleted resource's tags? It's a cost reporting tool that suddenly needs its own governance.

We also found that resource tags can change after the fact, so our historical cost reports would retroactively "update" if we didn't snapshot them at billing time. That created its own confusion.

Exactly. The vendor's tooling isn't broken, it's just serving a different master. Finance wants predictability, engineering wants causality. You're always going to build a parallel system because those goals are fundamentally opposed.

The real joke is paying a premium for an "enterprise" cloud platform, then having to build a bespoke cost dashboard yourself. So much for out-of-the-box visibility.