Simplified vs Standard Tax Invoices Under ZATCA: Which One, When, and Why It Matters

Written for whoever owns the invoice type decision in a Saudi business: the finance manager who configures document types, the ERP consultant mapping customer masters, and the operations lead who has to tell 40 cashiers what to press. By the end you should be able to decide the type for any counterparty, know which fields become compulsory the moment you decide, and know what to do when the decision turns out to have been wrong.

The distinction is legal, not commercial

The type is not a preference and not a setting. ZATCA's E-Invoicing Implementation Resolution does not define the two documents at all. It says "Electronic Invoices shall include Tax Invoices and Simplified Tax Invoices set forth under Article (53) of the VAT Implementing Regulation", then regulates what happens to each. The definition sits upstream, in VAT law.

ZATCA's E-Invoicing Detailed Guidelines state the working rule: "A Tax invoice is an invoice issued for most B2B and B2G transactions with fields defined in Article 53 (5), VAT Implementing Regulations", while "A Simplified Tax invoice is an invoice issued mostly for B2C transactions" with fields per Article 53(8). The same guidance permits simplified invoices in business-to-business cases "in case the value of supply is below SAR 1,000".

"Most" and "mostly" are doing real work: counterparty type is a strong proxy for the answer, not the answer itself. The decision that survives audit is made against the Article 53 conditions, with counterparty class as the first filter and the value, special-treatment and export tests applied after it.

[NEEDS SOURCE: the verbatim text of Article 53 (subsections 5 to 8) and Article 54 of the VAT Implementing Regulations. ZATCA publishes the Regulations as a single English PDF that could not be retrieved past Article 52 at the time of writing. Verify the subsection numbering and the exact wording of the value threshold before quoting them.]

The field sets that actually differ

Both types carry the same technical apparatus in Phase 2: UUID, previous document hash, tamper-resistant counter, QR code and cryptographic stamp are mandatory on both. The commercial fields diverge. The following is drawn from Annex 2 of the Implementation Resolution, showing only the rows where the two types disagree.

Field	Standard tax invoice	Simplified tax invoice
Buyer name	Mandatory	Conditional
Buyer address	Mandatory	Optional
Buyer VAT registration number	Conditional	Not in the simplified field set
Buyer additional identification	Conditional	Conditional
VAT rate (line level)	Conditional	Optional
VAT amount (line level)	Mandatory	Optional
Invoice taxable amount per rate	Mandatory	Conditional
VAT total	Mandatory	Conditional
Invoice gross total	Mandatory	Conditional
Payment means	Mandatory	Optional
Line-item discount percentage	Conditional	Optional
Self-billed invoice flag	Conditional	Not permitted
Third-party billing flag	Not listed	Conditional

Two things follow. The simplified set is not the standard set with the buyer removed; the VAT breakdown itself softens, which is why the document does not support input tax recovery the way a full tax invoice does. And buyer name is conditional rather than absent on a simplified invoice, which is what makes the special cases below possible without changing document type.

The XML carries the same split. ZATCA's Electronic Invoice XML Implementation Standard puts the decision in the name attribute of cbc:InvoiceTypeCode, where positions 1 and 2 are 01 for a tax invoice and 02 for a simplified tax invoice. Rule BR-10 then reads: "An Invoice shall contain the Buyer postal address (BG-8). Not applicable for simplified tax invoices and associated credit notes and debit notes (KSA-2, position 1 and 2 = 02)." One two-character decision switches the validation profile underneath the document. The remaining positions carry transaction-type flags, and the standard is inconsistent about how many: it says "Additional flags indicating transaction type have been added as the final four positions in the 'name' attribute", while the worked example shows a seven-character value (0100000), leaving five. [NEEDS SOURCE: the position-by-position mapping of the InvoiceTypeCode name attribute, specifically which position carries third-party billing, nominal supply, exports, summary and self-billing, and whether it is five or seven characters. Confirm against the Electronic Invoice Data Dictionary before configuring flags.]

Buyer identification, and when a simplified invoice stops being allowed

The practical test is not "is this person a business" but "does this buyer need, and are they entitled to, a document that identifies them for VAT purposes".

