Skip to main content
Talk to an expert
SPS Commerce logo

SPS Commerce integration for B2B and procurement commerce

B2B orders routed through SPS Commerce cleanly iWeb connects SPS Commerce with your commerce platform, ERP and OMS so that purchase orders, acknowledgements, ASNs and invoices flow without loss or delay. Buyer-specific pricing and approval workflows stay governed and synchronized. 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.

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

What a SPS Commerce integration gives you.

Fast and accurate order acknowledgement

Buyers receive a confirmation of their purchase order within minutes, showing delivery commitment and any changes to quantity or date. This reduces buyer follow-up calls and sets clear expectations for both teams.

Visibility into shipment status and tracking

Once goods ship, the buyer sees the ASN and tracking information in their procurement system without manual intervention. Receiving teams can plan unloading and inspection with confidence.

Correct pricing and approval handling

Each buyer's contract pricing and approval thresholds are applied consistently. Orders that should be auto-approved are approved without delay, and those that need escalation are flagged early.

Clean invoice and payment reconciliation

Invoices are transmitted in the buyer's expected format and timing, reducing dispute and accelerating payment. Remittance advice from the buyer flows back to your cash team automatically.

Resilience across ERP downtime or change

When your ERP is down for maintenance or upgrade, purchase orders queue safely in SPS Commerce and are processed in order once the ERP returns. No orders are lost or duplicated.

02 · When it's worth it

Where a SPS Commerce integration earns its place.

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

Receive purchase orders via cXML, OCI or EDI from buyer procurement systems
Route POs to ERP or OMS for validation, stock check and acknowledgement
Publish order acknowledgements, ASNs and invoices back to the buyer portal
Handle contract pricing lookup and buyer-specific discount validation
Manage approval workflows and cost-centre rules before orders enter fulfilment
Reconcile purchase orders, invoices and remittance against ERP accounts
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.

Buyer-specific pricing logic not built into SPS Commerce

SPS Commerce can store contract prices and discounts, but complex approval workflows, cost-centre rules and multi-tier pricing require custom logic in your ERP or OMS. Without clear ownership, pricing disputes and approval failures become invisible.

No native handling of split or conditional shipments

When a PO cannot be fulfilled in full from a single location, SPS Commerce does not automatically route to multiple warehouses or suppliers. The OMS or ERP must decide the split, and the integration must coordinate multiple ASNs back to the buyer.

Limited visibility into approval workflows across systems

If approval rules live in both ERP and SPS Commerce, they can drift independently. A PO approved in one system but rejected in another will confuse the buyer and the fulfilment team.

EDI format customisation requires mapping and testing

Each buyer may require different EDI dialects (EDIFACT, X12, PEPPOL) or cXML variants. SPS Commerce can handle multiple formats, but message customisation, segment ordering and validation rules must be tested thoroughly before launch.

Invoice and credit note timing gaps with ERP

If the ERP invoice generation is delayed or the timing between the invoice and SPS Commerce transmission is not synchronised, the buyer receives the document after they expected it, causing reconciliation delay and payment hold.

04 · The real work

Slow or missing acknowledgements and ASN delays are often the result of trying to route every PO through the same ERP validation path; separating early acknowledgement from longer ERP checks removes a major friction point in B2B order flow.

05 · Where it sits

Where this integration sits in your estate.

SPS Commerce 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. SPS Commerce sits at the centre of your estate, not at the edge of one platform.

System of record
Source / owner
SPS Commerce
B2B procurement message hub and EDI transformation layer
  • EDI and cXML message receipt and transmission
  • Purchase order validation and format mapping
  • Order acknowledgement workflow coordination
  • ASN and despatch notification transmission
  • Invoice and remittance format handling
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceBigCommerceOther storefronts
  • PO visibility and status querying in customer portal
  • Order context and buyer account linkage
  • Initial PO routing decision (OMS vs ERP path)
