The Technical Lifecycle of the Electronic Invoice

When you issue a single invoice in a system compliant with Phase Two of e-invoicing, that invoice travels through a governed technical journey that never surfaces to the end user. It begins with the generation of a structured XML file and ends with the archiving of an auditable copy years later. This page is the complete map of that journey. We trace the invoice stage by stage as the developer and the system see it, and we link each stage to its dedicated technical page within this track.

The target audience here is technical: integration developers, systems engineers, and compliance officers who need to understand the sequence of steps, not just its outcome. Every technical English term stays as it is (UBL, XML, PIH, CSID) because it is the reference adopted in the documentation of the Zakat, Tax and Customs Authority (ZATCA). The goal of this page is to be the starting point that connects the pages of the technical track to one another, so you read the full journey before diving into the details of each individual stage.

Why «lifecycle» and not «issuance step»

Many people picture e-invoicing as a single action that happens the moment you press save. The technical reality is different. The invoice is a digital object that passes through multiple states: created, signed, validated, cleared or reported, delivered, archived. Each state has entry and exit conditions, and every transition between two states is logged. This is why we use the term «lifecycle»: because the invoice has a lifespan that begins with generation and ends with archiving, and between them lie stages that cannot be skipped.

Understanding the journey as a lifecycle helps the developer in practice. When diagnosing an error, the first question is: at which stage did the invoice stop? An error in building the XML differs fundamentally from an error in signing or a rejection by the Fatoora platform during clearance. Identifying the stage identifies where the fix belongs.

An overview of the full journey

The lifecycle of the electronic invoice in Phase Two consists of eight sequential stages. Each stage takes the output of the previous stage as its input, and no link can be skipped. The general sequence is as follows:

1. Generation: Building the invoice file in UBL XML format.
2. Identifiers: Assigning the UUID, ICV, and PIH to the invoice.
3. Hashing: Computing the digital fingerprint of the invoice.
4. Signing: The cryptographic stamp via a CSID certificate.
5. Validation: Checking the Schema and the Business Rules.
6. Clearance or Reporting: Real-time Clearance for B2B invoices, and Reporting within 24 hours for B2C invoices.
7. Delivery: Delivering the invoice in PDF/A-3 format with embedded XML.
8. Archiving: Storing an auditable copy for the statutory retention period.

To comply with Phase Two, the accounting platform handles these stages automatically on behalf of the business. Qoyod’s e-invoicing software executes the full chain from generation to archiving without any manual intervention in the XML format or in the signing. The following sections explain each stage in depth and link it to its dedicated technical page.

Infographic one: map of the eight stages

Stage one: Generation, building the UBL XML file

The journey begins when you press «Save invoice» in the system. The invoice is not stored as free text; it is built as a structured file that follows the UBL 2.1 standard (Universal Business Language) in XML format. This standard is the foundation the Authority mandated for all invoices in Phase Two, and it is an open global standard that describes the invoice with predefined elements.

The XML file contains specific mandatory elements: seller data (name, tax registration number, national address), buyer data in B2B invoices, invoice line items (description, quantity, unit price), VAT amounts at 15%, and the totals before and after tax. Each element has a fixed XPath in the adopted schema. The absence of any mandatory element stops the invoice at the validation stage later on.

A simplified example of the invoice header structure in UBL XML format:

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:ProfileID>reporting:1.0</cbc:ProfileID>
  <cbc:ID>INV-2026-000142</cbc:ID>
  <cbc:UUID>3cf5ee18-ee25-44ea-a444-2c37ba7f28be</cbc:UUID>
  <cbc:IssueDate>2026-06-24</cbc:IssueDate>
  <cbc:IssueTime>14:30:05</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="0100000">388</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode>
</Invoice>

The value InvoiceTypeCode defines the invoice type. The code 388 means a tax invoice, and the mask name distinguishes between the standard invoice (B2B) and the simplified tax invoice (B2C). This distinction later governs the path of stage six: clearance or reporting. That is why the invoice type is decided from the moment of generation, not at a later stage.

The element ProfileID specifies the compliance profile used, and the invoice currency is always the Saudi Riyal (SAR) for domestic transactions. Every numeric value is written with a specific decimal precision to avoid rounding errors that the validation rules may reject. The full details of the file structure and its paths are explained on the UBL XML invoice structure.

Stage two: Identifiers (UUID, ICV, and PIH)

After the structure is built, three interrelated technical identifiers are assigned to the invoice. Each one serves a different purpose in the compliance chain:

• UUID: A Universally Unique Identifier, 128 bits long. It distinguishes the invoice from any other invoice in the world and is generated automatically at creation. The same UUID practically never recurs twice.
• ICV: The Invoice Counter Value. A monotonically increasing serial number that neither repeats nor decreases within the system; it proves the sequence of invoices and that none has been deleted. Its value starts at one and increases by one with each invoice.
• PIH: The Previous Invoice Hash. The hash value of the invoice that immediately preceded it, which is what links the invoices into a cohesive chain.

The three identifiers together prevent tampering: no invoice can be inserted into the middle of the chain, and no invoice can be deleted without breaking the ICV sequence and the PIH value of the following invoice. For the first invoice in the system, the PIH value is a fixed, known constant representing the chain’s starting point, and it is a standard value defined by the Authority’s specifications.

The fundamental difference between UUID and ICV deserves clarification: the UUID is a random, unique identifier with no relation to order, whereas the ICV is an ordered counter that proves the chronological sequence. The first answers the question «which invoice is this?» and the second answers «where does it sit in the chain?». The detailed explanation of each identifier and how it is generated is on the Invoice identifiers UUID, ICV, and PIH.

Stage three: Hashing, the invoice fingerprint

After the identifiers are assigned, a digital fingerprint of the invoice is computed using the SHA-256 algorithm. The result is a fixed-length string (256 bits) that represents the entire content of the invoice. Any change of a single character inside the XML produces a completely different hash, which is what makes hashing the primary tamper-detection tool in the system.

The hash is computed on the Canonical version of the XML after applying the C14N transformation, to ensure that two different systems arrive at the same hash from the same content. The reason for this transformation is that XML can be written in multiple equivalent ways (whitespace, attribute order, encoding) that nonetheless produce different hashes. The canonical transformation standardizes the wording before the computation. The result is encoded in Base64 and is later placed in the PIH field of the following invoice, so the chain is formed.

# Computing the invoice hash (illustrative representation)
canonical_xml = c14n_transform(invoice_xml)
invoice_hash  = base64(sha256(canonical_xml))
# invoice_hash is passed as the PIH value of the next invoice

An important property of SHA-256 is that it is one-way: the hash can be computed from the content, but the content cannot be recovered from the hash. This is sufficient to verify integrity without exposing the invoice data. The logic of the algorithm and the canonicalization steps are fully explained on the Electronic invoice hashing.

Stage four: Signing, the cryptographic stamp

Here the most important security element enters. The invoice is signed with a digital signature (Cryptographic Stamp) using a private key tied to a CSID certificate. The full name of the certificate is Compliance Cryptographic Stamp Identifier, and it is the certificate the Authority issues to the business upon onboarding with the Fatoora platform.

The signature proves two things: that the invoice was actually issued by the business that owns the certificate, and that its content has not changed after signing. The system signs the invoice hash (the output of stage three) with the private key, producing a signature no one can forge without possessing the same key. The signature is placed inside the XML within the digital signature element, in addition to the QR code that carries the signature data for simplified invoices.

The verification mechanism works in reverse: any party holding the public key (embedded in the certificate) can confirm that the signature matches the hash, thereby proving the invoice has not been touched. This is the essence of the Public Key Infrastructure (PKI) on which Phase Two is built.

The accounting platform manages the CSID certificate automatically after a one-time onboarding, so the developer does not need to deal directly with the keys for every invoice. This separation matters because manual key management is a common source of security errors. The signing specifications and the structure of the cryptographic field are on the Cryptographic stamp specifications.

Infographic two: the generation and signing sequence

Stage five: Validation, the schema and the rules

Before the invoice is sent to the Authority, it passes through two consecutive validation layers. The failure of either one stops the invoice and returns a specific error message:

• Schema Validation: A structural check that ensures the XML matches the adopted XSD schema. It detects missing elements, incorrect order, and invalid data types. This check is purely formal: is the file built in the correct shape?
• Business Rules Validation: A logical check that applies the Authority’s rules. For example: that the sum of the line items equals the total, that the VAT rate is correct, and that the tax registration number is in the correct format. This check is semantic: are the values logical and compliant with the law?

Each rule has an error code (such as BR-KSA-XX) that helps the developer pinpoint the reason for rejection precisely. The difference between the two layers is practical: a file may pass schema validation because it is built correctly, yet fail the rules because the tax total does not match the line items. That is why the two layers are always run in order.

