Xplan + HUB24 / Netwealth integration
Xplan and platform data that finally lets advisers see clients.
If you run Xplan alongside HUB24, Netwealth, Macquarie Wrap and a CRM that never quite agree on a single client record, here is how we would approach it. Melbourne financial advice practices spend half the week re-keying details into Xplan after a platform sync drops a field. An SOA that should be a half-day job can run two weeks because holdings, valuations, fee history and last year's strategy come from four systems that do not quite agree. A database-first approach underneath the four would aim to move the assembly off Friday afternoon and put the adviser back in front of the client. Capacity per adviser is the lever that still works after fee compression has taken the others.
Where Xplan and the platforms break the join
Xplan holds the planning spine: strategy, fact-find, SOA and ROA templates, fee model, review cadence. HUB24, Netwealth, Macquarie Wrap and BT Panorama hold the platform spine: holdings, valuations, fee history, statements. The CRM holds the relationship spine. The handoffs between Xplan, the platform stack and the CRM go wrong in a small number of named ways, and the practice principal tends to see the same patterns show up at every capacity review.
Fact-find and CRM
The client detail that has to be entered three times
Holdings reconciliation
The unit price HUB24 and Netwealth disagree on
SOA, ROA and annual review prep
The two-week assembly job
Compliance evidence scatter
The seven places the auditor walks
How we would approach Xplan and platform integration
Discovery before anything else
We would map where each piece of client, holding and fee data lives today, who edits it, and what "right" actually means. Which Xplan fields drive SOA generation, which platform feed is the silent canonical, where the workaround spreadsheet sits that the official systems never caught. If your practice sits under a licensee with an approved-vendor list, we surface that at the start so any integration fits inside the compliance framework rather than around it. That conversation is where the real data model comes from, not from reading the Xplan or HUB24 API docs in isolation.
Model the client-to-SOA join, not the API
The database-first move. Before building anything, we would write down the contract between a client, a fact-find, a holding, a fee event and an SOA section. Integration then becomes a question of reading from Xplan and the platforms, not negotiating between them after the fact. Reconcile at rest, in one place, not in the air between four vendor APIs while the adviser is in front of a client.
Reconciliation as a contract
Reconciliation would run on a nightly schedule. The Xplan fact-find, the platform holdings and the CRM client record get compared every night. Any drift surfaces to the head of operations before the morning huddle, tagged to the client, the holding, and the variance against the platform feed. Retries, idempotency and dead-letter handling get written down before the first line of integration code. If a HUB24 holding goes missing from the SOA feed, somebody finds out on day one, not at week two of the redraft.
Middleware that handles vendor failures
Xplan, HUB24, Netwealth, Macquarie Wrap and BT Panorama each misbehave in specific ways. Rate limits, auth-token refresh quirks, scheduled platform downtime on the weekend, silent payload changes on a quarterly release. We would build the integration on real infrastructure with queues, monitoring and alerts, so a throttled platform or an expired token raises a hand rather than quietly dropping a client's holdings update. When something breaks, the system tells you before the next SOA goes through compliance.
AI-ready as a side-effect
The reconciliation layer described above is also the data shape an AI agent would need to act on the practice safely later. One canonical record per client, audit trail by default, permissions modelled in the database, the agent reading from the source of truth rather than reconciling four platforms each time it acts. We would not bolt agents on in an integration engagement, but the work would leave the practice ready when the AI question lands.
We have done this since 2007. See who we are.
What this would typically look like in practice
Picture a Melbourne advice practice running Xplan on the planning side, HUB24 and Netwealth on the platform side, and Xplan's own CRM module on the relationship side. The advisers spend a third of their week chasing client details across systems that should have shared them. SOA prep runs into a second week per document because the back office pulls holdings, valuations and fee history from three places and then runs three rounds of compliance redraft. The pattern that usually triggers the call is a capacity review where the principal notices adviser-billable hours drifting down quarter on quarter while client headcount stays flat. The admin layer has been taking a percentage point of capacity each quarter, and nobody added it up.
A database-first approach would put a middleware layer in the middle of that. Each night it reconciles the Xplan fact-find, HUB24 holdings, Netwealth valuations and the CRM client record against each other. By the next morning the head of operations is working an exceptions list, one row per client whose record disagreed and the platform that last touched it. Xplan stays the planning system and the platforms stay the platforms; the layer just keeps them honest with one another. The aim is to move SOA prep from a two-week back-office job towards a half-day adviser-led one, and to give the principal a capacity number that stops sliding.
The aim of a database-first approach: the adviser opens one client record that already agrees with itself, instead of rebuilding the picture from four systems before every review.
From the Illustrative Xplan + HUB24 + Netwealth reconciliation case study
Illustrative pattern, not a specific client engagement. The database-first approach above is how we would take it on.
Common questions about Xplan and platform integration
Why not use Xplan's native platform feeds if they exist?
Use them if they cover your work. For a practice running a single platform with clean holdings, conventional fee structures and the Xplan modules sized to match, the native feed is the cheapest correct answer. Middleware earns its place when the feed misses fields the advisers actually use, drops valuations on a quarterly reset, cannot model the multi-platform spread that most growing practices end up with, or breaks the SOA generator because the fee history arrives in three different shapes. The diagnostic looks at what Xplan and your platforms already ship before anyone quotes anything new.
How would platform-and-Xplan reconciliation work if you built it?
The pattern we would propose puts a middleware layer between Xplan and whichever platforms the practice runs. HUB24 holdings, Netwealth holdings, Macquarie Wrap or BT Panorama valuations get pulled into a canonical client record overnight. Xplan reads from that record for SOA generation. The CRM reads from it for client communications. Discrepancies between what HUB24 says and what Netwealth says about a unit price would surface to the head of operations the same morning, with the client, the fund, and the variance attached. The point is to stop SOA prep finding the discrepancy at week two of the redraft.
What if our practice runs multiple platforms or is mid-transition?
Most growing practices do run multiple platforms. New money in one, legacy holdings in another, a third for a specific product range. A database-first shape handles that the same way regardless. Canonical client record in one place, each platform feeds it, Xplan reads from it, the CRM reads from it. A platform migration then becomes a question of rewriting the one vendor-specific feed rather than rebuilding the whole SOA pipeline. If you are mid-transition between platforms, the honest first step is a discovery call to map what you run today before we say anything about shape or scope.
How long would a Xplan and platform integration build take?
A realistic range is six to twelve weeks, depending on cleanup scope and platform count. Six weeks at the low end if you are on one platform, your Xplan modules are conventional, and the fee structures across the client book are tidy. Twelve weeks if you run three platforms, fee structures have drifted across legacy and new-money books, and the back-history needs reconciliation before the SOA generator can run cleanly. The diagnostic puts a real number on the table before you commit to anything bigger. We do not quote a build before we have mapped your actual data.
Does this set us up for AI agents on top later?
Yes, in principle. Step 5 above covers the same point. A database-first integration would leave the practice with a database it controls, one canonical record per client, audit trail by default, permissions modelled in the data layer. That is the shape an AI agent would need to act on the practice safely; adding agents later becomes a scoping question rather than a foundation question. We would not build the agents in an integration engagement.
How do you work alongside the dealer group or licensee?
Carefully and on the record. Many practices sit under a licensee that maintains an approved-vendor list for Xplan modifications and platform integrations. Tell us upfront. Any middleware would sit inside the compliance frameworks the licensee owns at the AFSL level, and we would expect it to live in your practice's infrastructure, not the licensee's, with every data flow documented for the next compliance review. We do not pretend the compliance officer is optional; database-first work is meant to make their audit week shorter, not someone else's problem.
Not sure if your practice needs middleware or a sharper Xplan setup?
Start with a conversation. We will look at how Xplan, the platforms and the CRM talk today and tell you whether you would need overnight reconciliation, a smaller fix, or a better Xplan setup.