EDI Delivery Credits Need More Than an Outage Report

Your VAN says service is restored and offers a delivery credit. Before closing the incident, you still need to know whether an order, shipment notice or invoice reached the right partner, and whether a resend could create a duplicate. That work can cost more in staff time than the credit is worth.

What an EDI delivery credit covers

An EDI delivery credit is a billing adjustment a provider may offer when delivery falls short of the service terms in your agreement. Its availability and amount depend on that agreement. A credit is an accounting outcome, not evidence that each business document reached its destination.

Electronic data interchange, or EDI, carries structured business documents between companies. A value added network, or VAN, helps route those documents between trading partners. When an EDI route fails, the network incident and its commercial consequences are related, but they need separate reviews. One review establishes whether a contractual credit applies. The other establishes what happened to the orders, shipment notices, invoices and acknowledgments that your business relies on.

That separation matters for executives. A credit calculated against the network bill might be appropriate under the contract while your staff is still resolving partner questions and checking shipments. It also matters for an EDI coordinator: an outage notice that says traffic resumed gives no instruction about which documents to resend, which to leave alone and which require a partner response.

Why restored service does not settle business impact

Outage duration is a useful starting point, but it is a poor substitute for transaction impact. A service failure at a quiet moment may have little downstream effect. A similar interruption during a partner's order or shipping deadline may require urgent investigation. The relevant question is which business documents were exposed, not simply how long the network was unavailable.

Consider three distinct outcomes. A document can remain in your sending system because it never reached the VAN. The VAN can receive it but fail to deliver it to the next destination. Or the receiving system can get it while the expected acknowledgment is delayed or missing. Those situations call for different recovery steps. Treating them all as undelivered and resending everything can introduce duplicates.

The type of document changes the consequence. An X12 850 purchase order communicates an order. An 856 advance ship notice describes a shipment, while an 810 invoice supports billing. If a partner requires one of these by a particular deadline, consult that partner's published EDI implementation guide and your commercial terms before assuming an operational or financial penalty applies. Do not turn a possible chargeback into a confirmed cost without the underlying evidence.

For finance and operations, keep an incident ledger that separates confirmed costs from exposure still under review. Include employee time spent tracing messages, partner follow-up, manual reentry and any documented external charges. For IT, keep the provider's incident timeline next to the transaction ledger so you can distinguish network failure from a mapping error, a partner rejection or an internal system issue.

Question	Evidence to collect	Decision it supports
Was the document submitted?	Sending system record, submission time and document identifier	Whether the VAN ever had the transaction
Was it routed?	Provider status, receiving partner and transmission attempt	Which route needs investigation
Was it acknowledged?	Expected acknowledgment, receipt status and control number	Whether further confirmation is needed
What did recovery cost?	Staff time, partner correspondence and confirmed external charges	Business impact beyond a service credit

How to reconcile affected documents before resending

Reconciliation means matching a document submitted by one party with its status and expected response at the next point in the exchange. It gives your team a defensible answer to the question, "Where is this document?" Start with a defined incident window, then widen it if transactions submitted before the outage were still queued or acknowledgments arrived afterward.

Build a document list from the sending system

List the trading partner, document type, submission time and control number for each potentially affected transaction. A control number is an identifier used to match EDI messages across records and acknowledgments. Assign someone to confirm that the list includes documents created during the incident as well as documents already in transit when it began.

Next, compare that list with what the VAN shows. Look for documents present in one record but absent from the other, entries with conflicting statuses and multiple attempts carrying the same business document. This is where a management portal that shows transaction status, acknowledgments and control numbers is useful. Nexus VAN provides that visibility, which helps an EDI coordinator examine specific transactions instead of relying on a general outage notice.

Distinguish transport evidence from business acceptance

A transport receipt can show that a transmission reached a technical endpoint. It does not, by itself, establish that the receiving business processed the contents. An X12 997 functional acknowledgment tells the sender whether a document passed the receiver's syntax check. It can report acceptance or rejection, but it does not mean the order or its content was accepted.

Check the partner's published implementation guide for the acknowledgment or application response expected for the document and EDI version in use. Record each response separately. If an acknowledgment is missing, mark the outcome unresolved until you have enough evidence to decide whether the transaction should be retried or escalated to the partner.

Resolve exceptions without creating duplicates

Give every affected transaction a disposition: delivered with the expected evidence, confirmed undelivered, rejected, pending confirmation or potentially duplicated. Do not use a blanket resend as the recovery plan. Before retransmitting, compare control numbers and business references, consult the partner where necessary and record who approved the action. Preserve both the original attempt and the retry in your incident ledger.

A simple hypothetical example shows the issue. Imagine your team sends an 856 advance ship notice, sees no acknowledgment and sends it again. If the first copy actually arrived, the partner may now have two notices to investigate. A missing response is a reason to check the trail, not proof that delivery failed. For more on interpreting responses, see our guide to EDI 997 and 824 acknowledgments in daily exception management.

How to build a credible credit request

Once you know the scope, request a written explanation that a finance reviewer and an EDI coordinator can both use. Your contract determines the credit calculation, notice requirements and any exclusions. Preserve the relevant contract language alongside the incident evidence so the discussion does not drift into conflicting assumptions.

