Integrating with ZATCA's Fatoora platform looks small on a slide: sign the invoice, send it for clearance, store the response. In a real business it is rarely one system talking to one platform.
The invoice is assembled, not stored
A compliant invoice needs the buyer's VAT registration, the correct tax category per line, a cryptographic stamp, a QR code, and a UUID that ties it to the previous invoice in the chain. Those fields live in different places - the CRM, the ERP, a pricing service, a contract system. The clearance call is the easy part. Gathering a correct invoice from four systems that were never designed to agree is the work.
Clearance is synchronous, and things fail
Standard tax invoices must be cleared before they reach the buyer. That puts a network call to a government platform on your critical path. You need a queue, idempotent retries, a dead-letter path a human can inspect, and a clear rule for what the user sees while an invoice is mid-clearance. Skipping this is how a Fatoora outage becomes your outage.
Every upstream system is another integration
Add a new sales channel, a new billing plan, or a new subsidiary and you have another feed into the invoice pipeline, each with its own data quirks. This is the point where e-invoicing stops being a project with an end date and becomes a permanent tax on the team.
What we would put in writing
A map of every system that contributes a field to an invoice; a signing-and-clearance service with retries, monitoring and an audit trail for every document; and a test suite that runs against ZATCA's sandbox on every deploy. Scope, timeline and price agreed before the work starts.