Skip to main content
Talk to an expert
EDI logo

EDI integration for B2B and procurement commerce

Governed EDI purchase orders routed cleanly to ERP daily. iWeb maps buyer-specific EDI messages into your ERP with contract pricing, stock checks and approval workflows built in, so purchase orders are acknowledged accurately and invoices reconcile without rework. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: B2B integration, procurement, PunchOut, cXML, OCI, EDI, PEPPOL, account-based commerce.

EDIiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Magento Open Source · Adobe Commerce · SAP Commerce Cloud · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a EDI integration gives you.

Reliable purchase order flow

POs arrive cleanly into ERP without rework, with contract pricing validated and delivery dates confirmed before acknowledgement. Buyers see order status and ASNs without delay.

Buyer-specific pricing accuracy

Each buyer sees their contracted rates, volume discounts and approved SKU list in the procurement catalogue. Order lines are priced correctly at entry, reducing invoice disputes.

Clear order-to-cash visibility

Buyers can track PO acknowledgement, shipment and invoice in their own system. Invoices match POs and resolve quickly because mapping and reconciliation are governed.

Faster returns and corrections

Returns, cancellations and invoice corrections flow as structured EDI messages so buyer and seller both stay in step. No phone calls or email recovery.

Compliance and audit trail

All EDI exchanges are logged, timestamped and tied to ERP orders and invoices. Audit trails and exception reports support compliance reviews and dispute resolution.

02 · When it's worth it

Where a EDI integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Receive purchase orders via EDIFACT or ANSI X12 and route them to ERP for fulfillment
Publish buyer-specific pricing and contract terms to procurement platform catalogues
Send order acknowledgements and advance ship notices back to buyer systems
Exchange invoices and credit notes with buyer ERP and accounts payable
Validate POs against buyer approval rules and cost-centre constraints before acceptance
Handle returns, RMAs and invoice correction flows across procurement EDI channels
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

No automated buyer contract enforcement

Off-the-shelf EDI engines do not validate POs against buyer negotiated contracts, MOQs, lead times or cost-centre budgets. iWeb integrates contract rules from procurement or ERP so invalid orders are rejected before fulfillment.

Missing buyer-specific customisation

Each buyer may use different EDI versions, document structures, UNS segments or line-item references. Generic EDI tools do not automatically adapt. iWeb builds buyer-specific mappers and routing rules so each account works cleanly.

No clear exception ownership

Failed sends, mismatched quantities, missing ASNs or rejected invoices create silent queues. Off-the-shelf EDI does not define who owns the retry, escalation or fallback decision. iWeb names the owner and builds the queue workflow.

Pricing and availability gaps

Procurement systems need access to available inventory and contract pricing. Generic EDI tools do not publish real-time stock or enforce buyer-specific discounts at order time. iWeb connects ERP stock and pricing feeds to the procurement catalogue.

Invoice reconciliation drift

Invoices sent via EDI may not match ERP order quantities, pricing or cost centres. Buyer AP systems reject or hold invoices. iWeb monitors invoice-to-order matching and flags mismatches before send.

04 · The real work

Many organisations assume EDI is purely about message format, but the real friction lives in pricing validation, approval workflow, exception ownership and catalogue sync—areas where EDI tooling is often silent.

05 · Where it sits

Where this integration sits in your estate.

EDI holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Platform-agnostic by design. EDI sits at the centre of your estate, not at the edge of one platform.

System of record
Source / owner
EDI
Structured purchase order, acknowledgement and invoice exchange layer between procurement, ERP and seller systems
  • EDI message definitions (EDIFACT, ANSI X12, cXML) and format rules
  • Message validation and routing logic
  • Buyer-specific customisations and protocol variants
  • EDI send / receive logs and delivery status tracking
  • Exception and fallback queuing workflows
iWeb integration layer
Customer-facing commerce
Commerce platform
Magento Open SourceAdobe CommerceSAP Commerce CloudOther storefronts
  • Order capture from storefronts and call centres
  • Customer account and contract pricing display
  • Cart and checkout for online buyers
  • Customer-initiated returns and order status queries
