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-03.
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 3 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 timestamp
Reported asmtb_qr_03.tag_absentthe field is absent from the QR code
What is wrong
The QR code decoded from this invoice has no field for the invoice timestamp, which is tag 3 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.
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 3 carries the date and time of issue together, taken from cbc:IssueDate and cbc:IssueTime. A missing tag 3 usually means the generator was given a date with no time, or nothing at all, and wrote no field rather than a partial one.
QR code timestamp is empty
Reported asmtb_qr_03.tag_emptythe field is empty in the QR code
What is wrong
The QR code decoded from this invoice carries the timestamp field, tag 3, 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. Tag 3 is the date and time of issue together, so check that both cbc:IssueDate and cbc:IssueTime are populated at the moment the QR is generated - a QR built before the issue time is stamped will have nothing to write.
QR code timestamp differs from the invoice
Reported asmtb_qr_03.mismatchdiffers from the invoice
What is wrong
The date and time in the QR code, tag 3, are not the issue date and issue time written in the invoice XML. The two describe the same invoice and must agree. The comparison uses the date and the wall clock time only and ignores the time zone designator, so the difference here is in the date or in the hours, minutes or seconds. 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 usual cause is the two values being taken at different moments or in different zones: the QR generated when the document is created and the XML stamped when it is posted, or one converted to UTC while the other stays local. Take both from one timestamp captured once. A difference of exactly three hours is the Kingdom's offset from UTC and points at a conversion applied to one side only.
QR code timestamp cannot be read as a date and time
Reported asmtb_qr_03.not_a_timestampcannot be read as a date and time
What is wrong
The QR code carries a value in the timestamp field, tag 3, but it is not in a form that can be read as a date and time, 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 3 is written as the date, then T, then the time on a 24-hour clock - for example 2026-09-08T14:30:00. A local format such as 08/09/2026 or a time with no date will not read. This normally comes from a generator that formats the timestamp for display rather than for the QR; check the format string it uses.
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 3.
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.