Oracle NetSuite: 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 NetSuite documents

• Oracle documents ZATCA e-invoicing for NetSuite as an Oracle extension installed into NetSuite, so the XML is generated inside NetSuite once that extension is in place (Saudi Arabia E-Invoicing).
• Its documentation reads the seller’s details from the subsidiary, or from a location where one is chosen on the transaction, and the buyer’s from the customer (Subsidiary; Location; Customer). A seller value that looks right in one of those records may still be wrong in the XML, because the document was built from the other.
• It says the generated XML is emailed to the customer with the PDF (Generating and Sending the Outbound E-Document of a Transaction).

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.

What to check in the exported XML

• The name attribute of cbc:InvoiceTypeCode is seven, eight or nine characters: 01 for a tax invoice or 02 for a simplified one, then five flags for third party, nominal, export, summary and self-billed, and up to two more for continuous supply and government, each 0 or 1. Confirm the attribute has no separator; MTB-STRUCT-01 reports it.
• 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 that the document was built from the subsidiary or location you expect; MTB-BR-KSA-40 reports the shape.
• Each party’s identifier is read from cac:PartyIdentification/cbc:ID and its schemeID attribute. Confirm the seller’s scheme is one of CRN, MOM, MLS, SAG, OTH or 700, and the buyer’s one of the eleven ZATCA accepts (which add NAT, TIN, IQA, PAS and GCC); MTB-BR-KSA-08 reports the seller’s and MTB-BR-KSA-14 the buyer’s.
• The address is read from cbc:StreetName, cbc:BuildingNumber, cbc:CityName, cbc:PostalZone, cbc:CitySubdivisionName (the district) and cac:Country/cbc:IdentificationCode. Confirm all six are present on the seller, reported by MTB-BR-KSA-09, and on a Saudi buyer on a tax invoice, reported by MTB-BR-KSA-63, both at WARNING.
• On every 381 and 383, confirm cac:PaymentMeans/cbc:InstructionNote carries the reason for the note, reported by MTB-BR-KSA-17, and cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID names the invoice it corrects, reported by MTB-BR-KSA-56.
• On a zero-rated or exempt breakdown, confirm cac:TaxSubtotal/cac:TaxCategory/cbc:TaxExemptionReasonCode is one of the published VATEX-SA- values; MTB-BR-KSA-CL-04 reports an unlisted code, at WARNING. ZATCA’s current checker asks for the code only, not for the reason text beside it.
• On a tax invoice, confirm cac:PaymentMeans/cbc:PaymentMeansCode is present and the code is on ZATCA’s list; MTB-BR-KSA-16 reports it.
• Confirm the ICV reference’s cbc:UUID is a plain integer that increments across every document the unit issues, and that the PIH reference carries a non-empty base64 value declared text/plain.
• Confirm the document-level cac:TaxTotal/cbc:TaxAmount equals the sum of the cac:TaxSubtotal/cbc:TaxAmount values under it, that every amount is written with at most two decimal places, and, where a prepayment was deducted, that cbc:PayableAmount equals cbc:TaxInclusiveAmount less cbc:PrepaidAmount.

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

• Oracle Help Center: Saudi Arabia E-Invoicing
• Oracle Help Center: Setting Up a Subsidiary Record
• Oracle Help Center: Setting Up a Customer Record
• Oracle Help Center: Setting Up a Location Record
• Oracle Help Center: Generating and Sending the Outbound E-Document of a Transaction

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