The inflow side of a thirteen-week forecast is genuinely hard, because it depends on customers. The outflow side is not hard. It is sitting in your AP ledger right now, and the reason most forecasts get it wrong is a single unexamined assumption: that invoices are paid on their due dates.

They are not. An invoice is paid on the first payment run that falls on or after the later of two dates — the date it became due, and the date it finished being approved. For a healthy invoice those two are close. For an invoice sitting in exception they can be weeks apart. A forecast built on due dates alone is not slightly wrong; it is wrong in a specific, predictable direction, and it is wrong by more in the weeks that matter most.

This is the method for fixing that, built from an ordinary AP export. No new software, one spreadsheet, and a weekly check that tells you which assumption failed rather than just that the number missed.

Start from the ledger, not the aging report

An aging report is a summary. It has already thrown away the fields you need. Export the open invoice line items instead, with six columns:

Invoice ID and vendor
Receipt date — when it arrived, not when it was entered
Due date — from the terms on the invoice, not the terms in the vendor master, if they differ
Amount
State — received-not-coded, in-approval, approved-not-scheduled, scheduled, or in-exception
Exception type, where one applies

The state column is the one most exports omit and the one the whole method rests on, because each state has a different distance to payment. If your system cannot produce it, you can reconstruct it from the approval audit trail; if it cannot produce that either, that is a finding worth acting on before you build any forecast at all.

The placement rule

Every open invoice gets one forecast payment date, from one rule:

forecast_pay_date = next_payment_run on or after
                      max(due_date, approval_ready_date)

approval_ready_date = receipt_date + remaining_lag(state)

Three things follow from writing it this way, and each is a correction to the naive due-date forecast.

The payment run quantises everything. If you run payments on Tuesdays and Fridays, no invoice is ever paid on a Wednesday. An invoice due Wednesday is paid Friday. Across a quarter this shifts a meaningful slice of your outflow into different weeks than the due dates suggest, and it is the easiest correction to make because the run calendar is a fact, not an estimate. If your run calendar is ad hoc, fix that first — see payment run scheduling for why the calendar itself is a control.

Approval lag only pushes, never pulls. The max() matters. An invoice approved three weeks early is still paid on its due date; an invoice approved four days after its due date is paid late. So approval lag adds to your forecast in one direction only, which is precisely why a forecast that ignores it is biased rather than merely noisy.

Exceptions do not belong in the same distribution. More on this below, because it is where most forecasts quietly break.

Measure the approval lag, do not assume it

Every article on this topic tells you to apply an approval lag. Almost none tell you to measure yours, and the assumed figures in circulation are close to useless because the distribution has a long right tail.

Pull the last 90 days of paid invoices and compute, for each one, the days from receipt to final approval. Then take percentiles, not an average:

Percentile	What it is for
p50 (median)	The centre of your forecast. Use this to place invoices.
p80	The lower edge of your confidence band.
p95	The upper edge, and the number that tells you how bad a bad week looks.

The mean is the wrong statistic here. A handful of invoices that took 40 days will drag a mean well above the value that describes a typical invoice, so a mean-based forecast is late on almost everything and then wrong in the other direction on the tail. The median places the mass correctly; the percentiles describe the spread.

Segment the measurement wherever the segments genuinely differ — the usual splits that pay for themselves are by approver, by amount band (anything above a threshold picks up a second approver and a different lag), and by whether a purchase order exists. Three segments is normally enough. If a segment has fewer than about thirty invoices in ninety days, do not segment it; you are fitting noise.

Then apply the remaining lag by state, not the full lag. An invoice already in approval has consumed part of its lag. A practical approximation: subtract days already elapsed since receipt, floor at one day.

Model invoices in exception separately

An invoice in exception is not a slow invoice. It is an invoice waiting on a fact that AP does not hold — a missing receipt, a price variance, an unanswered coding question, a vendor query. Its timing is governed by how long the person who holds that fact takes to respond, which has nothing to do with your approval-lag distribution.

Fold exceptions into the main distribution and you get two errors at once. Their long resolution times inflate your p80 and p95, making your whole forecast look more uncertain than it is. And the exception money itself lands with a shape your percentiles do not describe — bimodal, because exceptions either resolve quickly or sit.

Forecast them as their own line, with a resolution curve per exception type. You already have the data if you are tracking hold age; if you are not, our piece on invoice exception handling covers the two-clock design that produces it. A workable curve for most teams is: the share resolved within one week, within two, within four, and the share still open beyond that, computed per type from your last two quarters.

