Phase 2 E-Invoicing Requirements: The Full Technical Checklist

Phase 2 of e-invoicing is not merely a deadline your business must meet; it is a set of precise technical requirements that your accounting system must satisfy before you can issue your first compliant invoice. In Phase 1 it was enough to generate a structured digital invoice and store it. Phase 2, however, mandates a direct connection with the Fatoora platform operated by the Zakat, Tax and Customs Authority, a cryptographic signature, and a specific data structure for every invoice.

This guide does not repeat the wave dates or the rollout timeline. If you want to know your business’s exact wave date, you will find it in the guide E-invoicing rollout phases and dates. Here we focus on one thing only: the actual list of technical requirements for the Integration Phase, and what your system must produce for every invoice so that it is accepted.

What Phase 2 means at the technical level

Phase 2 is officially known as the Integration Phase. The core idea is that the invoice is no longer a local file on your device, but a structured message sent to the Fatoora platform the moment it is issued or within a defined window afterward. The Authority validates every invoice, signs or clears it, then returns it to you.

This shift requires capabilities your accounting system did not need before. It must generate the invoice file in a standard format, seal it with a cryptographic stamp, link it to the chain of previous invoices, and connect to a secured API with the Authority. Any missing link in this chain means a rejected invoice.

The difference between the two phases is clear in the following points:

• Phase 1: Issuing and storing a structured digital invoice, with no direct connection to the Authority.
• Phase 2: Real-time connection to the Fatoora platform, a cryptographic signature, a unique identifier, and a hash chain linking invoices.

To understand the details of what Phase 1 required, review the guide Phase 1 of e-invoicing. And for a full overview of the Saudi framework, browse the e-invoicing official page.

Phase 2 requirements in a single view

The technical requirements of Phase 2 come down to six interrelated pillars. It is not enough for your system to satisfy some of them; it must satisfy all of them on every invoice. We review each pillar in detail in the sections below.

Pillar one: registration and the digital certificate (CSID)

Before you can issue any compliant invoice, your system must obtain a digital identity certificate from the Authority. This certificate is called the Cryptographic Stamp Identifier, or CSID for short. It acts as an authenticated identity that links your issuing device to the Authority, and invoices cannot be signed without it.

Obtaining the certificate happens in two stages. The first is the initial compliance certificate, issued after your system passes the compliance tests in the simulation environment. The second is the production certificate, known as the PCSID, issued when you move to the live environment. The first is for testing, the second for real operation.

The technical steps to obtain the certificate:

1. Generate a Certificate Signing Request (CSR) from within your accounting system.
2. Enter the One-Time Password (OTP) you obtain from the Fatoora portal at the Authority.
3. Receive the initial compliance certificate (CSID) and store it securely.
4. Run test invoices in the simulation environment to confirm acceptance.
5. Request the production certificate (PCSID) and move to live issuance.

The certificate is tied to the issuing unit, meaning a specific point of sale, branch, or system. A business with several branches or several issuing systems needs a certificate for each unit. Managing and renewing these certificates is part of the technical requirement, not a one-time step that is done once and forgotten.

Many businesses stumble at this step specifically, because it involves dealing with encryption keys and signing requests. A good accounting system hides this complexity: you simply enter the verification code from the Fatoora portal, and the system handles the rest of the steps. This turns a thorny technical process into a few clicks inside a simple interface.

It is also important to watch the certificate’s validity. The certificate has a defined lifespan, and as it nears expiry it must be renewed before your ability to issue is cut off. A compliant system alerts you to the renewal date and handles it with the least possible intervention, so your invoicing does not stop suddenly.

Pillar two: the invoice structure in UBL 2.1 XML format

In Phase 2 the invoice is not a PDF file or an image. It is a structured XML file that follows the UBL 2.1 standard, the internationally adopted standard for commercial documents. This standard precisely defines how every field in the invoice is written, from the seller’s name to the tax amount on each line item.

