Error 1002: Buyer VAT Number Missing in a B2B Invoice

If a Fatoora platform rejects your invoice and returns error code 1002, the meaning is direct: the buyer VAT number is missing in an invoice issued from one business to another (B2B). This error never appears in individual consumer invoices; it appears only in standard tax invoices, which is why it confuses many businesses used to issuing simplified invoices that do not require this field. This page explains the error from its root: why the buyer VAT number is mandatory in a B2B invoice, exactly where it belongs inside the XML file, how to read the rejection message, how to correct the invoice and resend it, and how to prevent it from recurring for good.

This guide is part of the ZATCA e-invoicing error reference, within the e-invoicing system from Qoyod. The target audience is the developer, integration analyst, or accountant who runs the technical issuance and wants a precise understanding of the cause, not just a surface-level step.

What error 1002 means exactly

Error code 1002 is a rejection at the validation level of the invoice structure. The platform checks the invoice before approving it, so if it is a standard (B2B) type and finds no valid buyer VAT number in its designated place, it halts the invoice and rejects it with a message indicating that the buyer’s tax identity is incomplete.

The important thing is to understand that the rejection here is not random. The validation rule is explicit: a standard tax invoice addressed to a registered business must carry the buyer VAT number inside the buyer party block. A missing field, an empty one, or one placed in the wrong location all produce error 1002.

You should not confuse this code with error 1001, which concerns the seller VAT number. Error 1001 says the seller’s number (your own business) is invalid or does not match the format, that is, a problem in your own identity. Error 1002, by contrast, says the buyer’s number (the other party) is missing. The first is about who issues the invoice, the second about who receives it. We will devote a full section to this difference later so you do not fix the error in the wrong place.

How to read the rejection message

When the invoice is rejected, the platform returns a response carrying the invoice status and a list of validation errors. Each error carries a code, a category, and a message. The block below is an illustrative example of a rejection response caused by a missing buyer VAT number in a B2B invoice. Copy it and compare it against the response structure your system returns.

{
  "validationResults": {
    "infoMessages": [
      {
        "type": "INFO",
        "code": "XSD_ZATCA_VALID",
        "category": "XSD validation",
        "message": "Complied with UBL 2.1 standards"
      }
    ],
    "warningMessages": [],
    "errorMessages": [
      {
        "type": "ERROR",
        "code": "1002",
        "category": "Buyer party validation",
        "message": "Buyer VAT registration number is missing for a standard tax invoice (B2B)."
      }
    ],
    "status": "ERROR"
  },
  "clearanceStatus": "NOT_CLEARED",
  "clearedInvoice": null
}

The keys that matter to you when reading it:

• clearanceStatus with the value NOT_CLEARED means clearance did not happen, so the invoice was not approved and may not be handed to the buyer.
• status inside the validation results with the value ERROR means the reason for the stop is a blocking error, not merely a warning.
• code with the value 1002 is the precise definition of the cause, and the message explains it in text.
• clearedInvoice with the value null confirms that there is no stamped copy returned to you.

The practical rule: do not look at the text message alone; read the code because it is fixed and does not change, whereas the wording of the message may differ slightly between versions.

Why the buyer VAT number is mandatory in B2B but not B2C

The answer starts from the function of the invoice itself. A standard tax invoice (B2B) is a document between two businesses registered for VAT. The buyer in this case is a business that will use the invoice to deduct input tax: that is, it recovers the tax it paid you from the tax it collects from its own customers. For this deduction to be sound before the Authority, the invoice must identify the buyer completely, and the most important part of that identification is its VAT number.

In other words: the buyer VAT number is the link that proves the party who will deduct the tax is a real, registered business, and that the transaction is documented on both sides. Without this number the invoice becomes invalid for input-tax deduction, which is why the validation rule rejects it from the outset.

Compare this with the simplified tax invoice (B2C) addressed to a final consumer. The consumer is an individual who deducts no input tax; they are the end of the chain. There is no subsequent recovery that needs their tax identity documented, and so the simplified invoice does not require a buyer VAT number at all. This is the essence of the difference: the requirement is tied to the deduction function, not to the shape of the document.

