Under ZATCA's integration phase, every receipt a Saudi POS prints is a simplified tax invoice generated as XML, stamped with a cryptographic stamp identifier issued to that specific device, carrying a nine-tag TLV QR code, chained to the previous invoice by hash and counter, and reported to the Fatoora platform within 24 hours. The software must also lack a list of prohibited functions: no editing or deleting issued invoices, no counter reset, no date changes, no default passwords. Every one of those sentences comes from ZATCA's own detailed e-invoicing guideline, and the table below quotes it line by line.
According to BengalTech's 2026 price list, a custom single-counter POS built in Dhaka for a Saudi operator starts at $2,200 one-time and a multi-branch cloud-synced chain starts at $5,900, with ZATCA integration scoped into the build and no per-terminal fee.
This guide is for retail, restaurant and pharmacy operators in Saudi Arabia deciding whether their POS can pass integration, and for anyone commissioning a custom one. It is not tax advice: we implement the standard, your accountant confirms compliance, and ZATCA's published documents outrank anything here.
Phase 1, Phase 2, and Which Wave You Are In
ZATCA rolled e-invoicing out in two phases. The generation phase has applied to all VAT-registered taxpayers since 4 December 2021: invoices must be generated and stored electronically, with a basic QR code on simplified invoices. The integration phase has been "enforceable starting January 1st, 2023 in waves", each wave selected by VAT-taxable revenue, and ZATCA "will notify taxpayers of their Phase 2 wave at least six months in advance". The two most recent waves:
| Wave | Who is in it | Integration deadline | Source |
|---|---|---|---|
| Wave 24 | VAT-taxable revenue above SAR 375,000 in 2022, 2023 or 2024 | 30 June 2026 (passed) | VATupdate summary of ZATCA's announcement |
| Wave 25 | VAT-taxable revenue above SAR 187,500 in 2022, 2023, 2024 or 2025 | 1 February 2027 | ZATCA, 24 July 2026 |
ZATCA's own Wave 24 announcement page has since been removed from its site, so the Wave 24 row cites a secondary summary of it. The threshold has fallen with every wave; a business below SAR 187,500 should expect a future wave rather than assume exemption.
The Eight Things a Phase 2 POS Must Do
Each row quotes the guideline, says what it means at the till, and says how we build it. Page numbers refer to the May 2023 version 2 guideline, the one ZATCA still links from its e-invoicing hub alongside the XML implementation standard and the security features standard.
Every receipt is a simplified tax invoice in XML
- ZATCA guideline, p. 18
- Simplified tax invoices "must be generated in XML format or a PDF/A-3 (with embedded XML)" by an onboarded, compliant solution, and the XML (not the PDF) is what goes to Fatoora.
- At the till
- The paper receipt is a rendering. The legal document is an XML file your till has to produce for every sale, in ZATCA's XML implementation standard.
- How BengalTech builds it
- The POS writes the XML first, stores it, then prints from it. Printing never happens from data that has not been serialised and stamped.
Reporting within 24 hours, not real-time clearance
- ZATCA guideline, p. 32
- Reporting is "a near-real time transaction model, where Simplified Tax Invoices and their associated Credit/Debit notes are uploaded to the FATOORA Portal within 24 hours from issuance."
- At the till
- The till does not wait for ZATCA before handing over the receipt. It must get every invoice to Fatoora within a day, including the ones issued while the internet was down.
- How BengalTech builds it
- An outbox queue per device. Invoices are reported as they are issued when online, and the queue drains automatically on reconnection, oldest first, with the 24-hour clock visible on the manager dashboard.
A 9-tag TLV QR code on the receipt
- ZATCA guideline, p. 18
- The solution "must stamp the XML using CSID issued by ZATCA and also include a QR Code which is compliant with Phase 2 requirements (9 tags in TLV base64 format)."
- At the till
- The QR is not a link. It is a base64 TLV structure carrying seller name, VAT number, timestamp, totals, the invoice hash, the signature and the public key, and it must be verifiable by ZATCA's app.
- How BengalTech builds it
- QR generation is a pure function of the stamped XML, unit-tested against ZATCA's sandbox validator, so a receipt can never carry a QR that disagrees with its XML.
A cryptographic stamp from a device-specific CSID
- ZATCA guideline, pp. 44, 59
- Onboarding: the taxpayer logs into the Fatoora portal, "requests OTP code(s) for solution(s) to integrate" and enters them in the solution. "Every device issuing invoices with the same VAT number should be registered."
- At the till
- Each till is a registered "solution unit" with its own certificate. You cannot share one certificate across a chain of shops, and the taxpayer, not the vendor, performs onboarding with their own portal login.
- How BengalTech builds it
- A per-terminal onboarding screen: generate the key pair and CSR on the device, paste the OTP, obtain the compliance CSID, pass the compliance checks, then the production CSID. Keys never leave the terminal.
UUID, invoice counter and previous-invoice hash on every invoice
- ZATCA guideline, p. 28
- The solution "must not generate more than one sequence so that all invoices generated by an E-Invoice Solution Unit are linked using 'Previous Invoice Hash' value into a single chain," and "must not provide a feature where the invoice counting can be reset."
- At the till
- Every device keeps one unbroken chain. Two tills cannot share a counter, and a counter can never restart, not even after a reinstall.
- How BengalTech builds it
- The counter and last hash live in the device's local database with the invoice records. A reinstall restores them from the encrypted local backup or the central store before the first sale is allowed.
No editing, deleting, back-dating or anonymous use
- ZATCA guideline, pp. 27, 34
- Prohibited functions include "Allow alteration or deletion of generated E-Invoices", "Invoice counter reset", "Generated with inaccurate timestamps", "Anonymous access" and "Ability to operate with default password." Cancelling "may only be done through issuing an associated credit note."
- At the till
- The "void" button on a normal POS is illegal here. Mistakes are corrected with a credit note that is itself reported. Every cashier logs in as themselves.
- How BengalTech builds it
- Issued invoices are append-only records; the UI offers "credit note" instead of "void"; the system clock is read from the server and not editable on the till; first login forces a password reset; every action is written to a tamper-evident log.
Standard tax invoices when a business customer asks
- ZATCA guideline, p. 31
- Clearance "is a real-time transaction integration model of Tax Invoices, where ... the taxpayer directly sends the electronic invoice prior to sharing with the buyer," and it "applies to all Tax Invoices and their associated credit/debit notes."
- At the till
- A restaurant or shop that sells to a VAT-registered company must be able to issue a standard tax invoice from the same till, and that one has to be cleared by ZATCA before it is handed over.
- How BengalTech builds it
- A "business customer" toggle at checkout captures the buyer VAT number, switches the document type, calls the clearance endpoint, and prints only the ZATCA-stamped version.
Store the XML, and tell ZATCA when the system breaks
- ZATCA guideline, pp. 27, 38
- Invoices may be stored "in a server on-premises in the KSA or in the cloud" per the VAT law and regulations. Taxpayers must "Notify the Authority ... of any incidents, technical error or emergency matters which hinder the generation of Electronic Invoices" and resume reporting "as soon as the Solution becomes operable."
- At the till
- The XML archive is a legal record, and an outage is something you report, not something you hide.
- How BengalTech builds it
- Every stamped XML is replicated from the till to central storage; an outage longer than a configurable threshold raises a dashboard alert with the text you need to notify ZATCA, and the queue records exactly what was issued offline.
Why Offline-First Is the Whole Game
The guideline describes reporting as upload to Fatoora "whenever connected", with a 24-hour limit from issuance. That single sentence decides the architecture. A cloud POS that stops selling when the connection drops is not just losing sales; it is either issuing receipts it cannot stamp, or not issuing them at all, and both are compliance failures. A till that keeps its own certificate, counter and hash chain locally can issue valid stamped invoices all afternoon with no internet and report them at closing time.
We build POS in Dhaka, a city where the power and the internet both fail mid-service, so offline-first has been the default in every POS we have shipped. For ZATCA it stops being a convenience and becomes the requirement. See how the same engine handles multi-branch stock and tills on the POS service page.
Ten Questions to Ask Any POS Vendor Before You Sign
- Does each till produce the XML invoice itself, or does a cloud service generate it later from the sale record? (It must be the till, stamped before printing.)
- Show me the onboarding screen where I enter my own Fatoora OTP for each device.
- What happens to the counter and hash chain if the terminal is reinstalled or replaced?
- Can a cashier void a receipt? (The answer must be no; only a credit note.)
- Can anyone change the date or time on the till? (No.)
- How long can the till sell offline, and how does it show me what is still unreported against the 24-hour limit?
- Can the same till issue a standard tax invoice with the buyer's VAT number and clear it before printing?
- Where is the XML archive stored, and can I export it for an audit?
- Who gets alerted, and with what text, if reporting fails for more than an hour?
- Is ZATCA integration in the price, or a module with its own monthly fee?
What a ZATCA-Ready Custom POS Costs
BengalTech's 2026 POS tiers: single counter Starts at $2,200, multi-staff outlet Starts at $3,400, multi-branch with cloud sync Starts at $5,900. One-time, source code yours, no per-terminal fee. ZATCA integration is scoped into the build at the free scoping session: the XML profile, per-device CSID onboarding, QR, reporting queue and clearance path for business customers. Taxpayer onboarding on the Fatoora portal is done by you with your own credentials; we sit with you while you do it.
For the cost of a POS without the Saudi layer, see the POS price guide; for build-versus-subscribe, the custom POS development cost guide. Saudi operators evaluating a Dhaka team should also read the Saudi Arabia outsourcing guide. If you also trade in the Emirates, the UAE e-invoicing 2027 guide covers a very different model, and the Bangladesh NBR guide the third: invoice fields and books in a system, with no clearance platform yet.
Sources
External references behind the figures and claims on this page. Rate bands and vendor pricing move — check the source before quoting a number.
- Detailed Guidelines for E-Invoicing, version 2 (May 2023)
Zakat, Tax and Customs Authority (ZATCA)
The integration-phase requirements quoted in the article: XML simplified tax invoices, the 9-tag TLV QR, CSID stamping and OTP onboarding, single invoice chain with previous-invoice hash and non-resettable counter, reporting within 24 hours, clearance for tax invoices, prohibited functions, storage and malfunction-notification duties.
- E-invoicing roll-out phases
Zakat, Tax and Customs Authority (ZATCA)
Generation phase from 4 December 2021; integration phase enforceable from 1 January 2023 in waves, with at least six months' notice per wave.
- Criteria for the 25th wave of the integration phase
Zakat, Tax and Customs Authority (ZATCA)
Wave 25 covers taxpayers with VAT-taxable revenue above SAR 187,500 in 2022–2025, with integration due by 1 February 2027 (announced 24 July 2026).
- Wave 24 deadline 30 June 2026 (SAR 375,000 threshold)
VATupdate
Wave 24 criteria (VAT-taxable revenue above SAR 375,000 in 2022, 2023 or 2024) and its 30 June 2026 deadline; cited because ZATCA's own announcement page has since been removed.
- E-invoicing hub: specifications, security standards and solution providers
Zakat, Tax and Customs Authority (ZATCA)
Where ZATCA publishes the XML implementation standard, the data dictionary and the security features standard a solution must follow, and its statement that taxpayers may use any compliant solution provider.
Frequently Asked Questions
Under the integration phase, each receipt is a simplified tax invoice generated as XML by a solution onboarded with ZATCA, stamped with a cryptographic stamp identifier issued to that device, carrying a nine-tag TLV QR code, linked to the previous invoice by hash and a non-resettable counter, and reported to the Fatoora platform within 24 hours. The solution must not allow editing or deleting issued invoices, counter resets, date changes, anonymous access or default passwords. All of this is in ZATCA's detailed e-invoicing guideline.
Not for ordinary receipts. Simplified tax invoices (business to consumer) use the reporting model: hand the receipt to the customer immediately and report the XML within 24 hours. Standard tax invoices (business to business) use clearance: ZATCA must validate and stamp the invoice before you give it to the buyer. A POS that sells to companies needs both paths.
The guideline describes reporting as upload "whenever connected", within 24 hours of issuance. A compliant POS keeps issuing stamped invoices offline, keeps the hash chain and counter intact, queues the XML, and reports everything when the connection returns. If the outage stops you generating invoices at all, ZATCA expects to be notified and reporting to resume as soon as the system is operable.
ZATCA selects waves by VAT-taxable revenue and notifies taxpayers at least six months ahead. Wave 24 covered revenue above SAR 375,000 in 2022, 2023 or 2024 with a 30 June 2026 deadline. Wave 25 covers revenue above SAR 187,500 in 2022 to 2025 with a 1 February 2027 deadline. If your revenue is below that, watch ZATCA's announcements; the threshold has fallen with every wave.
No. ZATCA's FAQ says every device issuing invoices under the same VAT number should be registered, and the guideline requires each solution unit to keep its own single invoice chain. A ten-till chain onboards ten units, each with its own CSID, counter and hash chain, reporting to the same VAT registration.
According to BengalTech's 2026 price list, a custom single-counter POS starts at $2,200, a multi-staff outlet starts at $3,400, and a multi-branch cloud-synced chain starts at $5,900, one-time, with no per-terminal fee. ZATCA integration (XML, CSID onboarding, QR, reporting and clearance) is scoped into the build at the free scoping session rather than sold as a subscription module.
In Wave 25, or expecting the next one?
A free scoping session walks through the eight requirements against your current till and gives you a fixed quote. NDA before technical detail if you want one.