Introduction to ZATCA Technical Identifiers

As Saudi Arabia moves deeper into Phase 2 (Integration Phase) of the Fatoora project, the technical complexity of electronic invoicing has increased. For Saudi SMEs, compliance is no longer just about generating a PDF with a QR code; it is about ensuring that every XML file sent to the ZATCA (Zakat, Tax and Customs Authority) portal contains specific, immutable identifiers.

Two of the most critical components in this technical framework are the UUID (Universally Unique Identifier) and the ICV (Invoice Counter Value). Together with the Previous Invoice Hash (PIH), these elements create an unbreakable chain of records that prevents data tampering and ensures the integrity of the Saudi tax ecosystem.

In this guide, we will break down what these terms mean, why they are mandatory, and how Qeemah’s ZATCA Hub automates these complexities for your business.

1. What is a UUID (Universally Unique Identifier)?

A UUID is a 128-bit number used to uniquely identify an invoice across all systems in the Kingdom. Unlike an internal invoice number (which might reset or overlap between different companies), a UUID is globally unique.

✅ UUID Technical Requirements

Format: It must follow the RFC 4122 standard (Version 4).
Structure: A 36-character string containing hexadecimal digits and hyphens (e.g., 550e8400-e29b-41d4-a716-446655440000).
Placement: In the ZATCA XML (UBL 2.1), it is located under the cbc:UUID tag.
Immutability: Once a UUID is assigned to an invoice and submitted to ZATCA, it must never change. Even if the invoice is rejected and needs correction, a new UUID must be generated for the corrected version.

⚠️ Why UUID Matters

ZATCA uses the UUID to track the lifecycle of a document. If you attempt to submit two different invoices with the same UUID, the system will trigger a rejection error. This ensures that no two transactions can ever be confused or duplicated in the national database.

2. Understanding the Invoice Counter Value (ICV)

The Invoice Counter Value (ICV) is a sequential numeric value assigned to each invoice generated by a specific E-Invoicing Solution (Unit).

Key Rules for ICV:

Strict Sequentiality: The counter must start at 1 for the first invoice generated by a device and increment by exactly 1 for every subsequent document (Invoice, Credit Note, or Debit Note).
No Gaps: You cannot skip numbers (e.g., going from ICV 10 to ICV 12).
No Resets: The counter should not reset at the beginning of a new month or year. It continues for the lifetime of the cryptographic stamp (CSID) associated with that device.

📋 ICV Comparison Table

Feature	Internal Invoice Number	Invoice Counter Value (ICV)
Purpose	Business tracking/Reference	ZATCA sequence integrity
Format	Flexible (e.g., INV-2024-001)	Numeric only (e.g., 1, 2, 3)
Requirement	Business preference	Mandatory for Phase 2
XML Tag	`cbc:ID`	`additional:Item` (under Sequence Number)

3. The “Chain of Trust”: UUID, ICV, and PIH

ZATCA Phase 2 introduces the concept of Invoice Chaining. This mechanism ensures that invoices cannot be deleted or inserted retroactively without detection.

How the Chain Works:

Invoice N: Contains its own UUID and ICV.
Previous Invoice Hash (PIH): Invoice N must also contain a cryptographic hash of the entire XML of Invoice N-1.
The Result: If you try to change Invoice #5, the hash stored in Invoice #6 will no longer match, breaking the chain.

💡 Pro Tip: Managing this manually is impossible for human staff. This is why using a certified cloud accounting software like Qeemah is essential; our system automatically calculates the hash of the previous invoice and embeds it into the current one in milliseconds.

When integrating with the ZATCA Fatoora portal, developers and accountants often encounter these specific error codes:

KSA-1: Duplicate UUID. Occurs when an invoice with a UUID that already exists in the ZATCA database is submitted again.
KSA-9: Invalid ICV. Occurs when the sequence is broken (e.g., submitting ICV 5 when the last recorded was ICV 3).
KSA-13: Invalid Previous Invoice Hash. Occurs when the PIH provided does not match the actual hash of the previous document.

If you encounter these errors, you can use our ZATCA XML Viewer to inspect your file structure and identify the mismatch.

5. Checklist for Saudi Business Owners

To ensure your business remains compliant with Phase 2 requirements, follow this checklist:

Verify Software Certification: Ensure your provider is listed on ZATCA’s approved solution providers list.
Audit Your Sequences: Check if your current system allows for “gaps” in invoice numbers. If it does, it is non-compliant for Phase 2.
Check Multi-Device Handling: If you have multiple branches or POS terminals, each must have its own unique serial number and independent ICV sequence.
Data Retention: Ensure your system stores the UUID and PIH for at least 6 years as per Saudi Labor and Tax laws.

How Qeemah Simplifies ZATCA Compliance

Technical terms like UUID, ICV, and PIH can be overwhelming for business owners who want to focus on growth, not XML tags. Qeemah is designed specifically for the Saudi market to handle these complexities behind the scenes.

Automated Chaining: Qeemah automatically generates the UUID and manages the ICV sequence for every transaction.
Instant Validation: Our system validates your invoice against ZATCA rules before submission, preventing rejection errors.
Seamless Integration: Whether you are issuing a simple B2C invoice or a complex B2B tax invoice, Qeemah ensures the QR code and XML are 100% compliant.
Financial Clarity: Beyond compliance, get full visibility into your business with our Accounting & Finance module.

Don’t risk fines or business interruptions.

Explore Qeemah’s ZATCA Phase 2 Solutions | View Pricing Plans | Contact our Experts

ZATCA UUID and Invoice Counter Requirements: A Guide for Saudi SMEs