How to Build a Group Cash Flow Forecast Across Multiple Entities

Quick answer

A group cash flow forecast needs seven things: receipts modelled by project and milestone rather than by invoice date, payables split into committed and uncommitted, payment mode held as its own dimension, recurring operating expenses generated rather than collected, bank balances reconciled by rule rather than by manual tagging, movement commentary drafted from the data, and validation rules that run before anyone senior sees the number. Miss the payables split and the forecast will be wrong in the one direction that matters.

Why a group forecast is harder than a single-entity one

A single-entity cash flow forecast is mostly arithmetic. You know your receivables, you know your payables, you know when payroll runs, and the balance you are forecasting from is one number you can read this morning.

A group forecast breaks all four of those assumptions at the same time. The opening balance is a dozen balances in several currencies. Receivables sit against contracts that bill on milestones rather than on months. Payables are divided between what has actually been committed on a purchase order and what a supply chain team merely intends to buy. And the person assembling the forecast controls none of the inputs, because they belong to finance teams in other countries who have their own close to finish.

So most groups end up in the same place: a large shared workbook, a weekly deadline, and a number that the leadership team half believes. The workbook is not the problem. The problem is that a workbook has no way to tell you that something is missing.

A worked example: five countries, 114 hours a month

The structure below comes from a discovery session with a Singapore-headquartered group that designs, manufactures and installs modular cold rooms and insulated panel systems across Southeast Asia. It runs a regional plant in Vietnam and sales and installation operations in neighbouring markets, on SAP Business One, with roughly 100 staff.

Every week the CEO and the department heads reviewed the group cash position. Behind that meeting sat a six-month rolling forecast at daily granularity, maintained by hand by finance teams in five countries. The manufacturing entity alone consumed more than 80 hours a month. Across three preparers and two reviewers the total came to roughly 114 hours a month, to produce one report.

The interesting part is not the hours. It is which half of the model was breaking.

From the discovery session

We know what the cash flow should look like. The problem was that the AP side was not reliable, so we would end up making urgent payments that were never in the forecast.

That sentence describes almost every group cash flow forecast we have seen. Receipts get attention because they are the number the business wants to talk about. Payables get whatever time is left, which is why the forecast is accurate right up to the week it matters.

Step 1. Model receipts by project and milestone, not by invoice date

In a project business, revenue is not recognised on a schedule that has anything to do with when cash arrives. A supply-and-install contract bills on milestones: deposit on order, progress on shipment, the balance on completion and sign-off, with retention held behind that. One project therefore appears on many forecast lines, each with its own payment terms, its own status, and its own currency.

Two rules make this tractable. First, the forecast line is the milestone, not the project and not the invoice. Second, the milestone carries the project status, because a milestone on a project that has slipped two months is not a receipt next month, however firm the contract looks.

Local currency in, group currency out. If your entities bill in their own currencies, translate at the forecast layer rather than asking five teams to convert before they submit, or you will spend the review arguing about rates instead of about cash. The mechanics of that translation are the same ones you need for reporting, which we cover in the multi-currency consolidation guide.

Step 2. Split payables into committed and uncommitted

This is the step that decides whether the forecast works, and it is the one most groups skip.

Committed payables are obligations that already exist in a system. A purchase order has been issued, a supplier has been chosen, terms are known. These should never be typed into a forecast by a human, because the ERP already holds them. Read the open purchase orders, apply the payment terms from the supplier master, and let the forecast populate itself.

Uncommitted payables are what the business intends to buy but has not yet ordered. Supply chain knows about them. Finance usually does not. There is no system of record to read, so the only options are to collect them through a structured form with an approval step and automated reminders, or to be surprised later.

Once you have made that split, add the things that ride along with a purchase and are routinely forgotten: import duty, VAT or GST, freight forwarding, and agent or sales commissions. In a group that imports raw materials just in time, those items are not rounding.

Why this matters most

When an entity misses a payable, nothing in a spreadsheet objects. The forecast simply reads better than reality, and the business discovers the gap through an urgent payment nobody planned. Committed payables sourced from purchase orders remove the human step where that failure happens.

Step 3. Make payment mode a dimension

Not every payable is a cash payment. Many groups settle a large share of supplier obligations through trade facilities, letters of credit or supplier financing, and those obligations hit cash later, on their own repayment schedule, in a different amount.

At the manufacturing entity in our example, the majority of supplier payments went through trade facilities rather than cash. A forecast that treats every payable as cash out on terms therefore overstates next month's cash requirement and understates the month the facility matures.

The fix is structural rather than clever. Hold payment mode as a dimension alongside entity, project and period, with members for cash, trade facility, forwarder and services. Then the true cash requirement and the facility utilisation are two views of one set of numbers, and the finance lead can answer "how much cash do we actually need" without rebuilding anything.

Step 4. Generate recurring operating expenses instead of collecting them

Payroll, rent, professional fees, insurance and software renewals are predictable, repetitive and, in most groups, re-entered every cycle by somebody. They should be generated from a recurring schedule, with human input reserved for one-offs and for changes.

This is the least interesting step and one of the most valuable, because it removes a large block of routine keying from five finance teams without any judgement being lost. A bonus accrual or a one-off legal fee still needs a person. Rent does not.

