The OECD has published a standardised XML schema for the GloBE Information Return, and many tax authorities are adopting it as the required submission format. This guide walks through the schema structure, the mandatory fields, the Part E reconciliation requirement, and the most common validation errors.
Schema structure overview
A GIR XML document has two top-level sections: MessageSpec and GIRBody.
MessageSpec contains filing metadata: the sending entity's tax identification number, the transmitting country, the message type (GIR401 for a standard return), a unique message reference ID, and the reporting fiscal year.
GIRBody contains the substantive content, divided into five Parts:
- Part A — jurisdictional top-up tax computation: GloBE ETR, SBIE, top-up percentage and top-up tax amount per jurisdiction.
- Part B — constituent entity information: entity name, TIN, jurisdiction, entity type, and ownership chain.
- Part C — specific allocation rules: IIR allocation, UTPR allocation, QDMTT amounts.
- Part D — elections and adjustments: Art. 3.2 adjustments, Art. 4.6 elections, SBIE elections.
- Part E — summary reconciliation: total top-up tax payable, reconciled to IIR + UTPR − QDMTT credit.
Mandatory fields and data types
Currency amounts in the GIR XML schema must be integers — no decimal places. The schema uses whole-unit currency (euros or local currency, as applicable), so all monetary amounts must be rounded before serialisation. A common source of validation errors is passing decimal values from a calculation engine directly into the XML template.
Jurisdiction codes must be ISO 3166-1 alpha-2 (two-letter country codes). The GIR schema does not accept ISO 3166-1 alpha-3 codes or OECD jurisdiction codes that differ from ISO 3166-1.
Part E reconciliation
Part E is the most common failure point. The total top-up tax in Part E must equal the sum of all jurisdictional top-up tax amounts from Part A, and must reconcile to the IIR top-up tax plus UTPR top-up tax minus any QDMTT credits. A rounding error of even €1 will cause schema validation to fail in most implementations.
The correct approach is to derive the Part E total from the Part A figures by summation, rather than computing it independently. Independent computation of the Part E total and the Part A figures will accumulate rounding differences across jurisdictions.
Common validation errors
- ETR > 1.0 — an effective tax rate above 100% is impossible under GloBE rules and indicates a data error (usually swapped numerator and denominator in the ETR calculation).
- Duplicate jurisdiction codes — each ISO 3166-1 alpha-2 code must appear exactly once in Part A. Separate legal entities in the same jurisdiction must be aggregated before Part A population.
- QDMTT contradiction — claiming the QDMTT safe harbour while
QDMTTApplied = falseis a logical contradiction that most validators will reject. - Missing Part B entries — every constituent entity referenced in Part A must have a corresponding Part B entry with a valid TIN and entity type.
- Non-zero top-up tax for safe harbour jurisdictions — a jurisdiction that has been granted safe harbour treatment must have a top-up tax amount of zero in Part A. Any non-zero value for a safe harbour jurisdiction is a validation error.
Testing your GIR XML
Before submission, validate GIR XML against the published OECD XSD schema and against a set of logical consistency checks (ETR bounds, Part E reconciliation, safe harbour consistency). The Pillar2OS resources page offers sample GIR XML files — valid and annotated-invalid — for testing against your own validator implementation.
Pillar2OS generates OECD-schema-aligned GIR XML from your computation output, with Part E derived by summation from Part A to avoid rounding errors. Start free.