Short answer
Custom integrations connect the systems your firm already runs so data stops being re-keyed between them. Practice management to document management, ledger to workpapers, CRM to billing. No two Australian firms run the same stack, which is why this is a service line rather than a product.
Most accounting firms do not have a software problem. They have a joins problem. Every system in the practice does its job competently, and every hand-off between them is a person copying something from one screen into another.
That work is invisible on any timesheet, it is where a surprising share of errors originate, and it is almost never anybody's job to fix.
The joins we see most often
Practice management to document management. XPM, MYOB AE, APS or Karbon on one side; FYI, SharePoint, iManage or Active on the other. Jobs and documents that should share a client record and a status, and instead share a naming convention that everyone interprets slightly differently.
Ledger to workpapers. Xero, MYOB, QuickBooks or Reckon into whatever your firm actually prepares workpapers in — which, for most practices, is still Excel. Getting the trial balance in without an export-import round trip removes an entire class of version error.
Document capture to ledger to file. Dext or Hubdoc into the ledger is solved. Dext into the ledger and the right folder in the document management system with the right name is usually not.
SMSF systems. Class and BGL alongside the rest of the practice stack, where the SMSF division often runs as an island with its own duplicate client data.
Reporting. Fathom, Spotlight or Float pulling consistently from the ledger, with the mappings maintained centrally instead of being rebuilt per client.
Billing. Job records to invoices to the ledger, without WIP being reconstructed from memory at month end.
How we approach a build
We use documented APIs where they exist, which for the major Australian practice tools is most of the time. Where a system has no usable API we work with its import and export formats rather than automating a browser — a screen-scraped integration is a maintenance liability that breaks the first time a vendor ships a UI change.
Everything is built to be observable. When an integration fails at 2am, somebody needs to know what failed, what it was carrying, and whether it can safely be re-run. Integrations that fail silently are worse than no integration, because the firm stops checking.
Where the value shows up
| Symptom | Underlying join |
|---|---|
| Client details differ between two systems | No authoritative client record |
| "Which version of this workpaper is current?" | Ledger and workpaper are not connected |
| Documents saved under three naming conventions | Capture and document management not joined |
| WIP surprises at month end | Job records and billing not joined |
| Nobody can say what stage a job is at | Status maintained by hand |
Integration is usually the prerequisite
Firms often come to us wanting to automate a compliance workflow, and the audit finds that the actual blocker is that two systems do not talk. The AI part of an AI automation is frequently the smaller half of the build. Getting clean, current data to the point where it is needed is the larger half, and skipping it is why so many AI pilots quietly stop being used.
Our six-step method for automating compliance workflows covers how we sequence this, and the AI tools guide maps which parts of the stack already have good native options — including tools we do not sell and would not build.