1. Establish the timeline. Record the reported start, detection, mitigation and restoration times, with a time zone. Compare the provider's window with your own failed or delayed submission records.
2. Request transaction detail. Ask for affected partners, documents, statuses and transmission attempts. Match them against your sending records rather than accepting a total count alone.
3. Document operational consequences. Note which transactions needed investigation, partner confirmation or retransmission. Keep staff hours and confirmed external costs in separate columns.
4. Ask for the credit basis. Identify the contract clause, the service period used and how the provider calculated the adjustment. If the explanation is unclear, ask for the calculation in writing.
5. Request corrective actions. Ask what caused the failure, what made it harder to recover, who owns each corrective step and how completion will be checked.

The incident review should also have a named owner on your side. Finance can assess the credit and contract exposure. IT can challenge the technical explanation. The EDI coordinator can confirm that transaction exceptions are actually resolved. None of these reviews substitutes for the others.

Be precise about the remedy you are seeking. A contractual service credit, reimbursement for a documented charge and a change in future incident handling are different requests. Your provider may agree to some and not others. Separating them makes the discussion easier to resolve and leaves you with a clearer record at renewal.

When outages and fees justify a VAN review

A single incident does not necessarily require a provider change. Repeated failures to explain document status, however, increase the cost of every future incident. If your team cannot readily identify affected transactions or must pay to retrieve the records needed for recovery, review the service and the bill together.

Many legacy VANs use billing practices that can inflate the invoice, including rounding each document up in size, minimum charges per document, per-partner fees and archive-access fees. These are common industry practices, not assumptions about any particular contract. Check your own invoice and agreement before estimating the effect. A service credit should not distract from a recurring billing pattern that costs more than an occasional adjustment returns.

Nexus VAN prices by the kilo-character, and we never round up the size of your documents, so you are billed accurately for the exact data you transmit, and nothing more. To compare that model with your current arrangement, separate usage charges from partner, document and archive charges on recent invoices. Then compare the underlying transmitted data, rather than assuming two invoices with different billing units are directly comparable.

There is a concrete example of why that review matters. The Spanx case study describes a move away from a legacy VAN with hidden fees, high per-message rates, per-partner charges and archive-access fees toward more predictable, transparent pricing. It is a cost example, not an outage or service-credit claim.

For a CFO or private equity director overseeing multiple companies, use the same review format for each EDI contract. Record who pays for document rounding, partner additions and archive access, then compare how quickly each provider can explain a disrupted transaction. This makes vendor lock-in visible as an operating issue: if recovery depends on inaccessible records or poorly understood routes, moving later becomes harder.

How to make switching low risk

The worry about switching is legitimate. A wrong partner ID can misroute a document. A changed connection can leave acknowledgments unmatched. Cutting over before a partner completes its required testing can leave an order or invoice in limbo. Avoiding those outcomes takes an inventory, partner-specific checks and evidence from actual transaction flows.

During migration, Nexus VAN uses dual-VAN reconciliation: the old VAN and the new VAN run side by side so documents can be accounted for before an old route is retired. This is a low-risk approach because you compare the record of what was sent, where it went and what response came back instead of treating a new connection as proof of successful business exchange. It does not remove the need for partner approval or careful handling of duplicate delivery.

1. Inventory the current network. List trading partners, sender and receiver IDs, document types, connection methods, expected acknowledgments and owners. Capture open incidents and outstanding documents before changing routes.
2. Confirm partner requirements. Check each trading partner's published implementation guide for routing, document version, testing and acknowledgment expectations. Do not assume requirements are identical across partners.
3. Test representative exchanges. Include normal transactions and known exceptions. Record the expected response for each test and who signs off on the result.
4. Reconcile during the overlap. Compare the document list, control numbers, statuses and acknowledgments on both paths. Make sure a side-by-side arrangement does not accidentally submit duplicate production documents.
5. Retire routes deliberately. Obtain business and technical approval for a route change, identify documents still in flight and confirm where later acknowledgments will be received.

Nexus VAN supports AS2, SFTP and REST API and has interconnects to VANs globally. Those options can accommodate different connection arrangements during a review, but the right route still depends on the trading partner's requirements. Our EDI identifier and certificate inventory and dual-VAN reconciliation guide cover the practical checks in more detail.

Best practices for the next incident

Write the recovery process before the next failure. A short, shared checklist lets finance request the right credit evidence while the EDI team concentrates on safe document recovery. It also prevents the same missing-status question from being rediscovered during every incident.

• Define the evidence owner. Decide who captures sending records, provider statuses and partner responses. Store them together under the incident identifier.
• Record the last known good transaction. It helps bound the investigation, though it should not replace a search for queued documents outside the reported outage window.
• Set a resend approval rule. Require a status check and a record of the reason for retry before anyone resubmits a production document.
• Separate cost categories. Track the service credit, internal recovery effort and confirmed external charges independently.
• Retest corrective actions. Ask for evidence that the promised change addresses the failure mode. Keep any remaining open transaction exceptions on the incident list.
• Revisit the contract at renewal. Compare incident handling, access to transaction evidence and the way data usage is billed, not the headline price alone.

For an EDI coordinator, the best outcome is a clear disposition for every affected document. For an executive, it is a defensible account of exposure, recovery cost and the decision to stay or switch. Both start with transaction evidence rather than a generic statement that the network is back online.

---

Frequently Asked Questions

Make the credit decision and the provider decision separately

Ask for the credit your agreement supports. Then use the transaction record to decide whether the service, recovery effort and ongoing bill still make sense. If legacy document rounding or extra access fees are increasing what you pay, exact kilo-character billing gives you a different basis for comparison. If cutover risk is holding you back, dual-VAN reconciliation offers a way to account for documents before retiring the old route.

---