Automating CbC reporting data collection means replacing manual extraction from the general ledger and consolidation system with a repeatable pipeline that pulls jurisdictional revenue, profit, tax and headcount data once, then maps it to every filing format the group actually needs — not only the OECD’s CbC XML Schema. Most automation projects get this wrong: they are scoped to produce Table 1–3 of the Country-by-Country Report and nothing else, so the same underlying data has to be re-extracted, re-mapped and re-validated eighteen months later when the group also needs a GloBE Information Return under Pillar Two. That is not a hypothetical risk. On 20 October 2026 the OECD published version 2.0 of the GloBE Information Return XML Schema — the second overhaul of that exchange format in under two years — while the CbC XML Schema itself has barely moved since June 2019. A roadmap for CbC reporting automation that does not plan around that asymmetry is obsolete before it ships.

Why most CbC reporting automation projects fail within 18 months

The OECD’s 2015 BEPS Action 13 final report set out a three-tier transfer pricing documentation framework — Master File, Local File and the Country-by-Country Report — on the premise that one underlying dataset about the group’s global allocation of income, taxes and economic activity could serve all three tiers (OECD, 2015). In practice, most in-house automation projects only build for the third tier. They connect the ERP or consolidation system to a template that reproduces the CbC XML Schema’s data elements — revenue from related and unrelated parties, profit before tax, income tax paid and accrued, stated capital, accumulated earnings, number of employees and tangible assets, broken down by jurisdiction — and stop there.

That narrow scope holds up until the same finance function needs the same jurisdictional aggregates for a different purpose. Pillar Two’s GloBE Information Return asks for revenue, profit, taxes and employees by jurisdiction too, but computed under GloBE’s own definitions — adjusted covered taxes, substance-based income exclusion inputs, qualifying refundable tax credits — rather than the CbCR definitions. Transfer pricing documentation needs the same legal entity hierarchy and intercompany flows again, this time to support arm’s-length positions rather than to populate a template. Three projects, one general ledger, three data models built one at a time: that is the pattern behind almost every “we automated CbCR, now we have to rebuild it for Pillar Two” conversation tax functions have once a safe harbour test or a GIR filing lands on their desk.

What just changed, and why it resets the roadmap

On 20 October 2026 the OECD released the GloBE Information Return (Pillar Two) XML Schema, version 2.0, together with its user guide for tax administrations (OECD, October 2026). It replaces version 1.0, published in January 2025 (OECD, January 2025), and folds in the 2026 changes to the GIR that followed the Inclusive Framework’s Side-by-Side package, plus unspecified technical improvements. The transition is staged, not immediate: version 1.0 continues to apply to exchanges until 15 June 2028, and version 2.0 becomes mandatory for every exchange — including amendments and corrections to data already exchanged under version 1.0 — from 25 June 2028.

Compare that to the CbC XML Schema, which the OECD last updated in June 2019 and which has been in continuous use since 1 February 2021 (OECD). CbCR’s exchange format is, by Pillar Two standards, essentially frozen. GIR’s is not: two schema versions in under two years, with a mandatory cutover already on the calendar for mid-2028. Any automation architecture that hard-codes GIR or CbC XML tags directly into its extraction logic — instead of treating the schema as a replaceable output adapter — is signing up for re-engineering work on a clock it did not choose.

What does a CbC reporting automation roadmap actually look like?

The fix is architectural, not a bigger spreadsheet. It splits into six phases, run roughly in order but revisited as each filing regime changes.

Phase 1 — Build one entity data model, not three

Start with a single legal entity register that carries the CbCR constituent-entity population, the GloBE constituent-entity population and the transfer pricing intercompany entity list against the same source IDs. These three populations are not always identical — joint ventures, transparent entities and minority-owned subsidiaries get treated differently under each regime — but the register should resolve every entity to one record, with flags for which filings it belongs to, rather than three disconnected lists maintained by three teams.

Phase 2 — Inventory source systems, currencies and consolidation scope

Map which ERP, sub-ledger or consolidation tool holds each data point, and where functional currency, reporting currency and FX conversion rules diverge between statutory accounts and the management consolidation. This is the slowest phase in practice and the one most roadmaps skip, which is also why most automation projects stall in reconciliation rather than in the technology itself.

Phase 3 — Build a jurisdiction-level staging layer, decoupled from any XML schema

