Daftra: checking the ZATCA e-invoice XML

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 Daftra documents

• Daftra’s user manual describes its Phase 2 link with ZATCA as part of Daftra, with each branch linked separately and a trial link to the Fatoora simulation environment offered before the live one. So the XML is generated inside Daftra, per branch, and a document from the trial link is not the document ZATCA receives from the live one (Linking Phase 2 and sending invoices to ZATCA).
• Daftra’s release notes say a customer’s commercial register and tax number are saved on each invoice when it is created, so a later change to the customer does not alter invoices created before it (System updates). Correcting a customer’s data fixes the next invoice, not one already issued.
• Daftra’s guide on rounding says VAT summed line by line can differ from VAT computed on the invoice total (Rounding in tax calculation).

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 in Daftra?

Daftra does not publish a path. On 2026-10-14 its Phase 2 manual (Linking Phase 2 and sending invoices to ZATCA) covered enabling the e-invoicing app, the trial and final link with the Fatoora platform, the OTP, sending invoices and their statuses, and nothing about viewing, downloading or exporting an invoice’s XML; the one XML-export tutorial in its knowledge base belongs to its UAE app and does not apply to a Saudi account. Ask Daftra support for the invoice’s XML exactly as it was sent to ZATCA, or for a PDF/A-3 that carries it, and check that file. Vendor documentation changes: if your Daftra offers an XML download, use it.

What to check in the exported XML

• The seller’s VAT number is read from cac:PartyTaxScheme/cbc:CompanyID. Confirm it is the 15 digits alone, beginning and ending in 3, and confirm which branch’s number was written when a branch other than the main one issued the document; MTB-BR-KSA-40 reports the seller’s number.
• The buyer’s VAT number is read from the buyer’s cac:PartyTaxScheme/cbc:CompanyID, and a commercial-register or other identifier from a buyer cac:PartyIdentification/cbc:ID with a schemeID. Confirm the VAT number is 15 digits beginning and ending in 3, and that the identification carries a schemeID from the list ZATCA accepts for the buyer; MTB-BR-KSA-44 reports the number and MTB-BR-KSA-14 the identification.
• The national address is read from the six elements under cac:PostalAddress: cbc:StreetName, cbc:BuildingNumber, cbc:CityName, cbc:PostalZone, cbc:CitySubdivisionName (the district) and cac:Country/cbc:IdentificationCode. Confirm all six are present and non-empty on the seller, reported by MTB-BR-KSA-09, and on a Saudi buyer on a standard invoice, reported by MTB-BR-KSA-63, both at WARNING. A single address line written into cbc:StreetName leaves the other five empty.
• Totals. ZATCA’s check on the document total, MTB-BR-CO-14, compares cac:TaxTotal/cbc:TaxAmount with the sum of the cac:TaxSubtotal/cbc:TaxAmount values exactly, with no tolerance, while the per-category check MTB-BR-S-09 allows a small band. Confirm the header VAT total was written as the sum of the breakdown and not recomputed on the invoice total.
• Where a prepayment was deducted, it is read from cbc:PrepaidAmount in the totals. Confirm cbc:PayableAmount equals cbc:TaxInclusiveAmount less that prepaid amount; MTB-BR-CO-16 reports a payable amount carried straight from the total with the prepayment left out.
• Confirm every VAT amount is written with at most two decimal places, including the cac:TaxTotal/cbc:TaxAmount inside each cac:InvoiceLine; a per-line VAT computed to more places and written as stored is what MTB-BR-DEC-13 reports.
• Confirm cbc:InvoiceTypeCode holds 388, 381 or 383 and that its name attribute is seven, eight or nine characters, beginning 01 on a tax invoice and 02 on a simplified one; MTB-STRUCT-01 reports the attribute.
• Confirm the ICV reference’s cbc:UUID is a plain integer that increments across every document the branch issues, and that the PIH reference carries a non-empty base64 value declared text/plain, on the first document of each branch’s chain as well.

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

• Daftra user manual: ربط المرحلة الثانية للفاتورة الإلكترونية وإرسال الفواتير لهيئة الزكاة
• Daftra user manual: التقريب في حساب الضريبة
• Daftra: system updates

These pages were read on 2026-09-11. Vendor documentation changes.