How to make usage-based revenue auditable: the reconciliation finance needs

To manage revenue recognition for usage-based billing, split the work in two. Your billing system meters usage, rates it and issues invoices with a trail back to each event. Finance applies its recognition policy in the ERP or a revenue tool. What makes the result auditable is the reconciliation between those two systems.

If you need the standard itself, start with our IFRS 15 explainer for tech billing. This post covers the operating side: the records, the bridge and the checks that let finance defend a usage-based number.

This article describes operating practice, not accounting advice. Your recognition policy belongs to your finance team and auditors.

How do I manage revenue recognition for usage-based billing?

Start by naming the seam: the logic that connects what you sold to what you charge to what you recognize. Quote, usage, invoice, revenue recognition, general ledger. Each step usually lives in a different system, and someone has to own the handoffs. With usage, credits and commitments, the seam changes every time pricing does.

In our whitepaper, The Rise of the Finance Systems Engineer, we describe this as a transition in three stages. Finance 1.0 ran on spreadsheets and manual journals. Finance 2.0 moved to ERPs and closed vendor modules. Finance 3.0 is where finance systems become programmable and inspectable.

The accounting principle is stable. Under IFRS 15, an entity recognizes revenue to depict the transfer of promised goods or services, in the amount it expects to be entitled to (IFRS Foundation). When the promised consideration includes a variable amount, such as usage fees, the entity estimates it. How your contracts map to that principle is a judgment for finance.

What the billing system owes finance is a clean separation of five numbers that people often blur:

• Bookings: what the customer committed to in the contract.
• Billings: what you invoiced in the period.
• Cash: what you collected.
• Revenue: what you earned under your recognition policy.
• Deferred revenue: what you billed or collected but haven't earned yet, such as unused prepaid credits.

All five can move in different directions in the same month. Reconciliation explains each movement.

What makes usage-based billing auditable for finance teams?

Ask the question an auditor would: what evidence would make me trust this usage-based revenue number? The answer is a chain that runs from usage to invoice to payment to revenue to the general ledger, where every link can be reproduced from records rather than from one person's spreadsheet.

That chain starts with a durable usage event. Each billable event should carry:

• a stable, unique identifier;
• the customer or subscription it belongs to;
• the time the usage happened, not the time it arrived;
• the product, feature or model used;
• the unit and the quantity.

From there the trace runs through five steps. The event records what happened. The meter turns valid, deduplicated events into quantities. Rating applies the price version and the customer's terms. Funding applies grants, prepaid credits or commitments. Settlement produces the invoice, the payment and any correction.

Two rules keep that trace honest. A retry must never create a second charge. A price change or a correction must change the financial result without rewriting what was observed.

In Lago, events carry a required transaction_id that Lago uses for deduplication, so a re-sent event is billed once, even across delivery methods. Lago assigns events to billing periods by their timestamp, not their arrival time. An event that arrives after an invoice was finalized is not added to that invoice, so late usage is a reconciliation item to track. Correction rules depend on the event store, and the usage ingestion guide documents both late events and corrections.

Corrections after invoicing work the same way. Credit notes in Lago are issued against specific fees on a finalized invoice and carry a reason such as duplicated charge or order change. Manually creating credit notes requires a premium license. Premium plans also include activity logs that record who changed what and when, with longer history available as an enterprise add-on.

How do I reconcile raw usage events with a customer invoice?

Use a five-quantity bridge. Finance needs more than the invoice total. It needs to reconcile completed product activity, billable units, rated charges, invoiced amount and collected cash. Each step can have a valid difference. What makes the bridge auditable is that every difference has a reason code, an owner and a path to correction.

Run the bridge monthly on one customer first, then across the book, starting with the largest unexplained difference. Activity above billable units points to instrumentation or policy. Rated charges above invoices point to credits, discounts or write-offs. Invoices above cash point to payment failures or collections.

This is an operating bridge, not an accounting policy. It shows finance that the inputs to recognition are complete and explained. Finance still applies its own recognition and tax treatment.

The bridge only works if invoice lines are granular enough to trace. In Lago, each invoice line is a fee. Usage-based fees are tied to the charge and billable metric that produced them and carry their units and amount, so you can walk a line back to the events behind it. For multi-entity businesses, keep the seller, currency, tax treatment and payment account attached to each invoice so the bridge can be cut by entity.

