BR-KSA-14Buyer identification carries no scheme id
Mutabiq checks Saudi ZATCA Phase 2 e-invoice XML before you submit it: pre-validation against published ZATCA requirements, not an approval by the authority. This page explains one rule, BR-KSA-14.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-14]-The buyer identification (BT-46), required only if buyer is not VAT registered, then the buyer identification (BT-46) must be provided with one of the scheme IDs (BT-46-1) (TIN, CRN, MOM, MLS, 700, SAG, NAT, GCC, IQA, PAS, OTH) and must contain only alphanumeric characters. Tax Identification Number "TIN" as schemeID ;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 ;National ID with "NAT" as schemeID ;GCC ID with "GCC" as schemeID ;Iqama Number with "IQA" as schemeID ;Passport ID with "PAS" as schemeID ;Other ID 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 Mutabiq reports
One entry for each way this rule can be reported.
Reported as
What kind of value was found — empty, not_15_digits and the like — never the value itself.
Buyer identification carries no scheme id
Reported asscheme_id_missingno scheme id
What is wrong
A buyer identification (BT-46) — a cbc:ID under cac:PartyIdentification in the buyer's party block — has no schemeID attribute, or carries one that is empty. The schemeID says which kind of identifier the value is, and ZATCA rejects an identification without one under BR-KSA-14. Be careful reading ZATCA's own output here: the test it prints alongside this rule omits the presence check, so that text alone suggests a missing schemeID is tolerated. The check that actually runs rejects it.
What to check in your ERP
Every buyer identification needs both parts: the value in the element and the kind in its schemeID attribute. Eleven kinds are accepted for the buyer: NAT for a national identity number, TIN for a tax identification number, IQA for an iqama, PAS for a passport, CRN for a commercial registration number, MOM, MLS and SAG for the respective licences, 700 for the number the ZATCA XML Implementation Standard names, GCC for a Gulf identity, and OTH for anything else. In most systems the identifier and its kind are two columns of one table and the export writes only the first.
Buyer identification scheme id is not one ZATCA accepts
Reported asscheme_id_not_listeda scheme id ZATCA does not accept
What is wrong
A buyer identification (BT-46) carries a schemeID that is not in the list ZATCA accepts for the buyer, and is rejected under BR-KSA-14. In SDK 3.4.8, which rule pack 2.0.0 reads, the list has eleven entries - TIN, NAT, IQA, PAS, CRN, MOM, MLS, 700, SAG, GCC and OTH - and ZATCA's message for the rule prints all eleven. Earlier releases (SDK 3.0.8) accepted ten, without 700, and their message left TIN out although the check accepted it.
What to check in your ERP
Map each identifier you hold for the customer onto one of the eleven: NAT for a Saudi national identity number, IQA for a resident's iqama, PAS for a passport, TIN for a tax identification number, CRN for a company's commercial registration, GCC for a Gulf national identity, MOM, MLS or SAG for the licences, 700 for the number the ZATCA XML Implementation Standard names, and OTH for anything that fits none of them. OTH is a legitimate answer. The seller's list is shorter - CRN, MOM, MLS, SAG, OTH and 700 - so a code that works for the buyer may draw a warning on the seller.
Buyer identification value contains characters other than letters and digits
Reported asvalue_not_alphanumericcontains characters other than letters and digits
What is wrong
A buyer identification (BT-46) holds a value with something other than Latin letters and digits in it. Only rule packs before 2.0.0 report this: SDK 3.0.8's BR-KSA-14 also required the value to be alphanumeric and refused any other character - a space, a dash, a slash, a full stop, or Arabic text. In SDK 3.4.8, which rule pack 2.0.0 reads, BR-KSA-14 no longer tests the value, although its message still says the value must contain only alphanumeric characters, so a report produced under 2.0.0 never carries this note. SDK 3.4.8 adds separate format warnings on identifier values (BR-KSA-F-07 to BR-KSA-F-13), which Mutabiq does not mirror.
What to check in your ERP
Send the identifier as it appears on the document it comes from, with no formatting: no spaces inside a passport or iqama number, no dashes between groups, no prefix. The usual causes are a value stored with separators for display and exported as stored, and a customer record where the identifier field has been used to hold a note as well as a number.
The clause that runs
Quoted from the validation-rule stylesheet ZATCA publishes, at the file and line named below. The executed guard is what the check runs; the reported test is what it prints when it fails, and the two are not always the same.
Executed guard
not( string-length(normalize-space( ./@schemeID)) > 2 and contains('TIN NAT IQA PAS CRN MOM MLS 700 SAG GCC OTH', normalize-space(./@schemeID)))
Reported test
contains(' NAT TIN IQA PAS CRN MOM MLS SAG GCC OTH 700', ./@schemeID) and (matches((.), '^[a-zA-Z0-9]*$'))
As shipped in ZATCA SDK 3.4.8: the copy quoted here is, byte for byte, the file that release ships. The date in the file name is the name ZATCA gives the file; the rules in it are those of SDK 3.4.8.
A worked example
A synthetic document from the measured test corpus that trips this rule, shown where it differs from one that passed. Mutabiq's report names the class of the value, never the value itself.