Zoho Books: 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 Zoho Books documents

• Zoho documents its ZATCA Phase 2 e-invoicing as built into Zoho Books, which sends each invoice to the Fatoora platform itself, so the XML is generated inside Zoho Books (Phase-2 e-Invoicing).
• Its help says the XML of an invoice sent this way can be viewed in Zoho Books and is attached with the invoice PDF, which makes that attachment the file to check (Phase-2 e-Invoicing).
• It says a sent invoice cannot be edited or deleted: a correction is a credit or debit note, and both are sent as well (e-Invoicing; e-Invoicing FAQ).

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 Zoho Books?

Zoho’s Saudi help says the XML of a pushed invoice can be viewed in Zoho Books and is attached with the invoice’s PDF (Phase-2 e-Invoicing, read on 2026-10-14), and names no menu or button for either. So take the PDF Zoho Books produces for a pushed invoice: if the XML is inside it, Mutabiq reads it as a PDF/A-3; if it is not, or the invoice has not been pushed, ask Zoho support for the invoice’s XML as sent to the Fatoora platform. Vendor documentation changes: if your Zoho Books offers an XML download, use it.

What to check in the exported XML

• The seller’s address is read from the six elements under cac:AccountingSupplierParty/cac:Party/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; MTB-BR-KSA-09 reports a missing one, at WARNING. The additional number (cbc:PlotIdentification) is no longer among them in ZATCA’s current checker.
• The buyer’s address is read from the same six elements under cac:AccountingCustomerParty. On a standard invoice to a Saudi customer confirm all six, and confirm the country element holds the code SA and not a country name; an address written in two languages still has to leave each element holding one value. MTB-BR-KSA-63 reports the buyer address, at WARNING.
• The buyer’s name is read from cac:AccountingCustomerParty//cac:PartyLegalEntity/cbc:RegistrationName. Confirm a standard invoice carries it non-empty; MTB-BR-KSA-42 reports it missing or empty.
• The buyer’s identifier is read from a buyer cac:PartyIdentification/cbc:ID with a schemeID attribute. Confirm the attribute is one of the eleven ZATCA accepts for the buyer, NAT for a national identity number; MTB-BR-KSA-14 reports anything else.
• The buyer’s VAT number is read from cac:AccountingCustomerParty//cac:PartyTaxScheme/cbc:CompanyID. Confirm it is the 15 digits alone, beginning and ending in 3; customer VAT numbers are keyed by hand, so compare the XML with the customer’s own certificate. MTB-BR-KSA-44 reports another shape.
• On a credit note or debit note, confirm cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID names the invoice being corrected and that cac:PaymentMeans/cbc:InstructionNote carries the reason for the note; MTB-BR-KSA-56 reports the reference and MTB-BR-KSA-17 the reason, and a note raised without selecting the invoice it corrects has nothing to write in either.
• Confirm the document-level cac:TaxTotal/cbc:TaxAmount equals the sum of the cac:TaxSubtotal/cbc:TaxAmount values under it, and that each standard-rated subtotal’s VAT equals its cbc:TaxableAmount times its cbc:Percent; MTB-BR-CO-14 and MTB-BR-S-09 report a mismatch; both rule pages name per-line rounding of VAT before the sum as a cause to check.
• Confirm cbc:InvoiceTypeCode holds the bare code and that its name attribute is seven, eight or nine characters, with a second position of 1 on a standard invoice and 2 on a simplified one; MTB-STRUCT-01 reports the attribute.
• Where sending an invoice failed, check the XML of that invoice rather than of the corrected one: the correction goes out as a new document, and the file you upload for checking should be the file ZATCA will receive.

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

• Zoho Books help (Saudi Arabia): Phase-2 e-Invoicing
• Zoho Books help (Saudi Arabia): e-Invoicing
• Zoho Books (Saudi Arabia): e-Invoicing feature page and FAQ

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