The invoice takes two accepted forms. The first is a pure XML file for business-to-business invoices. The second is a PDF/A-3 format containing an embedded XML file, often used with simplified invoices directed at individuals. In both cases, the structured data is what the system reads, not the visual layout.

The most important mandatory fields your system must generate within the UBL file:

• The seller’s tax number, legal name, and national address.
• The buyer’s details for business-to-business invoices, including their tax number.
• The issue date and time to the precision of the timestamp.
• The details of each line item: description, quantity, unit price, tax rate, and tax amount.
• The invoice total before tax, the tax amount, and the final total.
• The additional seller identifier when dealing with government entities.

Any missing field or field that does not conform to the standard’s rules leads to the invoice being rejected. This is why the system must build the file according to the rules automatically, rather than leaving its formatting to the user. The difference between a structured invoice and the old paper invoice is made clear in the guide Types of electronic invoices.

The importance of the standard lies in it being a unified language that the Authority’s systems understand without ambiguity. When all businesses adhere to the same structure, the system can validate millions of invoices automatically. This is why there is no room for improvisation in the order or wording of fields; the rules are defined and strict.

The standard also imposes arithmetic rules on the values inside the invoice. The sum of the line items must equal the total before tax, the tax amount must match the applied rate, and the final total must accurately add the two together. Any conflict between these values is detected by the system and the invoice is rejected. An accounting system that calculates these values automatically protects you from this type of error.

Pillar three: the cryptographic stamp and digital signature

Every invoice in Phase 2 must carry a cryptographic stamp. The cryptographic stamp is a digital signature created using the private key associated with the CSID certificate. Its purpose is to prove that the invoice was issued by an authenticated party and that it has not been altered after issuance.

The stamp relies on public-key infrastructure, where your system holds a private key it signs with and a public key that lets the Authority verify the signature’s validity. The signature is computed over the invoice content itself, so any change to a number or letter breaks the signature and immediately reveals tampering.

In practical terms, your system must be able to create the signature and store it within the invoice in a standard format, and to manage the keys securely without exposing the private key. This is a complex technical process, which is why the accounting system handles it automatically rather than asking it of the user.

The core idea behind the stamp is that it turns the invoice into an authenticated, non-repudiable document. The seller cannot disown an invoice they signed, the buyer can confirm its source, and the Authority verifies its integrity. This digital trust is what makes the electronic invoice a full legal substitute for paper.

Note that the stamp differs from merely encrypting the invoice. Encryption hides the content, whereas the stamp proves its authenticity without hiding it. The invoice remains readable, but it carries a signature that reveals any tampering. This distinction matters for understanding what your system actually does in every issuance.

Pillar four: the unique identifier (UUID) and the hash chain

Phase 2 requires every invoice to carry a globally unique identifier called a UUID. This identifier distinguishes the invoice from any other invoice in the entire system and prevents duplication or forgery in numbering.

Alongside the unique identifier, the system must compute a hash value for each invoice. The hash is a digital fingerprint derived from the invoice content. More importantly, every invoice also carries the hash of the invoice before it, forming an interlinked chain known as the hash chain.

The benefit of this chain is that it guarantees the integrity of the sequence. If someone tried to delete an invoice or insert an invoice in the middle, the chain would break and the defect would appear. This mechanism makes the invoice ledger a record that resists retroactive tampering. It is your system’s responsibility to compute the hash and link it to the previous invoice on every issuance, without manual intervention.

The unique identifier (UUID) differs from the usual sequential invoice number. An invoice number may recur between two businesses, whereas the unique identifier is designed to be unique on a global level. This ensures that every invoice in the Authority’s system carries a fingerprint that matches no other invoice.

Combining the unique identifier with the hash chain builds a tightly controlled record. The identifier guarantees no duplication, and the chain guarantees no deletion or insertion. Together they form a layer of protection that makes tampering with invoices nearly impossible, which is a core objective of Phase 2.

Pillar five: the QR code

