How Should Taxes, Fees, and Purchased Credits Be Separated in the Payment Ledger?

Taxes, fees, and purchased credits should be recorded as separate but linked ledger components. Preserve the gross payment and net settlement as reconciliation totals, but do not use either total as a substitute for the underlying base charge, tax, fee, credit purchase, credit redemption, refund, or adjustment. This separation makes it easier to connect payment activity to invoices, credit balances, tax records, processor settlements, and the general ledger.

The Short Answer: Record One Payment as Linked, Distinct Components

A payment can produce several economic events at once. For example, a customer might purchase usage credits, pay tax, incur a service fee, and settle the total through a processor that deducts its own fee before sending funds to the seller. Although these events are related, they do not necessarily have the same accounting or tax treatment.

A componentized ledger keeps each amount identifiable:

Component	What the ledger should preserve	Why it should remain separate
Base service value	Amount attributable to the underlying service or product	Supports invoice matching and subsequent accounting classification
Tax	Tax type, jurisdiction, rate or calculation reference, and amount	Distinguishes tax from sales value and supports tax reconciliation
Customer-facing fee	Fee type, basis, and amount	Allows platform, network, processing, or service fees to be classified independently
Purchased credits	Monetary value, credit quantity, lot ID, and contractual terms	Establishes the origin of a prepaid balance without assuming immediate service delivery
Redeemed credits	Quantity and value applied to a specific usage event or invoice	Connects consumption to the credit lot and remaining balance
Refund or chargeback	Amount, reason, original transaction reference, and status	Preserves the original event while recording its reversal or dispute
Adjustment	Amount or quantity, reason code, authorizing reference, and linked event	Creates a traceable correction without overwriting history
Gross payment	Total amount initiated or charged	Provides a control total for the customer-facing payment
Net settlement	Amount received after processor deductions and other settlement items	Supports matching to the bank without hiding the deducted components

Why gross cash movement should not be treated as a single accounting amount

Cash movement does not, by itself, determine when an expense or revenue should be recognized. It also does not establish whether a tax is recoverable, payable to a tax authority, or included in the cost of an asset or service.

The appropriate conclusion depends on factors such as:

• Whether the organization is the buyer or seller
• When the underlying service is delivered or consumed
• Whether purchased credits are refundable, transferable, or subject to expiration
• How credits are redeemed and measured under the contract
• Which entity charges, collects, or remits a tax
• The relevant jurisdiction and reporting framework
• The organization’s accounting policies and materiality thresholds

For a buyer, purchased credits may need to be evaluated as a prepayment until the related service is received. In other circumstances, applicable policy may support expense recognition at purchase or another point. For a seller, cash received for credits that have not yet been redeemed may need to be evaluated separately from recognized revenue. Neither treatment should be inferred merely from the fact that payment occurred.

Taxes also require perspective-specific handling. Taxes collected from customers are commonly tracked apart from sales because they may represent amounts payable to a tax authority. Taxes paid by a buyer can require different treatment depending on whether they are recoverable, nonrecoverable, or incorporated into the cost of the related purchase.

Separate base value, tax, fees, credit activity, refunds, and adjustments

The ledger can implement separation through individual transaction lines, dedicated account codes, structured subledger fields, or a combination of these methods. The important design principle is that every component remains independently identifiable while sharing a common transaction or event-group identifier.

Fees should have both an amount and a fee-type field. A customer-facing platform fee, payment processor deduction, card-network fee, and foreign-exchange fee may arise at different points and belong to different reconciliation paths. Recording all of them as a generic “fee” or netting them against revenue can obscure their source and intended classification.

Credits should likewise be separated into at least two event types: credits purchased and credits redeemed. A purchase establishes or increases a balance. A redemption applies part of that balance to service consumption. Keeping those events distinct prevents the original cash receipt from being confused with later usage.

A Practical Ledger Schema for Payments and Prepaid Credit Activity

A practical design usually combines a payment ledger with a credit subledger. The payment ledger records monetary events and settlement details; the credit subledger records credit lots, balances, redemptions, expirations where applicable, and adjustments. Shared identifiers connect the two.

The following schema is illustrative. Field names and accounting mappings should be adapted to the organization’s contracts, systems, jurisdictions, and reporting policies.

Core transaction, entity, currency, and source-document fields

Field	Purpose
transaction_id	Unique identifier for the ledger event
event_group_id	Links all components arising from the same commercial event
original_transaction_id	Connects a reversal, refund, chargeback, or correction to the original event
timestamp	Records when the event occurred, including time zone where relevant
event_type	Identifies purchase, redemption, fee, tax, refund, chargeback, expiration, or adjustment
customer_or_entity_id	Identifies the buyer, seller, legal entity, or internal cost owner
transaction_currency	Currency in which the transaction was initiated
settlement_currency	Currency in which funds reached the settlement account
exchange_rate	Rate used to translate between transaction and settlement currencies
gross_amount	Total amount charged or initiated before settlement deductions
net_amount	Amount remaining after identified deductions or adjustments
invoice_id	Links the event to the invoice or billing document
processor_reference	Supports matching to processor reports
bank_settlement_reference	Supports matching to bank activity
source_document	Points to the invoice, tax document, contract, credit note, or other supporting record

Multi-currency transactions should retain both currencies, the applied exchange rate, and any conversion difference as distinct data. Replacing the original transaction amount with the settled amount removes information needed to explain foreign-exchange differences and processor settlements.

