ZATCA E-Invoicing and Your ERP: The 2026 Compliance and Integration Guide

If you run a VAT-registered business in Saudi Arabia, the definition of "invoice" has changed even if the paper still looks the same. An invoice is no longer a document you print and file; it is structured data that the Zakat, Tax and Customs Authority (ZATCA) expects in a defined format and, in many cases, wants to receive or clear electronically at the moment of issue. That shift — the Fatoora e-invoicing programme — changed what an invoicing system or ERP has to do.

The problem is rarely refusal to comply. It is treating compliance as an accounting detail: a QR code added to the old template, or a verbal assurance that "the system is compliant." Then the integration notification arrives, and the company discovers the vendor cannot integrate, or that branch terminals issue invoices that do not match what reaches accounting — and a rushed migration begins under time pressure.

This guide is for the owner and the finance manager, not the developer: what the two phases mean in practice, what compliance demands from a system, how to test your current one yourself, how an integration project runs, and where companies fail. We write it at Jad Digital (جاد للتطوير الرقمي) from building invoicing modules inside ERP systems for Saudi clients. Regulations evolve, so confirm current details with ZATCA or your tax advisor.

Before Fatoora it was enough to issue a document with the right content and keep a copy. Now your system must produce a file in a defined format, with mandatory fields, controls that prevent editing or deletion, and a sequence proving no invoice was removed. Compliance is a property of the system, not of the template.

One practical consequence follows. Every tool in your company that issues invoices is in scope — the branch point of sale, the online store, the subscription platform, the accounting package, the spreadsheet that bills monthly contracts. If you have more than one source of invoices, you have more than one potential compliance problem.

A second consequence is less obvious: compliance now constrains how you run the business day to day. You can no longer "adjust the invoice after agreeing with the customer" or cancel a sale by deleting it. Every correction must pass through a linked document, which means revisiting old habits in sales and accounting before changing any software.

This phase began in December 2021 and applies to every VAT-registered business: invoices are generated and stored electronically through a compliant system rather than by hand or in Word and Excel. A simplified invoice must carry a QR code, every invoice must include the required fields, and an issued invoice cannot be deleted or edited — corrections go through a credit or debit note referencing the original.

This is the phase that unsettles companies. Your system connects directly to ZATCA's platform, so invoicing stops being internal and becomes a live exchange with an outside party. Businesses enter in waves notified by ZATCA based on published revenue thresholds: check the latest wave announcements, or the notification sent to your business.

That difference is why "compliant system" is an insufficient phrase. Always ask: compliant with which phase, and for which invoice type? Many systems handle a QR-coded simplified invoice well, then stall at the first tax invoice that needs live clearance and a platform response.

• Clearance applies to tax invoices, mostly B2B. The invoice goes to ZATCA before it reaches the customer and is not valid until accepted, so your system needs a live wait, a response, and rejection handling.
• Reporting applies to simplified invoices, mostly consumer. The invoice is given to the customer immediately and reported within the required window. This matters at the till: a cashier cannot wait.

This is the list to put in front of any vendor:

• Invoices in XML, on the UBL standard, with every mandatory field: seller and buyer details, VAT numbers, line items, VAT breakdown, totals.
• A human-readable PDF/A-3 with the XML embedded: the customer needs a document, the authority needs the data.
• A compliant QR code on simplified invoices, with the specified fields and encoding — not a QR image carrying a link.
• Cryptographic stamping, hashing and sequencing: each invoice signed and chained to the previous one, so any gap is visible.
• Onboarding of each solution or device with ZATCA, with certificates for every issuing unit — often forgotten in branches.
• Platform integration for clearance and reporting, handling rejections and warnings correctly.
• Credit and debit notes linked to the original invoice, because deletion is not an option.
• Secure archiving for the retention period, with audit logs showing who did what.
• Offline behaviour: a local queue and automatic retry that neither loses nor duplicates an invoice.
• Arabic first: invoices issued in Arabic, English optional — the exact point many international systems get wrong.

You do not need a developer to run this today:

Every "no" is an action item, not an opinion. Keep the answers in writing — they become the scope of your integration project.

• Ask for the XML of a real invoice. If the system cannot export it, it produces a document, not data.
• Scan the QR code on a simplified invoice with a verification app: does it show the required invoice data, or a generic link?
• Try to delete an issued invoice. If you can, the system is non-compliant by design.
• Issue a credit note and confirm it references the original invoice and appears linked to it in reports.
• Ask about integration status: is the system connected today? Ask to see a real clearance response log, not an explanation.
• Disconnect a till for two minutes, issue an invoice, reconnect, and confirm it arrived exactly once.
• Compare invoice sources: do the store, the tills and accounting agree, or does one renumber?

1. Assessment and inventory. List every source of invoices (branches, tills, store, contracts), the types at each, and peak daily volume. This document defines the project's size more than anything else.

2. The route decision. Adapt the current system, connect compliant invoicing middleware, or move to a new system — a financial and operational decision, not only a technical one.

3. Onboarding and certificates. Register issuing units with ZATCA, obtain certificates, set master data: VAT number, commercial registration, national address, per-item tax settings.

