A downloadable usage export should include immutable record identifiers, explicit timestamps and billing periods, organizational allocation fields, model and serving dimensions, measured and normalized quantities, itemized rates and charges, and correction or invoice lineage. Finance and engineering should be able to analyze the same records independently, using shared IDs, units, pricing references, and control totals without relying on an opaque aggregate charge.
The Short Answer: Export Identity, Usage, Allocation, Pricing, and Lineage
A useful export connects an operational event—such as an inference request, batch job, or media-generation task—to its measured consumption, allocation, pricing treatment, and eventual financial result. That requires more than token counts and a total cost column.
The field groups both teams need
| Field group | Representative fields | Question answered |
|---|---|---|
| Record identity | Usage-record ID, request or trace ID, source system, export timestamp, schema version | Which event does this row represent, and where did it originate? |
| Time | Usage start and end, timezone, reporting period, ingestion timestamp, late-arrival status | When did the usage occur, and which period should include it? |
| Organizational allocation | Tenant, billing account, business unit, project, application, environment, cost center, owner, stable tags | Who generated the usage, and where should the cost be allocated? |
| Model and serving context | Model, model version, endpoint, deployment, region, route, cache outcome, serving configuration | How was the workload served? |
| Measured usage | Input and output tokens, cached tokens, requests, media units, compute time, GPU time, status | What did the metering system observe? |
| Normalization | Usage unit, raw quantity, normalized quantity, normalization method | How was measured consumption converted into a billable unit? |
| Pricing and charges | Rate, pricing version, gross charge, discounts, credits, surcharges, taxes, adjustments, net charge, currency | How did the usage become a monetary amount? |
| Reconciliation lineage | Invoice reference, original-record ID, reversal indicator, adjustment reason, calculation method | How does the record connect to corrections and financial documents? |
Tokens are only one possible usage unit. Depending on the workload, an export may need to represent requests, images, audio duration, video duration, compute time, GPU time, or another documented unit. Incompatible units should remain separate rather than being combined into a single usage total.
Why measured usage, normalized usage, rated cost, and invoiced amounts must remain distinct
These values describe different stages of the usage-to-bill process:
- Measured usage is the quantity observed by the metering source, such as input tokens, output tokens, requests, or GPU seconds.
- Normalized billable usage is the quantity produced after applying documented conversion, eligibility, cache, retry, or aggregation rules.
- Rated cost is the monetary result of applying a specified rate or pricing method to billable usage.
- Invoiced amount is the amount represented on a finalized invoice or statement, potentially after credits, taxes, corrections, or period-level adjustments.
A single cost field cannot explain these stages. Keeping them separate allows engineering to validate measured quantities while finance verifies rates, adjustments, and invoice mapping. An amount_status or equivalent field should also identify whether a value is estimated, rated, finalized, or linked to an invoice.
Start With a Minimum Viable Schema for Traceable Usage Records
The minimum viable schema should make every row identifiable, time-bound, allocatable, measurable, and rateable. It does not need every item of operational telemetry, but it should preserve enough context to reproduce the documented calculation and investigate discrepancies.
Record, request, source-system, and schema identifiers
Every row should have a unique usage_record_id that remains stable across exports. If a correction is required, preserving the original row and issuing a correction, reversal, or replacement record generally creates clearer lineage than silently changing historical values.
Related identifiers should be included where applicable and safe to share:
request_id,job_id,batch_id, ortrace_idsource_systemcalculation_method_idexport_generated_atschema_version
Request and trace identifiers help engineers connect usage to operational telemetry. They should not require prompt text, response content, secrets, or unnecessary personal data to appear in a finance-facing export.
Usage timestamps, timezone, reporting period, and late-arrival status
Include both usage_start_at and usage_end_at when duration or interval boundaries matter. Every timestamp should use a documented convention and explicit timezone, preferably as part of the timestamp or in a separate timezone field.
The schema should also include a reporting_period or billing-period identifier. This avoids forcing users to infer period membership from timestamps when billing cutoffs, local time, or late-arriving records are involved.
An ingested_at timestamp, late_arrival_status, or both can show whether a record entered the billing dataset after its usage period. This is important when engineering sees an event in operational logs before finance sees it in a period export.
Tenant, billing account, project, environment, cost center, owner, and stable tags
Allocation fields should bridge technical ownership and financial responsibility. Useful dimensions include:
- Customer or tenant ID
- Billing-account ID
- Organization or business unit
- Project, workspace, or application
- Environment, such as production or development
- Cost center
- Business or technical owner
- User-defined tags with stable keys
Tags are most useful when their keys and values follow a governed convention. Free-form labels that change frequently can make month-over-month analysis unreliable. If allocation metadata can change after usage occurs, the export should define whether it captures the value at event time, rating time, or export time.
Recommended minimum column set
| Column | Purpose |
|---|---|
usage_record_id | Stable unique identifier for the usage row |
related_event_id | Request, job, batch, or trace ID where applicable |
source_system | System that produced or supplied the record |
export_generated_at | Timestamp for creation of the export |
schema_version | Version of the column and calculation contract |
usage_start_at, usage_end_at | Usage interval or event time |
timezone | Timezone convention used by the record |
reporting_period | Billing or reporting period assignment |
ingested_at or late_arrival_status | Visibility into delayed records |
tenant_id, billing_account_id | Customer and billing ownership |
organization, project, environment | Operational allocation dimensions |
cost_center, owner, tags | Financial ownership and custom allocation |
usage_unit | Tokens, requests, seconds, images, or another defined unit |
raw_quantity | Directly measured quantity |
normalized_quantity | Quantity after documented billing normalization |
pricing_reference | Rate-card, contract, or pricing-version identifier |
rate, rate_unit | Applied price and its denominator |
gross_charge | Charge before separate financial adjustments |
discount, credit, surcharge, tax, adjustment | Individually represented monetary components |
net_charge, currency | Resulting amount and denomination |
record_status, amount_status | Operational outcome and estimate/final state |
original_record_id, adjustment_reason | Correction, replacement, or reversal lineage |
This is a recommended design pattern rather than a statement that every system currently exposes these fields.
Add an Expanded Schema for Operational Analysis
The expanded schema should capture serving decisions that can materially explain consumption or cost. For AI inference, that may include the model version, serving endpoint, routing outcome, cache status, or deployment configuration.
| Expanded dimension | Recommended fields | Reconciliation use |
|---|---|---|
| Model identity | Model name, model version, provider where relevant | Detect changes in model mix or pricing treatment |
| Serving destination | Endpoint, deployment ID, cluster ID, region or location | Attribute usage to serving infrastructure |
| Routing | Route selected, routing-policy version, fallback indicator | Explain why a request reached a particular model or deployment |
| Caching | Cache status, measured reused quantity, cache-policy version | Separate newly processed usage from measured reuse where supported |
| Serving configuration | Quantization or configuration identifier when material | Compare usage and cost across documented configurations |
| Workload modality | Input/output tokens, requests, images, audio, video, compute time, GPU time | Preserve modality-specific quantities and units |
| Outcome | Success, failure, cancellation, retry status | Determine which events were processed, retried, or excluded |
| Correction lineage | Original record, duplicate flag, reversal flag, adjustment reason | Trace corrections without overwriting history |
| Financial lineage | Statement, invoice, or billing-line reference when available | Connect usage records with downstream financial documents |
A retry should not automatically be treated as billable or non-billable. The export and its data dictionary should state the applicable rule. The same principle applies to failed requests, cancellations, cache hits, batch operations, and fallback routes.
Keep Pricing and Monetary Fields Transparent
A reconciliation-ready export should expose the components of the calculation rather than only the result. A useful conceptual equation is:
Gross charge − discounts − credits + surcharges + taxes ± adjustments = net charge
The actual formula depends on the documented pricing method. For example, some adjustments may be applied at the individual usage-record level, while others may appear only at the account or invoice level. The export should identify the aggregation level rather than allocating period-level adjustments to individual events without explanation.
Pricing lineage should include the applied rate, its rate_unit, and a rate_card_id or pricing_version. If tiered or graduated pricing applies, the schema may also need a tier identifier or calculation-method reference.
Currency should be explicit for every monetary value. If conversion occurs, include the source currency, target currency, conversion rate, and conversion date or reference. Do not mix amounts in different currencies in the same control total.
Let Finance and Engineering Reconcile the Same Records Independently
Both teams should begin with the same immutable records, then group them according to their responsibilities.
| Finance workflow | Engineering workflow |
|---|---|
| Group by reporting period and billing account | Group by usage time and source system |
| Allocate by organization, cost center, owner, and stable tags | Allocate by project, application, environment, and deployment |
| Compare currency, pricing version, rate, and rate unit | Compare model, endpoint, route, and serving configuration |
| Review discounts, credits, surcharges, taxes, and adjustments | Review raw quantities, normalized quantities, cache outcomes, retries, and statuses |
| Map finalized records to statements or invoice lines | Map records to requests, jobs, batches, traces, or infrastructure telemetry |
The teams can then compare shared control totals for:
- Record count
- Usage quantity, separated by compatible unit
- Gross charge
- Discounts, credits, surcharges, taxes, and other adjustment categories
- Net charge
Matching control totals can increase confidence and help isolate discrepancies, but they do not guarantee invoice agreement. Differences may result from late-arriving usage, rounding, currency conversion, period-level credits, corrections, or a distinction between estimated, rated, and invoiced values.
A practical investigation sequence is to compare record counts first, quantities second, rates third, and monetary adjustments last. This narrows the search from missing or duplicate events to normalization differences, pricing-version differences, and downstream financial treatment.
Make the Export Usable as a Data Contract
A machine-readable format such as CSV or another structured format is generally preferable for repeatable analysis. The format alone is not enough: the export should be accompanied by a versioned data dictionary defining:
- Field name and business meaning
- Data type, unit, precision, and rounding rule
- Allowed values and null behavior
- Timestamp and timezone conventions
- Record aggregation level
- Raw-to-normalized calculation rules
- Rate and monetary calculation rules
- Treatment of retries, failures, cancellations, cache hits, duplicates, and reversals
- Effective date and change history for each schema version
Stable column names reduce unnecessary integration work. When a breaking change is unavoidable, a new schema version and effective date allow finance and engineering to update their validation logic deliberately.
Privacy and access design matter as well. Finance-facing records usually need identifiers, quantities, allocation metadata, and financial lineage—not prompts, responses, credentials, secrets, or unrelated personal information. Operational details should be limited to what is necessary for allocation and reconciliation.
Usage Exports in a Private LLM Inference Strategy
Token Forge Cloud focuses on private LLM inference and serving-layer optimization across areas such as caching, routing, batching, quantization, and GPU scheduling. These serving decisions can create useful operational dimensions for teams evaluating inference economics, although the dimensions that belong in an export depend on the deployment, metering method, and pricing model.
Token Forge Cloud’s Managed Model APIs provide an API-first path for teams seeking model access and usage data before private deployment. Token Forge Cloud Private LLM Inference is designed for enterprises evaluating greater control over private deployment and the serving layer. In either scenario, buyers should define their required usage, allocation, pricing, and lineage fields before implementation so that technical telemetry and financial records can be connected without treating them as interchangeable.
Next Step
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.