This leads to an important design consequence: if your system issues both types, it must not apply the same rule to both. The buyer VAT number is a conditional field: mandatory when InvoiceTypeCode name starts with 01 (standard), and optional or usually absent when it is 02 (simplified). Treating it as a fixed field in both types produces either error 1002 in B2B, or an unnecessary empty field in B2C.

And because a B2B invoice goes through the immediate clearance path (it is sent to the platform, approved and stamped, then returned to you), the check on the completeness of the buyer’s identity happens instantly before approval. The simplified invoice, by contrast, is issued immediately and reported within 24 hours, so the buyer is not an obstacle to handing it over. The details of the two paths are in the guide on B2B business invoices, technically.

Where the buyer VAT number belongs in the XML file

The buyer VAT number has one specific place in the invoice, and any placement outside this location equals its absence from the validation’s point of view. The location is the buyer party block AccountingCustomerParty, specifically inside PartyTaxScheme in the element CompanyID. The block below shows the correct structure:

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:StreetName>King Fahd Road</cbc:StreetName>
      <cbc:BuildingNumber>1234</cbc:BuildingNumber>
      <cbc:CityName>Riyadh</cbc:CityName>
      <cbc:PostalZone>12345</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>SA</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>

    <cac:PartyTaxScheme>
      <!-- Buyer VAT number: 15 digits, starts and ends with 3 -->
      <cbc:CompanyID>300000000000003</cbc:CompanyID>
      <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
      </cac:TaxScheme>
    </cac:PartyTaxScheme>

    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Buyer Trading Company</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

Three precise points in this block:

1. The number is placed in cbc:CompanyID inside cac:PartyTaxScheme, nowhere else. Many errors are caused by placing the number in another identity element such as PartyIdentification which is meant for other identification numbers, so the validation rule does not read it as a VAT number.
2. The element TaxScheme/ID must carry the value VAT to confirm the number is a VAT number, not another identifier.
3. The Saudi VAT number is 15 digits, starting with the digit 3 and ending with it. If it has fewer digits or does not start with 3, the validation may read it as an invalid number, and here the problem may shift to other formatting errors and not just 1002 alone.

And for a direct comparison, this is what the buyer party looks like when it produces error 1002: a party block that exists but with no PartyTaxScheme at all, or with an empty CompanyID .

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:CityName>Riyadh</cbc:CityName>
      <cac:Country>
        <cbc:IdentificationCode>SA</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>

    <!-- PartyTaxScheme block entirely missing -> produces error 1002 -->

    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Buyer Trading Company</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>

Note that the rest of the invoice may be entirely sound: the line items are correct, the totals balance, and the stamp is in place. The absence of a single block in the buyer party is enough to halt the whole invoice. To understand the rest of the buyer-party sections and their place in the tree, see the guide on the invoice header (Invoice Header) in XML.

The difference between B2B and B2C in the buyer field

The table below summarizes when the buyer VAT number is mandatory, and what its absence entails in each type:

How to correct the invoice and resend it

Correcting error 1002 does not require changing the whole invoice structure, only completing a single block. Follow these steps in order:

1. Confirm the invoice type first. Open the type-code element and verify that name starts with 01. If it starts with 02 the invoice is simplified and should not require a buyer number at all, and the fault is in the invoice’s classification, not in the buyer field.
2. Obtain the correct buyer VAT number. Request it from the buying business, or pull it from its record in your system. Verify that it is 15 digits, starts with 3 and ends with it, and that it belongs to a business registered for VAT.
3. Add the PartyTaxScheme block in the correct location. inside AccountingCustomerParty/Party, place the number in CompanyID and set TaxScheme/ID to VAT, as in the correct model above.
4. Complete the national address if it is incomplete. A B2B invoice requires the buyer’s national address (city, postal code, country code SA at least). A missing address may trigger adjacent validation errors after 1002 is resolved.
5. Regenerate the document and sign it again. Any change in the invoice content alters its hash, so do not settle for just adding the field; regenerate the file and stamp it with the CSID certificate before sending.
6. Resend to clearance. Pass the corrected invoice through the local validation stage first, then send it. On successful clearance you will receive clearanceStatus with the value CLEARED and a stamped copy in clearedInvoice.

