Building the Deferred Revenue Schedule That Drives the Journal

There are two ways a deferred revenue balance comes to exist, and only one of them can be proved.

In the first, a schedule holds every contract, each contract releases on a pattern that was decided when it was signed, and the sum of this month’s releases is posted as the journal. The ledger balance is the schedule’s output. In the second, somebody looks at the ledger at month end, forms a view of what deferred revenue ought to be, and posts the difference. The second is far more common at this size, it produces a number that is usually not wrong by much, and it cannot be defended by anybody, including the person who posted it, four months later.

That is the whole argument of this piece. The direction of causation is the control. The schedule is the source and the ledger is the consequence, and any arrangement in which the ledger comes first is a balance nobody can substantiate. A plug journal survives right up until an outsider asks to see the contracts behind the balance, at which point the company discovers that the reconciliation it has been calling a reconciliation was an assertion.

What follows is the file itself: how a contract enters it, what one row holds, the roll-forward that proves it, the journal it produces, and the diagnostic when the tie to the control account breaks. The question of which recognition pattern a given contract type gets is not settled here. It is settled once, in the policy, and the service revenue recognition policy piece covers how that policy is written and what belongs in it. This piece assumes the answer exists and shows the machinery that carries it out every month.

All figures below are illustrative. They are here because the mechanics are hard to follow in the abstract, and they describe no client and no real contract.

Long format, not wide

The first decision is the file’s shape, and it is made badly almost every time.

The instinctive layout is wide: one row per contract, one column per month, release amounts typed across. It reads beautifully on the day it is built. It then breaks, in this order. It breaks at the year boundary, when somebody adds twelve more columns and the formulas from the old columns do not carry. It breaks when a contract is amended mid-term and there is no honest place to put the change. It breaks when a reviewer wants to know what the schedule said in a month that has already been locked, because the wide file has been overwritten in place and the earlier version no longer exists.

Build it long. One row per contract per period, with the period as a field rather than as a column position.

Field	What it holds
Contract identifier	The key everything else joins on, and it survives a customer name change
Customer, and the contracting legal entity	Two fields, because they are frequently different
Period	The month this row belongs to
Opening balance	Carried from the prior period’s closing balance for the same contract
Billings added in the period	What was invoiced, not what was collected
Released to revenue in the period	The output that becomes the journal
Adjustments in the period	Credits, terminations, corrections. Always separate from releases.
Closing balance	Opening plus billings, less releases, plus or minus adjustments
Release basis	The named pattern, and a reference to the clause in the policy memo that authorises it
Release start and end	Dates, held as data rather than embedded in a formula
Last reviewed, and by whom	So a stale row is visible without opening it

The adjustments column is the one people leave out, and leaving it out is why schedules stop tying. A credit note netted into the release column makes the month’s revenue wrong and hides the correction inside a figure that is supposed to be mechanical. Keep the two apart and the roll-forward will tell you which is which for the rest of the contract’s life.

Intake happens at signature

A contract enters the schedule when it is signed, not when it is first invoiced. That gap looks harmless and it is where the completeness problem lives: a contract signed near period end and invoiced in the following month is invisible to the schedule for a month, and nobody notices because the balance still ties.

Intake is six fields and it takes minutes.

1. Contract identifier and the contracting entity. Assigned by finance, not by the sales system.
2. Total contract value and the billing schedule. Two different things, and the schedule needs both.
3. The service period: start date and end date. Where the end date is conditional, record the condition rather than guessing at a date.
4. The release basis, chosen from the patterns in the policy. Chosen, not invented. If the contract does not fit any existing pattern, that is a signal that the policy needs a new row and the question goes to the accountant who reports on the statements, before the first release rather than after twelve of them.
5. Whether any amount is conditional or refundable, and on what. Refund and cancellation rights change what happens at the end and they are almost never remembered later.
6. Who at the company owns the delivery. So that the schedule has a person to ask when something looks wrong.

Field 4 is the one that matters. A contract entering the schedule with a release basis chosen by whoever set it up, rather than selected from a documented list, is the beginning of a schedule that is internally inconsistent in a way nobody will find until it is a year old.

One contract, nine months

Take a single support agreement to show the mechanics end to end. Illustrative figures throughout.

The contract runs twelve months for 60,000, invoiced in full at the start of month one, releasing evenly across the term at 5,000 a month. Two things then happen to it, and they are the two things that happen to real contracts.

In month five, the customer adds a second location. A further 18,000 is invoiced covering the remaining eight months of the term. Whether the unreleased balance of the original contract is re-spread together with the addition, or the addition runs as a separate element alongside the original pattern, is a question the policy answers and the memo records. It is not a question the person maintaining the schedule decides in the moment, and it is not a question this piece answers. For the arithmetic below, assume the memo directs the first treatment, so the remaining balance and the addition are released together over the remaining term.

In month nine, the customer terminates. The contract provides for a refund of the unearned portion, so a credit note is raised for the closing balance and the row ends at nil.

Month	Opening	Billings added	Released	Adjustments	Closing
1	0	60,000	5,000		55,000
2	55,000		5,000		50,000
3	50,000		5,000		45,000
4	45,000		5,000		40,000
5	40,000	18,000	7,250		50,750
6	50,750		7,250		43,500
7	43,500		7,250		36,250
8	36,250		7,250		29,000
9	29,000		7,250	(21,750)	0

The month five release comes from the unreleased balance of 40,000 plus the 18,000 added, spread across the eight months that remain, which is 7,250 a month. The month nine adjustment is the credit note for the balance the contract required to be refunded.

The proof of the whole row is one line of arithmetic, and it is the reason to build the file in long format:

