Resources

Inside the e-invoice: XML, UBL, the counter and the hash chain

The technical layerBy the alFatora team4 min read

What your customer sees is a tidy printout or a PDF. What the Authority sees is a structured XML document. In Phase 2, the real invoice is an XML file built on the international UBL standard, constrained by ZATCA's specifications — the fields, their types, and the validation rules applied before acceptance. The printed layout is just a rendering of that document, which can also be delivered as a PDF/A-3 with the XML embedded inside it.

The three identifiers that guard the sequence

Every Phase 2 invoice carries three fields that form the record's backbone:

  • The UUID: a globally unique identifier distinguishing this invoice from any other in existence, alongside its human-readable sequential number.
  • The invoice counter (ICV): a strictly increasing counter within the invoicing unit — every document consumes a value, and a gap in the counter is visible to an auditor.
  • The previous-invoice hash (PIH): each invoice carries the SHA-256 fingerprint of the invoice before it, forming a linked chain from the first document to the last.

Why a hash chain, specifically?

A hash is a mathematical fingerprint: changing a single byte of an invoice changes its fingerprint completely. And because every invoice carries its predecessor's fingerprint, editing an old invoice — or deleting one — breaks the fingerprint match in everything after it. An auditor does not need to examine every invoice; verifying the chain's integrity is enough to know the record has not been touched since issue.

The cryptographic stamp

On top of this, the invoice is stamped with a digital signature using the certificate of the invoicing unit registered with the Authority. The stamp proves two things at once: the source is a known, authorised unit, and the content has not changed since stamping. From the stamped invoice's components the QR code is built — detailed in our article on the invoice QR.

What this means for your business

You cannot — and your system cannot — "tidy up" the record retroactively. That is a feature, not a constraint: a tamper-evident record is your strongest evidence in any examination. What you need is a system that builds these layers correctly from day one: rule-clean XML, a counter that never slips, a chain that never breaks, a stamp that verifies. That is exactly what alFatora carries for you, and you can inspect the output in its free sandbox.

Was this useful? Review alFatora on Google.

Zakat, Tax and Customs AuthorityFatooraCompatible with ZATCA Phase 2
e-invoicing requirements
Create your account