On the fourth working day of the close, the revenue accountant is still rebuilding schedules. A multi-year deal signed in the last week of the quarter has a platform fee, implementation services and a usage tier, all on one invoice. The spreadsheet recognizes the invoice total evenly over 12 months. The auditor asks how the price was allocated across the three, and the answer is a formula someone wrote two years ago.
Revenue recognition is the last stage of order-to-cash, and it inherits every stage before it. It can only be as accurate as the contract data that reaches it. In most companies, that data arrives late, by export, and shaped like an invoice.
What is revenue recognition automation?
Revenue recognition automation builds revenue schedules from contract data instead of by hand. Under ASC 606 and IFRS 15, revenue is recognized as each promise in a contract is delivered. That means identifying the separate performance obligations in a contract, allocating the price across them using standalone selling prices, and recognizing each one on its own pattern: over the term, at a point in time, or as usage happens. Automation carries the contract data into the system that does this, and records the inputs behind every figure.
Where it breaks
- Schedules start from the invoice. An invoice is a billing event, and a performance obligation is an accounting one. An annual invoice for software and services doesn’t say how either should be recognized.
- Contract data arrives by export. Sales closes the quarter in the CRM. Revenue accounting gets a spreadsheet days later, and the close waits for it.
- Allocation lives in a spreadsheet. The standalone selling prices, the version of the price table and the arithmetic sit in formulas, so every audit reconstructs them.
- Modifications are adjusted by hand. A mid-term upgrade changes the contract. Instead of a new allocation, someone edits the existing schedule, and the result can’t be traced.
- Bookings, billings and revenue don’t reconcile. Each is reported from a different system, and the differences are plugged at period end instead of explained.
What it costs
The first cost is time in the close. Days spent rebuilding schedules are days not spent reviewing them.
The second is audit risk. A figure nobody can trace to its inputs becomes an audit finding, and an allocation error found later can mean restating revenue.
The third is the number itself. Deferred revenue is one of the figures boards and investors watch. When it’s assembled by hand, finance spends the board meeting explaining how the number was built instead of what it means.
What to fix first
- Start from the contract. Send contract lines from the CRM or CPQ to the revenue system as soon as the deal is signed, with the contract ID on every line.
- Map products to obligations once. Give each product or service an obligation type and a recognition pattern, so the mapping is data and nobody repeats the judgment every quarter.
- Keep standalone selling prices in a maintained table. Version it, and record which version each allocation used.
- Generate one schedule per obligation. A contract with software, services and usage gets three schedules, each with its own dates.
- Treat a modification as a new allocation. Apply the treatment the standard requires, and record why.
- Reconcile bookings to billings to revenue every period. Explain each difference, so every dollar of deferred revenue has a reason.
Your revenue accounting team and auditors decide how each obligation is treated. The integration carries those decisions to every contract and records what it did. The guides to building a revenue recognition feed and financial close automation have the prompts.
Where the manual queue starts
At Mixpanel, finance used to reconcile every closed-won contract between the CRM and the ERP by hand, and revenue recognition waited on that queue. After the team automated the handoff, it reviews incoming orders and adjusts the exceptions, and manual effort per sales order fell by 25%.
Where revenue recognition fits
Revenue recognition depends on the start of the process more than the end. If quote to order books an order that differs from the signed contract, the schedule starts wrong. If provisioning changes what the customer has without an amendment, the contract and what was delivered no longer match.
For all eight stages, see the order-to-cash process.