CRM and ERP integration: 6 data flows and who owns each

CRM and ERP integration is the agreement between sales, finance and IT on which data each system governs, which direction and how often each piece of data travels, at what moment a won deal becomes an order and who fixes the message that failed, and the connector you pick is the last of those decisions. The CRM, the customer relationship management system, records intent and negotiation, and the ERP, the enterprise resource planning system, records obligation: order, invoice, receivable and inventory. In TIC Empresas 2025, which interviewed 4,174 Brazilian companies with ten or more employees, 76% of companies with 250 or more people used ERP to integrate data and processes across departments (Cetic.br, 2026) and 56% used some CRM application in the previous 12 months (Cetic.br, 2026). The two figures add up to more than 100%, so at least 32% of large companies run both systems, and the board’s question becomes how they talk to each other.

The scene I come across often starts with a phone call. The rep calls the customer to offer a renewal and hears that the company is still disputing three overdue invoices with finance, information that had been in the ERP since the previous month. On the same day, finance holds an order for lack of credit without knowing that the sales director approved special terms for that customer. Both systems are correct and neither sees the other. The process from lead to cash in the bank is in lead to cash, and the owner of each entity in the operation is in revenue data architecture. The connection between CRM and ERP calls for decisions of its own, which IT projects tend to skip.

What does the CRM govern and what does the ERP govern?

Each piece of data needs a master system, the only place where someone creates or changes it, and the other systems receive a copy or query it. What originates in the commercial relationship belongs to the CRM: lead, contact, opportunity, stage, forecast value, proposal and approved discount. What originates in a tax, accounting or logistics obligation belongs to the ERP: the customer’s tax record, product code and tax treatment, order, invoice, receivable, credit limit and stock balance. Boundary data takes up most of the project’s time.

The customer is the first case. It starts in the CRM as a prospect company, often without a tax ID, and only becomes a tax record in the ERP when someone needs to issue an invoice. The design that works separates the two moments: the CRM owns the company while it is a prospect, and the ERP takes over the tax data once finance approves the record, when those fields become read only in the CRM. Price is the second boundary case. The official price list comes from the ERP or from the controller’s office, and the price actually charged comes from the negotiation, with the discount the discount policy authorized. The board has to decide which of the two prevails on the order, because an ERP set to recalculate from the price list wipes out the approved discount and the invoice goes out with a value different from the contract.

Which data flows between CRM and ERP, in which direction and how often?

The table covers the six data groups that show up in almost every CRM and ERP integration in a B2B operation. The CRM fields that receive this data, with type and who fills them in, come from the CRM data model.

Data	Origin (master system)	Destination	What flows and when	Frequency
Customer	CRM until the record is approved, ERP after	ERP, with return to CRM	On the win, legal name, tax ID, address and billing contact go out; customer code, status and credit limit come back	On the event, and daily for status
Product and price list	ERP	CRM	Code, description, tax treatment and list price; a deactivated item leaves the quote	Daily, and on the event when the list changes
Order	CRM creates, ERP governs once created	ERP	The deal that reaches the agreed stage generates the order; the ERP returns number and status	On the event, within minutes
Invoicing	ERP	CRM	Invoice number, date and value, with cancellation and reissue	On the event or hourly
Open receivables	ERP	CRM	Due date, amount and days overdue per customer	Daily, before business hours
Inventory	ERP	CRM	Available balance of the item at quoting time, with no copy stored	On demand

The frequency of each row comes from one question to the data owner: how much delay their process tolerates. Receivables and the price list can handle an overnight batch load, and the order needs to arrive within minutes, because finance and logistics work on it the same day. Inventory calls for a query to the ERP at quoting time, since a balance copied at six in the morning is wrong at three in the afternoon. Real time in every flow makes the project and its maintenance more expensive without improving any decision.

How do the unique key and value mapping work?

The unique key is the identifier that lets both systems recognize the same record, and the rule for headquarters, branches and corporate groups is in the data architecture. In the integration, the safe path is the cross key: the CRM stores the customer’s ERP code, the ERP stores the CRM record ID, and the integration searches by key before creating any record. The tax ID (CNPJ in Brazil) serves as validation and as the criterion to match the databases on the first load. The field has to accept letters in both systems, because Brazil’s Federal Revenue Service began assigning alphanumeric CNPJs to new registrations from July 2026, keeping the old numbers valid (Receita Federal, 2024). When databases already exist on both sides, someone matches the records, resolves duplicates and stores the cross key before switching the integration on, using the rules in CRM data quality. Turning the flow on before this matching moves every CRM duplicate into the ERP at once, where fixing them, with invoices already issued, costs far more.

Value mapping is the correspondence table between the values of a list in one system and the values of the same list in the other. The “30/60 days” payment term in the CRM corresponds to a code in the ERP, the account owner corresponds to a sales representative code that defines commission and cost center, and the business unit corresponds to the company or branch that issues the invoice. Each mapping is owned by the team that governs that list in the master system. A new value with no matching row in the mapping leaves the order stuck in the error queue, so whoever creates a new payment term or product creates the mapping row the same day.

