How to connect CRM, inventory and billing without duplicating information

Three systems, three versions of the same customer

The salesperson updates the customer's phone number in the CRM. Billing still has the previous one. Warehouse ships to an address the customer changed a month ago. No one did anything wrong: each system has its own copy of the data and no rule says which one is authoritative.

Connecting systems does not start with the technical integration. It starts by deciding, for each piece of data, where it originates, who changes it and where it should travel.

Master data: one source rules, the others read

A master data item is one that several systems need and that must have a single official source. In a typical SME these are customer, product, price and order. For each, define an owning system: the only one where it is created and modified. The other systems receive it.

The assignment depends on your operation; the table is an example. The important thing is that each row has a single owner.

Synchronization: when and in which direction

• Direction: does the data flow one way or both ways? Two-way synchronization is most prone to conflicts; use it only if indispensable.
• Timing: real-time, periodically or end-of-day? Not everything needs to be immediate; stock levels perhaps do, tax data rarely.
• Trigger: what event starts the synchronization? An approved order, an issued invoice, a created product.

Reconciliation: checking that they match

Even if the integration works, it's advisable to periodically check that systems match. A simple reconciliation compares counts and totals: number of approved orders in the CRM versus number of invoices issued, or inventory stock versus what the website shows. Differences are investigated, not silently corrected by hand.

Failures: what happens when something doesn't arrive

Every integration fails sometimes: a system does not respond, a data item arrives incomplete, a message arrives twice. Define in advance what happens in each case: who gets informed, where the error is recorded and how it is retried. A useful concept is idempotency: design operations so that repeating them does not duplicate the result, as documented by many payment APIs. That way a retry does not create two invoices.

For electronic invoicing in Colombia, the rules are set by the DIAN. Any integration with your billing system must be reviewed by your accountant; this guide does not interpret those rules.

Procedure

1. List the systems you use and which data each holds.
2. Identify data that appears in more than one system.
3. Assign an owning system and a responsible person for each master data item.
4. Define direction, timing and trigger for each flow.
5. Define how reconciliation is done and how often.
6. Define what happens on a failure: notification, logging and retry.
7. Document everything in the systems map before requesting the integration.

Applied example

Limits

This guide does not evaluate vendors or connectors. Before integrating, confirm with each provider which data they expose and how. If a system does not allow connecting, the map still helps to organize manual work.

Criteria to decide who rules

The table describes common patterns, not a rule. What matters is that each data item has a single owner and the other systems read it.

Complete synthetic example

Synthetic example. A fictional company creates customers in the CRM, in billing and in a dispatch spreadsheet. When reconciling, it finds the same customer with three NITs written differently.

They decide billing is the customer master because the NIT is validated there. The CRM receives a daily copy and salespeople no longer create customers: they request registration from billing. The dispatch spreadsheet is replaced by an inventory report. Every Friday someone compares the number of active customers in both systems and reviews differences. Invented example.

How to use the downloadable map

1. List your systems and the data each contains.
2. Mark which is the master for each data item.
3. Describe the direction and frequency of each synchronization.
4. Note what happens if a synchronization fails and who is notified.
5. Review the map when you add or change a system.

Questions for your integration provider

• In which direction does each data item travel and with what frequency?
• What happens if a system does not respond: is it retried, queued or lost?
• Who receives the failure notification and in how much time?
• How is a data item that synchronized incorrectly corrected?
• Where is the record of what was synchronized stored?

How to know if it worked

• Each master data item has a single system where it is created and corrected.
• Weekly reconciliation shows fewer differences over time.
• Synchronization failures generate a notification that someone addresses.
• The team stopped creating the same customer in multiple systems.

Plan for the first four weeks

1. Week 1: fill the systems and data map.
2. Week 2: decide the master for each data item with the involved areas.
3. Week 3: adjust permissions so only the master can create records.
4. Week 4: perform the first reconciliation and correct differences.

Diagnosis before starting

• Find the same customer in all your systems and compare the data.
• Ask where a new product is created.
• Check if someone copies data by hand between systems.

A second example, by contrast

Synthetic example. A fictional company has only CRM and billing, with few sales per month. It does not integrate: it agrees that billing rules on customers, exports a weekly file and loads it into the CRM. Unlike the first example, the solution was an agreement and a routine, not an integration. Invented example.

What to do when something fails

• If a synchronization fails, correct it in the master and resynchronize, not in the destination.
• If duplicates appear, stop creation in the system that is not the master.
• If nobody receives failure notices, assign a responsible person.

Common mistakes

• Connecting everything to everything without defining owners.
• Using two-way synchronization by default.
• Not logging integration errors.
• Correcting differences manually without finding the root cause.
• Assuming billing integration is solved without accounting review.

Checklist

• Each data item has a master system.
• Synchronizations have defined direction and frequency.
• There is a periodic reconciliation.
• Failures generate a notification to a person.
• The map is up to date.