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, MTB-QR-01.
Five checks a month on the Free plan. The file is checked in memory and is never stored.
No published ZATCA clause
No clause in ZATCA's published validation rules decodes the QR code's payload, so there is no clause for this page to quote. Mutabiq reads field 1 of the payload as ZATCA's Security Features Implementation Standards, version 1.2, section 4.1, table 3, lays it out, and reports what it finds there at the Warning level. A finding under this rule is Mutabiq's own check, not a rule ZATCA runs.
Reported at
Warning
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.
QR code carries no seller name
Reported asmtb_qr_01.tag_absentthe field is absent from the QR code
What is wrong
The QR code decoded from this invoice has no field for the seller name, which is tag 1 and is mandatory on every Phase 2 QR code. Nothing in the published ZATCA rule set decodes the QR payload, so this is reported as a risk rather than as a rejection - but a QR code missing a mandatory field is a real defect and a customer scanning it will not see who issued the invoice.
What to check in your ERP
The QR payload is built from five mandatory fields in order: seller name, VAT registration number, timestamp, total including VAT, and VAT amount. A missing tag 1 usually means the generator was given no seller name to write rather than that it skips the field. Check the seller name reaching the QR generator, which in some systems is a separate configuration item from the name written into the invoice XML.
QR code seller name is empty
Reported asmtb_qr_01.tag_emptythe field is empty in the QR code
What is wrong
The QR code decoded from this invoice carries the seller name field, tag 1, with no value in it. The field is mandatory on every Phase 2 QR code. Nothing in the published ZATCA rule set decodes the QR payload, so this is reported as a risk rather than as a rejection.
What to check in your ERP
The generator is writing the field and being given nothing to put in it, which points at the source of the value rather than at the QR step. Check the seller name held against the issuing entity, and whether the QR generator reads it from the same place the invoice XML does - the two are separate settings in some systems, and an empty one here often means the QR is configured against a branch record that was never filled in.
QR code seller name differs from the invoice
Reported asmtb_qr_01.mismatchdiffers from the invoice
What is wrong
The seller name in the QR code, tag 1, is not the seller name written in the invoice XML. The two describe the same invoice and must agree: a customer scanning the QR sees the name it carries, not the one in the XML. Nothing in the published ZATCA rule set decodes the QR payload, so this is reported as a risk rather than as a rejection.
What to check in your ERP
The comparison ignores differences in surrounding and repeated whitespace, so the two values genuinely differ. The usual cause is two sources for one name: the QR generator reading a company setting while the XML mapping reads the branch or legal entity record, or one of the two carrying a trading name where the other carries the registered one. Point both at the same field. A name that differs only in its Arabic form - with and without diacritics, or one written in English - is the same defect.
The fields of the QR code's payload
The nine fields ZATCA's Security Features Implementation Standards, version 1.2 lays out, in order, each with the rule that reads it. This page is about field 1.
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.