Use case
Usage billed. Revenue recognised. These are not the same event.
Definition
Usage-based revenue recognition is the process of earning consumption revenue when the performance happens, under ASC 606 / IFRS 15, even when invoicing, prepayment, and true-ups sit on a different clock. The contract is the source of both the invoice schedule and the recognition schedule. Prepayments sit in deferred revenue until earned; amendments post catch-up entries; billed, earned, and deferred stay columns that tie.
Map usage to recognition
Send one contract with usage plus a prepayment. We'll show billed vs earned vs remaining deferred.
The problem
- Billing invoices what the contract allows this period. Recognition should follow what was delivered. Those calendars are not the same.
- Annual prepayments, unused commitments, and mid-month usage force a schedule that spreadsheets cannot keep current.
- Upgrades, true-ups, and credits create catch-up entries that the GL never quite matches to billing.
How Lucius solves it
- The contract is the source of both the invoice schedule and the recognition schedule.
- Usage events recognise when consumption occurs. Prepayments sit in deferred revenue until they are earned.
- Amendments and true-ups update the schedule and post catch-up entries. History is append-only.
Workflow
- 1
Model the obligation
What did the customer actually buy: capacity, consumption, a minimum, a hybrid?
- 2
Invoice on commercial terms
Bill the minimum, the overage, or the prepayment as the contract states.
- 3
Recognise on delivery
Usage recognises as it is consumed; time-based elements recognise over the term.
- 4
True-up without breaking the trail
Catch-up entries reference the original schedule.
- 5
Report billed, earned, and deferred as columns that tie
Three numbers from one state — not three systems.
Example data flow
| From | To | What happens |
|---|---|---|
| Contract | Invoice schedule + recognition schedule | Two clocks, one source. |
| Usage event | Recognised revenue | Delivery earns revenue even if the invoice is later. |
| Prepayment | Deferred revenue | Cash in is not earnings. |
| True-up / amendment | Catch-up posting | The schedule updates; prior entries are not silently edited. |
Frequently asked questions
Can Lucius recognise usage under ASC 606?
Yes. Performance obligations and recognition over time or as consumed are derived from contract terms and posted to the stateful ledger. Usage billed and revenue recognised are kept as distinct events, even when they happen on the same day, so a later dispute or credit does not scramble the P&L.
What if we invoice in arrears?
Then AR and recognised revenue may move together. Lucius still keeps the invoice and the delivery event distinct. That matters when true-ups, credits, or mid-period amendments arrive after the invoice, because catch-up entries can reference the original schedule instead of silently editing history.
What if the customer prepaid for a year of usage?
Cash and deferred revenue post on collection. Recognition follows burns, or time if that is the obligation. Remaining deferred is a report from maintained state, not a reconstruction of a spreadsheet schedule at close.
Is this the same as Stripe Revenue Recognition?
No. Stripe can allocate payments. It is not your contract, your credit grants, and your GL. Lucius keeps billed, earned, and deferred as columns that tie because they come from the same contract-driven state.
Map usage to recognition
Send one contract with usage plus a prepayment. We'll show billed vs earned vs remaining deferred.
Map usage to recognitionOr explore the stateful ledger — Lucius's financial system of record.