CRM and ERP: Which Data Belongs Where

The boundary in one sentence

The CRM holds what describes the customer and tracks the path to a signature: company, contact, deal, activity, consent. The ERP holds what bills that signature: invoice, contract, revenue recognition. Every other assignment is a consequence of those two sentences.

This boundary is not a property of either system. It is a decision somebody makes and writes down. Where it is not written down it does not exist, and a CRM without one turns into a second, worse ERP over two or three years.

Why the boundary blurs on its own

Open a CRM that has been running for a few years and you will find things that do not belong there: invoice line items, connections into the finance system, workflows pushing records into a backend. Nobody ever took that as an architecture decision. It accumulated, because each individual addition looked reasonable on its own.

The mechanism is unremarkable, which is exactly why it works. A modern CRM can be extended far enough to express ERP functionality. Custom objects, calculated fields, workflows: the building blocks are there, and no system says no at that point. The bill arrives later, in three instalments. Maintenance for logic nobody can explain any more. A data quality problem, once two systems report the same figure differently. And migration cost the next time the stack changes.

Which object belongs where

The assignment below is the short version, the one that fits in a design document. The column that carries the actual content is the last one: what the wrong placement costs in practice.

The contested row is the quote. Sales creates it, it carries prices, and both systems have a plausible claim to owning it. The workable split: the quote lives in the CRM because sales works in the CRM, while pricing and discount logic stay in the system of record and get integrated. Setting that process up cleanly in HubSpot cut the time for sending quotes by 80% at aumico, in less than 2 weeks.

Integrate instead of rebuilding

The reflex in a migration is to carry the inherited scope across one for one. Somebody needed all of it once. The question that halves that scope: does this function need to live in the CRM, or does the CRM only need to be able to see it?

Seeing is usually enough. An interface that reads status out of the backend is cheaper to build and considerably cheaper to run than a reimplementation of the same logic inside the CRM. It also has an owner, which the reimplementation does not.

Both numbers come from projects where the boundary was drawn first. That is not a coincidence. A large share of what a migration saves is the effort that used to go into logic sitting in the wrong system.

“Our processes are different”

This comes up in almost every project, and it is rarely said in bad faith. It comes from real familiarity with the detail. It just does not survive inspection: lay the process models of several companies in the same industry on top of each other and they overlap almost entirely. What differs is naming, ownership and one or two genuine specifics. Not the structure.

That produces a selection criterion rather than an argument for taking the easy path. How far can a process be expressed in the system's standard, without custom build? The closer to standard, the cheaper every future update, the shorter the onboarding, the easier the next migration. Specifics go on top as colour, not underneath as foundation.

In practice: fix the number of custom objects for phase one before the first requirement arrives, and keep it countable on one hand. Anything beyond that needs a reason and a signature.

The boundary only holds in writing

There is a reason the boundary has to exist before the build rather than emerge during it. Requirements only come back honestly once there is a running system to look at. During discovery, people describe their work as they remember it. Put a first working configuration in front of them and you reliably hear that it is actually different from what they said, not out of carelessness but because a running system asks a sharper question than a workshop does.

A team that wrote the boundary down first can absorb that second, more honest round without renegotiating the architecture. A team that did not, negotiates both at once, against a deadline.

The hard case: several entities, several backends

Under one roof with several legal entities, the boundary is not drawn once. It is checked per entity. Each brings its own backend, usually with its own history and its own ownership. Decide a boundary for all of them without walking it through entity by entity and you get either resistance or one exemption per site, which amounts to the same thing as no boundary.

Something else matters in that setup: only a shared boundary makes a shared view of the customer possible at all. As long as each entity keeps customer data at a different depth and in a different place, the question “are we already working with this company” cannot be answered, and that is usually the question the project was started for. How a group-wide setup gets built is covered under group-wide CRM.

How to tell that no boundary was drawn

Four signs, all visible before go-live:

The fourth is the most telling. A boundary without a named approver is a recommendation, and recommendations do not survive the first urgent request.