Local validation before sending reduces rejection by the Authority and saves network round-trips. Every rejected invoice means an additional round-trip between the system and the platform, and pre-validation catches most errors before they arrive. The detail of the two validation layers and the common error codes are on the dedicated validation guide page within this track, which is currently being published and will be linked as soon as it is available.

Stage six: Clearance or Reporting

Here the journey branches according to the invoice type determined in stage one. The governing rule is simple: the standard invoice (B2B) is subject to real-time Clearance, and the simplified invoice (B2C) is subject to Reporting within 24 hours. This branch is the most important decision point in the entire journey.

Real-time Clearance for B2B invoices

The standard invoice addressed to another business is sent to the Fatoora platform before it is delivered to the buyer. The platform validates the invoice and adds its own stamp, then returns it «Cleared». The invoice is not considered valid until it is cleared. This is a Real-time synchronous process that completes within seconds, and the system must wait for the platform’s response before completing the operation.

If the platform rejects the invoice, it is returned with an error code and is not delivered to the buyer until it is corrected. This means clearance is a mandatory gate: an uncleared invoice legally does not exist. The details of the clearance cycle and the response states are on the Real-time Clearance.

Reporting within 24 hours for B2C invoices

The simplified invoice addressed to the final consumer is delivered to the buyer immediately (with a QR code), then reported to the Authority within 24 hours of its issuance. This path is asynchronous, so the customer does not wait for the platform’s response at the point of payment. The reason for this design is practical: it is not reasonable for a customer in a retail store to wait for a network response with every purchase.

The platform collects the simplified invoices and sends them in a batch or individually within the 24-hour window. If the sending fails, the system retries without disrupting the sale. The reporting mechanism and the statutory window are explained on the Reporting within 24 hours.

Stage seven: Delivery in PDF/A-3 format with embedded XML

After clearance or reporting, the invoice is delivered to the buyer. The adopted format for the human-readable delivery is PDF/A-3, a long-term archival format. Its fundamental advantage is that it allows the original XML file to be embedded inside the PDF file itself.

This embedding achieves two goals at once: a copy a human reads (the visible PDF) and a copy systems read (the embedded XML). The buyer can extract the XML from the file to record the invoice automatically in their system, without manual re-entry. This eliminates human error in transcription and speeds up accounting reconciliation between the two parties. A QR code is also placed in the simplified invoice to enable quick verification of its validity with a simple scan.

Choosing PDF/A-3 specifically is intentional: the A means Archival, and the number 3 refers to the version that supports embedding any file type. Ordinary PDF formats do not guarantee readability after years, whereas PDF/A is designed for long-term preservation. The format specifications and how XML is embedded are on the PDF/A-3 format and XML embedding.

Stage eight: Archiving

The final link is storing a copy of the invoice that is retrievable and auditable throughout the statutory retention period. The copy is stored in its original format (the signed XML) along with its hash and its clearance or reporting status, so that the integrity of the chain can later be proven to any auditor.

Archiving is not mere storage; it is organized preservation that links each invoice to its predecessor via the PIH value, so the chain remains verifiable as a single block. During an audit, the reviewer can take any invoice and confirm its hash, then trace the chain up and down to ensure there are no gaps. The accounting platform handles archiving automatically and enables the retrieval of any invoice on demand by its identifier, date, or serial number.

A complete example: the journey of a single invoice from start to finish

Let us trace a single standard invoice across the eight stages, to see how the links connect in practice:

1. The accountant issues an invoice of SAR 1,150 to a client business (SAR 1,000 + SAR 150 VAT). The system builds the UBL XML file with the mandatory elements.
2. The invoice is assigned a unique UUID, an ICV value (let us assume 142), and a PIH value equal to the hash of invoice number 141.
3. The system computes the SHA-256 hash of the invoice on its canonical version, producing the hash to be signed.
4. The system signs the hash with the private key of the CSID certificate and places the signature inside the XML.
5. The system validates locally: the schema is sound, the sum of the line items matches the total, and the 15% VAT is correct.
6. Since the invoice is standard (B2B), it is sent to the Fatoora platform for clearance. The platform responds with a cleared, stamped invoice.
7. A PDF/A-3 file is generated containing the visual presentation with the signed XML embedded, and it is delivered to the client.
8. The signed copy is archived, and its hash becomes the PIH value of invoice number 143.

Notice how the output of each step is the input of the next, and how the hash of this invoice did not complete its function until it became the link to the subsequent invoice. This is what the chain means in practice.

Infographic three: Clearance versus Reporting

How the chain holds together: the links between the stages

