Cash Flow · One module of the operating system
Your spreadsheet was right on Monday.
The records are right today.
A weekly cash flow forecast computed from the job records you already keep: progress claims, open purchase orders, approved invoices, recurring overheads, your client payment lag, and GST and BAS timing. It is arithmetic over your own data, not a prediction. The same inputs always produce the same forecast, and the figures are recomputed from the source records every time you read them, so the forecast cannot quietly drift away from the jobs underneath it.
The Founding Builders Programme · Onboarding in small cohorts
01 / What it does
What this feature does
Cash Flow Forecasting is the module that answers the only question that decides whether a building business survives a good year: not what each job earns, but when the money moves. It builds a weekly view of cash in and cash out across your jobs, and it builds it from records that already exist in the operating system rather than from a separate sheet somebody has to maintain. The discipline itself, the job cash curve, the mid-stage dip and the thirteen-week horizon, is covered in the reference on cash flow forecasting for builders. This page is about the machinery that produces the number.
Six sources feed it. Progress claims supply the money expected in. Open purchase orders supply money committed but not yet billed. Approved supplier invoices supply money going out with real due dates. Recurring items carry the overheads that land whether the jobs claim or not. A client payment lag setting moves each expected receipt from the day the claim is issued to the day the money realistically arrives. And GST and BAS timing sits on the remittance cycle, so the line does not treat tax you are holding as cash you can spend.
It is a planning instrument for running the business, not financial advice, and it does not replace your accountant or your accounting ledger. What it removes is the lag between the state of your jobs and the state of your forward view.
02 / Why it matters
Why builders need it
Builders fail on cash, not margin
Insolvencies in construction cluster around businesses with work in hand. Profit is settled at the end of a job; wages, trades and suppliers are settled this week, and only cash covers that.
You fund the gap on every stage
Trades are paid on their terms mid-stage, and the claim for that stage cannot be issued until the stage completes. That gap is financed by the builder, on every stage, of every open job, at once.
A hand-built forecast starts decaying immediately
The moment a stage moves, an order is raised or an invoice is approved, a spreadsheet built yesterday is describing a business that no longer exists. Nothing warns you; it just gets quietly wrong.
Committed money is invisible in a ledger
An order placed today is cash leaving in three weeks, but it has no invoice yet, so accounting software cannot see it. A forecast that ignores committed cost understates the outflow you already caused.
Late claims move the whole cycle
A claim lodged three weeks after the stage finished is a three-week interest-free loan to the client that nobody priced. The trades falling due in the middle do not slip with it.
GST feels like cash until BAS
The GST collected on a claim sits in the account looking spendable and is owed on the reporting cycle. Modelling the remittance stops the balance between BAS dates from flattering the position.
03 / The VIABUILD way
How VIABUILD handles it
Arithmetic over your records, recomputed every time you read it.
The forecast is deterministic. It is addition and subtraction over dated records, with the payment lag and the BAS cycle applied as timing rules, and the calculation is covered by tests. The same inputs always produce the same forecast, and you can trace any week on the line back to the specific claims, orders and invoices that put it there. No model is guessing at your cash. Plenty of tools market AI prediction here; the honest and more useful thing is a number you can audit, because a forecast you cannot explain is a forecast you will not act on.
Currency comes from where the figures live, not from a refresh cycle. Money surfaces are computed from the source records at the moment you read them, so the forecast is never a stored snapshot that has to be kept in step with the jobs. Raise a purchase order this morning and the committed outflow it creates is in the line the next time the line is drawn. That is the mechanical difference between a spreadsheet and a computed forecast: a spreadsheet is a picture of a moment somebody chose, while a computed forecast is current because the records are current.
The money-in side is tied to real site progress rather than to somebody remembering. A progress claim can be linked to a schedule phase, and when that phase’s tasks reach completion the claim flips to ready and you are told it is ready to send. Approved variations create their progress claim ready to send as well, so extra work you have already built does not sit unclaimed while its cost is already paid. Cash coming in follows work actually finished, which is exactly how progress claims are supposed to behave under an Australian residential contract.
- Weekly forecast from claims, POs, invoices and overheads
- Client payment lag applied to every expected receipt
- GST and BAS timing modelled on the remittance cycle
- Deterministic arithmetic, tested, no AI prediction
- Recomputed from source records on every read
- Claims tied to schedule phases, not to memory
04 / The workflow
How it runs, step by step
- 01
Set the claim schedule and the payment lag
The contract stages and amounts give the money-in events. The client payment lag setting says how long it actually takes for a claim to become money in the account.
- 02
Tie claims to schedule phases
Link a progress claim to the phase that earns it, so the claim date is driven by the programme rather than by whoever remembers to raise it.
- 03
Site progress flips the claim to ready
When the phase’s tasks reach completion, the claim moves to ready and you are told it is ready to send. Approved variations arrive with their claim already ready.
- 04
Orders and invoices place the outflows
Open purchase orders carry committed money going out; approved supplier invoices carry money going out with dates. Both land on the line at their own timing.
- 05
Recurring items and BAS land regardless
Wages, insurances, rent and repayments run whether the jobs claim or not, and the GST and BAS remittance falls on the reporting cycle. Both are carried as their own outflows.
- 06
Read the weekly line and decide
Open the forecast and the figures are recomputed from the records behind them. The decisions it enables, bring a claim forward, slow a start, ask for terms early, all need weeks of notice.
05 / FAQ
Common questions.
No, and that is deliberate. The forecast is deterministic arithmetic over your own records: claims, open purchase orders, approved invoices, recurring items, the client payment lag, and GST and BAS timing. The same inputs always produce the same forecast, the calculation is covered by tests, and every week on the line can be traced back to the records that produced it. Oryn does a great deal elsewhere in VIABUILD, including reading and coding supplier invoices, but it does not invent this number. A cash forecast you cannot audit is one you will not act on.
The money figures are computed from the source records every time they are read, so there is no stored forecast that has to be kept in step with the jobs. Approve an invoice or raise a purchase order and it is in the next reading of the line. This is the mechanical advantage over a spreadsheet: a hand-built forecast is a snapshot of the moment somebody built it, while a computed forecast is current because the records it reads are current.
It moves each expected receipt from the date a claim is issued to the date the money realistically arrives. Between those two dates sits assessment, bank drawdown and the client’s own habits, and a forecast that books the receipt on the issue date is optimistic by exactly that gap on every claim. Setting the lag to what your clients actually do, rather than what the contract allows, is the single change that makes most builder forecasts honest.
No. There are no bank feeds, and it does not project your bank balance. It forecasts job cash movements: what your jobs are expected to bring in and what they are committed to paying out, week by week. Your accounting ledger holds the bank position and the statutory reporting, and the Xero integration keeps invoices and claims consistent between the two. The forecast answers a different question, which is what the jobs are about to do to your cash.
GST and BAS timing is modelled, so the remittance appears as its own outflow on the reporting cycle rather than hiding inside a healthy-looking balance. That matters because the GST collected on a progress claim spends exactly like revenue right up until the day it is owed, which is how otherwise well-run builders get caught by a quarter they always knew was coming. Reporting cycles and treatments differ between businesses, so confirm your own with the ATO or your accountant; this module is an operational planning tool, not financial or tax advice.
Cost tracking answers whether a job will make money: budget against committed against actual, per cost line. Cash flow forecasting answers when the money moves: which week each receipt and each payment lands in. They read overlapping records and they answer opposite failure modes. A job can be tracking perfectly to budget and still put the business under, because the costs of a stage are paid before the claim for that stage is collected.
06 / Keep reading
Related features & guides
See the gap while you still have moves.
Start with 7 days free: the whole operating system, real data. $199 for your first month, then $555/mo. Set up a real job with its claim schedule and payment lag, and read a weekly forecast computed from the records rather than rebuilt by hand.