A simplified invoice has no place to put a buyer VAT registration number, and that single fact resolves most arguments. If the buyer is VAT-registered and intends to recover input tax, the document has to be a standard tax invoice. Writing their VAT number into the free-text notes field does not create a tax invoice; it creates a simplified invoice with a comment on it.

Where the buyer is not VAT-registered but the supply still requires a standard invoice, the buyer additional identification field carries the alternative: national identity number, GCC identity number, iqama, passport, tax identification number or commercial registration number. ZATCA's Detailed Guidelines note that where "additional Buyer ID is missing, invoice may be accepted with warnings". That is the trap: the document clears, the counter advances, and the defect sits in your records until someone reconciles.

The special case that surprises retailers is education and healthcare. Per the Detailed Guidelines, "the buyer details may be required in specific cases where Simplified Tax Invoices are issued towards Supply of Private Education and Private Health Care services to Saudi Citizens. These services are having a special tax treatment (treated as 'Zero Rated')." The document stays simplified and the buyer fields are populated anyway, because the zero rating attaches to the citizen. A school billing a parent runs a simplified flow with mandatory buyer identification, which most retail configurations do not anticipate.

What the choice does to the document's journey

Choosing the type chooses the endpoint, the timing and who applies the stamp, and therefore what a cashier is allowed to hand over. For a standard invoice, ZATCA "shall insert the Cryptographic Stamp only on the Invoices and Notes which fulfil the aforesaid controls and details as well as notify the issuers of such Invoices and Notes prior to sharing them with the customers". The document is not yours to give until it comes back. For a simplified invoice, the Resolution requires that it "must be reported to the Authority within a period which must not exceed (24) hours from its generation". The clock starts at generation, not at close of business, and the customer already has the paper. Reporting runs behind a completed sale; clearance is a gate in front of one.

The corollary is that the type decision is made before the document exists. A till that generates first and decides where to send it afterwards has already chosen: the type code is baked into the signed XML and the hash chain. Changing your mind means cancelling and reissuing.

The QR code carries different things

Both types print a QR code in Phase 2, and the contents are not identical. Per ZATCA's Detailed Technical Guidelines, tags 1 to 8 apply to both: seller name, seller VAT registration number, timestamp, invoice total including VAT, VAT total, hash of the XML invoice, the ECDSA signature, and the ECDSA public key. Tag 9 applies only to simplified invoices, and holds the "ECDSA signature of the cryptographic stamp's public key by ZATCA's technical CA".

The reason is structural. A simplified invoice never passes through ZATCA before it reaches the customer, so the QR has to be self-verifying: the ninth tag lets a reader confirm that the seller's key was itself vouched for. A standard invoice does not need it, because ZATCA has already stamped the document at clearance. Templates that still print a QR only on simplified documents are a Phase 1 artefact: the Resolution extended the requirement to "all types of Electronic Invoices and Electronic Notes" from 1 January 2023.

Notes follow the invoice, and self-billing is standard-only

ZATCA's Detailed Guidelines state that "the type of credit/debit note follows the type of invoice that they are issued against", and the Resolution requires that a "credit/debit note should correspond exactly to the type of Electronic Invoice for which the Credit/Debit Note is issued". A note against a simplified invoice is reported; a note against a standard invoice must be cleared. Two fields matter: the "reference to the original invoice(s) that the credit/debit note is related to" and the "reason for issuance of credit/debit note as per the VAT Implementing Regulation". The reason is what an auditor reads to decide whether the adjustment was legitimate. "Adjustment" is not a reason.

Where this breaks: a corporate customer returns goods bought at a branch counter on a simplified invoice, and the credit is raised from the back-office ERP, which only issues standard documents. Both are valid; the pair sits in two flows with no linkage. Raise refunds against the originating document class, from a unit configured to produce it.

