A monthly prepaid-credit wallet statement should identify the account and reporting period, reconcile the opening and closing credit balances, and list every credit addition, consumption event, refund, reversal, adjustment, and expiration. It should also connect those movements to stable transaction references, funding records, applicable credit terms, and useful usage dimensions. Unlike a postpaid invoice, the statement primarily explains how previously funded credits moved during the month; it does not necessarily request payment for newly incurred charges.
The short answer: show balances, every credit movement, and the records behind them
A reconciliation-ready statement should generally contain eight groups of information:
- Statement identity: Reporting period, issue date, statement reference ID, organization name, customer ID, and wallet or billing-account ID.
- Balance summary: Opening balance, credits added, promotional or adjusted credits, credits consumed, refunds or reversals, expired credits where applicable, and closing balance.
- Transaction ledger: Date and time, transaction type, description, reference ID, usage basis where available, credit amount, and resulting balance.
- Funding references: Purchase date, amount paid, payment currency, receipt or payment reference, credits granted, and any separate tax-document reference.
- Credit classifications: Separate totals for purchased, promotional, refunded, adjusted, and expiring credits when different rules apply.
- Usage allocation: Optional breakdowns by service, model, project, workspace, API key, team, region, or environment when the platform captures those dimensions.
- Terms affecting the balance: Credit denomination, conversion method, expiration dates, consumption order, rollover rules, and restrictions where applicable.
- Reconciliation support: Downloadable records, stable transaction IDs, linked corrections, access controls, a support route, and any defined dispute window.
These are practical design recommendations rather than universal legal or accounting requirements. The necessary fields and document types depend on the platform’s commercial terms, operating jurisdictions, and customer reporting needs.
How a wallet statement differs from a postpaid invoice
A prepaid wallet statement summarizes stored-value activity over a defined period. It starts with credits already available, records movements into and out of the wallet, and ends with the remaining balance.
A postpaid invoice serves a different purpose: it normally presents charges already incurred and requests payment by a specified date. It may include an amount due, payment terms, tax information, and remittance instructions.
The distinction should remain visible in both the document title and its contents. A wallet statement should not be presented as an invoice, receipt, bank statement, or universally sufficient tax document. A customer may need several related records:
- A receipt or payment confirmation showing that cash was paid.
- An invoice or tax document where applicable to the original credit purchase.
- A wallet statement showing how credits moved after funding.
- A usage export providing more detailed operational allocation.
- An adjustment or refund record documenting a later correction.
Linking these records through stable reference IDs is more useful than attempting to make one document serve every purpose.
Why consumed credits do not automatically represent money newly owed
Credit consumption usually reduces a balance that was funded earlier. It should therefore appear as wallet activity, not automatically as a new cash liability.
For example, consuming 2,000 credits during June may reduce the wallet from 10,000 to 8,000 credits without creating a June payment obligation. The relevant cash event might have occurred when the credits were purchased in May. If the platform also allows automatic top-ups, overdrafts, or another payment arrangement, those events should be identified separately rather than blended into usage.
This separation helps finance teams avoid double-counting the original funding payment and subsequent credit consumption as two expenses or liabilities. The correct accounting and tax treatment can vary, so organizations should review it with qualified finance, tax, or legal professionals in the relevant jurisdictions.
Identify the statement, customer account, wallet, and reporting period
A reader should be able to determine immediately which entity, account, wallet, and period the statement covers. Clear identity fields also make it easier to match a PDF or portal view to exported ledger data and internal accounting records.
Statement period, issue date, and stable reference ID
The header should show:
- Statement start and end dates, including the applicable time zone.
- The date on which the statement was generated.
- A unique, stable statement or reference ID.
- Statement status, such as original, corrected, or superseded, if versioning is supported.
Time-zone disclosure matters when usage occurs around month-end. Without it, an activity shown on the last day of one system’s month may appear on the first day of another system’s reporting period.
A corrected statement should retain a relationship to the original. Replacing an earlier document without a visible version or correction reference can make historical reconciliation difficult.
Organization, customer, wallet, and billing-account identifiers
The statement should identify the legal or account name associated with the wallet, along with identifiers that distinguish the relevant customer and balance. Depending on the account structure, useful fields may include:
- Organization or account name.
- Customer or tenant ID.
- Wallet ID.
- Billing-account ID.
- Parent organization and child account, where applicable.
- Workspace or cost-center label, if the wallet is scoped below the organization level.
These identifiers should be consistent across statements, funding confirmations, ledger exports, receipts, and adjustment records. Where one organization operates multiple wallets, the statement should clarify whether balances are isolated, shared, or rolled up for reporting.
Credit denomination and currency-equivalence disclosures
The statement should name the unit being reconciled—for example, “platform credits”—and explain whether that unit has a direct relationship to currency.
If one credit does not always equal one unit of currency, readers need the applicable conversion rule. That explanation should address questions such as:
- How many credits were granted for a funding payment?
- Does the conversion vary by purchase, promotion, contract, or currency?
- Is usage priced directly in credits, or is a currency charge converted into credits?
- Which rounding rules affect individual transactions or monthly totals?
The statement should not imply one-to-one currency equivalence unless that relationship is actually defined by the governing terms. If exchange rates, negotiated rates, or promotional multipliers are involved, the applicable rule or a reference to it should accompany the funding event.
Reconcile the opening and closing credit balances
The balance summary is the statement’s central control. A reader should be able to reproduce the closing balance from the displayed movement categories.
A common reconciliation is:
> Closing balance = Opening balance + credits added + refunds or positive adjustments − credits consumed − expired credits − negative adjustments
The exact categories may differ, but each term should correspond to transaction-ledger entries. If credits are reserved when a job starts and finalized later, the statement may also need to distinguish available, reserved, pending, and settled balances.
A clear summary might show:
- Opening purchased-credit balance.
- Purchased credits added.
- Promotional credits added.
- Refunds or reversals credited back.
- Manual positive or negative adjustments.
- Credits consumed.
- Credits expired, if expiration applies.
- Closing purchased and promotional balances.
When different credit pools follow different terms, a single net balance is not enough. Purchased credits, promotional credits, and credits approaching expiration may need separate opening, movement, and closing totals.
Include a transaction ledger that explains every movement
The ledger provides the evidence behind the summary. Each row should represent a discrete wallet movement or a clearly defined aggregation that users can expand or export.
Recommended ledger fields include:
- Event date and time, with time zone.
- Transaction type, such as funding, usage, refund, reversal, adjustment, transfer, or expiration.
- Plain-language description.
- Stable transaction or event ID.
- Related usage, payment, receipt, or adjustment reference.
- Quantity or usage basis where available.
- Credits added or deducted.
- Credit pool affected.
- Resulting wallet balance.
Signed values should be unambiguous. If positive numbers add credits and negative numbers consume them, state that convention clearly. Separate debit and credit columns can also work, provided the meaning remains consistent across the portal, statement, and export.
Usage aggregation should not remove the ability to investigate underlying activity. A monthly row labeled only “API usage” may be sufficient for a high-level summary, but finance and operations teams will often need daily or event-level records to explain an unexpected movement.
Separate funding, usage, promotions, refunds, and expirations
Different transaction categories often have different commercial and reporting implications. Keeping them separate makes the wallet easier to administer.
Funding events
For each purchase or top-up, include the purchase date, amount paid, payment currency, payment or receipt reference, credits granted, and the wallet receiving those credits. Where a separate invoice or tax document exists, include its reference rather than treating the wallet statement as a substitute.
If a payment funds multiple wallets, the records should explain the allocation. If one wallet receives credits from multiple purchases, each funding event should remain traceable.
Promotional and adjusted credits
Promotional credits should be distinguishable from purchased credits if they have different expiration, refund, transfer, or usage rules. Manual credits issued after a service review or account correction should carry an adjustment reason and a reference to the related case or transaction where appropriate.
Labels such as “other credit” are rarely sufficient for reconciliation. The description should explain whether the entry is promotional, corrective, refundable, or subject to special restrictions.
Refunds, reversals, and expired credits
A refund involving cash should be distinguishable from a reversal that returns credits to the wallet. The statement should show both sides when necessary: the wallet movement and the associated payment record.
If credits can expire, show the amount, expiration date, affected credit pool, and relevant governing term. Consumption order—such as whether earlier-expiring credits are used first—should be disclosed when it affects the customer’s remaining balance. Rollover rules and restrictions should appear only when they apply under published terms.
Add usage breakdowns that support AI cost allocation
For an AI platform, wallet totals become more useful when organizations can allocate consumption to the teams and workloads that generated it. Possible dimensions include:
- Service or model.
- Project or workspace.
- API key or service account.
- Team, department, or cost center.
- Region.
- Development, test, or production environment.
- Interactive, batch, or agentic workload category.
These dimensions are optional and depend on what the platform captures. They should not expose sensitive credentials: an API-key label or masked identifier is generally more appropriate than the secret itself.
A useful allocation view connects operational quantities to the corresponding credit deduction. For model access, this might involve captured request or usage units. For privately deployed inference, organizations may instead need reporting aligned to their own serving and infrastructure controls. In either case, the definitions and aggregation rules should remain consistent enough for month-to-month comparisons.
Make exports, corrections, and disputes reconciliation-friendly
A statement should be readable by a person, while its underlying records should also be suitable for systematic reconciliation. Downloadable, machine-readable exports are therefore a valuable implementation choice. Common options include CSV or another structured format, but the appropriate formats and delivery methods depend on the platform and customer workflow.
Exports should preserve the transaction IDs, timestamps, signed credit movements, affected balances, and allocation dimensions shown in the account interface. Stable field definitions are important for finance teams that import monthly data into accounting, procurement, or cost-management systems.
Corrections should create an auditable chain rather than silently rewriting history. A practical pattern is to:
- Preserve the original transaction.
- Add a linked reversal or adjustment.
- State the reason and effective date.
- Reference the related transaction, statement, or support case.
- Reflect the correction in the next statement or issue a clearly identified corrected version.
The statement should also show where to raise a question. If the commercial terms define a dispute window, include it without implying that the same period applies to every transaction or jurisdiction. Access controls and retention policies should be evaluated according to the organization’s own governance needs.
Illustrative monthly wallet statement layout
The following example is hypothetical. It is not a Token Forge Cloud statement, product interface, pricing schedule, or contractual document.
| Statement field | Illustrative value |
|---|---|
| Statement period | 1–30 June 20XX, UTC |
| Issue date | 2 July 20XX |
| Statement reference | STMT-EXAMPLE-0620XX |
| Organization | Example Organization |
| Customer / wallet ID | CUST-EXAMPLE / WALLET-EXAMPLE |
| Credit denomination | Platform credits; see applicable conversion terms |
| Opening balance | 10,000 credits |
| Purchased credits added | 5,000 credits |
| Promotional credits added | 500 credits |
| Credits consumed | 6,200 credits |
| Refunds or reversals | 200 credits |
| Expired credits | 100 credits |
| Closing balance | 9,400 credits |
An accompanying hypothetical ledger could contain a funding entry for 5,000 credits, separately identified usage deductions, a 500-credit promotion, a linked 200-credit reversal, and a 100-credit expiration. Each entry would carry its own timestamp, type, reference ID, amount, affected pool, and resulting balance.
The summary arithmetic should match the ledger:
> 10,000 + 5,000 + 500 + 200 − 6,200 − 100 = 9,400 credits
If the statement shows a different closing balance, it should identify another category—such as a transfer or manual adjustment—that explains the variance.
Buyer evaluation checklist for prepaid-credit reporting
When evaluating an AI platform that uses prepaid credits, finance, technical, and operations stakeholders should confirm whether its reporting can answer the following questions:
- Reconciliation: Can the closing balance be reproduced from the opening balance and itemized movements?
- Traceability: Does every movement have a stable transaction ID and useful supporting reference?
- Allocation: Can consumption be assigned to the relevant project, workspace, team, API key, model, region, or environment where those data are captured?
- Credit pools: Are purchased, promotional, adjusted, refunded, and expiring credits separated when their terms differ?
- Funding: Can each credit grant be matched to the corresponding cash payment, receipt, invoice, or tax-document reference where applicable?
- Conversion: Are credit denomination, conversion, and rounding rules understandable?
- Corrections: Do adjustments preserve prior activity and link back to the original entry?
- Exports: Are sufficiently detailed, machine-readable records available for the intended reconciliation workflow?
- Access: Can organizations control who views statements, downloads records, or initiates funding and adjustments?
- Retention: Are statements and ledger records retained for an appropriate period for the organization’s needs?
- Expiration: Are expiration dates, consumption order, rollover rules, and restrictions visible where applicable?
- Disputes: Is there a clear support route and a stated dispute period if one is defined?
The final design should reflect how the buyer reconciles cash, credits, AI usage, and internal cost ownership—not simply how the platform presents a balance on screen.
Discuss model access, private deployment, and inference economics with Token Forge Cloud
Billing records are only one part of governing AI costs. Teams must also decide how model access, workload allocation, and infrastructure control fit their operating model. Token Forge Cloud Managed Model APIs provides an API-first path for model access, while Token Forge Cloud Private LLM Inference focuses on private deployment and serving-layer control. Token Forge Cloud’s serving capabilities include caching, routing, batching, quantization, and GPU scheduling.
These deployment choices can shape which usage and cost dimensions an organization needs to collect for its own reporting. They do not, by themselves, imply the availability of a prepaid wallet or monthly wallet statement.
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.