WMS Integrations: Ecommerce, ERP, Shipping and EDI Guide

Why WMS Integrations Matter

A warehouse management system can only be as accurate as the data moving into and out of it. When the warehouse operates apart from the platforms that create orders, plan purchasing, ship packages and bill customers, people bridge the gaps by hand. That manual work is slow, and the errors it introduces spread into finance, customer service and retail partner relationships.

WMS integrations replace those hand-offs with defined data flows. Each system keeps doing its own job, and the records it shares arrive in a structure the receiving system can act on. The aim is not to wire everything to everything. It is to decide which system owns each record, then make sure all the others get an accurate copy.

The Cost of Disconnected Systems

Disconnected systems tend to produce the same problems:

• Re-keyed orders: staff copy orders from carts, marketplaces or emails into the WMS, adding labor and typos.
• Inventory mismatches: storefronts and the ERP show stock the warehouse does not have, which leads to oversells and backorders.
• Missed or late shipments: orders sit unreleased because nobody noticed they arrived.
• EDI chargebacks: retailers fine suppliers for missing or inaccurate ASNs, labels or invoices.
• Slow month-end close: accountants reconcile shipments and invoices across spreadsheets.

Any one of these looks minor. Together, they cap how many orders a team can handle before it needs more headcount. They also hide the real cause of a problem, because a late shipment might trace back to a typo made three steps earlier in a different department.

What a Connected Warehouse Looks Like

Picture a hypothetical facility where demand from every channel lands in the warehouse system without re-entry. Item masters come from a single source, so SKUs, units of measure and barcodes match everywhere. Receipts and fulfillments post back to the ERP, giving purchasing and accounting a true view of floor activity. Packers generate carrier labels at the station, and tracking numbers flow back to the sales channel. Retail partners receive compliant EDI documents. When a record fails to sync, someone sees an exception and fixes it before a customer notices.

The Five Integration Categories

Most warehouses need connections in five areas:

1. Ecommerce carts and marketplaces
2. ERP and accounting systems
3. Shipping carriers
4. EDI trading partners
5. An API for custom and niche third-party connections

Named connectors are shown on the integrations page. The sections below cover each category in turn, including what data moves in each direction and what to check before you buy.

Ecommerce Carts and Marketplaces

For online brands, and for the 3PLs that ship on their behalf, the storefront is where nearly every order begins. Sphere WMS lists connectors for Shopify, BigCommerce, Magento, WooCommerce and other carts on its integrations page, plus Amazon for marketplace sellers. The role of shopping cart software is narrow: it captures the order and the payment, then hands fulfillment to someone else.

That handoff is the whole point. Orders move into the warehouse system, and stock levels plus shipment confirmations travel back to the channel. The basic loop rarely causes trouble. The edge cases do:

• Partial shipments. When one line ships today and another is backordered, does the cart mark the order as partially fulfilled with the correct tracking number attached?
• Cancellations. A customer cancels twenty minutes after checkout. Does that change reach the floor before a picker pulls the item?
• Order edits. Address corrections and swapped sizes should update the open order, not create a second one.
• Shared inventory. If three storefronts sell from a single stock pool, the quantity each channel displays has to reflect what the others just sold.

How a connector handles these situations decides whether your team spends the afternoon packing or reconciling. When comparing wms integrations, ask vendors to demonstrate all four cases rather than only a clean, single-item order. Accurate order data also shapes floor work directly, and our pick and pack fulfillment guide covers what happens once an order lands.

This section stays short on purpose. For cart-by-cart detail, see our article on integrating a WMS with ecommerce platforms.

Ecommerce Data Flow at a Glance

• Sales orders: move inbound to the WMS. The cart or marketplace owns them.
• Customer ship-to details: arrive attached to each order, supplied by the shopper through the storefront.
• Available inventory: goes outbound to each channel. The WMS owns this figure (or the ERP, if it is the inventory system of record).
• Shipment confirmation and tracking numbers: sent back out after packing, with the warehouse system as owner.
• Cancellations and order edits: come in from the selling channel, ideally before picking starts.

If an ERP is also in the picture, settle one routing question early: do orders pass through the ERP first, or go directly from the storefront to the warehouse? Both designs work. Running both at once is how teams end up with duplicate orders, so choose a single path and document it for everyone who touches the setup.

ERP and Accounting Integrations: NetSuite as the Worked Example

In most companies the ERP is the financial system of record. It holds customers, vendors, pricing, purchasing and the general ledger. The WMS holds what physically happens in the building: where stock sits, what arrived, and what was picked, packed and shipped. A sound ERP connection respects that split rather than letting both platforms edit the same records. For background on how warehouse software sits next to an enterprise resource planning suite, see our comprehensive guide to WMS software.

