Multi-Cloud Cost Management: Why Cost Accuracy Matters

Every FinOps decision starts with a number. How much does this resource cost? How much would we save by downsizing? What's our projected spend next quarter? If that number is wrong, every decision built on top of it is wrong too.

Most teams assume their cloud cost tool is accurate. They shouldn't. After building CLARITY's multi-cloud cost engine and reconciling data across AWS, Azure, and GCP, we've found that raw cloud billing data is inaccurate by default — and the errors are systematic, not random.

Why Accuracy Is the Foundation of Every FinOps Decision

Cost data feeds everything downstream: right-sizing recommendations, budget alerts, anomaly detection, chargeback reports, executive forecasts. A 1% error in the cost data doesn't cause a 1% error in decisions — it causes cascading failures across all of these systems.

Consider what happens when your cost data overstates spending on a particular service by 2%:

• Your anomaly detector flags normal spend as anomalous, creating alert fatigue
• Your chargeback report overcharges one team and undercharges another
• Your right-sizing engine calculates savings against an inflated baseline, making recommendations look more attractive than they are
• Your budget forecasts drift month over month, eroding trust with finance

This is why we engineered CLARITY around a claim we can state precisely: the totals we report reconcile to your invoice. Service-level spend in CLARITY comes straight from AWS Cost Explorer, Azure Cost Management, and the GCP billing export — it is the provider's own figure, corrected for the failure modes described below, not a number we recompute from list prices.

That is a narrower claim than "our numbers are accurate," and the narrowness is the point. An unqualified accuracy percentage tells you nothing about which numbers it covers. A tool can reconcile perfectly at the account level and still be inventing the per-resource breakdown underneath — and the per-resource breakdown is what your right-sizing recommendations are built on. So this post is about two separate questions, kept separate: does the total match the bill, and where does each number below the total come from.

How Even 1% Error Compounds Into Six-Figure Mistakes

Let's make this concrete. Take an organization spending $500,000 per month across AWS, Azure, and GCP.

A 1% error rate means $5,000 per month in hidden inaccuracy. Over a year, that's $60,000 in phantom costs influencing every decision. But the real damage is worse than the raw number suggests:

• Right-sizing recommendations built on 1% error will recommend changes that save less than projected — or cost more. If you're targeting 20% savings ($100K/month), a 1% baseline error means your actual savings could be $95K or $105K. That's a $120K annual variance.
• Budget alerts fire at the wrong thresholds. Teams either ignore them (alert fatigue) or react to false signals (wasted engineering time).
• Chargeback disputes emerge when engineering managers see numbers that don't match what they see in the native console. Once trust is lost, adoption of the FinOps tool collapses.

The error doesn't stay at 1%. It compounds across resources, accounts, and time periods. A $500K monthly spend with hundreds of resources and three cloud providers can easily accumulate $150K-$200K in annual decision error from a 1% baseline inaccuracy.

The 9 Correction Mechanisms Behind CLARITY's Accuracy

Getting multi-cloud cost data right isn't about one clever algorithm. It's about systematically identifying and correcting every source of error in multi-cloud billing data. Here are the 10 mechanisms CLARITY uses.

This list used to have ten entries, and the tenth is the reason I want to say something about the list before describing it. It claimed we applied percentile thresholds to ECS Fargate cost data to filter deployment spikes. We don't, and we never did. We do classify CPU peak patterns — including deployment spikes — and use that classification to decide whether a right-sizing recommendation is safe to make, which is a real mechanism described in 6 CPU Peak Patterns Every FinOps Team Should Know. But it operates on utilization metrics and it corrects recommendations, not cost data. Somewhere between the engineering and the writing, one became the other. It has been removed rather than reworded, and the other nine have been rewritten to say what the code actually does. Several of them were describing the ambition rather than the implementation, and the gap between the two is exactly what this post claims to be about.

1. AWS Cost Explorer: Pagination and Precision

AWS Cost Explorer API returns paginated results. If your tool doesn't follow NextPageToken through every page, it silently drops cost records. This is especially dangerous for accounts with hundreds of services — the first page looks complete, and you are missing everything after it.

