The Simplified Tax Invoice (B2C) is the invoice your business issues to the final consumer, i.e. the individual who buys for personal use, not for resale or to deduct input VAT. At the data and XML level, this invoice differs from a B2B invoice in specific elements: the invoice subtype carries the value 02, the buyer’s VAT number is not required, the QR code is mandatory and visible on the receipt, and it is delivered to the buyer immediately then reported afterwards. This guide explains the structure of the simplified invoice from its roots at the field level, shows exactly what distinguishes it from a business invoice, presents real XML snippets, and clarifies how Qoyod’s e-invoicing software generates this structure automatically in line with ZATCA requirements.
This guide is technical and aimed at developers and accountants who work with the invoice structure at the field and tag level. If you are looking for the reporting mechanism itself (the deadlines and time flow), it is explained in detail in the Reporting in e-invoicingguide. Here we focus on the invoice as a type and a data structure.
What is the Simplified Tax Invoice (B2C)?
The Simplified Tax Invoice is a tax document issued by a VAT-registered business when selling to a final consumer. The word “simplified” does not mean it is less important; it means its data is lighter than the standard invoice because the buyer is an individual who does not need the details that would entitle them to deduct input VAT.
This invoice appears in our daily life more than any other document: the coffee-shop receipt, the pharmacy invoice, the fuel-station receipt, the retail-store invoice. They are all B2C simplified tax invoices. The individual takes the receipt and moves on, indifferent to what happens behind the scenes, but your business is obliged to make the structure of that receipt match ZATCA’s specification at the field and signature level.
In the second phase of e-invoicing, the receipt is no longer just a piece of paper. It has become a structured digital document in UBL 2.1 format, carrying a cryptographic signature, a QR code and a unique identifier, and later sent to the Fatoora platform to be reported. The change in structure is radical, even if the receipt shown to the customer stays as simple as it was.
Why does a separate category for individuals exist at all?
ZATCA separated the two tracks because the nature of the two transactions is fundamentally different. When selling to another business (B2B), the buyer needs a fully detailed invoice to deduct input VAT in their return, which is why that invoice passes through Clearance before it reaches them. When selling to an individual, the buyer deducts nothing and files no return, so there is no point in halting the sale to wait for a real-time response from ZATCA.
If real-time Clearance were applied to every single sale in a busy retail store, the checkout queues would stop at every internet outage. That is why ZATCA chose the deferred reporting model for individual invoices: issue the invoice, hand it to the customer immediately, then report it within 24 hours. This separation of the two tracks is the reason a separate subtype exists in the XML structure, which is what we will unpack in the following sections.
If you want a full overview of the remaining types and how they interrelate, see the e-invoice typesguide. The simplified invoice we cover here is one of these types, and the most frequent in the retail sector.
How the individual category differs visually from the business category
| Criterion | Simplified B2C | Standard B2B |
|---|---|---|
| Subtype | 02 | 01 |
| Buyer’s VAT number | Not required | Mandatory |
| QR code | Mandatory and visible | Not mandatory to display |
| Delivery | Immediate, then reported | After Clearance |
The invoice subtype: why the value 02?
Every e-invoice carries a field that defines its type at two levels. The first level is the document type (invoice, credit note, debit note), and the second level is the subtype field that distinguishes a business invoice from an individual invoice. This field is the starting point that determines the entire track.
In ZATCA’s specification, the document type is expressed by a numeric code in the InvoiceTypeCodefield: the value 388 means “tax invoice” according to the UN/CEFACT standard. The distinction between standard and simplified comes from the accompanying name attribute, a string of seven positions. The first position carries 01 for the standard invoice (B2B) and02 for the simplified invoice (B2C).
Here is the segment as it appears in the XML of a simplified invoice:
Here the value 388 is fixed because it is an “invoice,” while the attribute name="0211010" is what carries the classification: the first two positions 02 mean “simplified,” and the remaining positions are numeric flags for cases such as tax exemption, export and rental. For comparison, the standard invoice’s attribute starts with 01 instead of 02. Changing a single position flips the track from Clearance to Reporting.
This field is not cosmetic. The Fatoora platform reads it first to decide whether to hold the invoice for Clearance or receive it for Reporting. A single error in this position means the invoice is rejected or routed to the wrong track.
The buyer’s VAT number: why is it not required here?
The most prominent difference between the B2C and B2B structures is the absence of complete buyer data. In the standard invoice, the AccountingCustomerParty tag must carry the buyer’s VAT number and detailed address, because the buyer is a business that will deduct the tax. In the simplified invoice, however, the buyer is an individual, and their VAT number is not needed at all.
In practice, the buyer-data tag in a B2C invoice is either fully removed or reduced to the bare minimum. This is not a license regarding data; it is a deliberate simplification in the specification. ZATCA does not ask for what is not used.
Compare the two segments. In the standard invoice, the buyer party looks like this:
In the simplified invoice, this tag is either absent entirely or kept as an empty structure with no VAT number and no mandatory business name. This difference alone reduces the invoice size and speeds up its processing at the busy point of sale.
Note one exception: if the individual requests an invoice in their name for a refund or any other purpose, their identifier (such as the national ID number) can be added as an optional field, but that does not turn the invoice into a B2B one. It remains simplified as long as it is for a final consumer.
The QR code: mandatory and carrying the signature
In a B2C invoice, the QR code is not decoration but a mandatory element that must appear on the printed or digital receipt. Any simplified receipt without a valid QR is incomplete from a compliance standpoint. This differs from the standard invoice, where QR is not mandatory with the same strictness because the buyer receives the complete document.
The QR code in the second phase is not merely readable text. It is a field encoded in TLV format (Tag, Length, Value) then encoded in Base64, and it holds eight mandatory fields:
- Seller name.
- Seller’s VAT number.
- Invoice timestamp.
- Invoice total including tax.
- VAT amount.
- Invoice hash.
- Invoice cryptographic signature.
- Seller’s public key.
The last three fields (the hash, the signature and the public key) were added specifically in the second phase. They are what make the QR code automatically verifiable: anyone who scans the code can confirm that the invoice was genuinely issued from an approved system and has not been altered after issuance.
Here is how the field appears inside XML after encoding (the value is shortened for clarity):
The key point is to realize that this field is generated automatically after the invoice is signed, because it contains the signature itself. No accountant can write it by hand. The accounting system is what builds the TLV string, signs it, encodes it and places it in its position.
Dissecting the simplified invoice structure field by field
Header with subtype 02
Seller data (no mandatory buyer)
Sale lines and quantities
Total tax and amount
QR code carrying the cryptographic stamp
The cryptographic elements: signature, UUID and hash
The deeper difference between the first and second phase is not in the shape of the invoice but in the cryptographic layer. A B2C invoice in the second phase carries three cryptographic elements that make it a tamper-proof document:
1. The unique identifier UUID
Every invoice carries a globally unique identifier in UUID format of 36 characters. This identifier differs from the sequential invoice number the customer sees. The UUID is meant for systems, and it guarantees that no two invoices in the world share the same identity. It appears in a standalone tag:
2. The previous invoice hash
Every invoice carries a hash fingerprint of the invoice that preceded it in the same system. This builds a linked chain: if someone tried to delete an invoice from the middle or alter it, the chain would break and the tampering would appear immediately. The first invoice in the chain points to a standard zero hash value.
3. The cryptographic signature and CSID certificate
The cryptographic signature is a digital stamp generated using a certificate approved by ZATCA called the CSID (Compliance Cryptographic Stamp Identifier). This certificate proves that the issuing system is registered and approved. The signature is computed over the invoice content, so any later modification to any field invalidates the signature.
The details of the CSID certificate and how to obtain and renew it are explained in the CSID certificateguide. What matters here is that a B2C invoice is signed with the same certificate, but the post-signature track differs: it is delivered to the customer immediately instead of waiting for a Clearance response.
A precise note on naming: the correct abbreviation is CSID, not CCSI. The mix-up is common, and the full name is Compliance Cryptographic Stamp Identifier. Always write it as CSID to avoid confusion in technical documentation.
The B2C vs. B2B track: where does the XML actually diverge?
Now that we have unpacked the fields, let us bring them together in a direct comparison. The two invoices share most of the structure: the same UBL 2.1 format, the same seller, line-item and totals tags, the same signing mechanism. The difference is concentrated in five places:
- Subtype: B2C’s attribute starts with
02, and B2B’s with01. - Buyer’s VAT number: Mandatory in B2B, not required in B2C.
- QR code: Mandatory and visible on the receipt in B2C, less strict in B2B.
- Platform track: B2B passes through Clearance before delivery, and B2C is delivered immediately then reported.
- Platform submission timing: Real-time for Clearance in B2B, and within 24 hours for Reporting in B2C.
Clearance itself (the track a business invoice follows) is explained in the Clearanceguide. The essential difference is that Clearance happens before the invoice reaches the buyer, whereas Reporting in B2C happens after delivery. This is what makes selling to individuals fast even when connectivity is weak.
Summary of the idea: do not write two separate systems from scratch. Write a single invoice generator that reads the buyer type, then sets the subtype position, decides whether to include full buyer data and routes the invoice to the correct track.
Compliant simplified invoices without writing a single line of XML
Qoyod builds the full structure of the simplified invoice: the subtype, the signature, the QR code and the hash, then reports it to the Fatoora platform within the deadline. All of this happens automatically behind the point of sale.
The B2C invoice lifecycle at the data level
Let us trace the journey of the simplified invoice from the moment “Confirm sale” is pressed to the moment its copy reaches the Fatoora platform. This journey happens in fractions of a second, but it passes through clear data stages:
- Building the structured document: The system creates a UBL 2.1 document with all the tags: seller, line items, quantities, prices, the 15% tax rate and the totals. Here the subtype position is set to
02. - Generating the UUID and hash: The invoice is assigned a unique identifier, its hash is computed and linked to the previous invoice’s hash to complete the chain.
- Signing with the CSID certificate: The cryptographic signature is computed over the invoice content using the private key associated with the certificate.
- Generating the QR code: The TLV string is built from the eight fields including the signature, then encoded in Base64 and placed in the invoice.
- Issuance and immediate delivery: The receipt is printed or sent to the customer digitally at once, without waiting for any response from the platform.
- Reporting within 24 hours: A copy of the signed invoice is sent to the Fatoora platform via an API within the binding deadline.
Notice that steps one through five complete before the customer leaves, while step six may be delayed to under 24 hours. This time separation is the essence of the reporting model, and its timing details are explained in the Reporting.
The 24-hour rule and what it means technically
The Fatoora platform does not wait to approve a B2C invoice before delivery. The invoice is valid and in force from the moment it is issued and handed to the customer. The business’s obligation is to send its copy to the platform within 24 hours of issuance.
Technically, this means your system needs a local queue that keeps the signed invoices and waits for an internet connection to send them. If connectivity drops in the retail store, sales continue without interruption, invoices accumulate in the queue, and are sent in one batch when the connection returns, as long as that is within the deadline.
This design protects the payment experience. The sale of a bottle of water must not stall because the platform is slow to respond. A good accounting system manages this queue automatically, retries on failure, and records the status of each invoice: signed, sent, accepted.
How reporting flows after immediate delivery
Issuance, signing and QR generation
Immediate delivery to the customer
Local reporting queue
Reporting within 24 hours
The line-item and tax-totals structure in the simplified invoice
The heart of any invoice is its line items. In the simplified invoice, each line is represented by an InvoiceLine tag carrying the item description, quantity, unit price and the line value before tax. This part does not differ much from the standard invoice, because a good is a good in both cases. The difference begins at the higher layer: the totals and the tax breakdown.
The simplified invoice carries the TaxTotal tag that aggregates the tax amount, and the LegalMonetaryTotal tag that holds the total before tax, the total including tax and the amount due. The standard 15% tax rate appears in a sub-tag for each taxable line, along with the tax category code. Here is a simplified segment of the totals:
Precision in these figures is an essential condition. The tax amount declared in TaxAmount must match the taxable base multiplied by the rate, otherwise the platform rejects the invoice at reporting time. Likewise, the amount due must match the total including tax. Any difference, even by a single halala due to rounding, is handled according to the rounding rules adopted in the specification.
This is where the value of the accounting system shows. Computing the tax for each line, then aggregating it, then rounding according to the correct rule, is a manual process prone to error. Qoyod computes these values automatically and ensures they match the invoice structure before signing.
Credit note for a simplified invoice: an individual returning a product
What happens when an individual returns a product they bought? The original invoice must not be modified after it is signed, because that breaks the hash chain and invalidates the signature. The correct solution is to issue a credit note linked to the original invoice.
The credit note for the simplified invoice follows the same B2C structure: a subtype starting with 02, a mandatory QR code, a cryptographic signature, and reporting within 24 hours. The only difference is that the document value in InvoiceTypeCode becomes 381 instead of 388 to indicate a “credit note.”
Most importantly, the note must carry a reference to the original invoice via a BillingReference tag that links it to the invoice number. This link builds a clear logical chain: a sale invoice, followed by a credit note that cancels part or all of it. The Fatoora platform tracks this link, so a dangling credit note with no original invoice must not be issued.
Handling returns in the retail sector is daily and recurrent. A system that builds the credit note automatically with the correct subtype and the correct reference saves the accountant considerable trouble and protects the chain from breaking.
Your business’s technical readiness to issue B2C invoices
Before your business issues its first phase-two-compliant simplified invoice, you need to verify the readiness of your technical infrastructure. The essential steps:
- An approved system: Make sure your system generates UBL 2.1 and signs with a CSID certificate. Legacy systems that only print PDFs are not sufficient for the second phase.
- Certificate registration: Register the CSID certificate with ZATCA via the Fatoora platform. This is a one-time step per device or issuance point.
- Testing in the simulation environment: Try issuing invoices in the simulation environment before production, to confirm the structure is accepted without risk to your real data.
- Offline queue management: Verify that your system keeps issuing when the internet drops, and reports later within the deadline.
- Monitoring invoice status: Adopt a dashboard that shows the status of each invoice: signed, in queue, reported, accepted.
This readiness is not a large development project if you choose a system that handles it on your behalf. Qoyod covers these five points out of the box, including the simulation environment and queue management.
Common mistakes when building a B2C invoice
From technical documentation in practice, specific mistakes recur among development teams building a simplified invoice generator for the first time:
- Setting the subtype incorrectly: Placing
01instead of02routes the invoice to the Clearance track, so it gets rejected. Check the first position in the attributename. - Generating the QR before signing: The QR code contains the signature, so it cannot be built before the invoice is signed. The correct order: sign first, then build the TLV.
- Breaking the hash chain: Neglecting to link the invoice to its predecessor’s hash breaks the chain and invalidates verification. Maintain a strict sequence.
- Writing CCSI instead of CSID: A common naming error that confuses documentation. The correct abbreviation is always CSID.
- Missing the reporting deadline: Leaving invoices in the queue for more than 24 hours exposes the business to a violation. Monitor the age of each invoice in the queue.
Each of these mistakes practically disappears when an approved accounting system handles the structure generation instead of building it by hand. This is exactly what Qoyod provides.
How Qoyod handles the full B2C invoice structure
Qoyod builds Qoyod’s e-invoicing software the simplified invoice document per the second-phase specification with no manual intervention. When selling to an individual, the system sets the subtype position to 02 automatically, removes the buyer data that is not required, and builds the tax totals at 15%.
After that, Qoyod handles the entire cryptographic layer: it assigns the UUID, computes the hash and links it into the chain, signs the invoice with the automatically managed CSID certificate, and builds the QR code in TLV format and encodes it. All of this happens behind the point of sale in fractions of a second.
Then Qoyod manages the queue and reporting: it keeps the signed invoices, sends them to the Fatoora platform within the deadline, retries when the connection drops, and records the status of each invoice. Your business sells normally, and compliance runs in the background. Qoyod’s phase-two capabilities are documented on the phase-two compliance.
What Qoyod does not do should also be clear: the initial registration of the CSID certificate with ZATCA is a one-time step the business performs itself, and Qoyod guides you through it. After that, the issuance, signing and reporting cycle becomes fully automatic.
If you want to issue compliant B2C invoices without building the XML generator yourself, start here:
Frequently asked questions about B2C invoices, technically
What value does a B2C invoice carry in the subtype field?
The name attribute in the InvoiceTypeCode tag starts with the two positions 02 to indicate a simplified invoice, while the value of the tag itself stays 388 because it is an “invoice.” The standard business invoice’s attribute starts with 01.
Should I put the buyer’s VAT number on an individual’s invoice?
No, the buyer’s VAT number is not required on the simplified invoice because the individual does not deduct input VAT. An optional identifier such as the ID number can be added when needed, but it does not turn the invoice into a B2B type.
When is a B2C invoice delivered to the customer?
It is delivered immediately at the moment of issuance without waiting for any response from the Fatoora platform. This differs from the standard invoice, which passes through Clearance before delivery. The comparison details are in the Clearance.
How long is the deadline to send a B2C invoice to the platform?
The deadline is 24 hours from the moment of issuance. The invoice remains in force and valid throughout this window, and the obligation is to send its copy to the platform within it. The full details are in the Reporting.
Is the QR code mandatory on an individual’s receipt?
Yes, the QR code is mandatory and must appear on every simplified receipt. In the second phase the code contains the cryptographic signature and the hash value, which makes it automatically verifiable for the authenticity of the invoice.
What is the correct abbreviation for the cryptographic stamp certificate?
The correct abbreviation is CSID, short for Compliance Cryptographic Stamp Identifier. It is sometimes written incorrectly as CCSI. Always adopt CSID in documentation. More details are in the CSID certificate.
