Saudi Arabia ZATCA Tax Invoice (UBL)
Saudi e-invoice: ZATCA tax invoice (FATOORA, UBL)
A Saudi tax invoice (B2B) for FATOORA, checked against the UBL 2.1 schema and the rules of ZATCA's SDK: EN 16931 as ZATCA adapts it and the KSA rules.
About
Saudi e-invoicing (FATOORA) has been in force since 4 December 2021, when businesses started to generate and keep invoices electronically. Since 1 January 2023, its second phase connects their systems to ZATCA's FATOORA platform, in waves by revenue. Invoices are UBL 2.1 XML.
A tax invoice, usually issued by one business to another, has InvoiceTypeCode 388 (381 for a credit note, 383 for a debit note, 386 for a prepayment) with a name starting 01. ZATCA validates it against the UBL schema, a subset of the EN 16931 rules and the KSA rules (BR-KSA-*), which override EN 16931 where they differ.
E-invoicing in Saudi Arabia: the rules in short and how to check an invoice →
Good to know
- Rules run only when the document matches the schema. Documents over 50 MB are checked against the schema only.
- The rules are the two stylesheets of ZATCA's SDK 3.4.6: its copy of the EN 16931 rules and the KSA rules (20210819_ZATCA_E-invoice_Validation_Rules), both under the LGPL.
- The schema is UBL 2.1 with one change: the certificate serial number in the signature (X509SerialNumber) is read as an integer of any length. libxml2 reads integers of up to 24 digits, and ZATCA's certificates have longer serial numbers.
- ZATCA's SDK also checks the signature, the QR code and the invoice hash; those are not checked here, and clearance happens on the FATOORA platform.
- The example is the standard tax invoice of ZATCA's SDK 3.4.6, as phive-rules keeps the SDK's samples.
Files
14 files · 2.7 MB · Download all (.zip)-
maindoc/UBL-Invoice-2.1.xsd main
-
common/UBL-CommonAggregateComponents-2.1.xsd
-
common/UBL-CommonBasicComponents-2.1.xsd
-
common/UBL-CommonExtensionComponents-2.1.xsd
-
common/UBL-QualifiedDataTypes-2.1.xsd
-
common/UBL-UnqualifiedDataTypes-2.1.xsd
-
common/UBL-ExtensionContentDataType-2.1.xsd
-
common/CCTS_CCT_SchemaModule-2.1.xsd
-
common/UBL-CommonSignatureComponents-2.1.xsd
-
common/UBL-SignatureAggregateComponents-2.1.xsd
-
common/UBL-SignatureBasicComponents-2.1.xsd
-
common/UBL-xmldsig-core-schema-2.1.xsd
-
common/UBL-XAdESv132-2.1.xsd
-
common/UBL-XAdESv141-2.1.xsd
The validator loads all of these with their folder structure, so includes and imports resolve as published.
Business rules
Schematron · run in this order-
ZATCA e-invoicing rules (Saudi Arabia) SDK 3.4.6
The rules run after the schema check, only when the document matches the schema, and in your browser like the schema check (with SaxonJS by Saxonica). Each finding names its rule, such as BR-CO-15, and the line it points at; each rule has a page with what it checks.
Example document
sa-zatca-tax-invoice.xml · 13.8 KB · passes the schema and the rules
In CI and from code
The same schema by its name, sa-zatca-tax-invoice, through the API.
npx @xmlvalid/cli validate "**/*.xml" --schema sa-zatca-tax-invoice- uses: xmlvalid/validate-action@v1
with:
files: "**/*.xml"
schema: sa-zatca-tax-invoice
api-key: ${{ secrets.XMLVALID_API_KEY }}curl https://xmlvalid.com/api/v1/validations \
-H "Authorization: Bearer $XMLVALID_API_KEY" \
-F document=@sa-zatca-tax-invoice.xml \
-F schema=sa-zatca-tax-invoiceFree accounts get 100 API validations a month. On Pro, a URL monitor can check a published document against this schema every hour and email you when it breaks. More CI setups