Handling invoices when ZATCA is down, without stopping business

When the Authority's platform stops responding, or slows down, the problem is not just a failed API request. Handling invoices when ZATCA is down touches the moment of sale, your tax obligation, revenue close, and finance's ability to prove afterwards what happened. The difference between a containable outage and a costly operational incident is having a defined path: what gets issued, what gets held, what gets resubmitted, and who owns the exception decision.

The practical rule is not to confuse an Authority outage with a failure in your own invoicing layer. The point of sale may be available while clearance or reporting is not. Or the message may succeed at the Authority while the response is cut off before the confirmation reaches your system. Each case has a different consequence, and none of them is served by a blanket "just retry" policy.

What actually broke?

"Platform outage" is a broad term that can hide entirely different operational situations. If the internal invoicing system is running but cannot submit documents to the integration layer, the problem is usually the transport channel, the credentials or the intermediate service. If the invoice reaches the platform and is then rejected, that is not necessarily an availability problem but a validation problem in the data, the structure or the signature — and what rejection means for your record is an entirely different path.

There is also an important difference between the service provider being down and the tax authority's services being down. In the first case, you must be able to find out whether the documents were received and stored in a safe queue. In the second, the platform should keep accepting documents and validating them locally, then defer submission or reporting according to the regulatory scenario that applies to the invoice type.

And do not make a decision on the basis of a generic message like "submission failed". Ask for verifiable indicators: when the incident started, the proportion of failed requests, the kind of response codes, the number of invoices waiting, and the state of the last document the Authority accepted. That data turns an incident from an impression into a reviewable decision.

Start by classifying the outage, not by retrying

Before any invoice moves, the system should determine automatically whether the fault lies in connectivity, authentication, the certificate, signing, document-content validation, or the Authority's own service. A rejection caused by a wrong VAT number or an inconsistent tax total is not a ZATCA outage, and resubmitting it dozens of times fixes nothing. It is a rejected invoice that needs a governed correction with a clear record.

Where there is no response at all, the most sensitive problem appears: did the Authority actually receive the document or not? Neither possibility may be assumed. The invoice must be put into a pending state, keeping the request identifier, the document hash, the submission time, and the technical response if there was one. Then query the status before resubmitting, or use the idempotency mechanism that ties the new attempt to the same document.

In practice an organisation needs four distinct operational states:

1. Accepted and confirmed. The clearance or reporting result is stored and the invoice's status is finalised.
2. Rejected. The invoice leaves the submission path, and the rejection reason is presented in actionable form to finance or the source system.
3. Could not connect before confirmed submission. The invoice enters the retry queue under a controlled timing policy.
4. Timed out after submission. Treated as an unknown-result state, and queried before any further copy is sent.

That separation prevents duplicate invoices, and stops a single timeout message from becoming a manual reconciliation at month end.

The first thirty minutes: protect the record before restoring the service

The first objective is not to turn the status indicator green; it is to prevent invoices being lost, duplicated, or having their sequence broken. Which is why incident procedures have to be defined in advance and owned by a named team.

1. Freeze manual submission and ad-hoc retries. Users should not submit the same invoice from two different systems or regenerate it under a new number. Duplication can produce non-matching documents and complicate financial and tax reconciliation.
2. Locate the point of failure precisely. Examine the document's path from source to queue, then validation, signing or stamping, QR generation, submission to the Authority, and receipt of the result. One stage failing does not necessarily stop the whole path.
3. Establish every document's state. Classify invoices as: not created, created but not queued, awaiting processing, submitted with no final response, accepted, or rejected. Do not treat "we do not know" as a failure state; it needs a documented query before any action.
4. Open one decision channel. Finance needs to know the incident's effect on sales and close, while technology needs to diagnose the cause. A single incident owner who sets the approved messages, the time of the next update and the escalation conditions prevents contradictory instructions.
5. Preserve the operational evidence. Request logs, document identifiers, timestamps, error codes and certificate state are not secondary technical details. They are what later proves how documents were handled and why submission was delayed.

Handling by document type

The standard tax invoice and the simplified invoice do not follow the same operational path, and the difference between them is what determines the right behaviour during an outage. For the standard invoice, clearance governs your ability to hand an accepted invoice to the buyer. If clearance is not possible, final delivery should be held, or the fallback procedure in the Authority's instructions in force should be followed — not an alternative path invented inside the sales system.

For simplified invoices, what matters is the distinction between issuing the document to the customer and reporting it to the Authority within the statutory window. Selling may continue in defined cases if the controls on issuance, signing, the QR code and sequence integrity all hold, with reporting completed when the service returns. But that does not mean every outage justifies indefinite deferral: the invoice type, the time of issue, the phase rules that apply to your business, and the Authority's instructions at the time of the incident are what determine the correct behaviour.

