ZATCA Phase 2 e-invoicing for Saudi F&B manufacturers — the 2026 implementation guide

ZATCA Phase 2 changed the game for Saudi businesses. Phase 1 (2021) required electronic invoices. Phase 2 (2023+, rolling waves) requires those invoices to be cleared with the Zakat, Tax and Customs Authority before they can be issued. The technology, the cryptography, the timing — all of it shifted.

For F&B factories, the change is acute. A juice plant might issue 200 B2B invoices a day to retail chains, distributors, hotels, and institutional buyers. Each one needs to be in the right format, signed correctly, cleared by ZATCA, and embedded with a QR code — all within seconds, all without manual intervention.

This guide walks through what the regulation actually requires and how a Saudi F&B factory implements it with AION.

What ZATCA Phase 2 actually requires

Five technical requirements stack on top of the Phase 1 obligation to issue invoices electronically:

1. UBL 2.1 XML structure. Every invoice is a structured XML document conforming to the OASIS Universal Business Language standard. Specific fields — seller VAT number, buyer VAT number (or national ID for B2C), line items with item codes, tax category and rate per line, total breakdown — must be present and validly typed.

2. TLV-encoded QR code. A Type-Length-Value encoded QR that includes seller name, VAT number, invoice timestamp, gross total, VAT total, and the ZATCA-issued UUID. The QR is rendered on the printable invoice — a buyer with the ZATCA mobile app can scan it and verify the invoice exists in ZATCA’s records.

3. XAdES cryptographic signature. The XML is signed using a certificate issued by ZATCA through their portal. The signing happens server-side; the cryptographic infrastructure has to be in place at your end.

4. Invoice hash chain. Each invoice references the cryptographic hash of the previous invoice, creating a tamper-evident chain. If anyone tries to retroactively insert a fake invoice, the chain breaks at the point of insertion.

5. Real-time clearance. For standard invoices (B2B), the document is submitted to ZATCA’s portal before it’s issued to the buyer. ZATCA returns a UUID that gets embedded in the final document. For simplified invoices (B2C), the document is reported in periodic batches rather than cleared one-at-a-time.

Penalties for non-compliance start at SAR 1,000 per malformed invoice and escalate quickly. ZATCA has shown a willingness to audit aggressively.

How AION generates compliant invoices

In the Oasis Fresh (Saudi) demo BG, the entire pipeline is wired:

1. Sales clerk posts an invoice to Panda Retail Co. or any other customer. The standard sales order workflow.
2. SLA engine fires. As part of the same transaction that posts to the GL, the SLA rules generate the ZATCA XML payload. Net, VAT (15%), gross — all auto-split per line.
3. Certificate signing. The XML is signed with the ZATCA-issued certificate uploaded to the BG configuration. XAdES signature applied.
4. QR generation. TLV payload assembled and encoded as a QR. Embedded in the invoice PDF.
5. Clearance handoff. The signed XML is sent to your configured clearance channel (direct ZATCA portal, or a clearance partner). Wait for UUID response.
6. Buyer-facing PDF. Once the UUID returns, the final PDF with QR and clearance reference is generated. Emailed to the buyer or made available for portal download.

The whole pipeline runs in seconds per invoice. A factory issuing 200 invoices a day doesn’t notice the work happening.

The implementation timeline

A Saudi F&B factory implementing AION with ZATCA Phase 2 follows roughly this path:

Week 1: ZATCA registration confirmed. You need an active VAT registration and ZATCA portal access. Cryptographic Stamp Identifier (CSID) generated via the ZATCA portal. Production and sandbox certificates issued.

Week 1-2: AION configuration. Upload the CSID and certificates to the BG configuration. Set the clearance channel (direct or partner). Configure the invoice templates with the bilingual Arabic + English layouts ZATCA requires.

Week 2: Sandbox testing. Issue 50-100 test invoices against the ZATCA sandbox. Validate clearance returns successfully for each. Verify the QR codes scan correctly with the ZATCA mobile app. Verify the hash chain is contiguous across the test invoices.

Week 3: Production cutover. Switch the endpoint from sandbox to production. Issue your first live cleared invoice. Monitor for the first week for any rejection patterns.

Week 4 onward: Steady-state operations. Standard issuance cadence. Variance monitoring (clearance failures, retry counts, average clearance time) becomes a routine ops metric.

