Provider-specific discounts should be represented as explicit, auditable pricing adjustments linked to a stable canonical usage record—not by changing the recorded usage quantity. Keep list cost, adjustment amount, adjustment type, and net cost separate, while retaining provider-specific details in namespaced metadata and the original source records.
The short answer: keep usage stable and model discounts separately
A consistent customer-facing schema depends on separating what was consumed from how that consumption was priced. The usage record should answer questions such as which workload used which model, in which region, during what period, and in what quantity. Separate adjustment records should explain negotiated pricing, commitment benefits, credits, rebates, or later invoice corrections.
Where all required values are available, the basic relationship is:
net cost = list cost + sum of signed adjustments
Under a clear sign convention, discounts and credits are negative adjustments, while surcharges or upward corrections are positive adjustments. This equation should not be applied when the source does not provide a reliable list cost or does not disclose enough information to classify the difference.
Why discounts should not change metered quantities
Changing usage quantities to reflect a discount creates ambiguity. A record showing fewer tokens, requests, GPU-hours, or other units could mean either that the workload consumed less or that a pricing concession was applied. That ambiguity makes capacity analysis, unit economics, chargeback, and invoice reconciliation harder.
Usage should change only when the underlying meter is corrected. A pricing discount should change cost, not consumption. If a provider later corrects the measured quantity, treat that as a metering revision with its own source reference rather than disguising it as a pricing adjustment.
This distinction is especially important for AI inference workloads. Engineering teams may need token or compute quantities for optimization, while finance teams need the final billed cost. Both groups should be able to use the same record without assigning different meanings to the quantity field.
The relationship among list cost, adjustments, and net cost
The cost model should preserve several concepts independently:
- Metered usage: The quantity reported by the source, such as input tokens, output tokens, requests, or compute time.
- List cost: The cost obtained from an identified reference price before separately disclosed adjustments.
- Pricing adjustment: A signed amount associated with a defined type, scope, period, and source.
- Credit: A value that reduces the amount payable but may not change the effective unit rate for the underlying usage.
- Net cost: The resulting cost after applicable adjustments, where the necessary source data is available.
- Final billed cost: The invoiced amount after provider reconciliation, which may arrive later than operational usage data.
A negotiated rate requires careful treatment. If a provider exposes both a reference rate and a negotiated rate, the difference can be represented as an adjustment. If it exposes only the contract-priced amount, do not invent a list price or implied discount. Record the known cost and leave undisclosed fields null.
Define the canonical customer-facing usage record
The canonical record is the stable external contract used by dashboards, allocation systems, analytics pipelines, and customer-facing exports. Its fields should maintain the same names and semantics even when upstream providers use different terminology.
Core dimensions: account, workload, model, provider, region, and time window
A practical usage record should identify the business owner and technical source of consumption. The following field model is a provider-neutral starting point rather than a provider-specific billing format.
| Field | Data type | Purpose | Nullable? | Fictional example |
|---|---|---|---|---|
usage_record_id | String | Stable identifier for the canonical usage event or aggregate | No | usage_01HZX |
account_id | String | Account or billing owner | No | acct_research |
workload_id | String | Application, service, project, or cost-allocation unit | Yes | support_assistant |
model_id | String | Canonical model identifier used by the organization | Yes | model_text_a |
provider_id | String | Canonical source-provider identifier | No | provider_example |
region | String | Service or execution region, when reported | Yes | region_a |
period_start / period_end | Timestamp | Metering window covered by the record | No | 2026-01-01T00:00:00Z |
quantity | Decimal | Unmodified metered amount | No | 3000000 |
unit | String or enum | Meaning of the quantity | No | input_tokens |
source_currency | ISO currency code | Currency in which source cost was reported | Yes | USD |
list_cost | Decimal | Disclosed pre-adjustment reference cost | Yes | 120.00 |
adjustment_total | Decimal | Sum of applicable signed adjustments | Yes | -15.00 |
net_cost | Decimal | List cost plus applicable adjustments | Yes | 105.00 |
cost_status | Enum | Indicates whether cost is estimated, accrued, or invoiced | No | invoiced |
schema_version | String | Version of the canonical contract | No | 1.0 |
Use controlled unit definitions. For example, input tokens and output tokens should remain distinct when pricing or analysis depends on that distinction. If a source supplies only a combined token total, record the combined unit rather than fabricating an input-output split.
Quantity, unit, currency, and cost fields
Quantity and unit fields should describe only metered consumption. Currency and cost fields should describe financial values. Combining both into a field such as billable_usage makes it unclear whether the value is a physical measure, a rated measure, or an invoiced amount.
Nullability is also part of the contract. Common situations include:
- Usage is available before any cost data arrives.
- Net cost is available, but list cost is not disclosed.
- A credit appears at the account or invoice level and cannot be attributed to one workload.
- The provider reports an effective rate without identifying a separate discount.
- An invoice correction arrives after an earlier record was marked provisional.
In these cases, preserve the known values and leave unsupported values null. A difference between an internal estimate and an invoice does not, by itself, prove that a discount was applied.
Raw source identifiers needed for auditability
Normalization should not discard the source representation. Retain the original record or an immutable reference to it, along with identifiers such as:
- Source line-item ID and invoice ID
- Source account, project, subscription, or contract ID
- Original meter and SKU names
- Source event time and ingestion time
- Source schema version
- Adapter or transformation version
- Raw cost, quantity, unit, and currency values
Provider-specific attributes can live in a namespaced object such as provider_metadata.provider_example. This avoids adding a new top-level column every time a provider introduces a pricing concept, while still preserving information needed for investigation and reconciliation.
Sensitive source identifiers should be governed according to the organization’s access and retention policies. Not every identifier needs to be exposed in every customer-facing view, even when it is retained in the underlying data model.
Model discounts as linked adjustment records
A separate adjustment entity makes the pricing history explicit. It also supports discounts that apply above the individual usage-line level, including a workload, account, billing period, commitment pool, or invoice.
| Field | Data type | Purpose | Nullable? | Fictional example |
|---|---|---|---|---|
adjustment_id | String | Unique adjustment identifier | No | adj_01 |
usage_record_id | String | Direct link to a usage record when applicable | Yes | usage_01HZX |
adjustment_type | Enum | Business meaning of the adjustment | No | committed_use_discount |
scope_type | Enum | Level at which the adjustment applies | No | usage_line |
scope_id | String | Identifier for the applicable line, workload, pool, period, or invoice | No | usage_01HZX |
amount | Decimal | Signed adjustment in source currency | Yes | -18.00 |
currency | ISO currency code | Currency of the adjustment | Yes | USD |
effective_start / effective_end | Timestamp | Period to which the adjustment applies | Yes | 2026-01-01 to 2026-01-31 |
allocation_method | Enum | How a higher-level amount was distributed | Yes | direct |
precedence | Integer or enum | Order used when multiple pricing rules interact | Yes | provider_reported |
source_reference | String | Link to the supporting source line or document | Yes | invoice_line_88 |
corrects_adjustment_id | String | Earlier adjustment corrected by this record | Yes | adj_01 |
posted_at | Timestamp | Time the adjustment became available | No | 2026-02-05T10:00:00Z |
Keep adjustment types distinguishable when the source permits. Useful categories can include:
- Negotiated-rate adjustment
- Tiered-pricing adjustment
- Committed-use discount
- Promotional credit
- Service credit
- Rebate
- Surcharge
- Tax or fee, if included in the intended cost model
- Post-billing correction
Do not force a classification that the source cannot support. An unknown_adjustment type with the original source label is more reliable than an inferred category presented as fact.
Define scope, precedence, and allocation explicitly
A discount does not necessarily apply to each request or token. Commitment benefits may be calculated across an account or pooled across workloads. Rebates may be issued after a billing period, while promotional credits may apply only after other discounts have been calculated.
Each adjustment should therefore identify:
- Scope: The usage line, workload, account, commitment pool, billing period, or invoice to which it applies.
- Effective period: When the pricing rule applies, which can differ from when it is posted.
- Precedence: Whether it is applied before or after another pricing component when the source specifies an order.
- Allocation: Whether the amount is direct, proportional, evenly distributed, or intentionally unallocated.
If a provider reports only an invoice-level credit, retain it at the invoice level unless the organization has a documented allocation policy. Any internal allocation should be labeled as allocated rather than provider-reported, with the allocation method and rounding behavior retained.
Handle currency conversion and late-arriving corrections
Currency normalization should not overwrite source financial values. Preserve the source amount and source currency, then add separate reporting fields when a common currency is needed.
A converted value should retain the reporting currency, exchange rate, conversion timestamp, and rate source. This allows teams to distinguish provider pricing changes from foreign-exchange movement. Discounts and their associated base costs should generally be converted using the same documented policy when they are compared or aggregated.
Late-arriving discounts, credits, and invoice corrections should be represented with append-only or versioned records. Do not rewrite the original usage quantity simply to make an earlier estimate match the invoice.
A practical lifecycle might include:
- Usage arrives with quantity fields and provisional cost.
- Initial pricing adjustments arrive with daily or monthly cost data.
- The invoice establishes an invoiced cost state.
- A later credit or correction is appended with its own posting date and source reference.
- Reconciliation views calculate the current total while preserving the history that produced it.
This model supports both an “as known at the time” view and a current reconciled view. It also prevents historical dashboards from changing without an explainable adjustment trail.
Worked implementation example
The following fictional example shows one unchanged usage record linked to a discount and a later correction. The amounts and identifiers are illustrative only.
Canonical usage record
| Record ID | Quantity | Unit | List cost | Adjustment total | Net cost | Currency |
|---|---|---|---|---|---|---|
usage_01HZX | 3,000,000 | input_tokens | 120.00 | -15.00 | 105.00 | USD |
Linked adjustment history
| Adjustment ID | Type | Scope | Amount | Posted status | Relationship |
|---|---|---|---|---|---|
adj_01 | committed_use_discount | usage_line | -18.00 | Initial | Applies to usage_01HZX |
adj_02 | post_billing_correction | usage_line | +3.00 | Later correction | Corrects the financial effect of adj_01 |
The usage quantity remains 3,000,000 throughout. The first adjustment reduces cost by 18.00, while the correction adds 3.00 back. The cumulative adjustment is therefore -15.00, producing a net cost of 105.00.
If the correction arrived after an earlier report had been generated, the original adjustment record would remain available. A current-cost query would include both records, while a historical “as of” query could reproduce the state before the correction was posted.
If the discount had applied to an entire commitment pool rather than this usage line, usage_record_id could remain null. The adjustment would instead reference the pool and period. A separate allocation layer could distribute it to workloads when required, without presenting that allocation as a provider-supplied fact.
Preserve the external contract with adapters and schema versioning
Provider adapters can isolate source-format changes from the customer-facing contract. Each adapter maps source fields into canonical dimensions, retains raw identifiers, emits adjustment records when supported, and records which transformation version was used.
A resilient implementation generally follows these principles:
- Treat source ingestion, normalization, rating, allocation, and reconciliation as separate stages.
- Version canonical schemas and define the semantics of every field and enum.
- Prefer additive changes for optional fields instead of changing existing meanings.
- Preserve unknown provider values in namespaced metadata even when no canonical mapping exists.
- Record source and adapter versions so a transformation can be reproduced.
- Test quantity, sign, currency, scope, and rounding behavior at adapter boundaries.
- Expose cost status so provisional operational estimates are not mistaken for invoices.
Schema versioning should protect meaning, not merely field names. If net_cost initially means accrued cost and later changes to mean final invoiced cost, keeping the same field name would still break the contract. Separate fields or an explicit status dimension make the transition visible.
The same principle applies to enums. A consumer should be able to handle a newly introduced adjustment type without failing or silently treating it as an existing category. An other or unknown value can preserve forward compatibility when accompanied by the original provider label.
Apply the pattern to enterprise LLM inference cost control
A normalized usage-and-adjustment model can help organizations examine inference economics across managed API access and private model serving without confusing consumption changes with pricing changes. It can also give engineering, finance, and operations teams a shared vocabulary for workload usage, provider charges, internal allocation, and invoiced cost.
Token Forge Cloud Managed Model APIs provide an API-first path for teams seeking model access and usage data before workloads become predictable enough to consider private deployment. Token Forge Cloud Private LLM Inference supports private deployment paths where models, prompts, and telemetry remain in the customer’s controlled environment.
For private inference, serving decisions such as caching, routing, batching, quantization, and GPU scheduling can affect operational economics. A consistent measurement model helps teams examine those cost drivers while keeping API charges, infrastructure consumption, contractual adjustments, and internal allocations conceptually separate.
The appropriate implementation will depend on where usage and financial data originate. Managed API records, self-deployed infrastructure telemetry, commitment agreements, and invoices may each operate at different levels of granularity. The schema should preserve those differences rather than implying that every cost can be attributed to an individual request.
Next step
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.