The short answer
Duplicate data entry becomes an integration problem when all three of these are true:
- It happens often enough that the time or delay adds up.
- Mistakes are costly: a wrong address ships an order to the wrong place, or a missed update means an invoice is never sent.
- The systems involved can be connected through a supported method, and you can decide which system is correct when they disagree.
If only the first is true, a process change is often cheaper. If the third is not true, an integration will create new problems rather than solve the old one.
Step 1: map where the re-typing happens
Pick one flow of work from start to finish and write down every place the same information is entered. Here is a common example for a small business selling to other businesses.
Hypothetical lead-to-order flow for a small distributor
| Step | Who | System | Information typed |
|---|---|---|---|
| 1. Enquiry arrives | Customer | Website form | Name, company, email, need |
| 2. Lead created | Sales | CRM | Same name, company, email (retyped from the email notification) |
| 3. Quote sent | Sales | Spreadsheet template | Company, contact, products, prices |
| 4. Order accepted | Sales | CRM | Deal marked won, amount retyped |
| 5. Customer set up | Accounts | Accounting system | Company, billing address, tax details |
| 6. Invoice raised | Accounts | Accounting system | Products and prices retyped from the quote |
| 7. Payment status | Sales asks Accounts | "Has Company X paid?" |
In this invented example, the company name is typed four times and product prices twice, and payment status travels by email.
Step 2: decide which system owns each kind of information
Before connecting anything, agree which system is the source of truth for each kind of information. Without this, an integration simply copies disagreements faster.
| Information | Sensible owner | Others should… |
|---|---|---|
| Contact details and sales history | CRM | Read from the CRM |
| Billing address, tax details, invoices, payments | Accounting or ERP | Read from accounting |
| Products and prices | ERP or accounting (price list) | Use the same price list |
| Website enquiry text | Website record, then CRM | Keep a link back to the original |
Each record also needs a shared identifier, such as a customer number stored in both systems. Matching on names or email addresses alone creates duplicates, because people change jobs and companies trade under several names.
Step 3: score each re-typing point
Use a simple scoring table to decide what to do about each point of re-entry. Score each from 1 (low) to 3 (high).
| Re-typing point | Frequency | Cost of error | Delay caused | Can be connected? | Total |
|---|---|---|---|---|---|
| Website enquiry → CRM | |||||
| Won deal → accounting customer | |||||
| Quote lines → invoice lines | |||||
| Payment status → CRM |
- High totals where connection is possible: good integration candidates.
- High totals where connection is not possible: consider changing the process or one of the systems.
- Low totals: leave them alone for now. Not everything needs automating.
When a process change beats an integration
Sometimes the cheapest fix is organizational:
- Stop using the spreadsheet. If the CRM or accounting system can produce quotes, one step and one copy disappear.
- Give read-only access to the system that owns the information, instead of copying it elsewhere. If sales can see payment status in the accounting system, step 7 goes away.
- Use a built-in connector that the vendors already support, rather than building something custom.
- Batch the work. Entering new customers once a day from a clean list can be good enough when volumes are low.
When you do integrate: plan for exceptions
Real integrations spend most of their effort on the unusual cases:
- Duplicates: what happens if the same enquiry or order arrives twice?
- Missing data: what if a required field (such as a tax number) is empty?
- Conflicts: what if the CRM and accounting system show different addresses?
- Outages: what if one system is unavailable or rejects the request?
- Limits: APIs usually limit how many requests you can make. HubSpot, for example, publishes different limits for different plans.
A good design keeps failed records in a visible queue, retries them, alerts a named person, and never silently drops them.
Reconciliation: how you know it is still working
Even a well-built integration drifts over time as people edit records by hand or products change. A reconciliation check compares the systems regularly, for example "won deals without an invoice" or "invoices whose customer is missing from the CRM". An empty report is the goal. Anything listed gets fixed at its source, and repeated problems point to a rule that needs changing.
A note on one-off migrations
If the goal is to stop using one system entirely, you may need a one-off data migration instead of an ongoing integration. Most business systems offer import tools; ERPNext's data import, for example, accepts CSV or Excel files for inserting or updating records. Migrations need the same care with owners, identifiers and reconciliation, but only once.
Next step
When you have mapped a flow and scored it, the integration readiness checklist helps you gather what an integration project needs before asking anyone for a quote.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- API usage guidelines and limits, HubSpot Developers
- Data Import, ERPNext documentation (Frappe)
- Overview of SuiteTalk REST Web Services, Oracle NetSuite Help Center
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.