E-invoicing
Generation, stamping and chaining are built into the system behind one interface: UBL 2.1 XML in the profile of the Zakat, Tax and Customs Authority, a QR code for both phases, a cryptographic stamp, and a hash chain per device.
The above describes what is built in the code. Turning e-invoicing on for your account needs a VAT registration number, access to the Fatoora portal and a production certificate, and those are completed with you at onboarding.
What it stands on
E-invoicing does not run without these modules. The ones that always run are in every instance, and no plan that includes E-invoicing is accepted without the subscribable ones among them.
- Background jobsAlways on
From the real module registry: what each module needs in order to run.
E-invoicing, built in-house
- UBL 2.1 documents for four types: standard invoice, simplified invoice, credit note and debit note
- A TLV QR code for phase one and phase two
- An ECDSA cryptographic stamp and a SHA-256 hash of the legal document
- An invoice chain with an ICV counter and the previous invoice's hash, under a lock per device
- Certificate signing request generation, device onboarding, and certificate renewal before it expires
- Chain verification that detects any break, and a retry for a failed submission
How far this reaches today
- No invoice has been submitted to an Authority environment yet — not sandbox, not simulation, not production
- Sudo is not certified or licensed by the Zakat, Tax and Customs Authority, and does not claim to be
- No QR code the system generates has been scanned with the official verification app
- The advance-payment invoice (type 386) is not issued
- There is no reconciliation between what we sent and what the Authority holds, and no alert on a failed submission