Integrations
Integrations built on one database, not a chain of Zaps.
We build the middleware that lets the tools your firm already runs agree on one record. Melbourne accounting, legal, wealth and allied health firms where Xero, LEAP, Xplan, Salesforce or HubSpot each hold a piece of the client, and staff re-key the same fields into every system. Database-first integration, so reconciliation happens in the data model once, not inside a brittle chain of Zaps every night.
What integration actually means
Integration covers three different kinds of work, plus a fourth that has to run underneath all of them. Knowing which one you actually need saves six months and a lot of money.
- One-way push. The simplest case. Xero posting invoices into a reporting tool; LEAP pushing matter IDs into a document folder; the CRM firing a welcome email when a new client is created. Low risk, easy to set up.
- Two-way sync. Two systems, either side can edit, rules for who wins when both change the same field. Useful when both tools already exist and removing one is not on the table. Expensive when those rules are missing.
- Source-of-truth consolidation. One database holds the canonical record; every other tool reads from it. This is the database-first pattern. Staff stop arguing about which system has the right phone number.
- Reconciliation. The unglamorous part. A scheduled job that compares what Xero says against what the CRM says and flags any differences for review. Most integration failures we fix live here, usually because a Zap silently dropped records overnight and nobody noticed for three months.
Most firms need a mix of all four. The real question is which tool wins which fight, and who gets woken up when one of them breaks.
Tools we work with
Accounting
Xero, MYOB, Karbon, XPM
Invoice and bill sync, reconciliation, time-entry push from practice management, and cleaning up the gap between what Xero says and what the practice manager thinks is billed. BAS-season pain, measured and removed.
Legal
LEAP, Actionstep
Matter-based workflows, trust-accounting reconciliation, client and matter sync between the practice management system and whatever else the firm runs (Outlook, document store, accounting). WIP visible to partners on Friday, not hunted through Outlook. Conflict checks that actually fire before the engagement letter goes out.
Wealth
Xplan, HUB24, Netwealth
Adviser records consolidated across platforms, portfolio holdings and valuations reconciled between HUB24 and Netwealth, SOA production fed from one data model instead of three spreadsheets and a screenshot. Annual review prep stops taking a full week of adviser time per client.
Health
HL7 messaging, VINAH, VEMD
HL7 message generation and routing, regulatory submissions to Victorian hospital data collections, and the reconciliation between clinical systems and the reporting system that keeps compliance managers out of trouble.
Cross-cutting tools
HubSpot and Salesforce come into nearly every build on the sales side, where pipeline has to land in the operations system without stopping at the handoff. Microsoft 365 or Google Workspace sit underneath all of it, carrying single sign-on, calendar, email and the document store that decides whether staff keep data in the system of record or back in a folder of attachments.
Six integration pairs we keep solving
Melbourne firms searching for LEAP and MYOB, Xero and Karbon, or Xplan and HUB24 integration usually arrive with the same pair-shaped problem we have solved before. Each pair has a failure mode that off-the-shelf connectors and chained Zaps cannot survive at production volume.
Legal
LEAP + MYOB
Trust-accounting reconciliation between matter management and the ledger. Staff hand-key transfers each month and a partner notices three months later that two of them never landed in MYOB.
Accounting
Xero + Karbon (or XPM)
Practice management writing time entries that land in Xero invoices without re-keying. Karbon tasks tied to the same client record as the books, not a sister spreadsheet that nobody updates.
Trades
Simpro + ServiceM8
Quote booked in Simpro, dispatch ticket opened in ServiceM8, invoice back in Xero. The join breaks when the field tech updates labour on the van and the office invoices the original quote.
Wealth
Xplan + HUB24 or Netwealth
Holdings reconciled between Xplan and platform statements. HUB24 and Netwealth disagreeing on the unit price at end of month is where SOA prep usually breaks, and a manual override slips through review.
Health
VINAH and VEMD reporting
VINAH and VEMD reports built straight off the clinical systems, not hand-stitched at month end. Validations run overnight; the compliance manager finds out about an error on the day, not a quarter later when the state report does not match.
Manufacturing
Oracle APEX + MES or ERP
Legacy APEX systems sitting under the production floor, where the database is alive but the surrounding tooling has aged out. We extend the data layer without forcing a forklift rewrite of twenty years of business logic.
Most engagements touch more than one pair, so treat the labels as a starting point, not the scope.
How we approach it
Discovery before anything else
We map where each piece of data lives today, who edits it, and what "right" actually means. Which fields are load-bearing. Which ones only look important. Where the staff already have a workaround spreadsheet that the official system never caught. That conversation is where the real data model comes from, not from reading vendor API docs.
Model the data, not the API
The database-first move. Before we build anything, we decide what the canonical record looks like and which system owns which field. Integration then becomes a question of reading from the sources, not reconciling disagreements after the fact. Reconcile at rest, in one place, not in the air between four APIs at three in the morning.
A contract, not a hope
For every integration we write down what moves where, in what shape, how often, and what happens when it fails. Retries, dead-letter handling, idempotency, alerts to a human when something cannot recover on its own. If a record disappears, somebody finds out on the day, not three months later when the quarterly report does not add up.
Middleware that tells you when it breaks
We build the integration layer on real infrastructure with message queues, monitoring and alerting. When a vendor throttles, when an auth token expires at 2am on a Sunday, when a payload shape changes without notice, the system raises a hand rather than quietly dropping records. When something breaks, the system tells you before your client does.
AI-ready as a side-effect
The integration layer we just described is also the substrate an AI agent would need to act on the business safely. One canonical record per thing, audit trail by default, permissions modelled in the database, the agent reading from the source of truth rather than reconciling four vendor APIs each time it acts. We do not bolt agents on in this engagement, but the work leaves you with the shape that makes adding them later a question of scoping, not foundation.
We have done this since 2007. See who we are.
Proof
A 12-adviser Melbourne wealth management firm was running its client record through an Access database built by a former employee. Xplan, HUB24 and Netwealth each held a different slice of the truth. Staff resisted double-handling notes between email and the CRM, so notes drifted across systems and the practice manager could no longer tell which version was current. They had evaluated Salesforce Financial Services Cloud and ruled it out on cost. They had built Zapier flows that broke when volume grew. Melbourne wealth practices running Xplan with HUB24 or Netwealth feel this most directly; we cover the advisory side on our wealth management page.
We rebuilt the CRM on a normalised data model that owned the client record. Xplan, HUB24 and Netwealth fed into it. The integration sat underneath the existing tools rather than replacing them.
Manual data entry collapsed. Advisers got hours back each week.
From the wealth management CRM case study
Read the wealth management CRM case study
A Victorian public health service was submitting regulatory reports manually through a state government portal. Hours of staff time every week, compliance risk on every upload, and a dedicated admin hire that reduced the cost without reducing the errors. They had tried checklists. The checklists were fine. The manual step was the problem. Victorian hospitals running HL7 messaging and VINAH or VEMD reporting feel this most directly; we cover the clinical-systems angle on our hospital software page.
We built automated HL7 generation with validation and error tracking running overnight. The system pulled data from their internal systems, validated it against the state reporting requirements, and generated properly formatted submissions.
Submissions ran nightly, unattended. The error rate fell.
From the HL7 regulatory reporting case study
Common questions
What if a native connector already exists?
Use it. If Xero's native Karbon connector, a LEAP-to-accounting plugin or a Salesforce AppExchange app genuinely covers the three fields you need and the volume you push, that is the cheapest correct answer. We build middleware when the native option misses the fields, loses records at scale, cannot handle your custom logic, or does not exist at all. The diagnostic includes checking what the vendors already ship before we quote anything new.
Does Zapier or Make cover it?
Often, yes. Zapier and Make are legitimate tools for small-volume, low-stakes flows where the cost of a missed record is low. We use them ourselves for internal ops. They stop working well when the volume grows past a few hundred records a day, when the logic gets conditional, or when you need to guarantee that a record arrived. At that point you need proper middleware with queues, retries and alerts, which is usually where we come in.
What if the vendor's API is bad?
Most of them misbehave in some specific way. Rate limits, missing fields, silent truncation, undocumented auth changes. A good integration assumes the API will misbehave and handles it, rather than pretending everything works. We have seen most of the failure modes that Xero, LEAP and Xplan APIs can throw, and we design around them rather than hope.
Who owns the data?
You do. The middleware is yours, the database is yours, the integration logic is yours. When we hand over, everything is documented and running on infrastructure in your name. If we walked away tomorrow, your team or another developer could pick up the keys and keep it running. No per-seat licence, no vendor lock-in. A big consultancy earns its keep on multi-country rollouts and hundred-user programs; for a 30-person firm the overhead rarely pays back.
What happens when the vendor changes their API?
Vendors change APIs every few years. The first question is how much notice. Xero, LEAP and Xplan usually give several months' warning; Salesforce is good about versioning; HubSpot is variable. A proper integration isolates the vendor-specific code into one layer, so when the change comes you rewrite that layer and leave the rest of the system alone. We have moved clients through a dozen of these. It is never painless, but it is never catastrophic either.
How long does an integration take?
It depends on what "integration" means for you. A one-way nightly push between two systems with clean data can be a few weeks. A two-way sync with reconciliation across three systems and a legacy data migration can be three to six months. The honest answer comes out of the fixed-price systems diagnostic, which includes a scoped estimate before you commit to anything bigger.
Does this set us up for AI agents and automations later?
Yes, and increasingly that is why firms come to us before the AI conversation rather than after. The integration is the foundation: a database you control, with the canonical record per thing, audit trail and permissions model that AI agents need to act on the business safely. Without that substrate, an agent has nothing to act on except whatever each vendor API exposes that week, and no record of what it did. We do not build the agents in this engagement, but the work leaves you with the data shape that makes adding them later a scoping question, not a foundation question.
Not sure where the integration really starts?
Start with a conversation. We will map what talks to what today, and tell you honestly whether you need middleware, a new source of truth, or just a better data model.