The Prepaid Schedule, and Why It Stops Agreeing With the Ledger

Prepaid expenses drift for one structural reason, and once you see it the fix is obvious. Additions arrive by one route and releases leave by another. An addition is somebody coding an invoice to the prepaid account on a Tuesday. A release is a recurring journal that somebody set up months ago and that nobody has looked at since. Those two routes never speak to each other, so the balance is the sum of two independent processes that only agree by luck.

The fix is one artifact. The schedule is the sub-ledger, the general ledger account is the control account, and every movement in the control account comes from the schedule. Not most movements. Every one. If that rule holds, the account is right at all times and the annual sweep finds nothing. If it does not hold, you have a number that looks like an asset and is partly a memorial to expired contracts.

What follows is one fiscal year of one schedule, walked end to end. The figures are illustrative round numbers, chosen so the arithmetic is visible on the page. They are not a client file, and the categories are generic on purpose.

Three decisions made once, before any of this works

What belongs on the schedule at all. This is not the schedule’s decision and it is not the bookkeeper’s. Whether a given payment is a prepaid asset or an expense on payment is a reporting policy question, it depends on your framework, and it is settled once with whoever reports on your statements. Write their answer in a sentence at the top of the schedule so the next person applies it rather than re-deriving it.

The floor. Below an amount you set, an item is expensed on payment and never opens a schedule line, regardless of the period it covers. A schedule with forty lines and a two-line total is a schedule nobody maintains. The test is the same decision test used for accrual thresholds: the amount below which the timing would not change anything anybody does.

The part-month convention. An annual policy that starts on the eleventh of a month can be released as twelve equal monthly amounts starting that month, or prorated by days. Pick one. Write it down. The convention itself does not matter much; having two conventions in the same file is what costs you an hour every quarter forever.

The schedule at the start of the year

Two lines carried in from the prior year.

Line	Coverage	Total	Monthly release	Balance carried in
Annual insurance, policy A	Prior year Month 9 through this year Month 8	36,000	3,000	24,000
Software licence, retired product	Ended in the prior fiscal year	1,800	150	1,800

The second line is the whole problem in one row. The coverage period ended, the recurring release journal was never set up, and the balance has been sitting there being reported as an asset. Nobody put it there deliberately. It arrived because an invoice was coded to prepaid in a hurry and the schedule was updated afterwards, or not at all.

The additions rule

One sentence, and it is the single control that matters most: the person who codes an invoice to the prepaid account adds the schedule line in the same act, before the invoice is posted. Not at close. Not on a list for later. In the same act.

The line needs five fields and no more: what it is, the coverage start, the coverage end, the total, and the monthly release amount. If any of those five cannot be filled in from the invoice in front of you, the invoice does not belong in prepaid yet, and it goes to a query rather than to a guess. That test alone catches most of what would otherwise become a stale balance, because an invoice with no identifiable coverage period is almost never a prepaid.

The release journal for a new line is created at the same moment, with an end date set to the coverage end. A recurring entry with no end date is how a released item keeps releasing into a credit balance eighteen months later.

The year, month by month

Four things happen during the year: a routine renewal, a deposit for an event, a contract that is cancelled part way, and an annual sweep that finds the stale line. All four are ordinary. All four are also the four ways a schedule goes wrong when the rules above are not held.

Month 2. A twelve month software licence is bought for 18,000, covering Month 2 of this year through Month 1 of the next. Monthly release 1,500. Line added, recurring journal created with an end date.

Month 4. A deposit of 9,000 is paid for a trade event that will be held in Month 10. This one has no monthly release, because nothing is consumed until the event happens. The line carries at full value and releases in one entry in Month 10. That distinction is worth being deliberate about: a prepaid releases as the benefit is consumed, and the benefit is not always consumed evenly. Straight-lining a deposit over the months until the event is a habit, not a calculation.

Month 6. A twelve month maintenance contract is bought for 12,000, releasing at 1,000 a month from Month 6.

Month 8. Insurance policy A finishes releasing. Its line goes to nil. The recurring journal stops on its own because it was given an end date in the prior year.

Month 9. The insurance renews at 39,000 for twelve months, releasing at 3,250 from Month 9. New line, new journal, and the old line is marked closed rather than deleted, so the history stays readable.

Month 9, second event. The maintenance contract is cancelled effective the end of the month. Four months have been released, 4,000, so 8,000 sits unreleased.

Month 10. Three things clear. The trade event is held, so the 9,000 deposit releases in full. The maintenance supplier refunds 5,000 against the cancelled contract. The remaining 3,000 is a cancellation charge and it goes to expense in Month 10, in its own entry, with the reason in the description. This is the wrinkle most schedules handle badly. The temptation is to release the whole 8,000 to expense and book the refund as a credit somewhere else, or to reduce the schedule by whatever the refund happened to be and quietly leave 3,000 behind. Neither survives being looked at. The line closes to nil, and the 8,000 that left it is split into the part that came back as cash and the part that did not.