When does a won deal become an order?

The moment a deal becomes an order defines who can change what afterwards, and each type of sale calls for its own design. For replenishment to customers with approved records and credit, the win creates an order that is already released. For B2B sales to a new customer, the win creates a blocked order until finance checks the record, credit and payment terms. For projects and recurring contracts, the order is created only after the contract is signed or the customer’s purchase order arrives.

In any design, the won stage requires the fields the ERP needs, with validation that keeps the rep from moving forward without them, and the integration uses the deal ID as the order reference. Without that lock, a deal marked as won on the last day of the month to hit quota becomes an order for a customer with no approved credit. The ERP returns the order number to the CRM, and from then on the deal’s values and line items are locked. An extra discount the customer asks for after the win goes through the discount policy and becomes a recorded change to the ERP order or an amendment deal, never an edit in the CRM that the ERP does not receive.

How do you handle errors and reprocessing in the integration?

The integration will fail some day, and the design decides whether the failure shows up within minutes or when the customer complains about the invoice. It starts with the error queue, the list of messages that did not reach their destination, with the reason written in language the team understands and an alert to a named person. The deal in the CRM gets an integration status field, and the rep reads “order pending: payment term with no match in the ERP” without opening a ticket.

Two technical properties prevent the worst damage. Idempotency is the ability to receive the same message twice and produce a single result: the integration recognizes the deal reference and does not create a second order when someone resends it. Dependency order holds the order until the customer exists in the ERP and reprocesses both in the right sequence.

Error type	Example	Who fixes it	How it is reprocessed	Deadline
Incomplete data	Customer without state tax registration	Sales, in the CRM	Automatic resend after the fix	One business day
Missing mapping	New payment term with no ERP code	List owner	Queue reprocessed after the row is created	One business day
ERP rule	Credit blocked, inactive product	Finance or controller	Order released or returned to the rep, with a reason	Two business days
Unavailability	ERP down, call limit reached	IT	Automatic retries, alert if the deadline passes	Two hours

Native connector, integration platform or custom development?

The native connector is the one offered by the vendor of one of the systems, with fields already mapped. The integration platform, or iPaaS (integration platform as a service), is a cloud service where you build flows between systems with connectors and configured rules, with little or no code. Custom development is your own code written on the APIs of both systems, the interfaces through which each one receives and delivers data.

Option	When it fits	Advantages	Limits	Who maintains it
Native connector	Process close to the standard of both systems	Fast activation, low upfront cost, updates by the vendor	Fixed mapping; custom rules, such as a blocked order, often do not fit	CRM administrator
Integration platform	Custom rules, more than two systems, ERP with no connector	Error queue and reprocessing built in; rules change without programming	Subscription or volume pricing; requires someone who masters the tool	Revenue operations or IT
Custom development	Old or heavily customized ERP, high volume	Full control of rules and performance	Higher upfront cost; queue and reprocessing must be built	IT or a vendor

The decision starts from the flow table. Mark the rows the native connector covers in full, with trigger, mapping and error handling. If it covers all of them, the choice is made, and if two or more rows need custom rules, the platform tends to come out cheaper in the second year. Custom development comes in when the ERP offers no usable API, and it requires a second person able to take over the code.

How much does it cost to maintain a CRM and ERP integration?

The approved budget tends to cover the build and forget the maintenance. Maintenance includes the daily review of the queue, adjustments when the process changes, adaptations to each new version of the systems and the platform subscription. In the projects I follow, process changes weigh more than technical ones: sales launches a new offer and nobody mentions that it needs a mapping row.

In a hypothetical example, an integration project costs R$ 60,000. Maintenance takes 10 hours a month at R$ 200 an hour, or R$ 24,000 a year, and the platform costs R$ 1,000 a month, or R$ 12,000 a year. Keeping the integration running costs R$ 36,000 a year, 60% of the project value, and a board that approves without that line finds the bill at the first price list change.

How do you test and sign off the CRM and ERP integration?

User acceptance testing is the period in which the teams test the integration in a test environment, a copy of the systems with no tax effect, using real scenarios from the operation, and sign off before go-live. The checklist below is the tool I hand to leadership teams.

Test scenario	Expected result	Who approves
New customer with complete record	Customer created in the ERP and code returned to the CRM	Finance
Customer that already exists in the ERP	Integration finds it by key and does not duplicate	Finance
Branch of an existing customer	New establishment linked to the same account	Finance and sales
Customer with alphanumeric CNPJ	Record accepted in both systems	IT
Approved discount below the price list	Order with the negotiated price, no recalculation	Sales and controller
Product deactivated between quote and win	Readable error in the queue and a notice on the deal	Sales
Same message sent twice	A single order in the ERP	IT
Paid and overdue receivable	Correct status on the customer the next day	Finance and CS
Volume on the last business day of the month	Queue processed within the deadline	IT

