Testing your consolidation engine? Here's an IFRS 10 / IAS 21 reference dataset.

If you've built a consolidation engine — or you're testing one your firm bought from a vendor — you know the QA problem: it's hard to find a test dataset that exercises every corner case without exposing client data. Most internally-built test groups have one foreign sub, one NCI scenario, and a couple of IC pairs. Real groups have all four NCI flavours, multiple ownership tiers with mixed-currency exposure, equity-method investees with their own complex capital structures, and IC counterparties spread across four currencies. This post describes a synthetic reference dataset designed specifically to exercise those corners.

Why most consolidation test data is wrong

Three structural problems with hand-built consolidation test data:

**Independent ledgers.** When you generate two entity ledgers independently and then 'consolidate' them, IC payables don't match IC receivables. Most QA teams paper over this by hardcoding a few matched IC pairs. The result: a test group with 5 IC transactions, all matched, when a real group has thousands with realistic match-rate variability.

**Hand-plugged FX.** Synthetic CTA in test data is almost always a single round number rather than a derived figure. The period-end and average rates aren't internally consistent (USD/EUR period-end and EUR/CHF period-end don't compose to a sensible USD/CHF). Engineers debugging the consolidation engine can't tell whether their CTA arithmetic is right or wrong because the inputs aren't trustworthy.

**Single-shape NCI.** Test groups overwhelmingly have one NCI scenario — typically a partly-owned full-consolidation sub with no step-acquisitions, no equity-method affiliates, no fair-value investments. Real groups have all four scenarios coexisting. A consolidation engine that handles the test group passes regression but fails on the first real group with goodwill on a step-acquisition.

What you actually want: a test dataset where every transaction's provenance is documented, every elimination has a matched counterparty, every CTA derives from a triangulated FX matrix, and every NCI scenario gets a worked example. That's what the rest of this post designs.

The four NCI scenarios you must handle

Under IFRS 10 and the related standards, four NCI patterns coexist in real groups. A consolidation engine has to handle each correctly, and a test dataset should exercise all four to give you any confidence in the engine's behaviour.

Scenario 1: Full consolidation with NCI

Parent owns >50% (often 51%-99.99%) of a subsidiary. Full line-by-line consolidation: 100% of assets, liabilities, revenue, and expenses are aggregated. NCI is recognised as the non-owned proportion of net assets and net income. NCI is reported as a separate line in the equity section.

Reference dataset: 8 entities in this category, ownership %s ranging from 55% to 95%. Each NCI rollforward shows: opening balance, current-period earnings attribution (proportional share of net income), OCI movements (FX translation, available-for-sale revaluation), dividends declared to NCI, and closing balance. The rollforward ties to the consolidated balance sheet's NCI line item to machine precision.

Scenario 2: Equity-method (IAS 28)

Investor has significant influence (typically 20-50% ownership) without control. Equity-method accounting: investment is initially recorded at cost, then adjusted for the investor's share of post-acquisition net income / net loss / OCI movements. Dividends from the investee reduce the equity-method investment line. The investee's results are *not* line-by-line consolidated — only the investor's share of net income flows through.

Reference dataset: 5 equity-method investees with ownership ranging from 25% to 49%. Includes one with a documented control rebuttal (the investor has 49% ownership but contractually no control over operating policies — equity method despite the high ownership %). Each equity-method investment carries goodwill on initial recognition (acquisition-cost > acquired-net-assets share) and the dataset shows the goodwill being implicitly tracked (no impairment in the baseline scenario; an alternate scenario with impairment available).

Scenario 3: Fair-value (IFRS 9)

Investor has neither control nor significant influence (typically <20% ownership). Investment is carried at fair value with FVTPL or FVOCI treatment. No proportional consolidation, no equity-method tracking — just fair-value movements through P&L or OCI based on the IFRS 9 election.

Reference dataset: 4 fair-value investments at 5%-15% ownership. Two FVTPL, two FVOCI. Each has a fair-value rollforward: opening fair value, period-end fair value (driven by a synthetic price-feed), realised vs unrealised gain/loss split, and OCI vs P&L attribution.

Scenario 4: Step-acquisition

Investor's ownership crosses the control threshold during the period. The pre-acquisition investment (typically equity-method or fair-value) is remeasured to fair value at the acquisition date; the gain/loss flows to P&L; goodwill is computed on the full fair value of the acquired entity (not just the newly-acquired portion).

Reference dataset: one step-acquisition during the period. Pre-acquisition: 35% equity-method investment with 8M cost basis. Acquisition date: parent buys an additional 25%, taking ownership to 60%. The pre-existing 35% is remeasured to fair value (12M); the 4M gain flows to P&L. Goodwill is computed on the full fair value of the acquired entity at the acquisition date. The dataset shows the full step-up calculation, the P&L gain, and the resulting goodwill recognition.

Goodwill, bargain purchase, and impairment paths