Total billed, less total adjusted, equals total released.

Here, 78,000 billed less 21,750 credited is 56,250, and the release column adds to 56,250. That identity holds for every contract that has run to its end, and it is the first thing to check when a contract closes. A completed contract whose columns do not satisfy it has an error somewhere in its history, and you now know it is in that contract rather than somewhere in the ledger.

The journal, and where it comes from

Each month the schedule produces exactly two kinds of entry, and neither is typed by a person.

The billing entry, which usually arrives from the invoicing system rather than from the schedule: receivables debited, deferred revenue credited. In month five of the example, 18,000 both ways.

The release entry, which is the schedule’s own output: deferred revenue debited, revenue credited, for the total of the release column across every contract in the period. In month five, 7,250 from this contract plus whatever the rest of the book released.

Three rules around that entry, and they are what make it evidence rather than a number.

One release journal per period, for the whole schedule. Not one per contract, which nobody reviews, and not several posted on different days, which cannot be traced back to a single version of the file.

The journal description carries the schedule reference and the period. A reviewer reading the general ledger three years from now should be able to find the exact file the figure came from without asking anyone.

Nothing else is ever posted to the deferred revenue account. No reclassifications, no corrections typed straight into the control account, no year end tidying. If a correction is needed it goes into the adjustments column of the schedule and flows out through the same journal as everything else. The moment a second source is allowed to post to that account, the tie below stops proving anything.

The control account tie, and what to do when it fails

At every close, the closing balance column of the schedule agrees to the general ledger deferred revenue account. To the dollar, with no reconciling items. A tie carrying reconciling items is not a tie, it is a list of things nobody has explained.

When it does not agree, work the difference in this order. The sequence matters, because each step is cheaper than the one after it and the causes are roughly in this frequency.

1. Compare the difference to a single contract’s billing or release. Differences that match one row exactly are almost always a contract missing from the schedule, or an invoice raised against a contract nobody added. This finds most breaks in under a minute.
2. Check for a journal posted directly to the account. Filter the ledger detail for the period on anything whose source is not the release journal. This is the second most common cause and it is usually well intentioned.
3. Check the prior period closing against this period opening, contract by contract. A carried-forward balance that does not match its own prior closing means the earlier file was edited after it was locked, which is a process failure rather than an arithmetic one and needs fixing at the process end.
4. Check that every credit note in the period appears in the adjustments column. Credits raised in the billing system and never reflected in the schedule are the classic year end surprise.
5. Check the release start and end dates on any contract that began or ended in the period. Part months at the boundaries are where the arithmetic errors cluster.
6. Only then look for a systemic problem. By this point you are looking at a mapping error or a rounding convention, and both of those are worth an hour because they will otherwise recur every month.

Write the cause down each time, in one line, against the period. After six months the list of causes is a defect log, and it usually shows that two or three of the six steps above never fire at all, which tells you where the process is actually weak.

Locking, and why the prior file must be immutable

The schedule for a locked period does not change. Ever. It is saved, dated, and referenced by the journal that came out of it, and the next month starts from its closing balances rather than from a live file that someone can still edit.

This is the discipline that companies find fussy and then need. A reviewer, a lender or a buyer’s advisor asking why deferred revenue moved between two periods is asking a question that only has an answer if both periods’ files still exist as they were. A single living workbook that has been updated in place for three years cannot answer it, and the honest response, which is that the file has been overwritten, is the sort of answer that changes how the rest of the conversation goes.

Where this sits in the close sequence, and which day the tie is performed on, is part of the monthly close we run. The point in the sequence matters: the tie is performed after billing has finished for the period and before the balance sheet review, because a break found during the review is a break found too late to fix without moving the reporting date.

The three events that break schedules

Nothing else does much damage. These three do it repeatedly.

Event	What the schedule does mechanically	What it does not decide
Mid-term amendment	Records the change with its effective date, closes the old basis, opens the new one, and leaves both visible in the row’s history	Whether the amendment is treated prospectively, as a separate element, or otherwise. That is the policy’s answer, and where the policy is silent it is a question for the accountant who reports on the statements.
Early termination	Applies whatever the contract provides for, records the adjustment separately from releases, and ends the row at nil	Whether a balance with no refund right is released, held or treated some other way. Again the policy, and again not the person maintaining the file.
Re-billing or a credit and re-issue	Shows the credit and the new billing as two movements, never as a net figure	Nothing. This one is purely mechanical, and netting it is purely laziness.

The middle column is the schedule’s job and it is entirely mechanical. The right column is not, and the failure that produces restatements is a competent person doing the middle column while quietly answering the right column at the same time, because the file needed a number and there was nobody to ask that afternoon.

Who maintains it

One preparer, who owns intake and the monthly roll, and one reviewer, who checks the tie and reads the intake log for the period against the signed contracts.

The reviewer’s job is smaller than it sounds and it is the half that gets dropped. Checking arithmetic is not it; the file does the arithmetic. The reviewer is checking completeness, which means asking whether every contract signed in the period actually entered the schedule. That is a different question from whether the schedule ties, and a schedule can tie perfectly while missing contracts entirely, because a contract that was never billed and never released leaves no trace in either the file or the ledger.

What we do not do

We do not post a deferred revenue journal that was not produced by the schedule, in any month, for any reason. We do not net a credit note into a release. We do not maintain the schedule inside the accounting package’s own deferral tool without an independent copy, because a tool that both calculates and stores the answer cannot be used to check itself. And we do not answer a treatment question at the schedule, because the person maintaining the file at month end is the worst placed person in the company to be making that call and the best placed person to be recording somebody else’s.