E-invoice Integration with POS (Point of Sale) Systems

E-invoice integration with the point of sale (POS) is the scenario in which every payment made by the final consumer triggers the issuance of a simplified tax invoice (B2C) compliant with Phase Two of e-invoicing. The invoice is issued on the device at the moment of payment together with the QR code, delivered to the customer instantly, then reported to the Fatoora platform within a 24-hour window. This technical document explains how the POS device generates a valid invoice at the moment of sale, how each device is treated as an independent issuance unit (EGS), how the system handles internet outages, and how all of this ties together with the Qoyod e-invoicing software with the Qoyod point of sale system.

This guide addresses developers, system administrators, and owners of retail establishments that sell directly to individuals: shops, pharmacies, fuel stations, cafés, clinics, and every business that issues invoices at the point of payment. This scenario differs fundamentally from back-office ERP integration and from software integration through a direct API, each of which we have covered separately. Here we focus on the field case: speed, high invoice volume, and face-to-face selling.

Why the point of sale differs from other integration scenarios

The difference starts with the invoice type. A retail establishment issues a simplified tax invoice, which is the final-consumer invoice. This invoice follows the «Reporting» model: it is issued and delivered instantly without waiting for the Authority’s approval, then a copy is sent to the Fatoora platform afterwards. See the Reporting guide for the full detail of this path.

By contrast, back-office ERP integration mostly serves full business invoices (B2B), which fall under the «Clearance» model: the invoice waits for prior approval from the Authority before it is delivered to the buyer. This difference alone dictates a completely different technical design at the point of sale.

The logic behind the difference is practical. A single retail store may issue hundreds or thousands of invoices a day. If every invoice waited for instant approval from the Authority, payment queues would stall and selling would grind to a halt. That is why the Zakat, Tax and Customs Authority (ZATCA) allowed the instant issuance of the simplified invoice with deferred reporting, preserving the cashier’s speed while ensuring the data still arrives.

This results in three technical characteristics that distinguish the point-of-sale scenario:

• Issuance is local and instant on the device; it does not depend on a real-time round trip to the Authority before the sale is completed.
• The QR code is mandatory and visible on the customer’s receipt, because it is the field verification method for the invoice.
• Every POS device is registered as an independent issuance unit (EGS Unit) with its own technical certificate.

Next section heading: point-of-sale invoice flow diagram

The POS device as an independent issuance unit (EGS Unit)

In Phase Two of e-invoicing, the Authority does not treat your establishment as a single entity at issuance; instead it deals with each issuance device individually. The device that generates invoices is called the E-invoice Generation Solution, abbreviated as EGS Unit. Every cash register, every POS device, and every issuance application counts as an independent EGS unit.

This distinction is fundamental in retail. A store with three payment registers has three EGS units. Each unit goes through an independent onboarding cycle with the Fatoora platform and obtains its own technical certificate. Two devices may not share a single certificate.

The certificate that links the unit to the Authority is the technical compliance certificate, and its identifier is CSID (not CCSI). This certificate is what the device signs its invoices with, and it is what proves the invoice was issued by an approved unit. For the full technical detail, see the Compliance CSID certificate guide.

Onboarding cycle for a new POS device

When a new cash register is added, the device goes through a sequence of steps before it issues its first valid invoice. The steps in order:

1. Generate a key pair (a private key and a public key) inside the device or system.
2. Create a certificate signing request CSR carrying the establishment’s data and the unit identifier.
3. Request a one-time password (OTP) from the Fatoora platform through the Authority’s portal.
4. Send the compliance request and receive the compliance certificate CSID.
5. Pass the compliance checks on invoice samples, then receive the production certificate PCSID.

With the Qoyod system, the platform handles this cycle for every POS device automatically, and manages the certificates and their renewal without manual intervention. For an overview of the full onboarding path, see the onboarding and connection to the Fatoora platform guide.

How the POS device generates a valid simplified invoice

At the moment of payment, the device builds an invoice in UBL 2.1 format carrying a set of mandatory elements. Each element is generated locally on the device fractions of a second before printing. The core elements:

The QR code on the simplified invoice is not a decorative image. It is a mandatory field carrying nine elements in TLV (Tag-Length-Value) encoding, with the result then encoded in Base64. These elements include the seller’s name, tax number, the date and time stamp, the invoice total, the tax amount, the invoice hash, the signature, and the public key. A simplified example of the structure of a single field in TLV encoding:

Tag    Length   Value
0x01   0x0B     "Qoyod Store"        (seller name)
0x02   0x0F     "300000000000003"    (VAT number)
0x03   0x14     "2026-06-24T12:41:00Z" (timestamp)
0x04   0x06     "115.00"             (invoice total)
0x05   0x05     "15.00"              (VAT total)

This encoding is what allows the Authority’s app to read the invoice and verify it by scanning the code directly on the receipt, without any connection to the seller’s system.

Next section heading: anatomy of a compliant POS receipt

Step-by-step transaction flow inside the device

To understand the integration from a technical perspective, here is the sequence of what happens inside the device from the moment the payment button is pressed until the receipt is handed over:

1. The seller closes the cart and selects the payment method, so the request is sent to the issuance unit in the device.
2. The unit builds the invoice document in UBL 2.1 format and populates the line items, tax, and total.
3. The unit computes the invoice hash value and links it to the PIH value of the previous invoice.
4. The unit signs the invoice with its private key, producing the cryptographic stamp.
5. The unit generates the QR code in TLV then Base64 encoding.
6. The receipt is printed and handed to the customer instantly, so the transaction is complete from the customer’s perspective.
7. A copy of the invoice (XML) is placed in the local reporting queue.
8. The system sends the invoice to the Fatoora platform in the background within the 24-hour window and receives the acknowledgement.

Steps one through six are instant on the device and are unaffected by network status. Steps seven and eight are asynchronous, running in the background without disrupting the sale. This separation between issuance and reporting is the essence of a successful POS design.

The reporting request itself is a simple API call to the Fatoora platform. Its logical form, as an illustrative example:

POST /invoices/reporting/single
Content-Type: application/json

{
  "invoiceHash": "NWZ...base64...",
  "uuid": "3cf5ee18-ee25-44ea-a444-2c37ba7f28be",
  "invoice": "PD94bWwg...UBL-as-base64..."
}

Response 200 OK
{
  "reportingStatus": "REPORTED",
  "validationResults": { "status": "PASS" }
}

Handling internet outages at the point of sale

The most common technical question about the point of sale: what happens if the internet drops during a sale? The answer lies in the nature of the simplified invoice itself. Since issuance is local and does not wait for the Authority’s approval, a network outage does not stop the sale.

The device keeps issuing, printing, and handing invoices to customers normally. Each invoice is stored locally in the reporting queue. When the connection returns, the system sends the accumulated invoices to the Fatoora platform in batches, as long as they are within the permitted 24-hour window.

The Qoyod point of sale system supports offline operation, so the cashier keeps working during an outage. This capability is essential for establishments such as fuel stations and markets that cannot afford to stop selling for a moment. When the connection is restored, the reporting cycle for the pending invoices is completed automatically.

Speed at payment: why the integration does not slow the cashier

The legitimate concern in retail is that invoicing requirements will slow down the payment queue. A sound design eliminates this concern for two reasons.

The first is that all the heavy operations are local. Generating the UUID, computing the hash, the cryptographic signature, and building the QR code all happen on the device in fractions of a second. There is no waiting for a response from an external server before the receipt is printed.

The second is that reporting is asynchronous. The invoice goes into the queue and is sent in the background, while the cashier moves on to the next customer immediately. Selling speed is not tied to network speed nor to the Fatoora platform’s response time.

When designing a POS integration, hold to these two principles: keep signing and printing local, and make reporting a background process independent of the sales path. Any design that ties receipt printing to the Authority’s response will create queues and expose the establishment to a halt in selling at the first network fluctuation.

This design explains why large retail establishments choose the reporting model with confidence. A store with a high sales rate needs a device that prints the receipt in under a second, no matter the pressure of peak hours. When signing and QR-code building are local, the invoice issuance time stays constant, unaffected by the number of customers in the queue or the network status. This performance stability is what makes technical compliance invisible to both the customer and the cashier.

And the 24-hour window is generous enough to absorb long network failures. Even if the connection drops for hours, the system still has ample room to send all the accumulated invoices before the deadline expires. This time margin protects the establishment from a violation under real-world operating conditions.

Managing multiple devices and branches in a single establishment

Retail establishments rarely operate with a single register. A mid-sized store may contain several registers in one branch, and a chain may contain dozens of branches. Each register is an independent EGS unit, so how is this system managed technically?

The rule is that each device maintains its own invoice chain. The ICV counter increments within each unit separately, and the PIH value links each invoice to the one before it within the same device, not across devices. This means the hash chain does not break even if two registers operate at the same time.

The Qoyod point of sale system manages multiple branches and multiple devices from a single central dashboard. Every unit is registered, its certificate is managed, and its reporting status is tracked. Sales data flows from each device to the accounts in the background, so it appears unified in the establishment’s financial statements, while each unit remains technically independent in issuance.

Next section heading: structure of a multi-device establishment

Common mistakes in POS integration

From the reality of implementing Phase Two in retail, specific technical mistakes recur. Avoiding them saves violations and later audits:

• Tying receipt printing to the Fatoora platform’s response, so selling stops at any network fluctuation. The correct approach is to separate reporting from issuance.
• Sharing a single certificate across more than one device. Every EGS unit needs its own certificate, without exception.
• Neglecting the 24-hour window and deferring reporting without follow-up, so invoices exceed the deadline and turn into a violation.
• Generating a QR code with missing elements or the wrong encoding, so verification fails when it is scanned with the Authority’s app.
• Breaking the PIH chain when replacing or re-configuring a device without a proper migration of the last value.

With the Qoyod system these details are managed automatically: the separation between issuance and reporting is built in, each device gets its own certificate, the queue tracks the 24-hour window, and the QR code is built to the full specification. Your operational role remains issuing the sale, and the system handles the technical compliance.

How Qoyod handles POS integration