NetSuite works well as an example because many SMB and mid-market distributors and ecommerce brands run on it. Its record types (items, purchase orders, sales orders, item receipts, item fulfillments, invoices) also line up neatly with warehouse events. Sphere WMS offers a NetSuite connector, and its integrations page names SAP, JD Edwards and QuickBooks as well. Whatever the ERP, the order of work is the same: settle ownership first, then map the direction each record travels.

Which System Should Own Each Record

A practical ownership model for most operations:

• Item masters: the ERP owns SKU, description and cost. The WMS adds bin locations, lot or serial tracking and pick rules.
• Purchase orders: created in the ERP, received against in the WMS.
• Sales orders: created by the ERP or the sales channel, fulfilled by the warehouse.
• Receipts: the WMS records what actually came in and reports it back.
• Fulfillments: the WMS records shipped quantities, cartons and tracking numbers.
• Invoices: generated by the ERP from that shipment detail.

When two platforms both believe they own on-hand quantities, mismatches follow. Choose one source of truth for inventory and make the other a reader.

NetSuite Integrations: Data-Flow Table

Each record below moves in one direction only. Read it as a map of who sends what:

• Item master: NetSuite sends SKU, description, UOM and cost. Nothing returns.
• Vendors and customers: NetSuite supplies reference data used on receipts and orders.
• Purchase orders: come down from NetSuite as expected receipts.
• Item receipts: travel up from the warehouse with received quantities, lots and any discrepancies.
• Sales orders: NetSuite passes down orders to fulfill.
• Item fulfillments: the WMS returns shipped quantities, tracking and carton details.
• Inventory adjustments: cycle count and damage corrections post from the floor back to the ledger.
• Invoices: created inside NetSuite from fulfillment data, so they never originate in the warehouse.

Notice the pattern. Master data and planned transactions flow down from the ERP, while records of physical events flow up from the floor.

During a demo, request a live run of each item. Create a PO in NetSuite, receive it on the warehouse floor, and confirm the receipt posts back with correct quantities and lots.

Notes on SAP, JD Edwards and QuickBooks

The ownership model holds across ERPs, but scope differs:

• SAP and JD Edwards: frequently found at larger or multi-site manufacturers and distributors. Expect more complex item structures, plant or branch codes and stricter posting rules. Check how the connector maps warehouses and locations.
• QuickBooks: typical for smaller businesses whose main need is accounting. The connection usually centers on items, orders and invoices rather than full purchasing workflows. Confirm which records are covered.

For any of these, ask which specific transactions are supported for your ERP version before you commit.

Shipping Carriers and EDI Trading Partners

Carrier and EDI connections sit at the outbound edge of the warehouse, where errors are most expensive. A wrong label sends a package to the wrong place. A missing ASN can trigger a retailer chargeback. Both rely on structured data the warehouse system already holds: order lines, carton contents, weights and ship-to addresses.

Sphere WMS connects to UPS, FedEx and USPS for shipping, and it supports EDI transactions for retail trading partners. These links matter even more for 3PLs managing many clients with different carrier accounts and retailer rules, a topic our 3PL logistics WMS overview covers in depth.

Rating, Labels and Tracking with UPS, FedEx and USPS

A carrier exchange during pack-out usually involves four records:

• Package details (weight, dimensions, service level): sent by the WMS for rating and label creation.
• Rates: returned by the carrier so a packer or a shipping rule can pick a service.
• Shipping labels: delivered in the carrier response, ready to print at pack-out.
• Tracking numbers: arrive from the carrier and are stored on the shipment.

After the tracking number lands on the shipment, the WMS can pass it to the cart, marketplace or ERP, so customers and accounting see the same information. Printing labels at the pack station also eliminates the separate shipping desk where someone re-keys addresses and introduces typos.

Core EDI Transactions: 850, 856 and 810

EDI (electronic data interchange) is a standard format for exchanging business documents between trading partners. Retailers use numbered transaction sets defined by the X12 standard:

• 850 Purchase Order: the retailer's order to you. It flows into your ERP or warehouse system.
• 856 Advance Ship Notice (ASN): tells the buyer what each carton and pallet contains before the freight arrives. It originates in the warehouse, because only the floor knows how goods were actually packed.
• 810 Invoice: bills the retailer for what shipped, usually generated from ERP data after fulfillment.

Of the three, the 856 depends most on warehouse software. It needs accurate carton-level packing data and labels that match it.

How EDI Compliance Protects Against Chargebacks

Large retailers publish routing guides with strict rules for ASN timing, label formats and carton contents. A missing ASN, a late one, or cartons that differ from it can all lead to chargebacks that chip away at margin.