Every invoice, and especially the simplified invoice directed at individuals, must carry a QR code. But the QR code in Phase 2 is not just an image; it contains structured data that the Authority and the buyer can read and verify.

The data inside the code includes specific elements:

• The seller’s name and tax number.
• The timestamp of the invoice’s issuance.
• The invoice total and the tax amount.
• The value of the invoice’s cryptographic stamp.
• The public key and certificate data in simplified invoices.

This structure makes the code a real verification tool, not decoration on paper. The Authority’s app can read the code and confirm that the invoice was genuinely issued by an authenticated party. Your system must generate the code with this structure automatically for every invoice.

In the simplified invoice specifically, the code gains double importance. Because this invoice is issued to individuals and reported to the Authority later, the code becomes the instant verification method available to the buyer at the point of purchase. Any customer can scan the code and confirm the integrity of their invoice on the spot.

Correctly encoding the data inside the code follows a specific format imposed by the Authority. It is not enough to place the data as plain text; it must be encoded in the way the verification systems expect. This is another technical detail that justifies relying on an accounting system to handle it precisely rather than building it manually.

Pillar six: the integration model, Clearance versus Reporting

Here a fundamental difference appears that is often misunderstood. Phase 2 distinguishes between two types of integration depending on the invoice type. A precise understanding of this difference is essential because the way you deal with the Authority differs between them.

Clearance model: This applies to the tax invoice between businesses. Here the invoice is sent to the Fatoora platform and awaits clearance before it is delivered to the buyer. In other words, the invoice is not legally complete until the Authority clears it in real time.

Reporting model: This applies to the simplified tax invoice directed at individuals. Here the invoice is issued and delivered to the buyer immediately, then reported to the Authority within a maximum window of twenty-four hours from issuance. Reporting is subsequent, and issuance is immediate.

The difference between the two models is summarized in the following table:

A deep understanding of this split helps you know what the customer expects and what reaches the Authority in each case. For more detail on invoice classifications, review the guide Types of electronic invoices.

The API: how your system connects to the Fatoora platform

The six pillars above describe what the invoice carries. But a practical question remains: how does the invoice actually reach the Authority? The answer is through an Application Programming Interface, or API, provided by the Fatoora platform. This interface is the channel through which your system sends every invoice and receives the Authority’s response.

The API handles three main operations that your system must support:

• Compliance request: Your system sends test invoices to the compliance endpoint to confirm they conform before production.
• Clearance: The business-to-business tax invoice is sent to the clearance endpoint, and the system waits for a response carrying the acceptance or rejection status.
• Reporting: The simplified invoice is sent to the reporting endpoint within the defined window after issuance.

Every connection happens over a secure protocol and carries the invoice data in a structured format along with the signature. The Authority responds to each request with a message determining whether the invoice was accepted, rejected, or accepted with notes. It is your system’s responsibility to read this response and act on it: deliver the accepted invoice, retry the rejected one after correction, and log the notes.

The important thing to understand here is that integration is not an operation performed once. It is an ongoing dialogue between your system and the Authority on every invoice throughout the day. This is why the system needs a reliable mechanism to manage this dialogue, including handling connection interruptions and resending.

The stability of this connection is a fundamental condition for your invoicing to continue. If the connection fails while issuing a business-to-business invoice, the invoice will not be completed until the connection returns and clearance arrives. The simplified invoice, on the other hand, is issued immediately and reporting stays within the available window. A good system manages these cases calmly, storing pending invoices and resending them automatically when the connection returns, without letting that halt your sales activity.

The most common reasons for invoice rejection

Knowing the common reasons for rejection helps you assess your system’s readiness. Most rejection cases go back to technical errors that can be avoided if the system builds the invoice correctly from the start.

The most prominent of these reasons:

• A missing or incorrect mandatory field: Such as a missing tax number or a wrong date format in the UBL file.
• An invalid cryptographic stamp: This occurs when the invoice is edited after being signed, or due to an error in key management.
• A break in the hash chain: When the invoice is not linked correctly to the hash of the previous invoice.
• A missing or non-conforming QR code: When one of the required elements inside the code is absent.
• An expired or inactive certificate: When the certificate expires without renewal, or when issuance is attempted before obtaining the production certificate.

