ISA 600 (Revised): what synthetic component-auditor data should actually look like

If you're running a group engagement in 2026, you're working under ISA 600 (Revised), effective for periods beginning on or after 15 December 2023. The revision was a substantial rewrite — not just a renumbering — and the substantive changes around group-auditor responsibility for component work have not yet propagated through most audit-firm training material, methodology templates, or synthetic test datasets. This post is a short tour of what's actually different and what 'good' synthetic component-auditor data looks like under the revised standard.

The 2022 ISA 600 revision in 90 seconds

The revision moved the standard's centre of gravity from compliance-with-procedures toward outcome-based oversight by the group engagement team. Three substantive shifts:

• **Component vs. business unit** — the standard moved away from a strict 'component' definition (legal entity / branch / subsidiary) toward 'components are determined by the group auditor based on the group's structure'. This means a single legal entity might be split into multiple components, or multiple entities might be aggregated into one component.
• **Risk-based scoping** — instead of using percentage-of-revenue / total-assets thresholds to identify significant components, the standard requires risk-based scoping: where are the risks of material misstatement? That determines which components get full audits, specific-procedure work, or analytical procedures only.
• **Meaningful involvement** — the group auditor must be 'meaningfully involved' in component-auditor work, not just collect signed reports. The revised standard specifies what that involvement looks like (¶22-49): scoping discussions, risk-assessment review, procedure-design input, communication of significant matters, response to component-auditor findings.

These shifts changed the artefact requirements: scoping memos now have to document the risk basis, communication logs need to show two-way exchanges (not just a one-time instructions packet), and component-auditor work-product needs to be structured for group-auditor review (not just signed-and-filed).

Three failure modes in synthetic component data

Most synthetic group-audit test data we've reviewed (whether built in-house at firms, sourced from commercial methodology vendors, or generated by ad-hoc Python scripts) suffers from one or more of three failure modes that make the data unsuitable for ISA 600 (Revised) training or methodology QA.

Failure 1: 'Skeleton' component records

A skeleton component record has the right field names — firm, partner, scope, assigned entities — but no plausible content. The independence confirmation is a single 'Yes' string. The communication log is a placeholder ('Initial call held on date X'). The performance materiality is a round number with no derivation. The component-auditor 'report' is a one-page sign-off with no evidence of the work behind it.

Skeletons fail the meaningful-involvement test on day one — there's nothing for the group auditor to be involved with. A trainee using skeleton data learns nothing about how to actually exercise oversight. A methodology QA exercise that uses skeleton data won't expose any of the methodology's edge cases.

Failure 2: Pre-2022 ISA 600 framing

A surprising amount of test data still uses pre-2022 framing: 'significant component', 'non-significant component', percentage-of-revenue thresholds, 'component materiality' set as a fraction of group materiality with no risk-basis documentation. The standard moved on; the data didn't. Trainees using this data internalise the wrong mental model and have to unlearn it on first contact with a real engagement.

The revised standard's terminology — 'lower-of-thresholds clearly threshold', 'risk-based scoping', 'meaningful involvement' — should be the data's vocabulary. If the synthetic dataset is still talking about 'significant components' as a structural classification, it's behind the curve.

Failure 3: Non-falsifiable component opinions

A non-falsifiable component opinion is one where the component auditor's conclusion can't be checked against the component's underlying ledger. The component report says 'Aggregate misstatement: 1.2M'; the component's actual ledger has no traceable evidence of that 1.2M (no journal entries, no controls testing, no analytical procedures showing the variance that produced the figure).

Auditors evaluating the synthetic data — say, an audit-firm reviewer assessing whether a methodology team's training materials hold up — can't tell whether the component opinion is plausible. Worse, AI/automation tools trained on non-falsifiable data learn to reproduce the gap: predicting 'reasonable' aggregate misstatement figures with no traceable mapping to the underlying transactions.

What a 'good' component auditor record looks like

Good component-auditor data has four properties: complete (every ¶22-49 expectation has a corresponding artefact), realistic (the artefacts contain the kind of detail an auditor would actually produce), traceable (every claim ties back to the underlying ledger), and methodology-appropriate (the data uses 2022-revision terminology and structure).

Concretely, a good component-auditor record contains:

• **Firm + partner** — component auditor firm name, the engagement partner's name and credentials, the firm's regulatory standing (PCAOB-registered, FRC-registered, etc.).
• **Scope of work** — full audit / specific procedures / analytical-only, with the basis for that scope documented (risk assessment + group auditor's decision).
• **Assigned entities** — the legal entities or business units this component covers, with sector / currency / size information for each.
• **Performance materiality** — derived from a base materiality figure (typically a fraction of pre-tax income / total revenue / total assets) with a documented haircut for projected risk. The lower-of-thresholds clearly threshold (formerly 'clearly trivial threshold') is set as a fraction of performance materiality.
• **Independence confirmation** — date-stamped, identifies the engagement quality reviewer, lists any threats and the corresponding safeguards. Not a single-string 'Yes'.
• **Communication log** — chronological list of group-auditor / component-auditor exchanges, including: scoping call (typically pre-engagement), risk-assessment alignment (during planning), interim status update, draft-report review, response to group-auditor questions, final sign-off. Each entry has a timestamp, channel (call / email / portal), participants, and a one-line summary.
• **Detected misstatements** — classified per ISA 450 (factual, judgmental, projected). Aggregate magnitude. Resolution (corrected by management / accumulated for SUM / proposed adjustment).
• **KAMs proposed** — Key Audit Matters the component auditor flagged for elevation to the group level. Each KAM with a description, the underlying audit response, and the rationale for elevation.

Each of these is anchored to events that have plausible timing relationships with each other. The independence confirmation predates the engagement-acceptance date. Scoping is before risk assessment. Risk assessment is before procedure design. Status updates are spaced appropriately. The final report comes after all communication-log entries are closed.

Misstatements: factual / judgmental / projected — and why the classification matters

ISA 450 distinguishes three misstatement types, and the classification matters for both group-auditor aggregation and the final group opinion. Factual misstatements are mathematically determinable — a vendor invoice posted to the wrong account is a factual misstatement, full stop. Judgmental misstatements arise from estimation choices (impairment indicators, fair-value inputs, depreciation methods) that fall within a range of acceptable values; the auditor's view differs from management's. Projected misstatements are the auditor's extrapolation from a sample to the population.

Synthetic test data should distinguish all three. A standard approach: factual misstatements are direct ledger errors (e.g., a 50K transaction posted to expense rather than asset, a clear coding error). Judgmental misstatements are valuation differences (the synthetic engine generates an asset's fair value at 1.2M but management's books carry it at 1.5M — the 300K is judgmental). Projected misstatements are derived from a sampling exercise on synthetic populations (auditor samples 100 from 10K invoices, finds 3 errors at average 5K, projects 1.5M to the population).

VynFi's component data tags each misstatement with its ISA 450 classification, and the group-auditor's SUM (summary of unadjusted misstatements) aggregates them according to firm-policy rules: factual misstatements added directly, judgmental aggregated with disclosed uncertainty, projected aggregated with confidence-interval bounds.

KAMs vs scoping notes vs group-opinion modifications

Three artefacts that often get conflated in synthetic data, but are distinct under the standard:

• **KAMs (Key Audit Matters)** — required by ISA 701 for listed-entity audits. Address matters of most significance in the auditor's professional judgment. Reported in the auditor's report, addressed to the user of the financial statements.
• **Scoping notes** — internal documentation of the group-auditor's scoping decisions (which components get full audit, why, performance materiality basis). Not in the auditor's report; in the engagement file. Per ISA 600 (Revised) ¶22-26.
• **Group-opinion modifications** — qualified / adverse / disclaimer outcomes resulting from material misstatement, scope limitation, or going-concern uncertainty. Reported in the modified auditor's report; affects the user's view of the financial statements directly.

A trainee who treats a scoping decision as a KAM (or vice versa) will reach the wrong conclusion in a real engagement. Synthetic data that flattens these into a single 'audit findings' field is doing the trainee a disservice. VynFi's structure separates them: KAMs flow through the ISA 701 surface, scoping notes flow through the engagement-file artefact set, opinion modifications flow through the auditor's report draft.

How VynFi's generators map to ISA 600 (Revised) ¶22-49

VynFi Group Audit's component generator maps to the relevant paragraphs as follows:

• **¶22-26 (Scoping)** — emits scoping memos with risk-assessment basis, component classification, and assigned-procedures rationale.
• **¶27-30 (Component-auditor competence + independence)** — emits firm/partner records with credentials, regulatory standing, and date-stamped independence confirmations including threat-and-safeguard documentation.
• **¶31-35 (Component-auditor instructions)** — emits structured instructions with risk areas, performance materiality, sampling thresholds, reporting deadlines, and group-auditor expectations.
• **¶36-40 (Performing audit work + meaningful involvement)** — emits the communication log showing two-way exchanges, group-auditor review evidence (timestamps, comments on draft work), and risk-response evidence.
• **¶41-45 (Reviewing component-auditor work)** — emits component reports with detected misstatements (ISA 450 classified), KAMs proposed, and group-auditor review notes.
• **¶46-49 (Group opinion)** — emits the synthesised group-auditor opinion, group-level SUM, group-level KAMs, and any opinion modifications.

Every artefact has a corresponding section in the JSON output of /v1/groups/{id}/runs/{runId}, structured for direct consumption by audit-tooling integrations. The same artefacts are renderable as PDFs for human review.

Try it

If you're a methodology specialist or an engagement-quality reviewer evaluating component-auditor work, request a Group Audit walkthrough via /pricing#enterprise. The 12-entity Acme group sample includes a full set of ISA 600 (Revised) artefacts you can review against your own methodology checklist. The pipeline walkthrough shows how the artefacts are generated; the IFRS 10 reference dataset covers the consolidation side.