The residual — the share still open beyond four weeks — is the honest part of the forecast. Carry it as an explicit unresolved line rather than distributing it across future weeks. A number labelled "in exception, unscheduled, $198,000" is useful to a CFO. The same money smeared invisibly across weeks 5 to 13 is not.

Discount capture is an input, not a prediction

Early payment discounts are the one place where the forecast stops predicting and starts recording a decision. If a vendor offers 2/10 net 30 and you take it, that invoice's outflow moves forward by twenty days and shrinks by 2%. Nothing about that is uncertain. It is a switch you control.

So model it as a switch. Add a column for discount terms, a flag for whether you intend to take the discount, and let the placement rule read the flag: if set, the due date becomes the discount date. Then you can run the forecast twice and see the whole shape of the trade — the money you save against the week you have to find it in.

That framing also stops the common failure, which is discovering the discount too late to act on it. The decision has to be made while the invoice is still in approval, which means the forecast must show you the eligible population before the discount window closes, not after. Our guide to early payment discounts covers the underlying arithmetic of when a discount is worth taking.

A worked thirteen weeks

Every figure below marked ASSUMPTION is one you replace from your own export. The approval-lag percentiles are marked MEASURED, because those are the ones you must not assume.

The open ledger at forecast date — ASSUMPTION, from your export:

State	Count	Value
Scheduled	120	$410,000
Approved, not scheduled	95	$362,000
In approval	180	$684,000
Received, not coded	60	$215,000
In exception	44	$198,000
Total open	499	$1,869,000

The inputs:

MEASURED approval lag: p50 four days, p80 nine days, p95 twenty-one days
ASSUMPTION payment runs on Tuesdays and Fridays
ASSUMPTION coding adds two days before approval begins
ASSUMPTION exception resolution: 15% in week 2, 25% week 3, 25% week 4, 20% week 5, 15% still open at week 6
ASSUMPTION run rate of $570,000 per week of newly received invoices, mostly net 30

Applying the placement rule to each state gives the ledger-driven weeks:

Week	1	2	3	4	5	6
Scheduled	410,000	—	—	—	—	—
Approved, not scheduled	217,200	108,600	36,200	—	—	—
In approval	—	136,800	307,800	171,000	68,400	—
Received, not coded	—	—	64,500	96,750	53,750	—
In exception	—	29,700	49,500	49,500	39,600	29,700
From ledger	627,200	275,100	458,000	317,250	161,750	29,700

Those six columns sum to $1,869,000, which is the whole open ledger — a useful check that nothing has been double-counted or lost.

Notice what happens after week 4: the ledger runs out. That decay is not a forecast of falling payments, it is the edge of what you currently know. Weeks 5 onward have to come from the run rate, ramping in as newly received invoices reach their due dates, plus any commitment you can name:

Week	Forecast outflow	Source
1	$627,200	Ledger
2	$275,100	Ledger
3	$458,000	Ledger
4	$317,250	Ledger
5	$503,750	Ledger + 60% run rate
6	$542,700	Ledger + 90% run rate
7	$570,000	Run rate
8	$570,000	Run rate
9	$665,000	Run rate + insurance renewal $95,000 (ASSUMPTION, named commitment)
10	$570,000	Run rate
11	$632,000	Run rate + software true-up $62,000 (ASSUMPTION, named commitment)
12	$570,000	Run rate
13	$570,000	Run rate
Total	$6,871,000

Now the discount switch. ASSUMPTION: $150,000 of the in-approval bucket is with vendors offering 2/10 net 30, currently placed in week 4. Take the discounts and week 4 falls to $167,250 while week 2 rises to $422,100, at a cost of finding $147,000 six weeks earlier and a saving of $3,000. That is the whole trade, in two cells, and it is a decision for a person rather than an output of a model. Where those decisions compound is the subject of working capital optimization in AP.

The weekly variance check

A forecast that only tells you it missed teaches you nothing. Structure the check so that every variance is attributed to a named assumption, because then the forecast improves on a schedule instead of by intuition.

Each Monday, compare the previous week's forecast to what actually left the account, then decompose:

Assumption	What to compare	What a miss means
Approval lag p50	Forecast approval-ready dates vs actual approval timestamps	Re-measure. A drifting median usually means an approver's workload changed, not that the model is wrong
Exception resolution curve	Exceptions forecast to resolve vs those that did	Your curve is stale, or one exception type has an owner who stopped responding
Due-date distribution	Invoices forecast due this week vs actually due	Terms in the vendor master disagree with terms on invoices
Payment run adherence	Runs forecast vs runs executed	A run was skipped or added off-calendar, which is a control issue as much as a forecast one
Discount take-up	Discounts flagged vs taken	The decision is being made after the window closes
New invoice arrivals	Run rate assumed vs invoices actually received	Volume genuinely changed, or intake is being delayed somewhere before AP sees it

