Why Your Usage-Based SaaS Is Undercounting Revenue

You've built the usage tracking. Events fire correctly.
Your billing system picks them up. Invoices go out on time.

Everything works.

But your finance team is still reporting the wrong revenue number.

Here's why—and it has nothing to do with bugs in your code.

The Problem: Your Billing Cycle Is Not Your Revenue Cycle

In usage-based SaaS, customers pay for what they use.
But there's almost always a gap between:

• When the usage happens
• When you invoice for it

That gap is where your revenue goes missing.

If a customer uses your API heavily in January but gets
billed on February 1st—your January revenue report
shows $0 for that usage.

But you earned it in January.

This is what accountants call accrued revenue—and
Most engineering and product teams have never heard of it.

What Is Accrued Revenue?

Accrued revenue is the value your business has earned
but not yet invoiced.

Under accrual accounting (ASC 606 / IFRS 15—the standards
Most SaaS companies follow), revenue is recognized when
It's earned, not when cash arrives.

Accrued Revenue = Value Delivered During Period 
                − Amount Billed During Period

Simple example:

{
  "customer": "acme-corp",
  "usage_month": "January 2025",
  "api_calls": 2000,
  "price_per_call": 0.02,
  "value_earned": 40.00,
  "invoice_date": "2025-02-05",
  "accrued_revenue_in_january": 40.00
}

The $40 is real revenue. It belongs to January.
But if your system only counts billed amounts,
It shows up in February—one month late.

Why This Matters Beyond Accounting

This isn't just a finance compliance issue.
As a builder, here's what accrued revenue actually tells you:

1. Real-time adoption signal
Usage spikes in week 3 of the month?
Accrued revenue catches it immediately.
Waiting for invoices means you're always looking backwards.

2. Cash flow prediction
High accrued revenue = big invoices coming next cycle.
Your finance team can plan around that—if the data exists.

3. Investor reporting accuracy
For usage-based models, MRR and ARR are lagging indicators.
Accrued revenue shows what's actually happening right now.

Where It Breaks in Your Stack

Most teams have three systems that don't talk properly:

Usage Collection  →  Billing Platform  →  Accounting/ERP
(Datadog/          (Stripe/Saaslogic/    (NetSuite/
 Snowflake/         Orb)                  QuickBooks)
 CloudWatch)

The common failure points:

Revenue date = Invoice date (wrong)
Your billing system fires an invoice Feb 1st for January usage.
If accounting records revenue on the invoice date,
You're off by up to 30 days every single month.

Always use the usage date as your revenue recognition date.

Usage pipeline latency not accounted for

Raw event → Deduplication → Enrichment → Validation 
→ Billing system → Invoice

Every step adds lag. If your pipeline takes 48 hours,
Your accrued revenue calculation is 48 hours behind.
Document this lag explicitly. Don't pretend it doesn't exist.

No single source of truth for unbilled usage
If your billing platform, data warehouse, and ERP are all
show different numbers for "this month's usage" —
You have a reconciliation nightmare.
Pick one system as authoritative. Sync outward from there.

Booking ≠ Accrued Revenue
A signed contract is not accrued revenue.
Projected usage is not accrued revenue.
Only delivered, measurable value counts.

The Correct Journal Entry Flow

For those connecting usage data to accounting systems:

1. Usage occurs in January
   DEBIT:  Unbilled Receivable (Asset)  $40
   CREDIT: Revenue                      $40

2. Invoice issued February 5th
   DEBIT:  Accounts Receivable          $40
   CREDIT: Unbilled Receivable          $40

3. Payment received
   DEBIT:  Cash                         $40
   CREDIT: Accounts Receivable          $40

Step 1 is what most teams skip entirely.

Accrued vs Deferred Revenue vs MRR

These three get conflated constantly:

Metric	What It Is	When It Applies
Accrued Revenue	Earned, not yet billed	Usage-based / post-pay
Deferred Revenue	Billed, not yet earned	Prepaid / annual plans
MRR	Normalized monthly subscription value	Fixed recurring plans

Most SaaS products today have all three simultaneously.

What Growing Accrued Revenue Signals

Once you start tracking this, here's how to read it:

• Accrued revenue growing QoQ → real usage adoption, not just contract growth
• Accrued revenue > MRR growth → usage motion is outpacing subscription motion
• Accrued revenue flat, MRR growing → expansion is happening through seat upgrades, not usage
• Large accrued balance: consider faster invoice cycles to convert earned value into cash sooner

TL;DR

• Usage-based SaaS has a gap between delivery and billing
• That gap = accrued revenue
• MRR and ARR don't capture it
• It's an asset on your balance sheet (unbilled receivable)
• Your usage pipeline already has the data—surface it
• Connect usage → billing → accounting with usage date, not the invoice date, as the revenue recognition trigger

Full breakdown with tools, ASC 606 details, and real
Examples on the Saaslogic blog:

→ [Accrued Revenue: The Hidden Growth Metric in Usage-Based SaaS]

Building a usage-based billing system or dealing with
Revenue recognition complexity?
Drop your questions in the comments—happy to dig in.