Invoice incident response: contain, reconcile and recover

A billing incident can affect revenue, customer relationships and accounting evidence even when the website remains available. Respond to the business impact: which entities and transactions are affected, whether money or documents are wrong, and whether an operation might already have succeeded.

The procedure below is a suggested service practice. Severity names, response targets and escalation contacts must come from your organisation and contracted service terms. This guide does not promise a support response time.

Declare an owner and a scope

Assign one incident lead to maintain the timeline and one finance owner to decide commercial corrections. Integration support diagnoses technical failures; the access-point provider reconciles network outcomes where needed. Customer-facing communication should use your approved channel and named account owner.

Start a case with company/entity, flow, first observed time and timezone, affected count, amount by currency, source system and impact. Avoid vague descriptions such as “Peppol down” when only one buyer is unreachable.

Contain without destroying evidence

Pause the affected sender or integration queue in the system you operate. Preserve source transactions and their stable identities. Hold only the relevant entity or document type when scope is known. Do not delete numbered documents, change IDs or rotate credentials as a generic response to a timeout.

Record document IDs, invoice numbers, external_id, integration namespace, Peppol document IDs, last known state, error code and sanitized response. Keep API keys, full credentials and unnecessary customer data out of tickets. Preserve original XML/PDF and transmission snapshots when available.

If credentials are demonstrably exposed, the authorised key owner should revoke or rotate them and coordinate the integration update. First distinguish compromise from a missing scope or expired key; they need different corrective actions.

Classify each affected transaction

1. Rejected before acceptance: a specific validation or permission refusal describes what must be corrected. Retain the code and fix the cause.
2. Financial record may exist: a timeout after invoice creation requires external-ID lookup, not a new invoice identity.
3. Transmission uncertain: transmission_state: uncertain or PEPPOL_TRANSMISSION_UNCERTAIN means network acceptance is unresolved. Seek provider reconciliation or the signed provider update before resending.
4. Delivered, business disputed: route to the commercial owner. Transport success is separate from the buyer's decision.
5. Evidence inaccessible or corrupt: preserve the error and original references, then escalate archive retrieval. Do not regenerate a file and describe it as the original.

OpenPeppol distinguishes transport acknowledgements and business responses. This is why an accepted network message can still lead to a price dispute, and why a transport issue does not prove that an invoice should be credited.

Recover from a reconciled inventory

Build a transaction sheet with source ID, product ID, created/absent/unknown outcome, delivery state, next action and owner. Look up uncertain creates through /api/v1/invoices/lookup?external_id=... and movements through the payment lookup endpoint. Keep the original integration namespace and payload.

Retry identical known recoverable operations using their original identities. Do not replay a transmission whose network result remains ambiguous. When a known rejected send is eligible for retry, preserve the issued bytes and document identity. For changed commercial content, finance decides the credit/correction path.

Example: timeout during a batch

A batch of 50 invoices stops after 30 requests. Twenty-eight responses were successful, two timed out and 20 were never attempted. Lookup finds both timed-out invoices already persisted. One transmission is delivered; the other is uncertain.

Operations resumes the 20 unattempted source transactions with their original IDs. The delivered item needs no resend. The uncertain item stays held until provider evidence resolves it. Creating two replacement invoices would have turned a connectivity incident into duplicate revenue and customer debt.

Verify restart and close the handover

Before release, reconcile source counts, financial amounts, settlement and delivery separately. Run a controlled small batch and retrieve its documents. Record any manual actions performed during the outage so normal automation does not repeat them.

Close only when every affected transaction is accounted for or has a named residual-case owner. Retain the cause, impact window, corrective action, recovery evidence and an improvement action with a due date. A provider-restored service alone is not proof that your backlog reconciled.

Hand the service back with the queue position, outstanding uncertain sends, any customer disputes and the next monitoring check. Repeated incidents should update integration reliability controls and the rollout acceptance pack.