In a regular invoice, the seller issues their own invoice for a good they sold or a service they provided. But Saudi Arabia’s e-invoicing system permits the exact opposite case: the buyer issues the tax invoice on the seller’s behalf. This pattern is called Self-Billing, in which the buyer takes on building the document, signing it, and submitting it for clearance in the seller’s name, based on a written agreement previously concluded between them. At the XML level, this case has a dedicated flag in the type code, an agreement that governs it, and a distribution of responsibility that differs from the regular invoice.
This technical guide is aimed at developers and technical accountants who want to understand Self-Billing from the inside: when the buyer is entitled to issue the invoice, how the self-billing flag is raised inside the name attribute of the InvoiceTypeCodefield, who holds the CSID stamp identifier and signs, and how legal responsibility is distributed between the seller and the issuing buyer. This guide is part of the e-invoicing technical documentation.
series. Qoyod’s e-invoicing software builds the invoice with all its mandatory fields automatically, so you never have to write XML by hand. But understanding when the self-billing flag is raised, and who bears the signing and submission obligation, helps you set the agreement with your supplier correctly, and read the generated invoice accurately before approving it.
The essential difference from a regular invoice is not in the invoice content, but in the identity of its issuer. The supply is the seller’s supply, and the invoice is legally the seller’s invoice, but the one who built it, signed it, and sent it is the buyer. The system therefore needs a signal saying that the issuer of this document is the buyer, not the seller. This signal is the self-billing flag, and it is what distinguishes this type inside the XML.
It is important not to confuse self-billing with third-party billing. In self-billing, the buyer issues the invoice, meaning its issuer is a party inside the sale transaction itself. But in Third Party Billing the issuer is a party entirely outside the transaction: neither a seller nor a buyer, but an operating agent or an invoicing platform. This distinction drives a difference in which position is raised in the type code, and a difference in who bears responsibility.
In this guide we cover five axes that distinguish self-billing: the self-billing flag in the type code, the agreement that governs the relationship, who holds the CSID stamp identifier and signs, how responsibility is distributed between the seller and the buyer, and the practical difference from third-party billing. We then bring them together in a sample document, and close with the structural errors most frequently seen in this pattern.
The self-billing flag: how does the system know the issuer is a buyer?
Distinguishing this type begins from the very field that distinguishes every invoice: InvoiceTypeCode in the header. The value 388 means “tax invoice” under the UBL standard, and the name attribute carries a string of seven digits, each position of which is a flag describing a trait of the invoice. The first two positions determine the type: 01 a standard invoice addressed to an enterprise, and02 a simplified invoice addressed to an individual. The flags for special cases come in the following five positions.
The self-billing flag lives in the seventh (last) position of the string. When the buyer issues the invoice on the seller’s behalf, this position is raised from 0 to 1. So a regular standard invoice reads its string as 0100000, while a standard invoice issued by the buyer via self-billing reads 0100001. The seventh digit is the only visible difference in the flag, but it completely changes the meaning of the document for the system.
The order of the seven positions is fixed and defined in the Authority’s standard. The first and second positions are for the type, then the third position is for the third-party flag, the fourth for the nominal invoice (Nominal), the fifth for export, the sixth for the summary invoice (Summary), and the seventh for the self-billing flag. That is why the position of the self-billing flag (the seventh position) differs from the position of the third-party flag (the third position), even though both describe someone issuing the invoice in place of the seller.
This flag does not change whether the invoice is standard or simplified. An enterprise buyer can issue a standard self-billed invoice for its purchases, so the string reads 0100001, or a simplified self-billed invoice, so it reads 0200001. The first two positions keep describing the type, and the seventh position alone declares that the issuer is a buyer issuing on behalf of its supplier.
The lesson here is that the self-billing flag is a complementary trait added on top of the invoice type, not an independent type in its own right. The system reads the full string: the type first, then the special flags. Raising the seventh position tells the system to expect a signature from the buyer’s certificate, and to link the invoice to an existing self-billing agreement, rather than treat it as an invoice the seller issued themselves.
Writing this string by hand is a direct gateway to errors, because a single wrong position flips the meaning of the document. If the third position were raised instead of the seventh, the system would declare a third party, not self-billing. Any sound invoice editor builds the flag automatically based on the account configuration: if the account is set up as a buyer issuing self-billed invoices on behalf of a supplier, the system raises the seventh position without any user intervention.
Positions 1–2: invoice type (standard/simplified)
Position 3: third-party billing
Position 7: self-billing (the buyer issues)
0100000 regular ← 0100001 self-billing
The prior agreement: a precondition, not a later step
A buyer may not issue an invoice in the seller’s name merely because they wish to. The legal basis for self-billing is a written agreement between the seller and the buyer that explicitly states the buyer is authorized to create tax invoices for its purchases from this seller, sign them, and submit them for clearance on the seller’s behalf. This agreement is a precondition for raising the flag, not a later step completed after issuance.
The Authority requires several essential elements in this arrangement. Both the seller and the buyer must be registered for VAT, the agreement must define the scope of supplies covered by self-billing, and the seller must acknowledge that they will not issue invoices for the same supplies so that the invoice for a single transaction is not duplicated. This mutual acknowledgment is what prevents invoice duplication between the two parties.
At the document level, the agreement does not appear as text inside the XML, but its effect shows in two places: the self-billing flag raised in the type code, and the identity of the certificate the invoice was signed with. The system does not require attaching the agreement with every invoice, but it expects that the seller has in fact authorized the buyer, and that the signing certificate is registered to the issuing buyer, not to the seller.
This means that setting up self-billing begins outside the moment of issuance. Before the first self-billed invoice is issued, the agreement must be in place, the buyer must have obtained their own stamp certificate from the Authority, and their system must be configured to link this supplier’s invoices to their account as a self-issuer. This upfront configuration is what makes the flag truthful when it is raised.
Who holds the CSID stamp identifier and signs?
The CSID stamp identifier is an encryption certificate issued by the Authority to each entity individually after registering it on the Fatoora platform. In self-billing, the buyer is the one who builds the invoice and signs it, so they sign with their own certificate, not the seller’s. The certificate proves to the system that the one who built the document and signed it is this specific buyer, and that the raised flag is truthful.
The distinction is practical and important. If the buyer raised the self-billing flag but signed with the seller’s certificate rather than their own, a conflict between the flag and the signature would appear, and the system would reject the document. The flag declares “a buyer self-issued this,” and the signature must prove that the buyer themselves is the one who signed. Consistency of the flag with the certificate is a condition for accepting the invoice.
The seller’s section inside the document does not change despite this. The seller’s tax number and address remain in the AccountingSupplierParty element as if the seller had issued the invoice themselves, because the supply is theirs and the invoice is legally theirs. The buyer remains in the AccountingCustomerParty element as the transaction party. What differs is the certificate the document was signed with and the flag declaring that issuance was done self-billed from the buyer’s side. The seller is the owner of the invoice, and the buyer is its issuer.
This separation between the “owner of the invoice” and “its issuer” is the essence of the pattern. A large factory buying raw materials from dozens of small suppliers may authorize itself to issue the invoices on their behalf, signing them all with its single certificate, while each supplier remains the seller defined in their own invoice. The flag and the certificate together tell the system this arrangement without ambiguity.
The buyer builds the invoice with the seller’s data inside it
Signs with their CSID certificate and raises the position 7 flag
Clearance or reporting via the Fatoora platform
The seller remains the owner of the supply
Distribution of responsibility between the seller and the buyer
The issuing buyer is responsible for the technical side: building the document according to the standard, signing with their correct certificate, raising the self-billing flag in the seventh position, and submitting for clearance on time. If the buyer issues an invoice with a wrong structure or an invalid signature, the operational fault is theirs, even though the legal responsibility for the supply remains with the seller.
The seller remains responsible for the accuracy of the supply data on which the invoice is built: the value, the tax rate, and the description of the good or service. Authorizing the buyer to issue does not exempt the seller from responsibility for the accuracy of what their invoice contains, because it is legally their invoice. The agreement therefore usually stipulates a mechanism by which the seller reviews the invoices self-issued on their behalf, or objects to them within a defined period.
Corrective transactions likewise handle responsibility with the same logic. When a credit or debit note is issued self-billed, the note inherits the same self-billing flag and the same buyer certificate, and is linked to the original invoice it corrects. The seller remains responsible for the accuracy of the correction, and the buyer for its sound technical issuance. This consistency between the invoice and its corrective notes is a condition for the system accepting them together.
This distribution makes self-billing an arrangement that requires trust and discipline between the two parties. The seller cedes part of their control over issuing their invoices to the buyer, and the buyer bears the burden of building the document soundly. That is why this pattern spreads more in stable, long-term supply relationships, where the buyer is a large, organized party and the suppliers are small, recurring parties.
Let the system build the self-billing flag on your behalf
Qoyod builds the correct InvoiceTypeCode string, signs with your certificate, and submits for clearance automatically, so you never write XML by hand nor err in the flag’s position between the third and seventh positions.
The practical difference from third-party billing
Many developers confuse self-billing with third-party billing, because in both a party other than the seller issues the invoice. But the difference is essential and shows in the flag’s position and who bears it. In self-billing the issuer is the buyer, a party inside the transaction, and the flag is in the seventh position. In third-party billing the issuer is an agent outside the transaction, and the flag is in the third position.
This difference also entails a difference in the certificate. In self-billing the buyer signs with their certificate, being a party defined in the invoice itself within the buyer section. In third-party billing the agent signs with their certificate, being a party that does not appear in the seller and buyer sections at all; their trace appears only in the flag and the signature. This makes reading the two documents different at audit time.
The following table summarizes the three most prominent differences between the two patterns:
| Aspect | Self-Billing | Third Party Billing |
|---|---|---|
| Who issues? | The buyer (a party inside the transaction) | An agent or platform (a party outside the transaction) |
| Flag position | The seventh position (e.g. 0100001) |
The third position (e.g. 0110000) |
| Signing certificate | The issuing buyer’s certificate | The agent’s certificate |
The two flags could theoretically combine in a single invoice if an agent issued a self-billed invoice on behalf of a buyer, so the third and seventh positions would both be raised. But this is a rare and advanced case; the norm is that each case raises its own flag alone. What matters most is knowing that the flag’s position is not a formal detail, but is what determines how the system reads the document and whose signature it expects.
| Criterion | Self-billing | Third party |
|---|---|---|
| Issuing entity | buyer | Agent/external party |
| Flag position | Position 7 (0100001) | Position 3 (0110000) |
| Certificate holder | buyer | The third party |
Self-billing in standard and simplified invoices
The self-billing flag works on top of the invoice type, not instead of it, so it appears in both the standard and simplified types. Each type has a different approval path and timing, and the self-billing flag does not change this path, but adds the issuer trait on top of it.
In the standard invoice addressed to an enterprise, the buyer builds the document by raising the seventh position, so the string reads 0100001. The buyer sends the invoice for immediate clearance before delivering it, so the Fatoora platform verifies the structure, the fields, the signature, and the flag, then returns the invoice stamped with its approval. Only then is the invoice valid, and the buyer delivers it or keeps it in their capacity as its issuer on behalf of the seller.
As for the simplified invoice addressed to an individual, the string reads 0200001, and the buyer delivers it immediately without waiting for clearance, then reports it to the Authority within twenty-four hours. The difference is that the reporter here is the issuing buyer, so they are the one bearing the reporting obligation on time. A delay or omission of reporting falls on the buyer, not the seller, because the buyer is the one who took on issuance.
This means that whoever authorizes themselves to self-bill inherits the full issuance obligations according to the invoice type: immediate clearance in the standard invoice, and reporting within twenty-four hours in the simplified invoice. It is not enough to build the document soundly; they must also comply with the timeline that the type defines, otherwise they are considered to have breached an obligation that would have been the seller’s but for the authorization.
The buyer’s system must therefore be able to differentiate between the two types automatically. If the supplier is a registered enterprise, it builds the invoice as standard and passes it through clearance. And if the transaction is addressed to an individual, it builds the invoice as simplified and reports it later. Mixing the two types raises the wrong position in the first two positions, so the system rejects the document even if the self-billing flag is in its correct position.
When should you choose self-billing?
Self-billing is not a default option for every supply relationship, but an arrangement that suits specific cases. This pattern spreads when the buyer is a large, organized party dealing with many small suppliers, being more capable than them of building invoices soundly and sending them on time. Factories buying raw materials from small farms or workshops are a recurring example of this.
The small seller benefits from this arrangement because it relieves them of the burden of building a compliant invoice and sending it for clearance, especially if they do not have a configured e-invoicing system. And the large buyer benefits because it ensures the invoices coming to it are built in the form that suits its systems, so it does not wait for corrections from suppliers of varying technical capability.
On the other hand, the buyer in this arrangement bears a greater technical and legal burden. They must safeguard their certificate, build every invoice soundly, comply with the clearance or reporting path, and retain the signed agreements with each supplier. Self-billing is therefore not advisable unless the supply volume is large enough to justify this burden, and the buyer is equipped with a system that handles raising the flag, signing, and submission on their behalf.
Sample self-billing document
Let us bring the above together in a single, concise document. The following invoice is a standard invoice self-issued by the buyer: note the self-billing flag raised in the string 0100001, the seller section carrying the original seller’s data not the buyer’s, and the buyer section carrying the data of the entity that built and signed the document.
Read the document from the top: the self-billing flag in the type code tells you the issuer is a buyer, then the seller comes with their original data in the seller section, then the buyer with their data in their section, then the line items, then the totals. On submission, the buyer signs the document with their own certificate, so the system knows the flag is truthful. Any conflict between the flag, the signature, and the parties’ data halts clearance immediately.
The self-billing flag does not change the approval path that the invoice type defines. The standard invoice addressed to an enterprise passes through immediate clearance (Clearance) before delivery whether the seller issued it or the buyer self-billed it. And the simplified invoice is delivered immediately, then reported to the Authority within twenty-four hours. What determines the path is the invoice type, not the identity of its issuer.
The most frequently recurring structural errors
Most rejection cases in this pattern trace back to the flag being inconsistent with the signature or the configuration. These are the most frequent errors and how to read them:
- Flag raised without an agreement: the seventh position was raised without an existing self-billing agreement or without configuring the account, so an invoice appeared declaring a self-billing that has no basis.
- Signing with the seller’s certificate, not the buyer’s: the self-billing flag was raised but the document was signed with the seller’s stamp identifier, so a conflict appeared between the flag and the certificate.
- Flag in the wrong position: the flag was raised in the third position instead of the seventh, so the system read it as a third-party flag rather than self-billing, and the meaning of the document was completely distorted.
- Invoice duplication: the buyer issued a self-billed invoice for the supply, and the seller issued an invoice for the same supply, so a single invoice was duplicated for one transaction.
Note that these errors concentrate in two places: the type-code flag, and the signing certificate. A self-billed invoice is rarely rejected because of the line items or the totals, because these are sections shared with all invoices. But the flag in the seventh position and the certificate belonging to the buyer are what distinguish this pattern, and this is where the error usually occurs. Quality control of self-billing begins with getting the agreement, the buyer’s account configuration, and their certificate right before issuing any invoice.
The governing rule: the flag, the signature, and the agreement must be consistent together. An invoice declaring that a buyer self-issued it must be signed with that buyer’s certificate, must rest on an existing self-billing agreement, and must carry the original seller’s data in the seller section, otherwise clearance rejects it before it reaches the seller.
How Qoyod helps you
The difficulty of self-billing lies in the flag’s position and the certificate, which are precisely what the system handles for you without any manual intervention:
- Automatic type determination: Qoyod builds the correct
InvoiceTypeCodestring according to the invoice type and account configuration, and raises the seventh position on self-billing without you writing the string by hand. - Signing with the correct certificate: the system signs every document with the CSID stamp identifier belonging to your issuing account, ensuring the flag-to-certificate consistency that clearance requires.
- Submission for clearance on time: Qoyod sends the standard invoice for immediate clearance, and reports the simplified one within twenty-four hours, according to the path the invoice type defines.
- Corrective notes: it builds the credit and debit notes with the same self-billing flag and links them to the original invoice, so they stay consistent with it.
The technical difference has a direct impact on those building a software integration. If you are developing a system that issues self-billed invoices for your suppliers, you must raise the flag in the seventh position not the third, sign every document with your own certificate not the seller’s, and place the correct seller data in the seller section and your data in the buyer section. Mixing these elements is the most common cause of clearance failure in this pattern, because the system rejects any conflict between the flag, the signature, and the parties’ data.
For more technical context on the invoice structure and its fields, review the Invoice Header in XML guide, which explains every field in the header with its actual wording, and the B2B invoices between enterprises technically guide, which covers the standard invoice type and its approval path. Self-billing builds on top of these two foundations by raising a single flag in the seventh position, and by changing who signs and submits, while the document structure stays the same.
