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-04.
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 4 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 invoice total
Reported asmtb_qr_04.tag_absentthe field is absent from the QR code
What is wrong
The QR code decoded from this invoice has no field for the total including VAT, which is tag 4 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 the total is what a customer scanning it is most likely to check.
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. Tag 4 is the tax inclusive amount, the same figure as cbc:TaxInclusiveAmount in cac:LegalMonetaryTotal. A missing tag 4 usually means the generator ran before the document totals were computed.
QR code invoice total is empty
Reported asmtb_qr_04.tag_emptythe field is empty in the QR code
What is wrong
The QR code decoded from this invoice carries the total including VAT field, tag 4, 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 normally means the QR is built at a point in the document's life where the totals are not yet set. Move QR generation after the totals are computed, and confirm it reads cbc:TaxInclusiveAmount rather than a separate running total.
QR code invoice total differs from the invoice
Reported asmtb_qr_04.mismatchdiffers from the invoice
What is wrong
The total including VAT in the QR code, tag 4, is not the tax inclusive amount written in the invoice XML. The two are compared as numbers, so 115.0 and 115.00 are treated as the same amount - the difference here is a difference in value. A customer scanning the QR is shown a total the invoice does not state. 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 two figures are coming from different places or being computed at different moments: a QR built before a discount, a rounding adjustment or a delivery charge was applied, or one figure taken from the order and the other from the posted document. Point the QR generator at cbc:TaxInclusiveAmount in cac:LegalMonetaryTotal and generate it after the document is final.
QR code invoice total cannot be read as a number
Reported asmtb_qr_04.not_a_decimalcannot be read as a number
What is wrong
The QR code carries a value in the total including VAT field, tag 4, but it is not a plain decimal number, so it could not be compared with the invoice. 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
Tag 4 holds the amount as digits with an optional decimal point and nothing else - for example 1150.00. A currency code or symbol, a thousands separator, Arabic-Indic digits, or a value in scientific notation will not read. This normally comes from a generator that formats the amount for display; write the raw amount instead, the same value that goes into cbc:TaxInclusiveAmount.
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 4.
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.