Connected neighbours
Integration layer
ERP
System of record for inventory, orders, pricing, invoices and cost-centre approval. iWeb maps EDI messages to and from ERP order, receipt and finance tables.
Integration layer
Procurement system
Buyer-side order initiation and approval. iWeb receives POs via EDI and publishes catalogue updates, pricing and order status back to procurement.
Integration layer
Warehouse management
WMS generates ASN and dispatch confirmation. iWeb maps warehouse shipment data into EDI format for buyer receipt and reconciliation.
Integration layer
Order management
Optional OMS layer for routing, hold and exception management. iWeb integrates OMS validation rules into EDI acceptance workflow.
Integration layer
Accounts receivable
Finance team receives and processes invoices sent via EDI. iWeb validates invoice content against PO and receipt to reduce AP rejections.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Magento Open Source
  • Adobe Commerce
  • SAP Commerce Cloud
  • Other storefronts
Surrounding systems (examples)
  • SAP ERP
  • Oracle NetSuite
  • Microsoft Dynamics 365
  • Infor M3
  • Procurement platform (Coupa, Ariba, Jaggr)
  • Order management system
  • Warehouse management system
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into ERP
←From ERP & FULFILLMENT
↔BOTH WAYS
Purchase order ingestion: POs arrive via EDIFACT 96A, ANSI X12 850 or cXML OCI
iWeb maps buyer references, line items, pricing, delivery dates and approval metadata into ERP order lines, then routes for fulfillment or exception handling.
Order acknowledgement: ERP generates 997 functional acknowledgements and 855 purchase order acknowledgements, confirming receipt, availability and promised delivery dates back to the buyer system in their required format.
Advance ship notice: WMS or ERP dispatch confirms ASN 856 with actual shipment details, tracking, serial numbers and carton content
iWeb maps warehouse reality back to buyer systems so procurement can reconcile.
Buyer catalogue and pricing: Buyer-specific pricing, contracts and product availability flow from procurement or a master source into ERP pricing tables
iWeb ensures buyer accounts see only contracted SKUs and negotiated rates.
Invoice and credit note: ERP generates invoices and credits in EDIFACT 96A or ANSI X12 810/811 format, mapped to buyer document numbers and cost centres
iWeb handles retransmission of failed sends and orphaned invoice tracking.
Purchase order status and exceptions: Order status queries, cancellations and change requests flow bidirectionally
iWeb manages hold queues, escalation triggers and fallback notification when systems diverge.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Buyer-specific message design

    iWeb interviews each buyer to understand their EDI version, message variants, custom segments and routing rules. A mapper is built so that buyer's POs flow cleanly into your ERP without re-keying or manual translation.

  2. 02
    Contract and approval integration

    iWeb connects buyer account records, negotiated pricing, MOQs, lead-time policies and approval workflows from your ERP or procurement system into the EDI validation layer. Orders that breach contract terms are held for review instead of causing fulfillment rework.

  3. 03
    Exception queue and escalation

    iWeb designs named exception queues for missing ASNs, quantity mismatches, pricing disputes and orphaned invoices. Escalation rules, retry schedules and fallback notification ensure failures surface to the right owner.

  4. 04
    Real-time stock and pricing feeds

    iWeb publishes available inventory and buyer-specific pricing from ERP to the procurement catalogue. Buyers see real constraints at order entry, reducing invalid orders and delivery disappointments.

  5. 05
    Invoice reconciliation and matching

    iWeb maps order, receipt and invoice data so financial reconciliation is automated. Invoices are validated against PO quantities, prices and cost centres before send, catching mismatches before buyer AP systems reject them.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataPurchase order messages (EDIFACT 96A, ANSI X12 850, cXML OCI)
