01
A structured invoice, not a document
Invoices are generated as XML following the UBL 2.1-based ZATCA schema, or as a PDF/A-3 file with that XML embedded. A rendered PDF on its own is not an e-invoice.
ZATCA Phase 2 · Kingdom of Saudi Arabia
The invoice is created at the customer's door. Clearance has to happen there too.
Phase 2 is an integration requirement, not a formatting one. For a distributor that means e-invoicing has to reach the van, the field visit and the store till — not just the back-office ERP. Here is what the mandate asks of a system, and where distribution makes it harder than it looks.
The requirement
What Phase 2 asks of your system.
Six functional requirements. None of them is satisfied by changing how an invoice looks.
02
A UUID on every invoice
Each invoice carries a universally unique identifier, distinct from your own invoice numbering, so it can be referenced unambiguously outside your system.
03
A cryptographic stamp
Invoices are signed with a cryptographic stamp keyed to a CSID that ZATCA issues during onboarding, using a XAdES-based digital signature — which is what makes the origin provable and tampering detectable.
04
A hash chain
Each invoice records the hash of the one before it, so the sequence itself is evidence. A gap or a substitution shows up as a broken chain rather than a missing document.
05
A QR code
Simplified invoices carry a QR code encoding the core invoice fields, so a buyer or an inspector can verify the invoice without access to your system.
06
Integration with Fatoora
The system connects to ZATCA's Fatoora platform and exchanges invoices with it in near real time. This is the part that makes Phase 2 an integration requirement rather than a formatting one.
Source: Zakat, Tax and Customs Authority — ZATCA e-invoicing (Fatoora). Scope and timing are set by ZATCA per wave; check their pages for yours.
Two flows
Clearance and reporting are not the same obligation.
This is the distinction that decides where in your operation the integration has to live.
Standard tax invoice · B2B and B2G
Clearance
The invoice goes to ZATCA before it reaches the buyer. ZATCA returns a cleared XML carrying its own stamp, and until it does, the invoice is not legally valid.
- Submitted and cleared before the document is shared with the customer
- The cleared XML, not your original, is the legal invoice
- A failure here is not a reporting delay — it is an invoice you cannot hand over
Simplified tax invoice · B2C
Reporting
The invoice is issued to the customer immediately and reported to ZATCA within 24 hours of issuance.
- Issued at the point of sale without waiting on a round trip
- Reported in batches or individually, inside the 24-hour window
- Connectivity gaps are survivable, but the clock does not stop for them
Why distribution is harder
Your invoices are not created in an office.
Most e-invoicing implementations assume the invoice is raised in finance. In distribution it is raised at the roadside, in a store, or on a handheld with one bar of signal.
Van sales
A cash-van settlement produces invoices at the roadside, on a handheld, against stock that moved this morning. If clearance sits in a nightly batch, the driver hands over a document that is not yet a valid invoice.
Field visits
Field sales create standard invoices at the customer's premises. Clearance has to be reachable from wherever the visit happens — which means the mobile app, not just the ERP.
Retail POS
Store tills issue simplified invoices continuously, each needing its QR code at the moment of sale and reporting inside 24 hours. Day-close is the wrong granularity.
Connectivity
Coverage in a warehouse yard or a rural route is not guaranteed. The system needs a defined answer for what happens when Fatoora is unreachable — queue, retry, and preserve the hash chain — rather than an error the driver has to interpret.
One ledger
Invoices cleared in the field, stock movements, trip settlement and collections have to reconcile against the same record. Bolting an e-invoicing gateway alongside the ERP creates a second truth to reconcile, which is the problem it was meant to solve.
Questions
What operators ask us.
No. Phase 2 requires a structured XML invoice following ZATCA's UBL 2.1-based schema — either as XML, or as a PDF/A-3 with that XML embedded. A PDF that merely displays a QR code satisfies neither the schema nor the integration requirement.
Standard tax invoices (B2B and B2G) go through clearance: they are submitted to ZATCA before being shared with the buyer, and the cleared XML that ZATCA returns is the legal invoice. Simplified invoices (B2C) go through reporting: they are issued to the customer immediately and reported to ZATCA within 24 hours.
ZATCA phases Phase 2 in by waves defined on annual revenue, and notifies the taxpayers in each wave in advance. Because the waves roll forward continuously, we deliberately do not publish thresholds or dates here — check ZATCA's e-invoicing pages for the wave you fall into, and treat any vendor quoting a fixed date with caution.
For simplified invoices the sale continues and the report is queued inside the 24-hour window. For standard invoices clearance is a precondition, so the system has to hold the document, retry, and keep the hash chain intact rather than issue an uncleared invoice. How a system behaves offline is worth testing before you buy it, not after.
Yes. Synacores generates the compliant XML, applies the UUID, cryptographic stamp and hash chain, produces the QR code for simplified invoices, and exchanges invoices with Fatoora — from the ERP, the mobile field app and the retail POS, against one ledger of record. Book a demo and we will walk through it against your own invoice flows.
Not necessarily. Compliance is a property of the system that issues invoices, so the question is whether your current stack can produce cleared, stamped, chained invoices at the point where your invoices are actually created. For distributors invoicing from vans and store tills, that is usually where an otherwise adequate back-office ERP runs out of reach.
From Field Notes
All Field Notes →- Industry
Revenue leakage is a data problem, not an accounting problem
Money doesn't usually leave a company through fraud or theft. It leaves through the seams between systems that don't reconcile — and that makes it an engineering problem wearing a finance costume.
- Industry
The Margin Leak: where distribution loses 13–19% of every logistics dollar
A field-grade accounting of the margin that leaks between systems — failed deliveries, blind handoffs, shrinkage — and why most of it never shows up on a single line of the P&L.
- Product
Inside the agentic stack: perceive, reason, plan, act
Traditional automation is brilliant at repetition and helpless at improvisation. The shift to agentic systems is the shift from generating insight a human acts on, to wiring insight directly to action — under governance.
Next step
Bring us your invoice flows.
Van settlement, field visits, store tills, returns and credit notes — we will walk through how each one clears, and where your current stack stops reaching.