Go-live happens flow by flow. The catalog goes first, because it creates nothing in the ERP and the order depends on the product code, customer and order come next, and invoicing and receivables close the sequence. In the first week of each flow, the queue owner reviews the errors every day with the teams.

Who owns the integration between CRM and ERP?

The table separates who executes from who approves.

Role	Responsible for	Approves
Sales leadership	Required fields at the win and the team’s use of order and receivables data	When the win becomes an order and price exceptions
Finance leadership or controller	Tax record, catalog, price list and financial value mappings	Order release and changes to the lists it governs
IT	Access, test environment, availability, security and vendors	Technical, version and vendor changes
Revenue operations	Flow table, integration record and trigger rules	Field and rule changes, with the data owners
Error queue owner	Daily queue review, routing and deadline follow-up	Nothing; executes and escalates

The queue owner needs a name and a backup for vacations. The executive sponsor settles conflicts between teams, such as the rep who wants to edit the order after the win, and takes three numbers to the monthly meeting: open errors, average time to fix and orders created without manual intervention.

What are the common mistakes in CRM and ERP integration?

An integration without an error queue

Without a queue and an alert, the failed message disappears. Finance finds out about the order that never arrived when the customer asks for the invoice, weeks later, and nobody can say how many others were lost along the way.

Testing only the happy path

The test with the perfect customer, the active product and the ERP online passes on the first try. The real operation has branches, deactivated products, discounts below the price list and a slow ERP at month end, and those are the scenarios the checklist has to cover.

Keeping the rules in the developer’s head

A flow that only one person understands stops the day that person leaves the project. The integration record, with triggers, mappings, error handling and owners, sits next to the flow table and changes with each approved change.

Enablement: who needs to learn what

The rule becomes habit when each team knows what the other does with the data. Reps learn the fields the win requires, how to read the integration status on the deal and how to check the customer’s receivables before calling. Sales managers start using order and overdue data in the pipeline meeting. Finance learns to work the queue and to maintain the mappings it governs, and revenue operations and IT learn to update the integration record and reprocess without duplicating. Training works best with the teams together, walking through the testing scenarios in the test environment.

30-day roadmap for leadership

1. Week 1: write the flow table. Sales, finance and IT fill in the six data groups.
2. Week 1: name the owners. Apply the question from the box to each row and each value mapping.
3. Week 2: decide when the win becomes an order. Choose the design for each type of sale.
4. Week 2: measure the databases. Count how many CRM customers match the ERP by tax ID, how many duplicates show up and whether the field accepts letters.
5. Week 3: compare the integration options. Mark what each option covers out of the box and budget annual maintenance.
6. Week 3: write the test plan and the error deadlines. Adapt the checklist and set a fix deadline for each error type.
7. Week 4: get board approval. Bring owner, schedule by flow, maintenance budget and the queue indicators.

If your company has a CRM and an ERP and still relies on messages between the rep and finance to know whether the order went out or the customer paid, that is the work of the in-company Revenue Operations training. I run the program with sales, finance, IT and revenue operations together, on the real flows of your operation. The group leaves with the SLA between marketing, sales and CS extended to the handoffs with finance, and with the RevOps metrics matrix, which shows which system each number comes from and includes the integration indicators.

Frequently asked questions

What is CRM and ERP integration?

It is the connection that lets commercial data in the CRM and tax and financial data in the ERP flow without retyping. It includes the master system for each piece of data, the direction and frequency of each flow, the key that links the records and error handling. The connector is the technical part that carries out these agreements.

Which data should go from the CRM to the ERP?

The customer with its record data and the order generated by the won deal go from the CRM to the ERP, with line items, negotiated price and payment terms. The customer code, the catalog and price list, the order status, issued invoices, open receivables and the inventory query come back from the ERP to the CRM.

Should the customer be registered in the CRM or in the ERP?

In both, with different owners at different moments. The CRM owns the company while it is a prospect, and the ERP takes over the tax data once finance approves the record, when those fields become read only in the CRM. Each system stores the other’s key.

Native connector, platform or custom development: which should you choose?

Choose the simplest option that covers every row of the flow table with trigger, mapping and error handling. The native connector fits when the process is close to the standard, the integration platform when there are custom rules or more than two systems, and custom development when the ERP or the volume goes beyond what the tools cover.

How do you avoid duplicate orders in the integration?

Use the CRM deal ID as the order reference in the ERP and set the integration to look for that reference before creating anything. That way, a resent message updates the existing order instead of creating another one. Include this scenario in testing.

How do you prepare the team to use the CRM and ERP integration?

Train sales, finance, IT and revenue operations together, walking through the testing checklist scenarios in the test environment. Each profile learns what it records, what it checks and what to do when the queue shows an error. Measure by open errors, time to fix and orders created without manual intervention.