A solution provider produces your XML: what to ask for and what to check

Product names identify the systems only. Mutabiq is independent of their vendors and is not affiliated with or endorsed by any of them.

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

  • The document ZATCA judges is the XML the provider’s solution generates, signs and sends; the portal, the PDF and the spreadsheet are views of it. The published Implementation Resolution describes each e-invoicing solution unit as keeping its own invoice counter and its own certificate, which is why the counter and the hash in the XML belong to the provider’s unit and not to your invoice numbering (E-Invoicing Implementation Resolution).
  • The provider’s mapping decides what goes into every element: your company record becomes the seller block, your customer list the buyer block, your tax codes the VAT categories. A finding on the XML is therefore a question for the provider’s mapping as often as for your data, and the report names the element either way.
  • ZATCA publishes the law, the regulation and the resolution the requirements come from on one page (Laws and Regulations); the rule pages this guide links quote the clause each check mirrors.

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 a provider?

This guide names no vendor, so it names no menu or button: ask your provider. A portal may list each document with its clearance or reporting status and let you view or download its XML there; where yours does not, ask the provider’s support for the UBL XML of the document exactly as it was sent to ZATCA, or for a PDF/A-3 that carries it. Ask for a month’s documents as one ZIP if you want to check a period at once: Mutabiq reads an archive of XML files as a batch.

If the provider cannot give you the file, Mutabiq has nothing to check: what it checks is the file. A status screen that says “reported” or “cleared” is the Authority’s answer for that document and needs no second check; the file is worth checking when a document was refused, when a warning was returned, or before a mapping change goes live.

What to check in the provider’s XML

  • The seller block, which the provider builds from your company record: confirm cac:PartyTaxScheme/cbc:CompanyID is the 15 digits alone, beginning and ending in 3 (MTB-BR-KSA-40 reports an empty one); that cac:PartyIdentification/cbc:ID carries a schemeID such as CRN (MTB-BR-KSA-08); and that cbc:StreetName under the seller’s cac:PostalAddress is present (MTB-BR-KSA-09).
  • The document type, which the provider maps from yours: confirm cbc:InvoiceTypeCode is 388, 381 or 383 (MTB-BR-KSA-05) with a name attribute beginning 01 on a tax invoice and 02 on a simplified one (MTB-STRUCT-01).
  • The counter and the hash, which are the provider’s unit’s: confirm the ICV and PIH document references are present (MTB-BR-KSA-33 and MTB-BR-KSA-61); across a month’s files the counter should climb by one per document from the same unit.
  • The buyer block on a tax invoice, which the provider builds from your customer list: confirm the buyer’s cac:PartyTaxScheme/cbc:CompanyID is the 15 digits alone (MTB-BR-KSA-44) and that a Saudi buyer’s cac:PostalAddress carries its street name (MTB-BR-KSA-63): both are per customer, so expect them on some documents and not others.
  • The totals, which the provider computes: confirm the cac:TaxTotal block that carries the VAT breakdown also carries its own cbc:TaxAmount (MTB-BR-CO-14).

What to send back to the provider is the report: the CSV export lists every finding with its rule id, the element’s path and the rule’s page, which is what their integrator needs to find the mapping line. Nothing in it is an invoice value.

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 pages were read on 2026-10-15. Published documents are revised.

Rules to read

The rule pages this guide links, in the order they appear above. Each one quotes the published clause, says what Mutabiq reports, and names what to check in your e-invoicing mapping.

Check an invoice

Check a sample invoice in the browser