Direct or Indirect Method for Your Weekly Cash Forecast

The direct method forecasts cash by listing specific expected inflows and outflows, this invoice due on this date, that payroll run on that date, and rolling them forward week by week. It's precise for a short horizon, typically 13 weeks or less, because it's grounded in transactions you can actually name rather than a formula applied to the income statement.

The cost is that it takes real, ongoing data entry or integration work to keep the transaction list current, which is exactly why it tends to fall apart in a spreadsheet-based process as soon as whoever built it gets busy with something else.

The indirect method starts from net income and adjusts for non-cash items and changes in working capital, receivables, payables, and inventory, to arrive at cash flow. It's the method your audited cash flow statement uses, and it's faster to produce for a longer horizon, a quarter or a year, since it doesn't require listing every individual transaction.

The cost is precision at the short end: it's much better at explaining last quarter's cash movement than predicting exactly how much cash you'll have on a specific Tuesday three weeks from now.

The indirect method leans heavily on an assumed payables and receivables cycle to project working capital changes, and that assumption is where a lot of forecasting error actually lives. Payables days vary enormously by industry, from around two to three weeks in fast-turnover sectors like restaurants to closer to two months in some services and healthcare-support segments¹, and a forecast built on a generic assumption rather than your company's actual payment cadence will drift from reality every period.

Check your actual trailing payables days against whatever assumption is baked into your indirect forecast model, and update the assumption if the two have diverged.

A practical setup uses the direct method for a rolling 13-week view, where precision on specific payments matters most for managing near-term liquidity, and the indirect method for a longer 12-month view, where the effort of a fully transaction-level forecast isn't worth it and the income-statement-driven view is accurate enough to plan against.

Reconcile the two periodically rather than letting them exist as two unrelated exercises: if the 13-week direct forecast and the longer indirect forecast tell noticeably different stories about the same upcoming month, one of the two has a stale assumption somewhere.

A practical setup combines the two methods:

1. Build a rolling 13-week direct forecast from named receipts and payments, for managing near-term liquidity.
2. Build a 12-month indirect forecast from the income statement and balance sheet, for longer planning and board reporting.
3. Feed AP, AR and payroll data into the direct forecast automatically, so the transaction list does not go stale.
4. Reconcile the two forecasts periodically and investigate gaps, such as vendor payments clearing earlier than the payables assumption implies.

The direct method's biggest weakness, the manual effort of keeping a transaction-level forecast current, mostly disappears once your AP, AR, and payroll data feed the forecast automatically instead of getting re-entered by hand. That shift is what makes a rolling 13-week direct forecast realistic for a small finance team to maintain, rather than a project that gets built once for a board deck and then goes stale.

BILL's AP data, in particular, is a natural feed for the direct method's outflow side, since the expected payment dates already exist in the system rather than needing to be recreated separately for the forecast.

Say your indirect forecast projects $400,000 in cash for the end of next month based on a 45-day payables assumption, while your direct forecast, built from the actual invoices on file, shows $340,000 because three large vendor payments are scheduled to clear earlier than that assumption implies. That kind of gap between the two forecasts is worth chasing down before the month closes, since one of the two numbers is wrong and only the direct forecast's transaction-level detail can tell you which one.