An employee sees “submission failed” after approving an invoice, clicks again and then creates a replacement. When connectivity returns, the accountant finds two documents for the same transaction without knowing which reached the external service. This hypothetical operational incident illustrates why invoicing errors need evidence and a register rather than repeated attempts without diagnosis.
An exception register is not a red list for blaming users. It should answer four questions: which document is affected, what is known about its status, what is the next safe action, and what evidence permits closure? Separate those answers from lengthy technical details while retaining a secure reference that a specialist can investigate.
The connection timed out: was the invoice rejected?
A timeout means the application did not receive an answer within the expected interval. It does not by itself establish acceptance or rejection. Inspect the attempt log and any preserved response, then follow the verification or retry mechanism supported by the integration interface and official specifications. Do not assume that every provider or submission route offers a general status-query endpoint.
Retain document identity, attempt reference, timestamp and the submitted file's fingerprint where the design supports it, so a retry does not become another sale. Prevent repeated clicks from launching uncontrolled concurrent requests. Show an unresolved outcome rather than an invented success. If the status cannot be established, escalate the case with relevant evidence instead of deleting it from the queue.
A response contains an error: who should fix it?
A buyer-data error differs from a tax-calculation error or an authentication problem. The first may require verification of customer master data and its source; the second needs analysis of the calculation basis, rounding and line classification; the third belongs with the integration owner. Correct classification reduces time spent passing an invoice between finance and support.
Do not rely solely on the HTTP response code or a short intermediary message. Inspect the document-processing result and validation details defined by the interface. If the response includes a warning, preserve it and address its actual meaning under the specification rather than treating every warning as a rejection—or as something that can always be ignored. Treatment depends on the document type, route and applicable phase.
When correcting a problem, do not alter an approved file while retaining an identity or signature that no longer matches its contents. Establish whether the document failed the required process or was already issued or accepted and now needs a documented corrective procedure. Consult the Authority's requirements for the particular case before reissuing or creating an appropriate note. The register does not grant an exemption from invoicing obligations.
What belongs in a single register entry?
Use a small set of useful fields: document reference and type, operating environment, first failure and latest attempt times, issue category, evidenced status, owner, next action and follow-up date. Link to a sanitised original message and an escalation ticket where relevant. Never store a password, private key or connection token in free-text notes. Do not circulate a complete customer file when a sanitised example is sufficient for diagnosis.
A successful test does not establish production readiness. ZATCA provides specifications and tools for validating invoice files, but passing a local check does not replace fulfilment of the actual submission requirements. Distinguish integration tests from genuine commercial documents, and do not experiment with an unverified repair using customer invoices.
When is the case genuinely closed?
Close it after documenting the required final outcome, resolving any accounting or operational effect of the attempts, and identifying the valid document where multiple versions or attempts exist. Turning a row green is insufficient, and hiding an alert does not resolve its cause.
Review the oldest unresolved cases and recurring causes, not just the total error count. Twenty failures caused by one field may be prevented through earlier validation, while one old, high-value case may warrant urgent escalation. Set follow-up thresholds in light of risk and applicable regulatory deadlines rather than inventing one universal deadline within the register.
The official references below establish requirements; the responsibility and monitoring arrangements proposed here are organisational suggestions. This article does not claim that Wali ERP holds an accreditation or that a particular integration is implemented or ready without independent verification.
Sources & further reading
Visit the original source to explore the concept and its wider context.
General educational content. Appropriate treatment depends on your business and accounting policies; consult your accounting professional when applying it to business records.
