If you sell to people rather than to companies, the simplified tax invoice is the document you issue all day: the barbershop receipt, the clinic bill, the online order, the workshop ticket for a private car. ZATCA defines it as an invoice generated and stored in a structured electronic format, generally issued for a business-to-consumer sale, which does not generally carry the buyer's details. Here is how one is issued, in order.
Who gets one
A consumer: a buyer with no VAT registration number. A VAT-registered business or a government body gets a standard tax invoice instead, cleared by the Authority before they receive it, because that is the document they deduct input VAT against. Who the buyer is decides it — never the amount, never whether the sale happened at a counter; standard vs simplified settles it with one question.
Once, before the first invoice
A simplified invoice cannot be typed. ZATCA requires it to be generated by a compliant e-invoicing solution that has been onboarded: connected to the Fatoora platform with a one-time code from the portal, which gives the solution the certificate it signs with. A paper invoice scanned afterwards is, in the Authority's words, not an electronic invoice. Onboarding, OTP and CSID covers that step. The same setup puts your VAT number and national address on every invoice — street, building number, district, city, postal code, country. An address copied from a commercial registration usually lacks two of those; the invoice still goes through, and BR-KSA-09, a warning, comes back on every one until it is fixed.
The steps, sale to report
- Start the invoice at the moment of sale. Not at the end of the day, not from a notebook. Choose the simplified (B2C) form; the buyer is optional, and for a walk-in customer you leave it blank.
- Add the lines. What was supplied, the quantity, the unit price and a VAT category letter: S for standard-rated, Z, E or O for zero-rated, exempt or outside the scope. If your prices are shown with VAT included, enter them that way and let the solution work back to the net.
- Issue it. The step nobody sees. The solution assigns the invoice number and a UUID, takes the next invoice counter value and the hash of the previous document it issued, builds the XML, signs it with the onboarding certificate, and generates the QR code from the signed result. Once signed, the invoice exists and the counter has moved.
- Hand it to the customer immediately. Printed, or electronically by agreement — with the QR code, and now, not later.
- Report it within 24 hours. The solution sends the signed XML to the Fatoora platform, which validates it and answers with a status. The clock runs from the moment of issue.
- Keep the signed XML. Six years, in the format it was issued in. The PDF is what a person reads; the XML carries the signature, the counter and the hash chain.
What it must carry
| Field | What it must carry | Rule and severity |
|---|---|---|
| Seller name and VAT registration number | 15 digits, first and last digit 3 | BR-KSA-39 missing, error; BR-KSA-40 malformed, error |
| Seller national address | Street, building number, district, city, postal code, country code | BR-KSA-09, warning |
| Buyer | Not required. A VAT number entered anyway must be valid | BR-KSA-44, error |
| Invoice type code (BT-3) | 388 for an invoice, 381 or 383 for its notes | BR-KSA-05, error |
| Transaction code (KSA-2) | Begins 02; export and self-billed flags stay 0 | BR-KSA-06, error; BR-KSA-31, error |
| Invoice number and UUID (KSA-1) | The number a customer reads, and a machine identifier of letters, digits and dashes | BR-KSA-03, error |
| Issue date (BT-2) and issue time (KSA-25) | Two fields; the date not in the future, the time as hh:mm:ss | BR-KSA-04, error; BR-KSA-70, error |
| Invoice counter, ICV (KSA-16) | Digits only, one up per document, never reset | BR-KSA-33, BR-KSA-34, errors |
| Previous invoice hash, PIH (KSA-13) | Base64 SHA-256 of the document before this one | BR-KSA-61, BR-KSA-26, warnings |
| Lines: name, quantity, unit price, VAT category (BT-151) | Positive values; the category one of S, Z, E, O | BR-KSA-F-04, error; BR-KSA-18, error |
| Totals | Total without VAT, VAT amount, total with VAT | Checked arithmetically |
| Cryptographic stamp (KSA-15) | The signature made with the onboarding certificate | BR-KSA-60, warning |
| QR code (KSA-14) | Base64 TLV, built from the signed XML | BR-KSA-27, warning |
An error rejects the invoice: it was never registered, and you fix the field and send the same invoice again. A warning comes back alongside acceptance: the invoice is reported, with the defect recorded against it. Even the stamp and the QR code are required by warning-severity rules, which is why a successful report proves less than it seems to.
The Phase 2 QR code carries eight TLV fields: seller name, seller VAT number, timestamp, total with VAT, VAT total, the hash of the XML, the signature and the public key. On a simplified invoice and its notes ZATCA's QR guide adds a ninth, the Authority's own signature over that public key, so a scanner can trust the key without asking anyone. The field checklist lists the tags; the glossary defines the vocabulary.
A worked example at 15% VAT
Consumer prices include VAT, so the number you type is the number the customer pays and the solution works back to the net. Take a service priced at 245.00 SAR. The net is 245.00 ÷ 1.15 = 213.0434…, rounded half-up to the halala — ZATCA's rounding rule — to 213.04. The VAT is computed from the exact figure, not the rounded one: 213.0434… × 15% = 31.9565…, rounded once to 31.96. The invoice reads 213.04 without VAT, 31.96 VAT, 245.00 total, and the three add up. Rounding the net first and multiplying that gives the same answer here, but on a ten-riyal coffee it gives 1.31 VAT against a true 1.30, and the customer pays 10.01.
A basket is settled as a whole: add a 35.00 SAR product to that service and its line is signed at 30.44 rather than the 30.43 it rounds to alone, so the lines add up to the 243.48 they are worth together — VAT 36.52, total 280.00. Where no two-decimal unit price fits, the odd halala is declared as an allowance so the totals still reconcile and the customer sees the shelf price.
Correcting one
An issued invoice is never edited and never deleted. ZATCA's guideline is explicit that a taxpayer may not modify or delete an invoice once issued, and that cancelling one is done only through an associated credit note and, where needed, a new invoice. A return, a wrong price or a cancelled order becomes a credit note (381); an undercharge, a debit note (383). The note takes the invoice's type — simplified, reported within 24 hours — and must state a reason, which BR-KSA-17 rejects it without, and reference the original, which BR-KSA-56 warns about when missing; credit and debit notes covers the rest. The correction asked about most is the business buyer who wanted a standard invoice: there is no conversion, so it is a full credit note against the simplified invoice and a new standard tax invoice to the registered buyer, cleared before you send it.
Reading the response
Reported means the invoice is registered. Reported with warnings means the same, with defects recorded against it — fix them before the next invoice repeats them. Rejected means an error-level rule failed and the invoice does not exist for the Authority: correct the field and resend the same invoice; do not credit-note it, since there is nothing to credit. The 24 hours run from issue, so a rejection is fixed the same day. How to read the error code takes the response apart; the error code reference lists every rule.
What this needs from a system
Something onboarded that signs each invoice, builds the QR code, reports within the window, shows you the response and keeps the XML. ZATCA Tools does that job in the browser, with a phone layout for the invoice form. Connecting takes one OTP from the Fatoora portal. The form has a simplified (B2C) toggle, a blank buyer for walk-in sales, saved items, and a switch for prices entered with VAT included, worked back exactly as above. Issuing signs the invoice and sends it to the Fatoora platform at that moment, not in a nightly batch; the invoice page shows the reported status and any warnings by code with a link to the guide; the PDF prints with the QR code, in Arabic with English alongside; the signed XML is archived six years and downloadable. Credit notes are issued against the invoice with a reason. No VAT number or Fatoora access yet? The trial connects you to ZATCA's sandbox without either, on a separate numbering. It is not a point of sale — no cash drawer, no barcode scanning, no inventory — and not an accounting system: no ledger, no journals, no payroll. If a store or an ERP already produces your sales, the API is the smaller change. Free to start: 50 invoices or 30 days from the day you connect, whichever comes first, then from 49 SAR a month — start here, or read the Phase 2 walkthrough first.