Systems integration

Why it matters

Re-keying is the hidden tax of a growing business. Every order typed twice is time lost and an error waiting to happen, and every report that needs a spreadsheet to reconcile two systems is a decision delayed. Integration removes that tax, gives owners a single view of the business and makes it possible to add staff and sales without adding administrators. It also carries risks: a badly designed integration spreads errors at machine speed, which is why design matters more than the connector.

Why systems stop talking

Systems drift apart because they were bought one at a time, each for its own purpose, with nobody responsible for how they fit. The CRM has a customer named one way, the accounting software another, and the e-commerce platform a third. Over time, staff invent manual bridges: a Friday export, a shared spreadsheet, a person who "knows the numbers". These work until the volume grows or the person leaves.

The symptoms are familiar: the same data entered more than once, reports that disagree, customers asked for details they have already given, and month-end that takes days. Before buying any integration tool, list these symptoms and the systems involved. The most painful handoff is almost always the first one worth integrating, and it is usually between whatever takes orders and accounting.

How integration actually works

Modern software exposes an application programming interface, or API: a documented way for other software to read and write its data. A webhook is the reverse, a message a system sends out when something happens, such as "invoice paid". Integration tools use these to build a flow: something triggers, data is fetched, reshaped so the receiving system understands it, written in, and the result checked. Whether a flow runs the instant something changes or on a schedule depends on how quickly the business needs the data to match.

The hard part is rarely the connection. It is the transformation: matching a customer across systems when the names differ, mapping a product code to an accounting item, deciding what to do when a record is missing. Good integrations make those rules explicit, log every run, and tell someone when a record fails rather than skipping it silently.

Decide who owns the truth

Every piece of shared data needs one system that is its master, the source of truth, with the others receiving copies. Customers are usually mastered in the CRM or the order system, products in inventory or e-commerce, and money in accounting. Once that is decided, data should flow one way for each type wherever possible. Two-way sync of the same field between two systems is where most integration headaches live, because each system can overwrite the other.

Write these ownership rules down on a single page: for each type of data, which system is master, which systems receive it, how often, and who is responsible when it breaks. This page is more valuable than any connector, and it is what an integrator, in-house or external, needs on day one. Where a business is connecting several systems or has customer-facing processes that depend on them, SMBH Consulting’s integration work typically starts with exactly this map before any code is written.

• One master system per data type; everything else receives.
• Prefer one-way flows; use two-way sync only when genuinely necessary.
• Use stable identifiers such as a customer ID, not names, to match records.
• Decide the rule for every failure case: missing customer, unknown product, duplicate.

Keeping integrations healthy

Integrations fail quietly. A vendor changes its API, a password expires, a new product category breaks a mapping, and nobody notices until the accounts do not reconcile. Treat each integration as a small system with an owner, monitoring and a routine. Logs should be reviewed, failures should raise alerts to a person, and a monthly reconciliation between systems catches what the alerts miss.

Security deserves specific attention. Integrations use credentials that often have broad access; those should be dedicated accounts with the minimum permissions needed, stored securely and rotated when staff change. Any integration that handles personal information is part of your privacy obligations, so know what data flows where, including to any integration platform in between.

How to integrate your business systems

1. List the handoffs Every place data is re-keyed or exported between systems, with the time it costs and the errors it causes.
2. Pick the most painful one Usually orders to accounting. One integration done well teaches more than five started.
3. Write the data ownership map Master system for each data type, direction of flow, matching identifiers, failure rules.
4. Choose the method Native connector if it covers the need; integration platform for the gaps; custom API work for core, complex processes.
5. Build and test with real data Run it alongside the manual process for a few cycles and reconcile the results.
6. Add monitoring and an owner Alerts to a person, a monthly reconciliation and a documented fix-and-replay procedure.
7. Switch off the manual bridge Retire the Friday export. Then move to the next handoff.

Real-world example

A Perth retailer connects store, warehouse and accounts

Swan River Outdoors sells camping gear online and from one store. Orders arrive through the e-commerce platform and the point-of-sale system, stock is picked by a third-party logistics warehouse, and everything is re-entered into accounting by a part-time bookkeeper. Stock levels on the website are updated by hand each morning, so popular items oversell on weekends, and month-end takes four days of reconciliation.

The owner maps the handoffs and writes a one-page ownership rule: the e-commerce platform masters products and stock, the order systems master customers and orders, and accounting masters money. A native connector pushes online and store sales into accounting daily. An integration platform sends paid orders to the warehouse and returns dispatch confirmations and stock counts to the website every fifteen minutes. One custom piece handles a loyalty rule neither vendor supports. Failures alert the operations lead by message, and a monthly reconciliation report compares the three systems. Overselling stops, the bookkeeper’s month-end drops to a day, and the business adds a second online channel the following year by connecting it into the same map.

Common mistakes

• Two-way sync of everything Letting two systems overwrite each other creates loops and corrupted records. Pick a master and flow one way.
• Matching on names Customer and product names change and vary. Match on stable identifiers, and create them if you have to.
• No owner, no alerts An integration nobody watches will fail silently and be discovered at BAS time.
• Integrating a broken process Automating a messy handoff moves the mess faster. Fix the process, then connect it.
• Shared admin credentials in the connector Using the owner’s login for an integration gives it total access and breaks when the password changes. Use dedicated, limited accounts.

KPIs to track

• Hours of manual re-keying per week The baseline before integration and the figure after. The gap is the direct return.
• Integration failure rate Failed records as a share of records processed. Investigate anything above a fraction of a per cent.
• Reconciliation differences The number and value of mismatches found at the monthly check between systems. Trending to zero is the goal.
• Time to detect a failure How long between an integration breaking and a person knowing. Minutes with alerts; weeks without.

Frequently asked questions

Do I need a developer to integrate systems?

Not always. Native connectors and integration platforms handle many common flows without code. A developer becomes necessary for complex rules, high volumes, or systems with poor connectors; even then, keep the custom part small.

What is an API?

An application programming interface is a documented way for one piece of software to read and write another’s data. If a product has a good public API, almost anything can be connected to it; if it has none, you are limited to manual exports.

Real-time or scheduled sync?

Match it to the business need. Stock levels on a website benefit from near real-time; pushing sales to accounting once a day is usually fine. Scheduled flows are simpler and cheaper to run.

Is it safe to use an integration platform with customer data?

Reputable platforms are widely used, but data does pass through them, so review their security and privacy terms, use minimum-permission credentials, and include them in your privacy documentation.

Key takeaways

• Integration removes re-keying, but a design flaw spreads errors at machine speed; design before connecting.
• Write a data ownership map: one master per data type, one-way flows where possible.
• Use native connectors first, an integration platform for gaps, and custom API work only for core processes.
• Match records on stable identifiers, never on names.
• Every integration needs an owner, alerts to a person and a monthly reconciliation.