Goodwill on consolidation arises when the consideration paid (plus the fair value of any pre-existing investment plus the NCI fair value) exceeds the fair value of the acquired identifiable net assets. Bargain purchase is the inverse: consideration < acquired-net-assets, gain to P&L immediately. Impairment is the post-acquisition adjustment when goodwill's recoverable amount falls below its carrying value.

Reference dataset: each acquisition in the dataset has a documented goodwill computation. Two acquisitions show positive goodwill at recognition. One acquisition shows bargain purchase (gain recognised immediately). Three of the goodwill-bearing entities have an impairment scenario available as an optional overlay (toggle in the YAML config) to test the engine's CGU-level impairment logic.

IAS 21 FX matrix design — base currency, period-end vs average, and the period-CTA

The reference dataset has six currencies: CHF (group), USD, EUR, GBP, JPY, BRL. Why these six? They cover: a stable major (USD), a regional reserve (EUR), a non-Eurozone European (GBP), a low-rate currency (JPY), and a volatile emerging-market (BRL). Each currency interacts with the others through a triangulated FX matrix that's regenerated daily over the reporting period (252 trading days), with realistic intra-period drift modelled as a Brownian process. The triangulation is enforced — USD/CHF must equal USD/EUR × EUR/CHF up to an arbitrage tolerance.

Each entity translates its local-currency ledger to CHF using:

• **Period-end rate** for assets and liabilities (the CHF/local rate at the reporting-period close).
• **Average rate** for income statement items (typically the simple average of daily rates over the period; a weighted-by-revenue alternate is available).
• **Historical rate** for equity items posted at recognition (capital contributions translated at the rate on the contribution date).

The CTA falls out arithmetically: if the period-end rate moves from 1.10 CHF/EUR at period-open to 1.05 CHF/EUR at period-close, an EUR-denominated equity-method investment of 100M EUR at the period-open exchange rate translated to 110M CHF; at period-close, the same 100M EUR translates to 105M CHF. The 5M CHF reduction is a CTA loss flowing through OCI.

The reference dataset includes the full FX matrix for every trading day, the period-end and period-average rates as separate columns, and the per-entity CTA computation as a transparent rollforward. Engineers QA-ing a consolidation engine can step through the CTA line-by-line and verify the engine's arithmetic.

Inter-company elimination coverage: matched / unmatched / partial

Real groups have IC transactions in three states: matched (both sides agree fully), unmatched (one side has a posting the other doesn't, e.g., goods in transit at period-close), and partial (amount matches but timing differs by a few days due to cut-off issues).

The reference dataset has ~12K IC transactions across ~80 IC pairs (entity × counterparty), with controlled rates: 95% matched, 3% unmatched, 2% partial. The split is parameterised — you can dial the rates up or down via the YAML config to stress-test your matching logic.

The matched IC transactions eliminate fully against consolidation entries. The unmatched IC transactions show up on the elimination workpaper as in-transit / cutoff items requiring entity-level investigation. The partial IC transactions show up as timing differences, with a documented reconciling item bridging the period-end positions.

Pulling it all together: a 25-entity reference group

The reference dataset has the following structure:

• **1 parent + 24 subsidiaries / affiliates / investments.**
• **8 full-consolidation subs with NCI** (ownership %s 55-95).
• **5 equity-method investees** (ownership %s 25-49), one with documented control rebuttal.
• **4 fair-value investments** (ownership %s 5-15), two FVTPL + two FVOCI.
• **1 step-acquisition** (35% → 60% during the period, with pre-existing-investment fair-value step-up).
• **1 bargain-purchase acquisition** (consideration < acquired-net-assets, gain to P&L).
• **6 currencies** (CHF group + USD, EUR, GBP, JPY, BRL).
• **~12K IC transactions across ~80 IC pairs** (95% matched, 3% unmatched, 2% partial).
• **3 reportable IFRS 8 segments** (consumer products, financial services, technology) with cross-segment IC pricing.

Output formats: JSON (full audit trail with per-transaction provenance), CSV (per-entity ledgers + consolidation outputs as flat files), Parquet (analytics-ready). The audit-trail JSON includes the FX matrix at every trading day, the consolidation eliminations as journal entries, the NCI rollforward per entity, and the CTA computation per entity.

How to use it

Three primary use cases:

• **Consolidation engine QA** — load the per-entity ledgers into your engine, compare the engine's outputs (consolidated balance sheet, NCI rollforward, CTA, IC eliminations) to the reference outputs. Differences are bugs.
• **Methodology training** — give engagement leads a complete worked group engagement with all four NCI scenarios. Walk through how each one is consolidated. Validate that they can articulate the standard's mechanics for each.
• **AI/automation training** — train models on the synthetic group's full audit trail. The reference outputs are ground truth. Score the model's predictions exactly against the answer key.

Want the dataset? It's available on VynFi Group Audit (Enterprise tier). Contact sales for a guided walkthrough on the 25-entity reference group with all four NCI scenarios. Background reading: the Group Audit pipeline walkthrough shows how the dataset is generated end-to-end; the ISA 600 component-auditor deep dive covers the audit-firm coordination side.