Typing the same data twice? How to connect the systems you already use

Double entry is the same information typed by hand into a second system: a new client added to the CRM and again in the accounting software, a finished job copied onto an invoice, an online form retyped into a spreadsheet. Each copy takes minutes. Together they take hours every week, and every one is a chance to mistype a figure.

The larger cost is that the copies drift apart. Someone corrects a client's email address in one system but not the other, an invoice goes out with last month's figure, and nobody can say which version is right.

Before choosing any tool, write down every place where data is copied by hand. For each one, note:

• what is copied, field by field: names, email addresses, ABNs, amounts, dates
• from which system to which, and what sets it off, such as a deal marked won or a job marked done
• who does it, how often and how long it takes
• what goes wrong when it is late or mistyped.

The list usually shows a few hand-offs that cost the most time or cause the most mistakes. Start there. Some copies are not worth automating yet: a few records a week, mistakes that are quick to spot, data that rarely changes once it is typed.

Not every copy runs between two systems. When details are read out of emails and PDFs and typed in, the job is different: AI can read the documents and a person checks the result. And when one side of the copy is a spreadsheet, the better answer may be replacing the spreadsheet rather than connecting it.

The most important decision is not technical. For each kind of record, decide which system holds the original. A common split:

• the CRM holds contacts and deals, up to the sale
• the operations platform or job system holds the work: jobs, stages and tasks
• the accounting software holds invoices and payments.

The other systems receive what they need from it, and changes are made at the source. Where people really do change the same field in two places, such as a phone number updated by sales and by accounts, the integration needs a rule for which change wins. Without one, the two systems keep overwriting each other.

This is also where you set the direction of each connection: one-way where a system only needs to read, two-way only where people work in both.

Many products already connect to each other. Xero lists apps that work with it in the Xero App Store, and HubSpot lists them in the HubSpot Marketplace. Before building anything, see whether a ready-made connection between your two products exists, and test it against your list:

• does it move every field you need, including your own custom fields?
• does it run in the direction you need, at the moment you need, such as when a deal is won rather than once a night?
• how does it match records that already exist in both systems?
• when a sync fails, who finds out, and how?

If it passes, use it. A connection the vendor maintains is one less thing for you to look after.

An API is the published way for one system to read and write another's data. Xero's Accounting API (opens in a new tab), for example, lets apps retrieve, add and update contacts, and HubSpot documents its contacts API (opens in a new tab) as a way to sync contact data between HubSpot and other systems.

A direct integration earns its place when:

• there is no ready-made connection, which is common for industry software and for systems built for one business
• a connection exists but misses fields, or moves them at the wrong moment
• your own rules decide what moves and when, such as invoicing a job only once it has been approved
• one event has to update three or more systems, in order
• you need a record of every sync, and an alert when one fails.

The next four sections cover what such an integration has to get right. They work as questions to ask of a built-in connection too.

Names change and get typed differently, so an integration that matches on names creates duplicates. Xero's documentation recommends using its ContactID (opens in a new tab) to identify a contact, not the contact's name, and it has a ContactNumber field for the identifier another system, such as a CRM, uses for the same customer. In HubSpot, the email address is the main identifier (opens in a new tab) for avoiding duplicate contacts, and a business can add its own unique ID property, such as a customer number.

So when the integration creates a record on the other side, it should store that record's ID against its own, and look it up by ID every time after. Records that already exist in both systems need matching once, at the start, with a person checking the ones that do not match cleanly.

Every API limits how fast it can be called. Xero allows an app 60 calls a minute (opens in a new tab) for each connected organisation, plus a daily limit. HubSpot counts requests (opens in a new tab) per 10 seconds and per day, with limits that depend on the account's subscription: on a Free or Starter account, a privately distributed app can send 100 requests every 10 seconds, and all the apps in one account share a daily limit. Go over, and both answer with an error instead of the data.

Both also recommend sending records in batches, and Xero suggests scheduling or queuing large data pulls instead of expecting an immediate response. An integration built this way waits when it is told to and then carries on, instead of dropping updates at month-end, when volumes peak.

Instead of asking another system every few minutes whether anything has changed, an integration can be told. Xero sends a notification (opens in a new tab) when, for example, a contact or an invoice is created or updated. If the receiving end does not answer, Xero retries for 24 hours, then switches the notifications off and emails the app's developers; events from that time are kept for up to 31 days and sent again, in order, once it is fixed. Its documentation also says apps must be able to handle the same message being delivered again.

Two habits follow. The integration keeps a record of what it has already processed, so a repeated message changes nothing. And it checks on a schedule for anything it missed, so an outage is caught up rather than forgotten.

Give it only the access it needs. When a business connects an app to Xero, Xero shows which data the app is asking for (opens in a new tab), and its documentation tells developers to request the minimum. An integration that only reads invoices can be given read-only access to them.

Log every run. Each one should record what moved, what was skipped and why, and a failure should reach a person, with enough detail to act on, before a customer notices a missing invoice.

Test the awkward cases first, on test accounts or copies rather than live data: a customer with two email addresses, an invoice changed after it was sent, a deal reopened after it was won.

Pick the hand-off from your list that costs the most time or causes the most mistakes, connect it, and let it run through a full cycle of the work, such as a month of invoicing. Then read the log: how many records moved, how many failed, and why. Add the next connection after that. Connecting everything at once makes it hard to tell which part caused a problem.

Tell the team which system now holds what, and stop the manual copy on a set date. Otherwise someone keeps typing it in “just in case”, and the duplicates come back.

Vetrox is an Australian IT company that connects the systems businesses already use. We write each integration directly against each system's own API, two-way where it needs to be: Lark, Microsoft 365, Google Workspace, Xero, HubSpot, Stripe, e-signature services and shared drives. There is no extra service in the middle handling your data, and every sync is logged, so a failed update raises an alert instead of going missing quietly. If a ready-made connection already does the job, we will say so on the first call.