Who it's for: SaaS finance teams whose customers pay for usage (API calls, seats used, transactions, storage) or overages above an included allowance.
What you'll get: how usage revenue is typically recognised, a month-end routine for getting usage data in time, three worked examples with journals (an overage accrual, prepaid credits with breakage, and a true-up), and a risks and controls table.
Reading time: about 11 minutes. Find out now when your usage data actually lands.
Why usage billing makes month-end harder
With a fixed subscription, you know the month's revenue before the month starts. With usage billing, you don't know it until the meter has been read, and the meter often lives in a product database that finance can't see. Many usage invoices go out days after month-end, so revenue for the month has to be accrued from data that may still be moving. Get the timing wrong and revenue lands a month late; get the data wrong and it's simply wrong.
Key terms
- Usage-based billing: charging customers for what they use, such as per API call, per transaction or per gigabyte.
- Overage: usage above an allowance included in a fixed fee, charged at a set rate.
- Billing in arrears: invoicing after the usage has happened, usually early the following month.
- Accrued income (contract asset): revenue earned but not yet invoiced. Usage billed in arrears sits here at month-end.
- Prepaid credits: an amount paid upfront that the customer draws down as they use the service.
- Breakage: prepaid credits the customer is expected never to use.
- Variable consideration: any part of the price that depends on future events, such as usage.
- True-up: the adjustment when the final figure differs from the estimate.
How usage revenue is typically recognised
Under IFRS 15, and the revised FRS 102 Section 23 for periods beginning on or after 1 January 2026 (as at October 2026), usage fees are a form of variable consideration. For most SaaS usage, the answer is straightforward: revenue is recognised in the month the usage happens, at the contract rate. Two features of the standards support this:
- Usage relates to a specific month. When a variable fee relates only to the service delivered in a particular period, it can be allocated to that period rather than estimated and spread over the whole contract.
- Right to invoice. Where the amount you can bill matches the value delivered to the customer to date (for example, a fixed rate per call), revenue can be recognised at the amount you have the right to invoice.
Cases that need more thought: tiered pricing where the rate changes once annual usage passes a threshold, volume rebates, minimum commitments, and prepaid credits. These are covered below.
| Pricing model | Typical treatment | Where AI helps |
|---|---|---|
| Pure pay-as-you-go, billed in arrears | Revenue in the month of usage; accrued income until invoiced | Matching usage export to invoices |
| Fixed fee plus overage | Fixed fee spread as normal; overage in the month it happens | Flagging customers over their allowance |
| Prepaid credits | Deferred revenue on payment; released as used, with breakage estimated | Tracking burn rate per customer |
| Annual minimum commitment | Minimum recognised over the term; usage above the minimum as it occurs | Forecasting which customers will exceed the minimum |
| Tiered annual pricing or rebates | May need an expected average rate across the year | Projecting full-year usage per customer |
One rule for all of it: AI drafts, matches and flags; a person reviews and signs off. Only use AI tools your company has approved for customer and financial data.
The month-end routine
| When | Task | What "done" looks like | |
|---|---|---|---|
| ☐ | Day -3 | Confirm when the usage export will be ready and who sends it | Named owner in product or engineering, with a time on Day 1 |
| ☐ | Day -1 | Check for pricing changes, new contracts and allowance changes in the month | Rate card and allowance list up to date |
| ☐ | Day 1 | Get the usage report for the month, by customer | Report covers the full month, midnight to midnight, in the agreed time zone |
| ☐ | Day 1 | Check the report is complete | Customer count agrees to active customers; total usage within expected range of last month |
| ☐ | Day 1–2 | Price the usage | Usage × rate, less allowances, per customer |
| ☐ | Day 2 | Post the usage accrual (if not invoiced by month-end) | Dr accrued income, Cr usage revenue, with the priced report attached |
| ☐ | Day 2 | Release prepaid credits used and any breakage | Credit balances per customer agree to the product's credit ledger |
| ☐ | Next month | Clear last month's accrual against the actual invoices | Accrued income for the prior month cleared to zero; true-up booked |
| ☐ | Monthly | Track estimate vs actual | True-ups trended; anything over your threshold investigated |
AI shortcut: give an approved AI tool the usage export, the rate card and each customer's allowance, and ask it to price the month by customer, list anyone over their allowance, and flag customers whose usage moved more than 30% from last month. The flags are your review list; check the pricing for the top ten customers by value by hand.
Worked example 1: overage accrual
MonthEndClub Co Ltd (fictional) sells Damson Retail a plan at £1,000 a month, billed monthly in advance, which includes 100,000 API calls. Calls above that are charged at £0.02 each, billed in arrears on the 5th of the following month. VAT is at 20% (the UK standard rate as at October 2026).
In October, Damson makes 160,000 calls. Overage: (160,000 − 100,000) × £0.02 = £1,200.
31 October: accrue the overage. The usage happened in October, so the revenue belongs in October.
| Account | Dr | Cr |
|---|---|---|
| Accrued income | £1,200 | |
| Usage revenue | £1,200 |
No VAT on the accrual. For a continuous supply of services, the tax point is typically the earlier of the invoice date and the payment date, so the VAT is accounted for when the November invoice is raised.
5 November: invoice the overage.
| Account | Dr | Cr |
|---|---|---|
| Trade debtors | £1,440 | |
| Accrued income | £1,200 | |
| VAT output tax | £240 |
October revenue for Damson: £1,000 subscription + £1,200 usage = £2,200. Accrued income is cleared when the invoice is raised, so nothing is double-counted.
Worked example 2: prepaid credits with breakage
On 1 October, Elm Logistics prepays £12,000 (plus VAT) for 600,000 credits, valid for 12 months. Unused credits expire with no refund. That's £0.02 per credit.
MonthEndClub Co Ltd has several years of data on similar customers showing that, on average, about 10% of credits expire unused. It concludes it's highly probable Elm will use around 540,000 credits, and that recognising breakage on that basis won't lead to a significant reversal later. So instead of £0.02 per credit used, revenue is recognised at:
£12,000 ÷ 540,000 expected credits = £0.022222 per credit used.
1 October: payment received.
| Account | Dr | Cr |
|---|---|---|
| Bank | £14,400 | |
| Deferred revenue | £12,000 | |
| VAT output tax | £2,400 |
31 October: Elm uses 40,000 credits. Revenue = 40,000 × £12,000 ÷ 540,000 = £888.89.
| Account | Dr | Cr |
|---|---|---|
| Deferred revenue | £888.89 | |
| Usage revenue | £888.89 |
| Check at 31 October | Value |
|---|---|
| Credits used | 40,000 |
| Credits remaining (600,000 − 40,000) | 560,000 |
| Deferred revenue remaining (£12,000 − £888.89) | £11,111.11 |
| Revenue at face value would have been (40,000 × £0.02) | £800.00 |
The extra £88.89 is October's share of expected breakage. If MonthEndClub Co Ltd had no reliable history, the cautious approach is to recognise at face value (£0.02 per credit) and release any unused balance when the credits expire. The breakage estimate is reviewed each month and updated if Elm's usage pattern changes.
Worked example 3: the true-up
For a smaller customer, Fir Media, the usage export wasn't final on Day 2. Finance accrued £3,000 of October usage from the product dashboard. The final invoice on 5 November came to £3,150 because of late-arriving usage events.
5 November: invoice, clearing the accrual.
| Account | Dr | Cr |
|---|---|---|
| Trade debtors | £3,780 | |
| Accrued income | £3,000 | |
| Usage revenue (November true-up) | £150 | |
| VAT output tax | £630 |
Check: £3,000 + £150 + £630 = £3,780, and £3,150 × 20% = £630. The £150 lands in November as a change in estimate. Small, regular true-ups are normal. A pattern of large ones suggests the accrual method or the data cut-off needs fixing, not that someone made a one-off error.
Getting the data right
The accounting for usage is usually simpler than the data behind it. Points worth agreeing with the product and engineering teams:
- Cut-off time and time zone. Midnight UK time and midnight UTC are the same for half the year and an hour apart for the other half. Pick one and write it down.
- Late-arriving events. How long after month-end can usage events still arrive? That sets how long the accrual stays an estimate.
- Test and internal accounts. Excluded from billing and from revenue.
- Free usage and credits. Promotional credits and service credits reduce the bill; know how the product records them.
- One source of truth. The billing system's rated usage and the product's raw usage are agreed monthly, so finance isn't choosing between two numbers on Day 2.
If you report under US GAAP (ASC 606)
ASC 606 treats usage fees in much the same way, including allocating variable fees to the period they relate to, the right-to-invoice approach, and breakage on prepaid amounts using the same "don't recognise it unless a big reversal is unlikely" test. In practice the outcomes for SaaS usage are usually the same. US companies selling usage-based services often also need to think about state sales tax rules, which vary by state and are outside the scope of this guide.
Common mistakes and audit watch-outs
- Recognising usage when invoiced, not when used. Usage billed in arrears belongs in the month it happened. Without an accrual, revenue is a month late every month.
- Charging VAT on the accrual. The accrual is net. VAT follows the invoice or payment.
- Accrual never cleared. If the invoice posts to revenue instead of clearing accrued income, usage is counted twice.
- Aggressive breakage. Breakage needs reliable history. Without it, recognise at face value until the credits expire.
- Unreconciled usage data. Auditors will want to see that the usage report is complete and agrees to the billing system. A screenshot of a dashboard isn't evidence.
- Accepting AI-priced usage without testing. AI can apply the wrong rate tier or miss an allowance. Reprice a sample by hand each month, starting with the largest customers.
Tools that can help
Billing platforms such as Stripe Billing and Chargebee can meter and rate usage, apply allowances and produce usage invoices automatically. NetSuite can hold usage-based revenue arrangements for larger teams. Teams on Xero or QuickBooks often price the usage export in Excel or Google Sheets and post one accrual journal. An approved AI assistant can price usage, flag swings and draft the accrual. None of these replace an agreed data cut-off and a monthly reconciliation.
Key risks and controls
| Risk | Control | How to evidence it |
|---|---|---|
| Usage revenue in the wrong month | Monthly usage accrual from the priced usage report | Accrual journal with priced report attached |
| Incomplete usage data | Completeness check: customer count and total usage vs prior month | Signed checklist with counts and variance |
| Wrong rates or allowances | Rate card reviewed monthly; sample repriced by hand | Repricing working for the sample, initialled |
| Double counting | Prior month accrued income cleared to nil | Accrued income reconciliation by month |
| Breakage overstated | Breakage rate based on documented history; reviewed quarterly | Breakage analysis and approval |
| AI pricing errors or data exposure | Approved AI tools only; reviewer checks flagged items and top customers | Reviewer notes on AI output |
Rates, thresholds and rules in this guide
Figures were checked against the pages below in October 2026. They change regularly (often each April or at Budget time), and we can't guarantee they're still current or right for your situation. Always check the official page before relying on them.
- FRS 102 Explainer: a summary of the Periodic Review 2024 changes (Financial Reporting Council): effective date of the revised FRS 102 Section 23 revenue model
- VAT rates (GOV.UK): UK standard VAT rate of 20%
- VATTOS9155: continuous supplies of services (HMRC internal manual): VAT tax point for continuous supplies (earlier of invoice and payment)
Key takeaways
- Usage revenue typically belongs in the month the usage happened, not the month it's invoiced.
- Accrue usage billed in arrears; clear the accrual when the invoice goes out.
- VAT follows the invoice or payment, not the accrual.
- Prepaid credits sit in deferred revenue and are released as used; breakage only with reliable history.
- Agree data cut-off, time zone and late-event rules with the product team.
- Let AI price and flag; a person tests the pricing and signs off the accrual.
FAQs
Can we just recognise usage revenue when we invoice it?
If invoices go out after month-end, that puts revenue in the wrong month. Many teams accept this only where the amounts are immaterial and the policy is documented; otherwise an accrual is the usual approach.
What if the usage data arrives too late for our close?
A common approach is to accrue from the best available data, such as a dashboard or a partial export, and true up next month. Tracking the true-ups shows whether the estimate is good enough.
How do minimum commitments work?
The committed minimum is usually recognised over the period it covers, and usage above the minimum is recognised as it happens. If the customer is expected to fall short of the minimum and won't get a refund, the shortfall is also part of the price for the period.
Can AI work out our usage accrual?
Yes, given the usage export, rate card and allowances, AI can price usage by customer and draft the journal quickly. A person checks the data is complete, reprices a sample and approves the journal, using only AI tools your company has approved.
Related guides
- SaaS Revenue Recognition in Plain English (IFRS 15 / ASC 606)
- Reconciling Your Billing System to the Ledger
- Accruals and Prepayments: A Practical Guide with Examples
- ARR vs MRR vs Revenue: Why They Don't Match and How to Reconcile Them
More in Revenue guides.
From the Club
Unlimited usage. No overage charges. The Team Mug · The Triple Tick Bag
Join the Club. New guides, early access and members-only batches. Join here.
This guide is general information about common practice. It isn't tailored to any business, and standards, tax rules and figures change. Check your own circumstances, the latest rules and, where needed, a qualified professional before acting.
Last reviewed: October 2026.