“Our billing system sends JSON. Must we replace it to support UAE e-invoicing?”

Start by identifying which interface carries that JSON. An internal payload, an ERP-to-provider interface and the provider-to-provider invoice exchange are different boundaries.
Separate the boundaries
The official model allows C1 to submit data in a format agreed with C2. C2 converts it to the UAE-standard XML when another format was received, and the provider-to-provider invoice exchange uses XML. A JSON interface is therefore a possibility only where agreed and supported; it is not automatically a compliant external invoice format. MoF electronic invoicing guidelines.
Write the interface contract
| Contract area | Decision to record |
|---|---|
| Payload | Exact accepted structure and version |
| Meaning | Business definition of each input |
| Source | Authoritative field or derivation |
| Transformation | Team responsible for final structure |
| Checks | Which layer detects which issue |
| Responses | Status, correlation and error payloads |
| Recovery | What happens after correction or timeout |
These are design recommendations. A provider’s API documentation should resolve the product-specific contract.
Use a small example
The following JSON is a conceptual internal record, not an official schema or an ASP request template:
{
"sourceInvoiceId": "INV-DEMO-001",
"issueDate": "2026-10-21",
"currency": "AED",
"netAmount": 1000.00,
"taxAmount": 50.00,
"amountDue": 1050.00
}
Its simplicity is useful for discussion. It also reveals what it does not explain: buyer and seller identity, line data, tax breakdown, document category, scenario attributes and the intended meaning of every total.
Do not let a successful HTTP request hide those omissions. Connectivity and information completeness are separate questions.
Choose where transformation belongs
Review three options: the source prepares final invoice XML; an integration layer prepares it; or the provider converts the agreed business payload.
A single-source organisation may favour a different arrangement from a group with several billing systems. Compare maintenance responsibility, investigation effort and the process for adopting changed requirements.
For example, a centrally maintained mapping can reduce duplication across sources, but its owner needs to understand differences in business meaning. Two systems can use the same field name for different totals.
Test a failure at the boundary
Ask what happens if the payload lacks a value required for the intended scenario. Does the source reject it before transmission? Does the provider return a clear message? Can a business user locate the corresponding invoice?
Correct the data and repeat the test. Verify that the retry is controlled and linked to the earlier attempt. Avoid a design in which users create another commercial invoice simply to repeat a technical transmission.
Questions worth settling early
Does JSON reduce the underlying data requirement? A different payload format does not, by itself, change the business information needed by the target process.
Can we keep a proprietary internal format? Evaluate it against the agreed integration contract and mapping responsibilities, rather than assuming it is accepted.
Next step: use the ERP architecture guide to make the ownership decision, then review the XML example.
Reference diagram
Identify the boundary before deciding who owns conversion.
Frequently asked questions
Does JSON reduce the underlying data requirement?
A different payload format does not, by itself, change the business information needed by the target process.
Can we keep a proprietary internal format?
Evaluate it against the agreed integration contract and mapping responsibilities, rather than assuming it is accepted.
Continue your trail
You now have the E-Invoicing context.
Save this guide, continue to the next concept or return to the Knowledge Library with your context intact.
E-Invoicing
14 resources in this area.
Working on an FI-CA or IS-U implementation? I take on a limited number of advisory and architecture engagements.
Get in touch →
