BR-KSA-25Simplified private education or healthcare invoice does not name the buyer
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-25.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-KSA-25]-If it is a simplified tax invoice or an associated credit note or a debit note (KSA-2, position 1 and 2 = 02) and the tax exemption reason code (BT-121) is equal with VATEX-SA-EDU or VATEX-SA-HEA, then buyer name (BT-44) is mandatory.
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.
Simplified private education or healthcare invoice does not name the buyer
Reported asname_element_missingthe name element is missing
What is wrong
This is a simplified invoice, credit note or debit note (transaction code beginning 02), every exemption reason code on it is VATEX-SA-EDU or VATEX-SA-HEA - private education or private healthcare for a citizen - and the buyer party carries no cbc:RegistrationName under cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity, so the buyer name (BT-44) is absent. SDK 3.4.8 flags the document under BR-KSA-25 as a warning, not a rejection: the finding is reported without failing the document by itself. A simplified invoice normally needs no buyer name; these two supplies are the exception, because the zero rating belongs to the citizen who receives them, whose national ID BR-KSA-49 already requires. The rule applies only when every reason code on the document is one of the two: a document that mixes one of them with another code, such as VATEX-SA-32, is outside it, and so is a document with no reason code at all. ZATCA's checker was measured on that last point - read by the letter the rule would apply to every simplified invoice without a reason code, and ZATCA's own tool does not apply it there, so neither does Mutabiq.
What to check in your ERP
Write the citizen's name into cac:PartyLegalEntity/cbc:RegistrationName under the buyer party on every simplified invoice that uses one of these two codes, from the same customer record that supplies the national ID for cac:PartyIdentification. cac:PartyName/cbc:Name is a different element and does not satisfy this check. If the invoice is addressed to an insurer, an employer or another payer rather than to the citizen, read the note under BR-KSA-49 first: these codes are for a supply to the citizen, and the question is the code rather than the name.
Simplified private education or healthcare invoice's buyer name is empty
Reported asname_emptythe name is present but empty
What is wrong
This is a simplified invoice, credit note or debit note (transaction code beginning 02), every exemption reason code on it is VATEX-SA-EDU or VATEX-SA-HEA - private education or private healthcare for a citizen - and the buyer party carries the cbc:RegistrationName element under cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity, but every one of them is empty, so the buyer name (BT-44) has no value. SDK 3.4.8 flags the document under BR-KSA-25 exactly as it does a missing name: as a warning, not a rejection, so the finding is reported without failing the document by itself. Any one non-empty name would satisfy the check, so this note means all of them are blank. A simplified invoice normally needs no buyer name; these two supplies are the exception, because the zero rating belongs to the citizen who receives them, whose national ID BR-KSA-49 already requires.
What to check in your ERP
The structure is being written and the value is not, which normally means the export emits the buyer legal entity block for every document while the name comes from a field that is empty for a walk-in customer. For a private education or healthcare supply the customer is a named citizen: fill the name from the same customer record that supplies the national ID for cac:PartyIdentification, and stop emitting an empty block elsewhere.
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((every $taxreasoncode in //cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode satisfies contains(' VATEX-SA-HEA VATEX-SA-EDU ', $taxreasoncode) and exists(//cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) and (//cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) != '') or not(every $taxreasoncode in //cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode satisfies contains(' VATEX-SA-HEA VATEX-SA-EDU ', $taxreasoncode)))
Reported test
(every $taxreasoncode in //cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode satisfies contains(' VATEX-SA-HEA VATEX-SA-EDU ', $taxreasoncode) and exists(//cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) and (//cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName) != '') or not(every $taxreasoncode in //cac:TaxTotal/cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode satisfies contains(' VATEX-SA-HEA VATEX-SA-EDU ', $taxreasoncode))
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.