The Short Answer

ERP integration is the work of making your ERP and your other systems agree about the same facts — what stock exists, what a given customer pays, what has been ordered, what has been invoiced — without anyone retyping those facts by hand.

That is the whole idea. The ERP remains the system of record. Integration is what keeps everything else honest about what the ERP says.

The reason it is harder than it sounds is that two systems rarely mean exactly the same thing by the same word. Your ERP has a notion of a customer, a price and an order. So does your website. They are not the same notion, and the gap between them is where the actual work lives.

What Actually Moves Between the Systems

For a wholesale business, integration usually covers six kinds of record. It is worth being specific, because "we'll integrate the ERP" is not a scope — this is:

  • Products — the catalogue, its structure, and which items a given customer is even allowed to see
  • Inventory — what is available to promise, which is not the same number as what is on the shelf
  • Prices — including customer-specific price lists, which is where wholesale diverges sharply from retail
  • Customers — accounts, contacts, credit terms, and which of them may log in
  • Orders — placed on the website, landing in the ERP as though a person had keyed them
  • Invoices — flowing back the other way, so the customer can see their account without phoning

Most projects begin by discussing the first three and are surprised by the last three. Orders and invoices are where the ERP's rules are strictest, because they touch money.

The Four Ways It Gets Built

Almost every integration in this market is one of four things. They are not equally good, but each is the right answer somewhere.

1. Rekeying

A person reads one screen and types into another. It is not usually described as an integration strategy, but it is the one most wholesalers actually start with, and for a handful of orders a week it is entirely rational. It stops being rational at the point where the cost of a mistake exceeds the cost of preventing it — and that point arrives earlier than most teams notice, because the errors show up as credit notes and customer service time rather than as a line on an invoice.

2. File feeds

Scheduled exports and imports — CSV, or something like it, dropped somewhere on a timer. Unglamorous and genuinely useful. Feeds are robust, easy to reason about, and easy to re-run when something goes wrong. Their limitation is time: a feed that runs hourly means your website can be an hour wrong, and whether that matters depends entirely on what you sell.

3. Point-to-point connections

A direct link between two systems, built for that pair. Fast to deliver, and the most common thing sold as "an integration". The difficulty is what happens next: add a third system and you need three connections, a fourth and you need six. Each is separately maintained, and they tend to be built by different people at different times, so the rules end up encoded in several places that quietly disagree. We have written about why point-to-point integration accumulates risk as the number of systems grows.

4. An integration hub

One layer in the middle that every system connects to once, holding the mapping and the rules in a single place. More work up front and harder to justify when you have two systems. It earns its keep at the point where you have four or five and are still expecting to add more — which describes most wholesalers who have added a D2C site or a marketplace to an existing trade operation.

"Real-Time" Is Sold More Often Than It Is Needed

Real-time integration means a change in one system appears in the other within seconds, usually because the first system announces the change rather than waiting to be asked.

It is genuinely valuable for some records and close to pointless for others. Stock is the clear case: the cost of being wrong is a customer being promised something you cannot ship. Orders are a similar case, in reverse. But product descriptions, images and cost prices change slowly, and syncing them continuously buys you very little while adding something else to monitor.

A well-designed integration is usually mixed — real-time where a delay produces a wrong promise to a customer, scheduled everywhere else. If a supplier proposes real-time for everything, it is worth asking what that decision is protecting you from.

What Wholesalers Need That Generic Guides Miss

Most writing about ERP integration assumes a retail shape: one price, one customer type, stock either available or not. Trade businesses break all three assumptions, and the breakages are exactly where integrations tend to fail.

  • Price is per customer, not per product. The same item legitimately has many prices, and the website has to ask the ERP which one applies to whoever is logged in — before showing anything.
  • Not every customer may see every product. Catalogue visibility is a commercial rule, not a display preference, and it has to survive being wrong in the safe direction.
  • Ordering stock you do not have is normal. Back orders are routine in wholesale and awkward in software, because the website has to represent a promise the ERP is still tracking.
  • Accounts have terms. Credit limits, payment terms and account status all sit in the ERP and all affect what the website is allowed to let someone do.

None of this is exotic. It is simply the part that a generic connector, built for a retail shape, tends not to have an answer for.

Where It Actually Goes Wrong

In our experience the technical connection is rarely the thing that sinks an integration project. Two other things do.

Nobody owns it. When something behaves unexpectedly six months after launch, the delay is almost never diagnostic — it is working out who is entitled to decide the fix. This is worth settling before the build rather than during the incident; we have written about why ownership is the governance factor behind successful ERP projects.

Nobody planned for change. An integration that matched the business exactly on launch day will not match it a year later, because prices, channels and processes move. If no one has budgeted for that drift, it surfaces as manual workarounds that quietly reintroduce the rekeying you were trying to remove.

Where to Start

Three decisions are worth making before anyone writes any code, and none of them are technical:

  • Decide which system is authoritative for each record type — so there is an answer ready when two of them disagree, rather than a meeting
  • Name one accountable owner with the authority to settle disputes, not a committee
  • Write down the awkward cases — back orders, credit limits, customer-specific prices, part-shipped orders — because those are what integration projects actually argue about

If you are also trying to work out what this should cost, our ERP integration cost model sets out the six drivers that move the number and six questions that make competing supplier quotes comparable.

ERP Integration: Common Questions

What is ERP integration, in one sentence?

ERP integration is the work of making your ERP and your other systems agree about the same facts — what stock exists, what a given customer pays, what has been ordered and what has been invoiced — without anyone retyping those facts by hand. The ERP stays the system of record; integration is what keeps everything else honest about what the ERP says.

Is ERP integration the same as an API?

No, and conflating the two causes a lot of disappointment. An API is a door into a system. Integration is everything you build behind that door: deciding which system wins when two disagree, mapping one system's idea of a product onto another's, handling the record that fails at three in the morning, and knowing it failed. Most ERPs have had an API for years. That is why the API is rarely the hard part.

How long does ERP integration take?

The build is usually measured in weeks; the agreement about how the business should work is what takes months. In practice, the projects that run long are almost never held up by the technical connection — they are held up by questions nobody had settled beforehand, like what happens to an order for stock that is not there yet, or which system owns a customer's credit limit.

Do we need real-time integration?

For some things, and probably fewer than you would expect. Stock and orders usually justify it. Product descriptions, images and cost prices rarely do, and syncing everything continuously costs more and gives you more to monitor. A sensible design is real-time for the records where a delay causes a wrong promise to a customer, and scheduled for everything else.

What usually goes wrong with ERP integration?

Ownership, more often than technology. When something behaves unexpectedly six months in, the delay is rarely diagnostic — it is working out who is entitled to decide the fix. The second most common failure is that nobody planned for change: the integration matched the business precisely on the day it launched, and nothing was set up to keep it matching as prices, channels and processes moved.

What should a wholesaler get right before starting?

Three things, none of them technical. Decide which system is authoritative for each type of record, so there is an answer when two disagree. Name one person accountable for integration outcomes with the authority to settle disputes. And write down what happens in the awkward cases — back orders, credit limits, customer-specific prices, part-shipped orders — because those are what integration projects actually argue about.