ERP vs CRM: what each one owns

The one sentence difference

ERP is the system of record for what the business does: stock, production, purchasing, invoicing, payroll, the general ledger. CRM is the system of record for the relationship with the customer: who they are, what they asked for, what was promised, what happens next.

Put another way, ERP answers what happened and what it cost. CRM answers what is about to happen and who is responsible.

Where they genuinely overlap

Only two objects live in both systems, and both cause trouble when nobody decides who owns them.

Write that table down for your own business before anyone builds an integration. Ninety percent of sync problems are not technical. They are two systems both believing they own the customer's address.

What goes wrong when the ERP is used as a CRM

This is the common direction, because the ERP was bought first and it already has customers in it. What follows is predictable.

• Leads that never became customers have nowhere to live, so they live in a spreadsheet.
• There is no concept of a stage, so nobody can say what is likely to close this month.
• Follow up is invisible. The ERP records what was invoiced, not who was supposed to call back on Tuesday.
• Salespeople avoid it, because an ERP screen asks for twenty fields when they have thirty seconds.

The tell is a sales meeting that starts with someone reading from a notebook.

What goes wrong when the CRM is used as an ERP

Less common, more expensive. Businesses add stock fields, purchase orders and cost tracking into a CRM, then discover that the CRM has no concept of a stock movement, no landed cost, no period close, and that the accountant will not accept its numbers.

The line worth holding: if a number ends up on a tax return, it belongs in the accounting or ERP system. Everything upstream of that is fair game for the CRM.

How the two should be connected

A working integration is boring and specific. It has a written field map, a stated owner per field, and a reconciliation that runs nightly and tells a human when the two disagree.

1. Customers sync from CRM to ERP when a deal is won, not before, so the ERP is not full of prospects.
2. Products and prices sync from ERP to CRM on a schedule, so quotes cannot use a price that no longer exists.
3. A won quote creates the ERP order, and the ERP order number is written back onto the CRM record.
4. Order status, shipment and payment status flow back to the CRM so the salesperson answers without leaving the screen.
5. A nightly job compares both sides and emails a short list of mismatches. Without this, drift is silent.

We build this as part of a CRM integration project, usually in one to three weeks depending on whether the ERP has a real API.

So do you need both?

If you hold stock, manufacture, or have a finance team that closes periods, you need an ERP or at least proper accounting software. If you have a sales or service process with more than one step and more than one person, you need a CRM. Most businesses over about fifteen people need both.

The exception is a business that sells services with simple billing. There, the accounting package plus a custom CRM covers everything, and an ERP would be a large solution to a small problem.

One order, followed through both systems

Abstract definitions stop helping once a real order is moving. Here is a single order through a manufacturer that runs both, with the handover points marked.

1. A dealer registers a lead in the portal. The CRM creates the enquiry, protects it for that dealer for sixty days and assigns the regional manager.
2. The manager builds a configured quote. Prices and configuration rules come from the ERP, but the quote document, the revisions and the follow up sequence live in the CRM, because none of that is an accounting event.
3. The customer accepts. The CRM writes an order to the ERP, once, with the configuration attached. From this second the ERP owns the order.
4. Production schedules it, stock is committed, a delivery date is returned. The CRM reads that date and shows it on the account screen. It does not store its own copy and it never edits it.
5. The unit ships. The ERP raises the invoice. The CRM creates an installed product record against the customer with the serial number and the warranty end date.
6. Eleven months later the CRM starts the renewal sequence, because the warranty date it holds is the one the ERP gave it. The ERP has no opinion about renewal emails, and should not.

Notice what happened: the order crossed the boundary exactly once, in one direction, and everything after that was a read. That is what a healthy pairing looks like. Every problem we get called in to fix is a version of the same order crossing four times in both directions.

Which system owns which field

The argument is almost never about whether you need both. It is about which one is allowed to change a given field. Write this table for your own business and most of the integration design is done.

One rule makes the table enforceable: a field has exactly one owner, and the other system gets a read only view of it. Every field with two owners becomes a support ticket within six months. This is the first document we produce on any CRM integration project.

The three ways they get connected

Integration is a word that hides three very different amounts of work and risk. Knowing which one you are buying matters more than the tool used to build it.

