Industry research puts the scale of the coming generational wealth transfer at roughly $124 trillion moving to heirs through 2048, according to Orion's 2026 State of the Advisor report - and the same research finds that a majority of next-generation heirs say they plan to leave their benefactor's advisor once that transfer happens. Read those two findings together and the business problem becomes specific: a firm can retain a client relationship for decades and still lose the next generation of that same household, not because the advice was wrong, but because the way the firm communicates never adapted to who was actually going to be reading it.
This is a reporting design problem before it's anything else. The client who built the relationship over twenty years is often comfortable with a dense, traditional statement - full holdings detail, formal language, a printed-style layout. Their adult child, who may take over the relationship or inherit a share of the assets, often expects something closer to what every other financial app in their life already gives them: a cleaner visual summary, mobile-friendly, accessible without opening a PDF at all. Serving only one of these expectations, for a household that now spans both, is how firms lose the next generation while still retaining the current one.
What Actually Needs to Change Is Presentation, Not Data
The instinct when this problem comes up is to assume it requires building something new - a different reporting system for younger clients, a separate app, a parallel process. It doesn't. The holdings, the performance figures, the disclosures, and the underlying data are exactly the same regardless of which household member is looking at them. What differs is how that same information should be presented: how much detail is shown, what visual weight numbers get versus narrative context, and whether the output looks like a formal statement or a more visual summary.
This distinction matters because it changes the scope of the problem substantially. Building and maintaining two entirely separate reporting pipelines for the same household is expensive and creates exactly the kind of drift risk that shows up whenever two systems are supposed to represent the same underlying truth. Treating it as a presentation variant of one underlying dataset is a much smaller problem - and it's one that template design, rather than new infrastructure, actually solves.
Where This Is a Parameter and Theme Problem
Once the presentation-not-data framing is in place, the practical question becomes: what needs to vary, and what mechanism should drive that variation?
Format and detail level. One household member wants the traditional, comprehensive statement - every holding itemised, full disclosure language, the layout they've received for years. Another wants a condensed summary that leads with the numbers that matter (total value, performance, allocation at a glance) and treats granular holding-level detail as something to drill into only if wanted. Both views come from the same underlying holdings and performance data; the difference is which sections render and how much of the detail surfaces by default.
Visual style. Independent of detail level, the visual presentation itself - typography, colour use, how prominently charts versus tables are featured - can differ by recipient preference without touching the substance of what's reported.
Delivery channel. Some household members are well served by a PDF that lands in their inbox on the usual schedule. Others expect to see the same information inside a portal or app they already check regularly, without a PDF attachment at all.
None of these are data problems. They're recipient preferences, and preferences map naturally to parameters and template variants - a "recipient type" or "detail level" value that a household's reporting configuration carries per member, driving which sections of a shared template render and which visual theme is applied, rather than requiring a fundamentally different document for each generation.
Delivery Channel Matters as Much as Layout
Getting the layout right and then delivering it the wrong way solves only half the problem. A recipient who has told the firm, implicitly or explicitly, that they engage with financial information through an app or portal rather than an email inbox is not well served by a beautifully redesigned PDF that still arrives as an email attachment they have to open and read on their own initiative.
The two delivery models - a PDF sent to a recipient, and the same report embedded inside a portal or application a recipient logs into - are architecturally different, but they don't need to be content-different. A report built once, from one template and one data source, can be exported as a PDF for the household member who wants that, and the identical report can be rendered inside an embedded view for the household member who expects to find it in a portal instead. The design and data layer stays singular; only the delivery mechanism changes per recipient.
The Risk of Getting This Wrong
A firm that offers exactly one statement format is making an implicit bet that every member of every household it serves has the same reporting preferences the client who originally signed up had. For a single-generation relationship, that bet mostly pays off. For a household in the middle of a wealth transfer, it increasingly doesn't - and the cost of losing that bet isn't a complaint about formatting. It's an heir who, having no particular loyalty to a reporting style they never chose, moves the relationship to a firm whose communication style matches what they actually expect.
The fix doesn't require guessing what every future heir will want. It requires building the reporting layer so that offering a second, different presentation option is a template and parameter decision - something the firm can do when a household actually needs it - rather than a multi-quarter infrastructure project that only gets prioritised after the relationship risk has already materialised.
How This Maps to CxReports
Recipient preference as a report parameter. A household's reporting configuration can carry a parameter per member - detail level, visual style, or a combined "recipient profile" value - that the report reads at generation time to determine which variant to produce. This value comes from your CRM or household management system, not from CxReports itself; CxReports renders whichever variant it's told to render for that recipient.
Conditional sections for detail level. A component's Visible Expression, tied to the recipient profile parameter, controls whether the full itemised holdings table appears or a condensed summary section takes its place - from the same underlying data source, without maintaining two unrelated templates that could drift apart from each other over time.
Themes for visual style. The traditional, formal presentation and a more visual, modern presentation are captured as two Themes - typography, colour, table styling - applied to the same report structure. Generating the statement for one household member versus another is a matter of which theme is applied at generation time, not a different template.
PDF delivery for recipients who expect an attachment. Standard PDF export and scheduled email jobs handle the recipient who wants the statement to arrive on the usual cadence as a document they can save and file.
Embedded delivery for recipients who expect a portal. For a household member who checks a portal or app rather than an inbox, the same report can be displayed through CxReports' iframe embedding - authenticated via a short-lived nonce token issued by your application - so the statement appears inside the experience that recipient already uses, rather than requiring them to adopt a new one.
What stays outside CxReports: which household member gets which presentation and delivery combination is a preference your firm captures and maintains - in a CRM, a household management system, or a client preference record - and passes to CxReports as the parameter that selects the right variant. CxReports does not manage household relationships or determine generational preferences; it renders the variant it's given, consistently, every time.
Getting Started with CxReports
| Multi-generational reporting requirement | CxReports mechanism | What stays with your systems |
|---|---|---|
| Different detail level per household member | Report parameter + component Visible Expression | Recipient preference stored in your CRM/household system |
| Different visual style per household member | Themes (one traditional, one modern) applied per recipient | Preference determining which theme to apply |
| PDF delivery for attachment-preferring recipients | Scheduled email jobs with PDF export | Recipient list and schedule |
| Portal/app delivery for embed-preferring recipients | Iframe embedding via nonce token | Your portal or app surfacing the embedded view |
| One underlying dataset for every variant | Single report template and data source, varied by parameter | Holdings, performance, and disclosure data |
For documentation on report parameters, themes, and iframe embedding, see the CxReports documentation. To discuss a multi-generational reporting strategy for your client base, get in touch.