Phone app: is there a ZATCA XML to check?

The file Mutabiq needs

Mutabiq checks the e-invoice itself: the UBL 2.1 XML generated for each invoice, credit note and debit note under Phase 2 of e-invoicing with the Zakat, Tax and Customs Authority (ZATCA), whether your system generates it or an e-invoicing add-on or integration connected to it does. A PDF with the invoice XML embedded in it (PDF/A-3) works as well. A PDF without that XML, a printout, a spreadsheet export or a screenshot carries nothing Mutabiq can check.

What the published requirements say

A simplified invoice is the one an individual buyer gets. The published Implementation Resolution has it given to the buyer as a printed copy, and ZATCA’s FAQ has the QR code as mandatory on it (E-Invoicing Implementation Resolution; E-Invoicing FAQ). So a PDF with a QR code and no XML inside it is a lawful copy of a simplified invoice. It is also a copy with nothing in it for Mutabiq to check: the check is on the XML the app generated and reported, which stays inside the app’s service.
The same resolution describes each e-invoicing solution unit as keeping its own invoice counter and certificate. In an app, that unit is the app’s own service, so the counter and the hash are the app’s, and a finding on them is the app maker’s to answer.
If the app gives you the XML, or a PDF/A-3 with the XML inside it (what Mutabiq checks in a PDF), Mutabiq can check it. Whether it does is for the app’s own documentation or support to say; this page names no app and claims nothing about any.

Where the file usually is

Where the XML is kept depends on how your system is connected to ZATCA, not only on which system it is, and this guide names a screen or menu only where the vendor's own documentation states it, cited and dated. The usual places to look:

The e-invoicing or ZATCA section of your system, or of the add-on that handles e-invoicing for it, which may list each document with its status and let you view or download its XML.
The portal of your e-invoicing solution provider, if a provider sends your documents to ZATCA for you: the XML is often kept there beside each document’s clearance or reporting result.
An export or download of the document after it was cleared or reported, sometimes packaged with the PDF sent to the customer.
Your provider or implementer. If none of these shows the file, ask for the UBL XML of the document exactly as it was generated for ZATCA.

Check the file as your system generated it. A copy opened and saved again in another program may no longer be the file ZATCA receives.

Where do I get the XML file from an app?

This guide names no app, so it names no menu or button: look in the app for an export, a download or a share option on the invoice that offers XML, and if there is none, ask the app’s support for the invoice’s XML exactly as it was sent to ZATCA, or for a PDF/A-3 that carries it. If the app gives only the PDF with the QR code, there is no file to check and nothing is wrong with that: the invoice is reported by the app, and its answer from the Authority is the app’s to show you.

What to check in the XML, if you have it

Your own data, which the app takes from its settings: confirm the seller’s cac:PartyTaxScheme/cbc:CompanyID is the 15 digits alone, beginning and ending in 3 (MTB-BR-KSA-40 reports an empty one), and that cbc:StreetName under the seller’s cac:PostalAddress is present (MTB-BR-KSA-09): an address typed as one line is the usual cause, and those two are the fields you can change yourself.
The simplified-invoice shape, which the app decides: confirm cbc:InvoiceTypeCode carries a name attribute beginning 02 (MTB-STRUCT-01), that the QR document reference is present with a non-empty base64 payload (MTB-BR-KSA-27), and that the cac:Signature block is present (MTB-BR-KSA-60).
The counter and the hash, which are the app’s: confirm the ICV and PIH document references are present (MTB-BR-KSA-33 and MTB-BR-KSA-61).

Apart from your name, VAT number and address, nothing here is yours to fix: send the report to the app’s support with the rule id and the element’s path. The share button under the report sends it from the phone.

What to do with the findings

Fix the source, not the file. Each finding names an element of the XML, and the value in it came from your system: a setting, a master record such as the company, the customer, the item or the tax code, or the mapping that writes the XML. Correct it there, so the next document is generated right.
Do not edit the XML by hand and send the edited copy. The file that goes to ZATCA is the one your system generates and signs, and an edited copy is not that file.
Where the mapping itself is wrong, take the finding to whoever maintains your e-invoicing: the ERP vendor, the add-on or integration provider, or your implementer. The rule id, the element’s path and the rule’s page are what they need to find it.
A document that has already been cleared or reported is not corrected by sending it again. Ask your accountant or provider how your system corrects it; usually that is a credit or debit note and, where needed, a new document.
Once the source is fixed, check the next file your system generates.

Sources

Both documents were read on 2026-10-15. Published documents are revised.

A phone invoicing app: is there a file to check?