Sample batch report

The cbc:TaxInclusiveAmount in cac:LegalMonetaryTotal is not the cbc:TaxExclusiveAmount plus the sum of the VAT breakdown amounts. EN 16931 rule BR-CO-15, which ZATCA runs, adds the tax-exclusive total to the cbc:TaxAmount of every cac:TaxSubtotal, rounds the result to two decimals and requires an exact match.

The cbc:TaxExclusiveAmount in cac:LegalMonetaryTotal is not the line total plus the charge total less the allowance total. EN 16931 rule BR-CO-13, which ZATCA runs, checks whichever of those two optional totals your document carries, rounds the result to two decimals and requires an exact match. One case is stricter than the rest and catches people out: when the document has neither a charge total nor an allowance total, ZATCA requires the tax-exclusive amount to equal the line total with no rounding applied at all - so a line total written as 100.001 against a tax-exclusive amount of 100.00 fails, where in every other branch it would have been rounded first.

Two or more members of the uploaded archive carry the same invoice counter value (KSA-16) under the same seller VAT registration number, and this note is on each of them. ZATCA's E-Invoicing Detailed Guideline (Annex 2 of the E-Invoicing Resolution) describes the counter as a tamper-resistant sequence that cannot be reset and increments for each invoice or note issued; the XML Implementation Standard itself requires only that the counter is present and written in digits. In Mutabiq's reading, the counter belongs to the e-invoicing solution that issues the documents, so two solutions of one seller can carry the same numbers, while one solution cannot repeat one. If these files come from different devices, this is expected. This is reported as a risk rather than as a rejection: ZATCA's published rules read one document at a time and check only that a counter is present, so no assertion sees the repeat. While a value is repeated, Mutabiq does not judge the previous invoice hash link into it or out of it, because there is no single document before or after it.

The seller VAT registration number (BT-31), in cbc:CompanyID under the seller's VAT tax scheme, is not exactly 15 digits. ZATCA rejects it under BR-KSA-40, which requires 15 digits and nothing else - too few, too many, or any character that is not a digit all fail the same test.

Two or more members of the uploaded archive carry the same invoice counter value (KSA-16) under the same seller VAT registration number, and this note is on each of them. ZATCA's E-Invoicing Detailed Guideline (Annex 2 of the E-Invoicing Resolution) describes the counter as a tamper-resistant sequence that cannot be reset and increments for each invoice or note issued; the XML Implementation Standard itself requires only that the counter is present and written in digits. In Mutabiq's reading, the counter belongs to the e-invoicing solution that issues the documents, so two solutions of one seller can carry the same numbers, while one solution cannot repeat one. If these files come from different devices, this is expected. This is reported as a risk rather than as a rejection: ZATCA's published rules read one document at a time and check only that a counter is present, so no assertion sees the repeat. While a value is repeated, Mutabiq does not judge the previous invoice hash link into it or out of it, because there is no single document before or after it.

The seller's postal address carries no cbc:CitySubdivisionName element, which ZATCA's message calls the Neighborhood (KSA-3). BR-KSA-09 asks for six fields on the seller's postal address, cac:AccountingSupplierParty/cac:Party/cac:PostalAddress: street name (BT-35, cbc:StreetName), building number (KSA-17, cbc:BuildingNumber), city (BT-37, cbc:CityName), postal code (BT-38, cbc:PostalZone), neighbourhood (KSA-3, cbc:CitySubdivisionName) and country code (BT-40, cac:Country/cbc:IdentificationCode). This is reported as a risk and not as a rejection. Under the SDK release the pack read before 2.0.0 (3.0.8), this was the one assertion ZATCA flagged as a warning rather than as an error; SDK 3.4.8, which the pack reads now, flags most of its assertions as warnings, and BR-KSA-09 stays among them: the platform records the shortfall and does not refuse the document for it, so this note does not turn the report to FAIL on its own. SDK 3.0.8 also asked for the additional number (KSA-23, cbc:PlotIdentification); SDK 3.4.8 does not (KSA:1216). The Data Dictionary marks the address subfields mandatory, and that does not change the flag the checker carries. The check is presence only - an empty element satisfies it - and it stops at the first field missing in ZATCA's own order (street name, building number, city, postal code, neighbourhood, country code), so more than one of the six may be absent and only the first is named here. It applies to standard and simplified invoices alike.

Two or more members of the uploaded archive carry the same invoice counter value (KSA-16) under the same seller VAT registration number, and this note is on each of them. ZATCA's E-Invoicing Detailed Guideline (Annex 2 of the E-Invoicing Resolution) describes the counter as a tamper-resistant sequence that cannot be reset and increments for each invoice or note issued; the XML Implementation Standard itself requires only that the counter is present and written in digits. In Mutabiq's reading, the counter belongs to the e-invoicing solution that issues the documents, so two solutions of one seller can carry the same numbers, while one solution cannot repeat one. If these files come from different devices, this is expected. This is reported as a risk rather than as a rejection: ZATCA's published rules read one document at a time and check only that a counter is present, so no assertion sees the repeat. While a value is repeated, Mutabiq does not judge the previous invoice hash link into it or out of it, because there is no single document before or after it.