In this article
Parallel EDI reconciliation protects orders and invoices during an ERP cutover by comparing what the legacy and target systems do with the same business transactions before you switch production routing. You check that orders reach the new ERP, invoices match the records that generated them and exceptions have owners. Only one route sends each production document to a trading partner at a time.
This distinction matters because successful EDI transmission does not establish that an ERP posted an order or that an invoice is correct. BOLD VAN recommends treating transport, translation, ERP posting and partner response as separate checks. That gives your IT, operations and finance teams evidence to resolve differences before they affect fulfillment or billing.
What parallel EDI reconciliation means
In a parallel test, you take representative EDI transactions through the current process and the proposed ERP integration, then compare their business results. The target path can use controlled test transactions or isolated copies. It should not independently release production invoices, acknowledgments or ship notices while the legacy path still owns them.
A typical order-to-cash flow includes an inbound X12 850 purchase order, an outbound 855 purchase order acknowledgment, an 856 advance ship notice and an 810 invoice. Your actual document set, version and timing rules depend on the trading partner. Check each partner's published EDI implementation guide before building test cases or changing a map.
Critical cutover rule: Assign one production sender for every trading partner and outbound document type. Parallel testing should expose differences, not send duplicate 855s, 856s or 810s. Record who can authorize a route change and how you will identify documents already sent.
Compare business data, not just file counts
Start with the original partner document, the translated application data and the resulting ERP record. Preserve the relationship among the order, shipment and invoice so you can trace a mismatch to its source. An EDI map translates between a partner's document structure and the ERP's expected business data. During a cutover, the partner-facing meaning should remain consistent even when the ERP interface or internal identifiers change.
| Transaction | Compare across old and new paths | Confirm in the business process |
|---|---|---|
| 850 purchase order | Order reference, parties, items, quantities, units and requested dates | One intended ERP order with the right status |
| 855 purchase order acknowledgment | Response to the original order, including accepted or changed quantities where applicable | Outbound response agrees with the ERP decision |
| 856 advance ship notice | Shipment reference, order relationship, contents and quantities | Notice agrees with what was shipped |
| 810 invoice | Invoice and order references, items, amounts, taxes and terms as applicable | Outbound invoice agrees with the posted ERP invoice |
| 997 functional acknowledgment | Acceptance or rejection from the receiver's syntax check | Any rejection is investigated separately from business acceptance |
The precise comparisons vary with the partner guide and your ERP configuration. For example, a unit conversion can make two order lines appear different even when the quantities represent the same goods. Normalize agreed business values before comparing them, but retain the original values so reviewers can explain every transformation.
Run the cutover with explicit approval gates
Inventory the active flows
List each trading partner, document type, direction, map, connection and destination system. Include orders received but not posted, invoices prepared but not sent and documents awaiting a response. Give each flow a business owner as well as a technical owner. The inventory becomes your routing plan and your post-cutover reconciliation list.
Build tests from actual business cases
Use representative transactions that exercise ordinary orders, quantity changes, partial shipments and invoice adjustments relevant to your business. Add a failed document and a deliberate repeat to check how each path handles exceptions. Test both the translated output and what the ERP actually creates. Follow the ERP vendor's documentation for version-specific interface behavior.
Resolve differences before switching routes
For each test, record the source document, expected result, actual legacy result, actual target result and decision. Classify differences as mapping, ERP processing, source data or partner response issues. If a target order fails to post, a valid translated file is insufficient. If an invoice total differs, reconcile its source ERP record before releasing an 810.
Cut over by ownership, then verify
Agree on a routing change point and identify the last document owned by the old process. Move a partner or document flow only after its critical cases pass and open transactions have assigned owners. After the switch, compare received documents with ERP postings and sent documents with the underlying shipment or invoice records. Keep a rollback decision process that accounts for transactions already delivered to partners.
Best practices for avoiding missed or duplicate documents
- Separate technical and business status. A 997 functional acknowledgment reports whether the receiver's syntax check accepted or rejected a document. It does not mean an order or its contents were accepted.
- Check before reprocessing. Before requeuing an invoice or order, determine whether the receiving system already processed it. A retry without that check can create duplicates.
- Trace open work across the boundary. An order received before the switch may produce a shipment and invoice afterward. Keep its references visible to both teams.
- Keep partner rules in view. Validate the document version, expected response and timing against that partner's published EDI implementation guide.
- Give finance a signoff role. Finance should confirm invoice ownership and totals, while operations checks order and shipment outcomes.
These controls also help reduce the risk of chargebacks, an industry problem when partner expectations and transaction records do not align. They make a cutover review more useful than a simple count of files sent and received.
Keep partner requirements separate from ERP changes
BOLD VAN's BOLD Integration maps EDI data into and out of ERP, WMS and other systems. That includes SAP, Oracle ERP, Infor CloudSuite and others. Where a connected platform uses an API instead of EDI, integration can translate in either direction between EDI and that platform's API. The platform's own documentation governs implementation-specific details.
For a cutover, separating partner-facing requirements from ERP-specific mapping can limit the changes each partner needs to test. Our US-based team can work through map revisions as the target ERP path is validated. New maps are typically ready to test in about two days. When a trading partner changes its requirements, we update the map, and minor changes are typically handled at no cost.
The practical finish line is a reconciled set of orders, shipments and invoices, with each open exception assigned and each production route accounted for. If you are planning an ERP transition, review how BOLD Integration can connect the new system while you test the EDI flow.
Frequently asked questions
What is parallel EDI reconciliation during an ERP cutover?
It is the comparison of representative EDI transactions processed through the legacy and target ERP paths. You compare business results while keeping one authorized production route for each partner and outbound document type.
How do you reconcile EDI orders after an ERP migration?
Match each source purchase order to its translated data and ERP record. Compare references, parties, items, quantities, units, dates and posting status, then investigate missing or duplicate records.
Does an EDI 997 mean a purchase order was accepted?
No. A 997 functional acknowledgment reports whether the receiver's syntax check accepted or rejected the document. It does not establish that the business accepted the order or its contents.
How can you avoid duplicate invoices during ERP cutover?
Assign one production sender for each partner's 810 invoices. Before sending or reprocessing an invoice, compare its reference and status with the ERP billing record and check whether it was already delivered.
