Phase 2 changed Saudi e-invoicing from "print a QR code" into a live conversation with ZATCA. A standard B2B invoice must be cleared by the authority before you hand it to the buyer. A simplified B2C invoice can be given to the customer immediately but must be reported within twenty-four hours. And every invoice you issue must be cryptographically linked to the one before it.
None of that is realistic to do by hand. TamilAccounting does it as part of issuing the invoice.
Clearance or reporting — the ERP decides
You do not pick the route, and you should not have to. Based on the buyer, the system classifies the document and follows the right path:
- Standard invoice (B2B) — submitted for clearance, and the ERP waits for the authority's answer before the document is treated as issuable.
- Simplified invoice (B2C) — stamped and given to the customer at once, then reported behind the scenes within the required window.
Credit and debit notes follow their parent document's route, with the correct document type recorded on each.
The hash chain, maintained for you
This is where most implementations come unstuck. Every invoice carries the hash of the previous invoice and its own sequential counter. If that sequence is broken — an invoice submitted out of order, or a failed submission counted as successful — the authority rejects everything that follows, and unpicking it is painful.
The ERP keeps the chain per environment and advances it only when an invoice is actually accepted. A rejected submission does not consume a position in the chain, so a bad afternoon does not poison the next month.
A worked example
You issue invoice 41 to a company (standard, so cleared), then invoice 42 at the counter (simplified, so reported), then invoice 43 fails validation because the buyer's address is incomplete. Invoice 44 is issued after you fix it. The chain runs 41 → 42 → 44. Invoice 43 never took a place in it, because it was never accepted — which is exactly what the authority expects to see.
Onboarding is a wizard, not a project
Getting a device authorised with ZATCA is a lifecycle: prove compliance with sample invoices, obtain a compliance certificate, then request the production certificate that lets you transact for real. The ERP walks you through it — seller details and national address, compliance checks run against sample documents of each type, then the production request — and remembers where you are, so it can be finished across two sittings.
Three environments are supported in the correct order: sandbox for experimenting, simulation for a realistic rehearsal, and production. Each keeps its own chain state, so testing never contaminates live numbering.
Zero-rated, exempt and out-of-scope
Not every supply carries 15%. Exports, exempt supplies and out-of-scope items each need the right tax category and a reason code on the invoice itself, or the submission is rejected. You configure these once and every invoice carries them correctly thereafter.
The QR the inspector scans
The QR printed on your invoice is not decorative. It is generated in the required TLV encoding, carrying the seller, the VAT registration, the timestamp, the total and the VAT amount, so an inspector scanning it sees what the authority saw. It is placed on the invoice print automatically.
What you see day to day
One dashboard: how many invoices were issued, how many cleared, how many reported, your acceptance rate, and anything that needs attention pulled to the front. Behind it, an audit trail of every exchange with the authority — what was sent, what came back, when, and by whom.
Built to stay out of the way
The Saudi rules load only for Saudi companies. If you run entities in more than one country from the same system, an Indian company never touches this logic and a Saudi company never touches India's — they cannot collide, by design.
