In most invoices the seller issues their own invoice. But Saudi Arabia’s e-invoicing system permits a different case: that a third party issues the invoice on the seller’s behalf. This party is neither the buyer nor the seller, but an agent, a platform, or an invoicing service provider that takes on building the document, signing it, and submitting it for clearance in the seller’s name. At the XML file 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 Third Party Billing from the inside: who the third party is, how its flag is raised inside the name attribute of the InvoiceTypeCodefield, who holds the stamp identifier and signs, and how legal responsibility is distributed between the seller and their agent. 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 third-party flag is raised, and who bears the signing and submission obligation, helps you set the relationship with your agent or platform correctly, and read the generated invoice accurately before approving it.
What is Third Party Billing?
Third Party Billing is an arrangement in which an independent entity issues the tax invoice in the seller’s name and on the seller’s responsibility. The seller remains the legal owner of the supply, and remains the party responsible before the Zakat, Tax and Customs Authority (ZATCA) for the invoice’s validity, but the technical work of building, signing, and submitting is carried out by another party agreed upon with them.
The third party may be an accounting office that manages its clients’ billing, an aggregation platform that issues invoices for dozens of merchants, or a specialized invoicing service provider that connects sellers’ systems to the Fatoora platform. What they have in common is that this party is neither a buyer in the transaction nor the original seller, but an operating intermediary acting on the seller’s behalf under a written agreement.
The essential difference from a regular invoice is not in the invoice content, but in the identity of its technical issuer. The seller’s data stays as it is in the seller section, and the buyer’s data in its section, but the system needs a signal saying that the one who built and signed this document is an agent, not the seller. This signal is the third-party flag, and it is what distinguishes this type inside the XML.
It is important not to confuse Third Party Billing with Self-Billing. In self-billing the buyer issues the invoice for their purchases on the seller’s behalf, meaning the invoice issuer is a party inside the 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. This distinction drives a difference in which flag is raised in the type code, and a difference in who bears legal responsibility.
In this guide we cover four axes that distinguish Third Party Billing: the third-party flag in the type code, the agreement that governs the relationship, who holds the stamp identifier and signs, and how responsibility is distributed. We then bring them together in a sample document, and close with the structural errors most frequently seen in this pattern.
The third-party flag: how does the system know the issuer is an agent?
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 (standard or simplified), while the flags for special cases come in the following positions.
The third-party flag lives in the third position of the string. When an agent 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 through a third party reads 0110000. The third digit is the only visible difference in the flag, but it changes the meaning of the document for the system.
This flag does not change whether the invoice is standard or simplified. A platform can issue a standard invoice to an enterprise buyer through a third party, so the string reads 0110000, or a simplified invoice to an individual through a third party, so it reads 0210000. The first two positions keep describing the type, and the third position alone declares that the issuer is an agent.
The lesson here is that the third-party flag is a supplementary trait added on top of the invoice type, not a standalone type of its own. The system reads the whole string: the type first, then the special flags. Raising the third-party flag tells the system to expect a signature from an agent’s certificate, and to link the invoice to a standing authorization 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. Any sound invoice editor builds the flag automatically based on the account setup: if the account is configured as an agent issuing on a seller’s behalf, the system raises the third position without user intervention.
0100000: regular invoice (the seller issues)
0110000: Third Party Billing
Separate flag: Self-Billing (the buyer issues)
The certificate must match the issuing party
The agreement: what entitles the third party to issue in your name?
No entity may issue an invoice in a seller’s name without authorization. The legal basis for Third Party Billing is a written agreement between the seller and their agent that explicitly states the agent is authorized to build the tax invoices, sign them, and submit them for clearance on the seller’s behalf. This agreement is a precondition for raising the flag, not a later procedure.
The agreement defines the scope of authorization: whether the agent issues all of the seller’s invoices or a category of them, whether the authorization covers credit and debit notes, the term of validity, and the mechanism for terminating the authorization. The seller remains responsible for the validity of the data they supply to the agent, and the agent is responsible for the technical validity of the issuance in line with what they were authorized to do.
At the document level, the agreement does not appear as text inside the XML, but its effect shows in two places: the third-party 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 to every invoice, but it expects that the seller has actually authorized the agent, and that the signing certificate is registered to the agent, not to the seller.
This means that setting up Third Party Billing begins outside the moment of issuance. Before the first invoice is issued, the agreement must be in place, the agent must have obtained their own stamp certificate from the Authority, and the system must be configured to link this seller’s invoices to the agent’s account. This upfront setup is what makes the flag truthful when it is raised.
The stamp identifier and signature: who signs the invoice?
This is the deepest difference between Third Party Billing and the regular invoice. In a regular invoice the seller signs their own invoice with their own Compliance Cryptographic Stamp Identifier (CSID). But in Third Party Billing the signing is done with the agent’s stamp identifier, not the seller’s.
The CSID stamp identifier is a cryptographic certificate the Authority issues to each entity separately after registering it on the Fatoora platform. An agent who issues on behalf of multiple sellers obtains their own certificate, and signs with it every invoice they issue for their clients. The certificate proves to the system that the one who built and signed the document is this specific agent, and that the raised flag is truthful.
The distinction is practical and important. If the agent signed an invoice with the third-party flag raised but with the seller’s certificate rather than their own, a conflict would appear between the flag and the signature, and the system would reject the document. The flag declares “an agent issued this,” and the signature must prove that the agent themselves is the one who signed. Consistency between the flag and the certificate is a condition for accepting the invoice.
The seller section inside the document does not change, however. The seller’s tax number and address stay in the AccountingSupplierParty element as if they issued the invoice themselves, because the supply is their supply and the invoice is legally their invoice. What differs is the certificate the document was signed with and the flag declaring that issuance was done through an agent. The seller owns the invoice, and the agent is its technical issuer.
This separation between the “invoice owner” and its “technical issuer” is the essence of the pattern. An aggregation platform that issues thousands of invoices daily for hundreds of merchants signs them all with its single certificate, while each merchant remains the seller identified in their invoice. The flag and the certificate together tell the system this arrangement without ambiguity.
This arrangement explains why Third Party Billing suits particular business models. Platforms that host many sellers, accounting offices that manage their clients’ books, and solution providers that connect multiple systems to the Fatoora platform all need to issue invoices in others’ names with a single unified certificate. Instead of each enterprise obtaining its own certificate and managing its connection to the platform, the agent takes on this technical burden for everyone, and each seller stays identified in their invoice as if they issued it themselves.
But this unification imposes discipline in linking each invoice to its correct seller. An agent who issues for hundreds of sellers must ensure that the seller data in every document actually belongs to the seller who owns the supply, not to another seller in the system. An error in linking an invoice to its seller produces a structurally valid document that is attributed to the wrong party, and this is among the most dangerous errors in aggregation environments because it does not necessarily stop clearance; instead it produces an approved invoice attributed to someone other than its owner.
Seller: owner of the supply
Third party: issues and signs with its certificate
Buyer: receives the invoice
Clearance and reporting in Third Party Billing
The third-party flag does not change the approval path, which is determined by the invoice type. A standard invoice addressed to an enterprise goes through immediate Clearance whether the seller or their agent issued it. And a simplified invoice addressed to an individual is delivered immediately then reported to the Authority within twenty-four hours, whether the seller or their agent issued it. What determines the path is the invoice type, not the identity of its issuer.
The difference is that the agent is the one who does the submission on the seller’s behalf. During immediate clearance, the agent sends the document signed with their certificate to the Fatoora platform, which verifies the structure, the fields, the signature, and the flag, then returns the invoice stamped with its approval. At that point the agent delivers the approved invoice to the buyer on the seller’s behalf.
During clearance the system verifies the consistency of three elements together: the raised third-party flag, the signing certificate belonging to the agent, and the identified seller data. Any conflict between these elements returns the document with a rejection message before the stamp is issued. This pattern therefore requires precise tuning in setting up the agent’s account before issuing any invoice.
We focus here only on the pattern’s effect on the invoice structure. As for the full clearance steps from submission to the stamped response, you will find them in the e-invoicing technical documentationseries, and to understand the difference in mandatory fields between the standard invoice and the individual’s invoice review the B2B invoices between enterprises technically.
Distributing responsibility: who bears what?
The separation between the invoice owner and its technical issuer imposes a clear distribution of responsibility. The seller remains the first party responsible before the Authority for the invoice’s validity and content, because the supply is their supply and the tax is their tax. Authorizing the agent does not exempt the seller from their legal responsibility for the validity of what was issued in their name.
The agent is responsible for the technical side: building the document to the standard, signing with their correct certificate, raising the third-party flag, and submitting for clearance on time. If the agent issues an invoice with a wrong structure or an invalid signature, the operational fault is theirs, even though the legal responsibility for the supply stays with the seller.
This distribution makes data quality a shared link. The seller supplies the agent with correct data about the supply and the buyer, and the agent turns it into a compliant document and issues it on time. An error in the data received from the seller produces a wrong invoice despite the soundness of the agent’s technical work, and an error in the technical issuance fails an invoice despite the validity of the seller’s data. The relationship therefore requires clarity in the agreement about who controls what.
In practice, this means the seller does not walk away from oversight the moment they authorize. They must make sure the agent issues their invoices on time, review a sample of the invoices issued in their name, and keep copies of them for tax-audit purposes. Authorization transfers the technical work, not the ultimate responsibility.
There is another dimension of responsibility concerning the invoice record and its archiving. Every invoice the agent issues in the seller’s name remains part of the seller’s tax record, and must be available for review upon the Authority’s request. The seller therefore needs a mechanism guaranteeing their access to every invoice issued on their behalf, rather than it staying locked inside the agent’s system alone. A good agreement stipulates the seller’s right to receive complete copies of their invoices and their signed documents as soon as they are issued.
Corrective transactions likewise handle responsibility by the same logic. When issuing a credit or debit note through the third party, the note inherits the same third-party flag and the same agent certificate, and is linked to the original invoice it corrects. The seller stays responsible for the validity of the correction, and the agent responsible for its sound technical issuance. This consistency between the invoice and its corrective notes is a condition for the system to accept them together.
A complete example: reading an invoice issued through a third party
Let us bring the above together in one concise document. The following invoice is a standard invoice issued through a third party: note the third-party flag raised in the string 0110000, the seller section that carries the original seller’s data not the agent’s, and the signature that will be done with the agent’s certificate in the extensions section after clearance.
Read the document from the top: the third-party flag in the type code tells you the issuer is an agent, then comes the seller with their original data, then the buyer, then the lines, then the totals. On submission the agent signs the document with their own certificate, so the system knows the flag is truthful. Any conflict between the flag, the certificate, and the seller data stops clearance immediately.
Common structural errors in Third Party Billing
Most rejection cases in this pattern trace back to inconsistency of the flag with the signature or the setup. These are the most frequent errors and how to read them:
- A flag raised without authorization: the third position was raised without a standing agreement or without configuring the account as an agent, so an invoice appears declaring a third party with no basis.
- Signing with the seller’s certificate not the agent’s: the third-party flag was raised but the document was signed with the seller’s stamp identifier, so a conflict appeared between the flag and the certificate.
- Mixing the seller’s data with the agent’s: the agent’s data was placed in the seller section
AccountingSupplierPartyinstead of the original seller’s data, so the owner of the supply became wrong in the document. - A flag in the wrong position: a flag was raised in another position of the string instead of the third position, so the meaning of the flag changed entirely (export or medical sector instead of third party).
Note that all these errors concentrate in two places: the type-code flag, and the signing certificate. A third-party invoice is rarely rejected because of the lines or the totals, since these are sections shared with every invoice. But the flag and the certificate are what distinguish this pattern, and this is where the error usually falls. Controlling the quality of Third Party Billing begins from controlling the setup of the agent’s account and certificate before issuing any invoice.
The governing rule: the flag, the signature, and the setup must be consistent together. An invoice declaring that an agent issued it must be signed with that agent’s certificate, must rest on a standing authorization, and must carry the original seller’s data, or else clearance rejects it before it reaches the buyer.
How Qoyod handles Third Party Billing on your behalf
supports Qoyod issuing invoices in line with the requirements of the second phase of e-invoicing, and builds the document with its mandatory fields and its correct type code automatically, based on the account setup and the client’s data. You get this without writing a single line of XML:
- Automatic type determination: Qoyod builds the correct
InvoiceTypeCodestring according to the invoice type and the buyer’s data, and sets the compliant values without manual intervention. - Capturing mandatory data: Qoyod requests the necessary fields when adding the client, so you never issue an invoice missing the fields that would stop clearance.
- Signing and clearance: Qoyod signs the invoice with the CSID stamp identifier and sends it to the Fatoora platform for immediate clearance or reporting according to its type, then returns it stamped and ready for delivery.
- Reading validation messages: if the platform responds with a warning or a rejection, Qoyod displays the rejection reason in understandable language instead of the raw error code.
Issue your compliant e-invoices without writing XML
Qoyod builds your invoice document with its mandatory fields and its correct type code, signs it with the stamp identifier, and passes it through immediate clearance ready for delivery.
Why does understanding this pattern matter to you?
Even if you never write XML yourself, understanding Third Party Billing makes you better able to set your relationship with your agent or platform. You know why the agreement must be in place before the first issuance, why the agent must sign with their certificate not yours, and why the responsibility for the invoice’s validity stays on you even though someone else issued it.
The technical difference has a direct impact on those building a software integration. If you are developing a platform that issues invoices on behalf of merchants, you must raise the third-party flag in the third position, sign every document with your platform’s certificate not each merchant’s, and place the correct merchant data in the seller section. Mixing these elements is the most common cause of clearance failure in aggregation environments, because the system rejects any conflict between the flag, the certificate, and the seller data.
This understanding also helps you if you are a seller considering authorizing an agent. You know that you remain the legal owner of the invoice, that you must review the invoices issued in your name, and that the quality of the data you supply to the agent determines the quality of your invoices. Authorization transfers the technical work, but oversight stays your responsibility.
A quick checklist for a sound third-party invoice
Before issuing any invoice through a third party, make sure the elements that distinguish it from the regular invoice are complete. This list sums up the above in reviewable steps:
- Authorization: a standing written agreement entitling the agent to issue in the seller’s name and defining its scope.
- Third-party flag: the third position in the
InvoiceTypeCodestring raised to1(such as0110000). - Correct certificate: the signature with the agent’s CSID stamp identifier, not the seller’s.
- Seller data: the
AccountingSupplierPartysection carries the original seller’s data, the owner of the supply. - The path: the invoice is directed to clearance or reporting according to its type, not according to the identity of its issuer.
Completing these five items means a third-party invoice ready for clearance on the first attempt. A sound accounting system applies this list automatically, but knowing it makes you able to interpret any rejection if one occurs.
A prior written authorization agreement
Raising the third-party flag in the sub-type
A CSID certificate belonging to the third party
The original seller’s data in AccountingSupplierParty
The correct path for clearance or reporting
Frequently asked questions
What is the difference between Third Party Billing and Self-Billing?
In Third Party Billing an agent outside the transaction (a platform, an office, or a service provider) issues the invoice on the seller’s behalf. In Self-Billing the buyer themselves issues the invoice for their purchases on the seller’s behalf. The difference is that the third-party issuer is neither a seller nor a buyer, while the self-billing issuer is the buyer, and this drives a difference in which flag is raised in the type code.
How is the third-party flag raised in the document?
Through the third position in the name string inside the InvoiceTypeCodefield. This position is raised from 0 to 1 when issuing through an agent, so the standard invoice string reads 0110000 instead of 0100000.
Who signs the invoice issued through a third party?
The agent, with their own Compliance Cryptographic Stamp Identifier (CSID), not the seller’s identifier. The certificate proves to the system that the one who built and signed the document is the agent, and that the raised flag is truthful. Signing with the seller’s certificate while a third-party flag is raised produces a conflict that returns the invoice.
Who bears the legal responsibility for the invoice?
The seller remains the first party responsible before the Authority for the invoice’s validity and content because the supply is their supply. The agent is responsible for the technical side of issuing, signing, and submitting. Authorizing the agent does not exempt the seller from their ultimate responsibility.
Does the seller’s data change in the invoice when issuing through a third party?
No. The AccountingSupplierParty section keeps carrying the original seller’s data, the owner of the supply. The agent does not show their data in the seller section; their effect appears only in the type-code flag and in the signing certificate.
Do I need to write XML myself to issue an invoice through a third party?
No. Qoyod builds the invoice with its mandatory fields and its type code automatically, signs it with the stamp identifier, and passes it through clearance or reporting according to its type, so you enter the data through a simple interface and Qoyod generates the compliant document.
