Claude usage on Microsoft Foundry is billed in Claude Consumption Units (CCUs) — a single Azure Marketplace billing dimension that replaced the previous per-model token meters. That simplification is good for procurement (one meter, MACC-eligible, one line to negotiate) but it puts an abstraction layer between what your applications consumed and what your invoice says. Reconciling the two is a solvable problem, as long as you know where each number comes from and how stale each one can be.
How CCU charges reach your invoice
The pipeline works like this: your applications consume input and output tokens; token usage is converted to CCUs using Anthropic's published per-model token rates (Microsoft points to aka.ms/ccu-pricing rather than publishing dollar figures in its own docs), after any contractual discounts; the CCU meter accrues hourly; and the total is invoiced monthly in arrears through Azure Marketplace, pay-as-you-go, with no prepaid credits or balances. Negotiated discounts arrive as Azure Marketplace private offers and are applied at the token-to-CCU conversion step — they can carry different rates per model, which matters for reconciliation because it means one CCU total can blend several effective per-token rates.
Two consequences for finance teams. First, the CCU meter is MACC-eligible: spend decrements a Microsoft Azure Consumption Commitment like other Marketplace consumption. Second, because CCU appears as a single line in Azure Cost Management, per-model and per-deployment visibility lives elsewhere — in the Foundry portal's Monitoring tab and in Azure Monitor metrics, not on the invoice itself.
The five-hour delay
Microsoft documents approximately a five-hour delay from the billing event before charges become visible in Azure Cost Management, and viewing them requires at least read access to Cost Management data. This delay is the number-one source of false alarms in same-day reconciliation: a load test at 9 a.m. that has not shown up in Cost Analysis by lunchtime is not missing, it is in flight. Build the lag into your tooling — an automated spend checker that compares "tokens consumed today" against "cost recorded today" without a five-hour tolerance window will page someone every busy morning.
Cross-checking CCUs against token metrics
Azure Monitor collects Foundry Models deployment metrics automatically, with no configuration required (viewing needs the Monitoring Reader role). The relevant meters for reconciliation are InputTokens, OutputTokens, and TotalTokens, sliceable by dimensions including ModelDeploymentName, ModelName, and ModelVersion. A workable monthly cross-check:
- Pull token totals per model from Azure Monitor for the invoice period, split by
ModelName(and by deployment if you charge back internally). - Convert tokens to expected CCUs using the published per-model rates from the Claude offer's pricing reference — applying your private-offer rates if you have them.
- Compare against the CCU line items in Azure Cost Management / Cost Analysis for the same period; the portal's Cost Analysis view also breaks out per-deployment input/output token cost and consumption.
- Investigate residuals in a structured order: window misalignment first (hourly metering plus the five-hour visibility lag straddling month boundaries), then cached-token accounting (cache reads and writes are priced differently from ordinary input tokens), then per-model rate differences under private offers, and only then a genuine discrepancy worth a support ticket — armed with the correlation IDs described in the dual Foundry request IDs.
Expect small, explainable deltas rather than exact equality: metric aggregation windows, in-flight usage at period boundaries, and rounding in the token-to-CCU conversion all introduce noise. The goal of the exercise is not zero difference — it is a stable, explained difference, so that a genuinely anomalous month stands out immediately.
One scope note: deployments created before CCU became generally available continue on their previous per-model billing plan, while new deployments bill in CCU automatically. A subscription with a mix of both needs two reconciliation paths until the older deployments are recreated.
Where to go next
For the marketplace mechanics behind the meter, see Foundry marketplace billing and Foundry billing mechanics; for the portal workflow, Foundry cost analysis. Internal chargeback patterns are covered in building a chargeback model.