4. Build and test in the sandbox. Send invoices to the test environment until every case passes: standard, simplified, credit note, exempt line, discount, partial return.

5. A pilot in one branch. A week in a real branch reveals what no test does: latency, cashier behaviour, printers, peak-hour exceptions.

6. Rollout and training. Gradual deployment with short written guidance: what to do when an invoice is rejected, how to issue a credit note, when to call support.

7. Monitoring after go-live. A daily view of invoices sent, accepted and rejected, with reasons. Compliance is not an event; it is a number you watch.

• Treating it as a template change. A QR code on an old layout does not make a system compliant; the data structure and integrity controls underneath count.
• Disconnected systems. A till in the shop, Excel in the office and an accounting package re-keyed by hand produce mismatched numbers and reporting gaps.
• Waiting for the notification before planning. A company that starts after its wave notification works under pressure and pays for the hurry.
• Ignoring the exceptions. Partial returns, post-sale discounts, cancellations, a customer with no VAT number — these break systems, not ordinary sales.
• Manual database corrections. Any edit outside the credit-note path breaks the chain and shows up in the first review.
• A vendor who will not commit to maintenance. Specifications change; who maintains the integration a year from now? Make it a contract clause.

In retail and food service, simplified invoices dominate and speed is an operational requirement. A sound system issues the invoice immediately, stamped and QR-coded, then reports in the background, never holding the queue for the network. Every issuing device needs its own onboarding and certificate, every branch its own view of rejected invoices, and syncing with inventory and accounting should be automatic.

One detail many miss: older terminals may struggle with signing and storage requirements, and some thermal printers render the QR code too poorly to scan. Test scanning with an ordinary phone on real paper before rollout. If you run mobile carts on cellular networks, make the offline test mandatory in the pilot.

Legal responsibility towards ZATCA sits with the business, not the software vendor, whatever the contract says. That is why projects fail when handed entirely to one party. The split that works: finance owns the decisions — invoice types, returns and discounts, reconciliation with the VAT return. IT or the vendor owns execution — format, stamps, integration, monitoring. Operations owns reality — what the cashier does when an invoice is rejected.

Before you start, name one person accountable and give them authority to halt the rollout if the pilot fails. Projects that stall rarely stall for technical reasons; they stall because nobody owned the decision.

Ready-made systems widely used in Saudi Arabia have generally built support for both phases, and for a trading or services company with standard operations they are often the fastest route. The right questions: does the vendor actively maintain the integration, does the system fit your operations without reshaping the business around it, and are licensing and customisation reasonable at your size?

A custom system makes sense when operations are specific: project-based contracting with progress billing, manufacturing with layered costing, multi-branch retail with loyalty, or a subscription model. There, compliance is designed into the invoicing module while the rest reflects how you actually work. We cover the trade-off in custom vs ready-made ERP, and the same decision at accounting level in ready-made or custom accounting software.

Either way: verify compliance, do not assume it. Ask any vendor for a genuinely cleared invoice from a real client, with the platform response log — not a slide.

A Riyadh restaurant chain with five branches. The problem is not the invoice but the peak: hundreds of simplified invoices an hour and an unstable connection in one branch. The answer is a design that issues locally and reports in the background through a safe queue, with every device onboarded, a dashboard covering all five branches so rejected invoices surface the same day, and a link to inventory. One case deserves its own design: orders through delivery apps, where the invoice may be issued by another party — make it explicit who issues what, so sales are not counted twice.

A Jeddah wholesaler selling to businesses. Here tax invoices dominate and need clearance before delivery, and customers request changes after shipping. The answer is to connect the whole sales cycle: quotation, sales order, delivery, cleared invoice, with linked credit notes and a customer statement that matches what was reported. This kind of business also needs clean customer data: one wrong character in a VAT number becomes a rejected invoice and a shipment stuck at the door.

• A written inventory of every invoice source in the company
• Invoice types identified: tax invoices needing clearance, simplified needing reporting
• XML export, compliant QR code and PDF/A-3 proven in practice
• Deletion and editing blocked, with a working credit-note path
• Issuing units onboarded and certified in every branch
• Defined offline behaviour: queue and retry, no duplication
• Daily monitoring of rejected invoices and their reasons
• A contractual commitment to maintain the integration
• Arabic invoices in SAR with correct VAT rounding
• Exceptions reviewed: partial return, discount, cancellation, no VAT number

Done properly, e-invoicing is not a burden but free data infrastructure. Because every sale is structured data, you get live revenue and VAT reporting, cleaner receivables, fewer disputes because there is one record, and a straightforward VAT return. Companies that connect invoicing to inventory, projects and a CRM system stop reconciling spreadsheets and start seeing the business as it happens. If your online store is an invoice source, see also the requirements for launching an online store in Saudi Arabia.

We design the invoicing module in the ERP and CRM systems we build for Saudi clients with the Fatoora requirements from day one: compliant document structure, QR codes, stamping and chaining, credit-note workflows, Arabic invoices in SAR, and readiness for phase-two integration — connected to sales, inventory and point of sale so nothing is entered twice. If you already have a system, we audit it against the checklist above and recommend adapting or migrating, honestly. For choosing a partner, see our guide to software companies in Saudi Arabia.