The ERP connection works until the same order arrives twice
For IT heads, operations directors and digital project owners · Compare approaches
TL;DR — what you’ll learn
- Give business events stable identities across systems.
- Distinguish a failed request from an unknown outcome.
- Make retries safe and route business-data errors for correction.
- Reconcile source and destination outcomes instead of relying on a green connection status.
The order portal sends a request and receives no response. It tries again. The ERP has already created the first order, so a second one appears. Both systems are available and every request looks reasonable in isolation. The missing design is what should happen when the result of a request is uncertain.
What exception handling does a food ERP integration need?
ERP integration needs controlled handling of duplicates, uncertain responses, mapping errors and partial completion. Each business event should be traceable across systems, with safe retries and an owned exception queue. A successful connection test does not prove that orders, stock or financial records remain consistent during failure.
- 01Receive the eventStable source identity
- 02Check the destination stateExisting result and partial progress
- 03Classify the exceptionRetry, data correction or business reviewIs replay safe and authorised?YesComplete and reconcileNoKeep the event pending while its unknown outcome is resolved.
- 04Complete and reconcileLink source to destination outcome
Illustrative information flow. The article explains the evidence, exceptions and responsible decisions. Diagram: NextEdge Labs.
Identify the event and the intended effect
Use a stable source event identifier and retain its destination reference. A customer order revision should be distinguishable from a repeated transmission of the same order. Similar item lines and timestamps are not reliable substitutes for identity, especially when customers place legitimate repeat orders.
Amazon's Builders' Library explains idempotent API design as a way to make retries safe against duplicate effects. In an ERP integration, the actual implementation depends on the destination's capabilities. The design must establish whether a repeated request returns the existing result, is rejected safely or requires a controlled lookup before another attempt.
Source: Amazon Builders' Library · Retries, request identity and duplicate side effects. Reference details
Classify failures by the action they need
A temporary service outage may justify a bounded retry. An unknown item code needs master-data correction. A stock restriction requires the authorised business process. Sending all three through the same retry loop wastes capacity and can hide a decision that no amount of waiting will resolve.
An unknown outcome deserves special handling. If the destination accepted a request but the response was lost, creating a new request with a new identity can duplicate the effect. Preserve the original event and investigate its destination status before deciding how to continue.
| Condition | Response path |
|---|---|
| Temporary unavailable service | Controlled retry with limits and visibility |
| Unknown outcome after timeout | Reconcile using the original event identity |
| Missing item or unit mapping | Data owner reviews and corrects |
| Business restriction | Authorised business decision |
Plan for partial completion
A workflow may create a delivery record but fail before attaching receipt evidence or updating the customer portal. Show the completed and outstanding steps separately. Re-running the whole workflow without that knowledge can repeat work that already succeeded.
Define the recovery action for each step. Some changes can be retried; others need a compensating transaction or manual review under the ERP's rules. Avoid describing every failure as a rollback when the system has already created a durable business record. Preserve the original audit trail and link any correction.
Give exceptions a usable work queue
The operator should see the source reference, intended action, current state, error category, evidence and responsible owner. A raw technical error alone rarely tells a buyer or warehouse lead what to do. Translate it into the decision needed while retaining diagnostics for technical support.
Record every manual correction and replay. A user should not be able to edit the source payload silently and make the history appear as though the corrected event was received originally. Keep sensitive values out of broad logs and expose only the detail appropriate to each role.
Use alerts for stalled or material exceptions rather than every successful transfer. A queue with no owner becomes another inbox; a queue with clear responsibility can support daily operations.
Reconcile business outcomes
Compare eligible source events with destination outcomes over a defined period. Check counts, quantities and relevant values, and investigate missing or duplicated relationships. A dashboard showing the latest API call succeeded does not establish that yesterday's failed orders were recovered.
Test a duplicate event, lost response, invalid item, partial completion and out-of-order revision before release. Ask a business user to resolve an exception and a technical owner to reconstruct the history. When comparing integration proposals, require those demonstrations alongside the normal successful path.
Summary
A dependable ERP integration preserves event identity and makes failure recoverable. Classify errors, retain partial progress and reconcile the actual business outcomes. Safe retries and an owned exception queue matter as much as the initial connection between systems.
What to do next
- List the records each interface creates or changes and how their identities are linked.
- Test a lost response and a repeated event without creating duplicates.
- Reconcile one period's source events against destination outcomes.
Compare this workflow with your current setup
Share the step that takes the most manual work, the systems involved and the exceptions your team handles. That gives us a concrete starting point for comparing approaches.
Sources and further reading
Sources checked 15 October 2026. The worked examples and software evaluation suggestions are NextEdge Labs’ editorial analysis.
- Making retries safe with idempotent APIsAmazon Builders' Library · Technical article by Malcolm Featonby, accessed October 2026
Technical reference for preventing repeated requests from creating duplicate effects. ERP examples are original scenarios and require validation against each system's actual transaction behaviour.
Visual credits
AI-generated illustration created for NextEdge Labs; it does not depict a client facility. Workflow diagram by NextEdge Labs. Icons from Lucide (ISC licence).
