ERP and WMS Integration: What Syncs, Which Direction, and How Fast

What integration gives you, and what it does not

An integration moves records between two systems on a schedule you set. That is the whole of it. It does not merge two databases, it does not make one a copy of the other, and it does not remove the need to decide who is right when they disagree. So every field that exists in both systems needs an owner and every entity needs a direction. Skip that and you get drift nobody can trace, because both sides are writing and both look correct in isolation.

ERP and WMS integration is the case worth stating carefully, because the two systems are not competing for the same job. The ERP holds the financial and commercial record: purchasing, cost, invoices, the ledger. A warehouse management system holds the physical record: locations and bins, receipts, allocations, picks, packs, cartons. Three things cross the line between them, and only three: orders, invoices, and inventory adjustments. If you want the category definitions first, how a WMS differs from an ERP covers them.

What actually connects, and what does not

Vendor logo walls are a weak signal, so here is the real list. SkuNexus has working connector adapters for Shopify, BigCommerce, Magento 2, WooCommerce, Shopware 6, Walmart, and QuickBooks Online. Each one takes platform credentials, tests itself on creation, and activates only if the test passes.

Two clarifications that vendors usually leave out:

• Amazon and eBay have no active adapter. They appear in some internal lists. Attempting to connect them will not work. If Amazon is a material channel for you today, that is a scoping conversation before anything else.
• QuickBooks Online is an accounting connector, not a sales channel. It syncs financial data. It does not bring you orders.

Carriers connect separately. A carrier record carries a provider (EasyPost or manual), your own account number with that carrier, and an API key, and carriers can be pulled straight from your EasyPost account. The account number matters more than the carrier list does: it is what makes rate comparison run against the rates you actually negotiated rather than published retail rates.

Everything else, including an ERP, is API work. Orders also arrive through the API and through EDI, with the source recorded on the order. See the integrations list for what ships configured.

How the sync actually runs: polling first, webhooks second

This is the part most integration pages get wrong, including some of ours before this rewrite.

Order ingestion is polling-primary. A background worker checks the external platform on the configured interval and pulls new orders. It is not webhook-driven. The default poll interval is 5 minutes for Shopify and 60 minutes for other platforms, and you can move it in either direction: higher to reduce API usage, lower for tighter ingestion.

Webhooks are registered where the platform supports them, on Shopify, BigCommerce, WooCommerce and Shopware. Their job is divergence detection, catching a change somebody made directly on the channel between polls. They supplement polling. They do not replace it.

So the honest latency statement is this: expect up to one poll interval between an order being placed on the channel and it appearing in the warehouse system. Anyone who answers "real time" to that question without naming an interval is describing a feeling, not a mechanism. If you need an immediate pull outside the schedule, Trigger Sync queues a job for one entity type and one direction on demand.

Sync direction, set per entity

Direction is not one switch for the whole connector. Each connector has a Sync Config tab where five entities are set independently.

Entity	Typical default	Options
Orders	Inbound	Inbound, Outbound, Bidirectional, Disabled
Products	Inbound	Inbound, Outbound, Bidirectional, Disabled
Inventory	Outbound	Inbound, Outbound, Bidirectional, Disabled
Customers	Inbound	Inbound, Outbound, Bidirectional, Disabled
Fulfillment	Outbound	Inbound, Outbound, Bidirectional, Disabled

Read that column of defaults as a sentence and you have the standard ecommerce contract: the channel owns the catalog and creates the order, the warehouse owns on-hand and reports what shipped. Two of the most common questions in demos are answered right here. If a merchant adds a product in Shopify, does it appear in the warehouse system? Yes, because Products is Inbound. If inventory changes in Magento, does it come back down? Only if you set Inventory to Inbound or Bidirectional, and in most operations you should not, because the warehouse is where receiving, picking and counting happen.

Set Inventory to Bidirectional and you have two writers. A cycle count corrects three units, the warehouse pushes the corrected number, the channel decrements on its own order flow, and now the number is wrong in a way nobody can reconstruct.

What happens when both sides change the same record

Direction settings do not cover the case where the same field was updated on both sides before a sync ran. That is a separate setting with three options.

• Source Wins. The external platform overwrites the warehouse value. This is the default for most connectors.
• Newest Wins. The most recently updated value wins, decided on timestamps.
• Manual Review. Conflicting records go to the Review Queue for a person to decide.

The third option is the one worth arguing about during scoping. Manual Review is the only one that admits a conflict happened. The other two resolve silently, which is fine for product titles and dangerous for quantities. Ask any vendor where losing values go. If the answer is nowhere, conflicts are being discarded rather than resolved.

