E-invoicing without stopping the business

Electronic invoicing introduces something an accounting system never had before: a dependency on somebody else being available. A tax authority endpoint can be slow, can be down for maintenance, can reject a document for a reason that did not exist last month. None of that is unusual, and none of it should stop you selling.

The design question is therefore not how to submit an invoice. It is what happens when submission fails.

Separate issuing from submitting

An invoice is a commercial document between you and your customer. Its clearance is a separate obligation between you and the tax authority. If those two are the same action in your system, then the authority availability decides your trading hours.

Keep them apart. The invoice is issued, numbered and posted to the ledger. The submission is a job that runs after it, with its own status, its own retry schedule and its own error log. A failed submission is then a task someone can see and act on, instead of a sale that did not happen.

Retry, but do not retry blindly

Not every failure deserves the same treatment, and conflating them is how a queue becomes a loop.

• A timeout or a connection error is temporary. Retry it, with increasing gaps, and it will usually clear itself.

• A validation rejection is permanent until the data changes. Retrying it a thousand times produces a thousand identical rejections. It belongs in front of a person.

• An authentication failure affects every document, not one. It should raise an alert immediately rather than quietly failing each invoice in turn.

The practical consequence is that a submission needs a real status - queued, sent, cleared, rejected, failed - and the reason stored alongside it. A boolean flag cannot express the difference between not yet and never, and that difference is the whole operational question.

Never submit the same invoice twice

A duplicate submission is worse than a failed one, because the correction is an administrative process rather than a retry. The protection is that submission is keyed on the invoice identity, not on the attempt: the second attempt for the same document must be recognised as the same document, even if the first attempt crashed halfway and recorded nothing.

This is also why an invoice that has been cleared must become immutable. If a cleared document can still be edited, your records and the authority records diverge silently, and you will find out at an audit rather than at the time.

Make the backlog visible to the people who care

Somebody in finance needs one screen that answers: how many documents are waiting, how many were rejected, and which ones. Without it, the first indication of a problem is a customer asking for a document you believed had been issued.

That screen is also the reason the queue is safe. A queue nobody watches is not resilience, it is a delay with no end date.

Two markets, one shape

Egypt and Saudi Arabia differ in the detail - the document format, the signing requirements, whether clearance happens before or after the fact. The shape of the solution is the same in both: issue locally, submit asynchronously, classify failures, keep the cleared document immutable, and show the backlog.

A system built that way can take on a third jurisdiction by adding a format. One where submission is embedded in the save path has to be rebuilt for each.