Fields for base charges, tax jurisdictions, fee types, and net settlement

For the commercial components, useful fields include base_charge, tax_type, tax_jurisdiction, tax_amount, fee_type, fee_amount, refund_amount, and adjustment_amount. An organization may also use component-level account codes or subledger mappings so that each line can be routed to the appropriate review and posting workflow.

Tax records should preserve enough context to determine why an amount was calculated and which document supports it. That can include the taxing jurisdiction, tax type, invoice line, exemption or treatment reference where relevant, and the party responsible for collection. The ledger should not assume that every tax amount has the same accounting treatment.

Fee records should identify who imposed the fee and where it appears. For example, a platform fee shown to the customer differs operationally from a processor fee deducted during settlement. Both can be linked to the same transaction while retaining separate fee types, amounts, source references, and account mappings.

Credit purchases, redemptions, balances, lots, and expiration terms

A credit subledger should preserve credit history at the lot and event level where the commercial model uses those concepts. Useful fields include:

• credit_lot_id and purchase date
• Credits purchased and their monetary value
• Credits redeemed and the related usage or invoice reference
• Remaining credit quantity and value, if both are tracked
• Contractual expiration date or expiration rule, where applicable
• Refundability and transferability terms as contract attributes
• The entity, workspace, project, or cost center permitted to redeem the credits
• Adjustment reason, approver, timestamp, and linked source record

Do not assume that credits are refundable, transferable, or nonexpiring. Those characteristics should come from the applicable contract or program terms. If multiple lots have different prices or expiration terms, the ledger should also preserve the lot-allocation method used when credits are redeemed.

Preserve event history instead of rewriting prior entries

An append-oriented event model provides a clearer history than silently editing completed records. A possible sequence might include:

1. An original credit-purchase event establishes a credit lot and payment total.
2. A tax component and any customer-facing fee are recorded as linked lines.
3. A partial redemption reduces the available credit balance and references the associated usage.
4. A processor fee appears as a separate settlement component.
5. A refund creates a linked reversal for the eligible amount and credit quantity.
6. A chargeback creates a dispute or reversal event tied to the original payment.
7. An expiration event reduces the available balance if the contract provides for expiration.
8. A manual correction creates a new adjustment with a reason, authorization, and prior-event link.

Not every credit program supports every event in this example. The objective is to model applicable events explicitly rather than erasing or replacing their history. Access controls, retention policies, and operational review still need to be designed around the ledger; an event model alone does not establish correct accounting or regulatory treatment.

Reconcile every layer using shared identifiers

Reconciliation should connect the full transaction path rather than comparing only the bank deposit with the gross payment. A practical process compares:

• Invoice and customer-facing payment total
• Payment processor transaction and fee report
• Bank settlement and settlement currency
• Credit purchase, redemption, and remaining-balance records
• Tax calculation and tax documentation
• Refund, chargeback, and adjustment records
• General-ledger postings and period-end balances

Differences should be assigned explicit reason codes, such as processor timing, foreign-exchange conversion, partial settlement, refund timing, disputed payment, or posting error. Invoice IDs, processor references, bank settlement references, credit-lot IDs, and original-transaction links provide the joins needed to investigate those differences.

Illustrative buyer-side and seller-side journal flow

The following concepts are examples rather than prescribed journal entries. Actual account names, debit and credit treatment, recognition timing, and tax classification depend on the contract, service delivery, jurisdiction, entity perspective, and applicable accounting policy.

Illustrative buyer perspective: When a buyer purchases credits before consuming service, the initial event may involve cash and an account representing a prepayment, subject to the buyer’s policy. Tax and fees should be evaluated separately. As credits are redeemed and service is received, the buyer may reclassify the applicable amount from the prepayment to an expense or another appropriate account.

Illustrative seller perspective: When a seller receives cash for unredeemed credits, the receipt may need to be evaluated separately from recognized revenue. Taxes collected may be tracked separately from sales where they represent amounts payable to a tax authority. As the service is delivered through credit redemption, the seller can evaluate the corresponding revenue recognition event under its contracts and accounting policy.

Processor fees should not be hidden by recording only net cash. A seller can preserve the gross customer payment, the processor fee, and the net bank settlement as separate linked amounts, allowing each component to be reconciled and classified appropriately.

Applying the Design to Enterprise AI Cost Governance

Prepaid balances and usage-based services are especially relevant when finance teams need to connect AI consumption with budgets, projects, legal entities, or cost centers. A useful operating model distinguishes funding events from consumption events: purchasing capacity is not the same event as using a model, and neither event should be confused with the accounting conclusion applied to it.

Token Forge Cloud offers two relevant paths for enterprise AI workloads. Token Forge Cloud Managed Model APIs provides an API-first route for teams evaluating model demand and usage patterns. Token Forge Cloud Private LLM Inference supports private deployment and serving-layer control, including technologies such as quantization and GPU scheduling.

These deployment choices can inform broader AI cost-governance discussions, including how teams attribute usage and determine when workloads are predictable enough to consider private inference. The payment-ledger model in this guide is a general implementation pattern, not a description of Token Forge Cloud billing, tax, wallet, invoicing, or accounting functionality.

Ledger architecture and journal treatment should be reviewed by qualified accounting and tax professionals for the relevant contracts, entities, jurisdictions, and reporting framework. This guide provides general operational information and is not legal, tax, or accounting advice.

Next Step

Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.