The real value of this journey is not in each individual stage, but in their interconnection. Three threads bind the stages together:

• The hash thread: The hash of each invoice (stage three) becomes the PIH value of the following invoice (stage two), so an unbreakable chain is formed.
• The counter thread: The increasing ICV value proves that no invoice was deleted or inserted out of sequence.
• The signature thread: The cryptographic stamp (stage four) ties the invoice to the business’s identity via the CSID certificate, so it cannot be impersonated.

This interconnection is the essence of the Phase Two philosophy: a system that does not rely on the business’s trust alone, but on an auditable cryptographic proof at every step. Any tampering attempt breaks one of the three threads and is detected immediately. If someone deletes an invoice from the chain, the ICV sequence breaks. If they alter its content, its hash changes and no longer matches the PIH of the following invoice. And if they forge a complete invoice, signature verification fails for lack of the correct key.

The role of the accounting platform in executing the journey

The business is not required to build the XML manually, nor to compute the hashes, nor to manage the keys. These are all technical tasks handled by the compliant accounting platform. In line with the Phase Two requirements, Qoyod executes the eight stages automatically: it builds the UBL XML file with the mandatory elements, assigns the identifiers, computes the hash, signs via the managed CSID certificate, validates locally, handles clearance or reporting according to the invoice type, then delivers the PDF/A-3 and archives the copy.

What remains for the business is a single action: connecting the CSID certificate with the Fatoora platform once at the outset. After that, the full journey runs in the background with every invoice. This separation between «what the business does» and «what the system executes» is what makes compliance practical for thousands of businesses without a specialized technical team. The system turns eight complex technical stages into a single button press.

Common errors and how they are detected at each stage

Because each stage has entry and exit conditions, each stage also has its own error patterns. Knowing the location of the error shortens the diagnosis:

• In generation: A missing mandatory element or a tax registration number in the wrong format. The error does not appear here immediately; it is detected later at the validation stage.
• In identifiers: A repeated or decremented ICV value breaks the sequence, and a wrong PIH value breaks the chain’s link to the previous invoice.
• In hashing: Computing the hash on a non-canonical version produces a hash that does not match the one the platform computes, so validation fails despite the content being sound.
• In signing: Using an expired or unlinked certificate produces a signature the platform rejects.
• In validation: A mismatch between the sum of the line items and the total, or an incorrect tax rate, stops the invoice with a specific error code.
• In clearance: A rejection by the platform for compliance reasons returns the invoice without approval, so it is not delivered to the buyer.

The practical benefit is that the developer does not search randomly for the cause of failure; instead, they look at the stage where the invoice stopped and know the expected category of error. This is what makes conceiving the journey as a lifecycle of engineering value, not just a theoretical description. Local validation before sending catches most of these errors before they reach the platform, reducing rejection cycles and preserving issuance speed.

What remains is that the compliant accounting platform handles preventing most of these errors from the outset: it builds the file with the correct elements, and manages the counters, hashes, and certificates automatically, so all that is left for the user is entering the actual invoice data. In this way, the technical responsibility shifts from the business to the system, and compliance stays guaranteed at every link of the journey.

Frequently asked questions

Can any stage in the invoice lifecycle be skipped?

No. Each stage takes the output of its predecessor as its input. You cannot sign before computing the hash, nor clear before validation, nor deliver before clearance in B2B invoices. The chain is fully sequential.

What is the difference between Clearance and Reporting?

Clearance is a synchronous process for standard invoices (B2B): the invoice is sent to the Authority and approved before it is delivered to the buyer. Reporting is an asynchronous process for simplified invoices (B2C): it is delivered to the buyer immediately, then reported to the Authority within 24 hours.

What is the relationship between PIH and the invoice hash?

The PIH value of the current invoice is the hash of the invoice that immediately preceded it. This link creates an interconnected chain that reveals any subsequent deletion, insertion, or alteration.

Does the developer need to deal directly with the CSID certificate for every invoice?

No. The CSID certificate is linked once at setup, then the accounting platform manages it automatically for every signature. There is no need for manual handling of keys with each issuance.

Why is the PDF/A-3 format used specifically for delivery?

Because it is a long-term archival format that allows the original XML file to be embedded inside the human-readable PDF file. This way the buyer gets a copy a human reads and a copy systems read in a single file.

How long is the archived invoice retained?

The invoice is retained for the entire statutory retention period defined by the Authority, in its original signed format along with its hash and its clearance or reporting status, so it remains auditable later.