Prepayment Schedule from Xero: Why You're Still Building It by Hand

Search "prepayments" in Xero and you will find a feature. Open it, and it is the wrong one.

Xero's Prepayments are advance payments — a customer pays you before you invoice them, or you pay a supplier before the bill arrives. Useful, well built, has its own API endpoint. Entirely unrelated to the thing you were looking for.

What you were looking for is the annual insurance premium you paid in March, sitting on the balance sheet, that needs to be released to the P&L at one twelfth a month until February. Xero's own guidance tells you to do exactly that: book it as an asset, expense it as you consume it. What Xero does not give you is anywhere to record the period, anything to compute the release, or any schedule to show the auditor at year-end.

So it goes in a spreadsheet. It has gone in a spreadsheet at every company I have looked at.

The request is open, and it isn't coming

This is not an oversight nobody noticed. There is a Xero Product Ideas request for prepayment and accrual schedules, asking for something that works "similar to the Fixed Asset function" — register the item, set the period, let Xero generate the journals. It is marked Accepted and has 273 votes.

In November 2025, Xero's community manager replied that while they understand the need, with bill creation and payment improvements on the roadmap there are "currently no plans for this in the pipeline."

That is a clear answer, and a useful one. Plan around it.

What Xero actually gives you

The standard workaround, and the one every Xero-literate bookkeeper reaches for:

1. Code the bill line to a Prepayments current asset account instead of the expense account.
2. Set up a repeating manual journal: debit the expense, credit prepayments, one twelfth of the amount, monthly, with an end date after the final release.
3. Let it post.

This works. It is genuinely the right answer for a company with four prepaid contracts. The journals land on time, the asset unwinds, and nobody has to remember anything on the last day of the month.

It is also not a schedule. And the difference shows up the moment anything changes.

Where it breaks

The repeating journal doesn't know why it exists. It is an instruction to post $1,250 every month until a date. It has no link to the bill it came from, no record of the service period, no idea which supplier or contract it relates to. Cancel the contract in month seven and the journal keeps posting until someone remembers it exists.

Credit notes and renewals silently desynchronise it. A supplier issues a partial credit against a prepaid bill. The asset balance drops. The journal does not. Five months later the prepayments account is negative and nobody can say which contract caused it.

There's no listing. At year-end the auditor asks what makes up the $84,000 in prepayments. Xero can tell you the account balance and it can tell you the transactions that hit the account. It cannot tell you that the balance is nine contracts, with these start and end dates, these monthly releases, and this much left to run. That listing — the actual working paper — is assembled by hand every single year.

Part-months are a guess. A contract running 17 August to 16 August doesn't release in neat twelfths. Either you compute the daily rate and accept twelve different journal amounts, or you round to whole months and let the error sit there. Most people round. It is usually immaterial. "Usually" is doing work in that sentence.

One bill, several periods. A single invoice covers three software licences with three different renewal dates. It is one line in Xero, one coding decision, and one repeating journal — or it is three, split by hand, and now the bill doesn't tie to the schedule without a reconciling note.

Nothing reconciles itself. The prepayments account balance is correct only if every one of these has been maintained. There is no control that tells you it hasn't. You find out at year-end.

The part nobody mentions: the dates are in the description

Here is the thing that makes prepayments genuinely harder to automate than fixed assets, and it is the reason a prepayment schedule can't just be generated from the ledger.

A fixed asset has a purchase date and a useful life, both of which are fields. A prepayment has a service period, and the service period is not a field anywhere in Xero. It is written in the line description, by a human, in whatever format that human felt like using.

Across the books I have pulled prepayments out of, the same period gets written like this:

Annual licence 02.01 - 06.01.25
Insurance (From 24 Apr 25 to 19 Feb 2026)
Season parking Apr 2025 to Dec 2025
Period: 10 Feb 2025 - 09 Feb 2026
Maintenance 20/02/2025 - 19/02/2026
Subscription renewal Feb 26
Support contract, 12 months from 11.08.25

Seven lines. Seven formats. Dotted ranges, slashed ranges, "From … to …", a labelled period, a bare month, an implied duration with no end date at all. Two of them omit the year on the start date and only state it at the end. One of them, 02.01 - 06.01.25, is ambiguous unless you know the company writes day-first.

Any tool that claims to build your prepayment schedule automatically has to solve this, or it has to make you retype every period into a form — at which point you are back to maintaining a spreadsheet, just a more expensive one.

Solving it means reading those descriptions the way a person does. The part of the report that does that reading is a parser: a list of date patterns, tried in a fixed order until one of them matches. Dotted range, then slashed range, then "From … to …", then a labelled period, then a bare month, and on down the list.

Writing the patterns is the easy half. The half that matters is what happens when none of them match — because something always doesn't. The schedule has to flag the line it could not read rather than quietly guessing at it. A schedule that silently defaults an unreadable line to twelve months is worse than no schedule, because it looks finished.