How should prepaid credit expiry and rollover work in a billing system?

Prepaid credits add a second ledger inside billing. It needs to answer five questions without manual work:

1. Was this credit purchased or granted for free?
2. When was payment for purchased credits confirmed?
3. In what order are credits consumed when several balances exist?
4. What happens to unused credits at the end of a period or at expiry?
5. Which top-up funded which usage?

Decide each answer before you launch the offer, because each one has an accounting consequence. Purchased credits are generally held as a liability until the customer uses them. For unused prepaid rights, often called breakage, the guidance depends on whether you expect to be entitled to that amount. If you do, the expected breakage is recognized in proportion to the customer's pattern of use. If you don't, it is recognized when the chance of the customer using the remaining rights becomes remote (Deloitte Roadmap, ASC 606-10-55-46 to 55-49, which parallels IFRS 15 B44 to B47). Your billing system has to produce the data that judgment needs.

On the ledger side, Lago wallets separate paid credits from granted credits. Granted credits are added right away, and purchased credits are added once payment is confirmed. Wallet priority sets the order of consumption, with the soonest-expiring wallet applied first when priorities tie. Without an expiration date, credits roll over until the balance reaches zero. With one, Lago automatically voids the remaining credits on that date, which gives finance a dated record of what expired. On traceable wallets, you can see which top-ups funded each deduction and how each top-up was consumed. The premium real-time ongoing balance estimates consumption against current usage.

Partial burn needs the same discipline. If a customer uses part of a prepaid block before it expires, finance should see the consumed part as usage and the rest as a separate, dated expiry, not one net adjustment.

Is dedicated billing software or ERP integration better for managing complex usage-based billing at enterprise scale?

Both, with different jobs. The ERP is the accounting system of record: general ledger, journal entries, consolidation and close. A dedicated billing system handles event volume, metering, versioned pricing, credits, commitments and invoicing. What matters is how cleanly the handoff works.

A good integration moves finished financial documents, not raw events. In Lago, the NetSuite integration is a premium add-on that creates invoices, credit memos and customer payments in NetSuite as Lago finalizes them, and syncs catalog objects for mapping. The Xero integration, also a premium add-on, syncs billing data to Xero. Lago Data Pipeline, a premium feature on request, syncs billing objects to a warehouse so finance can run the bridge in SQL.

Lago also offers revenue recognition as an alpha premium add-on, released gradually. It can turn billing data into draft accrual-basis revenue reports with traceability to the underlying billing records. Because it is alpha, reconcile its output against your general ledger before using it for a statutory close.

The audit-readiness checklist

Use this before your next close or audit.

Events and usage

• ☐ Every billable event has a stable, unique ID, and retries cannot create a second charge.
• ☐ Events carry the time the usage happened, and late events are tracked as a reconciliation item.
• ☐ Missing usage can be detected by comparing product logs with billable units.

Pricing and invoices

• ☐ Any invoice line can be reproduced after a price or contract term changes.
• ☐ Negotiated terms exist as dated configuration, not only as manual invoice adjustments.
• ☐ Every credit note, discount and void carries a reason and links to the original document.

Credits

• ☐ Purchased, granted, consumed, expired and voided credits are separate, dated records.
• ☐ Expiry and rollover rules are written down and match what customers were sold.

Reconciliation and close

• ☐ The five-quantity bridge runs every month, with a reason code and owner for each difference.
• ☐ Invoices, credit notes and payments reach the ERP without re-keying.
• ☐ You track business days to close, billing exception backlog and aging, usage-to-invoice and invoice-to-payment reconciliation accuracy, and manual journal entries caused by system gaps.

Who owns the reconciliation

A common reason teams fail this checklist is that nobody owns the seam. Finance owns policy, engineering owns the product, and the bridge sits in a spreadsheet. One answer is to give it to a Finance Systems Engineer: a technical operator who sits with finance and makes revenue systems reliable, auditable and fast to change.

The Finance Systems Engineer hiring handbook covers a weighted hiring scorecard, an AI literacy ladder, a four-step interview loop with a 30-day work sample, and a 90-day plan for the first hire.

Download the Finance Systems Engineer hiring handbook

Want to see the usage-to-invoice trail on your own data? Book a demo.