How to Connect Two Business Systems That Don't Talk to Each Other

The cost is not the typing

Every business past a certain size ends up running two or three systems that were never designed to know about each other. A field service app and an accounting package. A CRM and an operations database. A scheduling tool, a payroll provider, and a spreadsheet somebody built in 2019 that turned out to be load-bearing.

The obvious complaint is the double entry — the same customer name, address, job number, and dollar figure typed into a second place by hand. That is real, and it is worth money, but it is not the expensive part.

The expensive part is that the two copies drift, and then nobody knows which one is right. A customer's address gets updated in one system and not the other, so an invoice goes to the old address. A job gets rescheduled in operations and the change never reaches the billing side. Someone runs a report and the number is wrong, and now three people spend an afternoon reconciling instead of working. Eventually the staff stop trusting both systems and start keeping a third record — usually a spreadsheet — because at least they know who maintains it.

That is the actual problem an integration solves. Not keystrokes. Agreement.

Four ways to connect two systems, cheapest first

There is a strong temptation to jump straight to building something. Resist it long enough to work through the options in order, because a fair number of integration problems are solved perfectly well at step two.

• Manual re-entry. What most businesses do now. Fine at genuinely small volumes, and the honest baseline you should measure the alternatives against — count the minutes per week before you assume it is intolerable.
• Scheduled export and import. One system produces a file, someone loads it into the other on a rhythm. Unglamorous, cheap, and completely adequate when the data does not have to be current to the minute and the volume is modest.
• A connector platform. Zapier, Make, and similar tools are very good at simple one-way triggers between popular products. They are weak at record matching, two-way sync, conditional logic, batches, and recovering from an error without creating duplicates.
• A purpose-built integration. Code that talks to both systems through their APIs, matches records on a real identifier, decides which side wins a conflict, logs what it did, and can be fixed when it breaks. More to build, and the only option that holds up under real volume and real edge cases.

The tell that you have outgrown a connector platform is specific and easy to recognize: the number of automations has grown past what one person can hold in their head, nobody is quite sure what triggers what, duplicates appear after every outage, and someone's unofficial job is checking whether the automation ran last night. At that point the connector is no longer saving you work — it has become an undocumented system with no error handling. The same trajectory shows up with low-code tools generally, which is covered in custom software versus low-code platforms.

Decide who owns each field before anyone writes code

Almost every integration that fails badly fails for the same reason: nobody decided, in advance, which system wins when the two disagree.

The fix is not to pick one system as the master of everything. It is to go field by field and name an owner. Accounting almost certainly owns the invoice, the payment, and the customer's billing terms. Operations owns the job, the schedule, and the crew assignment. The CRM owns the pipeline stage. Payroll owns pay rates. Once each field has an owner, the integration's behavior stops being a judgment call — the owning system writes, the other system reads, and a conflict has an answer instead of a meeting.

This is a business decision made by the people who run the business, and it takes an hour at a whiteboard. Skipping it is why so many syncs end up simply propagating whichever edit happened last, which teaches everyone on staff that neither copy can be trusted.

The parts nobody scopes for

Moving a record from one system to another is the easy half. What takes the time, and what separates an integration that survives from one that quietly corrupts your data, is the following list:

• Identity matching. Is "Smith Construction LLC" in one system the same company as "Smith Construction" in the other? Matching on names produces duplicates and false merges. You need a shared identifier, and creating one across two systems that never had one is usually the single largest piece of the work.
• Direction. One-way is dramatically simpler and safer than two-way. A surprising share of two-way requests turn out, on inspection, to be one-way in each direction on different fields — which is fine, and much cheaper.
• Timing. Real-time, every fifteen minutes, or nightly are three different systems with three different costs. Most operational data does not need to be real-time, and asking for it anyway buys complexity nobody needed.
• Failure. The other system will be down, slow, or rate limited at some point. The integration has to know what it already sent, retry safely, and never create a second copy of something it sent before the connection dropped.
• Field mismatch. The two systems will not agree on how to store a phone number, an address, a tax code, or a job status. Somebody has to define the mapping, including what happens to values that have no equivalent on the other side.
• Deletes and voids. A record removed or voided on one side rarely propagates cleanly, and this is the quietest source of long-running discrepancies.
• Visibility. When something does not sync, a human needs to find out from the system rather than from an angry customer three weeks later.

None of these are exotic. They are simply the questions that get skipped when an integration is described as “just push the customers over,” and they are the reason a job that sounds like a week is not a week. Working them out up front is the same discipline described in how to scope a software project.

First question: does your software actually allow this?

Before any of the above matters, find out whether the systems will let you in. This is a vendor question, and the answers fall into three groups.

Some products have a documented API that is genuinely usable, sometimes gated behind a higher subscription tier. That is the good case, and worth checking early because the plan requirement can change the arithmetic.

Some products offer only scheduled exports or a reporting feed. That is workable — it pushes you toward a file-based integration rather than a live one, which is often fine for accounting and reporting data.

And some products offer nothing at all: no API, no export worth the name, your data reachable only through their interface. That is worth treating as a strategic fact about the vendor rather than a technical inconvenience. A system that will not let you get your own data out is a system you cannot integrate, cannot report on properly, and cannot leave without pain. If that describes a core system, the honest conversation is about replacing it, not connecting it — and the practicalities of that move are in data migration to new software.

The most common version of this whole exercise, by a wide margin, is connecting an operations system to accounting, which has its own well-worn path in custom software with a QuickBooks integration.

Sometimes the right answer is not to integrate

Integration is a way of making two systems tolerable together. It is not always the cheapest way to make the problem go away, and there are three situations where building the connection is the wrong move.

The first is when one of the systems is a spreadsheet doing a job it was never meant to do. Syncing a spreadsheet is possible and almost always a mistake, because you are spending real money to preserve the least reliable component in the chain. The alternative is covered in when to replace your spreadsheets with custom software.

The second is when the only reason both systems exist is that neither one fully fits. If your team is in two products daily because each covers about sixty percent of the work, an integration locks in the split permanently and adds a moving part on top. Replacing both with one system that fits the actual operation is often less total work — the argument in signs your business has outgrown its software.

The third is when the real requirement is a report, not a sync. A great many “these systems need to talk” requests turn out to mean “I need one view of what is happening across both.” Reading from both systems into a single reporting layer is far simpler and far safer than writing into either of them, because nothing downstream can be corrupted by a bad write. That option is worth ruling out before anything else, and it is the subject of custom reporting software.

Credentials, access, and the boring safety work

An integration is a standing key to two systems, running unattended. That deserves a small amount of deliberate care: API credentials stored properly rather than pasted into a script, access scoped to the records the integration actually needs, a log of what was written and when, and a plan for rotating keys when the person who set it up moves on. None of it is elaborate, and all of it is much easier to do at the start than to retrofit. The general version is in custom software security for small business.

How we approach an integration

Brad Walker has spent more than twenty years connecting operational systems for contractors, professional firms, and service businesses from his base in Wake Forest, NC. An integration engagement starts with the same questions every time: which fields exist in both systems, who owns each one, how records will be matched, how current the data actually needs to be, what each vendor allows, and what should happen the morning the sync fails. Those answers usually shrink the scope — a good number of these projects turn out to be one-directional, nightly, and half the size the first conversation suggested.

Engagements are fixed price, with the scope agreed before development starts. You know what you are getting, what it costs, and when it lands.

Frequently asked questions

If two of your systems hold the same customer and give different answers, that is a fixable problem — and it is usually smaller than it feels once the fields have owners. Start the conversation. The first step is a discovery call to map what data moves between your systems today, who moves it, and what it costs you when the two copies disagree.