Seller VAT number identical to the buyer VAT number

What does this mean?

A tax invoice documents a supply from one business to another. If the VAT number in the seller field (BT-31) is the same as the number in the buyer field (BT-48), you are describing a sale from the business to itself — which is not a taxable supply, so the Authority rejects it immediately.

This is one of the codes we see most often in real rejection responses, and the cause is always bad data rather than a misunderstanding of the concept.

Why does it happen?

Ordered from the most common to the least — your cause is most likely the first or the second.

• Test data left behind in the customer record — your own VAT number sitting in the buyer field.
• A default point-of-sale customer created by copying the establishment details.
• Trying to issue an invoice between two branches of the same business.
• The buyer field being auto-filled from the establishment settings when no customer is selected.

How to fix it

3 steps, then send the invoice again.

1. 1
   Enter the real VAT number of the buyer

   Ask the customer for it, read it from the QR code on an invoice they issued, or confirm it with the VAT number lookup, which shows the name of the business registered under that number.

2. 2
   If the buyer is not registered for VAT, do not give them a VAT number

   A simplified tax invoice does not require a buyer VAT number. Leave the field empty instead of filling it with whatever number is to hand.

3. 3
   A transfer between two branches is not an invoice

   Branches share one VAT number because they are a single establishment for VAT purposes, so a movement between them is not a supply and no tax invoice is issued for it. Use an internal transfer document. The only exception is when the other party is a separate entity registered under a different VAT number.

Once corrected, send the invoice again. A rejected invoice was never recorded with the Authority, so it needs no credit note — send the corrected invoice itself.

What the rejection actually looks like

{
    "error": "ZATCA API error (HTTP 400) on POST /invoices/reporting/single",
    "context": {
        "validationResults": {
            "infoMessages": [
                {
                    "type": "INFO",
                    "code": "XSD_ZATCA_VALID",
                    "category": "XSD validation",
                    "message": "Complied with UBL 2.1 standards in line with ZATCA specifications",
                    "status": "PASS"
                }
            ],
            "warningMessages": [],
            "errorMessages": [
                {
                    "type": "ERROR",
                    "code": "BR-CUSTOM-VALIDATION-01",
                    "category": "KSA",
                    "message": "[BR-CUSTOM-VALIDATION-01]- The Seller VAT registration number or seller group VAT registration number (BT-31) of The invoice must not match the buyer VAT registration number (BT-48).",
                    "status": "ERROR"
                }
            ],
            "status": "ERROR"
        },
        "reportingStatus": "NOT_REPORTED"
    }
}

A real rejection response we recorded from the Authority interface. Note that XSD_ZATCA_VALID passed — the structure of the XML file is perfectly sound, and the rejection came from a business rule, not from the format. Note also reportingStatus: NOT_REPORTED: the invoice was not reported, so the 24-hour window is still running against you.

Frequently asked questions