Self-billing is standard-only. The Implementation Resolution is explicit: "The self-billing option is only allowed where both parties are VAT registered and it is not allowed in Simplified Tax Invoices." Summary invoices are a "Special transaction type flag (not mutually exclusive)" available to both types, and the flag does not change the type decision: a monthly summary billed to a VAT-registered business is a standard summary invoice; a periodic summary issued to a consumer is a simplified one. [NEEDS SOURCE: ZATCA's substantive conditions for issuing a summary invoice, including the maximum period one may cover and whether prior approval is needed. The Implementation Resolution names the flag but does not set out the rules.]

Decision table: scenario to document type to path

Scenario	Document type	Buyer fields you must have	Path
Cash sale to a walk-in individual	Simplified	None required	Report within 24 hours
Sale to a VAT-registered business, value SAR 1,000 or more	Standard	Name, address, buyer VAT registration number	Clear before handing over
Sale to a VAT-registered business, value below SAR 1,000	Simplified permitted; standard still available	If simplified: none, and no place for their VAT number	Report; but the buyer's recovery position weakens
Sale to a government body	Standard	Name, address, and buyer additional identification where no VAT number applies	Clear before handing over
Sale to a non-registered business that requests a tax invoice	Standard	Name, address, buyer additional ID (CRN or equivalent)	Clear before handing over
Export of goods to a non-resident customer	Standard, with the export transaction flag set	Name and address; no Saudi VAT number exists to quote	Clear before handing over
Private education or healthcare supplied to a Saudi citizen	Simplified, with buyer details populated	Buyer name and buyer additional identification	Report within 24 hours
Nominal supply (goods provided without consideration)	Follows the counterparty; nominal flag set	As for the underlying type	As for the underlying type
Self-billed document raised by a VAT-registered buyer	Standard only	Full seller and buyer identification	Clear before handing over
Credit note against a till receipt	Simplified credit note	Original invoice reference and reason	Report within 24 hours
Credit note against a cleared B2B invoice	Standard credit note	Original invoice reference and reason	Clear before issuing

The decision procedure a till or ERP can implement

Written as logic, because it has to run in under a second at a counter with a queue behind it.

1. Classify the counterparty before the tender screen. The type must be resolvable from the customer record or a cashier prompt while the basket is still open. Once the document is generated, the type is in the signed payload.
2. Resolve VAT registration status from master data, not from what the customer says. Hold the buyer VAT registration number as a validated field, and treat "claims to be registered, no number on file" as unresolved rather than registered.
3. Apply the value test only where it helps you. Below SAR 1,000 to a registered business you may issue simplified. If that buyer intends to recover input tax, issue standard anyway.
4. Apply the special-treatment tests next. Private education or private healthcare supplied to a Saudi citizen stays simplified but requires buyer identification. Exports go standard with the export flag.
5. Set cbc:InvoiceTypeCode positions 1 and 2 from that decision (01 or 02) and derive every downstream behaviour from it, never from a device-level flag or a printer template.
6. Enforce the field set as a hard block, not a warning. A standard invoice without a buyer VAT registration number or valid additional identification should not be generatable. Blocking at generation costs ten seconds; blocking at clearance costs the queue.
7. Derive the endpoint from the document. Clearance for 01, reporting for 02. Any code path that lets configuration override the document type will eventually send a simplified invoice to clearance.
8. For standard documents, hold the print until clearance returns. The customer copy is the cleared document ZATCA sends back, carrying its stamp and QR.
9. For simplified documents, print immediately with the nine-tag QR and enqueue with a per-document 24-hour timer keyed to generation time, not to a nightly batch.
10. Record why the type was chosen (counterparty class, registration status, value, special treatment) on the transaction. When ZATCA asks in two years why a SAR 40,000 supply to a registered contractor went out as a till receipt, the answer needs to be a record.
11. Handle the after-the-fact request as a sequence, not an edit. Credit note against the original, referencing the original invoice reference number and stating the reason, then a fresh standard invoice through clearance.
12. Reconcile daily by type: standard cleared, simplified reported, each rejected, against the sales ledger split by customer class. Drift between the two splits is the earliest signal that cashiers are choosing the wrong button.

Where teams get this wrong

Treating the invoice type as a device setting. A branch is configured "simplified only" because it is a shop. A contractor then buys SAR 60,000 of materials at the trade counter and gets a till receipt, because that is all the device can produce. The correction is a credit note, a cleared standard invoice and an explanation.

Assuming the SAR 1,000 threshold is an instruction. It permits a simplified invoice for a small B2B supply. It does not oblige one, and it does not help a registered buyer who wants their number on the document. Set as an automatic rule, it produces a trickle of customers coming back for a proper invoice.

Putting the buyer VAT number in a notes field. It passes validation because notes are free text. It does not make the document a tax invoice, and the error is hard to find because everything downstream looks correct.

Refunding from the wrong system. Back-office credit notes against branch till sales is the commonest structural break. Both documents are valid; the pair does not reconcile because they took different paths.

Ignoring "accepted with warnings" on buyer identification. Nobody notices, because the sale completed. A year later the warning count is five figures, each one a document with an identification defect.

What to automate, and what not to

Automate the mechanical consequences: field enforcement per type, endpoint selection derived from the type code, QR tag composition by type, the per-document 24-hour timer, the note-follows-invoice linkage, and the daily reconciliation of cleared and reported counts against the ledger split. These are rules, they do not change mid-transaction, and people get them wrong under time pressure.

Do not automate the decision itself where the inputs are uncertain. A system can classify a counterparty it already knows. It cannot decide whether the person at the counter is buying for a business, whether they intend to recover input tax, or whether healthcare is being supplied to a Saudi citizen. The honest design asks at the point of sale and records the answer, rather than inferring it from a customer group code someone set up three years ago.

Where a system helps

The value is in making the type decision explicit and letting everything else follow from it. An ERP that captures counterparty class, registration status and value as first-class fields, derives the invoice type code from them, hard-blocks generation when the field set is incomplete, and routes to clearance or reporting from the document rather than from a device setting removes this whole class of error and produces the reconciliation that proves the split was right. See RetailOS for SMB ERP.

FAQ

Can I issue a simplified tax invoice to a VAT-registered business? Yes, where the value of the supply is below SAR 1,000, per ZATCA's Detailed Guidelines. But the simplified field set has no buyer VAT registration number, so if that buyer needs the document to support an input tax claim, issue a standard tax invoice instead.

A customer asks for a tax invoice after I have already given them a till receipt. Do not edit or reissue the original. Raise a simplified credit note referencing the original invoice reference number and stating the reason, then issue a standard tax invoice through clearance with full buyer identification. Both documents stay in the record.

Do standard and simplified invoices need different QR codes? Yes. Tags 1 to 8 apply to both. Tag 9, ZATCA's technical certification authority signature over the seller's stamp public key, applies only to simplified invoices, because those reach the customer without ZATCA having seen them.

Can one till issue both types? Yes, and most should. The unit declares its capability at onboarding through the invoice type functionality map in the certificate signing request, described in ZATCA's Detailed Technical Guidelines as "one or a combination of Standard Tax Invoice (T), Simplified Tax Invoice (S)". A unit declared for both must pass compliance checks for both.

Which type applies to an export sale? A standard tax invoice with the export transaction flag set. The buyer has no Saudi VAT registration number to quote, so identification is carried by name, address and the applicable additional identification. [NEEDS SOURCE: ZATCA's specific guidance on invoicing exports under the E-Invoicing Regulation, including which buyer identification scheme applies to a non-resident buyer.]

Related reading

• KB-013: "What Is Fatoora? Saudi Arabia's E-Invoicing Platform, Explained"
• KB-014: "ZATCA Phase 2 Integration: Onboarding, Clearance and the Errors That Block Invoices"

Sources

• ZATCA, E-Invoicing Implementation Resolution, English, 19 May 2023 (PDF)
• ZATCA, E-Invoicing Detailed Guidelines, Version 2, May 2023 (PDF)
• ZATCA, E-invoicing Detailed Technical Guidelines (PDF)
• ZATCA, Electronic Invoice XML Implementation Standard, 19 May 2023 (PDF)
• ZATCA, Implementing Regulations of the VAT Law, English (PDF)
• ZATCA, VAT Implementing Regulations (index page)