CLARITY follows every pagination token to exhaustion. It also counts the pages, because every page is a separately billed Cost Explorer request charged to your account at $0.01, and a tool that reports one tool call as one charge is under-reporting your bill. One of our accounts returns 57,693 groups over 12 billed pages for a single query.

The second half of this mechanism is newer and it is the one I'd point at. Every amount this pipeline returned used to be rounded to two decimals on the way out. For a service-level total that is invisible — a service billing $1,128.70 does not care about a half-cent. For a per-resource daily amount it is the dominant term. On a real 20 GiB gp2 volume in a 31-day month:

• Cost Explorer returned 20 × $0.10 / 31 = $0.0645161/day
• we stored (0.0645161).toFixed(2) = $0.06/day
• our own pricing formula produced $0.0645/day

All 5,043 stored rows in that table were exact multiples of a cent. Not one carried a third decimal, because there was no path by which one could. At $0.06/day the rounding quantum is half a cent — eight percent — and it does not average out, because the same amount rounds the same way every day. Aggregated over 31 volumes across 14 days it read as a 7.7% bias in our own estimator. The estimator was fine. The number we were comparing it against was the approximation, and we had been treating the approximation as ground truth.

Two things came out of that. Per-resource amounts now keep six decimals. And a resource genuinely billed $0.004/day no longer rounds to "0.00" and gets dropped by the positive-cost filter — a real charge deleted for being small, which is a worse failure than the rounding was. Both are visible in the stored data rather than only in the code: of 41,330 per-resource cost rows in production on 7 September 2026, 33,064 carry more than two decimals, and 5,686 are for less than a cent — charges the old filter would have deleted for being too small to represent.

We found it because the product measures its own estimates against the provider's billing on the resources where both exist. That measurement is now a permanent part of the pipeline rather than a one-off query, and it deliberately reports a deviation smaller than the provider's own reporting precision as indistinguishable rather than as bias. A correction factor derived from that 7.7% would have moved a correct formula permanently away from the truth on the strength of a bug we hadn't found yet.

2. LINKED_ACCOUNT Filtering for Organization Accounts

When querying AWS Cost Explorer from a management (payer) account, the API returns cost data for all linked accounts by default. If your tool doesn't explicitly filter by the LINKED_ACCOUNT dimension, you get cross-account contamination — costs from Account B showing up in Account A's analysis.

CLARITY resolves the account identity with STS GetCallerIdentity, checks whether that account is a member of an AWS Organization, and applies the LINKED_ACCOUNT filter only when it is. The conditional matters: a standalone account filtered by LINKED_ACCOUNT returns $0 from Cost Explorer, so applying the filter unconditionally would replace a contamination bug with a much louder one.

Two clarifications on what this does not do, both of which the earlier version of this post got wrong. There is no cross-reference against the payer account's consolidated view — each credential is scoped to its own account and we do not query a second one to check the first. And while CLARITY does support onboarding by cross-account IAM role with an ExternalId-bound trust policy, and assumes that role at sync time for short-lived credentials, AssumeRole is how we authenticate; it is not the mechanism that separates one account's costs from another's. The filter is.

3. Resource State: Stale Inventory, and Not Inventing Cost

Resources disappear from inventories and appear in bills, and the relationship between the two is not what it looks like.

CLARITY marks a resource inactive when a full inventory sweep no longer returns it, and removes its per-resource cost rows. That part is straightforward. The part worth stating is what we deliberately do not infer from it: a resource vanishing from a provider API is equally consistent with a deletion, a credential rotation, a permissions change, and a region we stopped scanning. Only billing data tells those apart. So a disappearance is a trigger to go and look at the bill — never, on its own, evidence that spend stopped. Where the billing shows nothing further, we say the saving is verified. Where there is no billing data at all, we say unknown, which is not the same as zero.

The same rule cuts the other way, and this is where it cost us. Six Azure VMs that were switched off were each being modelled at a full 24 hours a day of compute, on top of an invoice Azure had already attributed correctly — so per-resource attribution for that subscription came out above 100% of the bill. Removing it took 338 rows worth $1,142.85, $959.09 of it from the calculated tier and $183.76 from proportional allocation on top of it. Those figures are the ones in the audit-log entry for the deletion rather than a recollection of it, and the rows were written to a backup file before anything was removed: a cost correction you cannot reverse is a second bug waiting to be found. The guard against it had been written and was correct in intent, and it could never fire: the Azure SDK call we used never populates power state, so every VM arrived with state "unknown" and a guard that excluded one exact string had nothing to match. The rule now requires positive evidence — we model compute only for a VM we know is running. A suppressed estimate shows up as a named gap in the coverage panel. An invented one shows up as a number you make decisions on.

4. Partial Day Handling

The current day's cost data is always incomplete, and providers keep adjusting a day's charges after it ends — AWS typically settles within 24 to 48 hours. A tool that treats today's partial figure as a data point creates a false "cost drop" at the end of every reporting period.

CLARITY excludes the current day from the daily rate that drives projections, and from the calibration that compares our estimates against provider billing — a partial final day always drags a mean down, and we watched it manufacture an estimator bias that wasn't there. Month-to-date totals do include today, deliberately: month-to-date means to date, and a headline that silently stopped at yesterday would be a different kind of wrong.

What carries the honesty here is labelling rather than exclusion. The interface shows how far the provider has actually settled, and separates two things that look identical and mean opposite things: spend that is estimated because those days haven't settled yet and will be replaced by the invoice at the next sync, versus spend the provider has finished with that still has no per-resource breakdown behind it. Only the second is a real gap. We had that boundary wrong in the flattering direction until recently — it was drawn from a fixed 48-hour constant rather than from the frontier of billed data we actually hold, which filed about 14% of estimated AWS spend in the window as a permanent gap when it was simply pending. The boundary now follows the data.

5. Tax, Support, and Credit Filtering

Cloud bills include non-compute line items: sales tax, support plan charges, enterprise discount credits, refunds. When these contaminate resource-level analysis, your per-service cost calculations become unreliable.

CLARITY excludes them at the query, not after the fact: the AWS cost request carries a filter that removes the Refund, Credit, Tax and Support record types outright. Without it, free-tier credits cancel out charges and Cost Explorer reports $0 for a new account — a tool showing a customer zero on their first day is a support ticket that looks like a bug in the cloud. The same filter excludes Cost Explorer's own charges, which would otherwise create a small recursive loop where querying your bill adds to your bill.

6. Direct vs. Proportional Cost Disambiguation

Some costs map directly to a resource (an EC2 instance's hourly rate). Others are shared and must be proportionally allocated (data transfer, NAT gateway charges, shared load balancers). Treating proportional costs as direct — or vice versa — distorts per-resource cost calculations.

CLARITY runs four allocation strategies in a fixed priority order — the provider's own per-resource billing first, then dynamic pricing formulas, then a service-level total split across its children, then Kubernetes namespace allocation by CPU and memory share — and records on every stored row which one produced it. When two rows compete for the same resource-day, the rule is not "last write wins". Two billed charges against one resource are two real charges and are summed; a billed charge competing with a modelled one lets the billed figure win outright.

Getting that rule wrong in either direction destroys money. Azure names a VM's disks and extensions after the VM, so 382 billed identifiers collapse onto 157 resources, and a first-one-wins rule copied from elsewhere in the pipeline would have silently discarded $2,334.08 of real charges on the first run that worked. The reverse error is quieter and worse: because records are written in priority order and in chunks, a colliding pair split across two chunks let the lowest-priority estimate overwrite the billed figure, with no error and no log line. The merge is now computed across the whole batch before anything is written.

7. ECR Storage-Weighted Allocation

Amazon ECR stores container images as layers, and multiple images typically share base layers. An earlier version of this post claimed CLARITY deduplicates at the layer digest level. It does not, and the honest version is more useful anyway.

AWS bills you for deduplicated storage — the invoice already reflects layers stored once. So the number that needs no correction is the billed one, and what CLARITY does is split that billed ECR total across your repositories weighted by repository size rather than dividing it evenly, which is what most naive allocation does and which charges a 40 GB repository the same as a 200 MB one.

The limitation belongs in the same paragraph as the mechanism: the size we weight by is the sum of the reported image sizes, which does count a shared base layer once per image. So a repository with many images built on one base is over-weighted relative to its true share of storage. That skews the split between repositories; it does not change the total, which comes from the bill. These rows are labelled as proportional, not billed, for exactly this reason.

8. Cross-Currency Exchange Rates

Azure bills in local currencies depending on the enrollment region. GCP bills in USD by default but supports local currency billing for some accounts. When aggregating multi-cloud costs, stale or incorrect exchange rates introduce systematic drift.

CLARITY fetches live rates at ingestion from the European Central Bank's published daily reference rates, with a second public rate source behind it for currencies the ECB doesn't cover, and validates every rate against a plausibility band before using it — a rate source returning something absurd should fail loudly rather than quietly repricing your estate. For Azure specifically we can also derive rates from Azure's own Retail Prices API by pricing one reference SKU in each currency, which is as close to "the rate the provider used" as a public API gets.

Three corrections to what this post used to say, because we hold other vendors to this and should hold ourselves to it first. These are not the exchange rates the cloud providers use to compute your invoice; providers set their own rates on their own schedule and do not publish them as a feed. There is a hardcoded fallback table, used only when both live sources are unreachable — including a EUR rate that is, embarrassingly, the exact example our own tool-comparison post uses to describe a platform doing this badly. And the claim that we "store both the original currency amount and the USD-normalized value for auditability" overstates the schema: the cost table has no currency column, and the original amount survives only in an untyped JSON field, which is not the same as a first-class auditable record. All three are being addressed. Until they are, this is what the mechanism does.

9. Resource ID Format Normalization

AWS uses ARNs (arn:aws:ec2:us-east-1:123456789:instance/i-abc123). Azure uses ARM resource IDs (/subscriptions/.../resourceGroups/.../providers/...). GCP uses project-qualified names. Worse, the billing APIs don't return the same shape the inventory APIs do: of 161 distinct billed identifiers on one production AWS account, 59 were full ARNs, 52 were bare i-… instance ids, 31 were vol-… volume ids and 19 were bare S3 bucket names.

CLARITY derives every identifier shape a provider might report from the canonical ARN, structurally, and resolves a billed identifier by exact lookup against that index. If you take one thing from this section, take the reason.

All three providers used to match by substring: the first known ARN containing the billed id won. That is not merely imprecise, it is non-deterministic — the winner depended on the order rows came back from Postgres, so the same billing input could attribute differently after a routine VACUUM. On Azure, 382 identifiers collapsed onto 158 resources, and 17 of 18 PowerShell DSC extension charges landed on a single VM. On AWS nothing collided in aggregate, which made it look safe, and it wasn't: four of the 161 identifiers changed winner between row orderings, and the drift was already written down. Four S3 buckets had $71.95 of storage spend filed against a CloudWatch alarm, an ELB target group and two log groups, and for a fortnight one bucket's daily cost was written twice — once to the bucket, once to the alarm — so the account total was overstated, not merely misfiled.

An identifier that two resources could both claim now resolves to nothing. Unattributed is a worse-looking answer than a plausible guess and a much better one, because the guess is indistinguishable from a fact on the screen where you make the decision.

The 9 Mechanisms at a Glance

Why Multi-Cloud Makes Accuracy Exponentially Harder

If cost accuracy were only about one cloud provider, nine correction mechanisms might be overkill. But multi-cloud environments face a combinatorial problem: 3 different billing APIs, 3 different data formats, 3 different rate-limiting strategies.

Three billing APIs with different behaviors. AWS Cost Explorer uses paginated REST calls with daily rate limits. Azure Cost Management uses a different pagination model with continuation tokens and supports both actual and amortized cost views. GCP BigQuery billing export requires SQL queries against a billing dataset with its own schema and data freshness guarantees. Each API has different latency characteristics, different error modes, and different data completeness timelines.

Three data formats with different granularity. AWS reports costs at the hourly level with resource-level tagging. Azure provides costs at daily granularity by default (hourly requires additional configuration). GCP billing export includes project-level labels but handles resource identification differently. Normalizing these into a single consistent model without losing provider-specific detail is a significant engineering challenge.

Three rate-limiting strategies that affect data freshness. AWS Cost Explorer has strict daily API call limits — exceed them and your data goes stale. Azure throttles based on concurrent requests per subscription. GCP BigQuery has its own quota system based on bytes scanned. A multi-cloud tool must respect all three simultaneously while keeping data fresh enough for real-time decisions.

This is precisely why most FinOps tools either specialize in one cloud provider and do it well, or support multiple providers but with accuracy trade-offs. CLARITY was built multi-cloud from day one, with each provider's quirks handled at the data ingestion layer — not as an afterthought.

If your FinOps dashboard is showing you numbers you can't quite trust, this problem often goes deeper than the dashboard itself. We explored the root causes in Why Your FinOps Dashboard Is Lying to You — the accuracy mechanisms in this post are how we address those failures at the data layer.

Below the Total: What Is Billed and What Is Modelled

Everything above is about the total. Now the harder half, and the part most vendors leave unsaid.

The three clouds do not publish per-resource billing for everything they charge you for. AWS Cost Explorer will break costs down by resource ID for many services and not for others. Azure's usage details name resources well, but a virtual machine's disks and extensions are frequently billed under names derived from the VM rather than as independent line items. GCP's BigQuery export is the most granular of the three and still leaves service-level charges that belong to no single resource.

Where the provider publishes a per-resource figure, we use it. Where it doesn't, we model it — from live pricing APIs, or by splitting a service-level total across the resources that plausibly generated it. Both kinds of number are useful. They are not the same kind of claim, and a tool that renders them identically is asking you to trust a model as if it were an invoice.

So CLARITY labels them. Every cost figure carries its basis: billed (the provider charged this resource this amount), estimated (our pricing or allocation model produced it), list price (a public on-demand rate for the instance type — not this resource's bill, and typically understated because it excludes storage, transfer, and discounts), or mixed, in which case the billed and estimated halves are shown as separate amounts rather than blended into one confident-looking total. Where nothing was collected, the figure reads as unknown rather than as $0 — those are different statements and printing the second as the first is its own category of lie.

Where we do have the provider's per-resource billing, this is not a rough correspondence. Measured against production over the fourteen days from 24 August to 6 September 2026: DMS $292.32 billed against $292.32 attributed; Glue $4.46 against $4.46; S3 $174.19 against $174.18. The window is named because a reconciliation figure without one is not a measurement — it is an anecdote, and naming it is what lets you re-run it and find out whether it still holds. On Azure the same subscription over-attributed its invoice until the misattribution described in mechanism #9 was corrected and the phantom compute in mechanism #3 was removed — 338 rows worth $1,142.85, deleted with a backup and an audit-log entry naming the scope, the cause and the dollar total by allocation tier. Over the thirty days to 6 September 2026 that subscription now attributes $3,599.12 of a $3,661.47 bill, 98.3%. It is not 100%, and it is quoted at 98.3% rather than rounded up, because the remaining $62.35 is real spend we have not tied to a resource and saying so is the entire point of the coverage panel described below. Where a whole service comes back at zero — API Gateway, $34.07 billed and nothing attributed — the cause is almost never the billing API. It is that we never discovered the resource, which is a different problem with a different fix, and the coverage panel says which one you have.

There is a coverage panel on the Resources screen that answers the question directly for your own accounts: of everything the provider billed this period, how much is attributed to a resource from real billing data, how much from our estimates, and how much is attributed to nothing at all. That last figure is reported rather than distributed. Some of it is structural — Savings Plan recurring fees belong to no single resource by construction — and some of it is spend nobody has claimed yet. Spreading it across resources to make the columns add up would make the screen look better and the numbers worse.

Unattributed spend is also split by why, because two opposite failures were being counted as one number. Across two production accounts over fourteen days, $2,138.28 of it arrived from AWS carrying a perfectly good resource identifier for a resource we had never discovered, and $507.00 arrived with no resource identity at all. The first is our inventory's fault and is fixed by going and finding the resource. The second is the provider declining to attribute the charge, and no amount of work on our side changes it. A merged counter cannot tell you which one you are looking at, and the remedies point in opposite directions. Where AWS sends a literal token we don't recognise, the panel prints the token verbatim rather than bucketing it as "other" — we would rather learn the spelling from your bill than assume it.

It also separates two things that look identical and mean opposite things: spend that is estimated because the provider hasn't settled those days yet (AWS closes a day's charges 24–48 hours late, so the newest days of any window are estimates by construction and will be replaced by the invoice at the next sync), and spend the provider has finished with that still has no per-resource breakdown behind it. Only the second is a real gap.

We publish this rather than a headline accuracy percentage on purpose. A single number, averaged across providers and estates and periods, is not auditable by you — and an accuracy figure you cannot reproduce against your own bill is a marketing artifact, not a measurement. The panel shows you your number, for your accounts, for the period you chose.

How to Verify Your FinOps Tool's Accuracy

Whether you use CLARITY or another tool, here's how to audit cost accuracy against the source of truth — the native billing consoles.

Step 1: Pick a representative month. Choose a completed billing month (not the current one) with typical usage patterns.

Step 2: Pull the numbers from each native console.

• AWS: Go to Billing Dashboard > Bills. Note the total for each linked account.
• Azure: Go to Cost Management + Billing > Cost Analysis. Select the billing period and note subscription-level totals.
• GCP: Go to Billing > Reports. Select the billing account and note project-level totals.

Step 3: Compare against your tool's numbers. For each account/subscription/project, calculate the delta: (tool_cost - console_cost) / console_cost * 100.

Step 4: Investigate any delta above 0.5%. Common causes:

• Tax/credit inclusion differences (mechanism #5)
• Partial day inclusion in the tool but not the console (mechanism #4)
• Currency conversion discrepancies (mechanism #8)
• Amortized vs. actual cost view mismatch

Step 5: Check resource-level accuracy — and ask where each number came from. Pick 10 resources of different types (EC2, RDS, S3, Azure VMs, GCP Compute Engine). Compare per-resource costs in your tool against the native console. This catches mechanisms #1, #2, #3, #6, #7, and #9.

Two outcomes are acceptable here and one is not. If the provider publishes billing for that resource, the tool should match the console closely — a delta above 1% on a resource with real billing data behind it means something in the pipeline is wrong. If the provider publishes nothing for that resource, no tool on earth can match the console, because there is no console figure to match; what the tool owes you is a clear statement that the number is modelled, so you can weight it accordingly.

The unacceptable outcome is the third one: a tool that presents both cases identically. If you cannot tell, from the screen, whether you are looking at the provider's charge or the vendor's estimate, then you cannot tell which recommendations rest on measurement and which rest on a model — and the confident ones will be the modelled ones, because models don't have error bars unless someone draws them.

So the question to ask a vendor is not "what is your accuracy percentage." It is "show me, on this resource, where this number came from." Ask it during the trial, on your own accounts.

Conclusion

Cost accuracy isn't a feature — it's the foundation. Every right-sizing recommendation, every budget alert, every chargeback report, every executive forecast is only as reliable as the cost data underneath it.

The nine correction mechanisms described here aren't theoretical. They're the result of reconciling cost records across AWS, Azure, and GCP, finding where the numbers diverge, and engineering corrections for each failure mode. That's how CLARITY's totals reconcile to the invoice — not through a single algorithm, but through systematic error correction at every stage of the data pipeline.

They also aren't finished, and this revision is the evidence. There were ten of them in the version of this post that ran until now. One described something the product does not do at all, and six described the intention rather than the implementation. Every correction in this rewrite came from the same place: a measurement we built to check ourselves, pointed at production, returning an answer we didn't want. That is the only mechanism on this page that actually matters, and it is the one I'd ask a vendor about.

And below the total, the honest answer is that some of it is the provider's bill and some of it is our model. We'd rather tell you which is which than average the two into a percentage that sounds better than either.

If you're making decisions based on cloud cost data, verify it. The cost of inaccuracy compounds silently — and by the time it surfaces, the decisions have already been made.

Related reading: See how inaccurate data manifests in real dashboards in Why Your FinOps Dashboard Is Lying to You, and how CPU peak patterns affect right-sizing accuracy in 6 CPU Peak Patterns Every FinOps Team Should Know. For Kubernetes-specific cost challenges, read our Kubernetes Cost Allocation Guide.