A failed ERP transfer should not remain only a technical error in an integration log. It needs to become an operational case showing the failure status, business consequence, integration exception owner and evidence of successful recovery. A failed ERP transfer queue serves this purpose: the process team decides priority and business handling, while the technical team establishes the cause, performs recovery and leaves a verifiable record.
This queue must clearly separate temporary unavailability from invalid data. The first case often calls for a controlled resend. The second calls for data correction and a business decision before sending. Treating both cases through the same workflow creates duplicate records, stopped orders or transfers without clear accountability.
An integration can technically record that a message was rejected, but that message alone does not say what should happen to an order, invoice, production order or inventory balance. Only the process owner can set the business response threshold: whether the case should stop, be retried, be corrected, be handled manually or be escalated.
Each queue record should therefore answer four questions:
Traces, metrics and logs help explain system behaviour. They are important diagnostic evidence, but they do not set business priority by themselves. For basic system observability context, see the OpenTelemetry observability primer . The process owner sets the response threshold, accepts manual handling and decides on the exception.
An operational queue does not need to be a complex tool. It does need complete information for a decision without searching across messages, spreadsheets and systems.
For each case, record:
The input data owner is accountable for the accuracy of the source business data, such as an item code, tax value, partner, or quantity. The integration exception owner coordinates analysis and technical resolution of the transfer. The business decision owner decides whether the process may wait, whether manual processing is acceptable and when escalation is required. One person may hold several roles in a small team, but the roles should still be stated separately.
Temporary unavailability exists when the data is acceptable, but the destination or communication path cannot process the transfer at that time. Examples may include an unavailable endpoint, a response timeout or a short-lived service error. Do not classify the issue from one error message alone. Check whether there is evidence that the ERP did not receive the document and whether partial processing is possible.
The workflow can include:
Automated retrying can reduce manual effort, but it does not replace checks for idempotency, document status and business consequence. If the workflow cannot rule out a duplicate, the case must move to controlled handling.
Invalid data exists when the ERP or an integration rule rejects the content: a mandatory field is missing, a value is in an invalid format, a code does not exist or a business rule does not allow the document. Resending without a change in this situation only increases the number of identical errors.
The workflow should start at the data source:
This split reveals where the problem began. Unavailability is usually a transfer or destination issue. Invalid data is a data quality, rule or business preparation issue. One queue can manage both branches, but it must not apply identical actions to them.
Priority should not be based only on the number of errors. One failed transfer may block billing, production or delivery, while a larger number of other records may have no immediate business consequence. The process owner should therefore set the priority rule according to document type, process stage, dependent activities and time to the business obligation.
A practical decision framework can use four steps:
Hypothetical scenario: a production order transfer to the ERP fails. If the record indicates destination unavailability, the team first checks whether the production order already exists in the ERP, then performs a controlled retry under the agreed rule. If the ERP rejects the order because a material code does not exist, the master-data owner corrects the reference and the process owner confirms whether the order may be sent after the change. In both cases, closure requires evidence in an official ERP transaction or another approved business record, not merely a message stating that the integration completed without an error.
Acceptance criteria need to be verifiable and tied to the business result. A status such as "sent" or "retry successful" is insufficient when it does not confirm processing in the ERP.
For each transfer type, define suitable evidence in advance, for example:
Express the acceptance measure as a check, not as an unsupported number: the share of closed cases with attached ERP processing evidence, the number of open cases without an assigned owner, or the time from opening to confirmed recovery. Set the baseline, target threshold and review frequency from the actual process and its risk, rather than adopting a generic recommendation.
An exception queue does not solve poor master-data quality, unclear business rules or undefined responsibilities by itself. It should also not become a parallel system for permanently managing ERP documents manually. When the same cause recurs, the queue record should trigger work on a lasting improvement: a validation change, data ownership change, integration rule change or process instruction.
Data access also needs attention. An exception record can contain business documents, partner identifiers or financial values. Roles should have only the access needed to resolve the case, and recovery evidence should remain in the agreed system of record.
Before introducing or redesigning the queue, check the following:
If the organisation is still defining owners and process boundaries, Business process screening can provide a structured starting point. The failed ERP transfer queue can then become a working mechanism: every exception has a visible status, accountable person, decision and recovery evidence.