One Reconciled Model Across 40 SPVs: Multi-Entity Consolidation for Vision 2030 Giga-Projects

A program director asks a simple-sounding question in a steering meeting: “What is our total committed capital across the whole project, and how much is drawn?” Three people open three different files. The numbers come back within about 4% of each other. Nobody can say which one is right. The meeting moves on, and the discrepancy quietly becomes the baseline for the next forecast.

That scene repeats across the Gulf’s largest construction programs. Saudi Arabia’s giga-projects do not run as single legal entities. NEOM alone operates through a stack of subsidiaries: NEOM Company as master developer, ENOWA for energy and water, NEOM Investment Fund as the co-investment gateway, plus joint ventures like the roughly $8.4 billion green hydrogen company with ACWA Power and Air Products, and a logistics JV in which DSV holds 49%. The five anchor giga-project companies (NEOM, Red Sea Global, Qiddiya, Diriyah, and ROSHN) are each wholly owned by the Public Investment Fund, and each spins up its own project companies and special-purpose vehicles underneath. PPP and build-operate-transfer structures add more: every concession is its own SPV with its own lenders, its own security package, and its own reporting calendar.

So when someone says “the project’s finances,” they mean dozens of balance sheets that have to roll up into one view. That rollup is where AI is now being pointed. And it is exactly where AI breaks if you skip a step.

The consolidation problem is older than AI

Multi-entity consolidation has always been hard, for reasons that have nothing to do with technology. Intercompany loans between an SPV and its parent have to be eliminated, or you double-count debt. A JV consolidated at 51% has to be carved differently from one equity-accounted at 30%. Sukuk and Ijara financing sit on the books differently than a conventional term loan. Capital denominated in dollars, contracts settled in riyals, and equipment invoiced in euros all have to land in one presentation currency, on one set of FX rates, as of one closing date.

Get any of that wrong and the consolidated number is wrong: not by a rounding error, but by the size of an eliminated intercompany balance, which on a giga-project can run into the billions. Finance teams know this. It is why month-end close on a 40-entity program takes weeks and why the consolidation workbook is the most fragile, most fiercely guarded file in the building.

Now layer AI on top. The pitch is appealing: let a program director type “show me net debt by entity” or “what’s our blended cost of capital across the PPP concessions” and get an instant answer. The problem is what the AI is reading from.

Why pointing AI at the raw entities makes it worse

If you connect a language model directly to 40 trial balances, here is what happens. The model retrieves figures from each entity, then tries to add them, eliminate intercompany items, apply ownership percentages, and convert currencies, all as probabilistic text prediction. It is not running a consolidation. It is guessing what a consolidation should look like, token by token.

Two failure modes follow, and they are different.

The first is retrieval drift. Ask the same cross-entity question twice and you can get two different totals, because the model pulled slightly different source rows each time. On benchmarks built from real financial filings, frontier models answer only roughly half of realistic figure-finding questions correctly even on a single clean document. Stretch that across 40 documents with different chart-of-accounts structures and the error surface multiplies.

The second is reasoning error, and it is the dangerous one because the inputs are right. The model reads each entity’s debt correctly, then forgets to eliminate the intercompany loan, or applies a 51% consolidation factor to a line that should be 100%, or nets a JV the wrong way. The figure looks plausible. It ties to nothing. A controller cannot sign it, and an auditor will not accept it, particularly now that GCC regulators expect every reported figure to trace back to an audited source, with the UAE, for example, requiring audited statements within nine months of period-end.

You do not fix this with a better prompt. You fix it by changing what sits underneath the model.

Reconcile first, then let AI ask questions

The order matters more than anything else in this article. The reconciled model has to exist before the AI touches it.

That means connecting each entity’s ledger (whether it lives in SAP, Oracle, NetSuite, a local accounting package, or uploaded statements) into one model where the consolidation logic is encoded once and applied deterministically. Intercompany eliminations are rules, not guesses. Ownership percentages are stored per entity. FX translation runs on a defined rate table as of a defined date. Every consolidated figure ties back, line by line, to the source entity it came from. This is one reconciled source of truth, not 40 spreadsheets that happen to agree most of the time.

Once that layer exists, the AI’s job changes completely. It no longer computes the consolidation. It retrieves from a model that is already consolidated and already reconciled, and any calculation it needs (a blended cost of capital, a debt-service coverage ratio across concessions, a what-if on a delayed drawdown) runs through a deterministic engine, not the model’s own arithmetic. The language model handles the language: understanding the question, framing the answer, explaining the drivers. The math stays where math belongs.

The practical test is whether two people asking the same question on the same date get the same number, and whether that number traces to source. On a reconciled layer, it does. On raw entities, it cannot, no matter how good the model is.

What this buys a giga-project finance team

Speed, but the defensible kind. A program director gets a cross-entity answer in seconds instead of three people opening three files. A controller can show an auditor exactly which entity each line came from. Oversight bodies (and Vision 2030 programs have a lot of oversight) see one consistent set of numbers instead of variance they have to chase.

It also surfaces the gaps you actually want surfaced. When every entity rolls into one reconciled model, an entity that has not closed, an intercompany balance that does not net to zero, or a JV percentage that changed mid-year stops hiding inside a manual workbook. The reconciliation step makes the discrepancy visible instead of letting it propagate into the next forecast.

None of this removes the controller. The reconciliation rules, the ownership treatments, the elimination logic: those are professional judgments, and they should be set and reviewed by people who own the close. What the layer removes is the silent arithmetic error and the question of which file is right.

The honest limit: this is harder to stand up than a chatbot bolted onto your ERP. Encoding consolidation logic deterministically takes real work, and it depends on the underlying ledgers being connectable. But that work is the difference between an AI answer a program director can repeat in front of the board and one that quietly drifts 4% every time it is asked.

If you are running consolidation across dozens of SPVs and want to see what asking a cross-entity question against one reconciled model actually looks like, book a demo. For the wider regulatory picture this fits into, start with the pillar on building a trusted numbers layer for AI in the GCC, and on the traceability bar auditors now hold you to, read whether your AI can tie every number back to the audit and why adjusted-EBITDA math cannot be improvised under IFRS 18.