To separate model, compute, and data costs, teams should record model usage, processing work, and data volume in distinct fields before mapping those fields to monetary charges. Measured token usage alone is not the final billed amount. While it provides a more accurate measure than pre-run assumptions, it reports token counts rather than the final amount billed. Consequently, this metric belongs in the model-usage record instead of the total-cost field.
How to Check the Split
A workable internal structure separates usage signals from billing conclusions:
| Bucket | Usage signal | What it helps teams inspect | What it does not establish |
|---|---|---|---|
| Model | Measured token usage | The volume of model use | The final billed amount |
| Compute | Query count and throughput, when defined as processing work | Processing demand | A fixed price or complete charge |
| Data | Volume of data indexed and processed | The scale of data handling | A standalone charge or total bill |
These are suggested accounting buckets, not a statement about how any particular invoice is structured. The design-principles guidance identifies data volume, query count, and throughput as cost drivers. For data volume, it specifically points to estimating the amount of data that will be indexed and processed. A cost driver is an input to cost analysis, not automatically a separate invoice line.
Model Costs: Keep Usage Distinct from the Total
Teams should preserve pre-run assumptions and measured token usage in separate fields. Keeping both prevents a planning estimate from being mistaken for measured usage or for the amount charged.
Token usage can help explain relative model activity, but it should not replace the final billed amount during reconciliation. A monetary allocation should be added only when the applicable billing definition establishes the relevant unit and rate. The cited cost guidance does not provide a universal conversion rule.
Compute Costs: Make Processing Work Visible
Query count and throughput should be recorded as workload signals when they describe processing work, rather than being folded silently into token counts or data volume. The guidance identifies both measures as cost drivers, but it does not prescribe a fixed allocation among model, compute, and data.
When an operation involves both processing and data handling, the team should document whether the related amount belongs to compute, data, or a shared bucket. That documentation helps prevent the same event from being counted twice under different labels.
Data Costs: Keep the Volume Visible
Teams should record the volume of data that will be indexed and processed, keeping estimated and measured values distinct when both are used. The cited guidance specifically points to the amount of data being indexed and processed as a cost consideration.
Data volume answers a different question from query count or throughput. Combining the measures without a documented classification can make later reconciliation harder to interpret, especially when a change in data size is mistaken for a change in processing demand.
Reconcile Without Forcing a Match
To check the split, teams should follow a structured reconciliation process. They must define the unit and reporting scope for each signal before assigning it to a bucket. It is also important to keep assumptions, measured counts, and billed amounts in separate fields. Furthermore, teams should map each monetary item to a bucket, or leave shared or unclear items unassigned until confirmed. Finally, they must compare the allocated total with the final billed amount and keep any difference visible.
Token counts should not be used to force the totals to match. The cited cost guidance distinguishes token counts from the final billed amount, so a reconciliation gap should prompt a review of billing definitions or unallocated items rather than an automatic change to the model bucket.
What Teams Must Still Confirm
The cited references do not state a universal fee, rate, or allocation formula. Before relying on the split for budgeting or oversight, teams must confirm several key parameters. They should verify whether measured token usage maps directly to a charge and which unit applies. Teams must also determine how query count and throughput are measured and assigned, along with how data volume is defined for indexing and processing.
Furthermore, organizations should clarify where applicable whether shared, bundled, or offsetting billing terms affect the final amount. Finally, they need to confirm whether estimates, measured usage, and billed amounts cover the same workload and period.
Until those points are confirmed, the ledger can organize evidence and make uncertainty visible, but it cannot establish an exact final cost from those measures alone.
Sources
The reference materials include Microsoft Learn and Microsoft Learn.