Somewhere in your invoicing system is a field that says standard or simplified, and it probably looks like a formatting choice. It is not. It decides whether the Authority sees the invoice before your customer does, what data the document must carry, and whether your customer can deduct the VAT on it. Everything else in Saudi e-invoicing is machinery. This is the decision.
The question that decides it
Is the buyer a VAT-registered business or a government body, buying in that capacity? If yes, you owe them a standard tax invoice. If the buyer is an individual consumer, you issue a simplified tax invoice.
Note what does not decide it: not the amount, not whether the sale happened at a counter or by transfer, not whether you sold goods or a service. A small sale to a registered company is a standard invoice; a very large sale to a private individual is a simplified one.
What a standard tax invoice must carry
The document identifies both parties. Your own VAT number and a complete national address are mandatory, and the address is six elements: street name, building number, district, city, postal code and country code. One missing element is a rejection, which is where most first-time failures come from — the address printed on a commercial registration usually carries neither the district nor the building number, so take the six from your national address rather than from the CR. See BR-KSA-09.
The buyer side is lighter than people expect: the buyer's VAT registration number, and a buyer address of street, city and country code — three elements, not the six you owe as the seller. Those are precisely the fields a simplified invoice does not carry.
Then the invoice must be cleared. Your system signs the XML and sends it to the Authority, which validates it and returns it cleared. Only then may you give it to the buyer. In practice that is a short pause at the moment of issue, and the document your customer receives is one the Authority has already seen and stamped.
What a simplified tax invoice must carry
Your details, the goods or services, the VAT, and a QR code. The buyer is not identified, because for VAT purposes there is nothing to identify: a consumer deducts nothing.
You hand it over immediately. The transmission to the Authority is reporting, and it has to happen within 24 hours of issue. This is deliberate design, not leniency: a shop's tills must not stop because a network call is slow. A standard invoice genuinely cannot be issued until clearance returns; a simplified one genuinely can.
Side by side
| Standard tax invoice | Simplified tax invoice | |
|---|---|---|
| Buyer | Business or government (B2B, B2G) | Consumer (B2C) |
| Buyer VAT number | Required | Not required — and must be valid if present |
| Buyer address | Required — street, city, country code | Not required |
| Sent to the Authority | Clearance, before the buyer sees it | Reporting, within 24 hours |
| When the buyer receives it | After it comes back cleared | Immediately |
| Document type (BT-3) | 388 | 388 |
| Transaction code (KSA-2) | Begins 01 | Begins 02 |
| QR code | Returned with the cleared document | Generated at issue |
| Buyer can deduct input VAT | Yes | No |
| Correcting document | Standard credit or debit note | Simplified credit or debit note |
One row of that table surprises people: the document type field is 388 for both, because an invoice is an invoice. What separates them is the seven-digit transaction type code, KSA-2, read in the order NNPNESB. The first two digits are the subtype — 01 tax invoice, 02 simplified — and the remaining five are 0-or-1 flags for third party, nominal, export, summary and self-billed. An ordinary local B2B invoice is 0100000; a consumer sale is 0200000. Two of those flags are closed to a simplified invoice: export and self-billed cannot be set on an 02 document, which is another way of saying an export sale is never simplified. BR-KSA-06 takes the field digit by digit.
What it costs to get it wrong
Issue a simplified invoice to a business and it will usually be accepted. Nothing appears to break. The damage lands weeks later in your customer's accounts department: input VAT cannot be deducted against a document that does not identify the buyer, because the deduction has to be supported by a tax invoice naming the person claiming it — the exact wording is on zatca.gov.sa. They ask you to reissue, and you cannot edit the original, because a signed and transmitted invoice is immutable. The correction is a credit note cancelling it plus a new standard invoice — two extra documents in your chain, and a customer who now doubts your invoicing.
The reverse mistake is louder and cheaper. Put a half-typed VAT number on a simplified invoice and it is rejected outright: if the field is present it must be fifteen digits starting and ending with 3, as BR-KSA-44 explains. A rejection you can see is always better than a compliance failure you cannot.
If your business does both
Most do. A workshop servicing company fleets also sells to walk-in customers; an online store has both kinds of buyer in one order table. The rule that survives real staff: do not make the person at the till choose. Derive the type from the customer record. A customer with a stored VAT number and address produces a standard invoice; a customer without one produces a simplified invoice. The only human decision left is asked before the sale, not after: are you buying for a company? That one question, asked at the right moment, removes almost every credit note discussed above.
Notes inherit the type
A credit note (381) or a debit note (383) is not a free-standing document. It takes the type of the invoice it corrects and follows the same road: a note against a standard invoice is cleared, a note against a simplified invoice is reported. It must also carry a reference to the original invoice and a stated reason for being issued — a note with no reason is rejected under BR-KSA-17. There is no cancel-invoice type in Phase 2 — BR-KSA-05 lists the only three document types the Authority accepts, 388, 381 and 383 — so cancelling means a credit note for the full amount.
Where to check what you already issue
If invoices already go out of a system you did not build, do not take its word for the type. Scan one with the QR code reader: the fields inside the code tell you whether Phase 1 or Phase 2 produced it, and the invoice itself tells you whether a buyer was identified. If something has been rejected, the error code index explains the codes the Authority returns.
An honest caveat before the plug. If you sell only to consumers, everything above about clearance and buyer addresses is irrelevant to you, and you should not let anyone sell you a workflow built around it. If you already run an ERP that maps the types correctly, keep it — connecting it through our API is the smaller change. And ZATCA Tools is not an accounting system: no ledger, no journals, no inventory, no payroll.
If you do need a system that issues both, ZATCA Tools produces signed invoices with their QR code, sends standard invoices for clearance and reports simplified ones within 24 hours, and keeps the signed XML for six years where you can download it. When something is rejected you see the official code with a link to its guide. It is free during the launch period, and connecting takes one OTP from the Fatoora portal — start here, or read the wider Phase 2 walkthrough first.