Then give people a way to be explicit when the description is hopeless. A convention like [prepayment period: 1 Mar 2026 - 28 Feb 2027] appended to the line description costs the person coding the bill about four seconds, overrides whatever the parser would otherwise infer, and turns the worst 5% of lines into the easiest ones. Conventions beat cleverness.

What hitting the wall looks like

The firm doing year-end for forty clients. Every file needs a prepayments working paper: contract, supplier, amount, period, released this year, carried forward. None of the forty have one. Forty spreadsheets get rebuilt from bill listings, at senior rates, every year. It is the same shape of problem as the fixed asset movement note — the data is in Xero, the deliverable format isn't.

The finance manager who inherited the file. There are fourteen repeating journals. Three relate to contracts that ended. One posts to an expense account that was archived. The prepayments balance is $61,400 and the schedule that explains it was last updated by someone who left in April.

The controller at month-end. Prepayments are a five-minute job in a good month. In a bad month — a renewal at a new price, a credit note, an early termination — they are the reason the management accounts go out two days late, because the release doesn't agree to the balance and somebody has to find out why.

The auditor's first request. Prepayments listing, agreed to the general ledger, with supporting invoices. This is the one that turns a two-day audit prep into a week.

What a good prepayment schedule looks like

Across the ones we have rebuilt, the same properties keep showing up:

1. One line per prepaid item, not per journal. Supplier, document number, description, amount, service period, and the monthly release across the columns of the year. The working paper is the schedule.
2. The period derived from the source, then shown. Parsed from the bill description where possible, stated explicitly where not, and visible on the row so a reviewer can check it without opening Xero.
3. Unreadable lines surfaced, not hidden. Anything the parser couldn't read appears in the schedule flagged, with the full original description, so the gap is a to-do rather than a silent misstatement.
4. A tie-out to the balance sheet. Total of the closing column equals the prepayments account balance at that date, computed on the sheet, every run. If it doesn't, the difference is shown rather than buried.
5. Release by month across the whole year. Not a single current-month figure — the full grid, so next year's P&L charge is already known and can go straight into the budget.
6. Credit notes and part-periods handled. A credit against a prepaid bill reduces the remaining release. A period that starts mid-month releases pro rata, or rounds on a stated convention, consistently.
7. Regenerated, not maintained. Run it again next month and it rebuilds from the ledger. A schedule that has to be carried forward by hand is a schedule that will eventually be wrong.

Accruals are the mirror image of the same problem, incidentally — same period-in-the-description issue, same missing module, same spreadsheet. If you are building one, build both.

The workarounds, ranked

1. Spreadsheet plus repeating journals. The default, and honestly correct below about ten prepaid contracts. Cheap, transparent, and everyone understands it. Breaks on staff turnover, early terminations and the third credit note.
2. A dedicated add-on. Tools like ScaleXP and Dext's prepayments module will generate the schedules and the journals off your Xero bills. Worth a look if prepayments are the only gap you have — though most of them still want you to confirm the period for each item, which is the work you were trying to avoid.
3. Build the schedule off the Xero API. Pull the bills coded to the prepayments account, resolve the periods, compute the release grid, tie it to the balance sheet. More effort up front, and nothing to re-template when a contract changes shape. Building Custom Reports with the Xero API covers what you're signing up for.

Where Cheetah fits

A decent share of our work starts with someone opening the prepayments tab of a year-end file and apologising for it. Usually it is a sheet with a column per month, a few rows highlighted yellow because nobody could work out the period, and a reconciling difference at the bottom that has been carried forward for two years.

We rebuild it as a report: every prepaid line pulled from Xero, the service period resolved from the description with the unreadable ones flagged rather than guessed, the monthly release computed across the year, and the closing total tied to the balance sheet on the face of the sheet. It regenerates every month from live data, so the working paper and the ledger cannot drift apart. Then we do the accruals schedule the same way, because it is the same problem wearing a different hat — and both end up in the same pack as the unaudited financial statements they support.

If the prepayments schedule is the bit of year-end that gets left until last, Cheetah is probably worth twenty minutes.

The short version

Xero has no prepayment schedule. The feature named "Prepayments" is advance payments against invoices, which is a different thing. The request for a real one is Accepted, has 273 votes, and has no place on the roadmap.

The repeating-journal workaround posts the entries but produces no working paper, and drifts the moment a contract changes. The genuinely hard part isn't the arithmetic — it's that the service period lives in free text in the line description, in a dozen formats, and any automation has to either read it or admit it couldn't.

The data is all in your Xero file. Turning it into the schedule the auditor asks for is a build-a-layer problem, not a wait-for-Xero one. The full menu of routes is in Xero Custom Reports: 4 Ways to Build Them in 2026.