ZATCA E-Invoicing (Fatoora): What Store Owners Need to Know
If you run an online store in Saudi Arabia, e-invoicing is no longer something you can put off. It is now part of the basic infrastructure for any business registered for VAT. The Zakat, Tax and Customs Authority (ZATCA) requires businesses to issue invoices digitally through a unified system called Fatoora, with precise technical specifications for how an invoice looks, what it contains, and how it is stored.
The problem is that many store owners hear the terms — QR, XML, CSID, the integration phase — without a clear picture of what they mean for their store specifically. This article explains the topic the way a business owner needs it, not a tax engineer: what e-invoicing is, its phases, what changes in your store, and how to approach integration without disrupting sales or risking penalties.
What e-invoicing actually is
An e-invoice is not just a PDF you email. It is an invoice created and stored in a structured electronic format through a system compliant with the Authority's requirements, containing every element ZATCA mandates. A handwritten or scanned (image) invoice does not legally count as an e-invoice.
The Authority distinguishes between two main types, and it matters where your store falls:
- Tax Invoice: typically issued between businesses (B2B) and requires more detailed data, such as the buyer's VAT number.
- Simplified Tax Invoice: issued to the end consumer (B2C), the most common type for stores and retail, and it must include a QR code.
- Alongside these are Credit and Debit Notes for returns and adjustments, subject to the same requirements.
In practical terms: a consumer-facing online store mostly issues simplified invoices, and each one must carry a QR code containing core data such as the seller's name and VAT number, the invoice total, the VAT amount, and a timestamp.
The phases of e-invoicing
The Authority rolled out e-invoicing in two consecutive phases, each with very different technical requirements:
- Phase One — Generation: started in December 2021. Businesses must issue invoices through a compliant electronic system and store them digitally, adding a QR code to simplified invoices. There is no direct connection to the Authority in this phase.
- Phase Two — Integration: applied in waves defined by the Authority based on a business's revenue. Here you must connect your system directly to the Fatoora platform via APIs.
The key difference in Phase Two is that an invoice is not valid simply because you printed it. Tax invoices (B2B) must be sent to the Authority for prior clearance before being handed to the customer, while simplified invoices (B2C) are reported to the Authority within 24 hours of issuance. This means your system no longer works in isolation — it talks to the Authority's platform on nearly every sale.
The Authority notifies each business of its Phase Two wave date well in advance. The general rule: the larger your revenue, the earlier you join. Do not wait for the notice to start preparing technically — the setup takes time.
What this means for your online store specifically
If your store sells to end consumers, the most important change is that every successful order must generate a simplified invoice in the required format, carrying a correct QR code, and stored as compliant XML. That sounds simple, but it touches several points in the purchase journey:
- Store data: your business name, VAT number, and national address must be recorded accurately in your system, because they appear on every invoice.
- VAT calculation: the store must compute VAT (15%) correctly at the line-item level, handling exempt or zero-rated items where applicable.
- Returns: any refund or partial cancellation needs a credit note linked to the original invoice, not just a tweak in the dashboard.
- Archiving: structured copies of e-invoices must be kept for at least six years.
The point many miss: off-the-shelf store platforms do not necessarily generate ZATCA-compliant invoices by default. Some print a good-looking invoice that lacks the proper XML structure and the compliant QR. A nice-looking layout does not mean technical compliance.
How integration works technically
In Phase Two, your system goes through three core steps to connect with the Fatoora platform. It helps to understand them even if you are not the one implementing them:
- Onboarding: your system requests a cryptographic certificate (CSID) from the Authority using an OTP from the Fatoora portal. This certificate is the system's identity with the Authority.
- Generating the invoice in the correct format: the invoice is built as XML following the UBL standard, then signed with a cryptographic stamp and a QR code.
- Sending to the Authority: the invoice is submitted via API either for prior clearance (tax invoices) or for reporting (simplified invoices), and the Authority returns a response of accepted, rejected, or accepted with warnings.
This process is sensitive because it happens at the moment of sale. If the Authority's platform is temporarily down or the connection fails, your system must handle it gracefully: store the invoice and resend it later for simplified invoices, without blocking the customer from completing the purchase. Designing a retry mechanism and failure monitoring is not a luxury — it is what protects your sales from grinding to a halt.
Practically, you have two options: use an approved solution provider that connects your store to the Authority, or build the integration directly into your system if your store is custom and you need full control. The first is faster to start; the second suits stores with complex logic or a volume large enough to justify investing in a dedicated integration.
Common mistakes and how to avoid them
From working with Saudi stores at different stages, a few avoidable mistakes keep recurring — and early planning prevents all of them:
- Waiting until the wave notice arrives to start technical preparation, then working under time pressure.
- Assuming the store platform 'handles everything' without actually verifying the invoice format and QR compliance.
- Neglecting return and partial-cancellation scenarios, which surfaces accounting reconciliation problems later.
- Having no plan for how the system behaves when the connection to the Authority drops during peak hours.
- Ignoring the accuracy of core data (VAT number, national address), causing the Authority to reject invoices for reasons that could have been fixed upfront.
The practical takeaway: treat e-invoicing as part of your store's architecture, not a bolt-on afterthought. Start by reviewing your store's current state, confirm which phase applies to you, and verify that your system genuinely issues compliant invoices — not invoices that merely look compliant. Preparing early is always cheaper than fixing things after a penalty.
Thinking about Web development?
Get a dedicated engineering team that builds this and keeps shipping it, fully managed by Kader.
