How to Build a 12-Week Rolling Cashflow for a Multi-Entity Business
A practical guide for founders and finance teams who have outgrown a P&L but don't yet have real cash visibility.
Most growing businesses have a P&L. Fewer have a balance sheet they trust. Almost none have a forward-looking view of cash.
That gap is where founders end up making three kinds of expensive decisions: paying a vendor on Friday and realising on Monday that payroll is short, taking on a capex commitment without seeing the 8-week consequence, or sitting on idle cash in one entity while another is overdrawing on its credit line.
A 12-week rolling cashflow solves all three. It is the single most useful operational finance tool a sub-$10M business can build — and it does not require new software, a CFO, or a clean ERP. It needs a structured workbook, a weekly cadence, and someone who treats it as a system rather than a report.
This article is the how-to. If you run finance for a multi-property, multi-entity, or transaction-heavy business, this is the structure I'd recommend you build before anything else.
Why 12 weeks, and why rolling
Twelve weeks is long enough to see a quarter ahead — including the next VAT or GST cycle, the next two payroll runs, and most major recurring obligations — but short enough that you can forecast at week-level granularity without it becoming fiction.
Rolling matters more than the number. A static 12-week forecast prepared once a quarter is a report. A rolling forecast that drops the oldest week and adds a new Week 12 every Monday is a system. The first goes into a folder. The second changes decisions.
The discipline of rolling it weekly forces three things:
- You compare last week's forecast to actuals before re-forecasting (which is the only way the forecast gets more accurate over time).
- Your team builds a Monday cadence around finance, not the other way around.
- You always have a fresh view in front of the founder — not one from three weeks ago.
The architecture
A workable 12-week cashflow is not a single spreadsheet. It is a small, opinionated system of linked sheets. The structure I use across hospitality, e-commerce, and services clients looks like this:
- Assumptions sheet — entities, opening bank balances per account, properties or revenue units, global parameters (OTA payout lag, card settlement lag, payroll cycle, statutory filing frequency, variance tolerance).
- Cashflow_12W — the main view: opening bank balance → inflows → outflows → net cashflow → closing bank → minimum cash threshold → headroom → status flag (OK / WATCH / BREACH).
- Inflows_Detail — revenue collections broken down by property and channel, because aggregated revenue lines hide the actual collections risk.
- Outflows_Detail — costs by category, vendor, and entity, so the model answers not just "what" but "who is paying for it."
- Payables_Tracker — the invoice-to-payment register that drives scheduled AP into the main cashflow.
- Recurring_Obligations — the master list of fixed recurring payments, because the obligations a business misses are almost always the ones nobody remembered to add.
- Variance — forecast vs actual for the most recent closed week, with automated flags on any line beyond tolerance.
- Dashboard — a one-page founder view with KPI tiles and trajectory charts.
- SOP — the weekly cadence document that lets a junior associate run the refresh end-to-end.
Notice what is not on that list: revenue forecasts by SKU, P&L by department, monthly MIS, scenario models. Those belong elsewhere. A cashflow tool gets diluted the moment you try to make it do everything.
How the model actually works
The mechanical structure matters more than the line items. Three rules:
Opening balance for Week 1 links from the Assumptions sheet. Opening balance for Weeks 2 through 12 links from the prior week's closing balance. This means a change to any input — a delayed OTA payout, a new vendor invoice, a rescheduled payroll — flows automatically through to every subsequent week. If your model needs manual updates to roll forward, it is not a system; it is a report.
Minimum cash threshold is a hard input, not a calculation. Every entity has a floor below which cash cannot fall — usually a multiple of fixed monthly obligations, or a covenant on a banking facility. The model should subtract this floor from the closing balance to show real headroom, not gross cash. A business with AED 500K in the bank and AED 450K of obligations due in 10 days does not have AED 500K of cash.
Status flags are automated. OK, WATCH, BREACH — driven by formulas, conditional formatting in colour, no human judgement at the data layer. The judgement happens above the model, not inside it.
What goes into inflows
The mistake most operators make is forecasting inflows in one line: "Revenue." For a multi-channel business that line is meaningless, because the timing of cash is completely different from the timing of revenue recognition.
In hospitality, for example, the inflow lines that matter are:
- Direct collections (walk-in, phone, website) — same-day or T+2 on card settlement.
- OTA payouts — Booking.com typically settles 15 days after checkout, Expedia around 30 days, Agoda variable.
- Corporate and events — contracted, predictable, but lumpy.
- F&B collections — daily, but with delivery aggregators creating a 7-day settlement lag.
- Ancillary income — spa, parking, retail.
Each of these has its own timing profile. Treating them as one line means the model cannot help you spot a problem in any single channel.
The same logic applies in other industries. E-commerce: marketplace payouts vs Shopify settlements vs B2B invoiced sales. Services: retainer invoices vs project milestones vs expense reimbursements. The principle is the same — model the timing where the timing actually lives.
What goes into outflows
Outflows need three groupings, not one:
Operating costs — payroll, COGS, consumables, utilities, rent, marketing, repairs, SaaS, petty cash, corporate card settlements. Most of these are weekly or monthly and reasonably predictable once you have three months of history.
Statutory and tax — VAT, GST, corporate tax instalments, trade licence renewals, labour-related payments. These are infrequent but large, and they are the most common cause of cashflow surprises. Every one of them should be a line in Recurring_Obligations with a next-due date.
Financing and capex — loan EMIs, lease payments, owner draws, inter-entity transfers, planned capex. These are the discretionary lines where founders make the worst decisions when they cannot see the consequence eight weeks out.
The weekly cadence
The model is only half of the system. The other half is the Monday routine that keeps it alive.
A workable cadence looks like this: bank balances pulled and Assumptions updated by 9:00 AM, AP ageing and payables tracker refreshed by 9:30, inflows and outflows updated by 10:00, variance and status reviewed by 10:15, dashboard PDF posted to the leadership channel by 10:30. Forty-five minutes, every Monday, run by a junior associate with the consultant or finance head doing the review pass.
If the cadence takes longer than 45 minutes after the first four weeks, something is wrong with the inputs — usually a data source that has not been properly integrated, or a recurring obligation that is being re-entered manually each week instead of pulling from the master list.
What this replaces
A 12-week rolling cashflow, run properly, removes about 80% of the cash-related questions a founder asks the finance team in any given week. "Can we pay this invoice?" becomes "the model already scheduled it." "Do we have cash for the refurb?" becomes "yes, but it pushes us into WATCH in Week 6 — let's defer two weeks." "Why was last month tight?" becomes "you can see it in the variance sheet from four weeks ago."
That is the real outcome you are buying. Not a spreadsheet. A reduction in founder dependency on finance for cash decisions.
Where to start
If you do not have something like this today, you do not need to build all ten sheets at once. The order that works is: Assumptions and Cashflow_12W first (get one entity working end-to-end), then Payables_Tracker and Recurring_Obligations (because they are the highest-failure-rate inputs), then Inflows_Detail and Outflows_Detail (the drill-downs), then Variance and Dashboard (the review and communication layers), and SOP last (you cannot SOP something that does not yet have a stable shape).
Expect six to eight weeks to get a multi-entity business onto a clean rolling cadence. Less than that and you are probably skipping the variance discipline that makes the forecast actually improve over time.
A working reference workbook with all ten sheets — Assumptions, Cashflow_12W, Inflows_Detail, Outflows_Detail, Payables_Tracker, Recurring_Obligations, Variance, Dashboard, SOP — is attached to this article as a downloadable Excel file. It is the same structure I deploy on client engagements, and it is configured for a multi-entity hospitality business with placeholder data you can replace with your own. If you would like help adapting it to your operations, get in touch at caram@rtaparia.com.