Saudi Arabia E-Invoicing: ZATCA Phase 2 and FATOORA

A tax invoice in Saudi Arabia is no longer a document the seller issues and the buyer files away. Under ZATCA Phase 2, the tax authority checks the invoice as part of the sale. The platform behind that check is FATOORA. For a company that bills from an ERP, this turns a print step into an integration.

What the Rule Asks of Your Systems

The invoice must exist as structured data, not as a PDF alone. The seller's system sends it in the required format. The authority validates it before it is legally issued. A valid invoice carries a cryptographic stamp, and the authority's response is part of the record.

This is clearance, not a monthly report. The invoice, the stamp and the response form one chain that an auditor can follow. The rule is therefore a systems rule as much as a tax rule. It asks where invoice data is created, how it is validated, who signs it, what happens when a check fails and how the evidence is stored.

The authority publishes the current timetable and the taxpayers each phase covers. Check that timetable with ZATCA or your tax adviser. The date that matters is the one in force for your business, not a date in a slide from last year.

Where ERP Projects Get Stuck

Most failures are not in the tax logic. They sit between the ERP and the platform. The same problems appear on project after project.

• The invoice is assembled by a report or a batch job, so it reaches the platform late.

• Custom fields do not map cleanly to the required schema, and the rejection reason is vague.

• A timeout is retried, and the same invoice is submitted twice.

• The ERP marks an invoice as posted while the authority rejects it.

• A key or certificate expires without an owner, and the connection stops.

• The team handles rejections in a mailbox, so the evidence is incomplete.

Each of these is an integration concern. The fix is a written mapping, a validation step before submission, an idempotent key for each invoice, an exception queue with a person responsible, and monitoring for every response.

What to Do First

Start with an inventory. List every invoice type you issue, every legal entity and every channel that creates an invoice. For each one, write down the data fields, the format the platform expects and the point in the process where the invoice becomes legally issued.

Then build one flow in a sandbox. Send a real invoice through the connector, read the response and store both. Test the failure cases as carefully as the happy path: a rejected field, a timeout, a duplicate, an expired certificate. The flow is ready when a failure is visible, explained and replayable.

Keep the mapping under version control. Tax rules and platform interfaces change, and the mapping is the part your team will need to update. A documented contract makes that change small. Keep keys and certificates in your key vault or hardware security module, never in code, and give someone the job of watching their expiry.

Reconcile the tax platform with the ledger every day. If an invoice is cleared but not posted, or posted but not cleared, the difference should appear before month end. That daily check is what turns a connector into a control.

What Good Looks Like

A cleared invoice leaves the ERP once and appears in the platform once. The stamp and the response are stored with the invoice. A rejection names the field that failed, reaches a queue and is replayed after a fix. A dashboard shows submissions, rejections and response times for each legal entity. A certificate alert reaches an owner before expiry. The audit pack is generated from the same records, not rebuilt by hand.

How XSIS Helps

XSIS connects ERPs to tax platforms and keeps the clearance flow observable. We build the invoice mapping, the validation and the exception path, and keep the evidence each submission produces. We do not give legal or tax advice. Your tax and legal teams decide how the rules apply, and we turn those decisions into systems they can check.