Step 5. Reconcile to the bank with rules, not with tags

Here is the constraint that surprises people: bank statements carry no project information. If you want project-level cash to tie back to the bank, somebody has to connect each receipt and payment to a project, and in a manual model that somebody does it line by line, every week, in every entity.

Import the statement instead and match by rule. Reference formats, counterparty names, amounts against expected milestones and open purchase orders will resolve the large majority of lines on their own. Finance then reviews the exceptions, which is a fundamentally different job from tagging everything.

Two things to get right. Rules need to be visible and editable by the finance team rather than buried in a configuration nobody can see, and the unmatched queue has to be a real queue with an owner, or it becomes a place where problems go to be forgotten.

Step 6. Draft the weekly movement commentary from the data

Every weekly cash meeting wants the same thing before it starts: what moved since last week, and why. In a manual model somebody produces that by comparing last week's forecast against this week's actuals line by line, which is both the least enjoyable hour of the week and the easiest to skip when the week is busy.

The comparison is arithmetic, so it should be generated. What moved in receipts, what moved in payables, what moved in facility repayments, and which projects account for the difference. A drafted commentary that a controller edits is a better use of a controller than a blank page, and the same argument applies to the narrative in your monthly management report.

The judgement stays with the person. What the model removes is the reconstruction.

Step 7. Validate before anyone sees it

A group forecast assembled from five entities needs to check itself before it reaches a CEO. At a minimum:

• Missing entries. An entity that has submitted nothing this cycle, or a project with revenue and no cost, should be flagged rather than silently treated as zero.
• Zero and negative values in fields where they make no sense.
• Out-of-range movements. A line that has moved by an order of magnitude since last cycle is usually a keying error, and occasionally the most important thing in the forecast.
• Opening balance ties to the bank. If the starting point is wrong, everything downstream is decoration.

Validation is what converts a forecast from a document into a control. It is also the cheapest part of the build.

Choosing a horizon and a granularity

Groups often argue about this for weeks. Two observations from practice.

Granularity should follow the decision, not the data. Daily granularity earns its cost inside the window where you would actually act, which for most groups is the next four to six weeks, because that is where a payment run gets moved or a facility gets drawn. Beyond that, monthly is enough, and daily detail creates work without changing a decision.

Horizon should follow your obligations. Six months is common because it covers a facility renewal cycle and a full project billing sequence. If you have covenants to test or a refinancing ahead, extend to cover it.

Run one model with both. A forecast that is daily near term and monthly further out is one structure with two views, and it should never be two files.

Five ways a group cash flow forecast goes wrong

• The payables side is manual. Everything else can be automated and the forecast will still miss, because the misses come from obligations nobody entered.
• Trade finance is treated as cash. The forecast is then wrong in both directions at once, too pessimistic now and too optimistic later.
• Project cash does not tie to the bank. Two sources of truth appear, and the meeting becomes a reconciliation.
• One person owns the workbook. It works until they take leave, and the concentration is invisible until the week it is not.
• There is no record of what changed. Without a movement view, a forecast cannot be held to account, and a forecast nobody is accountable for drifts.

Where this sits next to consolidation

Cash forecasting and statutory consolidation pull on the same data and are usually built as separate projects, which is how a group ends up maintaining two entity structures, two chart of account mappings and two sets of currency rates.

If you are choosing a platform for either, look at whether one model can carry both. We compare the options for multi-entity groups in the best multi-entity consolidation software, and the elimination mechanics that sit underneath a group position are set out in the intercompany eliminations guide.

For manufacturing groups specifically, where standard cost, transfer pricing and plant-level margin sit in the same model as the cash position, see Planir for manufacturing.

Frequently asked questions

How far ahead should a group cash flow forecast run?

Six months is the common answer for a group with trade facilities and project billing, because it covers a full facility cycle and a complete project billing sequence. Run daily granularity only inside the window where you would actually change a decision, which is usually the next four to six weeks, and monthly beyond that. If you have covenants to test or a refinancing ahead, extend the horizon to cover it.

What is the difference between committed and uncommitted payables?

Committed payables are obligations that already exist in a system, typically an issued purchase order with a chosen supplier and known payment terms, so they can be read out of the ERP rather than entered by hand. Uncommitted payables are purchases the business intends to make but has not yet ordered, which exist only in supply chain plans and have to be collected through a structured form with an approval step.

Why does payment mode need to be separate from the payable?

Because not every payable becomes cash out on supplier terms. Obligations settled through a trade facility, a letter of credit or supplier financing hit cash later and in a different amount, on the facility repayment schedule. Holding payment mode as a dimension lets you read the true cash requirement and the facility utilisation from the same numbers instead of maintaining a second working.

How do you tie project-level cash back to the bank?

Bank statements carry no project information, so the connection has to be made somewhere. Doing it by hand means tagging every receipt and payment to a project in every entity every week. The alternative is to import the statement and match by rule on reference formats, counterparty names and amounts against expected milestones and open purchase orders, then review only the exceptions.

Can we build this in Excel?

You can, and most groups do at first. What Excel cannot do is tell you that an entity forgot to submit its payables, apply supplier terms to purchase orders automatically, or keep a movement history you can hold people to. Those are the three failures that make a group forecast untrusted, and they are properties of the tool rather than of the team using it.