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-42.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
The buyer name (BT-44) must be present in the tax invoice and associated credit notes and debit notes (KSA-2, position 1 and 2 = 01).
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.
Standard invoice does not name the buyer
Reported asname_element_missingthe name element is missing
What is wrong
The document is a standard tax invoice and the buyer party carries no cbc:RegistrationName under any cac:PartyLegalEntity, so the buyer name is absent. SDK 3.4.8 flags the document under BR-KSA-42 as a warning, not a rejection: the finding is reported without failing the document by itself. The buyer name (BT-44) is read from cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName, and BR-KSA-42 makes it mandatory on a standard tax invoice and its credit and debit notes - the invoice transaction code KSA-2 beginning 01. A simplified invoice is not judged by this rule. One point of ZATCA output to know in advance: the label printed inside the message text reads BR-42, while the code the platform outputs, and the one to search its output for, is BR-KSA-42. A name written elsewhere does not help here: cac:PartyName/cbc:Name is a different element and this check does not read it, so a document that shows the buyer's name to a human reader can still fail this rule.
What to check in your ERP
The value ZATCA wants is the customer's registered legal name, the one on the commercial registration, not a trade name, a short name or a screen display name. The usual causes are a mapping pointed at cac:PartyName instead of cac:PartyLegalEntity, an export that writes the cac:PartyLegalEntity block only when the customer has a VAT number recorded, and a template built for simplified invoices - where the buyer block is minimal - and reused for standard ones. Check what happens for a customer with no legal name field filled in, which is common for records migrated from a point-of-sale system.
Standard invoice's buyer name is empty
Reported asname_emptythe name is present but empty
What is wrong
The document is a standard tax invoice and the buyer party carries the cbc:RegistrationName element, but every one of them is empty, so the buyer name has no value and ZATCA flags the document exactly as it does a missing one: SDK 3.4.8 runs BR-KSA-42 as a warning, which does not by itself reject the document. The buyer name (BT-44) is read from cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName, and BR-KSA-42 makes it mandatory on a standard tax invoice and its credit and debit notes - the invoice transaction code KSA-2 beginning 01. A simplified invoice is not judged by this rule. One point of ZATCA output to know in advance: the label printed inside the message text reads BR-42, while the code the platform outputs, and the one to search its output for, is BR-KSA-42. If the buyer party holds more than one cac:PartyLegalEntity, any one of them carrying a non-empty name satisfies the check, so this note means all of them are blank.
What to check in your ERP
The structure is being written and the value is not, which points at the field the mapping reads rather than at the template. Common causes are a legal name field that is optional in the customer master and empty on this customer, a customer created quickly at the counter and later invoiced as a business, and a mapping that falls back to a blank when the language-specific name field it reads is not filled. Check the customer record behind this document rather than the export layout.
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.
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.