JSON vs XML for e‑Invoicing: How to Choose the Right Format
Learn JSON vs XML for e‑invoicing, EN 16931/UBL rules, and how JSON files, validators and APIs keep tax‑compliant invoices flowing.
Choosing between JSON and XML for e‑invoicing is a format decision with real product impact, not a stylistic preference. Tax authorities define strict invoice data models and bind them to specific syntaxes, most often XML formats such as UBL 2.1, which implements EN 16931 in Europe, or government‑published JSON schemas in API‑driven systems like India’s GST e‑invoicing.
In practice, that means your invoice model has to serve two masters at once: legal compliance with standards and schemas, and a developer‑friendly representation that works well inside your product and API layer. This article looks at where XML is effectively mandatory, where JSON is now the natural choice, and how to design an invoice model that can emit both without disrupting your architecture.
Most tax authorities treat invoices as valid only when they are submitted as structured data that follows an official schema or data model, rather than as free‑form documents like PDFs.
Clearance or near‑real‑time reporting models then require your ERP or billing system to send that structured payload via APIs or portals, have it validated against those rules, and receive a confirmation or reference back. That makes your base format a strategic choice, because changing it later touches both your compliance layer and your developer interfaces.
JSON (JavaScript Object Notation) is a lightweight, text‑based structured format that modern APIs, web apps and mobile stacks use to exchange data. A JSON file in e‑invoicing is simply a machine‑readable invoice that follows the official schema, such as India’s IRP e‑invoice JSON format.
When developers work with JSON, they often use a JSON formatter to make payloads readable and a JSON validator to check that invoice data matches the required government schema before submitting it.
This is why JSON is a natural choice in API‑first clearance regimes: it lines up neatly with RESTful design, fits in most programming languages, and keeps e‑invoice payloads smaller than equivalent XML.
In many jurisdictions and networks, XML is still the default e‑invoice syntax. EN 16931 defines the semantic model for e‑invoices in Europe, and CEN technical specifications bind that model to UBL 2.1 and CII XML messages, which carry the business rules as concrete elements and attributes.
Public procurement in the EU is built around this setup: contracting authorities must accept EN 16931‑compliant e‑invoices in the approved syntaxes, and Peppol BIS Billing 3.0 uses UBL 2.1 XML as its mandatory format. Outside Europe, Malaysia’s IRBM also requires invoices to follow UBL 2.1, whether you submit XML or JSON, and validates them via the MyInvois portal or API.
The key upside of XML here is its tight coupling to mature schemas and validation artefacts that governments and public networks have already standardised on.
Aspects | JSON | XML |
Compliance | Required in API-first regimes (e.g., India IRP). | Required in the EU/Peppol via UBL 2.1 or CII. |
Flexibility | Often one accepted the syntax where JSON schemas exist. | Often the default syntax in EN 16931‑based setups. |
Dev experience | Lightweight, easy for web and REST APIs. | Strong schemas, namespaces, mature tooling. |
Usage pattern | Used inside apps for internal APIs and UI calls. | Generated at submission edges for authorities. |
Performance | Smaller payloads, faster to parse. | More verbose, better for complex hierarchies. |
Interoperability | Depends on matching official JSON schemas. | Depends on matching EN 16931 UBL/CII bindings. |
The smartest way to handle JSON and XML is to keep your core invoice data in one unified JSON model, then let DDD Invoices convert it into the required local format at the edge. That means your team works with one API, while DDD handles XML generation, country rules, tax portal delivery, Peppol routing, and ongoing compliance updates in the background.
This approach keeps development lighter, avoids country‑by‑country rebuilds, and makes it easier to scale across B2B, B2G, B2C, fiscalization, reporting, receiving, and archiving from a single platform.
It also gives you practical extras beyond format conversion, including dashboard monitoring, secure archive, embedded UI, mass invoicing, and support for incoming invoices and OCR flows.
Use whichever syntax your tax authority or network mandates and map your internal invoice model to that format. In EU/Peppol flows this is usually UBL or CII XML, while in India GST it is a prescribed JSON file uploaded to the IRP.
JSON is a structured data format used to represent invoice details in a way that APIs and tax platforms can process automatically. Under GST, for example, an e‑invoice JSON file is the machine‑readable version of your invoice that the IRP validates and signs before assigning an IRN.
A JSON formatter makes complex invoice payloads easier to inspect and debug. A JSON validator checks your e‑invoice JSON against the official schema so you can fix errors before submitting to portals like India’s IRP or Malaysia’s MyInvois API.
Yes, and this is recommended: define a neutral semantic invoice model in your application, then generate UBL/CII XML or authority‑specific JSON from it on demand. That way you keep your product logic clean but still comply with EN 16931, Peppol and national e‑invoicing schemas.
Written by the Compliance & Growth Team
Reviewed by Denis V. P.
DDD Invoices is an enterprise-grade platform delivering a powerful infrastructure for creating, sending, receiving and storing electronic documents. DDD Invoices enables software providers like ERPs, SaaS, eCommerce, POS systems, accounting & invoicing softwares, billing services and others, to easily adhere to global invoicing compliance requirements and shorten their time-to-market.
