When your business sells to another business, you don’t issue the same invoice you’d issue to an individual customer. The business-to-business (B2B) invoice in Phase Two of e-invoicing has a specific type, additional mandatory fields, and a different approval path before it reaches the buyer. At the XML document level, these differences aren’t a formality — they are what determines whether the FATOORA platform accepts or rejects the invoice.
This technical guide is aimed at developers and technical accountants who want to understand the business-to-business (B2B) tax invoice from the inside: what its type code is, which fields become mandatory here and aren’t in an individual’s invoice, and how it passes through real-time Clearance before delivery. We focus here on the invoice type and its structure only. The Clearance process step by step has its own dedicated guide, which we reference in place. This guide is part of the technical documentation series for e-invoicing.
builds Qoyod’s e-invoicing software a B2B invoice with all its mandatory fields automatically, so you never have to write XML by hand. But understanding what sets this type apart helps you read the generated invoice, interpret validation messages, and make sure the buyer’s data is complete before sending.
What is a B2B invoice between businesses?
A B2B invoice is the Standard Tax Invoice that a VAT-registered business issues to another VAT-registered business. The Zakat, Tax and Customs Authority (ZATCA) calls it the “Tax Invoice,” as opposed to the “Simplified Tax Invoice” aimed at individuals.
The core difference isn’t the amount or the sector, but the identity of the buyer. If the buyer is a business with a tax registration number that wants to deduct input tax, the invoice is B2B. If the buyer is an end consumer who doesn’t deduct tax, the invoice is a simplified B2C invoice. This distinction drives everything that follows: the type code, the mandatory fields, and the approval path.
At the document level, a B2B invoice follows the same UBL 2.1 standard that every invoice follows, and it splits into the same three major sections: the header, the lines, and the totals. To read this general structure in detail, see the e-invoice structureguide. What sets B2B apart is what gets filled in within this structure, not the structure itself.
This distinction is practical before it is theoretical. A business that sells both wholesale and retail will issue both types on the same day: a standard invoice for every merchant customer, and a simplified invoice for every individual customer. The accounting system decides the type the moment you select the customer, and from that moment the contract of mandatory fields and the approval path change entirely. Understanding this shift explains why the two invoices look identical on paper while differing fundamentally inside the XML.
In this guide we cover three aspects that set a B2B invoice apart from an individual’s invoice: the type code that declares its identity, the mandatory fields that appear in the buyer section, and the real-time Clearance path it takes before delivery. Then we bring them together in a complete document example, and close with the most common structural errors in this type.
Comparing a B2B invoice with a B2C invoice at the document level
| Criterion | Standard B2B | Simplified B2C |
|---|---|---|
| Subtype | 01 | 02 |
| Buyer’s tax number | Mandatory | Not required |
| Buyer’s address | Mandatory | Not required |
| Compliance path | Clearance before delivery | Reporting within 24 hours |
Type code: how does the system know it’s a B2B invoice?
Every distinction starts from a single field in the header named InvoiceTypeCode. This field carries a number that tells the FATOORA platform the document type before it reads anything else. The value 388 means “tax invoice” under the UBL standard, while the distinction between standard and simplified comes from a sub-attribute named name which carries a string of seven digits.
In a standard B2B invoice, this string starts with the digit 01. In a simplified B2C invoice it starts with the digit 02. These two digits are the first signal in the document that determines the full path the invoice will take.
The seven-digit string is not random. Each position in it is a flag that describes a property of the invoice: the first two positions determine the type (standard or simplified), and the following positions indicate special cases such as export, the medical sector, or an invoice summary. But what matters for distinguishing B2B from B2C is the first two digits: 01 versus 02.
If the system sets 01 on an invoice addressed to an individual with no tax number, or sets 02 on an invoice addressed to a registered business, validation conflicts will appear because the mandatory fields for each type differ. The code isn’t just a classification — it’s a contract the rest of the document must honor.
The remaining five positions in the string describe supplementary cases that don’t change the invoice being B2B, but do govern how it’s processed. The third position raises the export invoice flag, the fourth the medical sector flag, the fifth the travel invoice flag, the sixth the invoice summary flag, and the seventh the postal system cases flag. In an ordinary standard invoice these positions stay zeros, so the string reads 0100000. Changing any of them imposes additional fields, which is why the accounting system sets them based on the transaction type and not on the user’s judgment.
The lesson here is that the type code is not a single value but a miniature structure in its own right. The first two positions settle that it’s B2B, and the rest describe its circumstances. Any sound invoice editor builds this string automatically, because writing it by hand is a direct gateway to structural errors.
Mandatory fields: what does a B2B invoice add?
The most important thing that sets a B2B invoice apart from an individual’s invoice is that it requires complete data about the buyer. In a simplified invoice, the seller’s name and details are enough; in a tax invoice, the buyer is a fully identified party because they will use the invoice to deduct their input tax.
The additional mandatory fields in B2B fall into two groups: the buyer’s tax number, and the buyer’s full national address. The absence of either one makes the invoice rejected at Clearance.
These fields all live inside a single element in the header named AccountingCustomerParty. In an individual’s invoice this element may be nearly empty or absent, whereas in a B2B invoice it is a fully populated element. The shift from “anonymous buyer” to “fully identified buyer” is the clearest structural difference between the two types, and it shows immediately to anyone reading the two documents side by side.
1. The buyer’s tax number
The buyer’s tax number is mandatory in a B2B invoice and not required in an individual’s invoice. It is written inside the buyer section AccountingCustomerParty in the tax identification element, and consists of fifteen digits that start and end with the digit 3.
The FATOORA platform validates the format of this number: fifteen positions, starting with 3 and ending with 3, with the tenth position 1 denoting the business’s main branch. If the number is incomplete or in the wrong format, the invoice is rejected before Clearance.
2. The buyer’s national address
In addition to the tax number, a B2B invoice requires the buyer’s full national address per the Saudi National Address system. This address is optional in an individual’s invoice but mandatory here, and it consists of several sub-fields that must all be complete together.
The building number is four digits, the postal code is five digits, and the country code SA is two letters per the ISO standard. A missing building number or postal code is a common structural error that stops the invoice. Note that these fields live inside the header section. To understand the rest of the header fields and their order, see the invoice header in XML.
The additional mandatory fields in the buyer section of a B2B invoice
Buyer’s tax number (CompanyID, 15 digits)
Name of the buying business
Full national address (PostalAddress)
Tax scheme PartyTaxScheme
The seller section: what stays constant?
In contrast to the buyer section, which expands in a B2B invoice, the seller section AccountingSupplierParty stays constant across both types. The seller is always a registered business, so its tax number and national address are required in every e-invoice regardless of type. What changes is the counterparty: in B2C, identifying the seller is enough; in B2B, both parties must be identified.
This symmetry in the seller section is useful in practice: the data you record once about your business is used in all your invoices. The data that changes from one invoice to another is the buyer’s data — and that is exactly what turns an invoice into a B2B type. That’s why quality control for B2B invoices focuses on the completeness of the buyer section, not the seller section.
Credit and debit notes in the B2B context
B2B transactions aren’t limited to invoices. When goods are returned or an amount is corrected, the business issues a Credit Note or a Debit Note. These documents carry a different type code: 381 for the credit note and383 for the debit note, but they inherit the same mandatory fields as the B2B invoice if the buyer is a business.
The note adds a field to reference the original invoice it corrects inside BillingReference, so the system knows which invoice it is amending. A credit or debit note in a B2B transaction also passes through real-time Clearance, exactly like the original invoice, because it concerns a business that will adjust its input tax deduction.
Real-time Clearance: why doesn’t a B2B invoice reach the buyer directly?
The third and deepest difference between B2B and B2C is the approval path. A simplified individual’s invoice is delivered to the buyer immediately, then reported to the Authority within twenty-four hours (the Reporting path). A standard B2B invoice, on the other hand, may not be delivered to the buyer until it passes through real-time Clearance and is approved by the FATOORA platform in real time.
This means the business does not issue a final B2B invoice by itself. It sends the document to the platform, which validates its structure, fields, and stamp, then returns it stamped with its approval. Only the approved invoice is the legal invoice delivered to the buyer. This is what makes Clearance an integral part of the definition of a B2B invoice.
Here the Compliance Cryptographic Stamp Identifier (known in short as CSID) comes in. This identifier is a cryptographic certificate issued by the Authority to the business, used to sign the invoice before sending it for Clearance. A B2B signature is validated at the platform level in real time, unlike a B2C signature which is validated at Reporting.
The impact of Clearance on the structure isn’t limited to the stamp. The platform verifies the consistency of the B2B invoice’s mandatory fields before approving it: the type code matching the presence of a buyer tax number, the completeness of the national address, and the correctness of the tax calculation in the totals section. Any flaw in these fields returns the document with a rejection message, so no stamp is issued and the invoice never reaches the buyer. That’s why the mandatory fields and Clearance are two sides of one coin: the first is a condition for the success of the second.
In terms of timing, the difference is tangible to the user. An individual’s invoice appears printed in seconds because Reporting happens after delivery. A B2B invoice, however, waits for the platform’s response before its final stamped copy is displayed. This real-time wait isn’t a flaw; it is what guarantees that the invoice the buyer receives is officially approved and valid for their input tax deduction with no later dispute.
We focus here on the effect of Clearance on the invoice type and its structure only. The full Clearance steps, from sending to the stamped response, are explained in the Clearance in e-invoicing.
The full path: from selecting the customer to delivery
Let’s bring the three aspects together into a single sequential picture. Everything starts from the moment you select the customer, and from there two entirely different paths branch off. This sequence is the essence of the distinction between B2B and B2C, and it deserves to be read step by step.
When you select a registered-business customer, the system sets the type to B2B and opens the mandatory buyer fields. It requires the tax number and the national address, and does not allow the invoice to be issued before they are complete. After filling in the lines and calculating the tax, the system builds the XML document with the type code 01, then signs it with the CSID stamp identifier. Up to this moment the invoice is a technical draft; it has not yet become legal.
The draft is sent to the FATOORA platform for real-time Clearance. The platform verifies the fields, stamp, and totals in real time, and either responds with a rejection carrying the reason for the error, or approves the invoice and returns it stamped with an approved QR code. Only the returned stamped invoice is legal, and only then is it delivered to the buyer, who uses it to deduct input tax.
Compare this with the individual’s invoice path: the system builds a document with the type code 02 with no buyer tax number, and prints it immediately with a QR code, so the customer receives it at once. Then the Authority is notified of it within twenty-four hours in a batch. No waiting for a response, no prior approval. Both paths start from the same system but end with entirely different logics: approval before delivery in B2B, and reporting after delivery in B2C.
A complete example: reading a B2B invoice from top to bottom
Let’s bring the above together into a single concise document. The following invoice is a standard B2B invoice: note the type code that starts with 01, the buyer section that carries a tax number and a full address, and a structure that will not be delivered to the buyer until it returns stamped from Clearance.
Read the document from the top: the type code tells you it’s a standard B2B invoice, then comes the seller, then the buyer with all their mandatory data, then the lines, then the totals. This order is what the FATOORA platform expects, and any disorder in it or missing mandatory field stops Clearance immediately.
Common structural errors in B2B invoices
Most cases of B2B invoice rejection come back to an error in the fields that set it apart from an individual’s invoice. These are the most common errors and how to read them:
- Missing buyer tax number: the system issued an invoice with type
01without aCompanyIDfor the buyer. The fix is to fill in the tax number before sending. - Incomplete buyer address: the building number or postal code is missing inside
PostalAddress. These fields are mandatory in B2B even if they are optional elsewhere. - Type code doesn’t match the buyer: was set
02for a registered-business buyer, so a conflict appeared between the type and the attached fields. - Wrong tax number format: the number doesn’t start with
3or doesn’t end with it, or its length isn’t fifteen digits.
Note that all these errors are concentrated in the buyer section, which is exactly the section that sets a B2B invoice apart. An invoice is rarely rejected because of the seller section, since its data is pre-recorded and constant. The buyer’s data, however, changes with every customer, and that’s where the error usually occurs. Quality control for B2B invoices therefore starts with quality control of business-customer data in the system before issuing any invoice.
The governing rule: the type code, the mandatory fields, and their data contract must all be consistent. An invoice that declares itself B2B must carry complete buyer data, otherwise Clearance rejects it before it reaches the buyer at all.
How Qoyod handles a B2B invoice on your behalf
distinguishes Qoyod the invoice type automatically based on the customer you select. If the customer is a VAT-registered business, Qoyod generates a standard B2B invoice with all its mandatory fields and routes it to the real-time Clearance path. You get this without writing a single line of XML:
- Automatic type determination: Qoyod sets the type code
01and builds the correctInvoiceTypeCodestring based on the buyer’s data. - Capturing the mandatory buyer data: Qoyod requires the tax number and the national address when adding the customer, so no B2B invoice is issued with missing fields.
- Signing and Clearance: Qoyod signs the invoice with the CSID stamp identifier and sends it to the FATOORA platform for real-time Clearance, then returns it stamped and ready for delivery.
- Reading validation messages: if the platform responds with a warning or rejection, Qoyod shows the reason for the rejection in plain language instead of the raw error code.
Issue Clearance-compliant B2B invoices without writing XML
Qoyod determines your invoice type automatically, fills in the mandatory buyer fields, signs it with the stamp identifier, and passes it through real-time Clearance, ready for delivery.
Why does understanding this distinction matter to you?
Even if you don’t write XML yourself, understanding what sets a B2B invoice apart makes you better able to control your data. You’ll know why the system asks for the tax number and the address when adding a business customer, why a B2B invoice is delayed for a moment before delivery while an individual’s invoice comes out immediately, and how to read a rejection message pointing to a missing buyer field.
This understanding turns validation messages from obscure codes into clear indicators. And when you connect your business with another party via a software integration, you’ll know which fields your system must send so that Clearance succeeds on the first attempt.
The technical difference has a direct impact on those who build software integrations. If your system sends invoice data to an invoicing engine, it must distinguish between the two customer types at preparation: for a business customer it attaches the tax number and the full national address and sets the type code to 01, and for an individual customer it makes do with the basic data and sets the code to 02. Mixing data between the two types is the most common cause of Clearance failure in integration environments, because the platform rejects the conflict between the code and the attached fields.
This understanding also helps you audit your incoming invoices. When you receive a B2B invoice from a supplier, you can make sure it carries your correct tax number and address, because an error in these two fields could put your input tax deduction at risk of rejection during review. A structurally correct invoice protects both parties to the transaction, not the seller alone.
The journey of a B2B invoice from creation to delivery
Entering the invoice and buyer data
Generating XML and signing with CSID
Clearance via the FATOORA platform
Delivering the approved invoice
A quick checklist for a sound B2B invoice
Before sending any invoice addressed to a business, make sure the elements that set it apart from an individual’s invoice are complete. This checklist summarizes the above into reviewable steps:
- Type code: a
InvoiceTypeCodestring starting with01and a value of388for the invoice, or381and383for the notes. - Buyer’s tax number: present inside
CompanyID, fifteen digits, starting with3and ending with it. - Buyer’s national address: building number, city, postal code, and country code
SAcomplete insidePostalAddress. - Signature: the invoice is signed with the CSID stamp identifier before sending.
- Path: the invoice is routed to the real-time Clearance path, not Reporting.
Completing these five items means a B2B invoice ready for Clearance on the first attempt. A sound accounting system applies this checklist automatically, but knowing it makes you able to interpret any rejection if it occurs.
Frequently asked questions
What is the core difference between a B2B invoice and a B2C invoice in the document?
Three differences: the type code (a string starting with 01 for standard B2B versus 02 for simplified B2C), the mandatory fields (the buyer’s tax number and national address are mandatory in B2B), and the approval path (real-time Clearance in B2B versus Reporting within 24 hours in B2C). The general structure of the three sections is the same in both types.
Why is the buyer’s tax number required in a B2B invoice specifically?
Because the buyer is a registered business that will use the invoice to deduct its input tax. The invoice must therefore fully identify it by its tax number and address. In an individual’s invoice this isn’t needed because the end consumer doesn’t deduct tax.
What is the correct type code for a B2B invoice?
The value of InvoiceTypeCode is 388 (tax invoice), and the name attribute is a seven-digit string starting with 01 for a standard B2B invoice. The number 02 is reserved for the simplified B2C invoice.
Why doesn’t a B2B invoice reach the buyer directly?
Because it is subject to real-time Clearance: it is first sent to the FATOORA platform, which validates it and stamps it in real time, and it does not become legal and deliverable until it returns stamped. The details of the process are in the Clearance.
What is the CSID stamp identifier and what is its role in a B2B invoice?
The Compliance Cryptographic Stamp Identifier (CSID) is a cryptographic certificate issued by the Authority to the business and used to sign the invoice before sending it for Clearance. A B2B invoice’s signature is validated at the platform level in real time.
Do I need to write XML myself to issue a B2B invoice?
No. Qoyod builds a B2B invoice with all its mandatory fields automatically based on the customer’s data, signs it, and passes it through Clearance, so you enter the data via a simple interface and Qoyod generates the compliant document.
