Integrate ERP and CRM with a clear data owner

Your salesperson calls a customer and opens the contract price in the CRM. The customer accepts the quote, but the order in the business system already shows a different price. Now sales and finance have to work out which price applies and who promised what.

The business system works like the warehouse office. It holds the details on items, costs, availability and deliveries. The CRM is the salesperson's notebook, with customer contacts, requests and agreements. According to Statistics Sweden's definitions of business systems and CRM, business systems share information between internal functions, while CRM handles customer information, contacts, buying habits and interests.

An integration between the business system and the CRM therefore starts with ownership of each data domain. You need to decide which source applies when the systems show different values. That source is the master for that piece of data. The link between e-commerce and the business system matters even more when the same price is also shown on the website. The mapping needs to state which data should be shared, in which direction, and which decisions have to be made before the build starts.

Which data flows go in which direction

The split below is a proposal to test against your workflows. The frequencies need to match how long the business can accept an outdated value.

The business system is the master for customer identity, company registration number and legal name, which go to the CRM via API on every change. Payment terms and credit status take the same route, via API or a daily sync. Items, item numbers and core data are sent from the business system to the CRM and the website as an event when they change. Prices and customer-specific contract prices go to the CRM and the portal as a daily timestamped snapshot, and stock levels as a timestamped snapshot at a fixed interval. Invoice data and payment history are read daily.

Orders and order status have the business system as master but move in both directions, as events with an idempotency key. The CRM is the master for leads, activities and sales status, which go to the business system as an event when the deal is won. Contact attributes and consent are also owned by the CRM and are sent when needed, with a change log.

Let the business system own legal customer identity, payment terms and credit status. The same applies to item data, pricing logic and booked orders. Finance needs to be able to take responsibility for the data that drives invoicing and payment.

The CRM can own leads, activities and sales status. Contact attributes and consent data need their own rules for changes, access and deletion. The CRM being master for a contact detail never means every receiving system should get the whole contact record. Choose a master per piece of data. A full customer record rarely needs a single owner.

The shared customer key should include the company registration number and the internal customer ID. Also link billing and delivery addresses to the right customer relationship. Addresses help you tell delivery locations apart, but they should not on their own decide which legal customer an order belongs to.

Validate company registration numbers and normalise the format before matching. Remove formatting differences according to a documented rule and handle missing values separately. Records that cannot be matched reliably need to be reviewed before any history is moved across.

Say a group has customer records for the parent company, a branch and an old duplicate record. If the integration matches on company name, the branch's purchases can end up under the parent company's sales contact. The salesperson then spots the error through a misleading revenue figure.

An order can start in the CRM and still have the business system as master. The salesperson sends an order proposal that the business system validates and books. The order number, approved amounts and status then go back to the CRM.

Finally, every flow needs a named business owner. That person decides how a discrepancy should be corrected. The technical owner needs to be able to find the error, while the business owner has to be able to decide which value applies.

Five ways to connect the business system and the CRM, and when each is enough

Manual file export and import fits when you have few customers and a short transition period. It is quick to start, but duplicate entries and errors can go unnoticed. A nightly file sync works for small volumes and data that changes slowly, and the files are easy to troubleshoot. The risk is that sales works with yesterday's prices and stock levels.

A direct API connection fits a limited system landscape with few flows and gives fast updates for selected data, but every new connection adds maintenance. A message queue with events fits when many flows have several recipients. It handles outages and retries, and needs governance of message formats and versions. A ready-made standard connector can reduce the implementation work with pre-tested flows, as long as your systems and processes fit within it. Special processes can fall outside its scope.

Choose based on the number of flows, the delay you can accept and your ability to maintain the connection. An integration platform can help when several systems share data. Our walkthrough of integration platforms and their uses gives you a basis for that trade-off.

A message queue needs someone to decide what messages should look like and how errors should be handled. Every message should carry a correlation ID, a timestamp and a schema version. Retries should happen with gradually longer waits so an overloaded system has time to recover.

Order flows need idempotency keys. Say the business system books the order but the response is lost during an outage. When the CRM sends again, the recipient has to recognise the order and return the existing one. A retry function is only safe once the recipient can handle the same message again.

Price and stock can be published as events or timestamped snapshots. Customer data and order changes also need conflict rules and an audit history. Then you can see which change was accepted and why.

A manually written email with an attached file is not automated data sharing. The file needs a controlled import chain to work as a reliable flow.

Structured messages make it easier to compare behaviour before and after an upgrade. A daily reconciliation of counts and amounts complements the technical monitoring. Choose a method for each data flow, because orders and historical invoice data can tolerate different delays.

Where the benefits and risks show up first in daily work

Without a working connection, the salesperson can see old customer history while finance sees the latest payment. An invoice question then means someone has to search both systems. The contract price can also be missing from the quote even though finance has already registered it.

When the flows work, the salesperson can see orders, payment status and relevant history in one view. Approved contract prices can be used when the quote is created. Duplicate entries drop when an accepted value can follow through the workflow.

The same reach makes incorrect core data dangerous. A wrong customer link can carry the wrong purchase history into the salesperson's view, the customer portal and the analytics. An integration that drops messages without an alert can also lead users to trust incomplete data.

Say the same company has duplicate customer records used by different salespeople. When the orders are gathered in a shared view, conflicting payment terms suddenly appear. The team then has to sort out the register error and decide how future customer records should be created. Send uncertain customer matches for review before the history spreads to more recipients.

