Once the GloBE computation is complete, the next step is producing a GIR XML file that will pass schema validation and be accepted by the relevant tax authority. This sounds straightforward — it is essentially a serialisation exercise — but the number of implementation errors seen in the wild suggests it is not. This article covers the key decisions and pitfalls in building a GIR XML generator.
Design principle: one source of truth
The most important design decision is that the XML generator must draw from the same data as the on-screen computation — not from a separate calculation pass. If the XML and the screen figures are produced by different code paths, they will diverge when edge cases arise. The XML generator should be a serialiser over the computation output, not an independent calculation.
Currency amount handling
The OECD GIR schema expects currency amounts as integers. This means all monetary values must be rounded to whole units before serialisation. The rounding method matters for Part E reconciliation: rounding errors accumulated across many jurisdictions can cause the Part E total to diverge from the sum of Part A figures by several units. The safest approach is to round at the leaf level (individual entity figures) and derive all totals by summation of the rounded leaves, rather than computing totals from unrounded values and rounding at the end.
Jurisdiction aggregation
Part A of the GIR is at jurisdictional grain — one row per jurisdiction, not one row per entity. Before populating Part A, all constituent entity figures within a jurisdiction must be aggregated. The aggregation rules are not simply a sum: GloBE Income and Adjusted Covered Taxes aggregate straightforwardly, but some elections (Art. 4.6 deferred tax liability recapture) are applied at entity level before jurisdictional aggregation.
Entity type handling in Part B
Part B requires an entity type code for each constituent entity. The type codes differ for standard constituent entities, flow-through entities (Art. 3.5.1), joint ventures (Art. 32.), minority-owned constituent entities, and permanent establishments. Each type has different treatment in the computation and different required fields in the XML. A generator that treats all entities as standard CEs will produce incorrect Part B entries for flow-throughs and JVs.
Namespace and schema version
The OECD has published multiple versions of the GIR schema. Ensure your generator uses the version required by the specific tax authority — some jurisdictions have mandated a particular version, and a file produced under an earlier schema version may fail validation even if logically correct. The namespace declaration in the root element must match the schema version exactly.
Pre-submission validation checklist
- Schema validation: validate against the OECD XSD before submission.
- ETR bounds check: ETR must be ≥ 0 and ≤ 1 for every jurisdiction.
- Part E reconciliation: Part E total equals sum of Part A top-up tax amounts.
- Safe harbour consistency: zero top-up tax in Part A for all safe harbour jurisdictions.
- Duplicate jurisdiction codes: each ISO 3166-1 alpha-2 code appears at most once in Part A.
- Part B completeness: every entity referenced in Part A has a corresponding Part B entry.
Pillar2OS generates and validates GIR XML automatically from the computation output. Download sample GIR XML files from our resources page.