BR-KSA-08 — Seller identification (BT-29) missing, repeated or not alphanumeric

The message text as the Authority sends it in English, unedited

The seller identification (BT-29) must exist only once with one of the scheme ID (BT-29-1) (CRN, MOM, MLS, SAG, OTH, 700) and must contain only alphanumeric characters. Commercial Registration number with "CRN" as schemeID. MOMRAH license with "MOM" as schemeID. MHRSD license with "MLS" as schemeID. 700 Number with "700" as schemeID. MISA license with "SAG" as schemeID. Other OD with "OTH" as schemeID. In case of multiple commercial registrations, the seller should fill the commercial registration of the branch in respect of which the Tax Invoice is being issued. In case multiple IDs exist then one of the above must be entered following the sequence specified above.

What does this mean?

Alongside the VAT number, the invoice carries a second identifier for the seller (BT-29) — usually the commercial registration — in cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID, with its type (BT-29-1) in the schemeID attribute on that same element. The rule packs three conditions into one sentence: the identifier appears exactly once, its scheme is one of six codes, and its value contains letters and digits only.

The six codes, as the message explains them: CRN for the commercial registration, MOM for a MOMRAH (municipal) licence, MLS for a Ministry of Human Resources and Social Development (MHRSD) licence, 700 for the unified number, SAG for a Ministry of Investment (MISA) licence, and OTH for anything else. The seller list is narrower than the buyer list in BR-KSA-14: a national ID, an Iqama, a GCC ID and a passport are schemes for a buyer, not for a seller.

Letters and digits only rules out exactly what a CR number is usually formatted with to make it easy on the eye: the space between groups, the dash, the slash, the dot. A commercial registration written 1010-123456 is a correct number carrying a character the rule does not allow, and so is 1010 123456. The safe form is Latin letters and digits run together; Arabic-Indic digits from an Arabic keyboard are a risk with nothing to gain.

The rule has a second half that is easy to miss. Where there are several commercial registrations, the one to write is the CR of the branch the invoice is issued in respect of, not the head office's. Where there are several identifiers of different kinds, only one is written, chosen in the order the message sets out: CRN, then MOM, MLS, 700, SAG and OTH. Note that the bracketed list at the start of the message above puts 700 last, while its itemised explanation puts it fourth — and so does the XML implementation standard (version 1.2) published on zatca.gov.sa.

It is a warning: the invoice is accepted — cleared if it is a tax invoice, reported if it is simplified — and the warning comes back alongside that acceptance. Its neighbour BR-KSA-F-13, also a warning, concerns an invalid value in the same identifier, and the two often arrive together. What the warning does cost: the identifier that ties the document to your registered establishment arrives missing or malformed, and it repeats on every document, because the identifier is read from the establishment record.

Why does it happen?

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

A CR number copied the way it is printed for people: 1010-123456, 1010 123456 or 1010/123456, or with a trailing space carried over from a spreadsheet cell.
The scheme written as free text or as a code that is not on the list — CR, CRNO, Commercial Registration — or a schemeID attribute that is empty or missing.
Two seller identifiers instead of one: the commercial registration and the unified number together, or the head-office CR and the branch CR on the same document.
A template built on the European EN 16931 specification, where the seller identifier is optional and may repeat: the element is left out altogether, or sent twice, and the template passes European validation and fails here.
A buyer-side scheme used for the seller: a sole proprietorship sending the owner's ID under NAT, which is not among the six seller schemes.
Arabic-Indic digits from a form in an Arabic locale, or invisible direction marks pasted in along with a number copied out of a PDF.

How to fix it

4 steps, then send the invoice again.

1

Clean the identifier when it is entered, not when it is sent

Strip spaces, dashes, slashes and dots at the moment of saving, and store the number run together: 1010123456. Check its shape against its scheme — a commercial registration is ten digits. A mistake refused at entry is corrected once; one discovered at send time repeats on every document.
2

One element, one of the six schemes

Emit a single cac:PartyIdentification for the seller, holding cbc:ID with a schemeID attribute that carries one of the six codes exactly as the message writes them. If your system holds several identifiers, do not send them all to be safe: the rule asks for one.
3

Pick the right identifier for each document

A branch invoice carries the CR of the branch it was issued in respect of. Where the kinds differ, take the first in the order: commercial registration, municipal licence, MHRSD licence, unified number, MISA licence, then anything else. Then confirm the value really is of the scheme you declared, since a mismatch is the business of BR-KSA-F-13.
4

Correct the establishment record once

The documents that carried the warning were accepted and do not need reissuing to stand. Correct the identifier in the establishment record — and in the record of every branch with a CR of its own — and the next documents go out clean.

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

Does ZATCA Tools prevent it?

Yes. The identifier is stored run together — spaces, dashes, slashes and dots are removed on entry — and then refused unless it fits its scheme: a commercial registration is ten digits, a unified number is ten digits starting with 7, and the other schemes are 3 to 30 Latin letters and digits. That happens in establishment setup, in the establishment profile and in the partner API. The scheme can only be one of the six the rule names: the screens offer nothing else, and the partner API refuses anything else by name. The XML library writes a single identifier element for the seller, never more, and refuses to build the document when the identifier is empty, so no document leaves here without BT-29 or with two of them. And an invoice from a branch that has its own commercial registration carries that registration — ten digits, checked when the branch is added — in place of the head office's rather than beside it, which is what the rule asks for when there are several registrations.

Related codes

BR-KSA-F-13 Warning

Additional seller or buyer identifier holds an invalid value

BR-KSA-14 Rejects the invoice

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

BR-KSA-39 Rejects the invoice

Seller VAT number missing

Frequently asked questions

Does this code reject the invoice? +

No. It is a warning: the invoice is accepted and the warning is recorded with it. Fix it anyway — it repeats on every document until the identifier in the establishment record is corrected.

My error says registrationNumber can only contain alphanumeric characters. Is that this rule? +

That wording is not the message quoted above, and it is not among the rules we index from the SDK the Authority publishes, so we cannot tell you which layer produced it — a validator in your own software, a library, or a platform in between. The condition it describes does match the last clause of this rule, though, and the fix is the same: letters and digits only, with no spaces, dashes or slashes.

We hold a commercial registration and a MISA licence. Which do we send? +

One of them, not both: the rule asks for a single identifier and sets an order — CRN, MOM, MLS, 700, SAG, OTH. The commercial registration comes first, so it is the one to send.

We have several commercial registrations, one per branch. Which goes on the invoice? +

The CR of the branch the invoice is issued in respect of — the message says so in as many words. The head-office CR goes on head-office invoices, and each branch CR goes on that branch's invoices.

Can I use my national ID as the seller identifier? +

Not under this rule: its six schemes are CRN, MOM, MLS, 700, SAG and OTH, and NAT is not among them — national IDs, Iqamas and passports appear only in the buyer list of BR-KSA-14. Which document your establishment trades under is a registration matter rather than an XML one; whatever it is, send it under the scheme that names it.

You fixed this one — now avoid the next

ZATCA Tools builds the signature, the PIH, the counter and the encoding for you, and validates your data before it is sent. Start free, with no credit card.

Start for free

← All ZATCA error codes