From entity tree to group opinion: a walkthrough of VynFi's group-audit pipeline

Group audits are where audit-firm tooling tends to fall apart. Single-entity workflows are well-trodden — every Big4 platform has a workpaper authoring story for a standalone trial balance, every consolidation tool has an OK story for a single legal entity. But the moment you bring in a 30-entity multinational with mixed-currency subsidiaries, equity-method affiliates, and a network of inter-company balances that need to net to zero, the tooling story gets thin. You end up gluing together five different systems and hoping the audit-trail survives review.

VynFi's Group Audit feature attacks this with a different premise: model the entire group as one config artefact, generate the dataset and the workpapers in one pipeline, and emit the ISA 600 component-auditor coordination artefacts as first-class outputs rather than after-the-fact templates. This walkthrough takes a 12-entity Nestlé-style consumer-goods group from blank YAML to a signed group opinion, end to end, with every piece annotated.

The synthetic-data gap in group audits

Talk to anyone running a group engagement and you'll hear the same complaint: there's no way to dry-run the methodology end-to-end without a live client. Audit firms have plenty of single-entity test data — half the Big4 training programs spin up a one-company sandbox for new joiners. But group-engagement test data needs an org tree, multi-currency exposure, equity-method affiliates, NCI scenarios, and IC counterparties that actually match. Constructing that by hand for a training engagement takes weeks.

What firms typically settle for: a hand-built 3-entity test group with one foreign sub, fake CTA numbers, no equity-method affiliates, and no real ISA 600 component coordination. Trainees see a toy version of group audit and then meet a 50-entity multinational on day one of their first real engagement. The tools are similar — methodology training datasets are almost always a degenerate case of what the field looks like.

VynFi's stance: a synthetic group should be at least as complex as the engagement it's training for, and every component (entity, currency, IC pair, NCI scenario) should be traceable back to a configuration choice the engagement lead made on purpose. That's what the YAML config buys you.

Building the entity tree (form + YAML escape hatch)

Open the dashboard at /dashboard/groups and click 'New group'. The wizard's first step is the org tree. The default mode is form-based: pick a parent entity, set its currency and sector preset, then add children one at a time. Each child gets a consolidation method (full / equity / fair-value), an ownership %, an acquisition date, and a base currency.

For a 12-entity group, the form is fine. For a 100-entity group with three ownership tiers and 14 currency exposures, the form gets cumbersome — that's what the YAML escape hatch is for. Click 'Edit as YAML' and you get a textarea pre-populated with your form selections, plus a schema-driven validator that flags ownership-circle errors, currency mismatches, and consolidation-method mistakes (e.g., 50% with full consolidation requires a control-assessment override).

name: "Acme Consumer Goods Group"
basePeriod: "2025"
groupCurrency: "CHF"
parent:
  id: "acme-holdings"
  name: "Acme Holdings AG"
  currency: "CHF"
  sector: "consumer_goods_holding"
entities:
  - id: "acme-europe"
    parent: "acme-holdings"
    name: "Acme Europe GmbH"
    currency: "EUR"
    consolidation: "full"
    ownership: 1.00
    sector: "consumer_goods_distribution"
  - id: "acme-uk"
    parent: "acme-europe"
    name: "Acme UK Ltd"
    currency: "GBP"
    consolidation: "full"
    ownership: 0.85   # 15% NCI
    sector: "consumer_goods_distribution"
  - id: "acme-italy"
    parent: "acme-europe"
    name: "Acme Italia S.p.A."
    currency: "EUR"
    consolidation: "full"
    ownership: 0.70   # 30% NCI
    sector: "consumer_goods_distribution"
  - id: "acme-jv-jp"
    parent: "acme-holdings"
    name: "Acme-Sumitomo Joint Venture KK"
    currency: "JPY"
    consolidation: "equity"   # IAS 28
    ownership: 0.40
    sector: "consumer_goods_jv"
  - id: "acme-us"
    parent: "acme-holdings"
    name: "Acme US Inc"
    currency: "USD"
    consolidation: "full"
    ownership: 1.00
    sector: "consumer_goods_distribution"
  # ... 6 more entities

The YAML maps directly to the IFRS 10 consolidation model: 'full' is full consolidation with NCI for the non-owned share, 'equity' is IAS 28 equity-method (proportionate share of investee net income, no IC eliminations against this entity), 'fair-value' is the IFRS 9 / IAS 39 path for non-significant investments. The validator runs synchronously: if you've configured 70% ownership with 'equity' consolidation, it warns you (control assessment usually drives full consolidation at 70%, but you can override with a documented rebuttal).

IFRS 10 mechanics: full / equity-method / fair-value / NCI

Once the tree validates, the engine runs the consolidation. Each entity gets a forward-generated ledger appropriate to its sector (using the same DataSynth pipeline that powers single-entity generation), then the consolidation engine threads them together using the IFRS 10 mechanics:

• **Full consolidation (IFRS 10)** — 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 presented as a separate line in equity.
• **Equity method (IAS 28)** — investments are carried at cost initially, then adjusted for the investor's share of post-acquisition profits or losses. The investee's results are *not* line-by-line consolidated; only the share of net income flows through the income statement, and the equity-method investment line on the balance sheet rolls forward.
• **Fair-value (IFRS 9 / IAS 39)** — non-significant investments are carried at fair value with FVTPL or FVOCI movements. No proportional consolidation, no equity-method tracking.
• **Step-acquisition** — when ownership crosses the control threshold (typically 50%), the engine handles the remeasurement: existing investment is fair-valued at acquisition date, the gain/loss flows to P&L, and goodwill is computed on the full fair value.