Source / ownerBuyer procurement system
Maintained byBuyer or their trading partner
NotesiWeb maps inbound POs to ERP order format and validates against seller contract rules, pricing and inventory.
DataOrder acknowledgement and functional confirmation (997, 855)
Source / ownerSeller ERP
Maintained bySeller operations / order entry
NotesiWeb generates acknowledgements from ERP and maps them back to buyer EDI format, ensuring receipt confirmation and promised dates are accurate.
DataAdvance ship notice and dispatch confirmation (EDIFACT 96A, ANSI X12 856)
Source / ownerSeller WMS or ERP
Maintained bySeller fulfillment / warehouse
NotesiWeb maps WMS shipment reality to buyer ASN format so procurement can track actual dispatch and trigger receiving.
DataInvoice and credit note (EDIFACT 96A, ANSI X12 810/811)
Source / ownerSeller ERP finance
Maintained bySeller accounts receivable
NotesiWeb validates invoice amounts against PO and receipt, maps cost centres and buyer references, then routes to buyer AP system.
DataBuyer catalogue, pricing and contract terms
Source / ownerBuyer procurement system or seller master data
Maintained byBuyer procurement or seller sales operations
NotesiWeb publishes seller inventory, pricing and availability to buyer systems so POs are placed only for available, correctly-priced items.
DataPurchase order status, hold, cancel and change requests
Source / ownerBuyer procurement (status inquiry); Seller ERP (fulfillment state)
Maintained byBuyer procurement or seller order management
NotesiWeb routes status queries bidirectionally and enforces change policies so cancellations and amendments are agreed before fulfillment or shipment.
10 · Experienced integrator

Built B2B EDI flows before

iWeb has designed and built EDI integrations for manufacturing suppliers, trade distributors and consumer brands sending and receiving POs, ASNs and invoices at scale. We understand how EDI sits between procurement systems, ERPs and warehouse operations, where ownership ambiguity and exception handling typically cause the most friction.

Mapped multiple EDI standards (EDIFACT, ANSI X12, cXML) for different buyers so one seller can handle protocol variants without rework
Built contract pricing and approval validation into EDI acceptance workflows so invalid orders are caught before fulfillment
Designed exception queues and escalation rules so failed sends, inventory gaps and invoice mismatches surface to the right owner
Integrated real-time stock and pricing feeds from ERP to procurement catalogues so buyers see accurate availability at order entry
Implemented invoice-to-order-to-receipt matching and three-way reconciliation so financial records and buyer AP systems stay clean
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Test PO receipt, validation, 997/855 acknowledgement and ERP order creation for each buyer message variant.
Verify contract pricing enforcement: confirm POs that breach buyer negotiated rates are held in exception queue, not accepted.
Confirm cost-centre and approval-code validation rejects invalid combinations and escalates to operations.
Test ASN generation from WMS, mapping to buyer EDI format and confirmation of receipt from buyer system.
Validate invoice-to-PO-to-receipt matching: confirm invoice amounts, line quantities and cost centres match before EDI send.
Test exception escalation: confirm failed EDI sends, missing ASNs, pricing mismatches and orphaned invoices surface to named owners.
Confirm buyer catalogue is synced with ERP stock and pricing at defined frequency; test buyer sees real availability at order entry.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Silent purchase order loss

A PO arrives via EDI but the 997 acknowledgement fails to send back to the buyer. The buyer assumes the order was received; your ERP has the order. The mismatch goes unnoticed until shipment. iWeb monitors send confirmations and escalates failed acknowledgements.

Contract pricing not enforced

A buyer PO line arrives with a price that does not match their negotiated contract. ERP accepts it at the wrong price. Invoice is sent at the wrong rate. Buyer AP rejects it. iWeb validates every line against contract terms before acknowledgement.

Mismatched ASN and receipt

ASN says 100 units shipped; invoice says 110. Buyer received 95. WMS thinks 100 is in transit. Financial and inventory records drift. iWeb enforces ASN-to-receipt-to-invoice matching so numbers stay consistent.

Buyer catalogue stale or incomplete

Procurement system shows SKUs that are discontinued or out of stock. Buyer places POs for unavailable items. iWeb keeps the buyer catalogue in sync with ERP inventory and pricing so stale data does not create invalid orders.

Unowned exception escalation

An invoice correction arrives via EDI but no one is assigned to approve it. It sits in a queue for weeks. Buyer escalates via email. A fallback manual process kicks in. iWeb names the owner and automates the escalation so exceptions surface quickly.

Approval workflow silent drops

A PO arrives with a cost-centre code that does not exist in ERP or the buyer's approval system. The order is neither accepted nor rejected; it hangs. iWeb validates cost centres and approval metadata at entry and escalates invalid combinations.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about EDI integrations.

Which EDI standards does iWeb support?

