Seven Things to Settle Before You Connect a WMS to Your ERP

Connecting a warehouse system to the ERP you already run is less a technical project than a sequence of decisions: which system owns each field, how fast each record moves, and who is allowed to change a mapping after go-live.

This guide walks the seven decisions in the order they come up, from the first planning meeting through the first month after go-live. It is written for the operations and IT leads who already run an ERP and are working out whether to put a warehouse layer underneath it, and what that project will ask of them.

The Seven Decisions, in Short

Most of the work in a project like this is not connectivity. It is agreement. The ERP stays the financial and purchasing system of record. The warehouse system owns the physical work on the floor, receiving through shipping. What sits between them is a written agreement about which side wins for each field, and how quickly each side hears about a change.

These are the seven decisions that determine whether that agreement holds:

How an ERP and a warehouse system divide the work
What actually changes once the two are connected
Where these projects go wrong, and what prevents it
The rollout sequence, in order
How far the connection bends around workflows you already run
What training and post go-live support have to cover
What to measure once it is running

Questions to Settle Before the Project Starts

Direction of truth, field by field. Decide which system owns item master, cost, on-hand quantity, and order status. These projects fail on ownership disputes far more often than on connectivity.
Sync trigger and latency. Establish whether inventory and order updates are event driven or polled on a schedule, and what happens to the queue when the ERP is unavailable.
Who can change a mapping. Decide which mappings and rules your own team can edit without a vendor ticket, because requirements move after go-live.
Error handling you can see. Ask to be shown a failed message live: where it lands, who is alerted, and how it is replayed.
Your ERP specifically. Named ERP, named version, named connector. A general claim of universal integration is not an answer.

The mechanics of the connection itself, what syncs, in which direction, and how fast, are covered on our page about connecting a warehouse system to your ERP, store, and carriers. This guide stays on the planning side of the same project.

How an ERP and a Warehouse System Divide the Work

What is an ERP System?

An ERP (Enterprise Resource Planning) system is the financial and purchasing backbone. It holds the general ledger, purchasing, vendor records, costing, and usually the item master. When a controller asks what a unit cost or what has been committed to a vendor, the answer comes from the ERP.

ERPs are built around records and accounting periods, not around people moving boxes. That gap is what a warehouse system fills.

What is a WMS?

A WMS (Warehouse Management System) owns the physical work: receiving against a purchase order, putting stock away to a location, directing picks, packing, and producing the label. It tracks where an item is in the building, not only how many exist.

The practical test is whether your people are told what to do next by the system or by a printed sheet and their own memory. That is the line between an ERP with an inventory table and an actual warehouse operation running on software.

Why the Split Matters

Once both systems exist, every field belongs to one of them. Cost belongs to the ERP. Bin location belongs to the warehouse system. On-hand quantity is the contested one, and it needs an explicit decision rather than a default.

A workable rule: whichever system the change physically happens in should own the field. Stock moves in the building, so the warehouse system reports the count and the ERP receives it. Vendor cost changes in a purchasing conversation, so the ERP owns it and the warehouse system reads it.

What Changes Once the Two Systems Are Connected

Re-Keying Stops

The most visible change on day one is that nobody types the same order twice. Orders land once, move through the warehouse, and return to the ERP with what actually shipped. The staff who used to reconcile two screens get that time back, and the errors that came from typing are removed rather than caught later.

One Inventory Number Instead of Several

Before the connection, most operations run at least two counts: what the ERP believes and what the floor knows. After it, there is one number with a known refresh cadence. The cadence matters more than the phrase real time, which is why sync trigger and latency belong in the planning questions rather than in the demo.

Where the Savings Actually Come From

Savings on these projects come from three places: labor spent on re-entry and reconciliation, orders that no longer ship wrong, and stock held as a buffer against a count nobody trusts. We do not publish a savings percentage or a payback period, because both depend entirely on how much manual work you are doing today. Measure your own baseline before the project and the same figures after. That comparison is the only honest one.