Location mappings, and why inventory sync fails without them

The single most common reason inventory does not push is not an API failure. It is a missing location mapping.

A location mapping tells the platform which external channel location corresponds to which internal warehouse. Without at least one mapping in place, inventory will not push to the channel correctly. Each mapping names an external location, one or more warehouses whose combined on-hand is reported to that location, a priority for evaluation order, and an enable toggle.

The "one or more warehouses" part is the design decision. Stock is summed across every warehouse in the mapping. Map three buildings to one storefront location and the channel sees one blended number, which is correct for availability and useless for routing and delivery promises. Map them separately and the channel can tell where the unit is. Neither is wrong. Choosing by accident is.

Inventory push has its own guardrails on the same tab: Absolute or Delta sync mode, connector-level Safety Stock and Inventory Cap with per-listing overrides, and Floor at Zero so a negative quantity is never sent. A safety buffer set on both the channel and the warehouse applies twice, and you quietly stop selling stock you have.

Where this fits if your financial backbone is SAP, NetSuite, or Dynamics

Straight answer first: there is no native SAP, NetSuite or Dynamics adapter. QuickBooks Online is the only accounting connector documented in the product. ERP and WMS integration at that end of the market is build work against the API and the script extension points, which hook events like before and after order creation, after fulfillment completes, and on inventory change.

That is not a hedge, it is the position. On a recorded call, a logistics director running three US distribution centers on SAP put the requirement plainly: he wanted "something that can be utilized to run distribution centers and still communicate with the backbone of SAP." He was not shopping for an SAP replacement. He was explicit that SAP "does a good job, excellent job, honestly, of that financial side."

That is the shape of nearly every ERP conversation we have. The ledger stays. The floor changes. A NetSuite operation described generating build lists, pick lists and production documents out of NetSuite while having nothing that sized a carton. A Dynamics Business Central operation needed one thing from the integration: get the order in. A Dynamics AX evaluator, after seeing the field structure, said "all the fields you've shown us here, it's the fields we've got in Microsoft Dynamics AX as well," which is the actual precondition for an ERP integration going smoothly and is worth checking on your own field list before you scope anything.

If you are earlier than that and still choosing the ERP-side path, the ERP evaluation process and warehouse and inventory software are the two pages to read next. If the question is whether to extend the ERP instead, how this differs from customizing NetSuite or SAP answers it directly.

When your ERP warehouse module is already enough

Sometimes the honest answer is that you do not need this.

Stay on the warehouse module inside your ERP when the operation is one building, order volume is low enough that a person can hold the day in their head, there is no scan-enforced picking requirement, and you sell through a single storefront that the ERP already talks to. In that shape, adding a second system adds a sync contract, a conflict policy and a mapping table, and buys you very little. The module is not good, but it is sufficient, and sufficient is cheaper.

The line gets crossed when the warehouse stops being a stockroom. Multiple buildings, allocation and reservation logic, scan validation at pick and pack, carrier rate comparison, per-channel availability, kits assembled from components. ERP warehouse modules are usually built for the first shape and asked to do the second.

The SAP director above had already reached that line. He was moving from R3 to S4 HANA and said what he had seen of "S4 HANA, EWM, doesn't impress me." That is the buying trigger: not that the ERP is bad, but that its warehouse module was designed for a different job than the one your floor now does.

What a fragmented stack costs the people running it

Across 78 buyer-eligible SkuNexus demo calls, buyers themselves named at least one bolted-on third-party tool in 35 of them. It is one of the most common things a buyer describes without being asked.

What it sounds like in their words. An auto parts operation: "My guys have to go to this tool and then that tool and then this tool to get information to piece together the puzzle." A hobby retailer: "I think we use about five different software packages... None of the software communicates fully with each other." A shipping operation: "they're all kind of siloed within our business. They currently don't talk to each other, they don't integrate." And the version that states the goal rather than the pain: "it'd be sweet to be able to not have to work in so many different platforms. It just creates less errors by working in one system, from purchasing to receiving to shipping, everything."

Note what none of them said. Nobody asked for more integrations. They asked for fewer places to look.

An ERP integration that went live

New Look Vision Group, Canada's largest eyewear retailer, ran a web of data exchanges between a Magento 2 Community Edition storefront, their ERP, their POS and their CMS, which is what made any change feel risky. The implementation connected all four plus Canada Post, automated pick, pack and ship, and went live across 477 locations in nine months with no day of downtime. The consultancy that ran it described the code as "akin to working with legos." That is the whole claim, and their case study page is the source for it.