Which is why a store or customer-service team should not be left interpreting requirements by hand under pressure. The rules engine should decide in advance whether an invoice may be issued or must be held, and state the reason in operational language: "awaiting clearance", "issued and awaiting reporting", or "requires a tax-data correction".

A queue is not just a buffer

The invoice queue is a compliance layer. Its job is to preserve document order, prevent loss, and govern submission when the service returns. If the queue holds only the invoice file, without the signing and certificate state, the reference number and the result of each attempt, you will produce audit gaps that are hard to explain.

The invoice should be stored in a form that cannot be modified once its content is approved, with a digital hash and a stable identifier. On retry, the same approved document must be resubmitted — not a new copy under a different timestamp or number, unless the correction rules require it. This point in particular protects the invoice sequence and prevents what the ERP sees from diverging from what reaches the Authority.

The retry policy needs balance, too. Submitting intensively the moment the service returns can add pressure and bury the real errors among thousands of attempts. Better to use increasing backoff, clear attempt limits, and an escalating alert when a defined operational window is exceeded. The system should also support high-throughput processing during recovery, while preserving document order where order affects business rules.

Separate sales continuity from the signing keys

The most dangerous shortcut during an outage is moving signing keys or stamping certificates onto scattered machines so that "invoicing continues". That solves a short problem and creates a permanent risk: losing control of the keys, being unable to prove which party signed a document, and struggling to revoke access after the incident.

The sound approach keeps keys inside key-management or hardware protection modules, and makes signing requests part of a central, auditable service. The point of sale or invoicing system can then carry on creating requests, while actual custody of the key stays governed by defined access policies.

Sensitive production decisions need a clear separation of duties. Automation can detect rising timeouts, expand the processing queue and open an incident alert. But changing the issuance path or disabling a compliance control must go through documented human approval. Good automation reduces response time; it does not widen the risk surface without permission.

Do not fix an outage by hiding the rejections

The most dangerous thing after a service returns is pushing the whole backlog through at once without inspection. The original problem may have been a tax rate, a buyer's registration number, mandatory fields, the certificate signature, or the document structure. Resubmitting a thousand invoices with the same error does not speed recovery; it widens the incident.

Make rejection a workflow, not a crisis that moves to email. The rejection reason should appear in language both finance and technology understand, with the affected field or rule, a structured way to correct it, and a record of who changed what and when. Then test a representative sample before restarting the whole batch.

What finance needs during the incident

Finance does not need a technical screen full of error codes. It needs an actionable answer: how many invoices are waiting? What are they worth? Are they simplified sales or standard invoices? What is the oldest pending invoice? And is a reporting deadline getting close?

A single operations view helps separate the urgent work from the noise. It should show an invoice's status from the source system through to the Authority's result, searchable by invoice number, VAT number or request identifier. And when the incident ends, showing that the queue reached zero is not enough: what is required is a reconciliation of documents issued, submitted, accepted, rejected and excluded under a documented procedure.

The tamper-proof record is essential here. It holds the time of creation, signing, submission, response, retries and the user's decision. When internal or external review asks, the organisation can present a chain of evidence instead of collecting screenshots and emails from several teams. The requirements for invoice storage and the audit trail are covered in a separate article.

Test the outage scenario before it happens

Readiness cannot be measured by one successful invoice in a sandbox. A useful test simulates an extended outage, uncertain results, a sudden return of service with a large backlog, and invoices carrying real errors inside the queue. It also tests certificate validity, sequence behaviour, the ability to prevent duplicate submission, and the procedures for informing management and the customer.

Explicit operational ownership should be settled as well. Technology owns integration state, queues and monitoring. Tax owns the interpretation of regulatory impact. Finance owns transaction impact and reconciliation. And the decision to activate or stand down an exceptional procedure must be known by name and authority, not taken in a chat group under pressure.

How this looks in alFatora - الفاتورة

In alFatora Connect, an outage is a designed state rather than a surprise:

• An explicit "awaiting clearance" state for a document when the Authority's service slows or stops, so you know exactly where the invoice stands instead of reading a generic failure.
• A mandatory idempotency key on every submission. A retry with the same key returns the first request's result, so no second invoice appears after a network drop.
• Local validation continues even when submission cannot, so errors are still caught near their source rather than accumulating in the queue.
• Every document's result arrives by webhook when it settles, rather than waiting on a manual query.
• An immutable audit trail tying the request, the submission time, the response and every retry — which is what gets asked for in a review months later.

Outages will happen, whether the cause is a network provider, an expired certificate or an external service under pressure. What determines their impact is whether the organisation knows, at every minute of the incident, where each invoice is and what it is permitted to do. When that answer is available and provable, disciplined operations come back faster than the service itself.