Revenue recognition automation takes the invoices a company has already sent and works out, for accounting purposes, when the revenue on each of those invoices was actually earned — which is very often a different date, or a different amount, than when it was billed.
The core idea behind revenue recognition is simple: a $12,000 annual contract billed in January was not all earned in January. It was earned across the twelve months the service was actually delivered. Recognizing it all up front overstates January and understates every month after. Recognizing it correctly means the revenue line should track delivery, not invoicing.
Billed vs recognised — the distinction that starts every conversation
| What it answers | |
|---|---|
| Billed | What did we invoice the customer, and when? |
| Recognised | How much of that amount counts as revenue in this accounting period? |
These two numbers agree by coincidence on a simple month-to-month subscription billed and delivered in the same period. They diverge constantly on annual prepay contracts, milestone-based services, and anything billed ahead of or behind when the underlying obligation is actually met.
The two patterns that cover most contracts
- Straight-line (ratable) recognition — the amount is spread evenly across the days of the service period. A 12-month subscription billed upfront releases roughly 1/365th of the amount each day (or 1/12th each month) of the term, regardless of when the invoice was sent.
- Point-in-time recognition — the whole amount is recognised on the date a specific obligation is met, not spread out. A one-time setup fee, delivered instantly, generally recognises immediately. A freight shipment recognises on the date the haul actually happened — even if the invoice was raised earlier or later.
A single company frequently needs both: a subscription line recognising straight-line across its term, alongside a one-time implementation fee recognising point-in-time the day it's delivered.
The waterfall and the journal are different outputs
Revenue recognition automation typically produces two related but distinct artifacts:
- A revenue waterfall — a table showing how each invoiced amount releases across future periods. This is the narrative: "this invoice's revenue is spread across these six months, this much per month."
- Journal entries — the actual debits and credits that move revenue from deferred (a liability, since it hasn't been earned yet) to recognised, period by period, the way an accountant needs to see it to close the books.
The waterfall explains the story; the journal is what actually posts. Automation that only produces one of these is giving a finance team half the picture.
What automation should never claim
Revenue recognition automation is not the same thing as an ASC 606 or Ind AS 115 certification. Automating the mechanical work — computing schedules, generating journal entries, tying them back to source invoices — is genuinely valuable and removes a huge amount of manual spreadsheet work. But "this system runs the calculation" and "this system has been certified as compliant with a specific accounting standard" are different claims, and a vendor conflating the two is worth being skeptical of. The honest framing: automation gives you a defensible, source-linked trail. Whether that trail satisfies your specific auditor's read of ASC 606 is a conversation with your accountant, not a checkbox in a settings page.
What to check before trusting revenue recognition automation
- Does it support both straight-line and point-in-time recognition, and can they coexist on lines from the same contract?
- Does every recognised amount trace back to the specific invoice line it came from, or does the journal exist independently of the billing record?
- What happens to recognition when an invoice is corrected or credited after some of it has already been recognised — does the reversal flow proportionally?
- Does the system claim certification, or does it describe itself honestly as a calculation and audit-trail tool?
- Can freight, subscriptions, and one-time fees all recognise correctly on the same journal, or does each pricing shape need separate handling?
Sonic AI generates the waterfall and journal entries directly from invoices already sent — subscription lines recognise straight-line across their period, one-time fees and freight recognise point-in-time on the relevant date, and every journal line traces back to its source invoice. It does not claim ASC 606 or Ind AS 115 certification — it's a defensible trail, not a compliance certificate. See how revenue recognition works, or the deeper mechanics on billed is not recognised and reading the revenue waterfall and journal.
Related terms: billed vs recognised, deferred revenue, revenue waterfall, straight-line recognition, point-in-time recognition.