Xplan integration: what advisers can and cannot extract

Xplan stores most of a Melbourne wealth practice. What it does not store, advisers patch with Excel, Zapier, and a cabinet of HUB24 and Netwealth exports. The question every wealth firm asks before integration work is which fields they actually own outside Xplan. The honest answer is most fields are exportable, a few are exportable but lossy, and the licensee compliance overlay decides what the firm is allowed to automate at all.

The fields Xplan owns and the ones it shares

Xplan was sold as the integration hub. In a 12-person planning practice, that framing usually holds for the client record itself: name, address, dependants, fact-find answers, risk profile, goals. Xplan is also the obvious owner of the strategy, the SOA history, and the file-note trail. None of that needs to live anywhere else, and pulling it out into a second system is usually a mistake.

The fields Xplan does not own are the ones the platforms own. Holdings sit in HUB24 or Netwealth or Macquarie Wrap. Valuations come from the platform daily. Fee history, fee-disclosure consents, and the actual cash flowing into and out of each client account live on the platform side. Xplan can show a synced version of all of this, but the source of truth is the platform. When the sync drops a field or runs late, the adviser sees yesterday’s number. The practice manager finds out at the next review.

This is the first thing to be honest about. Xplan is the spine for client and strategy data. It is a downstream copy for holdings and fees. Treating it as the source of truth for what is on the platform is how the data drift starts.

What “exportable” actually means in practice

Most fields in Xplan are exportable. That sentence is technically true and operationally misleading. A field is exportable when the API exposes it cleanly, when the export retains the structure, and when the field’s meaning travels with it. Xplan satisfies the first two for the bulk of its data model. The third is where the integration work actually lives.

Custom fields are the obvious case. A practice that has been on Xplan for ten years has accumulated custom fields that capture local meaning: which adviser owns the partner relationship, which clients are flagged for the spring review batch, what the agreed-fee structure was before the most recent re-engagement. The field name exports. The free-text value exports. The shared understanding of what the field is for stays inside the practice. If the integration is moving Xplan data into a new CRM, that meaning has to be reconstructed by hand or it gets lost.

Then there are the exportable-but-lossy fields. Notes attached to a client are exportable as a flat blob. The thread structure, the author, the date stamp, the linked document, all of those are sometimes preserved and sometimes not, depending on which API endpoint the integration uses. SOA history exports as documents, but the version chain that tracks which SOA superseded which is harder to reconstruct outside Xplan. The lesson we have learned across several integrations is that a clean export is usually a structural export. A complete export is the structural export plus a documented translation layer, and the translation layer is where the work lives.

A working test we run early in any Xplan integration: pick five real clients, run them through the integration end to end, and have the responsible adviser look at the output and tell us what is missing. The first round always finds something. The integration is not done until the third round finds nothing.

HUB24, Netwealth, and the four other exports most practices ignore

The platform side has its own integration shape. HUB24 and Netwealth both have public APIs, both ship daily holdings and valuation feeds, and both have a documented mechanism for fee-disclosure exports. Macquarie Wrap and BT Panorama are similar in scope, with their own quirks. The technical work to consolidate platform data into one model is well understood. The harder problem is the practice has usually never sat down and decided which platform owns which client.

Most multi-platform practices we see hold this in adviser memory. Adviser A’s HUB24 clients, adviser B’s Netwealth clients, the legacy Macquarie Wrap book that nobody has migrated, and the BT Panorama subset that came in through an acquisition. The integration cannot consolidate what the practice has not first written down. The diagnostic call always includes this conversation, because it is the cheapest thing to fix and the most expensive thing to leave unfixed.

Beyond the four big platforms, there are exports most practices do not pull at all. The platform’s transaction-level fee history, broken down by client and adviser, is the input to a real revenue-per-client view. The corporate-actions feed lets the practice spot dividend reinvestments and capital returns before the client asks about them. The platform’s audit trail of trades and rebalances is the evidence the compliance officer needs at audit. None of these are hidden. They are documented. Practices ignore them because Xplan does not ask for them and the adviser’s daily workflow does not surface them.

A practice that wants to demonstrate value at the annual review benefits more from these exports than from any new feature in Xplan. The integration layer is what makes them usable.

SOA generation and the licensee compliance overlay

SOA production is where the compliance overlay shows up. Every wealth practice we work with has a licensee, and every licensee has its own view of what an SOA has to contain, in what order, with which disclosures, signed off by which compliance reviewer. The Xplan template engine handles the document layout. The compliance overlay decides what goes into the document and who gets to approve the version that goes to the client.

This matters for integration in two specific ways. First, the practice cannot fully automate SOA generation away from the licensee’s review queue. The compliance officer is in the loop because the regulator requires it. The integration’s job is to feed the compliance officer better source data, faster, in a structure they can review without reconstructing it. Pulling holdings from HUB24, valuations from Netwealth, fee history from the platform, and risk-profile evidence from FinaMetrica into one consolidated view, then handing that view to the compliance officer, is most of the time saved.

Second, the licensee usually has a list of approved vendors. If the practice runs on a dealer-group structure, any integration that touches client data needs to pass through that approval. We have worked alongside approved integrators, applied through licensees, and watched perfectly designed integrations stall in a six-week compliance review. The way to handle this is to surface it on the discovery call. If the licensee runs an approved-vendor list, the integration scope and the timeline both flex around it. Pretending the licensee will not look does not work.

The SOA workload itself moves from a two-week back-office cycle to a half-day adviser job, when the data feeds are right and the compliance template is set up to read from one consolidated record. That is the gain on offer. It does not happen by switching planning software. It happens by deciding which system owns which field and putting a real database underneath that the planning software, the platforms, and the compliance overlay all read from.

When Xplan integration becomes a custom CRM project

Most integration scopes start as “we want HUB24 and Netwealth to stop disagreeing about client X.” A useful number of them end up somewhere bigger. The pattern we see most often runs like this. The practice maps the fields. Six or seven of them turn out to be custom Xplan fields that capture how the practice actually operates: the referral source, the partner-of-record, the agreed review cadence, the fee structure before and after the most recent re-engagement. The adviser has been managing those fields through workarounds for years. Once the integration surfaces them as data the rest of the system can read, the practice realises Xplan was never modelling the work at the level they needed.

At that point the conversation shifts. The integration delivers a consolidated client record across Xplan and the platforms. The custom layer models the parts that Xplan does not natively capture: capacity per adviser, the review pipeline by quarter, the compliance-readiness score, the partner-of-record handoff. Xplan stays, because the advisers open it every day and replacing it would be a different and much larger project. The custom layer sits next to it, and the database underneath captures the truth across both.

This is when Xplan integration becomes a custom CRM project. It is not a re-platform. The practice keeps its planning software and its platforms and its licensee relationship. What changes is that the work the senior adviser used to hold in their head is now modelled explicitly. The practice runs the same way on the day a senior adviser takes leave.

We saw the shape of this play out in a recent wealth-management CRM rebuild. The starting point was an Access database that captured ten years of operational logic and was about to fall over. The work was to reverse-engineer the data model, preserve the business logic, and build the surface the firm actually needed without tearing out what already worked. Manual data entry dropped 80% and capacity per adviser went up without another admin hire.

If you want a sense of which path your practice is on, the integration page covers the engagement model and what we ask for upfront. The integration service overview describes the diagnostic and the build sequence. The wealth management page covers the broader picture for a 10-30 adviser practice. If the conversation turns out to be about a custom CRM in disguise, that has its own shape and we will say so on the call.