Buyer identification (BT-46) missing or without its scheme

What does this mean?

Read it as one of two branches. If the buyer holds a VAT registration number, it goes in BT-48 and this rule has nothing to say about the document. If the buyer holds none — a business under the registration threshold, a government body, an individual — then the invoice has to identify them by something else, in BT-46.

The identifier does not travel alone. It is sent with a scheme identifier (BT-46-1) stating which document the number came from, because the same digits mean different things depending on their source. The official message printed above names the accepted codes and what each one stands for. Note that its own prose mentions a passport code that its bracketed list leaves out, so confirm the current list on zatca.gov.sa before you fix a mapping in code.

The value itself is alphanumeric: letters and digits, with no dashes, spaces or slashes. A commercial registration written as 1010-123456 fails on the dash even though the number is right.

It rejects, so the document is not recorded until it is corrected. Two neighbouring codes are close enough to be mistaken for it: BR-KSA-81 is a warning that fires on a tax invoice where the buyer has neither a VAT number nor any other identification, and BR-KSA-F-13 is a warning about a value that does not fit the scheme declared beside it. The extract we work from gives us each message and its severity, not the test that fires it — so read the code you actually received rather than assuming which one covers a plain absence.

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: the buyer has none, the field is left empty, and nothing is put in its place.
• The identifier written without the scheme attribute, so the number looks present and the rule still fails.
• Free text in the scheme — CR, Commercial Registration, national id — instead of one of the codes the rule names.
• Formatting characters inside the value: a commercial registration with dashes, an Iqama number with spaces, an identifier copied out of a spreadsheet with a trailing space.
• The buyer VAT number placed in BT-46 instead of BT-48, which leaves a registered buyer identified in the wrong field.

How to fix it

4 steps, then send the invoice again.

1. 1
   Settle the branch before you build the XML

   Is the buyer registered for VAT? Then BT-48, in its required shape: 15 digits beginning and ending with 3, covered in BR-KSA-44. Not registered? Then BT-46 with its scheme, and no BT-48 at all.

2. 2
   Send the scheme with the number

   The identifier goes in the buyer party identification element and the scheme goes in the schemeID attribute on that same element — not in a separate field, and not inside the value. The value stays alphanumeric.

3. 3
   Take the codes from the Authority, not from a guess

   The message printed above names the codes, but a code list is exactly the kind of thing that gets revised — check it against the current XML implementation standard on zatca.gov.sa before you map your customer types onto it. Where a buyer holds several identifiers the rule asks for one, chosen in the order it lists.

4. 4
   One tightening worth knowing before it bites

   If the invoice carries the exemption reason VATEX-SA-EDU or VATEX-SA-HEA — private education or private healthcare — the requirement narrows: BT-46 becomes mandatory and its scheme must be NAT, the national ID. That is a separate code, BR-KSA-49, and it rejects too.

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.

Frequently asked questions