Consolidation Failures Are Sequencing Failures: The Case for a Fixed Process Order

When a group close goes wrong, the diagnosis usually lands on one of three things: the data was late, the accounting was wrong, or someone made an error. These are satisfying explanations because they are specific, they point to a responsible party, and they suggest a concrete fix. Get the data earlier. Train the team. Build a better check.

Most of the time, the diagnosis is wrong.

Late closes, restatements, and audit queries in group consolidation share a root cause that sits one level deeper than any of those three. The data was probably available. The accounting was probably correct. The team is probably competent. The failure happened because the steps of the consolidation ran in an order that allowed an error to enter the calculation at one point and propagate forward unchecked to every step that depended on it — and there was no gate in the process designed to catch it before it reached the output.

This post makes the case that consolidation failures are, at their root, sequencing failures — and that a fixed process order is not a nicety or a best practice but a structural requirement for a close that is reliably correct, reliably on time, and reliably defensible under audit.

What “Consolidation Failure” Actually Means

The term is worth defining precisely, because finance teams use it to describe situations of very different severity. A consolidation failure is any outcome where the group accounts do not accurately represent the group’s financial position — whether that inaccuracy is discovered internally before publication, by auditors after fieldwork begins, or by management when comparing this period’s accounts to the prior period and finding movements that have no business explanation.

Under this definition, a consolidation failure includes the close that required three additional days to reconcile a balance sheet that should have balanced from the start. It includes the goodwill figure that was restated six months after the original close when someone noticed the acquisition-date net assets had been calculated from a trial balance that still contained an unreconciled intercompany balance. It includes the audit query that consumed four weeks of finance team time because the auditor could not reconstruct the CTA schedule from the working papers, because the working papers did not document the sequence in which the translation steps had been applied.

None of these is primarily an accounting failure. The accounting, in each case, was probably technically correct. The failure is a process failure — specifically, a failure to control the order in which steps ran and the quality of the inputs at each step before subsequent steps could begin.

Three Types of Sequencing Failure

Sequencing failures in consolidation take three distinct forms. Each produces a different symptom, but all three share the same structural origin: a process in which steps can run before their prerequisites are met.

Type 1: Wrong order

The most common sequencing failure is running a dependent step before the step it depends on is complete. The textbook case is calculating goodwill before intercompany balances are reconciled — using a subsidiary’s net assets as the denominator in a goodwill calculation when those net assets still contain an intercompany receivable that the other party is reporting at a different figure.

The consequence is not that goodwill is obviously wrong. It is that goodwill is calculated from an input that was not yet finalised, and the goodwill figure carries that uncertainty forward into every period that inherits it as an opening balance. When the intercompany balance is eventually agreed — in this period’s reconciliation, or next period’s — the agreed figure is different from the figure that was used in the goodwill calculation, but the goodwill calculation is not revisited. A residual lives in the accounts that has no business explanation, and which will resurface periodically as an unexplained movement.

For groups with foreign subsidiaries, wrong-order sequencing creates a second category of error: translation steps that run before eliminations, pulling intragroup balances into the CTA calculation. The CTA is then built on a net asset figure that includes items that should have been eliminated, and the translation difference is overstated by the FX effect of those intragroup items. Our guide to how to calculate the cumulative translation adjustment covers the correct sequence — eliminations before translation — in detail.

Type 2: Missing gate

A missing gate is a step that was supposed to happen but was skipped — usually under time pressure, and usually with the intention of “going back to it later.” Going back to it later means the step’s outputs are available only after subsequent steps have already been built on the assumption that those outputs existed and were correct.

The most consequential missing gate is the intercompany reconciliation. When intercompany balances are not formally agreed before elimination entries are built, the eliminations run against two figures that do not correspond. The group balance sheet does not balance. The response — a manual balancing entry, a rounding adjustment, a plug — closes the balance sheet but embeds an unexplained balance that carries forward into the next period as part of the opening position.

Over several periods, a series of missing-gate patches accumulates into an opening position that cannot be reconstructed from the underlying transactions. This is the state that produces the worst audit outcomes: a finance team that knows their current-period accounting is correct but cannot demonstrate the integrity of the opening position from which it starts. Understanding why intercompany balances fail to agree in the first place — and how to eliminate the disagreement structurally rather than patching it — is covered in our guide to why intercompany balances never match.

Type 3: No sequence at all

