Define What Success Means at Each Layer
An EDI transmission is not complete merely because an HTTP request returned 200, an SFTP upload finished, or an AS2 MDN arrived. Treat success as separate milestones: transport receipt proves that bytes reached an endpoint; a functional acknowledgment, such as X12 997 or 999 or EDIFACT CONTRL, reports whether the envelope and document were understood; a business response confirms that the order, shipment, or invoice was accepted by the receiving application. A document can pass one layer and fail the next.
Model these milestones as explicit states rather than one success flag. Useful states include created, queued, sent, transport-confirmed, awaiting-functional-acknowledgment, accepted, rejected, retry-scheduled, and manual-review. Advance a state only from evidence, retaining the event source, timestamp, reason code, and original acknowledgment. This prevents operations staff from mistaking sent for posted and allows alerts to identify the particular response that is overdue.
Build the Exchange Around Idempotency and Correlation
Exactly-once delivery is not a realistic guarantee across independent companies and networks. A sender can time out after the receiver has stored a file, while a receiver can post a transaction and fail before returning its response. The practical contract is at-least-once delivery with idempotent processing. Keep the identity of the business document separate from the identity of each transmission attempt.
- Business identity: purchase order or invoice number, supplier, company code, and document version.
- Exchange identity: interchange, group, and message control numbers together with sender and receiver identifiers.
- Content fingerprint: a hash of the normalized payload to distinguish exact duplicates from conflicting revisions.
- Event history: every attempt, channel response, acknowledgment, parsing result, state transition, and operator action.
The receiver should use an agreed idempotency key to prevent duplicate posting. An exact replay can return the previously recorded outcome, but the same business key with different content should be quarantined rather than silently ignored. Whether a retry reuses a control number or creates a new envelope depends on the partner agreement. In either case, retain links from every transmission attempt to the original business document.
Retry According to Failure Type
Automatic retry is appropriate for temporary connection failures, throttling, and short service outages. It is usually harmful for an expired certificate, disabled account, invalid envelope, missing mandatory field, or unknown trading partner. Classify failures as transient, permanent, or uncertain before scheduling another attempt. The uncertain category matters because an acknowledgment timeout does not prove that the receiver failed to process the document.
- Transient: use exponential backoff, jitter, attempt limits, and an overall retry deadline.
- Permanent: stop retrying and place the document in a correction queue with an actionable reason.
- Unknown outcome: query partner status or replay safely using the same business identity and duplicate controls.
- Channel-wide outage: apply circuit breaking, concurrency limits, and priority queues to control the recovery surge.
Persist retry schedules outside application memory. Record the planned and actual attempt times, error classification, and response summary. Manual replay must pass through the same idempotency and audit controls as automated delivery. Otherwise, an operator trying to resolve an incident can accidentally create the duplicate posting the retry design was intended to prevent.
Reconcile Technical and Business Ledgers
An acknowledgment proves a stage of exchange, not agreement between the companies' books. Maintain a technical exchange ledger for payloads, control numbers, transfers, and acknowledgments, plus a business document ledger for orders, shipments, receipts, invoices, and ERP status. A reconciliation job should correlate them by stable identifiers and evaluate them within partner-specific business-day and response-time rules.
- Missing: a sender record has no matching receiver record or acknowledgment.
- Duplicate: one business document was accepted, posted, or converted more than once.
- Mismatch: identifiers match, but version, quantity, amount, currency, or status differs.
- Stalled: transport succeeded, but no functional or business outcome arrived within the agreed window.
Reconciliation must account for time zones, late files, overnight batches, cancellations, and corrected versions, or it will generate recurring false exceptions. Critical flows may need intraday checks, while complete financial comparison can run after business close. Close an exception only with evidence such as an acknowledgment, a partner status response, an ERP record, or an authorized manual decision. Encrypt retained payloads, restrict access, and apply defined retention rules. Operational monitoring should expose time spent in each state, retry backlog, rejection reasons, and unresolved differences so engineers can investigate both individual documents and channel-wide failures.