Most ZATCA rejections are not caused by a bad decision about software. They are caused by a missing field: a buyer VAT number that was never captured, a QR code built from the wrong values, a credit note issued without a reason for issuance. The Fatoora platform validates structure, and structure is unforgiving.

This is a field-by-field checklist of what a compliant electronic invoice has to carry in Saudi Arabia — what applies to every invoice, what changes between standard and simplified documents, and which parts your billing system must generate for you because no human can type them. If you are still getting oriented in the regime as a whole, start with our complete ZATCA e-invoicing (Fatoora) Phase 2 guide and come back to this page when you are ready to audit your own invoice layout.

Two invoice types, two field lists

Everything in ZATCA e-invoicing branches from one question: who is the buyer?

  • Standard tax invoice — business-to-business and business-to-government. It must be cleared by ZATCA before you hand it to the buyer, so the field list is stricter and the buyer's details matter.
  • Simplified tax invoice — business-to-consumer, typically a point-of-sale receipt. It is given to the buyer immediately and reported to ZATCA afterwards, within 24 hours of issuance.

The two documents also carry different invoice subtype flags inside the XML, which is how ZATCA knows which validation ruleset to apply. Getting the type wrong is one of the quietest ways to fail compliance: the invoice looks perfect on paper and is judged against the wrong rules. We break the distinction down in detail in simplified vs standard tax invoices in Saudi Arabia.

Work through the shared list below first, then add the extras for the type you are issuing.

The core fields every tax invoice must carry

Whatever the type, these have to be present and correct:

  • The document title — the invoice must identify itself as a tax invoice (or simplified tax invoice), in Arabic.
  • Seller name and address — the legal name registered with ZATCA, not a trading name you use on the website.
  • Seller VAT registration number — the 15-digit number. It begins and ends with 3, and the digits in between are not decorative: a transposed digit fails validation.
  • Other seller identifiers where applicable — commercial registration number or the equivalent (national ID, licence numbers) depending on how the business is registered.
  • Invoice issue date, and for electronic invoicing also the issue time — the timestamp is part of what is hashed and encoded, so "date only" is not enough.
  • Invoice number — a unique, sequential identifier from your own numbering series.
  • Line-level detail — description of the goods or services, quantity, unit price, and any discount applied to the line.
  • Taxable amount per line, the VAT rate applied, and the VAT amount.
  • Total excluding VAT, total VAT, and total including VAT for the document as a whole.
  • The VAT category and, where VAT is not charged at the standard rate, the reason — zero-rated exports, exempt supplies and out-of-scope items all need the category code plus a stated reason, not a blank tax column.

The standard VAT rate in the Kingdom is 15%, and it applies unless a specific exemption or zero-rating covers the supply. If you are not certain which category a particular supply falls into — medicines, exports, some financial services, real estate — resolve that before it reaches an invoice; our overview of VAT in Saudi Arabia: rates, registration and returns covers the ground, and ZATCA's own guidance is the authority on edge cases.

What a standard tax invoice adds

For B2B and B2G documents, the buyer stops being anonymous:

  • Buyer name and address — the registered legal name of the customer.
  • Buyer VAT registration number — mandatory when the buyer is VAT registered. This is the field most often missing in practice, because sales teams collect a company name and an email and nothing else. Capture the VAT number when the customer record is created, not when the invoice is due.
  • Buyer's other identifier where the buyer is not VAT registered but the transaction still requires identification.
  • Supply date, where it differs from the invoice date.
  • Payment terms and due date, where applicable.

Standard invoices go through clearance: the invoice is submitted to ZATCA, validated and returned with a cryptographic stamp before it is legally valid to share with the buyer. An uncleared "standard invoice" sitting in a customer's inbox is not a tax invoice — it is a PDF.

What a simplified tax invoice adds

Simplified invoices drop most buyer detail but add one non-negotiable element:

  • A QR code, printed on the invoice and scannable. On a simplified invoice this is not decoration — it is the mechanism by which anyone, including an inspector, can verify the document.
  • Buyer details only when the buyer asks for them or when the transaction requires identification.

Simplified invoices are not cleared in advance. You issue them to the customer immediately and report them to ZATCA within 24 hours. That makes correct-by-construction generation even more important here: nobody at ZATCA is going to catch your mistake before the customer walks out with the receipt.

The technical layer your software must generate

