A forecast built from exported balances is accurate on the morning it is built and slightly wrong by the afternoon. The reasons are structural, and they show up in the same few places in most growing businesses.
1. What the forecast is actually built from
A cash flow forecast in a growing business is usually a spreadsheet with four inputs.
The four inputs
- The bank balance today. The only one of the four that is easy to verify.
- The receivables ledger, with a date beside each invoice for when the money is expected rather than when it is due.
- The payables ledger, with the dates the business intends to pay rather than the terms on the bill.
- The fixed items that sit outside both, such as payroll, rent, loan repayments and tax.
Only the first of those is easy to verify. The other three come out of the accounting system, and how they come out decides how long the forecast stays true. In an entry-level tool it normally means an export: someone runs an aged receivables report and an aged payables report, pastes both into the forecast file, overrides a handful of dates using what the sales and operations teams know, and presents the result. For a business with forty open invoices and a dozen suppliers, that method works and there is no reason to change it.
2. Where the drift starts
The forecast is a snapshot. The ledger is not. Between the export on Monday and the management meeting on Thursday, a customer pays two weeks early, four invoices are raised, a supplier bill arrives dated last month, and a credit note is issued against an invoice that the forecast still counts as incoming cash. None of those is a mistake. Each one moves the forecast away from the accounts, and nothing in the spreadsheet announces that it has happened.
The gap widens where payables, receivables and the general ledger are maintained as separate sets of records that reconcile to each other on a schedule. A payment applied in the receivables ledger but not yet reflected in the general ledger produces two reports that are each internally consistent and disagree about the same week. Whoever builds the forecast picks one of them, usually the one that is easier to export, and the difference surfaces later as an unexplained variance rather than as a known timing difference.
By the time the forecast is a few weeks old, the corrections tend to be applied on top rather than rebuilt from the ledger, because rebuilding means redoing the manual dates. That is the point at which the forecast stops being a view of the accounts and becomes a separate document that resembles them.
3. The spreadsheet holding the assumptions
The real value in most forecast files is not the exported figures. It is the overrides. This customer settles fifteen days after terms every time. That one pays on the day if the invoice reaches them before the 25th. This supplier will wait a fortnight if asked, that one charges interest. A retainer client is invoiced monthly but pays quarterly. None of that is in the accounting system, because entry-level tools have nowhere structured to put it.
Two problems follow. The knowledge lives with one person, so when they are away the forecast either goes stale or is rebuilt from raw terms and reads as wrong to everyone who knows the customers. And each refresh means re-applying those adjustments by hand against a fresh export, which is where the version most people are looking at stops matching the version someone updated yesterday.
The forecast is only as current as the last export, and the ledger does not stop moving while the spreadsheet is open.
4. What changes when the records sit in one ledger
AOC Accounting holds accounts payable, accounts receivable and the general ledger as a combined ledger, with a chart of accounts that prevents the same transaction being recorded twice. Reports are produced from that ledger immediately, without an export step in between.
For forecasting, the effect is narrow and specific. The receivables and payables positions a forecast starts from are read at the moment they are asked for, not at the moment someone last ran an export, and they cannot disagree with the general ledger because they are not separate records. The credit note raised on Tuesday is in the position on Tuesday. The bill dated last month that arrived this week is in it as soon as it is posted.
That does not build the forecast. It changes what the forecast is anchored to. The judgment about when a customer will actually pay still belongs to the business, but it is applied to a current position rather than to a copy that has been aging quietly since Monday. When someone in a meeting asks whether a figure includes a particular invoice, the answer comes from opening the ledger rather than from working out which export the file was built from.
5. Forecasting a business with more than one thing in it
Most forecasts start as one total for the whole business and stop being useful at the point where the business is doing several distinguishable things at once. A firm running four client projects, or trading through two entities, or selling through both a retail channel and a wholesale one, needs to know which part of the operation is consuming cash and which is producing it. A single company-level number cannot answer that, so the usual response is a second sheet, and then a third, each maintained separately and reconciled to the first by hand.
AOC supports up to 10 analysis dimensions per function, so the split a business cares about, whether that is project, entity, office, channel or client group, is recorded on the transaction as it is entered. Receivables and payables can then be read by that dimension directly. A project that is cash-negative for the next six weeks shows up as its own position rather than as an inference drawn from a company total, and no separate sheet has to be kept in step.
6. What a system will not forecast
No accounting system knows when a customer will pay. It records the invoice, the terms and the eventual receipt, and it can show what that customer has done historically, but the assumption about next month is a judgment the business makes. A forecast built on optimistic collection dates is wrong in exactly the same way whatever ledger sits underneath it.
A ledger also holds what has been committed, not what is expected. Revenue still in the pipeline, a hire planned for November, a price increase under negotiation and a capital purchase that has been discussed but not ordered are all outside the accounting records by definition, and any forecast worth reading includes them from somewhere else. The ledger supplies the committed base; management supplies the rest.
Designing the dimensions is real work as well. Deciding what counts as a project, whether a client group sits above the customer, and which of the available dimensions the business will genuinely maintain takes a session with the people who understand operations, done once and before anything is configured. And history already recorded without those splits stays that way, so a business that starts tagging by channel in October cannot report the previous two years that way without going back over them.
7. One month, run both ways
Take a business with about 120 open sales invoices and three project teams. On the first Monday of the month, someone exports aged receivables and aged payables, pastes them into the rolling thirteen-week forecast, adjusts around thirty payment dates from memory and from a conversation with the account managers, and circulates the file. It takes most of a day and it is accurate that morning.
Over the next nine days a large customer pays early, two invoices are credited after a delivery dispute, a subcontractor bill for work done in the previous month arrives, and one project slips by three weeks, which moves both its billing and its costs. At the mid-month review the forecast shows a shortfall in week six that is no longer real, and nobody can say quickly whether the invoice being argued about is inside the number or not. The file is either rebuilt, which costs another half day and loses the thirty manual dates, or it is trusted with a caveat.
With the same transactions in one ledger, the mid-month position is read at the point the question is asked. The early payment, the credit notes and the late supplier bill are already in it. What still has to be decided is the same as before, which is when the disputed invoice is likely to be settled and how the slipped project rebills, and that discussion happens against figures nobody has to reconcile first. The saving is not the forecasting judgment. It is the day and a half a month spent rebuilding the base the judgment is applied to, and the meetings that no longer stall on whether the number is current.
Bring your thirteen-week forecast to a walkthrough
See the receivables and payables positions read from one ledger at the moment the question is asked, with no export to rebuild and no manual dates to reapply.
About AOC Accounting: AOC Accounting is a combined-ledger accounting system built by Strategic Asia, a Singapore-based company that has run the product since 2015.
