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.
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.
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 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.
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.
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.
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.
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:
Where Zoho Accounting Actually Stops: Multi-Entity Consolidation and Revenue Recognition. (article)
ERP Total Cost of Ownership: The Five-Year View a Vendor Quote Never Shows. (article)
For the relationship facts, yes, and for a while the accounting package covers the obligations. The CRM stops being enough when orders, stock and invoices need a system that is complete and auditable, which the CRM was never designed to be. The sign is a CRM with a shipped stage. At that point the answer is usually an accounting-plus-inventory stack joined to the CRM at the seam, not a suite, for most companies under a few hundred people.
From the CRM to the ERP, one way: the customer with the CRM's key, and the accepted order. Back from the ERP to the CRM, read-only: invoice status, balance, stock position and shipment status, so a salesperson can have an informed conversation without editing any of it. Money and stock never become editable facts in the CRM, and the quote never gets edited to change an order the ERP owns.
Because the deal amount and the order total are the same number for about a day. Then a discount is applied, a shipment goes short, or a credit note is issued, and the two diverge for legitimate reasons. A two-way sync forces them back together, and one side is always wrong. The fix is a single crossing: the accepted quote becomes the order, the ERP owns it from then on, and the CRM reads its status.
The ERP, or the accounting system that plays that role, because the invoice is an obligation that is audited and closed at period end. It is generated against the customer that sales sold to, using the key that crossed the seam, so finance never creates a second customer record. The CRM shows the invoice status so the account manager knows what is outstanding, but the fact lives where the ledger does.
Ask one person in sales, one in finance and one in operations where the customer lives, where the order lives, and what they do when the two systems disagree. If the three answers match, the seam is drawn and the product choice is a cost question. If they differ, the company has an integration and ownership problem, and buying a suite will ask the same question back in configuration under a deadline.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