An important note on resending: do not resend the original rejected invoice as is, thinking the problem is transient. A 1002 rejection is a fixed structural rejection, and it will recur until you actually complete the field. Likewise, do not create a new invoice with a new sequential number to bypass the rejected one, because the invoice counter ICV must remain sequential. Correct the invoice itself and regenerate it with the same counter.

The error 1002 fix path, step by step

This path works as a quick checklist every time error 1002appears. The two most commonly overlooked steps are regenerating after the edit and completing the national address, so do not skip them.

How to tell 1002 from 1001 and not fix the error in the wrong place

The two codes are adjacent in numbering and both concern the VAT number, so they are easy to confuse. But the source of each is entirely different, and treating one with the logic of the other wastes your time.

Error 1001 concerns the seller’s, that is, your own business. It appears when your VAT number in the AccountingSupplierParty block is invalid: wrong number of digits, or does not start with 3, or does not match the number linked to your certificate. The fix there is in your business settings and matching your number with your registration certificate.

Error 1002 concerns the buyer’s, that is, the other party. It appears when the buyer’s number in the AccountingCustomerParty block is missing in a B2B invoice. The fix here is in the customer data you enter for each invoice, not in your business settings.

A quick way to tell them apart: read the category in the error message. If it points to Seller or Supplier the problem is in the seller (1001); and if it points to Buyer or Customer the problem is in the buyer (1002). And if the invoice is a simplified B2C one and you receive 1002, the classification is most likely wrong and your invoice was classified as standard by mistake.

A practical scenario: a supplier in Riyadh issues an invoice to another business

Let us take a real-world case that explains when the error appears and why. A contracting company in Riyadh sells building materials to a real-estate developer. Both parties are businesses registered for VAT, so the invoice between them is of the standard B2B type. The contractor’s accountant enters the customer data, sets the line items, and issues the invoice, and it comes back rejected with error 1002.

The reason for the rejection here is that the customer record in the system was created hastily with only the name and address, without entering the VAT number. The system built the buyer party block with the name and address, but PartyTaxScheme came out empty, so the validation rule halted the invoice. Note that the accountant made no mistake in the line items or the tax; the fault was in an entirely earlier step, namely the completeness of the customer record.

The fix in this case is practical and direct: the accountant requests the VAT number from the real-estate developer, adds it to the customer record, verifies that it is 15 digits starting and ending with 3, then regenerates the invoice so the buyer block is built in full and clearance passes successfully. The lesson: error 1002 often reveals a gap in your customer-onboarding procedures, not in the invoice itself. A business that requires the VAT number when opening any business-customer record will never face this scenario at all.

How to validate the buyer VAT number before issuance

Adding the number alone is not enough, because a number that is malformed may resolve error 1002 yet trigger another formatting error. Check these points before accepting any buyer’s number:

• Length. The Saudi VAT number is exactly 15 digits, no fewer and no more. Any different length means an entry error.
• The prefix and suffix. The number starts with the digit 3 and ends with it. This is a fixed rule in Saudi VAT numbers.
• The middle digits. The digits between the start and the end are entirely numeric, with no letters, spaces, or symbols.
• Matching the entity. The number belongs to the buying business itself, not a sister business or a different branch. A common mistake is entering the parent group’s number instead of the contracting entity’s number.

Automated validation of the length and prefix catches most entry errors before they reach the platform. And when the buyer is a repeat customer, saving its validated number once in its record eliminates the need to enter it manually on every invoice, and that alone cuts off the most common source of the error.

How to prevent the error from recurring for good

Error 1002 is one of the most preventable errors, because its cause is incomplete data, not a deep technical fault. The following measures close the door on it:

• Make the VAT number a mandatory field in the business customer record. If your customer is a business, do not allow its record to be saved without a valid VAT number. This way the invoice never reaches the issuance stage with an empty buyer field.
• Separate business customers from individual customers in your system. Classify each customer: a business that gets a B2B invoice and requires a VAT number, or an individual who gets a simplified B2C invoice that does not. This classification automatically determines which validation rule applies.
• Validate the number before issuance, not after. Add local validation that rejects a standard invoice without a valid buyer number before sending it to clearance, so you catch the error in your system instead of the platform catching it.
• Check the number’s format automatically. 15 digits, starting and ending with 3. A simple check of the length and prefix catches most entry errors before sending.
• Use an invoicing system that builds the block automatically. When the system fills the buyer party block directly from the customer record, the human error that produces 1002 disappears.

Together these measures turn error 1002 from a recurring problem into a rare case that appears only with incomplete new-customer data, and even then it is caught locally before it reaches the platform.

What happens if you leave the error unresolved

Error 1002 is not a warning you can bypass; it is a rejection that stops the invoice legally. As long as clearanceStatus with the value NOT_CLEARED, the invoice is not approved and may not be handed to the buyer. In practice this means you have not yet issued a valid invoice, however complete it may look in your system.

The impact extends to both parties. You cannot prove revenue with an approved invoice, and the buyer cannot deduct input tax because it does not hold a legal invoice. Delaying the correction disrupts the document cycle between you, and it may accumulate with later invoices if the customer record was incomplete to begin with. That is why dealing with 1002 the moment it appears is cheaper than postponing it.

A final important point: the same rule applies to credit and debit notes tied to a B2B invoice. A note that adjusts a standard invoice inherits the buyer VAT number requirement, so if you issue a credit note on a B2B invoice with no buyer number, you receive error 1002 itself. Treat notes with the same care you give the original invoice.

Issuing sound B2B invoices the first time starts with a system that fills the mandatory fields for you, validates them before sending, and passes them through clearance automatically.

Where the buyer VAT number sits in the invoice tree

This tree captures the whole rule: the number goes in CompanyID inside PartyTaxScheme, not in any other identity element. Placing it out of position equals its absence. To understand the full technical path of the invoice from issuance to clearance, see B2B business invoices, technically, and to review the rest of the error codes see the ZATCA e-invoicing error reference.

Frequently asked questions

What is the difference between error 1001 and error 1002?
Error 1001 concerns the seller VAT number (your business) when it is invalid, and error 1002 concerns the buyer VAT number (the other party) when it is missing in a B2B invoice. The first originates in your business settings, the second in the customer data in the invoice.

Does error 1002 appear in a simplified B2C invoice?
It should not, because a simplified invoice does not require a buyer VAT number at all. If you see 1002 on an invoice you think is simplified, it was most likely classified as standard B2B by mistake in the type code. Verify that name starts with 02.

Where exactly is the buyer VAT number placed in the file?
inside AccountingCustomerParty/Party/PartyTaxScheme/CompanyID, with TaxScheme/ID set to the value VAT. Placing it in another identity element such as PartyIdentification is not read by validation as a VAT number and produces the same error.

Do I resend the rejected invoice as is after adding the number?
No. Any change in the content alters the invoice hash, so the document must be regenerated and signed with the CSID certificate again before resending to clearance. Add the field, regenerate, then send.

What does a correct Saudi buyer VAT number look like?
15 numeric digits, starting with the digit 3 and ending with it, and belonging to a business registered for VAT. A wrong length or a wrong prefix may move the problem to another formatting error after 1002 is resolved.

How do I prevent error 1002 from recurring in the future?
Make the VAT number a mandatory field in the business customer record, separate business customers from individuals, and add local validation that rejects a standard invoice without a buyer number before sending it. Qoyod builds this block automatically from the customer record, so the error never reaches you in the first place.