These fields cannot be typed by a person. They are produced by the e-invoicing solution, and they are the real difference between a nice-looking PDF and a compliant electronic invoice:

  • UUID — a universally unique identifier for the document, separate from your human-readable invoice number.
  • Invoice Counter Value (ICV) — a strictly incrementing counter across all invoices generated by that solution unit.
  • Previous Invoice Hash (PIH) — the hash of the preceding invoice, which chains your documents together. Break the chain (by restoring an old database, or running two systems against one counter) and every subsequent invoice is suspect.
  • Invoice hash — a hash of the current document.
  • Cryptographic stamp — applied using the certificate tied to your solution unit, obtained during onboarding.
  • QR code — a base64-encoded TLV structure carrying, at minimum, the seller name, seller VAT number, invoice timestamp, invoice total including VAT and the VAT total; Phase 2 adds hash and signature elements.
  • The UBL 2.1 XML document itself — the invoice is the XML. The PDF/A-3 with the XML embedded is what humans read.

If any of that sounds like something you would rather not implement yourself, that is the correct reaction. The mechanics of the encoding are covered in the ZATCA QR code and XML/UBL invoice format, and the onboarding, certificate and integration side is in Phase 2 integration requirements and rollout waves.

Credit and debit notes have their own rule

A credit note or debit note is an electronic document in its own right, with the same field discipline as the invoice it corrects, plus two additions:

  • A reference to the original invoice being corrected.
  • The reason for issuance — a stated, human-readable reason. A blank reason field is a validation failure, and "correction" is not a reason.

Note also what you cannot do: you do not fix a cleared or reported electronic invoice by editing it. You issue a credit note. Any workflow that still lets a user open last month's invoice and change the amount is a compliance problem, whichever country you are billing in.

Language, currency and rounding

Three details that trip up businesses selling internationally from the Kingdom:

  • Arabic is mandatory. The invoice must be issued in Arabic. You may add another language alongside it — a bilingual Arabic/English layout is common and perfectly acceptable — but Arabic cannot be the one that is missing.
  • Foreign currency is allowed, SAR is required. You can invoice in USD or EUR, but the VAT amount must also be shown in Saudi riyals, using an accepted exchange rate for the supply date.
  • Rounding must be consistent. VAT is computed to two decimals and the document totals must reconcile with the sum of the lines. Validation compares your stated totals against the arithmetic; a half-halalah discrepancy from inconsistent rounding will be rejected.

A pre-flight audit you can run this week

Take one recent invoice of each type out of your system and check it against this list, in this order:

  1. Is the seller VAT number exactly 15 digits, starting and ending with 3, and identical to the one on your ZATCA registration?
  2. Is the document labelled as the correct type, and does the XML subtype match that label?
  3. For every B2B invoice: is a buyer VAT number present?
  4. Does every line carry a VAT rate and, where that rate is not 15%, a category code and a reason?
  5. Do the line totals add up to the document totals, to the halalah?
  6. Does the QR code actually scan, and do the values it returns match the printed invoice?
  7. Is Arabic present on the face of the document?
  8. If the invoice is in a foreign currency, is the VAT shown in SAR as well?
  9. For credit notes: is the original invoice referenced and the reason stated?

Nine checks. An invoice that survives all nine is structurally in good shape; the remainder of compliance is the integration layer, which is a property of the system rather than of each document.

Why the checklist belongs in the software, not in a procedure

You can enforce all of the above with a written procedure and a careful finance team, and it will work until the week somebody is on leave. Field-level compliance is exactly the kind of work that should be structurally impossible to get wrong: the VAT number validated when the customer is created, the Arabic label part of the template, the counter and hash chain maintained by the system, the QR code generated from the same values that are printed rather than from a second calculation.

That is the test worth applying when you evaluate a vendor — not whether the marketing page says "ZATCA compliant", but whether the product makes an incomplete invoice unsendable. We wrote up the questions to ask in how to choose ZATCA-compliant e-invoicing software.

Facturi handles the structural side for you — Arabic-first invoice templates, VAT number validation, per-line tax categories, the UBL XML and the QR code generated from the invoice itself, and multi-currency billing with SAR totals. Create your first compliant invoice with Facturi and check it against the nine points above.

Verify against the source before you go live

ZATCA publishes the e-invoicing implementation resolution, the data dictionary and the XML implementation standard, and it updates them. The field list above reflects the requirements as they stand for businesses issuing invoices under Phase 2, but wave dates, technical specifications and validation rules are changed by ZATCA and not by anybody's blog. Before a go-live, check the current documentation on zatca.gov.sa, and if your circumstances are unusual — mixed supplies, agency billing, self-billing arrangements — take professional tax advice in the Kingdom rather than relying on a general guide.