NCI rollforward is a first-class output. Opening NCI per entity, period earnings attribution, OCI movements, dividends declared to NCI, and any step-acquisition adjustments all show up on a single rollforward schedule that ties to the consolidated balance sheet's NCI line item to the cent. This is the workpaper auditors actually want to see — most internally-built test data has the rollforward as an afterthought, often with NCI plugged to make the balance sheet tie.

IAS 21 in practice: CTA rollforward, FX matrix, period-CTA

Foreign-currency translation under IAS 21 is where most synthetic group data falls apart. The standard requires assets and liabilities at period-end rates, equity at historical rates, income statement at average rates, and the resulting translation difference (CTA) flows through OCI. Get any of those four rates wrong and you've got a balance that doesn't tie.

VynFi generates a triangulated FX matrix at the start of each period: USD↔EUR, EUR↔GBP, GBP↔CHF, all the cross-rates the group needs. The triangulation is enforced (USD/CHF must equal USD/EUR × EUR/CHF up to an arbitrage threshold) so the rates are internally consistent. Period-end rates and average-period rates are both derived from the same matrix, with realistic intra-period drift modelled as a Brownian process.

The CTA rollforward output shows: opening CTA, current-period translation movement (broken down by entity), reclassification adjustments (when an entity is disposed of), and closing CTA. Every line traces back to the FX matrix and the entity's local-currency net assets. The audit-trail JSON includes the full FX matrix at period-open, period-close, and all 252 daily marks in between — useful when an audit-firm reviewer wants to spot-check the period-CTA on a specific entity.

IC matching and elimination coverage

Inter-company balances are the silent killer of synthetic group data. If you generate two entities' ledgers independently, IC payables don't match IC receivables, and elimination journals leave residuals — visible to anyone running a sanity check. VynFi generates IC pairs jointly: when entity A's accounts payable to entity B is created, the corresponding accounts receivable on B's books is generated with the same amount, transaction date, and reference number.

The IC elimination workpaper output classifies every IC transaction as: matched (both sides agree to the cent), unmatched (one side has a posting the other doesn't — by design, the engine injects a configurable percentage of unmatched IC items so audit-firm trainees can practice the in-transit reconciliation), or partial (amount matches but transaction date differs by a few days, simulating cut-off issues).

• **Matched IC** — eliminates fully against the consolidation entry. Default 95% of IC volume.
• **Unmatched IC** — one side missing. Configurable rate (default 3%). The matching workpaper flags these as cutoff or in-transit items requiring entity-level investigation.
• **Partial IC** — same amount, different date or reference. Configurable rate (default 2%). These force the trainee to chase the timing difference and document the reconciling item.

ISA 600 artifacts: component auditors, instructions, reports, group opinion

ISA 600 (Revised, 2022) raised the bar significantly on group auditor oversight of components. The 2024 implementation requires the group auditor to demonstrate 'meaningful involvement' in component-auditor work — not just collect their opinions. VynFi generates the artefacts that demonstrate that involvement.

Per component (where 'component' typically means a subsidiary or significant business unit), the engine emits:

• **Component auditor record** — firm name, partner, scope (full audit / specific procedures / analytical), assigned entities, performance materiality, lower-of-thresholds clearly threshold, independence confirmation, and a chronological communication log.
• **Component instructions** — what the group auditor asked the component auditor to do, including risk areas, sampling thresholds, and reporting deadlines.
• **Component report** — what the component auditor reported back: opinion (clean / qualified / adverse / disclaimer), aggregate detected misstatements (factual / judgmental / projected per ISA 450), key findings, and KAMs proposed for elevation to the group level.
• **Group opinion** — the group auditor's synthesis: the group-level opinion, the projected aggregate misstatement, the SUM (summary of unadjusted misstatements), and KAMs that survived the group-level filter.

Each artefact is anchored to a real event in the engagement timeline. The component instructions are dated before the component report. The communication log shows a documented exchange (email, video call, secured-portal message) for every reporting milestone. Auditors reviewing the bundle see a defensible chain of involvement, not a fabricated 'one signed report' as evidence.

How to use this for training and methodology QA

Two primary use cases drive group-audit feature requests. Training: a Big4 firm's audit-academy team builds a curriculum for new group-engagement leaders. They need 30 worked engagements covering different scenarios — straightforward, qualified opinion, going-concern uncertainty, IFRS 8 segment complexity, mid-period acquisition, currency hyperinflation. Each scenario takes weeks to build by hand. With Group Audit, each scenario is a YAML file plus a one-line API call.

Methodology QA: a methodology team at a mid-tier firm wants to dry-run a new group-engagement template against a realistic dataset before rolling it out. They generate a 50-entity test group, run the new template against the dataset, and watch where it breaks. The synthetic data is realistic enough to expose the methodology's edge cases without exposing client data.

A third use case is emerging: AI / automation tooling QA. Audit firms building AI-assisted review tooling need ground-truth datasets to validate their models. Group Audit's full audit trail (every NCI rollforward line, every CTA accrual, every IC elimination) is the ground truth — the AI's predictions can be scored exactly against the synthetic answer key.

Try it

Group Audit is part of VynFi Enterprise. If you're an audit firm or a CFO preparing IFRS 10 consolidations and want to see the pipeline end-to-end, contact sales for a guided walkthrough on a 12-entity sample group. We'll set up the YAML, run the consolidation, and walk through the consolidated balance sheet, NCI rollforward, CTA rollforward, IC elimination workpaper, and the four ISA 600 artefacts in one session.

Background reading: the ISA 600 component-auditor coordination deep dive covers what the 2022 revision actually changed and why most synthetic component data falls short. The IFRS 10 consolidation reference dataset walks through the four NCI scenarios you have to handle correctly.