What is different about buying in Saudi Arabia

The authority's own description: "Phase 1, known as the Generation phase, will require taxpayers to generate and store tax invoices and notes through electronic solutions compliant with Phase 1 requirements." It started on December 4th, 2021, applies to resident taxable persons, and precedes any connection to the authority's systems: the invoice is produced and kept electronically, but nothing is transmitted for approval yet.

What to do with it. Any system already in service in the Kingdom is either past this gate or already non-compliant, so it is Phase 2 that a selection turns on. Treat a vendor that answers a Saudi question with Phase 1 conformance as answering the wrong question.

Phase 2 "will involve the introduction of Phase 2 technical and business requirements for electronic invoices and electronic solutions, and the integration of these electronic solutions with ZATCA’s systems", and the authority "will notify taxpayers of their Phase 2 wave at least six months in advance". The twenty-fifth wave covers "all taxpayers whose revenues subject to VAT exceeded (SAR 187,500) during 2022, 2023, 2024 or 2025", who must integrate by February 1, 2027.

What to do with it. Each wave has cut the threshold, and at SAR 187,500 the population being brought in is small businesses rather than the enterprises the early waves caught. The deadline to hold a vendor to is the buyer's own wave date, which arrives with six months' notice, not the phase start.

For business invoices: "Each Tax Invoice generated electronically must be cleared by the Authority as a prerequisite for sharing them with the buyers and for such Electronic Invoice to be regarded as legal and valid". It is a real-time model in which the invoice goes to the authority first and comes back stamped, with a QR code, to be shared and stored "in XML or PDF/A-3 (with embedded XML) format". Consumer invoices run the other way: simplified invoices "are uploaded to the FATOORA Portal within 24 hours from issuance", in XML, using APIs.

What to do with it. This is the deep difference from the UAE model. An invoice here is not valid until a government service says so, so the ledger has to tolerate a synchronous round trip in the middle of issuing a document, and needs a defined answer for what happens when that call fails or times out.

The human-readable invoice "can be presented provided that it is in Arabic (in addition to any other language) and Arabic or Hindi numerals can be used (either of which will be considered as Arabic in the invoices)". Arabic is a property of the document rather than of the user interface, and a second language sits beside it as a translation rather than replacing it.

What to do with it. Ask to see an Arabic invoice come out of the system rather than an Arabic screen. Item descriptions, tax labels and numerals all have to render, which makes it a question about the item master and the print template together, not about interface localization.

The authority's resolution puts requirements on the software, not only on the filing. "Each electronic invoicing system that generates Simplified Tax Invoices and its associated Notes must have a unique cryptographic stamp identifier that will be used to apply a cryptographic stamp on each Simplified Tax Invoice"; the solution "must be able to generate a QR code"; it must hash each document; it must have "a tamper-resistant Electronic Invoice counter that cannot be reset"; and the annexes list functions a compliant solution is prohibited from having.

What to do with it. These are engineering requirements on the invoicing component, which is why so many Saudi buyers keep the ledger they have and certify a solution beside it. Ask whether the vendor holds the stamp identifiers itself, or expects a partner product to sit between the ledger and the authority.