Why Your Forecast Does Not Match Your Books

Every founder who has built a model has had this moment. You open the forecast, you open the accounts, and the same month shows two different numbers.

Usually it is discovered about ten minutes before it matters, and the ten minutes get spent deciding which number to say out loud rather than working out why they differ.

There are four causes, they are all mundane, and knowing which one you have takes about twenty minutes.

One: cash and accrual are not the same month

The commonest by a distance.

Your model recognises revenue when the customer starts. Your ledger recognises it when the invoice is raised, or when it is paid, depending on how it is set up. An annual contract signed in March, invoiced in April, paid in May, appears in three different months depending on which lens you use.

Neither is wrong. They answer different questions. Cash tells you what is in the bank, which is what kills companies. Accrual tells you what the business earned, which is what investors value.

The failure is not having both. It is running a model on one basis and reading accounts on the other without ever saying so out loud, so every comparison is apples to oranges and nobody notices for a quarter.

Fix: write the basis at the top of your model. Then check your accounting system is on the same one. In most SEA setups your statutory accounts are accrual and your instinct is cash, which is exactly the mismatch that bites.

Two: your revenue lines and your chart of accounts do not agree

Your model has revenue streams that reflect how you sell. Starter, Pro, Enterprise. Or hardware, subscription, services.

Your general ledger has accounts that reflect how you file. Often a single revenue account, occasionally two.

So the model has six revenue lines and the books have one. There is no automatic way to compare them, which means somebody does it by hand in a spreadsheet, which means it happens once and then never again.

Fix: decide the mapping deliberately and write it down. Either split the chart of accounts to match how you actually sell, or hold the mapping in a system that can apply it every month without a person. Doing it by hand is the option that silently fails.

Three: one-off revenue is sitting in your recurring line

Setup fees, implementation, professional services, that one hardware resale you did as a favour.

In the ledger it is all revenue and that is correct. In your model, if it lands in the same line as subscription revenue, your ARR is overstated and your growth rate is wrong.

This one has consequences beyond tidiness. Overstated ARR is trivially checkable in diligence, and an investor who finds it stops trusting every other number you have given them. It is one of the fastest ways to damage your own credibility, and it is almost always an accident rather than a fiddle.

Fix: separate recurring from non-recurring at the point of entry, in both places. If it does not renew without a new decision from the customer, it is not recurring.

Four: the model stopped being updated

The honest one.

You built the model before a raise. It was good. Then you closed the round and got busy, and the model has your March assumptions in it while your books have September reality. They do not disagree because of a technical mismatch. They disagree because one of them stopped tracking the business six months ago.

This is the most common cause and the least discussed, because it is embarrassing in a way the other three are not.

Fix: there is no fix that relies on discipline. Every founder intends to update monthly and most stop by month three. The only version that survives is one where actuals arrive in the model without anyone deciding to put them there.

How to work out which one you have

Take one month that is fully closed. Not the current one.

Compare total revenue in the model against total revenue in the accounts for that month. If they match, your problem is timing, and it is cause one or three. If they do not match at all, it is cause two or four.

Then compare the same figure three months earlier. If the gap is roughly constant, it is a structural mapping issue. If the gap is widening month on month, your model has stopped tracking and you have cause four.

Twenty minutes, and you know which conversation to have.

What it actually costs

Two things, and the second is worse.

The obvious cost is the board meeting where a number gets questioned and you cannot immediately explain the difference. Recoverable, but it spends credibility you would rather keep.

The real cost is that once a founder knows their forecast and books disagree and does not know why, they stop using the forecast to decide things. It becomes a document produced for investors rather than a tool for running the company. From that point you are making decisions on instinct while maintaining a spreadsheet that performs rigour.

That is a worse position than having no model at all, because it feels like being in control.

The structural answer

The four causes above are all symptoms of the same thing. The forecast and the ledger are two separate artefacts maintained by two separate processes, and reconciliation depends on a human choosing to do it.

Humans reliably choose not to, around month two, because it is tedious and nothing breaks immediately.

The version that holds up is one where the actuals land in the forecast automatically, on the same basis, with the mapping applied consistently, so that variance appears without anybody producing it. Then the question stops being which number is right and becomes why the gap exists, which is the useful conversation.

See how actuals and forecast connect