How do you keep prepaid credits and the general ledger tied?

Track the obligation (credits remaining or minimum not yet fulfilled), usage against it, invoices (prepay, draw, true-up), and cash as one trail. Deferred revenue should move when the obligation is satisfied, not when a journal is reclassed at close. If remaining credits live only in billing, the GL will always lag.

What is a revenue or billing subledger?

Operational balances for commitments, usage, invoices, and cash that the general ledger can trust. It is not a second GL and not another invoicing tool. Finance teams need it when they sell prepaid credits, usage minimums, drawdowns, or customer balances.

Why do Stripe Revenue Recognition and billing exports break for commitments?

Those tools assume the invoice line is the economic event. Commitments create an obligation first. Usage, true-ups, and processor payouts happen on different days. Without shared state, remaining credits, deferred revenue, AR, and cash will not match.

Does Lucius replace the general ledger for commitment billing?

Lucius is a financial system of record: contracts, rated usage, invoices, recognition, settlement, and reporting stay connected. For teams that already have a GL, the job is so obligations do not live only in billing. It is not AI bookkeeping and not a first-ledger setup for a simple services business.

How do you keep prepaid credits, commitments, and the GL tied?

If you sell financial commitments, the general ledger is not the hard part. Prepaid credits, usage minimums, drawdowns, wallets, revenue share, and customer balances create obligations that live upstream of the GL. Billing knows the remaining credit. The product knows consumption. The books see invoices and cash — often days later, and often as a lump.

Heads of finance and controllers are not looking for another close tool or another invoicing product. They already have a GL. They need commitments, usage, invoices, and cash to stay tied so the monthly close is a check, not a reconstruction.

What “we sell commitments” actually means

It is not generic SaaS seats. It is any model where the customer pays for a right to consume later, or commits to a minimum, or holds a balance you must track:

Prepaid credits drawn down against usage
Minimum commitments with true-ups and overages
Wallets or stored value that is not yet revenue
Customer funds or balances that must stay distinct from operating cash
Revenue share or partner take-rates that depend on volume after the fact

The commercial event is the obligation. The invoice may be a prepayment, a drawdown, a true-up, or a mix. Revenue is earned as the obligation is satisfied. Cash may hit a processor, a wallet, or an FBO-style account on a different day.

If those objects only exist in the billing system, the GL will always be a lagging interpretation.

Why Stripe Revenue Recognition and billing exports break here

Processor revenue tools and billing-to-ERP connectors work when the invoice line is the economic event. Commitments break that assumption.

Typical failure:

Billing shows remaining credits; the GL shows deferred revenue that does not match the same units
A true-up invoices in month two for usage in month one; recognition and AR aging disagree
Payouts net fees and refunds; the GL cannot tie cash to the invoices that created the obligation
A customer draws a wallet in product; finance learns about it from a CSV

Controllers then search for usage-based revenue recognition, billing-to-GL reconciliation, and alternatives to stitching Chargebee, a billing engine, and NetSuite by hand. The category language is a revenue or billing subledger: operational balances that the GL can trust, not a second set of books that never lands.

What has to stay tied

Four things, same customer, same period:

Obligation. What the customer is entitled to or committed to — credits remaining, minimum not yet fulfilled, balance held.
Usage. What was consumed against that obligation in the period.
Invoice. What was billed: prepay, draw, overage, true-up.
Cash. What settled, net of fees, refunds, and timing.

Revenue recognition is the schedule that turns (1) and (2) into earned revenue without pretending (4) is the earning event. Deferred revenue should move when the obligation is satisfied, not when someone reclasses a journal at close.

If finance cannot produce those four from one maintained state, the close is a negotiation between systems.

What this is not

It is not replacing the bookkeeper with “AI bookkeeping.” It is not a first-ledger setup for a founder who has not chosen a revenue model. It is not another full GL for a company that already runs one.

It is also not a claim that every wallet, FBO, and credit-grant ledger is a solved product category. The requirement is narrower and more honest: contracts, rated usage, invoices, recognition schedules, and settlement have to share state so obligations do not live only in billing.

How to evaluate a system

Ask to see, for one customer who prepaid or committed:

Opening obligation, usage in the period, invoices issued, cash applied, revenue recognised — as one trail
What happens to deferred revenue when usage posts, not when a spreadsheet is uploaded
How processor fees and refunds hit the same invoices, not a clearing account that never clears
Whether a true-up is a first-class event against the contract or a manual journal

If the demo is categorisation, receipt capture, or a prettier close checklist, you are in the wrong product. If the demo cannot start from a commitment and end at a balanced explanation of AR, deferred revenue, and cash, you will still own the tie-out.

Lucius is built as a financial system of record where contracts, invoices, payments, settlements, and reporting stay connected — including usage rated against contract terms and recognition that follows that state. For finance teams whose daily pain is billing that will not tie to the GL, that is the job. Not another general ledger. Not another invoicing tool. Obligations, usage, invoices, and cash in one place.