When a single enterprise with one tax number operates across several branches or devices, the most important question in Phase Two of e-invoicing integration becomes: how does each point issue its own invoice without conflicting with the rest? The Zakat, Tax and Customs Authority (ZATCA) treats every device that issues invoices as an EGS invoice-generation unit in its own right, even if all branches sit under one tax number and one trade name. This division is the essence of «Multi-Branch invoicing».
In this technical documentation we explain how a single enterprise splits into several independent issuing units, how each unit obtains its own certificate, counter, and hash chain, how the branch data appears inside the invoice, then we compare the centralized model with the distributed model, and finish with how reports are aggregated for a single tax entity. The goal is for the developer or system administrator to come away with an accurate picture before connecting the first branch.
One enterprise, several branches: where is the technical difference?
From a tax standpoint, the enterprise is a single entity with one VAT registration number. This enterprise files a single tax return that combines the sales of all branches. But from the technical standpoint of e-invoicing, the situation is entirely different.
Every actual issuing point, whether a full branch or a point-of-sale device inside the branch itself, is treated as an independent invoice-generation unit. The unit here is not the enterprise, but the device or system that creates the invoice, signs it, and submits it. This means a single enterprise may contain ten issuing units or more.
The reason for this separation is purely technical. Each unit signs its invoices with its own cryptographic certificate, keeps an independent sequential counter that no one else shares, and builds a separate hash chain that links each invoice to the one before it within the same unit only. If we tried to group several devices under one identifier, the counter numbers would overlap, the hash chain would break, and the Authority would be unable to verify sequence integrity.
Early takeaway: the tax number is single at the enterprise level, while the issuing identity is multiple at the device and branch level. Understanding this separation resolves most integration errors in multi-branch environments.
A practical grounding on the ground
Imagine a restaurant chain with one tax number and three branches in different cities. Each branch has two point-of-sale devices. The number of units here is six issuing units, not one branch and not one enterprise. Each of the six devices needs its own certificate, its own counter, and its own hash chain. But the tax return remains a single return for the enterprise.
Every branch or device is an independent EGS unit
An invoice-generation unit (EGS Unit) is any software component or device capable of creating an electronic invoice compliant with the Authority’s specification, signing it, and submitting it to the Fatoora platform. In a multi-branch environment, this unit is repeated by the number of issuing points.
The Authority defines each unit through a fixed set of data registered at setup time, most notably the unit’s industrial or serial identifier, the trade name, the enterprise’s tax number, and the branch address. This identifier is what distinguishes one device from another within the same enterprise, and is known in the specification as the EGS Serial Number.
The format of the unit serial identifier follows a three-part pattern that separates the manufacturer name, the model name, and the device serial number, in this shape:
The serial number must be unique for every device within the enterprise. Two devices may not carry the same identifier, because this identifier is embedded inside the certificate request and becomes part of the unit’s identity on the platform. A duplicate identifier means a duplicate identity, which the Authority’s system rejects.
Why aren’t all branches grouped under a single unit?
It might seem simpler to route the invoices of all branches through one central server with a single certificate. This option is technically possible and is known as the centralized model, which we will cover shortly, but it does not eliminate the principle of multiple units. Even in the centralized model, each logical issuing point is registered as a unit with its own identifier inside the central system.
The reason is that the hash chain and the invoice counter must be sequential and unbroken within each unit. If two branches issued two invoices at the same instant under a shared counter, they would contend for the same number. Splitting into units prevents this contention from the outset.
The certificate, counter, and hash chain per unit
Each issuing unit has three technical assets that are not shared with any other: the cryptographic certificate, the invoice counter, and the hash chain. Understanding these three is what separates sound integration from broken integration in a multi-branch environment.
1. The CSID cryptographic certificate per unit
Each unit obtains a Cryptographic Stamp Identifier, abbreviated CSID. This certificate is what the device signs its invoices with, and it proves to the Authority that the invoice was issued by an authorized unit. The unit goes through two stages to obtain the certificate: the temporary compliance certificate (Compliance CSID) during testing, then the production certificate (Production CSID) after passing the readiness checks.
In an enterprise with three branches and six devices, we deal with six separate production certificates, one per device. A device’s certificate may not be copied to another, because the certificate is tied to the unit serial identifier it was generated for. The certificate’s private key stays inside the device and never leaves it.
2. The ICV invoice counter per unit
The invoice counter ICV (Invoice Counter Value) is a sequential number that increments by one with every invoice the unit issues. The first invoice on the device has a value of 1, the next 2, and so on with no gaps and no repeats. This counter is entirely independent per unit.
This means the Riyadh branch device may have its counter at 4,520 while the Jeddah branch device is at 980 at the same moment. There is no relationship between the two counters, and they are not expected to match. The common mistake is trying to unify the counter at the enterprise level, which breaks the unbroken-sequence requirement within the unit.
3. The PIH hash chain per unit
The Previous Invoice Hash PIH (Previous Invoice Hash) is a field that carries the fingerprint of the invoice that preceded the current invoice within the same unit. Every new invoice carries in its header the fingerprint of its predecessor, forming a linked chain that cannot be tampered with without detection.
The chain starts from a fixed initial value for the first invoice in the unit, then each invoice links to its predecessor. As with the counter, the chain is separate per device. The Riyadh branch chain never touches the Jeddah branch chain at all. Mixing chains between devices is one of the most dangerous errors in multi-branch integration.
Illustrative caption for the first unit
Enterprise with one tax number
Several branches under the enterprise
Each device/branch is an independent EGS unit
Data aggregates centrally for reporting
How branch data appears inside the invoice
Since the enterprise has one tax number, this number stays constant across the invoices of all branches. But the practical question is: how do we distinguish a Riyadh branch invoice from a Jeddah branch invoice within the invoice file itself? The answer lies in the address and identifier fields inside the invoice structure.
The seller data is recorded in the invoice under the seller party (AccountingSupplierParty). The enterprise’s tax number stays unified in the tax registration field, while the address of the issuing branch is loaded into the seller’s postal address field. This way the invoice carries the enterprise’s unified identity and the actual branch address together.
In practice, the system distinguishes the issuing branch by three elements combined: the unit serial identifier that belongs to the device, the branch address in the seller’s postal address, and an optional extension in the internal invoice number that carries the branch code. These elements are enough to trace any invoice down to the device that issued it.
The internal invoice number and the branch code
The invoice number the customer sees (Invoice Number / ID) is independent of the technical ICV counter. Many systems embed the branch code inside the visible invoice number to ease human tracking, such as a prefix indicating the city or branch. This code is for internal organization and does not affect the invoice structure approved by the Authority.
The centralized model versus the distributed model
A multi-branch enterprise has two ways to organize its issuing units: a centralized model in which all units are managed from a single server, and a distributed model in which each branch manages its issuing locally. Each model has a place that suits it, and choosing between them is an architectural decision that precedes integration.
The centralized model
In the centralized model, all branches send their sales data to a single central accounting system, which handles generating the invoices, signing them, and submitting them to the Fatoora platform. Each issuing point remains an independent logical unit with its own identifier, counter, and chain inside the central system, but certificate management and signing happen in one place.
This model suits branches always connected to the internet over a reliable network, where certificates and updates are managed centrally. Its advantage is that it simplifies maintenance and unifies monitoring. Its drawback is that a loss of connection to the central server may halt issuing across all branches at once.
The distributed model
In the distributed model, each branch carries a local issuing unit that works even if the connection to the center is lost. Each device signs its invoices locally with its own certificate, and keeps its counter and chain on the device itself, then syncs with the center when a connection is available.
This model suits remote branches or those with unstable connectivity, and direct-to-consumer (B2C) sales branches where the simplified invoice is delivered instantly and reported to the Authority within twenty-four hours. Its advantage is flexibility when the network drops. Its drawback is that certificate management and monitoring are distributed across several devices, so they need tighter organization.
Illustrative caption comparing the two models
Its own CSID cryptographic stamp certificate
An independent ICV invoice counter
Its own PIH hash chain
Independent registration on the Fatoora platform
Handling multi-device points of sale
The most common branch environment is the point-of-sale environment, where a single branch contains several cashier devices operating at the same time. Each cashier device is an independent issuing unit with its own certificate, counter, and chain, exactly as if it were a separate branch. For more detail on this scenario, review the Invoice integration with POS point-of-sale systems.
documentation. In this environment, each cashier device must carry its unique serial identifier from the moment of setup. If a new device enters the branch, it is registered as a new unit and obtains its own certificate before issuing its first invoice. A new device may not inherit an old device’s certificate.
You must also note that issuing the simplified invoice at the point of sale happens locally and instantly, then the Authority is reported to afterward. This makes the distributed model usually the most suitable for points of sale, because the customer must not wait for the platform’s response at payment.
Adding a new branch or device
When expanding by opening a new branch or adding a device, the steps are fixed: generate a unique serial identifier for the unit, then request the compliance certificate, then pass the readiness checks, then activate the production certificate. The new unit’s counter starts from 1 and its chain starts from its initial value. No existing branch is affected by this addition.
It is important to carry out these steps in order. The new device may not issue any production invoice before the production certificate activation is complete, because any invoice before that will be rejected by the platform. It is also recommended to record the unit identifier and its activation date in an internal log, so that later it is easy to trace any invoice down to the device that issued it and the date it began operating.
The unique UUID identifier for the invoice in a branch environment
Alongside the ICV counter and the PIH chain, each invoice carries a globally unique identifier known as the UUID. This identifier distinguishes the single invoice from all the enterprise’s invoices, regardless of the branch or device that issued it. While counter number 1 repeats in every unit, the UUID stays unique across the whole enterprise.
This separation between identifiers matters in a branch environment. The ICV counter guarantees the unbroken sequence within the unit, while the UUID guarantees absolute uniqueness across all units. So if two devices both issued their invoice number 1, each remains entirely distinct by a different UUID. This prevents any confusion when aggregating invoices from all branches in the reporting layer.
When integrating branches, the system must ensure a unique UUID is generated for each invoice regardless of branch. Systems that rely on local UUID generation on each device must use an algorithm that guarantees uniqueness without central coordination, so that the same identifier is not generated on two devices at the same time.
Unified reports for the single tax entity
Despite the multiple issuing units, the enterprise remains a single tax entity that files a single return. This is where aggregation comes in: the accounting system aggregates the invoices of all units under the single tax number, so that the sales of all branches appear in the unified VAT report.
Aggregation happens at the data level, not the issuing level. That is, each unit issues, signs, and reports independently, then the accounting system aggregates all these invoices into a single report for the return. This separation between «distributed issuing» and «aggregated reporting» is the essence of managing a multi-branch enterprise.
Unified reports make it easy for the enterprise to see the performance of each branch on its own, then combine them for the tax return. The report can be filtered by branch to analyze each location’s sales, then show the total for the whole enterprise. This ability to analyze by branch while aggregating for the return is what any branch chain needs.
What does the system aggregate and what stays distributed?
Stays distributed: the signing, the counter, the hash chain, the certificate, and the instant reporting per unit. Aggregates centrally: the sales report, total output tax, tax-return data, and per-branch performance analysis. Separating the two layers preserves the integrity of individual invoices and unifies the financial picture.
In practice, the accounting system keeps a reference for every invoice linking it to the branch and device that issued it. This reference is what makes it possible to build a filterable report: the enterprise can show Riyadh’s sales alone, or Jeddah’s alone, or the total. And when preparing the return, the system aggregates the output tax from all branches into a single figure submitted to the Authority under the unified tax number.
Note an important point during reconciliation: the sum of all units’ invoices must equal the total sales in the return. Any gap between the two figures means an invoice that was not aggregated or a unit that did not sync with the reporting layer. It is therefore best to run a periodic reconciliation report that compares the number of invoices issued by each unit with the number of invoices that reached the unified report.
| Layer | Level | Example |
|---|---|---|
| Signing and submission | Distributed per unit | Each device signs with its certificate and reports to the platform |
| ICV counter and PIH chain | Distributed per unit | Independent counter and chain per device |
| The UUID identifier | Unique across the enterprise | Not repeated between any two invoices |
| The tax number | Unified for the enterprise | One number across all invoices |
| Tax report and return | Aggregated for the enterprise | Total sales of all branches in a single return |
Illustrative caption for the aggregation flow
| Criterion | Centralized setup | Distributed setup |
|---|---|---|
| Signing location | A single central system | Inside each branch |
| Connectivity | A single point | Per branch |
| Best suited for | Interconnected branches | Scattered branches or those without permanent connectivity |
Common errors in multi-branch integration
A set of errors recurs in multi-branch environments, most of them arising from trying to unify what should stay separate, or separating what should stay unified. Here are the most prominent:
The first error: unifying the counter at the enterprise level. This breaks the unbroken-sequence requirement within the unit, because each device must start from 1 and increment with no gap.
The second error: copying the certificate between devices. The certificate is tied to the unit serial identifier, and copying it means duplicating the identity, which the platform rejects at verification.
The third error: mixing hash chains. If a device takes the PIH value from another device’s invoice, the chain breaks and sequence-integrity verification fails.
The fourth error: changing the tax number per branch. The enterprise’s tax number is unified and does not change with the branch; only the branch address changes.
The fifth error: adding a new device without setup. Any new device needs a unique identifier and its own certificate before it issues its first invoice, and it may not inherit a previous device’s identity.
How Qoyod handles multi-branch invoicing
The Qoyod e-invoicing software manages the multi-branch environment such that it treats each branch or device as an independent issuing unit automatically. The system generates each unit’s serial identifier, manages its certificate, and keeps its counter and hash chain separate, with no manual intervention from the user.
When opening a new branch or adding a device, Qoyod takes care of the setup steps, the certificate request, and the readiness checks, so the unit becomes ready to issue. And at the reporting level, Qoyod aggregates the invoices of all branches under the single tax number, and enables sales analysis by branch alongside the unified total for the tax return.
This means the owner of a branch chain gets the correct technical separation at the issuing level, and the correct aggregation at the reporting level, without having to manage the certificates, counters, and chains themselves. Technical support is available 24 hours a day, seven days a week to help technical teams during connection.
Manage your multiple branches with compliant invoicing from one place
Qoyod treats each branch and device as an independent issuing unit, and aggregates their invoices under your single tax number in a unified report ready for the return, without manual management of certificates and counters.
Start your free trial and invoice all your branches in full compliance
Frequently asked technical questions about multi-branch invoicing
Does each branch need a separate tax number?
No. The enterprise has one tax number that stays unified across the invoices of all branches. What differs is the issuing unit identifier and the branch address inside the invoice, not the tax number.
Does the ICV counter start from a unified number across branches?
No. Each unit’s counter is entirely independent. Each device starts from 1 and increments with no gap within the same unit only, and there is no unified counter at the enterprise level.
Can a single CSID certificate be shared between several devices?
No. The certificate is tied to the unit serial identifier it was generated for. Each device needs its own certificate, and a device’s certificate may not be copied to another.
What is the difference between the centralized and the distributed model?
In the centralized model, all invoices are signed on a single server, which suits branches that are always connected. In the distributed model, each branch signs locally and keeps working when the network drops, which suits points of sale and remote branches.
How do you distinguish one branch’s invoice from another’s if the tax number is the same?
Through the issuing unit serial identifier, the branch address in the seller’s postal address, and optionally the branch code inside the visible invoice number.
How do branch sales appear in the tax return?
The accounting system aggregates the invoices of all units under the single tax number in a unified VAT report, with the ability to analyze sales by each branch on its own.
