Saudi e-invoicing: ZATCA Phase 1
Customer invoices, credit notes and debit notes issued in Arabic and English with a QR code, numbered from one unbroken series and fixed once issued — standard or simplified, VAT categories from the tax code, the buyer’s CR number and national address, and the invoices posted before the switch issued too.
ZATCA Phase 1, the generation phase, asks a Saudi VAT-registered seller for three things: every tax invoice and note carries set content in Arabic, it carries a QR code a phone can read, and nothing issued is altered afterwards — a mistake is put right with a credit or debit note. TRANXACT does all three once the company switches it on, and nothing differently for a company that has not.
Phase 2 — the XML invoice, its cryptographic stamp and clearance or reporting through ZATCA’s platform — is not part of this. See What Phase 1 does not do, at the end.
Switching it on
Open the company’s tax jurisdiction under Accounting → Tax → Tax Jurisdictions. When its Country is SA, two more fields appear: Name (Arabic), and E-invoicing regime. Set the regime to ZATCA Phase 1 (generation) and save.
The save is refused, with every missing item listed at once, until the company can actually issue under it:
- Registered is ticked on the jurisdiction.
- Registration number is a Saudi VAT number: fifteen digits, beginning and ending with 3.
- The letterhead carries the company’s legal name in Arabic and its address in Arabic. Edit it under Platform → Printed Forms → Edit the letterhead; for a Saudi company the letterhead also asks for the building number, the district and the additional number of the national address.
Once it is on:
- The number ranges for customer invoices, credit notes and debit notes (ARINV, ARCREDIT, ARDEBIT) are numbered by the system, never reset and only move forward. The database itself refuses a change that would take a number back or reuse one.
- The bilingual forms ZATCA-A4 (invoices) and ZATCA-A4-MEMO (credit and debit notes) become the company’s default printed forms.
- Every invoice and note the company posted before the switch is issued after the fact — see Invoices posted before the switch, below.
Raising an invoice
Accounting → Payables & Receivables → AR Invoices has New invoice. It asks for the customer, the invoice and due dates, the currency (empty for the company’s own), the invoice type, the supply date and, for a supply over a period, its end date, and the lines.
| Field | What it does under ZATCA |
|---|---|
| Invoice type | Tax invoice (B2B) or Simplified tax invoice (B2C). Left empty, a buyer with a VAT number gets a tax invoice and one without gets a simplified invoice. |
| Supply date | When the goods or services were supplied. Defaults to the invoice date. |
| Lines | Description, quantity, unit price, discount, the Tax code, and the VAT category: S (standard), Z (zero-rated), E (exempt) or O (outside the scope). |
| Tax code | The usual way to say how a line is taxed. Under ZATCA the line takes its VAT category, its rate on the invoice date and its exemption reason from the tax code. A code with no ZATCA category leaves the line uncategorized — it is never guessed to be standard — and Post names the line. |
| Exemption code | On a Z, E or O line, the VATEX reason code ZATCA publishes for that reason. A Z, E or O line without one cannot be issued. |
| Tax | Not yours to type: the server works the VAT out from the category — the company’s standard rate (15% unless set otherwise) on an S line, and 0% on Z, E and O. |
Until it is posted the invoice is a draft with a provisional number beginning DRAFT-. It can be corrected, and cancelled, like any draft. It takes its real number only when it is issued, so a cancelled draft never leaves a gap in the series.
Standard or simplified, and changing it
A tax invoice (B2B, “standard”) names the buyer, the buyer’s address and VAT number; a simplified tax invoice (B2C) does not, and its buyer block is left blank by law. The type is decided when the invoice is raised: what you choose, or, left empty, a tax invoice for a buyer with a VAT number on file and a simplified one for a buyer without.
While the invoice is still a draft, Change invoice type on AR Invoices switches it. The change is logged: the Type changed column shows when it was made, the record keeps who made it, and the audit trail has both. Once the invoice is issued its type is fixed with everything else.
Tax codes carry the ZATCA category
Accounting → Tax → Tax Codes has three fields for ZATCA, shown in the list as the ZATCA column:
| Field | What it holds |
|---|---|
| ZATCA category | S — Standard rate, Z — Zero rated, E — Exempt, or O — Out of scope. |
| ZATCA exemption reason | For Z, E and O codes: the reason from ZATCA’s list — VATEX-SA-32 Export of goods, VATEX-SA-33 Export of services, VATEX-SA-35 Medicines and medical equipment, VATEX-SA-EDU Private education to citizen, VATEX-SA-HEA Private healthcare to citizen, VATEX-SA-OOS Out of scope, and the rest. |
| ZATCA exemption reason (words) | The reason as it is printed on the invoice. |
Existing VAT codes were filled in from their treatment: standard, reduced, margin scheme and deemed codes are S; zero rated is Z; exempt is E; out of scope and reverse charge are O. Out-of-scope codes were given VATEX-SA-OOS, and zero-rated codes named as exports were given the export reasons. Every other zero-rated or exempt code is left without a reason on purpose — which of ZATCA’s reasons applies is yours to say — and Post names each line until it is said.
The buyer’s details
A Saudi tax invoice names the buyer as the commercial registry knows them. On a customer whose country is SA (CRM → Accounts & Contacts → Accounts), the form adds:
- Name in Arabic.
- Commercial registration (CR) no.
- The parts of the national address: Building number, District and the four-digit Additional number. The Address Book (Platform → Classification → Address Book) asks for the same three on a Saudi address.
Under the regime the customer’s VAT number is checked when its site or financial details are saved: fifteen digits, beginning and ending with 3. A wrong one is refused there, rather than at the moment you try to issue.
Post is issue
Posting an invoice under ZATCA issues it. Everything is checked together, and anything missing is listed in one message rather than one at a time:
- the seller’s Arabic name, Arabic address and VAT number;
- a VAT category on every line, and a reason on every Z, E and O line;
- on a tax invoice (B2B), the buyer’s name, address and VAT number;
- on a credit or debit note, the original invoice and the reason.
Then, in one step: the next number in the series is taken; the issue time is stamped from the server’s clock (printed in Riyadh time); the seller’s and buyer’s details are copied onto the invoice, so a later change of address does not change an issued invoice; the VAT is shown in SAR as well when the invoice is in another currency; and the QR code is made.
The QR code is the one ZATCA specifies for Phase 1: five tags, encoded together as Base64 TLV (tag, length, value). ZATCA’s own app reads it.
| Tag | What it carries |
|---|---|
| 1 | The seller’s name. |
| 2 | The seller’s VAT number. |
| 3 | The time of issue (the server’s clock, in UTC). |
| 4 | The invoice total including VAT. |
| 5 | The VAT total. |
An issued invoice cannot be edited, deleted, cancelled or reversed, and nor can its lines. Reverse is not offered on it. To correct it, issue a credit note (or a debit note) against it.
Credit and debit notes
AR Credit/Debit Memos under ZATCA must name the issued invoice they correct, and the reason. The reason is required from the moment the note is created, not only at issue: a note without one is refused on save. A credit note cannot take the invoice below nothing: all the credit notes against an invoice together may not exceed the invoice plus its debit notes. A note is issued on Post, like an invoice, with its own number from its own series and its own QR code.
A credit note is money owed to the customer, not by them. It reduces the invoice it credits, or is paid back to the customer as a refund; it is never received against. So, for every company and not only under ZATCA:
- Apply receipt is not offered on a credit note, and the server refuses a receipt against one.
- A credit note is never shown as overdue: the AR list puts credit notes in a Credit band of their own, with no days late.
- Under the regime a receipt is also refused against an invoice that has not been issued yet.
Invoices posted before the switch (the back-fill)
A company that already had a ledger when it switched ZATCA on had invoices and notes that were posted but never issued. Switching on now issues them after the fact, and the same happens on every start of the system for anything still left. Each invoice, credit note and debit note that was posted, part paid, paid or reversed is given:
- A time of issue: its posting date (or its invoice date if it has no journal) at noon Riyadh time, so the time in the QR falls on the date the paper says.
- An invoice type: what it was given, or a tax invoice when the buyer has a VAT number on file or is a government body, and simplified otherwise. A note follows its invoice.
- A VAT category and rate on each line: from the line’s tax code where it has one, otherwise from the tax it was posted with — taxed lines are S; an untaxed line is Z for a buyer outside the Kingdom (an export) and O for a buyer inside it, with a reason saying it was categorized from a 0% posting.
- The seller and the buyer as they are on file now, the VAT in SAR, a UUID and the QR code, made from the totals it was posted with.
Nothing that was posted moves: not a total, a number, a date or the journal. The AR Invoices list marks these with Back-filled, because they were not checked when they were raised and their time of issue is a posting date rather than a clock reading.
The printed invoice
- Arabic and English side by side, with the QR code at the top right.
- The seller’s block with its Arabic name, address and VAT number, and the buyer’s block — omitted on a simplified invoice.
- VAT per line with a VAT category column, a VAT summary by category with the Arabic totals in their own cells, the VAT summary in words with thousand separators, the exemption reason for each Z, E or O line, and the VAT in SAR.
- A note’s title says which kind of invoice it belongs to; a note carries the original invoice and the reason.
- The time of issue, in Riyadh time.
A correct invoice prints with no warning. Fields that are blank on purpose — the buyer block of a simplified invoice, the note fields on an invoice, the QR on a draft, the SAR line on an invoice already in SAR, the exemption list when there are no exemptions — no longer raise a blank-field warning.
What Phase 1 does not do
Phase 2 — the XML invoice, the cryptographic stamp, the hash chain and clearance or reporting through ZATCA’s platform (Fatoora) — is not part of this. The fields Phase 2 needs are reserved: every invoice is given its UUID at issue, so it already has the identity Phase 2 will report it by, and the invoice hash, the previous invoice’s hash and the counter are kept empty until Phase 2 fills them.
Since 12 October, Phase 2 can be switched on on top of Phase 1: each invoice is then stamped as it is posted. A company that stays on Phase 1 is unchanged. See ZATCA Phase 2: signing units and the stamp at posting.
Kept for as long as the law asks
Invoices and notes issued under ZATCA, the record of each time they were printed, and the company’s audit log are never archived or purged by a data retention policy, whatever the policy says. See Keeping and removing old data.