The question becomes more pressing when combined data is used by AI. According to Statistics Sweden's official statistics, 35 percent of Swedish companies with at least ten employees used AI in 2025, an increase of 10 percentage points from 2024. For an AI function that suggests the next offer, the customer's identity, the valid price and the available items need to match.

More real-time never makes incorrect master data correct. Faster transfer can make a wrong price reach more users sooner. That is why you need to store the source reference, validity period and version for information used in automated decisions.

Permissions also have to follow when data is combined. A salesperson may need to see payment status without access to every financial detail. Plan for human review of suggestions that affect price, credit or the customer's commitments.

Design the structure so more data sources can be connected using the same definitions. That does not mean everything has to be built from the start. Begin with clear definitions of customer, item, order and valid price so the next recipient can use them.

Metrics that show whether the integration reduces data silos

The following is a suggested follow-up routine after go-live. Adjust the intervals once you know where discrepancies arise and how quickly they need to be handled.

Track the match rate for customer records every week, meaning how many customer records are linked correctly through company registration number and customer ID. Track the share of failed messages daily, because it shows whether data risks going missing. Measure the delay from a booked order to the CRM every month with spot checks. Count manual corrections every month to see whether users are fixing recurring errors. Reconcile counts and amounts between the business system and the CRM daily, with an alert on any discrepancy.

A received message can contain the wrong customer reference or an amount with the wrong meaning. Technical monitoring therefore needs to be complemented by business testing. Have a salesperson and a finance colleague review the same customer journey from quote to payment.

Statistics Sweden's regulation on companies' digital ways of working covers analysis of transaction and customer data and electronic sharing with external parties. The regulation also covers CRM as a cloud service. That makes use, operating model and responsibility worth documenting together.

An approved business test should show that users can make the right decisions with the data in their view. Write acceptance criteria that can be tested. The sales manager should, for example, be able to analyse orders and customer data together. Relevant information should be shareable with external parties without unauthorised data coming along.

Say revenue per customer in the CRM differs from finance's report. Check the period, currency, credit notes and which order statuses are included. A daily reconciliation can catch the difference before anyone uses the figure in a management report.

Data coverage, update frequency and traceability need their own approvals. It should be clear which records are included and how old the data may be. Users should also be able to see when a value was last updated.

Thresholds have to be set from your own data. Treat preliminary limits as rules of thumb until you have measured and tested them. State at the same time who receives the alert, when that person acts and how the correction is documented.

What this approach requires and when a simpler solution is enough

A connection between the CRM and the business system needs an owner for customer data and a decision on which system owns each piece of data. Clean up the customer register before the first transfer and set aside time to test exceptions, such as credit blocks, returns and changed delivery addresses.

Sales and finance also need to know which fields they can change and where to request a correction when a value comes from another system. Set aside time to teach the new ways of working.

Automate the flows where waiting or manual handling actually gets in the way of the work. If almost all sales are handled in one system, a controlled export routine can be enough, especially with low volumes and few customer-specific contract prices. Appoint an owner, document the checks and add a recurring reconciliation.

Statistics Sweden's statistics on system use cover companies with at least ten employees and can be broken down by size, industry and region. Smaller companies may work differently. Choose your setup based on your organisation's needs and how your staff use the data.

In a group, you also need to clarify how data responsibility works between companies. Document which companies and regions use each system, whether customer numbers are shared or local and who approves changes.

Decide who owns ongoing management before go-live. The guidance on system integration and responsibility between systems can help you scope the work. Include version tracking, compatibility testing and bug fixes in your assessment of the total cost of ownership.

Glanser Care is a contracted responsibility at a fixed monthly cost that covers version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing. Still assess whether your data flow needs an integration or can be handled with a clear routine.

Three questions to ask the supplier before you choose a connection

Which system is master for customer identity, and how are company registration numbers normalised before matching? Ask the supplier to show how a parent company, a delivery location and a duplicate record are told apart. The answer reveals whether matching is based on documented rules or on uncertain assumptions about company names.

How is an order protected from being created again after an outage, and are idempotency keys used? Ask for a demo where the order is booked but the confirmation never reaches the sender. The answer shows whether the solution can handle retries without finance getting an extra order.

How are discrepancies between the business system and the CRM measured, who owns the alert after go-live and what happens during an upgrade? Ask the supplier to describe how an error is followed from alert to corrected record. The answer reveals what responsibility actually exists when the systems change. A vague answer is a signal to ask for a concrete example from a similar project.

A strong proposal should contain more than a diagram of the system connections. You need to be able to follow a message, see how a discrepancy is handled and understand who makes decisions. Also check that the test cases and the responsibility are included in the agreed scope.

The technical owner can explain formats and retries. The business owner also needs to approve how price, customer identity and order status are used. Both perspectives need to be part of how you assess the answers.

Map the data flows before you choose a connection

Take a quote with a contract price as a test case. Follow it from the customer's first details to the quote the salesperson uses, and note where someone has to check or add information by hand. That shows which flows to prioritise and whether the sync works in daily work.

Start with a review together with sales, finance and IT. Have them examine a concrete error, such as a payment term that was changed in the wrong system. Decide how the error should be detected, who corrects the data and how you check that the corrected information reaches the right place. Also document the test cases and who is responsible for them when the solution changes.

Then try the flow with test data. Check that the contract price shows correctly in the quote, that a change is not overwritten by another source and that an outage does not lead to duplicate transactions. Follow the whole chain, from entry to use, and have the roles involved approve the result.

In a 72-hour analysis, you set aside two hours, and within 72 hours you get an inventory of functions and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge.