Research-backed calculator guide

Claude CCU Marketplace Invoice Reconciliation: Map AWS and Foundry Bills to Token Usage

A finance-ready method to reconcile Claude Consumption Unit invoices on AWS Marketplace and Microsoft Foundry to model, feature, workspace, and token usage.

What a CCU represents on AWS and Microsoft Foundry

The most important accounting distinction is between a usage dimension and a billing dimension. Input tokens, output tokens, cache writes, cache reads, model IDs, requests, and workspaces help explain consumption. CCU is the commercial unit that rolls those details into a marketplace charge.

On AWS, the current billing page says AWS Marketplace is the billing backend, usage is metered hourly, and monthly charges arrive on the existing AWS bill. It also states that 100 CCU represents $1.00 at the fixed price of $0.01 per CCU. A private offer affects the conversion from token-rated dollars to CCUs. It does not change the published CCU unit price.^[1]

Foundry’s CCU documentation describes the same separation. CCU is used solely for invoicing, while application calls still use tokens and model-specific rate limits. The document says the Azure invoice and Azure Cost Management show an aggregated CCU meter, while the Foundry Monitor view retains per-model token and request detail.^[2] That means a finance team should preserve both the invoice-facing aggregate and the engineering-facing detail rather than treating either one as a complete ledger.

AWS presents Claude Platform on AWS as a native Anthropic platform accessed with AWS credentials, IAM, CloudTrail, and consolidated AWS billing.^[3] That is useful for procurement and access control, but a consolidated bill is not automatically a detailed cost-allocation file. The AWS product page and the Claude Platform documentation point to separate usage and cost views for the detail needed to explain the aggregate.^[3]

The reconciliation data model

Create one normalized usage table before comparing money. A practical minimum schema is:

• provider: aws_claude_platform or azure_foundry.
• billing_account: the AWS account, payer account, Azure billing account, or subscription that owns the charge.
• workspace_or_deployment: the Claude workspace on AWS or Foundry deployment and resource scope.
• bucket_start_utc and bucket_end_utc: the hourly metering interval, not only the local calendar date.
• model_id and feature: for example, standard messages, cache write, cache hit, batch, or another billable feature.
• input_tokens, output_tokens, cache_write_tokens, and cache_read_tokens: retain separate columns rather than one total-token field.
• rate_version and effective_at: the pricing snapshot used for the calculation.
• discount_rate or discount_rule: the private-offer treatment, if applicable.
• source_file and retrieved_at: evidence for audit replay.

The invoice-side table should retain the marketplace line description, meter name, invoice ID, line period, CCU quantity, unit price, extended amount, tax, currency, credit, and any adjustment. Keep the raw line even if your accounting system later summarizes it. A summary such as “Claude AI, $92.80” is not enough to prove whether the difference came from model mix, a rate change, a private offer, a time-zone boundary, or a duplicate export.

The reconciliation key should be as narrow as the source data allows. Start with billing account and provider. Then match invoice period and UTC hour, followed by workspace or deployment when the invoice export exposes it. If the invoice has only one monthly CCU line, aggregate the provider usage to the same monthly period and retain hourly sub-ledgers for investigation. Never invent a model-level invoice split that the marketplace did not provide.

The CCU-to-token formula

For each usage bucket, calculate the gross token-rated amount as:

gross_usd = Σ(token_class_count / 1,000,000 × effective_rate_usd_per_MTok)

The sum must include every billable class present in the provider export. A model with prompt caching may have ordinary input, cache-write, and cache-hit quantities at different rates. Output tokens are normally separate. If your export contains batch, long-context, routing, geography, or other feature-specific dimensions, give each dimension its own row and rate.

Apply the contractual discount at the level specified by the offer. If one model receives 10% and another receives 15%, calculate each model’s net amount separately:

net_usd = Σ(gross_usd_i × (1 − discount_i))

Then calculate the expected meter quantity:

expected_ccu = net_usd / 0.01

The last formula is a control calculation, not permission to override the invoice. Providers may apply bucket-level rounding, credits, refunds, or corrections. The reconciliation should therefore retain both the unrounded expected amount and the documented rounding policy. Compare the invoice CCU quantity and the invoice extended amount independently. A line can have the expected CCU quantity but still have a tax, credit, or currency issue.

For Foundry, also retain the private-offer terms. Microsoft says Foundry’s estimated-cost chart does not reflect private-offer discounts, so a portal estimate can be directionally useful while still differing from the actual Azure invoice.^[2] For AWS, the documented treatment is likewise to apply the discount before conversion so that fewer CCUs are metered.^[1]

Worked cost example

The following is an illustrative control example, not a vendor quote or a forecast of your current Claude price. It assumes a USD-denominated month, a fixed CCU price of $0.01, a 10% private-offer discount, and a rate snapshot that was effective for the entire example window. Replace the example token rates with the rate card effective at each call time.

At a 0.25% tolerance, the example passes the quantity check because the absolute variance is about 0.15% of expected net spend. It does not prove the difference is immaterial in every environment. The reviewer should still identify whether the 14 CCU difference came from hourly rounding, a rate change at the boundary, a late usage record, or a correction. If the invoice instead showed 9,280 CCU, the variance would be 46 CCU and $0.46, or about 0.50%, which would fail the same tolerance and require an exception work paper.

The example also shows why using a single blended “cost per token” is dangerous. Cache hits are not ordinary input tokens in the table, and a private-offer percentage may differ by model or feature. If the source export reports only total tokens, label the result as an estimate and do not present it as a proof of invoice correctness.

Use the AI API invoice reconciliation calculator to test the arithmetic with your own invoice amount, usage buckets, rate snapshot, discount, tolerance, and currency assumptions. For a token-level estimate before the close, compare the result with the AI token cost calculator. When the rate card has changed during the month, the model pricing comparison workflow is a useful companion for documenting the model and feature assumptions.

A month-end workflow that survives review

1. Freeze the period. Define the invoice period in UTC, then record the local accounting period beside it. AWS and Azure may show monthly invoice dates while the underlying meter is hourly. Include a short ingestion-lag window only if your close policy allows it, and flag late-arriving data rather than silently changing the period.

2. Export both ledgers. Save the raw marketplace cost or invoice export and the provider usage export. On AWS, retain the invoice or Cost Explorer evidence plus Claude Console usage and cost detail. Anthropic’s AWS documentation says usage can be viewed by model, workspace, and dimension, while logs include request metadata such as time, model, workspace, token counts, and status.^[3] On Foundry, retain Azure Cost Management data plus the Foundry Monitor export. Microsoft recommends matching the same cost scope and date range when comparing estimates with actual meter charges.^[4]

3. Normalize units. Convert token counts to integer tokens, rates to USD per million tokens, CCU quantities to decimal quantities, and currency amounts to the invoice currency only after recording the USD basis. Do not mix a local-currency invoice total with a USD rate-card calculation without recording the exchange-rate source and date.

4. Re-rate at call time. Join each usage row to the model and feature rate effective when the call occurred. If a rate changed mid-period, produce two or more rate-version buckets. The invoice’s monthly date is not evidence that one rate applied to every request in that month.

5. Apply private-offer logic. Attach the signed offer ID or contract reference to each discounted row. Confirm whether the discount is per model, feature, region, or account. Never create a fake negative invoice line if the commercial terms reduce CCUs during conversion. Instead, show gross token-rated dollars, discount dollars, net dollars, expected CCUs, and the actual marketplace quantity as separate control fields.

6. Aggregate to the bill’s grain. Sum expected usage to the same provider, account, meter, and period represented by the invoice line. Preserve the lower-grain model and workspace breakdown in a child table. This gives finance a short tie-out and engineering a way to locate the cause of a variance.

7. Run controls. At minimum, test amount variance, CCU variance, period completeness, duplicate invoice IDs, duplicate usage rows, missing model IDs, unsupported rate versions, and unexplained credits. Set a documented threshold such as 0.25% or a fixed dollar amount, whichever is larger, but choose the threshold based on materiality rather than copying this example.

8. Sign and retain. The reviewer should sign the tie-out, list unresolved exceptions, and link each adjustment to raw evidence. Retain the calculation inputs so a later reviewer can reproduce the expected CCU quantity without relying on a dashboard that may have changed.

Common failure modes

Dividing a monthly invoice by total tokens. This hides cache classes, output tokens, model mix, and mid-period price changes. It can be a rough planning metric, but it is not a reconciliation.

Treating CCU as a token count. CCU is a billing unit. The same number of tokens can produce a different dollar amount when model, feature, cache state, geography, or effective rate changes.

Expecting the marketplace invoice to show model detail. AWS Cost Explorer can show an aggregated CCU line even when the Claude Console has model and workspace detail.^[3] Microsoft similarly documents aggregated Azure Cost Management visibility alongside Foundry’s per-model Monitor data.^[2]

Booking the private offer as an invoice credit by default. The documented AWS and Foundry mechanics apply the discount before conversion. Look for fewer metered CCUs, not necessarily a separate discount row.^{[1] [2]}

Ignoring old deployments. Foundry documentation says deployments created before the CCU model may continue on their earlier billing plan, while new deployments use CCU billing.^[2] Segment the reconciliation by deployment creation and billing model instead of assuming one rule covers the whole subscription.

Using portal estimates as actuals. An estimate is a planning input. The invoice and marketplace meter are the financial actuals. Microsoft explicitly notes that Foundry estimates may not reflect private-offer discounts.^[2]

FAQ

Is one CCU always equal to one token?

No. CCU is an invoice unit, not a token unit. The documented AWS price is $0.01 per CCU, while token usage is first rated using model and feature rates and then converted after discounts.^[1] The conversion must therefore retain token class, model, rate version, and discount assumptions.

How do I reconcile a single AWS CCU line to multiple Claude workspaces?

Export workspace-level usage from the Claude Console, rate it by model and feature, aggregate it to the AWS invoice period, and compare the sum with the AWS CCU line. Keep workspace rows as a sub-ledger because the AWS invoice may not expose the same detail. AWS’s product materials describe consolidated billing, while the platform documentation describes model and workspace usage views.^[3]

Where is the token detail for Claude in Microsoft Foundry?

Use the Foundry Monitor view for per-model token and request detail, and Azure Cost Management or the Azure invoice for the billed CCU aggregate. Microsoft says private-offer discounts can make the estimated-cost chart differ from actual billed cost, so use the invoice for the financial tie-out.^[2]

Should I use current Claude pricing for an old invoice?

Not without a dated rate snapshot. Rate the usage with the model and feature prices effective at each call time, document the rate source and retrieval date, and split the calculation when a rate changes. A current rate page can explain today’s planning, but it does not automatically restate a prior billing period.

What variance tolerance should finance use?

There is no universal tolerance. Set one from materiality, data latency, expected rounding, and the cost of investigation. A percentage-only threshold can miss a large dollar error on a high-volume account; a fixed-dollar-only threshold can ignore a meaningful small-account error. Use both, then escalate any unexplained variance that exceeds either limit.

Can I reconcile CCUs from the invoice alone?

You can verify the billed amount and CCU quantity from the invoice, but you cannot prove the token-to-CCU composition from that line alone. The missing evidence is the provider usage detail and effective pricing or private-offer terms. If those exports are unavailable, label the result as an invoice amount check rather than a usage reconciliation.