MatrixBy Khaled Hawari

Writing a Service Revenue Recognition Policy Under ASPE

Most service companies do not have a revenue recognition problem. They have an undocumented revenue recognition practice, which becomes a problem the first time somebody outside the company asks what it is.

The question arrives from outside. A practitioner preparing a first review engagement asks how revenue on the implementation contracts is recognised. A lender wants to understand why deferred revenue moved. A buyer’s advisor asks for the deferred revenue schedule during diligence. In each case the company has been recognising revenue in a consistent way for years, and in each case it turns out that the consistency lived in one person’s judgement rather than in a document.

That is the gap this piece closes. What follows is the triage we run over a service company’s contracts, the policy memo the answers go into, and the two schedules that make the policy provable every month rather than defensible once a year.

First, the framework

Everything below assumes ASPE, which is the framework most privately held Canadian companies at this size use. ASPE addresses revenue in Section 3400. If your company reports under IFRS, the applicable standard is IFRS 15, the model is materially different, and the triage below will point you at the right questions but not the right answers.

Two things are worth settling before you write anything. First, confirm in writing which framework your financial statements are prepared under, because it is surprisingly often assumed rather than known. Second, confirm the mechanics of whichever method you land on with the practitioner who reports on your statements. The purpose of the artifacts here is to make your practice explicit and consistent, not to substitute for the professional judgement that sits on top of it.

The five questions we ask about every contract

Run these in week one, over every distinct contract type the company sells. Not every contract; every type. A company with 300 customers usually has four or five contract types and a couple of one-offs.

Question Why it decides something
1. What has the customer actually bought, and is it one thing or several? Determines whether the arrangement has to be separated into components before anything else can be decided
2. Is performance a single act, or a series of acts over time? This is the fork between recognising at a point and recognising as work progresses
3. What is the most faithful measure of progress, and can we actually measure it reliably? If progress cannot be reliably estimated, the answer changes
4. Is the amount fixed or determinable, and is collection reasonably assured? A contract that fails either test does not get recognised on schedule regardless of the answers above
5. Are we principal or agent in this arrangement? Decides gross versus net presentation, which changes reported revenue enormously without changing profit at all

Question 5 catches companies out most often, because it does not feel like an accounting question. A firm that subcontracts a component of its delivery, or resells third party software alongside its own service, has to reach a defensible conclusion on whether it controls that component before deciding whether the third party cost appears as revenue and cost or nets out entirely. Reach the conclusion once, write it down with the reasoning, and revisit it when the arrangement changes.

The contract triage matrix

This is the artifact. One row per contract type, and it lives in the policy memo.

Contract type Performance pattern Recognition basis Measure of progress Evidence maintained monthly Balance sheet position it creates
Fixed monthly retainer, defined scope Continuous over the term Rateably across the term Time elapsed Contract, term dates, billing schedule Deferred revenue if billed in advance
Prepaid block of hours Series of acts, consumed on use On consumption of hours Hours delivered against hours purchased Hours ledger reconciled to the block Deferred revenue until consumed, plus a policy on expiry
Fixed fee implementation project Series of acts over time Proportionate to progress, where progress can be reliably estimated Labour hours or costs incurred against a maintained total estimate Hours to date, current total estimate, and the date the estimate was last revised Deferred revenue where billings run ahead, unbilled revenue where they run behind
Time and materials Series of acts As the hours are delivered Hours approved Approved timesheets Unbilled revenue between the cut off and billing
Single deliverable, one act A single act On performance of that act Not applicable Delivery evidence, signed acceptance where applicable None, if billed on delivery
Setup or onboarding fee attached to a recurring service Depends on whether it has standalone value Settled by analysis, not by convenience As determined The analysis, in the memo Frequently deferred across the service term
Milestone billed project Series of acts Progress, not the billing schedule As above Milestone schedule alongside the progress measure Whatever the difference between the two produces
Reimbursable expenses recharged to a client Follows the underlying service Gross or net, per the principal and agent conclusion Not applicable The conclusion, in the memo None
Contract with a refund or cancellation right Any Constrained by the right As applicable The right, quantified A provision, where a refund is likely

The row that causes the most trouble is milestone billing, because billing schedules are negotiated commercially and progress is a matter of fact. They are not the same thing and the policy has to say so explicitly, in a sentence a non accountant will understand: we bill on the milestone schedule and we recognise on progress, and the difference is deferred revenue or unbilled revenue. Say it once in the memo and it stops being re-litigated every quarter.

The policy memo

Six sections, three to five pages, signed and dated. This is the document that goes to the practitioner, to a lender who asks, and to a buyer’s advisor in diligence.

  1. Scope and framework. The reporting framework, the period from which this policy applies, and which entities it covers.
  2. The contract taxonomy. The matrix above, with an example contract named for each row so the classification is testable.
  3. The recognition conclusion for each type, with the reasoning, not just the answer. Reasoning is what makes the memo survive a change in staff.
  4. Estimates and how they are maintained. For anything recognised on progress: who owns the total estimate, how often it is revisited, what evidence supports a revision, and who approves one.
  5. Judgement calls, settled. Setup fees, expiry of unused prepaid hours, principal versus agent, treatment of a contract modification, treatment of a loss making contract, and the point at which collection ceases to be reasonably assured.
  6. Schedules and controls. The deferred revenue schedule, the unbilled revenue schedule, the monthly tie out, and who reviews each.

Section 4 is the one that gets skipped and the one that causes restatements. An estimate nobody owns drifts, and a drifting estimate on a progress based contract moves revenue silently.

The two schedules

Every month, two schedules and a tie out. Below is a worked extract at the end of month three of a fiscal year. All figures are Canadian dollars.

Four contracts:

  • A, an annual support retainer of 48,000, invoiced in full in advance at the start of month one, recognised rateably at 4,000 per month.
  • B, a fixed fee implementation of 90,000, recognised on progress measured by labour hours, total estimate 600 hours, 210 hours delivered to date. Billed 45,000 on a milestone.
  • C, a single act service of 25,000 delivered and billed in month two.
  • D, a fixed fee project of 60,000, recognised on progress, total estimate 400 hours, 160 hours delivered to date. Billed 15,000 to date.
Contract Contract value Progress Revenue to date Billed to date Deferred revenue Unbilled revenue
A 48,000 3 of 12 months 12,000 48,000 36,000 -
B 90,000 210 of 600 hours, 35% 31,500 45,000 13,500 -
C 25,000 Complete 25,000 25,000 - -
D 60,000 160 of 400 hours, 40% 24,000 15,000 - 9,000
Total 92,500 133,000 49,500 9,000

The tie out is a single arithmetic identity and it is the control that makes the whole policy provable:

Billings to date, less revenue recognised to date, equals deferred revenue less unbilled revenue.

On these figures, 133,000 less 92,500 is 40,500, and 49,500 less 9,000 is 40,500. If those two numbers do not agree, one contract has been billed or recognised outside the schedule and you have found it in the month it happened rather than in fieldwork nine months later.

Present the two balances gross on the balance sheet, deferred revenue in liabilities and unbilled revenue in assets, rather than netting them to 40,500. Netting hides the fact that the company is carrying both, which is information a lender and a buyer both want.

What a change in estimate does, and why it must be visible

This is the mechanic that surprises owners, so put it in the memo with an example.

Take contract B into month four. Fifty further hours are delivered, bringing hours to date to 260. In the same month the project manager revises the total estimate from 600 hours to 720, because the scope turned out to be heavier than assumed.

Under the original estimate, 260 of 600 hours is 43.3 percent and revenue to date would have been 39,000. Under the revised estimate, 260 of 720 hours is 36.1 percent and revenue to date is 32,500. Revenue recognised in month four is therefore 32,500 less the 31,500 already taken, which is 1,000, despite fifty hours of work having been delivered in the month.

That is the correct answer and it is also the answer that produces an uncomfortable conversation, which is exactly why it needs to be written down before it happens rather than explained afterwards. The margin story is the same one told properly: at a fully burdened 85 per hour, a 600 hour estimate implies cost of 51,000 and a margin of 39,000, or 43.3 percent. A 720 hour estimate implies cost of 61,200 and a margin of 28,800, or 32.0 percent. The month four revenue figure is not an accounting oddity. It is the contract telling you its margin fell, in the month it fell.

Two consequences follow, and both belong in the memo. The total estimate must be revisited on a defined cadence by a named owner, because an estimate only revised when it is convenient produces revenue that is only correct when it is convenient. And where a revised estimate shows total expected costs exceeding total contract revenue, the expected loss is a separate question requiring prompt attention, and one to take to your practitioner rather than to resolve internally.

The monthly control

At close, three checks, in this order.

  1. The deferred revenue schedule and the unbilled revenue schedule each agree to their general ledger control accounts, to the dollar.
  2. The identity above holds.
  3. Every progress based contract shows the date its total estimate was last reviewed, and no contract in flight has an estimate older than the agreed cadence.

Check 3 fails more often than the other two, and it is the only one of the three that predicts a future problem rather than reporting a current one.

When the policy has to be reopened

Trigger Why
A new contract type is sold that does not fit a row in the matrix Classification by analogy is how policies quietly become wrong
A material contract is modified A modification can change the unit of account, not only the price
The company begins reselling a third party product or subcontracting delivery Reopens the principal and agent conclusion
A framework change, or a change in the level of assurance on the statements The evidence standard changes even when the policy does not
A pattern of contracts running materially over their estimate The measure of progress may not be faithful, which is a bigger question than any single estimate

What we do not do

We do not let the billing schedule determine the revenue, in either direction. We do not write a policy that describes what the software currently does, because the software should implement the policy rather than define it. We do not settle a principal versus agent question, a multiple deliverable separation or a loss making contract without putting the analysis to the practitioner who reports on the statements. And we do not net deferred and unbilled revenue for presentation, because the gross position is the part that tells the reader something.

MoreOther working documents

If this keeps failing in the same place.

A document that has to be re-explained every period is a process problem rather than a documentation problem. That is the point at which handing the function over is cheaper than fixing it again.