Xplan + HUB24 / Netwealth integration
Xplan and platform integration that finally lets advisers see clients.
We build the middleware that makes Xplan, HUB24, Netwealth, Macquarie Wrap and the CRM agree on a single client record. 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 runs two weeks because holdings, valuations, fee history and last year's strategy come from four systems that do not quite agree. Database-first underneath the four moves the assembly off Friday afternoon and puts 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 sees 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 approach Xplan and platform integration
Discovery before anything else
We 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 the 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 we build anything, we 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 runs on a nightly schedule. The Xplan fact-find, the platform holdings and the CRM client record are 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 are 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 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 we just described 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 do not bolt agents on in this engagement, but the work leaves the practice ready when the AI question lands.
We have done this since 2007. See who we are.
What this typically looks like in practice
A Melbourne advice practice we worked with was 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 spent a third of their week chasing client details across systems that should have shared them. SOA prep ran into a second week per document because the back office pulled holdings, valuations and fee history from three places and then ran three rounds of compliance redraft. The pattern that triggered the call was a half-year capacity review where the principal noticed adviser-billable hours had drifted down quarter on quarter while client headcount stayed flat. The admin layer had taken a percentage point of capacity each quarter for two years before anyone added it up.
Each night a middleware layer 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 stayed the planning system and the platforms stayed the platforms; the layer just kept them honest with one another. SOA prep moved from a two-week back-office job to a half-day adviser-led one, and the principal's capacity dashboard started moving in the right direction.
SOA prep moved from a two-week back-office assembly job to a half-day adviser-led one. The capacity dashboard started moving in the right direction.
From the Xplan + HUB24 + Netwealth reconciliation case study
Pattern story, anonymised. No named client, dates or dollar amounts. We will publish a named case study once a Melbourne advice practice engagement has consented.
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. We build middleware 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 we quote anything new.
How does platform-and-Xplan reconciliation actually work after integration?
The middleware sits between Xplan and whichever platforms the practice runs. HUB24 holdings, Netwealth holdings, Macquarie Wrap or BT Panorama valuations are 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 are flagged to the head of operations the same morning, with the client, the fund, and the variance. SOA prep stops finding the discrepancy at week two of the redraft.
What if our practice runs multiple platforms or is mid-transition?
Most practices we see do run multiple platforms. New money in one, legacy holdings in another, a third for a specific product range. The integration shape is the same regardless. Canonical client record in one place, each platform feeds it, Xplan reads from it, the CRM reads from it. A platform migration becomes a question of rewriting the one vendor-specific feed rather than rebuilding the whole SOA pipeline. We have run practices through HUB24-to-Netwealth and Netwealth-to-Macquarie migrations with both feeds in parallel for the cutover so no client loses a quarter of holdings history.
How long does a Xplan and platform integration build take?
Six to twelve weeks, depending on cleanup scope and platform count. Six weeks 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. Most builds we ship sit in the eight to nine week middle, and the SOA prep wins arrive in the first month rather than at handover.
Does this set us up for AI agents on top later?
Yes. Step 5 above covers the same point. The integration leaves 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 do not build the agents in this engagement.
How do you work alongside the dealer group or licensee?
Carefully and on the record. Many practices we work with sit under a licensee that maintains an approved-vendor list for Xplan modifications and platform integrations. Tell us upfront. We have worked alongside approved integrators and inside compliance frameworks where the licensee owns the AFSL-level controls. The middleware lives in your practice's infrastructure, not the licensee's, but every data flow is documented for the next compliance review. We do not pretend the compliance officer is optional; the database makes 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 need overnight reconciliation, a smaller fix, or a better Xplan setup.