Connecting Your ERP to Your 3PL: What Actually Has to Sync, and What Goes Wrong

An ERP to 3PL integration is narrower than most people expect. Only five things genuinely need to move: product master data and purchase orders go out to the warehouse, and goods receipts, dispatch confirmations and stock adjustments come back. Everything else is optional. The integration usually takes two to six weeks depending on the ERP and the cleanliness of your product data, and the failures are almost never technical. They are unit of measure mismatches, incomplete SKU masters, and disagreement about which system is the authority on stock. Settle that last question first and most of the rest resolves itself.

One Question Decides the Whole Design

Before anyone writes a line of integration code, agree which system is the single source of truth for physical stock.

The answer should almost always be the warehouse system, because the warehouse is where the stock physically is and where it gets counted. The ERP holds the financial and commercial record and receives movements from the warehouse. When brands invert this and treat the ERP as the stock authority, every physical count becomes an argument, and the integration spends its life reconciling two numbers that were never going to agree.

This sounds like a philosophical point. It is the most practical decision in the project, and the one that determines whether the integration is calm or permanently noisy.

What Actually Has to Sync

Five flows cover the majority of real world integrations. The rest is optional and should be treated as optional, because every additional flow is something that can break.

Flow	Direction	What it carries	Typical frequency
Product master	ERP to 3PL	SKU, description, barcode, dimensions, weight, batch and expiry flags	On change, or daily
Purchase orders	ERP to 3PL	What is arriving, from whom, expected quantities	On creation
Sales orders	ERP to 3PL	Only where orders originate in the ERP rather than a sales channel	Near real time
Goods receipt	3PL to ERP	What actually arrived against the purchase order, with discrepancies	On receipt
Dispatch confirmation	3PL to ERP	What shipped, when, with which tracking reference	On dispatch
Stock adjustments	3PL to ERP	Cycle count results, damages, write offs	Daily or on event

Two things worth noting. First, the sales order flow is often unnecessary: if orders arrive from Shopify, Amazon or Noon directly into the fulfillment platform, routing them through the ERP first adds a hop and a failure point for no benefit. Second, goods receipt is the flow brands under specify most often, and it is the one that causes the most downstream pain, because it is where purchase order quantities meet reality.

The Three Ways It Gets Built

Approach	How it works	Suits
Native connector	A pre-built integration maintained by the platform vendor	Common ERPs where a connector already exists. Fastest and cheapest to run
Middleware	An integration platform sits between the two systems and maps fields	Complex mappings, multiple systems, or where you want to own the logic
Custom API build	Direct point to point development against both APIs	Unusual requirements or an ERP with no available connector

Commercially available fulfillment platforms typically offer pre-built connectivity to the major ERP and accounting systems, including SAP, Oracle NetSuite, Microsoft Dynamics NAV and Xero. If your ERP is on that list, start there rather than scoping a custom build, and ask two questions: who maintains the connector when the ERP releases an update, and is that maintenance billed to you.

A custom build is sometimes genuinely necessary. It is also the option most likely to become an orphan, working perfectly until the person who built it leaves and the first API change breaks it. If you go that route, make sure the documentation and the credentials are yours.

The Six Things That Actually Go Wrong

1. Unit of measure mismatches

The most common failure in the entire category, and the most expensive. The ERP holds a SKU in cases, the warehouse holds it in eaches, and nobody notices until stock is out by a factor of twelve. Agree the base unit of measure for every SKU, in writing, before go live, and test specifically for SKUs that are sold in more than one configuration.

2. An incomplete product master

Missing dimensions and weights are not a data tidiness issue. They determine storage charges, carrier rate selection and whether an order can be packed automatically. An integration that passes a product master with blank fields will technically succeed and operationally fail.

3. Timing and sequence

A dispatch confirmation that reaches the ERP before the goods receipt for the same stock creates a negative inventory position, which some ERPs handle gracefully and some do not. Agree the sequence and the retry behaviour, and make sure messages that fail are queued and visible rather than silently dropped.

4. Nobody owns the error queue

Every integration produces failed messages. The question is whether a named person looks at them daily. The usual pattern is that failures accumulate unnoticed for weeks, then surface as a stock discrepancy nobody can explain. Assign the error queue to a person on your side and a person on the provider side, by name, before go live.

5. Returns are forgotten

Returns are scoped last and specified least. A returned unit needs to reach the ERP as a stock movement with a reason code, otherwise your ERP believes it sold goods that are physically back on the shelf. Decide at design time how returns post, and whether restocked and written off returns are distinguishable.

6. Two systems both think they are in charge

The failure that follows from not answering the first question in this article. If both systems adjust stock independently, they will diverge, and no amount of integration work will stop it. One authority, one direction of travel for stock movements.

A Realistic Timeline

