ERP vs CRM: What Each One Is For, When You Actually Need an ERP, and the Integration Reality
Cin7 publishes $349 a month. Brightpearl and NetSuite publish nothing. Here is what each system owns, the five symptoms that predict you genuinely need an ERP, and the rung below it where most growing merchants should stop.
Somebody in your business is asking for an ERP. Somebody else is asking for a CRM. There's a decent chance both of them are describing the same underlying problem, which is that data lives in five places and nobody trusts any of them.
Here's a diagnostic that tells you a lot before you read another word. Go to the pricing page of the systems you're considering. Most CRM vendors publish a per-seat price. Most ERP vendors will not publish anything at all. Brightpearl's pricing page asks you to "request pricing now" and offers a demo instead of a number[1]. HubSpot publishes free tools at $0 and Starter from $7 a seat a month[2]. Zoho publishes its whole ladder[3]. Odoo publishes per-user pricing across its whole app set[4].
That difference isn't accidental. It tells you that ERP pricing depends on scope, and scope depends on a discovery process, and a discovery process is the first invoice. Budget accordingly.
What each system actually owns
Strip the marketing and there are three distinct jobs. Most confusion comes from vendors selling into all three.
| Owns | Answers | Breaks when | |
|---|---|---|---|
| ERP | Stock, purchasing, suppliers, costs, fulfilment, accounting | "What do we have, what did it cost, what do we owe?" | Stock is wrong and nobody knows which system is right |
| CRM | People, companies, conversations, pipeline | "Who are they, what have they asked for, what's next?" | Two records for the same person |
| Commerce platform | Catalogue, cart, checkout, orders | "What did they buy and did it go through?" | It's asked to be the other two |
The one-line version: ERP is about things and money. CRM is about people and conversations. Your commerce platform is the transaction, and it is not a substitute for either.
Where it gets genuinely muddy is that ERPs ship CRM modules and CRMs ship order objects, and both will demo well. The question to ask a vendor is not "can you do X" but "which system is the source of truth for X, and what happens when they disagree".
Does this actually impact you? The honest thresholds
You need an ERP when
- You're buying stock on purchase orders with lead times, rather than reordering when you notice
- You hold inventory in more than one location and need to allocate
- Landed cost matters, meaning duty, freight and FX change your true margin
- You're doing wholesale or B2B alongside DTC, with different pricing and payment terms
- Your accountant is rekeying data from your store into the accounts
Under those conditions, a spreadsheet plus your platform's native inventory is genuinely fine, and I'd resist anyone telling you otherwise. Above about £5M with multi-location stock, it stops being fine quite quickly.
You need a CRM when
- You have a sales motion, meaning humans talk to buyers before money moves
- Wholesale accounts, B2B quotes, or high-value considered purchases
- Customer service needs history across channels
A pure DTC store selling £40 items to consumers who never speak to anyone does not need a CRM. It needs an email platform with segmentation, which is a different product that people call a CRM because it stores email addresses. Calling your ESP a CRM is fine. Buying a real CRM to do the job of an ESP is not.
You need both when
You're running DTC and wholesale from the same stock, which is the most common mid-market shape and the one where integration cost is highest.
So at what size do you actually need one?
This is the question people actually mean when they ask about ERPs, and the answer they usually get back is a revenue number. Revenue is the wrong trigger.
Why revenue is the wrong trigger
A £3M business selling twelve SKUs from one warehouse has a simpler operation than a £900k business selling 4,000 SKUs across three locations with wholesale terms. The second one needs a system. The first one doesn't, and will be told it does by anyone selling systems.
Complexity is the trigger, not turnover. Specifically: how many places stock lives, how many ways it's sold, and how many hands touch a number before it reaches your accounts.
The five symptoms that actually predict it
Count how many of these are true right now. Not aspirationally. Today.
- Somebody rekeys data between two systems as part of their job. Not occasionally. Weekly, as a task with a name.
- You've oversold something in the last ninety days because two systems disagreed about stock.
- You can't answer "what's my true margin on this SKU" without a spreadsheet, because duty, freight and FX live somewhere other than your cost field.
- You raise purchase orders and track lead times manually. A spreadsheet with a column called "ETA" that somebody updates from emails.
- Your month-end takes more than two days and most of it is reconciliation rather than review.
Zero to one: you have a process problem, and buying software will encode it. Two to three: you need a tool, and it's probably not a full ERP. Four to five: you need an ERP, and the business case writes itself from the hours in symptom one.
The order things break in
Operations degrade in a predictable sequence, and knowing where you are tells you what to fix next.
| Stage | What breaks | What it feels like | Right fix |
|---|---|---|---|
| 1 | Stock accuracy | Occasional oversells, apologetic emails | Cycle counting and one source of truth |
| 2 | Purchasing | Stockouts on bestsellers, overstock on the rest | A purchase order process, in software or on paper |
| 3 | Costing | Margin surprises at month end | Landed cost capture. This is the ERP tipping point |
| 4 | Multi-channel allocation | Channels fighting over the same units | Allocation rules and a single stock pool |
| 5 | Financial close | Month-end takes a week | Integration to accounts, not a bigger spreadsheet |
Almost everybody who thinks they're at stage five is actually at stage one, and buying a stage-five system to fix a stage-one problem is the most common expensive mistake in this category. If your stock is wrong, an ERP will hold the wrong number more expensively.
The ladder below an ERP, and where most stores should stop
There are five rungs here and the industry talks about two of them. Work up from the bottom and stop as soon as the pain does.
Rung 1: spreadsheets plus your platform
Genuinely fine, and I'll defend it further up the revenue scale than most consultants will. Single location, straightforward reordering, one sales channel. If that's you, the spreadsheet isn't a sign of immaturity. It's the correct tool.
What it can't survive is a second stock location or a second person needing the same number at the same time.
Rung 2: platform-native inventory
Shopify handles multi-location adequately. Adobe's multi-source inventory model handles sources, stocks and concurrent checkout protection properly and is enabled by default[26]. Both are free with the platform you're already paying for.
One live deadline for Shopify merchants: Stocky retires on 31 August 2026[25]. If your purchasing process runs through Stocky, that decision has been made for you and the clock is running.
Rung 3: accounting with an inventory module
Xero and similar publish their pricing openly and handle basic stock alongside the books[24]. Underrated rung. If your real problem is that your accountant is rekeying orders, this may be the whole answer for a fraction of the ERP conversation.
Rung 4: a dedicated inventory and order management system
This is the rung the ERP conversation skips, and it's where most growing merchants should actually land. Purchase orders, landed cost, multi-location allocation, multi-channel sync, without the general ledger.
Cin7 publishes $349, $599 and $999 a month for Standard, Pro and Advanced, with 5, 10 and 15 users and 6,000, 24,000 and 120,000 annual sales orders respectively, plus 2, 4 and 6 integrations[21]. Unleashed publishes £269 and £499 a month for Core and Pro, with 3 and 5 user licences, 100 sales orders included and additional integrations at £29 each[23]. Katana runs a free tier at 30 SKUs and a Core plan from $299 a month[22].
Read the metering carefully. Unleashed including 100 sales orders a month at £269 is a very different shape from Cin7 including 6,000 a year at $349, and the sales-order allowance is the line that moves your bill, not the user count.
Rung 5: a full ERP
General ledger, multi-entity, manufacturing, full financial consolidation. Genuinely necessary above a certain complexity and genuinely over-sold below it.
The rung table
| Rung | Buy it when | Stop here if |
|---|---|---|
| 1. Spreadsheet plus platform | Always, first | One location, one channel, no purchase orders |
| 2. Platform-native inventory | Second stock location[26] | Allocation is simple and lead times are short |
| 3. Accounting with inventory | Somebody is rekeying into the books[24] | Stock complexity is low, finance pain is high |
| 4. Inventory and order management | Purchase orders, landed cost, multi-channel[21] | Most growing merchants stop here |
| 5. Full ERP | Multi-entity, manufacturing, consolidation[18] | You're past the point of stopping |
What we found comparing the integration surfaces
The interesting question isn't which ERP. It's whether your commerce platform can feed one without a bespoke middleware project. So we read the four platforms' API documentation with that lens.
| Platform | Primary API | Version churn | Practical integration cost |
|---|---|---|---|
| Shopify | Admin GraphQL[5] | Quarterly releases, 12-month support, 9-month overlap[6] | Low to build, ongoing to maintain |
| Adobe Commerce | REST and GraphQL[7] | Tied to version lifecycle[8] | Higher to build, stable once done |
| BigCommerce | REST management[9] | Low | Low |
| WooCommerce | REST[10] | Low core, high plugin | Low to build, unpredictable to maintain |
Two findings from that read-through, and the second one is the one people underestimate.
First: the APIs are all fine. Every one of these platforms can export orders and import stock levels. If a systems integrator tells you the platform is the obstacle, ask them to point at the specific endpoint that's missing.
Second: version churn is a permanent staffing cost that nobody budgets. Shopify ships a new API version quarterly, supports each for at least 12 months, and guarantees at least 9 months of overlap[6]. That's a fair and generous policy. It also means every custom integration you own needs somebody to look at it at least once a year, forever, and if you have six integrations that's a recurring commitment nobody put in the ERP business case.
The third finding is about WooCommerce specifically and it's the sharpest one. Woo's core REST API is stable and well documented[10]. Your integration risk isn't there. It's that a plugin update can change the shape of an order object, and nobody versioned that. The integration cost on Woo is low at build time and unbounded at maintenance time, which is the opposite of the usual story about self-hosted platforms.
The integration reality, in the order it actually goes wrong
Assume you're connecting a commerce platform to an ERP. Here is the sequence in which projects fail, from most to least common.
1. Nobody decided the source of truth
The single most expensive omission. For every shared entity, one system wins. Write it down before any code:
| Entity | Typical source of truth | Why |
|---|---|---|
| Product attributes | PIM, or the platform if you haven't got one | See the PIM piece |
| Price | ERP for cost, platform for sell price | Sell price is a merchandising decision |
| Stock quantity | ERP, always | It counts receipts and allocations |
| Order | Platform at creation, ERP after | Fulfilment state lives with fulfilment |
| Customer identity | CRM if you have one, platform if not | One of them, never both |
| Refunds | Wherever the money moves | Follow the payment provider |
2. The stock sync is a poll instead of an event
A fifteen-minute polling job is how you oversell on a flash sale. If your platform emits webhooks, use them, and reconcile with a poll rather than relying on one. Reconciliation and synchronisation are different jobs and they need different schedules.
3. Nobody modelled the failure case
What happens when the ERP is down and an order comes in? The answer must not be "the order fails". It should queue. Every integration needs a queue, a retry policy, and an alert when the queue depth grows. That's three days of work that saves a Black Friday.
4. Identity matching was assumed to be easy
The same human orders as sarah@work.com on wholesale and sarah@gmail.com on DTC. Your CRM now has two customers with one credit limit between them. Decide the matching rule up front, and make it a rule rather than a fuzzy match, because fuzzy matching merges the wrong people at exactly the wrong moment.
5. The middleware became the system
Business logic drifts into the integration layer because it's the fastest place to put it. Two years later, the rule that decides which warehouse ships an order lives in a mapping tool that one contractor understands. Keep logic in systems, keep mapping in middleware.
If you are on Shopify
What you get natively
Shopify's own inventory across locations is adequate for straightforward multi-location retail, and the Admin GraphQL API is genuinely good to integrate against[5]. Plenty of £5M to £15M DTC businesses run without an ERP and are fine.
When an ERP becomes unavoidable
Purchase orders with real lead times, landed cost, wholesale price lists with payment terms, or multi-entity accounting. Those are the four. Shopify's B2B features cover some of the third one on Plus, which is worth checking before you buy a system to solve it[11].
The maintenance clause to negotiate
If you're paying an integrator, get API version maintenance into the contract explicitly, with a named response window[6]. Otherwise you'll be quoted for it in eighteen months as new work.
Not on Shopify? The other platforms
WooCommerce
The REST API is fine[10]. The thing to insist on is that your integration reads orders through the API rather than the database directly, because High-Performance Order Storage changed where orders live and any direct-query integration written before that is either broken or about to be[12].
Woo's ERP story is usually Odoo or a mid-market accounting package with an inventory module, and Odoo publishes its per-user pricing openly, which is unusual in this category and worth something[4].
Magento and Adobe Commerce
This is where ERP integration is most mature and most expected. Multi-source inventory, per-website scope and a full REST and GraphQL surface[7][13]. Most mid-market Magento merchants already have an ERP and the question is whether the integration is any good.
Watch the version lifecycle, because an ERP connector is a version-bound dependency and support for 2.4.6 ends 11 August 2026[14]. Upgrades and connector compatibility need to be the same project. See the replatforming piece.
BigCommerce
Clean REST management APIs and a decent set of prebuilt ERP connectors[9]. Fewer options than Shopify or Magento, but the ones that exist tend to be maintained. Check GMV-based plan auto-upgrades when you model total cost[15].
Headless and custom
Note that headless stores are undercounted in every platform statistic you will read, because the usual detection fingerprints are gone[20].
You're already running an integration layer, so adding an ERP is architecturally easier and organisationally harder, because there's no vendor to blame. Put the source-of-truth table in your repo as a document, not in someone's head.
What it costs, as honestly as the vendors allow
This is where the category is deliberately opaque, so here's what can actually be verified.
| System | Published pricing? | What's published |
|---|---|---|
| HubSpot | Yes | Free tools at $0 up to 2 users; Starter from $7/seat/mo promotional, $20 standard[2] |
| Zoho CRM | Yes | Full per-user ladder[3] |
| Odoo | Yes | Per-user, all apps[4] |
| Salesforce | Yes | Per-user editions, annual billing terms[16] |
| Microsoft Dynamics 365 Business Central | Partly | Documented product, partner-led implementation[17] |
| NetSuite | No | Module-based quote[18] |
| Brightpearl | No | "Request pricing now"[1] |
Business Central sits awkwardly between the two models: the product documentation is public and detailed, down to tenant administration[19], while the price comes from a partner.
The pattern: CRM is a per-seat product with transparent pricing. ERP is a scoped project sold through a discovery process. That's not a criticism, it reflects genuine variability. But it does mean you cannot compare ERP options without spending weeks in sales conversations, and you should treat any published third-party ERP price as unverified.
The number that actually matters and never appears on any page: implementation. On mid-market ERP it routinely exceeds the first year's licence, and it varies most with the quality of the data you're migrating. Which is, again, the product data problem.
What we found: the pricing transparency line runs through the middle of the category
We read every pricing page in this space on the same day, and a pattern fell out that's cleaner than expected.
| Product | Publishes a price? | What's on the page |
|---|---|---|
| Cin7 | Yes | $349 / $599 / $999 per month, with user, order and integration limits[21] |
| Unleashed | Yes | £269 / £499 per month, per-user and per-integration add-ons priced[23] |
| Katana | Yes | Free at 30 SKUs, Core from $299 per month[22] |
| Odoo | Yes | Per-user across the whole app set[4] |
| Brightpearl | No | "Request pricing now"[1] |
| NetSuite | No | Module-based quote[18] |
| Business Central | Partly | Product documented publicly, price via partner[17] |
The line runs between products that solve an operational problem and products that solve an organisational one. Inventory and order management is a definable scope, so it can be priced on a page. ERP is a scoped programme with data migration and process change attached, so it can't.
That's a fair explanation and it has an unfair consequence, which is that the two categories can't be compared. You can evaluate Cin7 against Unleashed in an afternoon. Evaluating NetSuite against Brightpearl takes weeks of sales calls, during which the option of not buying either quietly stops being discussed.
Treat any third-party ERP price as fiction
You'll find sites publishing NetSuite and Brightpearl prices. Those numbers come from resellers, old quotes and estimation. The vendors don't publish, so nobody outside can know, and a figure that isn't from the vendor isn't a price. It's a rumour with a currency symbol.
The number that never appears on any page
Implementation.
On mid-market ERP it routinely exceeds the first year's licence, and it varies most with the quality of the data you're migrating. That last part is the bit worth sitting with. You are being quoted for a project whose cost is driven by the state of your own product and stock data, which the vendor has not seen.
What actually drives it
Four things, in order of impact. How many SKUs and how consistently they're described. How many years of history you insist on migrating, which is almost always more than you need. How many bespoke processes you refuse to change. And how many integrations connect to it, since each one is a separate small project with its own maintenance tail.
Only the last one is technical. The first three are decisions you control before anybody quotes.
The clean-data discount
Spending six weeks tidying your product data before a selection process is the highest-return work available in this whole area. It lowers the implementation quote, shortens the project, and improves everything downstream including your feeds, your marketplace listings and your machine readability. It is also deeply boring, which is why nobody does it.
I've watched a mid-market ERP project run two quarters long entirely because nobody could agree what a product's cost price meant. Not a technical problem. Three people had three definitions and all three were in use.
The decision table
| Your situation | Buy | Don't buy |
|---|---|---|
| DTC only, under £2M, one warehouse | Nothing. Platform plus accounting | Either |
| DTC only, £2M to £10M, one warehouse | An ESP with segmentation | CRM, ERP |
| DTC plus wholesale, any size | CRM for the wholesale motion | ERP, until stock hurts |
| Multi-location stock, purchase orders, landed cost | ERP | Nothing else first |
| Rekeying orders into accounts by hand | The integration, not a new system | An ERP to fix a data-entry problem |
| Two customer records for the same person | An identity rule | A CRM to fix a governance problem |
| £15M+, multi-market, multi-entity | Both, with a named integration owner | Doing it without one |
The two "don't buy" rows in the middle are the ones I'd defend hardest. Most ERP and CRM purchases in the mid-market are governance failures being solved with software, and the software inherits the governance failure on day one. A named owner and a written source-of-truth table costs nothing and fixes a surprising share of it.
What agents change about back-office systems
Two things, and one of them is a genuine argument for getting the ERP right.
An agent completing a purchase needs an accurate, current availability answer, and it needs it at request time rather than from a fifteen-minute-old cache. Overselling to a human generates an apologetic email. Overselling to an agent that has already reported success to its user generates a much worse conversation, and it's the kind of failure that gets a merchant deprioritised in whatever ranking the assistant is using.
The second: agents will increasingly read your delivery promise, and a delivery promise that's accurate depends on allocation logic that usually lives in an ERP. "In stock" is a claim about a warehouse. "Arrives Thursday" is a claim about a warehouse, a carrier and a cut-off time, and only one system in your stack knows all three.
So the agentic case for an ERP isn't about AI at all. It's that inventory accuracy stopped being an internal metric and became a customer-facing one. Both of the emerging commerce protocols treat availability and fulfilment as structured fields an agent reads directly[27][28], which is a data-quality requirement wearing an AI costume.
On urgency, hold it loosely. Shopify reports AI-referred orders up roughly 13 times year on year[30], while peer-reviewed work by Kaiser and Schulze across 973 sites and $20 billion of revenue puts ChatGPT under 0.2% of ecommerce traffic[29]. Fast growth, small base. Fix the stock number because it is wrong today, not because of what an agent might do next year.
One adjacent thing worth a look if your ERP or CRM has shipped AI forecasting or AI scoring features in the last year: those are automated decisions, and some of them carry disclosure and governance obligations in the EU. Our EU AI Act compliance guide for ecommerce sets out what applies to a merchant and what does not.
What to do this week
- Write the source-of-truth table. One row per shared entity, one system per row. An hour, and it will start an argument worth having.
- Count your integrations. Every system that reads or writes commerce data, with a named owner each.
- Check your stock accuracy. Count one location physically, compare to the system. The variance is your real business case.
- Find out how your stock sync works. Webhook or poll, and at what interval. If nobody knows, that's the finding.
- Ask what happens when the ERP is unavailable. If the answer is "orders fail", fix that before buying anything else.
- Get one ERP quote with implementation itemised separately. If a vendor won't separate them, that's informative.
- Before buying a CRM, check whether you need an ESP. Cheaper, faster, and usually the actual requirement.
- Count how many of the five symptoms are true today. Two or fewer and you want a tool, not an ERP.
- Price rung four before rung five. Cin7, Unleashed and Katana all publish numbers you can compare in an afternoon[21][23][22].
- If your purchasing runs through Stocky, start migrating. It retires 31 August 2026[25].
- Ask three people what "cost price" means in your business. If you get three answers, fix that before any selection process.
The takeaway
ERP is things and money. CRM is people and conversations. Your commerce platform is neither and shouldn't be asked to be. All four major platforms have integration surfaces that are perfectly adequate[5][7][10][9], so the project risk is not technical. It's that nobody decided who owns what, and that the maintenance cost of the connection was never budgeted[6].
I've been on the wrong side of this. We shipped an integration that polled stock every fifteen minutes because it was simpler than handling webhooks properly, and it worked for eleven months. Then it didn't, on the one day it mattered, and the fix took three hours while the queue built.
And on the question people actually arrive with, which is whether they need an ERP: probably not yet. The rung below it is cheaper, published openly, and solves the purchasing and landed-cost problem that sends most merchants looking in the first place[21][23]. If you're weighing this against hiring someone to do it manually, the build, buy or hire piece has the loaded-cost maths.
Who owns your stock number? Not which system. Which person.
Sources
- Brightpearl, "Pricing". Accessed 22 July 2026. (No published pricing; quote-led.)
- HubSpot, "HubSpot CRM pricing". Accessed 22 July 2026.
- Zoho, "Zoho CRM pricing". Accessed 22 July 2026.
- Odoo, "Odoo pricing". Accessed 22 July 2026.
- Shopify, "Admin GraphQL API". Accessed 22 July 2026.
- Shopify, "API versioning". Accessed 22 July 2026.
- Adobe, "Adobe Commerce REST API". Accessed 22 July 2026.
- Adobe, "Software lifecycle policy". Accessed 22 July 2026.
- BigCommerce, "Orders API". Accessed 22 July 2026.
- WooCommerce, "WooCommerce REST API". Accessed 22 July 2026.
- Shopify, "Shopify pricing". Accessed 22 July 2026.
- WooCommerce, "High-Performance Order Storage". Accessed 22 July 2026.
- Adobe, "Adobe Commerce GraphQL API". Accessed 22 July 2026.
- Adobe, "Released versions". Accessed 22 July 2026.
- BigCommerce, "BigCommerce pricing". Accessed 22 July 2026.
- Salesforce, "Sales Cloud pricing (UK)". Accessed 22 July 2026.
- Microsoft, "Dynamics 365 Business Central documentation". Accessed 22 July 2026.
- Oracle NetSuite, "NetSuite ERP". Accessed 22 July 2026. (No published list pricing.)
- Microsoft, "Business Central tenant administration". Accessed 22 July 2026.
- HTTP Archive, "Web Almanac 2025: Ecommerce". Accessed 22 July 2026.
- Cin7, "Pricing". Standard $349/mo (5 users, 6,000 annual orders, 2 integrations), Pro $599/mo, Advanced $999/mo, Omni quote-led. Accessed 23 July 2026. Vendor page.
- Katana, "Pricing". Free at 30 SKUs; Core from $299/mo. Accessed 23 July 2026. Vendor page.
- Unleashed, "Pricing". Core £269/mo (3 users, 100 sales orders, 3 integrations), Pro £499/mo. Accessed 23 July 2026. Vendor page.
- Xero, "Pricing plans" (UK). Accessed 23 July 2026. Vendor page.
- Shopify, "Transitioning from Stocky". Stocky retires 31 August 2026. Shopify Help Center.
- Adobe, "Inventory Management introduction". Multi-source inventory, enabled by default. Accessed 23 July 2026.
- Google, "Under the Hood: Universal Commerce Protocol (UCP)". Google Developers Blog.
- Agentic Commerce Protocol, specification repository. Maintained by OpenAI and Stripe.
- Maximilian Kaiser and Christian Schulze, "ChatGPT Referrals to E-Commerce Websites", Marketing Science. Peer-reviewed; 973 sites, $20B revenue.
- Shopify, financial reports, Q1 2026. AI-referred orders up roughly 13x YoY.