ERP vs CRM: What Each System Is Actually the Record For, and Where the Two Meet.
The question is usually asked as if it were a choice: ERP vs CRM, which one do we need? It is not a choice. A company past a certain size has both, whether or not it has bought either. The CRM might be a spreadsheet of contacts and the ERP might be an accounting package plus a warehouse whiteboard, but the two sets of facts exist, they are kept separately, and they meet somewhere, usually badly.
The useful question is a different one. Which facts belong to which system, and where does the seam between them run? Answer that and the buying decision mostly answers itself. Skip it and the company buys a suite to solve a seam it never drew, which is the most expensive way to discover where the seam was.
What a CRM is the record for.
A CRM is the record for relationships and intent. Who the prospect is, who the contacts are, what they were told, what they were quoted, where the deal stands, what the account manager promised. The facts are about people and about the future: pipeline, forecasts, commitments, conversations. They are edited constantly, by many people, and their value is in being current.
The CRM is also, in most mid-market companies, the system where the customer is first created, which makes it the natural owner of the customer record even after the customer has been invoiced a hundred times. We have argued elsewhere that the system of record for each fact must be decided, and for the customer the CRM is usually the right answer.
What an ERP is the record for.
An ERP is the record for obligations and resources. What was ordered, what was shipped, what is in stock, what was invoiced, what was paid, what it cost, what the company owns and owes. The facts are about transactions and about the past: they are created by events, edited rarely, audited, and closed at period end. Their value is in being complete and immutable once posted.
Whether the ERP is one suite or an accounting system plus an inventory system plus a purchasing tool joined together, the facts are the same. We have written about whether a company needs an ERP or an integration to hold them; either way, this is the set.
The seam: where a promise becomes an obligation.
The two systems meet at one place, and it is the same place in every business: the moment a promise becomes an obligation. A quote is a promise; an accepted order is an obligation. A forecast is intent; an invoice is a fact. The seam runs through quote-to-order, order-to-fulfilment and fulfilment-to-invoice, and everything that goes wrong between sales and operations goes wrong there.
Three things have to be true at the seam.
The customer crosses it once, from the CRM. The ERP receives the customer with the CRM's key and does not create its own. The invoice goes to the customer sales sold to, not to a second record finance typed.
The order crosses it once, from the CRM to the ERP, and does not come back. The accepted quote becomes the order; from that point the ERP owns it. Sales sees the order's status through a one-way flow and changes it, if it must, through the ERP's own process, not by editing the quote.
Money and stock never cross it into the CRM as editable facts. Sales sees the invoice status, the balance and the stock position, read-only, because the CRM needs them to have a conversation, not to own them.
Draw those three flows and most of the ERP-versus-CRM confusion disappears, because the two systems stop competing for the same facts.
The four mistakes companies make at the seam.
Running the order in the CRM. The CRM has a deal, so someone builds fulfilment stages onto it, then invoicing, then a stock field. Two years later the CRM is a bad ERP and the real one is fed from it by hand. The tell is a CRM with a "shipped" stage.
Running the pipeline in the ERP. Less common and worse: the ERP's sales module becomes the CRM because it is where the customer is invoiced. Reps hate it, adoption collapses, and the forecast is whatever finance says it is.
Two customer records with no key. Covered above; the most frequent, and the one that makes every report about a customer wrong on both sides. Our piece on Zoho's ERP and what a US operator should do now starts from this problem, because the interim architecture is mostly about the seam.
Two-way sync of the deal and the order. The deal amount and the order total are the same number for about a day, and then a discount, a partial shipment or a credit note makes them different for good reasons. A two-way sync forces them back together and one side is always wrong.
What this means for the buying decision.
If the seam is drawn and the three flows run, the choice of products matters less than people fear. A CRM and an accounting-plus-inventory stack, joined at the seam, behaves like a suite for most operators under a few hundred people, and it costs a fraction. A suite is the right answer when the volume across the seam is high enough that the joins themselves are a job, when the ERP-side facts need a single database for audit or multi-entity reasons, or when the company has decided to stop maintaining integrations altogether and pay a vendor to own the seam.
What a suite does not do is draw the seam for you. The most common ERP implementation failure we see is a company that bought a suite hoping the question of who owns the customer and where the order lives would be settled by the software, and found that the software asked it back, in configuration, under a deadline.
A short test.
Ask three people, one in sales, one in finance, one in operations, where the customer lives, where the order lives, and what they do when the CRM and the ERP disagree about either. If the three answers match, your seam is drawn and the product choice is a cost question. If they do not, you have an integration problem wearing a purchasing decision's clothes, and it is cheaper to fix as the former.
Discovery for that is paid for only if you proceed. It produces the record assignments, the three flows across the seam, and a guaranteed estimate to build them on the systems you already own; if we estimate low, we absorb the difference. The ERP-versus-CRM question then becomes what it should have been all along: not which to buy, but which facts each one keeps, and where the promise becomes the obligation.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments