BR-KSA-44Buyer VAT registration number is not 15 digits
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-44.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-44]-If it exists in the invoice,the buyer VAT registration number or buyer group VAT registration number (BT-48) must contain 15 digits. The first digit and the last digit is "3".
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 VAT registration number is not 15 digits
Reported asnot_15_digitsnot fifteen digits
What is wrong
The buyer VAT registration number (BT-48), the cbc:CompanyID under the buyer's cac:PartyTaxScheme, is not exactly 15 digits. ZATCA rejects it under BR-KSA-44, which requires 15 digits and nothing else. Earlier SDK releases (3.0.8) applied this rule only to invoices that are not exports and forbade a buyer VAT registration on an export under BR-KSA-46; SDK 3.4.8, which rule pack 2.0.0 reads, removed BR-KSA-46 and applies this rule to every invoice, export or not. Note that unlike the seller's equivalent rule, this one passes over a value that is present and blank - it only tests a number that is actually there.
What to check in your ERP
Send the 15 digits alone: no spaces, no dashes, no VAT or SA prefix, and no group separators. The usual causes are a number stored with formatting for display and exported as stored, and a commercial registration number - usually 10 digits - mapped into this field by mistake. Correct it in the customer record or the mapping. If this customer is not VAT-registered, the whole cac:PartyTaxScheme block for them should be left out rather than filled with a placeholder.
Buyer VAT registration number does not begin with 3
Reported asfirst_digit_not_3does not begin with 3
What is wrong
The buyer VAT registration number (BT-48), the cbc:CompanyID under the buyer's cac:PartyTaxScheme, is 15 digits but does not begin with 3. Every Saudi VAT registration number does, and ZATCA rejects one that does not under BR-KSA-44.
What to check in your ERP
A 15-digit number starting with something else is usually a different identifier that has been mapped into this field - a commercial registration number, a national identifier, or a customer account code. Those belong under cac:PartyIdentification with a schemeID, not here. Check the VAT registration number recorded against this customer.
Buyer VAT registration number does not end with 3
Reported aslast_digit_not_3does not end with 3
What is wrong
The buyer VAT registration number (BT-48), the cbc:CompanyID under the buyer's cac:PartyTaxScheme, is 15 digits but does not end with 3. Every Saudi VAT registration number does, and ZATCA rejects one that does not under BR-KSA-44.
What to check in your ERP
The last digit is the one most often lost or altered in transit: a value truncated to 14 digits and then padded, or a number typed from a document that wrapped. Compare what the export writes with the number the customer supplied. Customer VAT numbers are usually keyed by hand, so this is worth checking against the customer's own certificate rather than against your record of it.
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
string-length(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID) > 0 and not(exists(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID) and matches(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '^[0-9]{15}$') and starts-with(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '3') and ends-with(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '3'))
Reported test
matches(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '^[0-9]{15}$') and starts-with(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '3') and ends-with(//cac:AccountingCustomerParty/cac:Party/cac:PartyTaxScheme/cbc:CompanyID, '3')
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.
Where it differs from a document that passed
− This example
+ A document that passed
</cac:PostalAddress><cac:PartyTaxScheme>−This example: <cbc:CompanyID>31111111111113</cbc:CompanyID>+A document that passed: <cbc:CompanyID schemeID="HQ">311111111121113</cbc:CompanyID> <cac:TaxScheme> <cbc:ID>VAT</cbc:ID>