When the ASN is built from scans captured during packing, the document reflects what actually left the dock. That match between physical cartons and the electronic record is the heart of compliance. When comparing wms integrations for EDI, ask each vendor how partner-specific requirements are configured, how rejected documents are flagged, and who is responsible for fixing them.

The API and Other Third-Party Integrations

No vendor ships a prebuilt connector for every system a warehouse touches. Many operations also run custom order portals, niche marketplaces, robotics, BI tools or a homegrown ERP. An API (application programming interface) fills that gap. It is a documented way for outside software to read and write warehouse data under defined rules.

Building on an API gives you control over what connects, which records move and when. As you evaluate a platform, look for an API that can link systems falling outside the prebuilt connectors. If you are still sorting out the core job of warehouse software, this overview of WMS basics is a useful starting point.

When Prebuilt Connectors Are Not Enough

The API route makes sense when:

• You sell through a channel that has no ready-made connector.
• Your ERP is custom built or heavily modified.
• Your 3PL clients need to push orders from their own software.
• You want warehouse data flowing into a reporting or analytics platform.
• A standard connector handles most flows but misses one critical transaction.

Picture a distributor with its own B2B ordering portal. Through the API, the portal could send new orders into the warehouse system and pull shipment status back, so buyers can check progress without calling customer service.

What a WMS API Should Expose

At a minimum, the interface should cover the same records discussed in earlier sections:

• Items and their attributes
• Inventory levels by location
• Inbound orders and receipts
• Outbound orders, shipments and tracking numbers
• Order status updates

Beyond coverage, check the quality of the documentation, how authentication works, whether error responses explain what went wrong and whether a sandbox or test environment exists. An API that exposes only some of these records tends to force manual workarounds later, such as rekeying receipts or exporting spreadsheets by hand.

Connecting Custom or Niche Systems

Before anyone writes code, map each flow on paper. For every record, note which system owns it, which direction it travels, what event triggers the sync and what should happen when a call fails. A failed order push, for instance, needs an alert and a retry plan rather than a silent gap that surfaces days later as a missed shipment.

Next, decide who builds and maintains the connection: your IT team, an integration partner or the vendor. Custom wms integrations need a named owner after go-live, because the software on both ends will keep changing through upgrades, new fields and retired endpoints.

How to Evaluate WMS Integration Depth Before You Buy

A logo on a vendor's integration page proves that a connection exists. It does not tell you which transactions the connection carries, whether data travels both ways, or what happens when a sync fails. Use the questions below in demos and reference calls to test how deep each connection goes.

Start with your own data flows. List every system you run today and the records each one sends and receives. Then have the sales team walk through those exact flows instead of giving a canned tour.

Supported Transactions and Data Direction

For each connected system, confirm:

• Which record types are covered: items, purchase orders, receipts, sales orders, fulfillments, inventory adjustments, invoices and EDI documents.
• Whether each flow is one-way or two-way. With two-way sync, a change made in either system appears in the other. With one-way sync, data moves in a single direction only.
• Which platform owns each record as the source of truth.
• How partial shipments, backorders, cancellations and returns are treated.

Error Handling and Visibility

Ask the vendor to break something on purpose. Send an order with an unknown SKU, or have the ERP reject a fulfillment, and watch what follows.

• Where does the error surface, and who gets notified?
• Can warehouse or office staff fix and resend a failed record without calling IT?
• Is there a log showing what synced and when?

Silent failures are the biggest risk in any connection. Nobody notices them until a customer calls about a missing order.

Connector Ownership and Maintenance

Find out who built and maintains each connector: the WMS vendor, the other platform, or a third party. When a cart or ERP changes its API, ask who repairs the connector and how fast. Also ask whether those repairs are covered under your agreement or billed separately. A connector built by an outside developer may work well on day one, but you want a clear answer about who answers the phone when it stops working.

Multi-Client and 3PL Support

Third-party logistics providers have extra requirements. Ask whether each client can link its own cart, marketplace or ERP account, whether data stays separated by client, and whether billable activity can be tied back to the right client. Confirm how mixed setups work, such as one client sending orders over EDI while another submits them through the API.

Questions to Ask in a Demo

• Trace an order from my sales channel to shipped status, with tracking posted back to the channel.
• Receive a NetSuite (or other ERP) purchase order in the warehouse system and post the receipt back.
• Build an ASN from actual packing data.
• Trigger a failed sync and let a regular user resolve it.
• What does your API expose, and where is its documentation published?
• Which of these wms integrations are live today with operations similar to ours?

To see these flows on your own data, Request a Demo with Sphere WMS.