Why Don’t My Systems Talk to Each Other?

There’s a person in a lot of Australian businesses whose job, for about an hour every morning, is to look at one screen and type what it says into another.

They export orders from the online store into a spreadsheet, tidy the columns, and load them into the accounting system. Or they take the enquiries that came in overnight and add them to the CRM by hand. Nobody planned this role. It accumulated. And it’s usually the first sign that a business has outgrown the way its systems were bought, and that business system integration is worth costing properly.

Why does this happen to everyone?

Because each system was a sensible decision on its own.

You chose the accounting package because your accountant recommended it. You chose the online store because it was the fastest way to start selling. The booking system came later, when phone bookings became unmanageable. The CRM arrived when the sales team grew past the point where a shared inbox worked.

Every one of those was the right call at the time. None of them were chosen with reference to each other, because at the point of each decision there wasn’t yet a whole to fit into. So you end up with four good systems and no arrangement between them, and the gap gets filled by the cheapest available connector, which is a person and a spreadsheet.

This isn’t a sign of mismanagement. It’s what growth looks like from the inside.

What does business system integration actually mean?

It’s worth knowing there are levels, because the word gets used for all of them and they differ enormously in cost.

Scheduled transfer. Something automatically exports from one system and imports into another on a timer, overnight or hourly. This is the cheapest option available, and for most businesses it’s entirely sufficient. It gets dismissed more often than it deserves. If your accounts team only looks at yesterday’s orders anyway, real-time buys you nothing.

Event-driven sync. When something happens in one system, the other is told about it more or less immediately. An order is placed, the stock level updates, the customer record appears in the CRM. More work, more moving parts to monitor, and the right answer when the delay actually costs you something, such as overselling stock you don’t have.

A single source of truth. Rather than copying data between systems, one system holds it and the others read it. Architecturally this is the cleanest answer. It also changes how a business operates, because it requires deciding which system owns what and then living with that decision.

Most businesses need the first, think they need the third, and are best served by the second in one or two specific places.

The hard part isn’t the connection

People assume the difficulty is technical: getting two systems to exchange information. That part is usually the straightforward bit. Most modern systems can be connected.

The hard part is agreeing what’s true.

Your online store has a customer called Jane Smith with one email address. Your CRM has Jane Smith with a different one, because she gave a work address at a trade show. Your accounting system has “Smith, J” attached to a company name because that’s how the invoice was raised. Are these the same person? A human glances at it and knows. A system needs a rule.

Then it compounds. If she updates her address in one place, which system wins? If the store says an item is in stock and the warehouse system says it isn’t, which do you show a customer? If a record is deleted in one system, should it vanish from the others, or is that how you accidentally destroy your audit trail?

These are business decisions, not technical ones, and they’re the reason business system integration projects take longer than expected. The code is the easy half. Getting three departments to agree which system is authoritative for a customer’s contact details is the half that takes the meetings. That work pays off well beyond the integration itself, because it’s the first time anyone has written the rules down.

What to ask before you buy the next system

The cheapest integration work is the work you avoid by choosing well. Three questions, asked before you sign, save disproportionate amounts later.

Does it have a proper API, and is it included? An API is the documented way for other software to talk to it. Plenty of products have one and place it on a higher tier, which is a cost you’ll meet at exactly the wrong moment. Ask specifically.

Can I get all my data out, in a usable form? The same question that matters for platform risk matters here. A complete structured export is the difference between a system you can integrate and one you can only feed.

What does it need to know about, and what needs to know about it? Answer this before purchase, not after. It occasionally changes which product you buy, and that’s a much cheaper way to solve the problem than building a bridge.

What it’s really worth

Where integration pays, it usually pays in three places at once.

The time is the obvious one and generally the smallest. The errors matter more: every manual transfer is an opportunity for a wrong number, and wrong numbers in an accounting system or a stock level cost far more than the minutes to prevent them. And the largest, hardest to see, is decision quality. When your systems agree, you can actually answer questions about your own business, rather than assembling an approximate answer from three sources that don’t quite match.

That last one is what businesses actually notice afterwards. Not the hour saved each morning. The fact that when someone asks how the quarter is going, there’s a single answer instead of a debate.

Simon Paul is a Business Solutions and Technology Specialist at Code Brewery who’s spent 25+ years turning business ideas into software that actually earns its keep. He’s talked as many clients out of integrations as into them, and considers both good days. Reach out to Simon to talk through how your systems could fit together.