The common denominator among these reasons is that they are all technical errors in building or managing the invoice. When the accounting system handles these details automatically, most rejection reasons disappear. To assess your business’s readiness methodically before your wave date, the accounting software page helps you understand the required capabilities.

The checklist: what your system must produce

After reviewing the six pillars, we summarize the requirement as a practical checklist. Your accounting system is ready for Phase 2 only if it is able to do each of the following automatically:

• Generate a Certificate Signing Request and obtain the CSID then the PCSID from the Authority.
• Build every invoice in UBL 2.1 XML format with all its mandatory fields.
• Apply the cryptographic stamp to every invoice using the private key.
• Generate a unique identifier (UUID) for every invoice.
• Compute the hash value and link it to the previous invoice in a connected chain.
• Create a QR code carrying the required structured data.
• Connect to the Fatoora platform through a secured API for clearance or reporting.
• Handle the clearance model for business-to-business invoices and the reporting model for simplified invoices.
• Test all of this in a simulation environment before moving to production.

Any missing item in this list means your business is not ready for Phase 2. For a quick assessment of your business’s readiness, use the e-invoicing readiness checklist.

How Qoyod helps you meet Phase 2 requirements

The technical side of Phase 2 is complex, but it becomes simple when a compliant accounting system handles it. Qoyod is designed to satisfy every one of the six pillars without you writing a single line of XML or managing a cryptographic key yourself.

• Full compliance with both phases: Qoyod issues invoices compliant with Phase 1 and Phase 2 per the requirements of the Zakat, Tax and Customs Authority.
• Automatic exchange with the Authority: Qoyod connects your invoices to the Fatoora platform and handles clearance and reporting automatically according to the invoice type.
• A simulation environment for testing: Qoyod lets you test your invoices in a safe simulation environment before live issuance, so you confirm acceptance without risk.
• Support for government entities: Qoyod supports invoices for government entities by adding the required additional seller identifier on saving.
• Reducing human error: Qoyod builds the invoice file, signs it, and generates its code automatically, so the likelihood of rejection due to a manual error drops.

In this way, the technical requirements we reviewed turn into automatic operations running in the background, while you focus on managing your business. Learn more about Qoyod’s Phase 2 compliance and about the details of integration with the Authority inside the accounting system.

Frequently asked questions

What is the difference between the CSID and PCSID certificates?

The CSID is the initial compliance certificate your system obtains after passing the simulation-environment tests. The PCSID is the production certificate issued when you move to the live environment. The first is for testing and the second for real operation.

Do I need to write the XML file myself?

No. A compliant accounting system builds the UBL 2.1 XML file automatically per the standard’s rules. Your task is to enter the ordinary invoice data, and the system handles generating the file, signing it, and sending it.

What is the difference between Clearance and Reporting in Phase 2?

Clearance applies to business-to-business invoices, where the invoice is cleared by the Authority before being delivered to the buyer. Reporting applies to simplified invoices for individuals, where the invoice is issued immediately and reported to the Authority within twenty-four hours.

What is the benefit of the hash chain between invoices?

The hash chain links every invoice to the one before it through a digital fingerprint. This guarantees the integrity of the sequence and reveals any attempt to delete an invoice or insert one in the middle, making the invoice record resistant to retroactive tampering.

Can I test the requirements before live issuance?

Yes. The Authority provides a simulation environment that lets you run test invoices and confirm their acceptance before moving to production. A compliant accounting system like Qoyod gives you this environment to test without risking your actual data.

What happens if my invoice does not conform to the technical requirements?

A non-conforming invoice is rejected by the Fatoora platform, meaning it is not legally valid. Any missing field in the UBL file, a wrong cryptographic stamp, or a missing identifier leads to rejection. This is why the system must build the invoice entirely automatically to guarantee its conformity.