Total: 4-6 weeks elapsed for a factory with an active ZATCA registration. The bulk of time is in the testing and validation, not the technology. The technology side of AION is configuration, not custom development.

Worked example — Oasis Fresh invoice to Panda Retail Co.

Walking through it as cfo.saudi in the demo:

1. Navigate to Sales → Invoices → New
2. Customer: Panda Retail Co. (CUST-SA-PND)
3. Items: 2,000 × Oasis Mango Juice 1L at SAR 18 each = SAR 36,000 net
4. VAT: 15% × SAR 36,000 = SAR 5,400
5. Gross: SAR 41,400
6. Click Post

What happens behind the scenes:

• SLA engine generates the GL entries: DR AR — Panda 41,400 / CR Revenue 36,000 / CR VAT Output 5,400
• ZATCA pipeline generates the UBL 2.1 XML with the line items, tax breakdown, both bilingual descriptions
• TLV QR assembled: “Oasis Fresh Beverages Co. / VAT 300000000003 / 2026-05-16T14:32:18Z / 41,400.00 / 5,400.00 / [UUID after clearance]”
• XAdES signature applied
• Hash of previous invoice (the last one Oasis Fresh issued) included
• Document submitted to clearance partner
• UUID returns within ~2 seconds
• Final PDF generated with QR, clearance UUID, and bilingual layout
• PDF emailed to Panda’s AR address

The CFO sees: “Invoice posted, cleared, sent.” No technical detail surfaces unless something goes wrong.

Common pitfalls

Pitfall 1: Treating ZATCA registration as an IT task. ZATCA registration is a tax/legal task. Your tax advisor or in-house tax team has to register the VAT account, the ZATCA portal user, and the cryptographic certificate. IT can help with the technical glue but can’t initiate the registration.

Pitfall 2: Underestimating the bilingual requirement. ZATCA requires Arabic + English on the same invoice — not “Arabic or English depending on the buyer.” Both languages, side-by-side, in the document layout. If your current system only outputs English (or only Arabic), the template work is real.

Pitfall 3: Letting the hash chain break during migration. If you’re migrating from another ERP, your historical invoices retain their original hashes from the old system. AION’s chain starts at the first invoice issued through AION. ZATCA accepts this transition, but only if you communicate the migration date clearly in your records. Don’t pretend the chain continuous when it doesn’t.

Pitfall 4: Forgetting credit and debit notes. Returns, refunds, and price adjustments each need their own ZATCA document type (credit note for returns, debit note for additional charges). They reference the original invoice’s UUID and follow the same clearance flow. Configure these from day one — don’t bolt them on later.

Pitfall 5: Single-point-of-failure on the clearance channel. Your clearance provider might have an outage. ZATCA’s own portal occasionally has windows of slowness. Your invoice issuance shouldn’t halt because of a clearance hiccup. AION queues failed clearances and retries automatically; configure the retry interval and the manual-intervention threshold.

What about simplified invoices

Most factory transactions are B2B and go through the full clearance flow. But factories often have:

• Employee canteen sales (B2C)
• Factory outlet sales (B2C)
• Sample shipments to potential customers (technical B2B but treated differently)
• Donations and free-of-charge issues (still need invoicing, with special tax treatment)

Each of these has its own ZATCA document type. Simplified e-invoices for B2C, full e-invoices for B2B, free-of-charge documents with VAT zero-rating. AION handles them all through the same engine — configuration per scenario, not separate systems.

What’s coming next from ZATCA

ZATCA continues to evolve the e-invoicing mandate. Upcoming changes include:

• Expanded waves bringing smaller businesses into scope
• Additional document types (e-credit memos, e-debit memos with new fields)
• Potential integration with the e-receipts standard

The architecture of AION — SLA-driven posting, configurable clearance channels, certificate management at the BG level — accommodates these changes via configuration. You don’t rebuild when ZATCA evolves.

Where to go from here

If you’re operating across multiple GCC countries plus Egypt, GCC VAT 2026 — multi-country in one ERP covers the broader regional picture. If you’re migrating from QuickBooks specifically, Switching from QuickBooks to ZATCA-compliant ERP walks through the data migration and clearance setup specifically for that path. For Egyptian factories, the parallel article is ETA e-invoicing in Egypt — the factory guide.