The third type of sequencing failure is the absence of a documented process order entirely — a close that runs differently each quarter depending on which data arrived first, which team member started first, and which problem appeared most urgent to resolve. This is more common than finance teams acknowledge, because a close that has always produced approximately correct results does not obviously require a documented process. The process is implicit in the people who run it.

The risk of an implicit process is that it varies in proportion to variation in the team. A new team member who starts with the eliminations because the intercompany schedules arrived first is not making an error — they are working sensibly with what they have. The result is a close that looks different from the one run by the experienced team member who knew (implicitly, without it being written down) that eliminations had to wait for reconciliation. Both closes are produced by teams trying to do the right thing. One produces a clean output. The other produces a late adjustment that the experienced team member makes to “fix” it — without documenting why the fix was needed, ensuring it will be needed again.

An implicit process is a process that works only while the people who carry it in their heads are present. It is also a process that cannot be audited, because there is nothing to audit — only the output, and an output without a documented sequence is not defensible in the way an output with one is.

How Sequencing Failures Propagate: A Worked Example

To make the propagation mechanism concrete, consider a five-entity group executing a quarterly close. The sequence for the quarter runs in this order, as it often does under time pressure: elimination entries first (because the intercompany schedules arrived and the preparer wanted to make progress), then intercompany reconciliation (because the other entity’s data arrived late), then net assets and goodwill, then CTA, then NCI split, then consolidated output.

At the elimination step, Entity A’s intercompany receivable from Entity B is £640,000. Entity B’s intercompany payable to Entity A is £610,000. The £30,000 difference is not yet investigated — reconciliation has not run. The elimination entry removes £610,000 (the lower figure) and leaves £30,000 sitting as an unexplained intercompany receivable in Entity A’s balance sheet.

When intercompany reconciliation subsequently runs and determines the agreed figure should be £610,000, the £30,000 in Entity A is identified as an error in Entity A’s trial balance submission. The trial balance is corrected. But the elimination entry already ran against the original £640,000 figure — and was only applied to £610,000. The corrected trial balance now has a net asset figure that is £30,000 lower than it was when goodwill was calculated, meaning the goodwill figure is slightly wrong. The CTA calculation used the pre-correction net assets, so the CTA is slightly wrong in the direction of the FX rate applied to £30,000 at the closing rate. The NCI split applied to the pre-correction profit produces an NCI balance that is slightly wrong by the minority’s share of the £30,000 correction.

None of these errors is large. Together they require the preparer to make four small corrections after the output is assembled — adjusting goodwill by an immaterial amount, correcting the CTA, repointing the NCI, and re-running the consolidated P&L to pick up the corrected trial balance. The close finishes three hours later than it would have if reconciliation had run before eliminations. In those three hours, the CFO has sent two emails asking where the draft accounts are.

Now run this process in the correct order: reconciliation first, then eliminations, then net assets and goodwill (from agreed data), then CTA (from eliminated net assets), then NCI split (from the goodwill-adjusted and CTA-adjusted figures). The £30,000 discrepancy surfaces at the reconciliation step, is resolved in twenty minutes, and the agreed figure of £610,000 flows cleanly through every subsequent step. No late corrections. No four-step rework. No CFO emails. The close is on time because the sequence was right — not because the team worked faster.

Step	Wrong sequence (eliminations first)	Correct sequence (reconciliation first)
Intercompany elimination	Runs on unreconciled data (£640k vs £610k). £30k residual left uneliminated.	Runs on agreed data (£610k). Full elimination, no residual.
Intercompany reconciliation	Identifies £30k error after elimination has already run. Requires correction and re-run.	Runs first. Agrees £610k before any dependent step begins.
Goodwill	Calculated from pre-correction net assets. Wrong by £30k.	Calculated from agreed net assets. Correct.
CTA	Uses pre-correction, pre-elimination net assets. Wrong by FX of £30k.	Uses eliminated, agreed net assets. Correct.
NCI split	Applied to wrong net assets. Wrong by minority % of £30k.	Applied to correct net assets. Correct.
Late corrections required	4	0
Extra time spent	~3 hours	~20 minutes (reconciliation itself)

Why More Checks Don’t Fix a Sequencing Problem

The common response to consolidation failures is to add more checks: more reconciliation columns in the spreadsheet, more cross-reference formulas, more review steps before sign-off. These additions reduce the probability that an error reaches the output undetected. They do not change the order in which the steps run, and they do not prevent an error from entering the calculation at a step whose inputs were not yet finalised.