Compute a “golden” set of jurisdictional aggregates once per period — revenue from related and unrelated parties, profit before tax, income tax paid and accrued, stated capital, accumulated earnings, employees and tangible assets for CbCR, plus the GloBE-specific aggregates (adjusted covered taxes, substance-based income exclusion inputs) for Pillar Two — independent of how any single filing format will eventually consume it. This staging layer, not the XML output, is the actual deliverable of an automation project.

Phase 4 — Treat schema mapping as a thin, versioned adapter

Keep the CbC XML Schema mapping and the GIR XML Schema mapping as separate, swappable modules that read from the staging layer in Phase 3. When the OECD moves from GIR v1.0 to v2.0, or revises the CbC schema for the first time since 2019, only the relevant adapter changes — not the extraction logic or the underlying calculations. Evaluating whether to build this adapter layer in-house or buy it is a separate decision with its own criteria, covered in our buyer’s checklist for transfer pricing documentation software, much of which applies equally to CbCR and GIR tooling.

Phase 5 — Automate validation and status-message handling

The OECD publishes separate Status Message XML Schemas for both CbC and GIR exchanges, used by tax administrations to report back filing errors and request corrections. Build parsing of those status messages into the pipeline so a rejected or flagged filing triggers an internal alert automatically, instead of relying on someone to check a tax authority portal manually.

Phase 6 — Governance: tie version control to known OECD transition dates

Maintain a standing calendar of confirmed cutover dates — the CbC schema’s 1 February 2021 switchover is already behind you; the GIR v2.0 mandatory date of 25 June 2028 is not — and assign an owner for re-testing the relevant adapter well before each one. Governance here means treating a schema version bump as a scheduled, budgeted event, not an emergency that surfaces when a filing bounces back.

Build, buy or outsource the automation layer?

None of the six phases above dictates a specific vendor or platform, and that is deliberate. Groups with an ERP already capable of jurisdictional reporting (through a native tax module or a bolt-on consolidation layer) can often build Phases 1–3 internally and buy only the schema adapters in Phase 4. Groups running fragmented or legacy ERP landscapes — common after a string of acquisitions — tend to get more value from a dedicated tax reporting platform that owns the staging layer end to end. Outsourcing the whole pipeline to an advisory firm removes the architecture decision entirely, at the cost of recurring fees and less internal control over how fast the staging layer adapts when requirements change. None of these paths is automatically correct; the criteria that should decide it — data ownership, audit trail requirements, integration with existing Pillar Two tooling — are the same ones laid out in our transfer pricing software checklist, and they apply to a CbCR/GIR automation decision just as directly.

What should multinationals do now, with the 2028 GIR cutover ahead?

Twenty months is enough time to re-architect the pipeline properly; it is not enough time to wait and see. The practical move is to start the staging-layer/adapter separation described above while GIR version 1.0 is still the mandatory format, so that by the June 2028 cutover the only required change is swapping one adapter module for another — not re-building the extraction and calculation logic under deadline pressure. Tax functions that wait until the 2028 transition window to start this work will be doing it at the same time as every other multinational competing for the same implementation resources, which is exactly the bottleneck a roadmap is supposed to avoid.

FAQ: CbC reporting automation

What data does CbC reporting automation need to extract?

Jurisdictional revenue from related and unrelated parties, profit (loss) before income tax, income tax paid and accrued, stated capital, accumulated earnings, number of employees and net book value of tangible assets, for every constituent entity in the group as defined under BEPS Action 13 — the data elements set out in the OECD’s CbC XML Schema.

Did the OECD change the CbC XML Schema in 2026?

No. The CbC XML Schema itself was last updated in June 2019 and has been in use since 1 February 2021. What changed in 2026 is the separate GloBE Information Return (Pillar Two) XML Schema, which moved from version 1.0 (January 2025) to version 2.0 (October 2026) — a different filing, on a different, faster-moving schedule.

How does Pillar Two’s GloBE Information Return affect CbC reporting automation?

It shares most of its jurisdictional source data with CbCR — revenue, profit, taxes, employees — but applies different definitions and sits on a schema that the OECD revises far more often. Any CbC automation built without a shared data layer for both filings will need substantial rework once the group also files a GIR.

Should transfer pricing documentation be automated in the same project as CbCR?

The entity and intercompany data should come from the same source layer, yes — duplicating that extraction for Master File and Local File purposes wastes the same effort CbCR automation is meant to save. The output logic differs enough, though, that TP documentation usually needs its own evaluation criteria when selecting tooling.