A timeout does not prove that an e-invoice failed. It proves only that the sending system did not receive a usable response, while the provider or authority may already have accepted the submission.
Replaying an invoice from that state can create a duplicate, a second technical attempt or a conflict between SAP and the external platform. In this article, you will learn how to classify an uncertain submission, decide whether replay is permitted and preserve the evidence needed to reconcile the result safely.
Freeze the uncertain population before retrying anything
Stop uncontrolled retries first. Pause manual retry activity and any overlapping scheduled job through the customer’s normal operational procedure. Continue posting business documents only if the operating model can keep new submissions separate from the incident population.
Create the affected population from a reproducible query, not from screenshots or a manually maintained count. Bound the query by system, client, country process, interface and incident window, then retain the selection logic and execution time.
- Source document, company code and fiscal year
- Electronic-document identifier and current SAP status
- Original payload version or hash
- Middleware message identifier
- Provider or network correlation identifier, when available
- Last confirmed external response and timestamp
- Previous technical attempts
- Applicable operational or statutory deadline
- Named technical and business owner
This list becomes the outage ledger. Every status check, replay decision and final reconciliation should update this same record.
Establish the last state that can be proved
Trace each document through the actual submission chain. Do not collapse several technical states into a single label such as “failed.”
- Business document posted
- Electronic document created
- Payload generated
- Handoff to middleware attempted
- Provider or network accepted the request
- Authority or recipient platform processed it
- Final status returned to SAP
A local error is not an external rejection. A provider correlation identifier normally proves more than a local send timestamp, but its exact meaning must be checked against the provider’s interface specification. An authority acceptance may also exist even when the callback to SAP failed.
Use a replay decision gate
An invoice is safe to replay only when the team can answer the following questions for that document. If one answer is unknown, keep the invoice out of the replay queue.
1. Can external acceptance be excluded?
If the request never left the customer-controlled integration boundary and no external identifier was created, replay may be possible after recovery. Verify this from middleware and application logs, not from the SAP status alone.
If a request was transmitted or a correlation identifier exists, query the existing transaction first. Use the original identifiers to check the middleware, provider, network or authority status.
2. Does the receiving interface define retry or idempotency behavior?
A technical retry can be safe only when it follows the documented behavior for the applicable endpoint. Confirm whether the receiver recognizes the same business identifier, payload identifier or idempotency key, and whether a repeated request returns the existing result or creates another attempt.
Never infer idempotency from a successful test in another country process. Endpoint behavior can differ by authority, provider, document type and message operation.
3. Will replay use the approved payload?
Preserve the original payload. Regenerating it may change a timestamp, identifier, signature, mapping result or code-list value. If the original payload is valid and replay is permitted, send the approved version through the documented retry path.
If the external party explicitly rejected the document because the content was invalid, do not call the correction a replay. Retain the rejected payload, correct the verified defect, create a controlled new version and link it to the original attempt.
4. Has the business submission already been accepted?
If external evidence shows acceptance while SAP still displays an error, the required action is status reconciliation. Restore or obtain the missing response through the supported process rather than creating a new business submission.
Keep business identity separate from attempt identity
The SAP document number alone may not be unique across company codes or fiscal years. A middleware identifier may change on every attempt. Define one stable business-submission key and record every technical attempt beneath it.
- Business identity: legal entity, company code, fiscal year, source document, compliance process and payload version
- Attempt identity: attempt sequence, request timestamp, interface message identifier and returned correlation identifier
This separation lets the team see several attempts without mistaking them for several invoices. It also provides a practical duplicate-control key during reconciliation.
Prove recovery before releasing the backlog
A green status page is not sufficient evidence of end-to-end recovery. Submit one controlled document through the affected path, confirm that the response returns to SAP and verify that external identifiers and statuses are recorded correctly.
Then divide the ledger into controlled queues:
- Existing submissions awaiting an external status check
- Original payloads approved for replay under the documented retry behavior
- Rejected documents requiring correction and a new version
- Accepted documents requiring status reconciliation
- Ambiguous documents requiring a named business decision
Release approved replays in small operational batches. After each batch, check duplicate responses, new rejection patterns and response processing before releasing the next group.
Close the incident only after document-level reconciliation
The incident is not complete when the retry queue is empty. It is complete when SAP, middleware and external evidence agree for every document in the frozen population.
- Final external status and supporting identifier
- Action taken and approving owner
- Final SAP status
- Duplicate-control result
- Any missed deadline or affected recipient
- Unresolved exception and next owner
- Control change resulting from the incident
Replay rule: replay only when external acceptance has been excluded or the applicable interface explicitly supports a repeat of the original submission under a verified idempotency rule. Otherwise, reconcile first.
Implementation references: Use the relevant process documentation in the SAP Document and Reporting Compliance Help Portal together with the applicable authority, network and provider interface specifications. Retry, duplicate-control and legal treatment vary by scenario.