Where These Projects Go Wrong

The Common Failure Points

Dirty data carried across. Item masters with duplicate SKUs, units of measure that disagree, locations that exist on paper only. Migration does not clean data. It copies what you have into a system that will now act on it.

No named owner per field. When both systems can write the same field and nobody decided which one wins, the last writer wins by accident. That surfaces weeks later as inventory drift nobody can reproduce.

A connector only the vendor can change. Requirements move. If every mapping change is a services ticket, the connection slowly stops matching how you work.

What Prevents Them

Clean before you migrate. Deduplicate SKUs, agree on units of measure, delete locations you do not use. Do this while it is still a spreadsheet problem.
Write the ownership map down. One row per field, one system named as owner, agreed by operations and finance together before configuration starts.
Pilot one area. One zone or one order type, running both directions, before the whole building moves.
Ask to see a failure. Have the vendor break a message on purpose during the demo and show you the queue, the alert, and the replay.

Three Builds Worth Reading

Three SkuNexus customers describe this same shape of project on their own pages, each under a different constraint.

Graeter's Ice Cream arrived with inventory data scattered across systems, manual fulfillment, and software that would not bend. The build covered receiving, inventory, order routing, fulfillment, and shipping, including packing rules specific to shipping ice cream and user roles cut to match how their departments already worked.
Carewell needed vendor dropshipping to stop being a series of email threads. Their build connects BigCommerce, raises purchase orders to vendors automatically, and keeps every vendor in one place, so adding a vendor does not mean inventing a new process.
New Look Vision Group ran Magento 2 alongside an ERP, a POS, and a CMS, and needed pick, pack, and ship automated across a retail network. Elena Pomazanova, President of Cyper, the implementation partner, called the modular code akin to working with legos.

The Rollout Sequence, in Order

Planning and Preparation

Start with the outcome, stated in terms someone on the floor would recognize. "Cut mis-picks" and "stop re-keying orders from the ERP" are goals you can test after go-live. "Improve efficiency" is not.

Then pick the systems. If you are still choosing the ERP side, our ERP evaluation walkthrough covers that half. If the warehouse side is the open question, start from what the warehouse and inventory layer has to own.

Implementation

Kickoff. Scope, timeline, and named owners on both sides, including someone from finance who can settle a field-ownership argument.
Data migration. Move the cleaned item master, locations, and open orders. Reconcile counts before anything else is turned on.
Configuration. Build the workflows, user roles, and mappings against how the building actually runs, not against a reference implementation.
Training. Train on the real workflow with real SKUs, not on a sandbox catalog.
Pilot. Run one zone or one order type end to end and fix what the pilot exposes.

Testing and Go-Live

Test the paths that hurt, not the happy path: a partial receipt, a short pick, a cancelled order that already had a label, an ERP outage mid-sync. Those are the cases that decide whether go-live week is calm.

Keep a written go-live checklist, keep the old process available for the first days, and watch the error queue rather than the dashboard. Nobody finds problems in a summary chart.

How Far the Connection Bends Around Your Workflows

Most integration disappointment is not a missing feature. It is a connection that only works one way, the vendor's way. The question to ask is which parts of the flow you can change yourselves after go-live: order routing rules, packing rules, user roles, field mappings, and what triggers a sync.

Graeter's is the clearest example on our own customer list. The dry ice packing rules and the department-specific roles were not switches in a settings page. They were built for that operation, and they have kept changing since. That is what to test for in a demo: ask the vendor to change something in front of you.

Scale is the same question over a longer horizon. Adding a warehouse, a channel, or a product line should be a configuration exercise. If the answer to "what happens when we open a second building" is a new project, that is worth knowing before you sign.

Training and Support After Go-Live

A warehouse system is only as good as the people using it at 6am on a Monday. Training has to cover the exception, not just the standard pick, because the exception is where staff fall back to paper and the data starts to drift.