Qoyod combines an accounting system, e-invoicing software, and a point of sale system in a single platform. This internal integration removes the need to connect three separate systems:

• The point of sale system issues the simplified invoice with a compliant QR code at the moment of payment.
• The e-invoicing software manages each device’s certificate (CSID) and its automatic renewal.
• The system reports every invoice to the Fatoora platform within the 24-hour window without manual intervention.
• The cashier works offline and completes reporting when the connection returns.
• Sales data flows from each device to the accounts and financial statements directly.

The result is that the store owner sells as usual, while technical compliance runs in the background. There is no need to write XML manually, nor to manage certificates, nor to follow up on each invoice individually. All of that is built into the platform.

To review the neighbouring scenarios, see the Reporting guide, which explains the simplified-invoice path in greater detail in the Reporting guide, and the technical certificate guide in the Compliance CSID certificate guide.

Credit notes and returns at the point of sale

Returns are a daily part of retail work. A customer returns a product, so the cashier needs to issue a document that reduces the value of the original sale. This document is not a new invoice, but a credit note linked to the original invoice.

The credit note at the point of sale follows the same technical path as the simplified invoice. It carries its own document type, references the original invoice number and its reason, is signed, stamped, and carries a QR code, then is reported to the Fatoora platform within the 24-hour window. The essential difference is that its value reduces the tax due rather than increasing it.

There is also the debit note, issued when the transaction value increases after the original invoice was issued. Both notes fall under Phase Two with the same technical elements. The following table summarizes the difference:

The Qoyod system automatically links each credit note to its original invoice, preserving the document chain and the accuracy of the tax return. There is no need to rebuild the link manually, since the cashier selects the original invoice and creates the note directly from it.

Integration with payment devices and peripherals

A POS device does not work alone, but within an ecosystem of peripherals: the barcode reader, the thermal printer, the cash drawer, and sometimes the payment terminal. Proper integration connects these peripherals to the issuance path without slowing it down.

The Qoyod point of sale system automatically recognizes connected barcode readers, printers, and cash drawers. This automatic recognition reduces setup steps and prevents manual connection errors. When a product is scanned, its line items are added directly to the cart, so the invoice document is built from real data rather than error-prone manual entry.

The important separation here is that the bank payment device and the e-invoicing cycle are two separate paths. Collecting the amount from the customer’s card happens through the bank payment device, while issuing the compliant invoice happens in the issuance unit. A sound system completes the invoice the moment payment is confirmed, so it does not issue an invoice for a transaction that did not complete, nor collect an amount without an invoice.

Key security and protection of issuance data

Signing the invoice relies on the unit’s private key. This key is what proves the invoice was issued by an approved device, and any leak of it threatens the integrity of the invoice chain. That is why private keys are kept in secure storage inside the system, are not transferred between devices, and are not shared outside the unit.

The public key, by contrast, is embedded in the QR code and made available for public verification. Any party who scans the code can verify that the signature is correct using the public key, without ever reaching the private key. This separation between the two keys is the foundation of the asymmetric cryptography on which Phase Two is built.

The hash value using the SHA-256 algorithm guarantees that any modification to the invoice data after it is signed is detected instantly, because any small change in the data alters the hash value entirely. And linking each invoice to the hash of its predecessor via PIH builds a chain from which no link can be deleted or modified without breaking the whole chain.

The Qoyod system manages this entire security layer: it stores the keys securely, generates the hash to the specification, and preserves the invoice chain for each device. Your establishment stays compliant without dealing directly with the complexity of the cryptographic infrastructure.

Integration testing and readiness verification

Before launching a point of sale in production, the unit goes through compliance checks on samples of invoices and notes. These checks verify that the invoices are built according to the correct UBL 2.1 schema, that the mandatory elements are complete, and that the signature and QR code pass verification.

A sound practice before launch is to verify specific items. Make sure the QR code is read successfully by the Authority’s app, that the date and time stamp is in the correct UTC format, that the tax number matches the establishment’s registration, and that the ICV counter increments without jumps or repetition. Any flaw in these items is caught in the test environment far more cheaply than discovering it after thousands of invoices in production.

For a broader readiness checklist covering the regulatory and technical aspects, see onboarding and connection to the Fatoora platform guide. With Qoyod, compliance checks are run for each device within the automatic onboarding cycle, so you do not need to build a manual test environment.

Frequently asked technical questions about POS integration

Does every point of sale need a separate certificate? Yes. Each device is an independent EGS unit with its own CSID certificate. Two devices may not share a single certificate, even within the same branch.

What if an invoice exceeds the 24-hour window without being reported? The delay turns into a potential violation. That is why the system continuously monitors the queue and sends the pending invoices as soon as a connection is available, before the deadline expires.

Is handling restaurants different from retail stores? The technical principle is the same: a simplified invoice with a reporting model and a QR code. The interface, table management, and kitchen differ, and these are what the restaurant POS system adds on top of this foundation, without changing the e-invoicing logic.

Do I need to write code to build the QR code or the signature? No, when using Qoyod. These operations are built into the platform. The code examples in this guide are for technical understanding only, not for manual implementation.