Nightly file. One system writes a file, the other reads it at two in the morning. Cheap, almost impossible to break, and completely wrong for anything a customer asks about on the phone. Price lists and cost centres live here happily.

Scheduled sync. Both sides call each other every few minutes through an API. This is where most pairings land, and where most of them get into trouble, because the moment both sides can write the same field you need a documented rule for who wins. Our answer is to remove the situation rather than resolve it: single owner per field, and the sync is one direction for that field.

Event driven. The ERP announces a change and the CRM reacts within seconds. It is the right pattern for order confirmed and shipment dispatched, and it demands real engineering: retries, ordering, and somewhere for messages to land when the far side is down for maintenance. We only build this for the two or three events that genuinely need it.

What the ERP vendor means by CRM module

Most mid market ERPs sell a CRM module, and it is usually cheaper than anything else you are considering. It is worth understanding what you get, because the answer is consistent across vendors.

You get a customer screen with contacts, an activity log, an opportunity list with stages, and reports built in the ERP's reporting tool. For a business whose selling is genuinely simple, an inside sales desk taking repeat orders from known accounts, that is enough, and buying anything else is waste.

What you do not get is the part sales people use hourly: a phone view worth opening, a quote document you are not ashamed to send, sequences that chase a prospect without anybody remembering, and a pipeline board that can be dragged. ERP interfaces are built for accuracy under audit, which is the opposite design goal to speed under pressure. Adoption is where these modules fail, and an unused CRM is worse than no CRM, because it produces reports that look real.

The honest test: ask the vendor to show you the module on a phone, outside, in the app your sales people would actually have. Then ask what a quote looks like when it reaches the customer. Two questions, and they tend to settle the argument.

Signs you have outgrown the ERP customer screen

These are the complaints that show up in discovery calls, in roughly the order they appear.

• Your forecast lives in a spreadsheet that somebody rebuilds every Monday, because the ERP cannot hold a probability or a close date that has not happened.
• Nobody can tell you where an enquiry came from, so marketing spend is defended with opinions.
• Follow up depends on memory. The quotes that go quiet are found weeks later, or never.
• The customer record has one contact on it, and that contact left the company in March.
• Sales people keep their real notes somewhere else, which is the clearest signal of all: the system is not helping them, so they have built a private one.
• A question like which accounts have not ordered in ninety days takes a developer and two days.

Three or more of those and the conversation is no longer whether to add a CRM, it is which one. If your process is unusual, or per seat fees across a larger team have become a real line item, a system built around your process is worth pricing against the subscription. We do that comparison honestly, including the cases where we lose it: see the custom CRM development page for what we scope and what we refuse.

Five years of cost, both routes

A twenty five person distributor already running an ERP, comparing an added subscription CRM against a built one. Figures in US dollars, rounded, using mid market list prices at the time of writing.

The numbers favour building, and they are still not the whole argument. Two things push the other way. A subscription has no build risk and works next week, and a built system needs somebody to own it for five years. What tilts it for most businesses this size is not the total, it is that the subscription line grows with headcount and the built one does not. Our own bands are on the pricing page, and the assumptions behind them are set out in what a custom CRM costs.

Three questions before you sign either contract

Whether you are adding a CRM next to an ERP, replacing one, or buying both together, these three questions predict how the next five years go better than any feature list.

Can I get all of my data out, in full, without asking you? Not an export of contacts. Every record type, with relationships and attachments, on a schedule, without a support ticket. If the honest answer is no, you are not a customer, you are a tenant, and your negotiating position at every renewal is weaker than you think. This is the core reason our clients own the database and the hosting account: it is described plainly on the how it works page.

What happens when my headcount doubles? Model it. Per seat pricing is reasonable at twelve people and a serious line item at forty, and the price per seat rarely falls as fast as your team grows. Businesses expecting to double are the ones for whom a built system pays back quickest, because the cost does not follow the headcount.

Who owns the integration when it breaks at nine on a Monday? An ERP vendor blames the CRM, the CRM vendor blames the ERP, and the middleware vendor points at both. Get one name on the integration in writing. We monitor the connections we build for twelve months and fix them under the build price, precisely because this question has an expensive default answer.

None of the three is technical. They are commercial questions about leverage, and they are easier to ask before money changes hands than afterwards.