Businesses that deliver over a period, consultancies, agencies, construction firms, software implementers, managed service providers, share a set of revenue recognition mistakes. The mistakes are consistent enough to be worth listing, and most of them come from one underlying error: treating the invoice as the event.
The question to ask first
Before anything else, establish whether your revenue is earned over time or at a point in time. It determines everything that follows and it is a conclusion you should be able to evidence, not an assumption inherited from how the business has always posted things.
Broadly, revenue is recognised over time where the customer receives and consumes the benefit as you perform, where your work creates or enhances an asset the customer controls as it is created, or where what you produce has no alternative use to you and you have an enforceable right to payment for work completed to date.
That last limb is the one most often missed and it does real work. If a customer can walk away mid-contract and owes you nothing for the work already done, you may not have an over-time arrangement at all, whatever the commercial expectation is. The answer sits in the termination clause, which means someone has to read the contract.
Measuring progress
Having concluded you recognise over time, you need a method for how much.
Input methods measure your effort: hours incurred against hours expected, costs incurred against total expected costs. They are easy to operate because the data already exists in your timesheets and ledger. Their weakness is that effort and value can diverge, and they flatter an inefficient project, since going over budget mechanically recognises more revenue.
Output methods measure what the customer has received: milestones achieved, units delivered, surveys of work performed. They are more faithful and usually harder to evidence.
Either is acceptable, but pick one per performance obligation, justify it, and apply it consistently. Switching method between periods, or using whichever gives the preferable answer on a given contract, is exactly what an auditor is looking for.
Two refinements that catch people. Uninstalled materials sitting on site are not progress, and including their cost in an input measure overstates revenue. And where you have given the customer a discount or variable consideration, the transaction price you are spreading must reflect it.
Separating the obligations
A contract that bundles implementation, a licence, training and ongoing support is not one performance obligation because it is one invoice. Each distinct promise is accounted for separately, with the transaction price allocated between them, and they may be recognised on entirely different patterns.
This is where multi-element contracts go wrong. Implementation might be over time, a licence at a point in time, support ratably across the term. Treating the whole thing as a single monthly recognition is simpler and frequently wrong, and the error compounds across every contract on the same template.
The practical defence is to look at the contract templates rather than the individual contracts. Get the treatment right once per template and the population follows.
The usual findings
A few patterns recur often enough to check for directly.
Revenue recognised to the invoice rather than to performance, with no contract asset or deferred income to bridge the gap.
Deferred income understated because annual fees billed up front were taken to revenue on receipt.
Expected losses on bad contracts spread forwards instead of recognised immediately.
Contract modifications, scope changes and variations accounted for as though the original contract still governed, when a modification may need treating as a separate contract or as a change to the existing one depending on what was agreed.
No contract register, so nobody can demonstrate that the policy was applied across the population rather than to the three contracts the auditor sampled.
What to have ready
A contract register listing each live contract, its value, its performance obligations, the recognition method and the stage reached. A written policy explaining the method and why it faithfully depicts transfer. The templates, with the termination and payment clauses flagged. And a reconciliation from revenue recognised to amounts invoiced, with the difference analysed into contract assets and deferred income.
Prepare that and the revenue section of your audit becomes a review. Leave it, and it becomes the part that overruns, because the auditor has to reconstruct from contracts what you could have summarised in a table.