A cross-check that runs after an error has already propagated through four dependent steps does not undo the propagation. It identifies the final expression of the error — the output that does not balance, the figure that does not reconcile to prior period — but by the time that check fires, the error is already embedded in goodwill, CTA, NCI, and the elimination entries. The rework required is proportional to how far the error has travelled, not to how early the check was placed.

The only intervention that prevents propagation is a gate: a formal point at which a step’s output is verified and locked before the next step is permitted to begin. A gate is not a check — a check confirms that a number matches another number. A gate confirms that a prerequisite condition has been met and certifies that the next step may now safely proceed. The difference is structural: a check operates within a sequence; a gate controls whether the sequence advances.

More checks in a bad sequence produce more checkpoints at which you discover you are in the wrong state. Only a fixed sequence with enforced gates prevents you from reaching those checkpoints in the wrong state in the first place.

What a Fixed Process Order Actually Guarantees

A fixed process order does not guarantee that the accounting is right. It does not prevent an entity from submitting a trial balance with an error in it, or a team member from applying the wrong FX rate. What it guarantees is something more specific and more valuable: that any error in the inputs is caught at the earliest possible point, by the step that directly depends on that input, before any subsequent step can consume the wrong value.

This is the property that makes a fixed process order worth building and enforcing. Not that it makes the team infallible, but that it makes errors cheap. An error caught at reconciliation — the second gate in a fixed five-step sequence — requires a correction to a single input and a clean run through the remaining steps. An error caught at the output — because there was no fixed sequence — requires the same correction to the same input plus the unwinding of every step that consumed the wrong value. The correction is the same in both cases. The cost is orders of magnitude different.

A fixed process order also guarantees something auditors value highly and finance teams often underestimate: a documented sequence that can be reconstructed, reviewed, and tested independently of the team that ran it. An auditor examining a consolidation working paper that shows “Intercompany reconciliation signed off [date/name] → Eliminations built from reconciled figures [date/name] → Net assets calculated [date/name]” is not looking for errors in the same way as an auditor presented with a spreadsheet that has a correct output but no documented sequence. In the first case, the auditor can test whether the sequence was followed. In the second, the auditor must reconstruct the sequence from the arithmetic — a substantially more expensive exercise that finance teams pay for in extended fieldwork.

For groups building a fixed process sequence for the first time, the BrizoConsol BRIZO methodology provides the five-phase framework: Bring Data Together, Reconcile Relationships, Integrate Adjustments, Zero Group Effects, Output Group Financials. Each phase is both a step in the sequence and a gate that must close — with explicit sign-off — before the next phase begins. The methodology is designed specifically so that the error-propagation scenarios described above cannot occur: reconciliation (R) must complete before any adjustment or elimination step begins, ensuring that goodwill, CTA, NCI, and elimination entries are all built from agreed data.

Our intercompany reconciliation guide covers the mechanics of the R phase in detail — how to build an intercompany matrix across multiple entity pairs, how to agree discrepancies before they become late-stage rework, and how to lock reconciled figures so that no downstream step can consume an unreconciled balance. The multi-entity month-end close checklist maps the five phases to practical sign-off checkpoints that can be adopted immediately without a full system change.

The Argument, Stated Plainly

Group consolidation is a dependent process. Every step requires something from a previous step. When that dependency is respected — when a step cannot begin until its prerequisite is complete — errors are contained to the step where they entered. When the dependency is violated — when steps run in whatever order is convenient — errors travel forward through every step that depends on the wrong input, compounding as they go.

Consolidation failures are the outcome of violated dependencies. They are sequencing failures. The consolidation team is usually competent; the accounting is usually technically correct; the data is usually sufficient. What is missing is the structural control that prevents a competent team applying correct accounting to available data from inadvertently running steps in an order that allows a correctable input error to become an expensive output failure.

A fixed process order is that structural control. Not a better spreadsheet, not more checks, not a larger team. A sequence, documented, enforced by explicit gates, in which each step is permitted to begin only when its predecessor has been completed and certified. That is the case for a fixed process order — and it is the single most impactful change most group finance teams can make to their close without changing their accounting.

BrizoConsol enforces the sequence automatically

The BRIZO dependency gates are built into the product — each phase requires explicit sign-off before the next one opens, so the sequence is fixed by design, not by discipline. Start Free