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-04.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
The message ZATCA prints
[BR-04]-An Invoice shall have an Invoice type code (BT-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.
Invoice type code element is missing
Reported asmissingthe element is missing
What is wrong
The document carries no cbc:InvoiceTypeCode element at all. EN 16931 rule BR-04 requires every invoice to have an invoice type code (BT-3), which is what tells ZATCA whether the document is a tax invoice, a debit note or a credit note, so a document without the element is refused. Two fields are lost together here, not one: the invoice transaction code (KSA-2), the seven character code such as 0100000, is the name attribute on this same element, so it cannot be present either while the element is absent.
What to check in your ERP
Check the mapping in your e-invoicing module: the document type belongs in the text content of cbc:InvoiceTypeCode - 388 for a tax invoice, 381 for a credit note, 383 for a debit note - and the invoice transaction code must be written as the name attribute on the same element. Common causes are an export template built for one document type and reused for another that was never mapped, a mapping that writes the element only when a lookup in the document type table succeeds and skips it silently when it does not, and a field suppressed because it was read as optional. Confirm the element is emitted for every document type your system issues, not only for the standard invoice.
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((exists(cbc:InvoiceTypeCode) and (cbc:InvoiceTypeCode) !='') or (exists(cbc:CreditNoteTypeCode) and (cbc:CreditNoteTypeCode) !=''))
Reported test
(exists(cbc:InvoiceTypeCode) and (cbc:InvoiceTypeCode) !='') or (exists(cbc:CreditNoteTypeCode) and (cbc:CreditNoteTypeCode) !='')
Evaluated against
/ubl:Invoice | /cn:CreditNote
Source
vendor/zatca/schematron/CEN-EN16931-UBL.xsl:657
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
<cbc:IssueDate>2026-09-01</cbc:IssueDate><cbc:IssueTime>10:00:00</cbc:IssueTime>+A document that passed: <cbc:InvoiceTypeCode name="0100000"> 388 </cbc:InvoiceTypeCode><cbc:DocumentCurrencyCode>SAR</cbc:DocumentCurrencyCode><cbc:TaxCurrencyCode>SAR</cbc:TaxCurrencyCode>