Connected neighbours
Integration layer
ERP
Validates stock, credit and delivery dates; owns pricing truth and approval rules; generates invoices and credit notes; provides financial reconciliation.
Integration layer
OMS
May hold initial PO and route to warehouse or supplier; orchestrates split shipments and dropship handling; coordinates ASN generation.
Integration layer
WMS
Generates ASN and despatch events; manages shipment tracking and carton counts; reports stock movements back to ERP.
Integration layer
Customer Master / CRM
Holds buyer account, contract pricing, approval limits and buyer-specific terms that iWeb looks up during order processing.
Integration layer
Buyer Procurement System
External system where the buyer submits purchase orders and receives acknowledgements, ASNs and invoices; may be SAP Ariba, Coupa, Jaggr or custom.
Integration layer
Accounts and Cash
Receives invoices and remittance advice from SPS Commerce; reconciles purchase orders, invoices and payments.
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)
  • Adobe Commerce
  • Magento Open Source
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • ERP (SAP, NetSuite, Infor, Dynamics 365)
  • OMS (order management system)
  • WMS (warehouse management system)
  • Customer master / CRM
  • Procurement portal (buyer-side)
  • Accounts and cash reconciliation
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 COMMERCE & ERP
←From ERP
↔BOTH WAYS
Purchase order intake via EDI or cXML: Purchase orders arrive from buyer procurement systems via cXML, OCI, EDIFACT, X12 or PEPPOL
The integration captures PO number, buyer reference, line items, quantities and delivery instruction, routing them to the commerce platform or OMS for immediate visibility and validation.
Order acknowledgement and stock check: The PO moves into ERP or OMS for stock availability, delivery-date confirmation and credit-limit check
The system confirms or amends the delivery window and returns an 850 order acknowledgement back through SPS Commerce to the buyer.
ASN and despatch confirmation to buyer: Once goods are picked and packed at the warehouse, the WMS or ERP sends ASN (advance shipment notice) and despatch detail back through SPS Commerce
The buyer receives tracking, carton counts and expected delivery in the format their procurement system expects (cXML, EDI or PEPPOL).
Invoice and remittance reconciliation: The ERP generates the invoice and sends it through SPS Commerce to the buyer
The buyer's procurement system returns remittance advice or payment confirmation, which flows back to ERP accounts and cash reconciliation.
Contract pricing and approval rules: Buyer-specific pricing, volume discounts and approval thresholds are maintained in SPS Commerce and made available to ERP at order-entry time
iWeb ensures the right price is locked before the order enters fulfilment.
Returns and credit notes via EDI: When a buyer initiates a return or disputes a charge, the credit-note request flows through SPS Commerce to ERP
Once the return is inspected, the credit note is sent back to the buyer in their required EDI format.
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
    Design buyer-specific EDI and cXML mappings

    iWeb defines the exact message format, segment sequence and validation rules for each buyer. Testing is done against sample orders from the buyer's procurement team before the first production PO arrives.

  2. 02
    Orchestrate order acknowledgement and PO routing

    iWeb builds the acknowledgement path so that fast, early confirmation is separated from longer-running ERP stock checks and credit validation. Buyers see confirmation immediately; ERP processes in its own rhythm.

  3. 03
    Manage contract pricing and approval workflows

    iWeb documents which system owns the pricing truth, builds the lookup logic, and handles caching and refresh so that every PO is priced correctly before it enters fulfilment.

  4. 04
    Handle ASN, invoice and remittance timing

    iWeb coordinates the despatch event from WMS, ensures the ASN is transmitted to SPS Commerce at the right moment, and manages the invoice transmission timing so the buyer receives all documents in the expected sequence.

  5. 05
    Build monitoring and exception queues

    iWeb creates observability so that unacknowledged POs, failed message transmissions and approval rejections are visible in a central queue. On-call teams know immediately if a buyer's order is stuck.

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 intake and acknowledgement
Source / ownerSPS Commerce / OMS
Maintained byProcurement integration team
NotesSPS Commerce receives and holds the PO until acknowledgement is sent. OMS or ERP validates stock and delivers the acknowledgement back. iWeb ensures the acknowledgement is fast and cannot be lost.
DataContract pricing and buyer-specific discounts
Source / ownerERP or SPS Commerce (depends on design)
Maintained bySales operations and pricing team
NotesiWeb documents which system owns the pricing truth and manages the lookup and refresh cycle. Contract changes are loaded once and reused for every PO from that buyer.
DataApproval and cost-centre rules
Source / ownerERP
Maintained byFinance and credit team
NotesiWeb ensures approval thresholds and cost-centre validation are defined once in ERP and are not duplicated or overridden in SPS Commerce.
DataASN, despatch and tracking information
Source / ownerWMS / ERP
Maintained byWarehouse and logistics team
NotesThe WMS generates the ASN event and ERP forwards it to SPS Commerce. iWeb handles the timing and format transformation so the buyer sees the shipment in their procurement system.
DataInvoice and remittance
Source / ownerERP
Maintained byAccounts and credit team
NotesERP generates the invoice and sends it to SPS Commerce in the buyer's required EDI format. Remittance from the buyer flows back to ERP accounts for cash reconciliation.
DataReturns and credit notes
Source / ownerERP
Maintained byWarehouse and returns team
NotesiWeb ensures that return requests from the buyer are routed to the warehouse and returns process, and that the resulting credit note is sent back to the buyer without loss.
DataIntegration transport, message format and exception handling
Source / owneriWeb integration layer
Maintained byiWeb and integration team
NotesiWeb owns the mapping, transmission timing, retry logic, message validation and exception queues. All EDI or cXML transformation happens here, keeping legacy ERP code unchanged.
10 · Experienced integrator