Where integrations break after go-live

Integrations rarely fail on launch day. They fail three weeks later, in ways that look like warehouse problems.

• Identifier mismatch. The channel SKU, the internal item code, the supplier part number and the UPC are four strings for one product. Nearly every unmatched order line traces back here. Reconcile identifiers before anything is built.
• Partial writes. The order lands but allocation fails, so it sits in a state nothing picks up. There has to be a queue and a named owner.
• Kits and bundles. The channel sells a bundle, the warehouse holds components. Decide which side does the availability math, because if both do, both are wrong.
• Reversals. Cancellations, refunds and returns need a defined path back through every system told about the original sale. This is the most commonly skipped item in an integration scope.
• Peak rate limits. Channel APIs throttle. An integration that is fine at 300 orders a day and queues silently at 3,000 is an incident with a date on it.

Two habits catch most of this. Read Sync History, which holds the last 25 sync jobs per connector with entity type, direction, status, record count and error message. And run the new path in parallel with the old one on real orders, compared daily, until the differences are explainable. Then cut over one channel at a time, and after that one warehouse at a time, so a rollback touches one thing.

Frequently asked questions

Which system is the source of truth for product and inventory data?

They usually split. The channel or the ERP owns the product record, because that is where a SKU is created commercially. The warehouse owns on-hand, because that is where receiving, picking and cycle counting happen. In connector terms that is Products set to Inbound and Inventory set to Outbound, which are the typical defaults. What matters is that each entity has exactly one writer.

Does the platform sync two-way with my ecommerce platform?

It can, per entity rather than as a single setting. Orders, Products, Inventory, Customers and Fulfillment are each set to Inbound, Outbound, Bidirectional or Disabled. Bidirectional is available on all five, and is the right choice on fewer of them than people expect, because two writers on one field is how drift starts.

Is inventory updated in real time across channels?

No, and be suspicious of anyone who says yes without naming an interval. Sync runs on a poll schedule, 5 minutes by default for Shopify and 60 minutes for other platforms, adjustable per connector. Webhooks on the platforms that support them catch changes made directly on the channel between polls. Plan for up to one poll interval of lag, and use Safety Stock to absorb it on fast-moving items.

Can we map custom product attributes and custom fields between systems?

Yes. Beyond the standard field mappings, connectors carry ID mappings between external and internal record IDs, carrier mappings between internal carrier names and the codes each platform expects, and location mappings. Where mapping alone is not enough, scripts hook platform events, including before and after order creation, after fulfillment completes, and on inventory change.

What are the first steps in planning a WMS integration?

List every system that touches an order or a unit of inventory, then go entity by entity and decide which system is the master for products, inventory, orders and shipments. Reconcile product identifiers across those systems before any code is written. Only then evaluate tools, because the ownership decisions determine which capabilities you actually need.

How do I choose the right WMS for integration with my existing ERP?

Check three things. Whether inventory adjustments made in the warehouse write back to the ERP without re-keying. Whether inventory syncs at SKU plus location granularity or only at SKU level. And whether warehouse work continues when the ERP is unreachable, because an integration that blocks picking during an ERP outage is a warehouse that stops. Ask to see API documentation during evaluation rather than after signing.

What are the signs that my current WMS integration isn't effective?

Recurring oversells, order lines that cannot be matched to a product, staff re-keying data between systems, availability numbers that disagree between channel and warehouse, and syncs that need manual restarts. Each traces back to an ownership or identifier problem rather than to a warehouse process problem.

How can small to medium businesses benefit from WMS integration?

The gain is mostly removed handoffs. Orders stop being exported and imported, inventory stops being reconciled by hand, tracking numbers stop being pasted between systems. For an operation without a dedicated systems team, that recovered time is usually worth more than any single feature.

Definitional questions about ERP and WMS as categories, including what each system is and how long a project typically runs, are answered on the ERP and WMS pairing post. The warehouse execution side, including how pick, pack and ship consumes what the integration delivers, is covered separately.

See it against your own stack

The useful version of this conversation is specific: your ERP, your storefront, your carrier accounts, and the one system nobody has a connector for. Book a demo and we will walk the entity-by-entity direction map for the stack you actually run, name the poll interval you would live with, and say plainly which parts would be configuration and which would be integration work.

Written by Yitz Lieblich, Founder and CEO of SkuNexus. In eCommerce since 2007; founded Web Solutions NYC in 2007 and SkuNexus in 2018. Product mechanics on this page come from the SkuNexus connector documentation; buyer quotes come from recorded sales calls.