Month 12. The annual sweep, described below, finds the retired software licence line still carrying 1,800 with a coverage period that ended in the prior year. It is released to expense in Month 12 with a note naming what it was and when the coverage actually ended.

The roll-forward

Line	Opening	Additions	Released to expense	Other movement	Closing
Insurance, policy A	24,000	0	24,000	0	0
Software licence, retired	1,800	0	1,800	0	0
Software licence, current	0	18,000	16,500	0	1,500
Event deposit	0	9,000	9,000	0	0
Maintenance contract	0	12,000	7,000	(5,000)	0
Insurance, policy B	0	39,000	13,000	0	26,000
Total	25,800	78,000	71,300	(5,000)	27,500

The closing balance is two live lines: one month left on the software licence and eight months left on the insurance. That is what a prepaid balance should look like at any point in time, which is to say every dollar in it should be traceable to a coverage period that has not yet ended.

The monthly tie

This is the step that gets skipped, and skipping it is what turns a small error into a two year error. It takes four minutes.

Month	Additions	Released	Other	Schedule closing
Opening				25,800
1	0	3,000	0	22,800
2	18,000	4,500	0	36,300
3	0	4,500	0	31,800
4	9,000	4,500	0	36,300
5	0	4,500	0	31,800
6	12,000	5,500	0	38,300
7	0	5,500	0	32,800
8	0	5,500	0	27,300
9	39,000	5,750	0	60,550
10	0	16,750	(5,000)	38,800
11	0	4,750	0	34,050
12	0	6,550	0	27,500

Every month, the schedule closing figure is compared to the general ledger prepaid control account. Two tests, not one.

The balance test. Schedule closing equals ledger balance. A difference means either an addition was posted to the ledger and not added to the schedule, or a release journal ran that the schedule does not know about.

The line test. The number of open lines changed only by the additions and closures you can name from the month. This is the test that catches the failure the balance test cannot, which is two errors that happen to offset. A schedule that ties on the total while carrying an extra line and a missing line is a schedule that will fail in a month when the two amounts stop being equal, and by then nobody remembers which month it started.

Note both results in the close binder with the preparer’s name against them. A tie that nobody asserted is the same as a tie that never happened, which is the general rule for reconciliations in the close checklist and applies here without amendment.

The four ways it breaks

Ranked by how often I find each of them, not by how bad each one is.

The failure	What the schedule looks like afterwards	The rule that prevents it
Invoice coded to prepaid, schedule never updated	Ledger balance exceeds the schedule, growing	The additions rule: line before posting
Renewal coded as a new addition while the old line keeps its balance	Two lines for one contract, both live, balance roughly doubled	The renewal closes the old line in the same entry that opens the new one
Recurring release journal with no end date	Balance goes through nil into a credit, and a credit in a prepaid account is invisible on a summary balance sheet	Every release journal gets an end date at creation
Credit note or refund posted to the ledger only	Schedule exceeds the ledger, and the gap is the exact size of the credit	Every movement in the control account comes from the schedule, including credits

The second one is worth more attention than it gets. Renewals are the majority of prepaid additions in a stable company, and the person coding a renewal is usually looking at an invoice that says almost exactly what last year’s said. Nothing about the document signals that a line needs closing. This is why the coverage end date is a required field: a line with a coverage end that has passed and a balance that has not is a report you can run in ten seconds, and it should be part of the close.

The annual sweep

The monthly tie catches arithmetic. The annual sweep catches judgment, and it takes about half an hour once a year, before the year end file goes anywhere.

Read every open line and answer three questions on each.

1. Does the coverage period still extend beyond the balance sheet date? If not, the balance is not an asset and it releases now, in the current year, with a note. This is the question that found the 1,800 in the walkthrough.
2. Is the counterparty still supplying the thing? A contract that was cancelled, a supplier that stopped trading, a service that was migrated away from mid-term. The balance may be a receivable, or it may be nothing. It is not a prepaid.
3. Does the release pattern still match how the benefit is actually consumed? A support contract billed annually and used evenly is straight line. A deposit against a single future event is not, and neither is a licence that was only deployed halfway through its term.

Anything the sweep changes gets written up in one line: what the item was, what changed, what was posted, and the date. The write-up matters because a prepaid adjustment found at year end is exactly the kind of item that gets asked about later, and “we found it during the annual review of the schedule” is a much better answer than a reconstruction attempted eight months afterwards.

Who owns it

One person owns the schedule, and it is the person who codes invoices, not the person who reviews the close. That allocation feels backwards to people who expect the more senior person to own the harder artifact, but the schedule is not hard. It is continuous. Its integrity comes from being updated at the moment an invoice is coded, and the reviewer is not in the room at that moment.

What the reviewer owns is the tie and the sweep. Two checks a month and one read a year. On an engagement where we run the monthly close, the schedule is set up in the first month and the tie goes on the reconciliation day with everything else, because a prepaid schedule built as a separate exercise gets maintained as a separate exercise, which is to say for about a quarter.

Against that half hour: a balance in a small company’s accounts that is genuinely correct every month, and a year end where nobody has to explain what the prepaid account is made of.