Tax invoice to a buyer with neither a VAT number nor another ID (BT-46)

What does this mean?

The rule reads a family and a condition together. The family is the tax invoice and its credit and debit notes: the documents whose KSA-2 code begins 01. A simplified invoice, beginning 02, is outside it. The condition is that the buyer VAT number (BT-48) is not provided. When both hold, the other buyer ID (BT-46) has to be there.

BT-46 is cac:AccountingCustomerParty/cac:Party/cac:PartyIdentification/cbc:ID, with the kind of document the number comes from in its schemeID attribute. ZATCA's XML Implementation Standard names that element as the one this rule uses, and its Data Dictionary lists BR-KSA-81 against it beside BR-KSA-14 and BR-KSA-49. The accepted kinds, from a commercial registration and a 700 number to a national ID and an Iqama, are named in the message of BR-KSA-14, and that page covers them.

It is a warning: the document is accepted and the warning is recorded with it. That is exactly why it lingers in a system. Nothing stops, and every tax invoice to that buyer goes out naming a buyer it does not identify.

Three codes sit on the same buyer and are easy to confuse with this one. BR-KSA-14, an error, governs the identifier's scheme and its characters. BR-KSA-44, an error, governs the shape of a VAT number that is present. BR-KSA-F-13, a warning, flags a value that does not fit the scheme declared beside it. We read each rule's message and severity, not the test that fires it, so read the code you actually received rather than assuming which of them a bare absence produces.

Why does it happen?

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

• A system that only knows how to send a VAT number: when the buyer has none, the buyer block goes out with a name and an address and nothing in place of the number.
• The identifier is on the customer record but never reaches the XML, because the template writes the VAT element and has no party identification element at all.
• An XML library that demands a buyer VAT number on every invoice that is not simplified. The one we build on does exactly that, and the obvious ways past it trade one problem for another: fifteen zeroes in BT-48 fail BR-KSA-44, and a number that merely looks valid is a VAT number that is not the buyer's.
• The identifier written in the wrong place: a commercial registration or a national ID in the VAT element, where it becomes a malformed VAT number, or in a free-text note, where no validator looks for it.
• A credit or debit note built from the buyer record as it stands today, after the identifier was removed, or from a note template that copies the buyer name and leaves the identification behind.

How to fix it

4 steps, then send the invoice again.

1. 1
   Settle whether the buyer is VAT-registered

   Registered: the number goes in BT-48, 15 digits beginning and ending with 3, and this rule is satisfied; check a number you were given with the VAT number lookup before you rely on it. Not registered, which covers a business under the registration threshold, a government body and an individual: no BT-48 at all, and the buyer is identified in BT-46.

2. 2
   Write BT-46 with its scheme

   Inside the buyer party, ahead of its postal address: <cac:PartyIdentification><cbc:ID schemeID="700">7009876543</cbc:ID></cac:PartyIdentification>. The number goes in as letters and digits with no dashes or spaces, and its kind goes in schemeID. A government body is identified by its 700 number, a company by its commercial registration, a person by a national ID or an Iqama, whose check digit the Authority verifies (BR-KSA-F-13).

3. 3
   Carry it onto the notes

   The rule names credit and debit notes too, and a note against a tax invoice carries a buyer block of its own. Build it from the same identified record as the invoice, not from a copy of the buyer name. The rest of what a note needs, its reason and its reference to the invoice, is in BR-KSA-17 and BR-KSA-56.

4. 4
   Fix the record, not the accepted document

   A document accepted with this warning is issued and stays in your chain. Correct the buyer record so the next tax invoice carries the identifier, and look at the rest of the buyer block while you are there: the buyer name has a warning of its own on the same family of documents, BR-KSA-42.

This code does not block acceptance, so the invoice you have is compliant. Correct the data so the warnings disappear from future invoices.

Frequently asked questions