Three things worth agreeing in advance: who your team calls when a sync fails, how updates are scheduled around your peak season, and who retrains new hires once the vendor's onboarding team has moved on. That last one is usually left unassigned and is the reason a good rollout degrades in year two.

What to Measure Once It Is Running

Pick a small number of measures and take a baseline before go-live, otherwise you will have opinions instead of evidence.

Order cycle time. Receipt of order to handed to carrier.
Inventory accuracy. Cycle count variance by location, not a site-wide average that hides the problem aisles.
Error rate. Mis-picks, short ships, and address failures, counted per thousand orders so growth does not flatter you.
Exception volume. How many orders needed a human decision. This is the number that tells you whether the rules are right.

Review the error queue monthly with the people who work it. The operational gains a warehouse system is supposed to deliver show up in these four measures or they are not real.

FAQs

What is WMS and ERP?

A WMS (Warehouse Management System) manages and controls warehouse operations, from receiving and storing goods to picking and shipping orders. An ERP (Enterprise Resource Planning) system holds the wider business processes, such as finance, purchasing, and vendor records, in one platform. The WMS owns the physical work, the ERP owns the money.

What is WMS integration?

WMS integration means connecting a warehouse management system to other software systems, such as an ERP, an online store, or a carrier account, so data moves between them without anyone re-keying it. Done properly it gives one inventory number, one order record, and one place to look when something is wrong.

What is ERP system integration?

ERP system integration is the process of connecting an ERP to other business software, such as a WMS, a CRM, or an ecommerce platform. The point is that every department works from the same records, so a shipment on the floor and a receivable in the ledger describe the same event.

What is WMS ERP integration?

It is the connection between warehouse management and enterprise resource planning, in which the ERP keeps finance and purchasing while the warehouse system runs receiving through shipping, and the two exchange orders, inventory, and fulfillment results on an agreed cadence with an agreed owner for each field.

Can we integrate TMS & WMS with ERP?

Yes. A TMS (Transportation Management System) can sit alongside both, taking shipment data from the warehouse system and returning rates, labels, and tracking. The thing to settle early is which system owns the carrier selection decision, because if two systems both think they choose the carrier, the shipment gets rated twice.

What is ERP in a warehouse?

ERP in a warehouse usually means using the ERP's own inventory and order modules to run the building. That works while the operation is one site with low volume and no scan enforcement. It stops working when you need directed putaway, location-level accuracy, or picking that adapts to the order profile.

What businesses benefit most from ERP WMS integration?

Operations with high order volume, many SKUs, or more than one place to ship from benefit most, because those are the conditions under which manual reconciliation stops scaling. Retail, ecommerce, distribution, and B2B wholesale are the common shapes. A single-site operation shipping a modest number of orders a day is usually better served by tightening the ERP it already runs.

How long does the integration process typically take?

It depends on three things far more than on the software: the condition of your item and location data, how many systems are being connected, and how much of the workflow is specific to you. A single warehouse with clean data and one storefront is a different project from a multi-site rollout with an ERP, a POS, and vendor dropshipping. Ask any vendor to break their estimate into data preparation, configuration, pilot, and go-live, and to say which of the four they have seen slip most often.

What to Do Next

Take the seven decisions above in order. Write the field-ownership map first, because it needs no software and it exposes disagreements that otherwise surface during go-live week. Then get your item and location data clean while it is still a spreadsheet problem. Then, and only then, look at connectors.

If you want the decisions walked through against your own ERP and order flow, book a live SkuNexus demo and we will map the integration path for the systems you already run, including the parts that will need building.

About the Author

Yitz Lieblich is the founder and CEO of SkuNexus. He has worked in ecommerce since 2007, founded the ecommerce agency Web Solutions NYC in the same year, and started SkuNexus in 2018 to give merchants an operational platform they could actually change. He has worked with merchants from mom-and-pop startups to Fortune 100 operations across auto parts, food and beverage, apparel, B2B wholesale, and retail, and has spent a lot of hours on warehouse floors watching where the software gets in the way.