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-06.
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 6 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 Advisory level. A finding under this rule is Mutabiq's own check, not a rule ZATCA runs.
Reported at
Advisory
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 invoice hash
Reported asmtb_qr_06.tag_absentthe field is absent from the QR code
What is wrong
The QR code decoded from this invoice has no field for the hash of the XML invoice, which is tag 6. Tags 6 to 9 exist only on a signed document, so on an unsigned one their absence is expected and this note is advisory: it does not affect the result.
What to check in your ERP
Nothing needs changing if this document was not meant to be signed. If it was, the hash and the signature fields are written by the signing step of your e-invoicing module, so this points at signing not having run rather than at the QR generator. Mutabiq does not verify the signature chain and does not recompute the hash; it reports only which of these fields the QR carries.
QR code invoice hash is empty
Reported asmtb_qr_06.tag_emptythe field is empty in the QR code
What is wrong
The QR code decoded from this invoice carries the invoice hash field, tag 6, with no value in it. Tags 6 to 9 exist only on a signed document. This note is advisory and does not affect the result.
What to check in your ERP
The field is being written and the value is not, which normally means the QR is assembled from a fixed template of nine fields while the signing step that fills the last four has not run or has not returned a hash. Mutabiq does not verify the signature chain and does not recompute the hash; it reports only which of these fields the QR carries.
QR code invoice hash is not the shape of a SHA-256 digest
Reported asmtb_qr_06.not_a_sha256not the shape of a SHA-256 digest
What is wrong
The QR code carries a value in the invoice hash field, tag 6, but it is neither 32 raw bytes nor 44 characters of base64 that decode to 32 bytes - the two forms a SHA-256 digest takes in a ZATCA QR code. This note is advisory and does not affect the result. Mutabiq does not recompute the hash, so this says the value is the wrong shape and nothing about whether it is the right digest.
What to check in your ERP
The hash is written by the signing step of your e-invoicing module. A value of the wrong length usually means a different digest algorithm was configured, or the digest was written as hexadecimal text rather than as bytes or base64. Check the algorithm and the encoding the signing step uses; both are set once and rarely revisited.
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 6.
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.