ZATCA e-invoicing moved from a compliance checkbox to an integration project the moment Phase 2 arrived. If you sell online in Saudi Arabia, your checkout and your invoicing system now have to talk to a government platform in real time.
What changed between Phase 1 and Phase 2
Phase 1, the generation phase, required taxpayers to issue structured electronic invoices instead of handwritten or free-form PDFs. It was largely a formatting and record-keeping change that most accounting packages absorbed.
Phase 2, the integration phase, is materially different. Invoices must be generated in a prescribed XML format, cryptographically stamped, and either cleared with or reported to ZATCA's Fatoora platform through a compliant integration. For online stores this means the invoicing flow becomes part of the transaction path rather than a back-office task.
The two invoice types and why the difference matters
| Standard invoice (B2B) | Simplified invoice (B2C) | |
|---|---|---|
| Typical use | Business customers, VAT-registered buyers | Consumers, retail and most ecommerce |
| ZATCA process | Cleared before issuance | Reported after issuance |
| Timing | Real time, before sending to buyer | Within 24 hours of issuance |
| QR code | Required | Required and must be scannable |
| Buyer VAT number | Required | Not required |
Most consumer ecommerce runs on simplified invoices, which are reported rather than cleared. That is operationally kinder — a ZATCA outage does not block your checkout — but it does mean you need reliable queuing and retry logic, because the 24-hour reporting obligation does not pause when an API does.
What your store actually needs
- A compliant e-invoicing solution. Either a certified provider integrated into your platform, or your own solution built to ZATCA's technical specifications and passed through their compliance checks.
- Cryptographic stamp identifiers. Onboarded through ZATCA's portal and stored securely, with a defined renewal process before expiry.
- Correct XML generation. UBL 2.1 based, with every mandatory field populated — including line-level VAT breakdowns that many storefronts do not natively produce.
- A compliant QR code. Base64 TLV encoded, containing seller name, VAT number, timestamp, total with VAT and VAT amount. It must be scannable on the customer's copy.
- Archival. Invoices retained in their original electronic form for the statutory period, retrievable on request.
The compliance failure that costs money is almost never the XML schema. It is a queue that silently stopped retrying three weeks ago.
Where implementations go wrong
- No retry and dead-letter handling. Reporting fails intermittently. Without a retry queue and alerting, invoices quietly go unreported until an audit surfaces them.
- Credit notes and refunds ignored. Returns generate credit notes that carry their own reporting obligation and must reference the original invoice.
- Rounding mismatches. Line-level versus invoice-level VAT rounding differences cause rejections that are tedious to diagnose after the fact.
- Certificate expiry. Cryptographic stamp identifiers expire. Without a calendar reminder and a renewal runbook, reporting stops without warning.
- Arabic field handling. Seller and buyer names in Arabic must encode correctly through the entire chain, including the QR payload.
- Test environment only. Passing in the sandbox and never validating a production invoice end to end is a surprisingly common gap.
Buy or build?
For most Saudi online stores, integrating a certified provider is the correct commercial answer. The specification changes, certificates rotate, and maintaining your own implementation means owning that burden permanently for no competitive advantage.
Building in-house makes sense in narrower cases: very high invoice volumes where per-invoice provider fees become material, unusual invoicing logic that providers cannot model, or environments where data cannot leave your infrastructure. Even then, isolate the ZATCA integration behind a single service boundary so the rest of your platform is insulated from specification changes.
Platform-specific notes
- Salla and Zid handle much of this natively as Saudi platforms, which is a genuine advantage for smaller merchants.
- Shopify and WooCommerce need an app or plugin from a certified provider, plus careful testing of refund and partial-refund flows.
- Custom and headless stores need a deliberate invoicing service with its own queue, retry policy, monitoring and alerting — treat it as infrastructure, not a feature.
A practical readiness checklist
- Confirm which invoice types your business issues, including edge cases like B2B orders through a consumer storefront
- Select and onboard a certified solution, or scope a build with an explicit maintenance owner
- Complete ZATCA onboarding and store cryptographic credentials securely
- Validate a real production invoice end to end, then scan the QR code with a phone
- Test credit notes, partial refunds and cancelled orders explicitly
- Add monitoring and alerting on reporting failures, with a named person receiving the alerts
- Diarise certificate renewal well before expiry
- Confirm archival meets the retention requirement and is actually retrievable
None of this is technically difficult. It fails when it is treated as a one-off launch task rather than an operational system with an owner.
Frequently asked questions
Does ZATCA e-invoicing apply to online stores?+
Yes. Any VAT-registered business in Saudi Arabia issuing invoices, including ecommerce, falls within scope. Most consumer online orders are simplified invoices, which must be reported to ZATCA within 24 hours of issuance.
What is the difference between clearance and reporting?+
Standard B2B invoices must be cleared by ZATCA before being issued to the buyer. Simplified B2C invoices are issued first and reported to ZATCA within 24 hours.
Do I need a QR code on every invoice?+
Yes. Both standard and simplified invoices require a compliant Base64 TLV encoded QR code containing seller name, VAT number, timestamp, total including VAT and the VAT amount, and it must be scannable.
Can Salla or Shopify handle ZATCA compliance?+
Salla and Zid provide native support as Saudi platforms. Shopify and WooCommerce require an app or plugin from a certified solution provider, with careful testing of refund and credit-note flows.
What happens if invoices are not reported on time?+
Non-compliance can result in penalties from ZATCA. The practical risk for most merchants is a silently failing integration that goes unnoticed until an audit, which is why monitoring and alerting matter.
Should we build our own ZATCA integration?+
Usually not. Certified providers absorb specification changes and certificate management. Building in-house is justified mainly at very high invoice volumes, with unusual invoicing logic, or where data residency prevents third-party processing.