Usage-based and AI compute billing break the seat-and-invoice model. Consumption happens in the product. Pricing lives in the contract. Cash arrives later from a processor. If those three stay in different tools, the close becomes a reconstruction project — not a report.
This is the accounting problem for companies that bill on GPU hours, API calls, tokens, storage, or any metered unit. It is also the problem if you are setting books up for the first time and already know revenue will be usage or compute. Starting in a generic ledger and “figuring billing out later” is a 12–18 month migration.
Why the stack splits
A typical setup looks clean on day one:
- A billing tool or processor invoices usage
- QuickBooks or Xero records the bank feed
- A spreadsheet tracks what the contract actually said
- Someone (often a bookkeeper or fractional CFO) ties it together at month end
Each piece is doing its job. None of them is the system of record for the economic event.
Usage is an event: a quantity, a period, a customer, a price list. The invoice is a consequence. Revenue recognition is another consequence. Cash application is a third. When the ledger only sees the cash, it cannot explain the bill. When billing only sees the meter, it cannot explain recognised revenue. The spreadsheet becomes the real books.
The sequence that has to stay in one place
For usage and compute, financial truth follows one path. Skip a step and you will rebuild it in Excel.
- Meter. Ingest the quantity from the product or infrastructure system — hours, tokens, calls, gigabytes — tied to a customer and a period.
- Rate against the contract. Apply the price that actually governs that customer: included volume, tiers, overages, committed spend, discounts, true-ups.
- Invoice. Turn rated usage into a receivable on a schedule the customer agreed to, not whatever the processor exported.
- Recognise. Post revenue when it is earned. For metered services that is often as consumed; for prepaid or committed usage it may be as the obligation is satisfied. The schedule has to come from the contract, not from when cash landed.
- Settle. Match processor payouts, fees, refunds, and chargebacks back to the invoices they belong to — not to a lump “Stripe revenue” line.
If any of those live in a different system, you will reconcile by hand. That is not a bookkeeping preference. It is architecture.
What “the numbers don’t match” usually means
Founders rarely mean the arithmetic is wrong. They mean three reports disagree:
- Product says we consumed X units
- Billing says we invoiced Y
- The books say we recognised Z, and the bank shows a payout of W a week later
X, Y, Z, and W can all be “correct” in isolation. They are measuring different events. Investor-ready numbers require them to be views of the same state — billed usage, recognised revenue, receivables, and settled cash — not four exports.
That is why adding more close labor does not fix usage billing. A better bookkeeper on top of a split stack still reconstructs the month. The work you want gone is the reconstruction.
If you are starting from scratch
Do not open QuickBooks first because it is familiar. If you already know customers will pay for consumption, compute, or credits, the chart of accounts and the billing model have to be the same system from day one.
Greenfield is not “we will keep it simple until Series A.” It is: set up one ledger that can rate usage against a contract before you outgrow three tools. The expensive path is a clean small-business file that cannot hold commitments, overages, or processor settlement — then a cleanup right as you are raising.
Qualify the decision the same way either way. If you cannot name usage, compute, or commitments as how you make money, a generic accounting tool may be enough. If you can name them, the stack you pick on day one is the stack you will still be reconciling two years later — or replacing.
What to demand from the system
You do not need another invoicing UI. You need books, bills, and investor-ready numbers from the same maintained state:
- Contracts and price lists that govern rating, not a separate “billing truth”
- Usage events that become rated charges, then invoices, then revenue, then cash application
- Processor settlement that explains fees and timing instead of hiding them in miscellaneous expense
- Reports you can show a board without a side model
Lucius is built as that system: contract-to-cash on a stateful ledger, so consumption, invoices, recognition, and settlement stay aligned as the business runs — not reconstructed at close.
If you are still stitching a billing tool to QuickBooks and a contractor, the question is not which bookkeeper is cheaper. It is whether usage and compute will ever fit a seat-based close.