The Previous Invoice Hash is one of the most important technical-integrity mechanisms in Phase Two e-invoicing. It is simply a digital fingerprint of the previous invoice, written inside the current invoice, so that every invoice is linked to the one before it in a continuous chain that cannot be tampered with without exposure. The official schema refers to it by the abbreviation PIH, and it is written inside the XML file under the element AdditionalDocumentReference with the identifier PIH.
Many developers confuse the Previous Invoice Hash with the concept of hashing itself (Hashing) and with the calculation algorithm (SHA-256). The field is one, but behind it lie a mathematical concept and a specific algorithm. This technical guide focuses on the field alone: what PIH is, where it sits in the XML, how it links each invoice to the hash of the previous invoice to build a tamper-resistant chain, what the base state is for the first invoice, and how it works side by side with the Invoice Counter ICV. The concept of hashing itself and the SHA-256 algorithm each have a separate guide that we reference where relevant.
The official reference is the requirements of the Zakat, Tax and Customs Authority (ZATCA) for e-invoicing, and the invoice schema built on the UBL 2.1 standard. In any conflict between what is here and the official schema, the Authority’s official schema prevails.
What exactly is the Previous Invoice Hash (PIH)?
The Previous Invoice Hash is a fixed-length text value that represents a digital fingerprint of the invoice issued immediately before the current one. This fingerprint results from passing the content of the previous invoice through a hash function, producing a string of letters and numbers that represents the entire invoice in a condensed form.
The core idea is that any change, however small, in the previous invoice changes its fingerprint entirely. If someone altered a single riyal in an old invoice, its fingerprint changes, so it no longer matches the value stored in the next invoice. This mismatch exposes the tampering immediately. That is why the chain is described as tamper-resistant.
The value is written encoded in Base64, the format the official schema requires to represent the hash output as text inside XML. The length is fixed because the output of the algorithm used is always fixed-length, regardless of the size of the original invoice, whether small or large.
It is important to distinguish from the outset: PIH is not the concept of hashing itself; it is the field that carries the hash output of the previous invoice. The concept of hashing as a mathematical operation, and the SHA-256 algorithm that performs it, are separate topics. Here we deal with the field, its location, and its role in the chain.
Where does the Previous Invoice Hash sit in the XML file?
The PIH value sits inside a dedicated AdditionalDocumentReference block, distinguished by the identifier PIH in the element ID. The value itself is written inside the EmbeddedDocumentBinaryObject element, which carries the attribute mimeCode with the value text/plain.
This block is not alone in the invoice. There is another block with the identifier ICV that carries the Invoice Counter, and there may be a third block with the identifier QR for simplified invoices. The order and wording of the blocks must match the official schema precisely, because any deviation in structure leads to the invoice being rejected at validation.
A complete XML example of the PIH block
This is a simplified example of the Previous Invoice Hash block as it appears inside the invoice. The value here is illustrative and not a real fingerprint:
Note three essential elements. The first is the ID with the value PIH element, which defines the type of reference. The second is the containing Attachment element. The third is EmbeddedDocumentBinaryObject which carries the fingerprint encoded in Base64 along with mimeCode with the value text/plain.
The position of PIH among the other AdditionalDocumentReference blocks
The PIH block usually appears after the Invoice Counter ICV block within a series of AdditionalDocumentReferenceblocks. The following example illustrates the approximate order:
The ICV block carries the Invoice Counter, a sequential integer you will find in the Invoice Counter ICV guide. The PIH block carries the fingerprint of the previous invoice. The two fields are functionally related but structurally separate, and each has its own block.
Inside the AdditionalDocumentReference block
Identifier ID = PIH
The value in EmbeddedDocumentBinaryObject (Base64)
Encoding mimeCode = text/plain
Sits after the Invoice Counter ICV block
How does the Previous Invoice Hash link invoices into a chain?
Here lies the heart of the idea. Every invoice carries within it the fingerprint of the invoice that preceded it. This builds something like a metal chain, each link connected to the one before it.
Imagine three consecutive invoices on the same device. The first invoice has its own fingerprint. The second invoice writes the fingerprint of the first in its own PIH field. The third invoice writes the fingerprint of the second in its own PIH field. And so the chain continues.
The practical effect is powerful. If someone tried to delete the second invoice from the middle, the chain breaks, because the third invoice points to the fingerprint of an invoice that no longer exists. And if someone tried to modify a value in the second invoice, its fingerprint changes, so it no longer matches what was written in the PIH field of the third invoice. In both cases the tampering is exposed at validation.
This interlinking is what makes the invoice chain a tamper-resistant digital ledger. No invoice can be inserted, deleted, or modified without breaking the chain and producing a clear sign of tampering.
The relationship between PIH and ICV step by step
The Invoice Counter ICV and the Previous Invoice Hash PIH work together but measure two different things. The counter guarantees numerical sequence, and the hash guarantees content integrity. The following steps show how they advance together with each new invoice:
- The device issues a new invoice, so the Invoice Counter ICV increases by one over the previous invoice.
- The system retrieves the stored fingerprint of the previous invoice and writes it into the PIH field of the new invoice.
- The fingerprint of the new invoice is computed in full and kept to serve as the PIH value for the next invoice.
- The invoice is sent to the Fatoora platform for clearance or reporting depending on its type.
The counter says “this is invoice number 125 on this device.” The hash says “and it is linked to invoice number 124 by its fingerprint exactly as it is.” Together the two numbers prove sequence and integrity at once.
Invoice 1 (ICV=1)
Invoice 2: PIH = hash of 1
Invoice 3: PIH = hash of 2
What is the base state for the first invoice on the device?
A logical question every developer asks: what is written in the PIH field of the first invoice, when there is no previous invoice at all before it? This is the base state in the chain.
The official schema defines a fixed, known value for this state. The first invoice in the device’s lifetime writes into the PIH field the hash value of an empty string. This value is standard and known in advance, and every compliant system uses the same value for the first invoice.
The fixed value used is:
This value is not random. It is the fingerprint of an empty string in a specific form, encoded in Base64. Using it achieves two things. First, it gives the chain a fixed, unambiguous starting point. Second, it allows validation systems to recognize that this is a first invoice and not an invoice whose previous value was lost.
After the first invoice, every subsequent invoice takes the fingerprint of the real invoice that preceded it, and the base state ends. This fixed value is not repeated in any subsequent invoice on the same device. Repeating it a second time means an error in building the chain.
Why must the chain be continuous without interruption?
The entire strength of the Previous Invoice Hash mechanism is in the continuity of the chain. Any interruption strips it of its oversight value. That is why the Authority requires each issuing device to be responsible for its own chain without overlap with other devices.
Continuity means that the PIH value in every invoice must match the fingerprint of the previous invoice on the same device exactly. It is not enough for it to be close or similar. The fingerprint either matches entirely or is rejected. There is no middle state.
This strict discipline is intentional. The goal is to build an audit trail that is hard to forge. As long as every invoice is linked to its predecessor by a precise fingerprint, any tampering becomes mathematically exposed, with no room for interpretation.
Common errors that break the chain
A set of errors recurs when implementing the PIH field, all of which lead to the invoice being rejected or the chain breaking:
- Writing the fingerprint of an invoice other than the immediately previous one, due to a flaw in issuing order or synchronization.
- Reusing the base-state value in an invoice that is not the first on the device.
- Computing the fingerprint over content other than the content specified in the official schema, producing a fingerprint that does not match what is expected.
- Mixing the chains of two devices, where one device writes the fingerprint of an invoice issued on another device.
- Base64 encoding errors or extra spaces inside the field value.
Each of these errors leads to a mismatch at validation. That is why it is preferable to rely on an accounting system that manages the chain automatically instead of building it manually from scratch.
Let Qoyod build the invoice hash chain on your behalf
Qoyod computes the fingerprint of every invoice and writes it into the PIH field of the next invoice automatically, building a continuous chain compliant with Phase Two, without you writing a single line of XML or tracking fingerprints by hand.
How does the Previous Invoice Hash differ from the Invoice Counter?
Confusing PIH with ICV is very common, because the two fields appear in adjacent blocks and serve the same chain. But the role of each is entirely different.
The Invoice Counter ICV is a sequential integer that answers the question “how many invoices has this device issued?” The Previous Invoice Hash PIH is a digital fingerprint that answers the question “is the previous invoice intact and untampered?” The first measures order, the second measures integrity.
If we relied on the counter alone, a skilled manipulator could renumber the invoices. But with the hash, any modification to an invoice changes its fingerprint and is exposed. The counter and the hash together cover the gap from both sides: order and content.
The three fields at a glance
In addition to the counter and the hash, the unique identifier UUID appears. The following table distinguishes between the three:
| Field | Type | Role |
|---|---|---|
| Invoice Counter ICV | Sequential integer | Proves the order of invoices on the device |
| Previous Invoice Hash PIH | Fixed-length text fingerprint | Proves the integrity of the previous invoice and links the chain |
| Unique Identifier UUID | Globally unique identifier | Distinguishes every invoice uniquely, without repetition |
For a deeper look at the Invoice Counter, refer to Invoice Counter ICV guide, and for a deeper look at the unique identifier, refer to Unique Identifier UUID guide. The three fields are part of the complete e-invoice structure .
| Criterion | ICV counter | PIH hash |
|---|---|---|
| Type | Sequential number | Text hash |
| Role | Order of invoices | Chain integrity |
| Base | Starts from 1 | Empty hash for the first invoice |
Where does the Previous Invoice Hash sit relative to the concept of hashing and the algorithm?
It helps to clarify the boundaries between three levels so they do not blur for the developer. The PIH field is the first level, and it is the subject of this guide: a specific location in XML that carries a specific value.
The second level is the concept of hashing (Hashing) itself, that is, the mathematical operation that transforms any content into a fixed-length fingerprint. This concept is broader than the PIH field and is used in other places in the invoice. Its detailed explanation is in a separate guide dedicated to hashing.
The third level is the specific algorithm that performs the hashing, which is SHA-256 in the case of e-invoicing. The details of how the algorithm works and its properties are in a separate guide dedicated to it. Here it is enough to know that the PIH value is the output of applying this algorithm to the previous invoice, then encoding it in Base64.
With this separation, our guide stays focused: we deal with the field, its location, and its role in the chain, and we refer the details of the concept and the algorithm to their proper place.
Practical considerations for developers when implementing the PIH field
When building an integration with e-invoicing, a set of practical considerations around the Previous Invoice Hash recurs:
- Store the fingerprint of every invoice the moment it is issued, because it is the PIH value for the next invoice. Relying on recomputing it later is a common source of errors.
- Separate the chain of each issuing device from the others completely. Each device has its own chain and its own fingerprints.
- Handle synchronization carefully. If the device issues two invoices at the same moment, they must be ordered before building the chain, so that the two invoices do not point to the same fingerprint.
- Verify the base-state value for the first invoice only, and never use it after that.
- Ensure correct Base64 encoding without extra spaces or broken lines inside the value sent.
These considerations are the difference between a sound chain that passes validation and a broken chain whose invoices are rejected. Building it manually is possible but tedious and error-prone, which is why many turn to a certified system that handles it automatically.
A quick checklist before sending
Before sending the invoice to the Fatoora platform, review the following points related to the PIH field:
- Is the PIH value the fingerprint of the immediately previous invoice on the same device?
- Does only the first invoice carry the base-state value?
- Is the fingerprint encoded in correct Base64 without extra spaces or line breaks?
- Is the PIH block inside
AdditionalDocumentReferencewith the correct identifierPIH? - Is the Invoice Counter ICV consistent with the invoice’s position in the chain?
Storing the fingerprint and the long-term audit trail
The Previous Invoice Hash is not a transient value. It is part of the audit trail that must remain available for review. Storing the fingerprints properly allows the chain’s continuity to be re-verified at any later time.
Whenever the Authority or an internal auditor needs to confirm the integrity of the invoice record, it is enough to rebuild the chain and confirm that every PIH value actually matches the fingerprint of the previous invoice. Any interruption or mismatch pinpoints the location of the tampering precisely.
This long-term dimension is what elevates the field from a mere technical requirement to an actual governance tool. A continuous chain means a financial record that is hard to forge, which is at the core of the goal of Phase Two e-invoicing.
It is advisable that the storage of fingerprints remain independent and protected, not erased when an invoice is deleted from the user interface. Even if the user cancels an invoice, its fingerprint remains part of the audit trail, because it is already the PIH value for the next invoice. Cancellation in e-invoicing is done by issuing a linked credit note, not by deleting the invoice from the chain. Physically deleting it breaks the linkage and voids the value of the entire field. That is why a sound system separates commercial cancellation from physical deletion, keeping the chain intact in all cases.
A full-chain scenario on a single device
Let us trace a real chain on a single issuing device from its first day of operation. This trace brings together everything above into one practical picture.
The first invoice is issued with an ICV counter of 1. There is no invoice before it, so the system writes the fixed base-state value into the PIH field. The fingerprint of this first invoice is computed and kept.
The second invoice is issued with a counter of 2. The system writes into the PIH field the fingerprint of the first invoice that was just saved. The fingerprint of the second invoice is computed and kept in turn.
The third invoice is issued with a counter of 3. The system writes into the PIH field the fingerprint of the second invoice. And so the chain proceeds, each invoice raising the counter by one and carrying the fingerprint of its predecessor.
If we assume a manipulator wanted to delete the second invoice to hide sales, the third invoice still carries in its PIH field the fingerprint of an invoice that no longer exists in the record. When the chain is rebuilt, it appears that the counter jumped from 1 to 3, and that the fingerprint of the second invoice is missing. This is a double exposure: the counter reveals the jump, and the hash reveals the gap. Here the value of the two fields working together becomes clear.
Multiple chains in an establishment with more than one device
Many establishments run more than one issuing device. A store with three cash-register devices is a common example. Each of these devices builds a completely independent hash chain.
The first device starts its first invoice with the base-state value, then sequences in isolation. The second device likewise starts its first invoice with the same base-state value, but its chain is separate and does not overlap with the first. The third device is like them.
The fatal error here is for one device to write into its PIH field the fingerprint of an invoice issued on another device. This mixes the chains and breaks them all. That is why each device must keep the fingerprint of the last invoice it issued itself, not the last invoice in the establishment as a whole. Separating the chains is a fundamental condition for the integrity of each one of them.
This separation also explains why the base-state value appears more than once in a single establishment, once per device at its first invoice. Its appearance is tied to the device, not to the establishment. Repeating it on the same device is an error, but its appearing once per device is entirely sound.
How does the Authority’s system verify the PIH value?
When the invoice is received, the validation system does not merely read the PIH field as is. It recomputes the fingerprint of the previous invoice and compares it with the written value. If they match, the invoice passes on this point. If they differ, it is rejected.
This means the PIH value is not merely text that is copied, but a mathematical commitment. The issuing system says “this is the fingerprint of my previous invoice,” and the validation system confirms it for itself. There is no room for blind trust; the verification is purely computational.
Among the errors that cause the invoice to be rejected: the PIH value does not match the actual fingerprint of the previous invoice, or using the base-state value in an invoice other than the first, or corrupted Base64 encoding. Each of these errors stops the invoice at the validation gate before it is cleared or reported.
For this reason it is advised not to build the integration manually except with a precise understanding of the official schema requirements. Any small detail in computing the fingerprint or encoding it may flip the validation result. Relying on a certified system spares the establishment these fine details.
How does Qoyod handle the Previous Invoice Hash?
Qoyod manages the entire hash chain on the user’s behalf. With every new invoice, Qoyod computes the invoice’s fingerprint, stores it, writes it into the PIH field of the next invoice, and handles the base state for the first invoice automatically.
This means the business owner deals with neither XML nor Base64 encoding nor tracking fingerprints by hand. The system builds the chain compliant with Phase Two requirements, links it to the invoice counter, and sends the invoices to the Fatoora platform for clearance or reporting depending on their type.
To review the rest of the technical-integrity pillars in the invoice, see the XML invoice guide and theCryptographic Stamp Identifier CSID guide. And to understand the full picture of e-invoicing in Saudi Arabia, see the Qoyod e-invoicing.
Frequently asked questions
What is the difference between the Previous Invoice Hash and the concept of hashing?
The Previous Invoice Hash PIH is a specific field in XML that carries the fingerprint of the previous invoice. The concept of hashing is the broader mathematical operation that produces this fingerprint. The first is a location and a value; the second is a concept and an operation.
What is written in the PIH field of the first invoice?
A fixed, known value is written that represents the fingerprint of an empty string, encoded in Base64. This value is standard and is used for the first invoice only on each device, and is not repeated in any subsequent invoice.
What happens if an old invoice in the chain is modified?
The fingerprint of the modified invoice changes, so it no longer matches the PIH value written in the next invoice. This conflict exposes the tampering immediately at validation, which is the purpose of the chain.
Is the Previous Invoice Hash linked to the Invoice Counter?
Yes, the two fields work together. The counter proves the order of the invoice on the device, and the hash proves the integrity of the previous invoice. Together they guarantee sequence and integrity within the chain itself.
Where is the PIH value written inside the XML?
Inside the AdditionalDocumentReference with the identifier PIHblock, specifically in the EmbeddedDocumentBinaryObject fingerprint mimeCode with the value text/plainelement, and the value is encoded in Base64.
Does Qoyod compute the PIH value automatically?
Yes, Qoyod handles computing the fingerprint of every invoice and writing it into the PIH field of the next invoice, and manages the base state for the first invoice, without any manual intervention from the user.
Does the base-state value change from one establishment to another?
No, the base-state value is fixed and standard for all establishments and devices, because it is the fingerprint of an empty string computed the same way. It appears only once at the first invoice of each issuing device, then every subsequent invoice takes the real fingerprint of its predecessor on the same device.
