ERP and CRM Integration: Getting to One Version of the Customer

Sales works in the CRM. Finance works in the ERP. Both have a customer record, and both are sure theirs is right. The address on the quote does not match the address on the invoice. A customer on credit hold still gets a new opportunity. A sales rep promises a delivery date the warehouse never saw.

Connecting ERP and CRM is a common request in SMEs and mid-size companies. It is also one of the most underestimated. The interface itself is usually the easy part. The hard part is deciding, in advance, which system is the truth for what.

Why ERP CRM integration projects disappoint

Most integration projects start with the technical question: which connector, which API, real-time or batch. Those questions matter, but they come second. Integrations that disappoint usually skip three business decisions:

1. Which system owns each piece of data. If both systems can change the same field, they will eventually disagree, and the sync will overwrite someone’s work.
2. When a record moves from one system to the other. Does a prospect become a customer in the ERP when the first quote is sent, when the first order is signed, or when credit is approved?
3. What happens when the sync fails. Every interface fails sometimes. If nobody watches the errors, records silently drift apart.

Decide ownership field by field

The most useful document in an ERP CRM integration is not a technical design. It is a simple table: every shared field, which system owns it, which system receives it, and who may change it.

A typical split for an SME looks like this:

• CRM owns: prospects, contacts and their roles, opportunities, quotes in progress, marketing preferences, activity history.
• ERP owns: legal entity name, VAT and enterprise numbers, invoicing and delivery addresses, payment terms, credit limits, price lists, orders, invoices and open balances.
• Shared, with one owner: customer number, account manager, segment or customer type.

Your split may differ. What matters is that it is written down, agreed by sales and finance, and enforced by the integration: a field owned by the ERP is read-only in the CRM, and the other way around.

Choose the trigger points

Next, define the moments when data moves:

• Prospect to customer. Usually when the first order is confirmed, or when finance approves the account. Creating ERP customers for every prospect fills your ERP with records that never buy.
• Quote to order. If quotes are made in the CRM, decide whether the order is created in the ERP automatically or reviewed first, and how prices are checked against the ERP price list.
• Back to sales. Which ERP information sales needs to see: open orders, delivery status, outstanding invoices, credit hold. Showing a credit hold in the CRM prevents a lot of awkward conversations.

Clean before you connect

Connecting two systems with inconsistent data multiplies the problem. Before the first sync, match customers between systems, merge duplicates and agree on a unique key, usually the ERP customer number or the VAT number. A one-off cleanup is far cheaper than a year of duplicates created automatically.

Real-time or batch?

Not everything needs to be real-time. Credit holds and order status benefit from near real-time updates. Segment changes or marketing preferences can sync overnight. Real-time integrations are more complex and fail in more interesting ways, so use them where the business case is clear.

Monitor the interface like a process

Treat the integration as part of daily operations, not a finished project:

• Someone checks the error log daily and resolves failed records.
• Rejected records are fixed at the source, in the owning system, not patched in the receiving one.
• Changes to fields, picklists or validation rules in either system go through a simple change check, so a CRM admin does not break the ERP sync by renaming a value.

That daily monitoring and correction work is steady and rule-based, and it is part of the post-go-live support our remote team handles for clients.

Where an architect makes the difference

ERP CRM integration sits between two departments, two systems and often two vendors. Each partner configures their own side well and assumes the other side will adapt. Someone has to own the space in between: the ownership table, the trigger points, the data cleanup and the test scenarios that cover real cases, from a new customer to a credit note.

That is the role of a business application architect. Ben Van Aken works in exactly that space across ERP, CRM and planning tools, including leading the Roadnet rollout at Sip-Well, where planning and ERP data have to line up every day.

Rolling Out Roadnet: Lessons From Planning Real Delivery Routes

A short checklist

1. List every shared field and name the owning system.
2. Make owned fields read-only in the receiving system.
3. Define when a prospect becomes an ERP customer.
4. Decide which ERP data sales needs to see in the CRM.
5. Clean and match customers before the first sync.
6. Choose real-time only where it matters.
7. Name an owner for daily error handling.
8. Add a change check for fields and picklists on both sides.

The bottom line

An ERP CRM integration is a business agreement first and an interface second. Decide who owns each piece of customer data, when records move and who fixes errors, and the technology becomes the straightforward part.