A billing platform feeds a provider: what to ask for and what 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

• The platform’s invoice is not the e-invoice. What ZATCA receives is the XML the provider generates from it, signed by the provider’s solution unit with that unit’s own counter and certificate, as the published Implementation Resolution describes (E-Invoicing Implementation Resolution). The platform’s invoice number, its customer record and its currency reach the XML only through the provider’s mapping.
• ZATCA’s published FAQ says e-invoicing applies to every person subject to VAT in the Kingdom, and that non-residents registered for VAT are outside it (E-Invoicing FAQ). Whether your entity is in scope at all is a question for your adviser, not for this page.
• A standard tax invoice to a Saudi business carries the buyer’s registered name, VAT number and national address; a platform that holds a billing e-mail and a card cannot supply those, so the provider’s mapping has to take them from somewhere else, and that is where the gaps show.

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 this pipeline?

From the provider, not from the billing platform: the platform never had the file. This guide names no vendor, so it names no menu or button: ask the provider’s support for the UBL XML of each document exactly as it was sent to ZATCA, and for a month’s documents as one ZIP, which Mutabiq checks as a batch. If the provider cannot give you the file, Mutabiq has nothing to check: what it checks is the file.

A useful routine is one export per month, checked before the provider’s mapping or the platform’s customer fields change, and the first export after any change. The files are never kept here: the check runs in memory and the report holds rule ids, paths and counts, not invoice values.

What to check in the provider’s XML

• The buyer on every standard invoice: confirm cac:AccountingCustomerParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName carries the customer’s registered legal name and not the account’s display name (MTB-BR-KSA-42); that a Saudi customer’s cac:PartyTaxScheme/cbc:CompanyID is the 15 digits alone, with no prefix the platform stored for display (MTB-BR-KSA-44); that any cac:PartyIdentification/cbc:ID carries a schemeID (MTB-BR-KSA-14); and that a Saudi buyer’s cac:PostalAddress carries its street name (MTB-BR-KSA-63). Each of these is per customer: expect them on some documents and not others.
• The currency, which a platform billing in dollars sets per invoice: confirm cbc:DocumentCurrencyCode is a code ZATCA accepts (MTB-BR-CL-04) and that cbc:TaxCurrencyCode is present with the value SAR on every document (MTB-BR-KSA-68).
• The amounts, which cross a conversion and a second rounding: confirm every VAT amount is written with two decimal places (MTB-BR-DEC-13) and that the cac:TaxTotal block carrying the breakdown also carries its own cbc:TaxAmount (MTB-BR-CO-14).
• Exports and exempt supplies, which the platform’s tax rules decide: confirm every breakdown coded Z or E carries one of the published VATEX-SA- reason codes (MTB-BR-KSA-CL-04).
• Refunds and credits, which the platform raises automatically: confirm each credit note carries a reason in cac:PaymentMeans/cbc:InstructionNote (MTB-BR-KSA-17).

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, so “your XML fails this rule on these documents” is a sentence with evidence behind it. 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

• ZATCA: E-Invoicing Implementation Resolution (English, 2023-05-19)
• ZATCA: E-Invoicing FAQ (English, 2021-06-10)

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