The discipline that makes this work: attribute the whole variance, every week, even when it is small. A $12,000 miss decomposed into $30,000 of late approvals against $18,000 of exceptions resolving early is a much more informative week than a $12,000 miss that nobody opened.

After roughly six weeks of this you will find one or two rows carrying most of the error. Those are the rows to fix — usually by re-measuring more often, occasionally by segmenting a distribution that turned out to hide two populations.

How this relates to DPO, and where to stop

Days payable outstanding is the output of everything above, not an input to it. If your forecast is accurate, DPO falls out of it: it is the average distance between invoice date and forecast payment date, weighted by amount. That makes DPO a useful summary and a poor instrument.

The distinction matters in one practical way. Managing DPO as a target tends to produce a decision to pay everything later, which improves the metric and damages vendor relationships without telling you anything about the timing of your outflows. Building the schedule first, and reading DPO off it afterwards, gets you the metric and the week-by-week picture — and it makes the trade-offs visible, because you can see exactly which weeks a stretch would move money into.

That is where the forecast should stop. If your DPO is out of line with your terms, that is a payment-policy question with its own answer, not a forecasting one.

What to build this week

Four steps, and none of them need new software.

Export open invoices with a state column. If you cannot produce state, reconstruct it from the approval trail and note the gap.
Measure your approval lag. Ninety days of paid invoices, receipt to approval, p50/p80/p95. One number segmented three ways at most.
Split exceptions onto their own line with a resolution curve per type, and carry the beyond-four-weeks residual explicitly rather than distributing it.
Add the discount flag and run the forecast twice.

Then run the variance check next Monday and every Monday. The first three weeks will be uncomfortable and the sixth will be the point at which someone in the business starts using the number.

The part that decides how good this can get is upstream of all of it: how quickly an invoice becomes a ledger row with a state you can read. This is where Ken does its work — capture on arrival, coding and routing in hours, exceptions flagged with an owner and a clock rather than sitting in a mailbox. None of that is forecasting software. It just means that when you pull the export on Monday, the ledger describes what you actually owe rather than what you owed a fortnight ago.

FAQ

How do you forecast accounts payable outflows accurately?

Place every open invoice on the first payment run falling on or after the later of its due date and its approval-ready date, where approval-ready is the receipt date plus your measured remaining approval lag. Forecast invoices in exception on a separate resolution curve rather than the approval-lag distribution, because they are waiting on a fact rather than a signature. Treat discount capture as a switch you control, not a probability. Then check the forecast weekly and attribute the whole variance to named assumptions.

Why are cash flow forecasts wrong on the accounts payable side?

Because they use due dates as payment dates. An invoice is paid on the first payment run at or after the later of its due date and its approval completion, so approval lag pushes payments later and never earlier — which makes the error biased rather than random. Two further sources: invoices in exception follow their own timing entirely, and payment run calendars quantise every payment onto specific weekdays, moving a meaningful share of outflow into different weeks than the due dates suggest.

How do you measure approval lag for a cash forecast?

Take ninety days of paid invoices and compute days from receipt to final approval for each. Use percentiles rather than an average — p50 to place invoices, p80 and p95 for your confidence band — because the distribution has a long right tail that drags the mean above any typical invoice. Segment by approver, by amount band, and by whether a purchase order exists, but only where a segment has enough invoices to be meaningful; roughly thirty in ninety days is a sensible floor.

How should invoices in exception be handled in a cash flow forecast?

As a separate line with their own resolution curve per exception type, never inside the approval-lag distribution. An exception is waiting on someone outside AP who holds a missing fact, so its timing is governed by that person's response, and its shape is bimodal — resolving quickly or sitting. Carry the share still unresolved beyond about four weeks as an explicit unscheduled line rather than distributing it into future weeks, because an amount labelled as unscheduled is decision-useful and the same money smeared across the horizon is not.

Is DPO an input or an output of an AP cash flow forecast?

An output. Days payable outstanding is the amount-weighted average distance between invoice date and payment date, so an accurate forecast produces it rather than consuming it. Managing DPO as a target usually collapses into paying everything later, which moves the metric without telling you anything about when cash actually leaves. Build the dated schedule first and read DPO off it; if the result is out of line with your terms, that is a payment-policy decision rather than a forecasting problem.

Cash Flow Forecasting from Accounts Payable: Building the Outflow Side From Data You Already Have