Stage	Typical duration	What happens
Scoping	3 to 5 days	Agree which flows are in scope, which system owns stock, and field mappings
Data preparation	1 to 2 weeks	Clean the product master, fix units of measure, fill dimensions and weights
Build or configure	1 to 3 weeks	Connector configured or integration built, depending on approach
Testing	1 week	End to end tests on real SKUs, including deliberately broken cases
Parallel run	3 to 10 days	Both systems updated, discrepancies investigated daily
Go live and stabilisation	1 to 2 weeks	Live operation with the error queue monitored daily

The variable that moves this timeline most is not the ERP. It is how clean your product master is on day one. Brands with accurate dimensions, consistent units of measure and no duplicate SKUs are live in a fortnight. Brands without spend three weeks on data before the build starts.

What to Test Before You Go Live

Testing the happy path proves very little. The tests that matter are the ones that break things on purpose.

• A purchase order that arrives short, and one that arrives over

• A SKU sold in two different units of measure

• An order for a SKU with no stock

• A partial dispatch, where some lines ship and some do not

• A return that is restocked, and one that is written off

• A cycle count adjustment flowing back into the ERP

• A deliberately malformed message, to confirm it lands in the error queue rather than disappearing

• The same message sent twice, to confirm it does not duplicate the stock movement

That last one catches a surprising number of integrations. Retries happen, and an integration that is not idempotent will double count the first time a network hiccup causes one.

Do You Even Need This?

Worth asking honestly, because a meaningful proportion of brands who scope an ERP integration do not need one yet.

If your order volume is modest, your SKU count is manageable and your finance team is comfortable importing a daily movement file, a scheduled file exchange does the same job at a fraction of the cost and complexity. It is less elegant and it is entirely adequate. The point at which a real integration earns its cost is usually when the manual reconciliation starts consuming someone's day, or when the lag between physical and financial stock starts affecting decisions.

A provider who tells you that you need a full integration before you have that problem is selling a project. The right answer for a lot of growing brands is to start with file exchange and build the integration when the pain is real.

How We Handle This

Eshopify Fulfillment operates on an enterprise order management and warehouse management platform with pre-built connectivity to the major ERP and accounting systems. For most brands that means configuration rather than development, which is the difference between a fortnight and a quarter.

The practical sequence we work to is the one above: agree stock authority first, clean the product master before building anything, test the failure cases rather than the happy path, and name the people who own the error queue on both sides. Our published operating accuracy is 98% inbound, 98% outbound and 99% inventory accuracy, and that number only holds because the stock record is maintained in one place rather than reconciled between two.

If you are not sure whether you need a full integration yet, we will tell you. A scheduled file exchange is the right answer more often than anyone selling integrations will admit.

Send us your ERP and a sample of your product master and we will tell you what the integration actually involves.

Frequently Asked Questions

What needs to sync between an ERP and a 3PL?

Five flows cover most real integrations: product master data and purchase orders going out to the warehouse, and goods receipts, dispatch confirmations and stock adjustments coming back. Sales orders are a sixth, but only where orders originate in the ERP rather than arriving directly from a sales channel. Everything beyond these is optional and each additional flow is something that can break.

Which system should hold the stock record, the ERP or the warehouse?

The warehouse system, in almost all cases, because that is where the stock physically sits and where it is counted. The ERP holds the financial and commercial record and receives movements from the warehouse. When the ERP is treated as the stock authority, every physical count becomes a dispute and the integration spends its life reconciling two numbers that will never agree.

How long does an ERP to 3PL integration take?

Two to six weeks for most brands. Scoping takes a few days, data preparation one to two weeks, build or configuration one to three weeks, then testing, a parallel run and stabilisation. The variable that moves the timeline most is not the ERP, it is how clean your product master is: accurate dimensions, consistent units of measure and no duplicate SKUs can halve the project.

What is the most common cause of stock mismatches after integration?

Unit of measure mismatches. The ERP holds a SKU in cases while the warehouse holds it in eaches, and nobody notices until stock is out by a factor of twelve. Agree the base unit of measure for every SKU in writing before go live, and test specifically for SKUs sold in more than one configuration.

Which ERPs integrate with fulfillment platforms?

Commercially available fulfillment platforms typically offer pre-built connectivity to the major systems, including SAP, Oracle NetSuite, Microsoft Dynamics NAV and Xero. If your ERP is on that list, start with the existing connector rather than scoping a custom build, and ask who maintains it when the ERP releases an update and whether that maintenance is billed to you.

Do I need a full integration or is a file exchange enough?

A scheduled file exchange is adequate for a lot of growing brands and costs a fraction of a real integration. The point at which a full integration earns its cost is when manual reconciliation starts consuming someone's day, or when the lag between physical and financial stock starts affecting decisions. Before that, a provider telling you that you need an integration is selling a project.

What should I test before going live?

The failure cases, not the happy path. Test a purchase order that arrives short and one that arrives over, a SKU sold in two units of measure, a partial dispatch, a restocked return and a written off return, a cycle count adjustment, a deliberately malformed message, and the same message sent twice. That last test catches integrations that double count on a retry.