iWeb supports EDIFACT (ORDERS 96A, DESADV 96A, INVOIC 96A), ANSI X12 (850, 855, 856, 810, 811), cXML (OCI, PunchOut, order confirmation and invoice), and emerging standards like PEPPOL BIS. Each buyer may use a different standard; iWeb designs buyer-specific mappers so your system handles multiple protocols cleanly.

How do we ensure a PO is not lost between the buyer and our ERP?

iWeb monitors PO receipt, validates it against contract rules, generates a 997 functional acknowledgement and a 855 purchase order acknowledgement, and logs timestamps for each step. If the acknowledgement fails to send, an alert triggers so the sales team can intervene. ERP order and EDI receipt are tied together so nothing goes missing.

How do buyer-specific prices and terms get enforced?

iWeb integrates contract data from your ERP or procurement system into a validation layer. When a PO arrives, each line is checked against the buyer's negotiated pricing, MOQs, lead times and approved SKU list. Lines that breach contract terms are held for review instead of being accepted at the wrong price or quantity.

What happens if a PO arrives with invalid cost centres or approval codes?

iWeb validates cost-centre and approval-code references against your ERP and the buyer's account setup before acknowledging the order. Invalid combinations are flagged in an exception queue and escalated to the operations team so the buyer can be asked to correct the PO before fulfillment begins.

How do we keep the buyer's procurement catalogue in sync with our inventory?

iWeb publishes available stock and buyer-specific pricing from your ERP to the procurement catalogue on a defined schedule (hourly, daily or event-driven). The buyer sees real availability and negotiated rates at order entry, reducing invalid orders for out-of-stock or discontinued items.

How do ASN, receipt and invoice numbers stay linked?

iWeb maps PO number, line reference, receipt number and invoice number across all EDI messages. When an ASN is generated, it references the PO and expected delivery. When goods are received, the receipt is matched to the ASN. When an invoice is sent, it references the receipt and PO so the buyer can reconcile three-way match without manual effort.

What happens if an invoice does not match the PO or receipt?

iWeb validates invoices against the PO line quantities, prices and cost centres, and against receipt quantities, before the invoice is sent via EDI. Mismatches are flagged in an exception queue so accounts receivable can review and correct the invoice before it reaches the buyer's AP system, avoiding rejection and payment delays.

How do we handle purchase order cancellations and changes?

iWeb routes cancellation and amendment requests from the buyer EDI system to your order management layer. If the order has already been fulfilled or shipped, the cancellation is escalated to customer service. If the order is still in planning, the change is applied and a revised acknowledgement is sent back to the buyer.

How do returns and credit notes flow back to the buyer?

iWeb maps return authorisations (RMAs) from your ERP or order management system into EDI format (EDIFACT 96A, ANSI X12 820 or similar). When goods are received and inspected, a credit note is generated in EDI format and sent to the buyer AP system, tied to the original PO and invoice so the buyer can reconcile the credit.

What visibility does the buyer have into order status?

iWeb logs every state change (PO received, acknowledged, in-pick, in-pack, shipped, delivered) and maps them to buyer EDI queries and subscriptions. The buyer can query order status in real time, or iWeb can push status updates automatically when significant milestones occur (shipment, delivery).

Who owns the exception queues and escalation rules?

iWeb defines exception types (missing ASN, price mismatch, cost-centre invalid, acknowledgement failed) and names the owner for each one (sales operations, accounts receivable, order management, customer service). Escalation thresholds and fallback notification channels are agreed before launch so exceptions surface quickly to the right team.

How do we know if an EDI message failed to send?

iWeb monitors every outbound EDI message (acknowledgement, ASN, invoice) and logs a delivery status. If a send fails (network error, validation error, buyer system offline), an alert is generated and the message is queued for retry. Manual interventions and fallback channels (email, phone) are triggered if retries exceed a threshold.

What happens during a system outage or network failure?

How do we replatform or migrate EDI to a new ERP?

iWeb maps the EDI layer to the new ERP's order, pricing and invoice structures during replatform. Testing includes PO validation, acknowledgement timing, ASN and invoice matching, and exception queue operation. Dual-running or parallel validation may be used during cutover so that orders moving through the old and new systems stay in sync.

Next step

Have a EDI integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →