Model Your First GPU Settlement Transaction
Clone Formance Ledger from GitHub, run it locally, and model the tenant-to-operator settlement split from this article as your first transaction.
A customer launches 800 AI jobs at once, paid for from a $10,000 prepaid account. The system tracks usage every second across every machine. Partway through, three of those machines get shut down early, and the software running on them crashes before it can report the final usage numbers.
GPUs (graphics processing units) are the specialized chips that power AI workloads, rented out by the hour to companies training large language models like GPT or Claude, or running inference to serve those models to end users. By the end of the month, the finance team can't match the bill to the GPU usage records, the hardware provider is fighting over an $8,200 payment, and the customer's prepaid account has somehow gone $412 into the negative.
GPU billing is a payment system and not a reporting layer. GPU-hours are metered in fractional units, rated against tiered contracts, and settled across tenants, operators, and financing partners, each of whom expects a different number.
We believe application-layer enforcement of ledger invariants fails under the concurrency GPU billing generates, so GPU-hours and dollars belong in one double-entry ledger, like Formance Ledger. One ledger prevents the metering-versus-billing drift that breaks month-end close and blocks financing partners from auditing usage revenue.
The GPU compute market has three sides: operators who own the hardware, tenants who consume it, and financing partners who fund the deployments. Money moves between the three sides at machine speed, and a billing platform sits in the middle of all three flows. That position turns every metering ambiguity into a money dispute with a named creditor on the other end.
Operators sell GPU capacity to tenants through a platform that sits between them as the middleman for both sides. The platform charges the tenant, keeps a cut, and pays the operator the rest, so its books always track both what it owes and what it's owed on every job. Public GPU marketplaces like Vast.ai, RunPod, and Lambda all work this way, each with their own take-rate and payout rules.
AI agents, job schedulers, and inference routers buy GPU time automatically, so spend tracks how much code runs, and not how many people log in. Spending grows with how much code runs, not how many people use it.
Inference now accounts for more AI infrastructure spending than training, and it arrives in short, overlapping bursts. That means billing needs to track usage by the second, and many jobs may pull from the same prepaid balance at the same time. Under that kind of load, prepaid balance limits often break down.
Financing partners put up the money for the hardware operators buy, and they get paid back from the GPU-hours those machines are expected to sell. Their risk depends entirely on whether the platform can connect delivered hours to collected dollars. When it can't, the record that justified the loan effectively disappears.
Nvidia itself has become the linchpin of this financing chain, with Wall Street lining up hundreds of billions of dollars to securitize GPU capacity much like mortgages were once bundled into tradable debt.
Financing deals often come with extra strings attached from the hardware supplier, like revenue-sharing or rent-back terms on unused capacity, and the operator bakes those costs into every GPU-hour it sells.
GPU-hours behave like a currency because they move through states (delivered, reserved, consumed, billed) and should be accounted for together, in double-entry, alongside the money they generate. Understand how GPU metering works as an event pipeline, why GPU-hours belong in a double-entry ledger, and how to handle preempted spot jobs to avoid money drifting from the ledger.
GPU metering works as an event pipeline. The steps are:
Unique event IDs plus a short deduplication window keep retries from being counted twice. Idempotent ingestion is essential for the same reasons it matters to ensure ledger integrity anywhere money is counted.
How finely you track usage shapes every downstream pricing and settlement decision. Platforms pick per-second or per-minute billing and set contract-specific rounding rules for partial minutes.
GPU-hours belong in a double-entry ledger next to dollars because recording GPU-hour state changes alongside the dollar entries they generate keeps hours and money in the same place.
A GPU-hour moves through four states (reserved, delivered, consumed, and billed) that map directly onto how currency moves through accounts, and each transition is a source-and-destination entry. Each entry must balance according to the discipline of double entry. Recording both quantities together in one ledger keeps the hour and the dollar in the same system of record. The application still has to supply the correct quantities and pricing logic.
When a spot job gets cut short, the platform has to generate its own "end" event, because the software on the machine dies before it can send one, and per-second billing depends on that final timestamp.
Two problems follow: figuring out actual usage from gaps in the heartbeat data, and deciding whether the control system or the machine itself emits the substitute event.
Whichever one does it, the design has to preserve the delivered-to-consumed handoff. A host gets paid or doesn't based on that handoff. Recording both when an event was logged and when it actually happened lets the platform later correct a preemption to the true end time without rewriting history the financing partner has already audited.
Rating is where usage records match a pricing plan, and it's where most costly GPU billing bugs come from. It maps each product code to a price, applies the right tier (spot, on-demand, or reserved), adds any extra fees, and splits jobs that run across two billing periods.
Understand what the ledger entries look like for a single GPU job (tenant charge, operator payment, and platform cut) and how to match GPU-hour usage against billed dollars to keep tracking finances accurate.
A rated GPU job splits into a charge on the tenant's side (from a prepaid balance or an invoice) and a payment owed on the operator's side, recorded together as one multi-party ledger entry because it's a single transaction that touches many accounts at once.
Take an example training job that uses 1,024 GPUs for about 20 hours at $2.35 per GPU-hour. That's a $48,128 charge and 20,480 GPU-hours delivered. With a 15% platform cut, the platform books $7,219.20 and the operator gets $40,908.80.
Acme's prepaid funds sit in @customers:acme:prepaid, the operator's payment owed sits in @sellers:h4421:payable, and the platform's cut goes to @platform:revenue:takeRate. The GPU-hour side of the same transaction moves 20,480 GPU-hours from @sellers:h4421:capacity:delivered to @sellers:h4421:capacity:consumed.
In Numscript, Formance's transaction language, this looks like:
// GPU_USAGE_SETTLEMENT
// Event: settle Acme's GPU job; platform keeps a 15% take-rate
// Records the USD split and the GPU-hour transition atomically.
send [USD/2 4812800] (
source = @customers:acme:prepaid
destination = {
15% to @platform:revenue:takeRate
remaining to @sellers:h4421:payable
}
)
send [GPU_HOUR 20480] (
source = @sellers:h4421:capacity:delivered
destination = @sellers:h4421:capacity:consumed
)
set_tx_meta("event_type", "gpu_usage_settlement")
set_tx_meta("job_id", "job001")The Numscript transaction records the dollar split (one charge and two payments) and the GPU-hour transition in one write. Either the whole transaction goes through, or none of it does. There's no way to end up in a broken state where the tenant was charged, but the operator was never paid, and no cleanup script is needed if a process crashes partway through.
Matching GPU-hour usage against billed dollars needs two things: charges saved in an unchangeable ledger record, and a scheduled job that sums the invoice from raw usage data and compares it to what the billing system actually produced.
When usage tracking and billing live in separate systems, the numbers drift apart quietly (metering-versus-billing drift in action), and the mismatch shows up later as a gap nobody can trace to specific hours.
Reconciliation runs a scheduled comparison between what the meter says was delivered and what the billing system says was charged, flagging any gap as soon as it appears. The only twist for GPU billing is that one side of the comparison is measured in hours instead of dollars.
Settling GPU billing requires separating workload authorization from payment, managing USDC and fiat on one ledger, recording the USDC-to-USD exchange rate on every transaction, and tracking payouts through every stage until the money actually lands.
Settling GPU billing means moving money between tenants and operators across different payment rails: cards, bank transfers, stablecoins, and agent-driven payments. Each has its own timing, refund rules, and dispute process, and none follows the same schedule as the platform's internal ledger.
Underneath every payout is an authorization question: who approved this workload, and who is on the hook to pay for it? With human users, they're usually the same person.
With AI agents, job schedulers, and inference routers spending automatically, the entity that approved the spend and the entity that owes the money are often different, and the platform has to keep them straight for audits, disputes, and refunds.
The clean way to handle it is to separate the approval (the mandate) from the payment that fulfills it, and treat both as accounts in the ledger, one per approval and one per payer. When a payment fails or gets disputed, the platform can trace it back to the original authorization without guessing.
The USDC-to-dollar exchange rate should be saved on each transaction as it happens. It should not be looked up later from a rates table. Paying an operator in USDC while charging a tenant in dollars requires linking the two sides in one transaction, with the exchange rate stored right on the transaction.
A stored rate lets you reproduce any past settlement exactly the way it happened. A rate looked up later turns every historical number into a guess.
An operator payout moves through stages: accrued (the platform owes it), instructed (payment sent to the rail), cleared (rail confirms), and confirmed (funds landed). This status belongs on the debt itself, and not as a flag on a specific payment attempt.
An operator credited on the ledger isn't the same as an operator actually paid, and the gap depends on the payment method. Cards clear in seconds, ACH takes one to two business days, while on-chain stablecoin transfers take minutes.
A status flag tells you where one payment attempt is. Tracking status on the debt itself tells you what the platform still owes if that attempt fails, which is what audits, disputes, and reversals ultimately reduce to.
Formance itself doesn't hold or move money. All actual payments run through a connected provider, such as a payment processor, bank, exchange, or crypto custodian. Formance records who owes what and triggers the payouts through those connections.
GPU financing prices delivered-and-paid GPU-hours rather than the hardware, and underwriting it requires an immutable per-operator usage-to-cash record.
The immutable per-operator usage-to-cash record is what makes multi-billion-dollar bets on future usage revenue underwritable in the first place. Financing partners feel the pain last. After tenants have already swallowed billing errors, hardware providers have already fought over payouts. Without a trustworthy record of every GPU-hour that turned into cash on compute marketplaces, there's no way to price the risk they're taking on.
GPU financing prices what the hardware will actually earn. When a vendor helps finance a deployment, the deal often comes with extra terms, including that the vendor may require a cut of the revenue or the right to rent back unused capacity. The operator prices those terms into every GPU-hour it sells.
The financing agreement and the usage meter are two views of the same thing. And the exposure is huge. CoreWeave reported $21.4 billion of debt against a $66.8 billion revenue backlog, and every vendor-financed deployment depends on how many GPU-hours actually get delivered, billed, and collected.
Underwriting a GPU financing deal requires an uneditable per-operator record. Delivered GPU-hours and settled dollars or USDC, with any corrections added as new entries that point back to the original event.
A financing partner backing one operator needs to see only that operator's data, isolated from every other operator on the platform, and every transaction should be chained to the previous one. The partner gets a tamper-evident audit trail without needing a separate blockchain.
Overwriting a row destroys the history the financing partner is paying to see. Most GPU platforms don't produce this record today, which is why underwriting these deals is still guesswork, unless you have a ledger.
Everything in this article (metering GPU-hours as a currency, rating them without drift, settling across fiat and stablecoin rails, and producing the immutable per-operator record) comes down to one requirement: GPU-hours and dollars have to live in the same double-entry ledger, recorded atomically, and never overwritten.
Formance Ledger records GPU-hour transitions and dollar postings in a single atomic transaction, handles the concurrency of thousands of jobs drawing on the same prepaid balance, supports multi-asset transactions (USD and USDC linked by a stored exchange rate), and gives financing partners a hash-chained, per-operator audit trail.
It's open-source (MIT License), programmable through Numscript, and sits alongside your general ledger or ERP as a product ledger, not a replacement.