5 signs your ERP and webshop are secretly fighting

An ERP and a webshop set up by different people at different times often look like they work together. Orders come in. Invoices go out. Stock levels update, eventually. Most days, nothing obviously breaks.

But somewhere inside the business, people are compensating. Someone re-checks prices before orders ship. Someone exports a CSV every Friday because nobody trusts the dashboard. Someone keeps a spreadsheet of “special cases” the system can’t handle. Someone else reconciles invoices by hand at month-end.

Each of these is a signal that two systems which should be operating as one are running in parallel. Every time they disagree, a human has to pick a side. Here are the five symptoms we see most often, with what each one typically costs and how to start unwinding it.

Stock levels that don't match between systems

The classic sync problem: different numbers in the webshop, the ERP, and the warehouse.

The webshop says five in stock. The ERP says three. The warehouse confirms two. The sync runs on a schedule instead of in real time, or it moves in one direction but not the other. Customer service becomes a manual reconciliation team, apologising for overselling or losing sales the business didn't know it had.

The underlying question is which system is the source of truth for stock. In almost every case it should be the ERP, because that's where the warehouse sits. The webshop should read from the ERP, not hold its own independent count. When we audit mismatched-stock problems, this decision is the first thing missing.

Pricing that drifts, especially for B2B customers

Dealer tiers, volume discounts, and country-specific rules drift apart faster than anyone expects.

B2C pricing is usually straightforward. B2B is where things break. Dealer tiers, volume discounts, country-specific rules, promotional logic. These tend to live in the ERP, but the webshop applies its own rules on top. When the two layers conflict, the customer sees the wrong price, or sales spends the day fixing quotes before they go out.

On YOONIT Bikes we resolved this with a single rule: the ERP calculates the price, the shop displays it. The shop never applies pricing logic on top of a number the ERP already computed. One decision, and an entire class of bugs stops recurring.

Product data scattered across three places

Descriptions in the ERP, images in the shop, copy in Google Docs, and nobody knows which one is current.

Descriptions are updated in the ERP. Images are uploaded to the webshop. Marketing copy lives in a shared Google Doc, and translations go through yet another tool. Nobody is entirely sure which version is current, so updates require checking all four places.

The root cause is source of truth again, this time for content. Nothing has been declared the canonical version, so every update becomes a negotiation. The fix is to pick one system for product master data and accept that the others will mirror it. Product content can live in either the ERP or the shop, but only one.

Orders that need manual review before anything ships

If your team double-checks every order, the system is producing enough errors that checking is cheaper than fixing.

If your team “just double-checks every order,” that's a workaround for a system producing incorrect data often enough that checking is cheaper than fixing mistakes later. Once we measure how often the checks catch real errors, the answer is usually under 5%. The other 95% of the time, the team is burning hours insuring against problems that could be fixed upstream.

A team reviewing 80 orders a day catches a real error in maybe 3 or 4 of them. The other 76 reviews are waste. Tracing those 3 or 4 errors back to their source almost always reveals a handful of specific sync failures or logic gaps that, once fixed, remove the need for the manual review step entirely.

Reports that contradict each other

When finance and marketing pull different numbers every month and nobody can explain the gap.

Finance pulls revenue from the ERP. Marketing pulls it from the webshop. They disagree by a few percent every month and nobody can fully explain why. Usually it's a timing issue: orders in different states at different cutoff points. The lack of a clear answer erodes trust in every report that follows.

This is a visible symptom of the same invisible problem. Two systems holding overlapping data without a clear owner produce two slightly different answers, and the difference compounds up the reporting chain until nobody knows which board-level number to trust.

What this actually costs a mid-sized business

The real numbers on integration friction, based on projects we've audited.

Each symptom has a price, and most companies underestimate it.

An operations manager spending two hours a day reconciling data burns 500 hours a year. At a loaded cost of €40 per hour, that's €20,000 of time spent on work that shouldn't exist.

A 3% overselling rate on a webshop doing €2M in revenue means €60,000 in cancelled orders, refund handling, and lost goodwill. The goodwill component is hardest to measure and usually the largest.

Pricing drift on B2B accounts tends to cost somewhere between 0.5% and 2% of B2B revenue, either in under-charging or in sales time spent renegotiating quotes after the fact.

Fixing the integration is almost always cheaper than the workarounds, once you add the numbers up. Most mid-sized integration projects we run pay back inside 12 months, often faster.

Where to start

The first decision is ownership, not technology.

The first question is which system should be the source of truth for each piece of data. Stock belongs in the ERP. Product content can live in either one, but only one. Pricing rules belong where the business logic lives, which is usually the ERP. Customer records split cleanly: B2C in the webshop, B2B dealers in the ERP.

Once those decisions are made and written down, the integration stops being a negotiation and starts being a direction. The technical build that follows is almost mechanical. The hard part is the conversation before it.

Action plan for the next two weeks

A two-week audit you can run yourself before talking to anyone about a rebuild.

You don't need to commission an integration project to start making progress. Most of the clarity you need comes from a two-week internal audit. Here's what to actually do.

1. Make the workaround list. Ask each team (sales, ops, finance, customer service) to list every spreadsheet, export, or manual check they run each week that exists because the system won't do it. Give them 48 hours. You'll end up with 15 to 30 items. This is your integration backlog, ranked by real pain.

2. Measure one of them. Pick the most time-consuming item and measure it for one week. How many minutes per day. How many people involved. How often it catches a real problem. Concrete numbers change the conversation with leadership.

3. Find a pricing mismatch. Take 20 B2B orders from the past month. Compare the price the shop charged to the price the ERP would have quoted. If more than one disagrees, you have pricing drift. Document the pattern.

4. Ask who owns stock. In a room with ops, IT, and finance, ask which system is the authoritative source for stock numbers. If you get more than one answer, or an uncomfortable pause, you've found the root cause of the overselling complaints.

5. Write down the source of truth for five data types. Stock, price, product content, orders, customers. One system each. No fence-sitting. This document is the foundation of any integration work you do next, and it often resolves 30% of the problem before a developer touches anything.

6. Cost the top three workarounds. Using the numbers from step 2, estimate the annual cost of the three most expensive manual processes. Compare that to a rough integration estimate (our mid-sized ERP/webshop integrations typically run €25k to €80k). Most businesses discover the workarounds cost more than the fix.

By the end of two weeks you'll have an evidence-backed case for or against an integration project, and you'll know exactly where the money is leaking. That's the starting point for any real conversation with a development partner.

Frequently asked questions