Built this integration pattern before

iWeb has designed and supported B2B procurement integrations through SPS Commerce across multiple industries. We understand how purchase orders, contract pricing and approval workflows need to flow between multiple systems, and how to isolate message format and timing concerns from business logic.

We map EDI and cXML transformation separately from ERP logic so that pricing, approval and returns can be updated without touching core trading code.
We design acknowledgement and ASN transmission paths that are independent from ERP processing, so buyers see fast confirmation regardless of backend load.
We coordinate split shipments, dropship orders and returns across OMS, WMS and ERP so that the buyer sees one coherent order even when fulfilment is distributed.
We build monitoring and exception queues so that unacknowledged POs, failed transmissions and approval rejections are visible and actionable on day one.
11 · Before launch

What we test before launch.

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

Test EDI message parsing and validation against sample POs from each buyer to ensure no segments are dropped or misinterpreted.
Verify that purchase order acknowledgements are generated within 60 seconds of arrival, independent of ERP availability.
Confirm that split shipments generate multiple coordinated ASNs with the same PO reference so the buyer sees them as one order.
Validate that contract pricing and buyer-specific discounts are applied consistently on every PO from each buyer.
Test ERP outage recovery by stopping the ERP, submitting a PO, restarting ERP, and confirming the queued PO is processed without duplication.
Verify that returns and credit-note requests are routed to the correct team queue and do not disappear without trace.
Confirm that invoice transmission timing matches buyer expectations and that invoices can be matched to ASNs by the buyer's system.
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.

Purchase orders stuck between procurement and ERP

If the PO acknowledgement workflow is not clearly separated from the ERP order-entry workflow, acknowledgements can be delayed waiting for stock or credit checks. The buyer sees no confirmation, assumes the order was not received, and resubmits or calls.

Pricing or approval rules drift between SPS Commerce and ERP

If contract pricing or approval thresholds live in both systems and are updated independently, one system can approve an order that the other rejects. The PO either fails silently in ERP or is acknowledged but then rejected, confusing the buyer.

EDI format changes or missing validation

When a buyer's procurement system is upgraded or a new buyer joins with a different EDI variant, message format changes can break the mapping without warning. Orders fail to parse, and the integration team is left debugging segment errors in production.

Split or dropship orders losing ASN coordination

When a PO is split across multiple warehouses or suppliers, each location must generate its own ASN. If the ASNs are not coordinated through SPS Commerce with the same PO reference, the buyer receives fragments of the shipment without visibility to the whole.

Invoice timing or format mismatch with buyer reconciliation

If the ERP invoice is generated after the goods are already received and the ASN has been sent, or if the invoice format does not match the buyer's expected EDI standard, the buyer cannot match invoice to receipt and payment is withheld.

Returns or credit-note requests lost in queues

When a buyer initiates a return or disputes a charge, the message arrives in SPS Commerce but no one in your team is assigned to process it. Credit-note requests pile up, and the buyer's accounting sees an unresolved charge.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about SPS Commerce integrations.

How does SPS Commerce fit into our B2B procurement flow?

SPS Commerce is the hub through which purchase orders arrive from buyer procurement systems (in cXML, EDI or PEPPOL format) and through which acknowledgements, ASNs and invoices are sent back. Your commerce platform or OMS may hold the PO initially; ERP validates and processes it; and SPS Commerce handles the format conversion and transmission timing. iWeb designs which system does what and ensures nothing is lost.

Do we handle pricing and approval in SPS Commerce or ERP?

That depends on your design. Contract pricing can live in SPS Commerce or ERP; iWeb documents the choice and ensures lookups are fast and consistent. Approval workflows typically live in ERP (against your credit and cost-centre rules), but SPS Commerce can hold pre-approval rules for auto-approved lines. iWeb ensures both systems stay in sync.

What happens if a buyer's EDI format changes?

iWeb maintains the EDI mapping in the integration layer, not in your ERP or commerce platform. When a buyer upgrades their procurement system and their EDI variant changes, iWeb updates the mapping, tests it against sample orders from the buyer, and rolls it out. Your ERP code and data structures stay unchanged.

How quickly can a buyer expect an order acknowledgement?

iWeb separates the acknowledgement path from the ERP validation path. A fast acknowledgement is sent within seconds of the PO arriving, showing order receipt and delivery commitment. ERP stock and credit checks run in parallel, and if changes are needed, a revised acknowledgement is sent before the PO enters fulfilment.

What if ERP is down when a purchase order arrives?

The PO is held safely in SPS Commerce and the acknowledgement is queued. Once ERP returns, the queued orders are processed in sequence without duplication or loss. iWeb ensures the recovery path is automatic and monitored.

How do we handle split shipments across multiple locations?

iWeb coordinates with your OMS or warehouse system to split the PO across locations. Each location generates its own ASN (advance shipment notice), and iWeb ensures all ASNs reference the same original PO so the buyer sees them as fragments of one order, not multiple unrelated shipments.

When should the invoice be sent to the buyer?

Invoices should be transmitted after goods are despatched and the buyer has received the ASN. iWeb ensures the timing is synchronised so the buyer can match ASN to invoice and receipt. If goods are delivered in multiple shipments, invoices may be consolidated or sent per shipment depending on the buyer's requirement.

How do returns and credit notes flow back through SPS Commerce?

When a buyer initiates a return or disputes a charge, SPS Commerce receives the request and iWeb routes it to the warehouse or returns team. Once the return is inspected and the credit note is authorised by ERP, iWeb sends the credit note back to the buyer in their required EDI format. The process is monitored so no request is lost.

What data validation happens before a PO enters the ERP?

iWeb applies mapping and format validation to ensure the EDI or cXML message is correct, buyer reference matches, line items have valid SKUs and quantities are within reason. If validation fails, the PO is flagged and the integration team is alerted before the ERP sees a malformed order.

Who owns the integration monitoring and exception queues?

iWeb builds the exception handling and observability. Unacknowledged POs, failed message transmissions, pricing mismatches and approval rejections appear in a central queue. Your integration team checks the queue regularly and resolves issues before the buyer has to call.

Can we use the same SPS Commerce configuration for all buyers?

No. Each buyer may have different EDI dialects, approval thresholds, price tiers and delivery requirements. iWeb maintains buyer-specific configurations in SPS Commerce and ensures the right one is applied to each incoming PO. Changes to one buyer's rules do not affect others.

What happens if a buyer's procurement system sends a duplicate PO?

iWeb builds idempotency logic so that if the same PO number arrives twice (due to a network retry or buyer error), only one order is created in your system. Duplicate acknowledgements are suppressed. The buyer is protected from accidentally ordering twice.

How often should we reconcile SPS Commerce, ERP and the buyer's system?

iWeb can generate daily reconciliation reports showing all POs received, acknowledged, invoiced and paid. Mismatches (a PO acknowledged in your system but showing as pending at the buyer) are flagged for investigation. Monthly reconciliation catches long-running issues.

What if we need to support a new buyer with a different protocol (punchout, cXML, X12)?

SPS Commerce supports multiple protocols. iWeb tests the new buyer's EDI or cXML variant against sample orders, updates the mapping, and rolls it live. The configuration change is isolated to the new buyer and does not affect existing buyers.

Next step

Have a SPS Commerce 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 →