What are the approved e-invoice formats?
Published
The summary first
Under Phase 2, an invoice is issued in one of two forms:
Pure XML ← a structured data file, read by systemsPDF/A-3 + embedded XML ← a human-readable document carrying that same XML inside it
Either way, the XML is the invoice. The PDF is a presentation wrapper; the statutory data, signature, and stamp all live in the XML.
XML: why it is the foundation
XML is structured data: every field on the invoice - seller, buyer, lines, amounts, tax - is a named element in a defined structure that systems can read and validate automatically. That is what lets the Fatoora platform check each invoice on arrival: structure valid? fields complete? signature correct? sequence unbroken?
By contrast, an ordinary PDF or an invoice image is a picture of an invoice: a person can read it; a validation system can extract nothing trustworthy from it.
PDF/A-3: why that specific type
PDF/A is the PDF family built for long-term archiving: fixed rendering with no dependence on external fonts or resources that may disappear. The decisive feature of version A-3 specifically: it permits embedding other files inside the document - which is what makes the combination possible: one document that opens as a PDF for human eyes and carries an XML file for machine ones.
Embedded XML: how it works in practice
One PDF/A-3 invoice├── Presentation layer: the printed look, logo, QR code└── Internal attachment: invoice.xml - the full statutory invoice, signed
When your customer receives the file, they receive both at once. Their accounting system extracts the XML and imports the data with no manual entry; their staff read the PDF like any invoice.
The tiebreaker in any conflict: if what the PDF displays differs from what the XML carries, the XML governs - it is what was cleared and signed. A mismatch between them is itself a defect in the generating system and must be fixed immediately.
What this means for a small business
You don't write XML or build PDF/A-3 - your compliant invoicing system does. But understanding the formats settles practical questions:
| Question | Answer |
|---|---|
| The customer asks for the "original invoice" - which file do I send? | The system-issued PDF/A-3 suffices - the original is inside it |
| Is editing the PDF in a file editor acceptable? | No; it breaks the signature and invalidates the file. Corrections go through credit/debit notes |
| Is our old archive of invoice scans compliant? | For periods after the requirements applied: no. Retention is of the statutory files in their formats |
| A system that exports "PDF only"? | Not Phase 2 compliant, however correct the invoice looks |
Frequently asked questions
Should I send my customer the raw XML?
Integrated systems can exchange it directly, but the customary practice with customers is the PDF/A-3, which carries both faces.
What is the difference between ordinary PDF and PDF/A-3?
Ordinary PDF is display-only, guarantees nothing about archiving, and carries no statutory attachments. A-3 is archival by design and permits embedding XML - which is why it was chosen.
Is the QR code inside the XML or the PDF?
The code's data is part of the statutory invoice package, and the code is rendered in the PDF layer so it can be scanned on paper and on screen.