Year-End Tax Packages for Wealth Clients
Summary
A year-end tax package has to reconcile to custodian forms the firm does not produce, which arrive in different formats and on different dates and are sometimes corrected. The firm's figures and the forms often differ, so the package should show each difference and its reason, carry a revision history, and be issued per client when that client's documents are in. For operations and technology leaders at wealth managers.
In the second week of February, a client with five accounts at three custodians sends her accountant the firm's year-end summary. The accountant has the custodians' tax forms open next to it. The summary shows realised gains of $41,280.55. The forms add up to $39,812.35. The accountant asks which is right. Both are, in a sense: the firm's portfolio accounting system and one custodian disagree about the cost basis of a position that was sold and bought back in December. It takes the firm's operations team two days to find the $1,468.20 difference, and the client has been told, in the meantime, that the numbers will be corrected.
The numbers did not need correcting. The package needed to explain itself. A year-end tax package is read by someone who will compare it line by line against documents the firm does not control, and any gap between them, explained or not, becomes a question. The design work is mostly about making that comparison easy, and about what happens when a document changes after the package has gone out.
What a Year-End Package Contains
The contents vary with the client and the jurisdiction, but a typical package for a client with several accounts has six parts. A cover note says what the package covers, when it was prepared, the cost basis method used, and what is not included. A summary page gives income, realised gains and losses and expenses by account and in total, split into whatever categories the client's filing requires. A per-account schedule lists each realised gain or loss with its acquisition date, sale date, proceeds, cost basis and result. Income and expense detail follows. A reconciliation page ties the firm's figures to the custodian documents. A last page lists the custodian documents themselves, with whether each has been received.
Nothing in that list is difficult to lay out. The difficulty is that the package sits between two sets of numbers: the firm's records, and the forms issued by each custodian. Those forms follow each custodian's own format and arrive on their own schedule, and a few of them will be corrected after they are first issued.
Show the Difference, Not Only the Total
Back to the $1,468.20. The firm's schedules and the custodian forms disagree in one account, and agree in the other two. A reconciliation page shows this directly:
| Account | Firm schedule | Custodian form | Difference | Reason |
|---|---|---|---|---|
| Joint account, custodian 1 | $24,115.10 | $24,115.10 | $0.00 | |
| Trust account, custodian 2 | $12,980.45 | $11,512.25 | $1,468.20 | Custodian adjusted basis on a repurchase; firm's records do not apply the adjustment |
| Personal account, custodian 2 | $4,185.00 | $4,185.00 | $0.00 | |
| Total | $41,280.55 | $39,812.35 | $1,468.20 |
A page like this changes the conversation. The accountant who sees the difference already explained does not need to ask for it, and the client can forward the package without the firm answering a question first. It also forces the firm to find the reasons before sending, which is cheaper than finding them with a client waiting. Which figure the client should use in a filing is a question for the client's tax adviser, and the page should say so; the firm's job is to state both figures and what accounts for the gap.
Two things make this page more useful than it sounds. First, the reasons should come from the people who know them. Cost basis methods, lot selection and adjustments for transactions such as repurchases are calculated and decided in the portfolio accounting or tax function, and the template can only print the explanation it is given. A column of blank reasons next to a non-zero difference is worse than no page, because it shows that the firm noticed the gap and could not explain it. Second, the page works only if the totals are consistent. If the total on the summary page differs from the total on the reconciliation page by a few cents because of rounding, the reader has found a new discrepancy while looking at the one that was meant to be explained. The totals should arrive from the system that calculated them, and a pre-generation check that compares each supplied total with the sum of its supplied lines catches many of these before they reach a client.
Corrections and Late Documents
The second problem is that the package has a date and the forms do not stop changing on that date. A custodian issues a corrected form in March for the trust account: $370.00 of dividends that were reported as taxable are reclassified as a return of capital. The firm's original package, sent in February, is now out of date for that client.
A corrected package needs three things the original did not. It has to identify itself as a revision, with a number and the date of the version it replaces. It has to say what changed, line by line, so the client's accountant does not have to compare two PDFs by eye. And it has to say why. A "what changed" page for this correction might look like this:
| Line | Revision 1 (9 February) | Revision 2 (14 March) | Change |
|---|---|---|---|
| Dividends, taxable | $6,310.00 | $5,940.00 | -$370.00 |
| Dividends, return of capital | $0.00 | $370.00 | +$370.00 |
| Total income, trust account | $6,310.00 | $6,310.00 | $0.00 |
Reason: custodian 2 issued a corrected form on 14 March reclassifying part of one distribution.
The total did not move, but a reader looking only at the total would not know that a filing line has. The "what changed" page appears only on revisions, and it has to be built from data: someone, or some process, has to compare the two versions of the figures and supply the differences. A template cannot see what the previous package said unless it is told. That makes a revision a versioning question as much as a layout one. The firm needs to keep what each package contained and to supply the changed lines when it issues the next one. The original needs to stay in the firm's own records, because a client or an accountant may later ask what was sent in February.
Issuing Per Client, Not Per Firm
The third problem is timing. Tax packages have a fixed early-year window, and the documents that feed them arrive staggered across custodians. A firm that waits for every document from every custodian before issuing anything delivers late to clients whose documents were all in by the first week. A firm that issues on a fixed date regardless sends incomplete packages to some, and corrections follow.
The workable pattern is readiness per client. Each expected custodian document has a status: received, pending, or not applicable. A household is ready when everything expected for it has arrived, or when the firm decides to issue with the pending documents listed on the last page and a note that a revision will follow. The first group goes out in the first run. The late households go out in a later one, and a late document triggers a revision for the households it affects instead of a new round of manual work. The cover note and the document list make the status visible to the client, so a package that goes out without one custodian's form says so and names the form.
At this volume the package also needs a review step before release, at least for the first run. A reviewer reading one sample package can check the layout, but the awkward cases (a household with an adjustment, one with a pending form, one with a revision) are the ones a sample misses.
How This Maps to CxReports
Here is how the pieces above map to CxReports. Each mechanism is described as documented, with the boundary stated where it matters.
The structure of the package. A cover page, a summary, a section per account and a closing page are a parent report with a repeated subreport for each account, the same pattern described in consolidated family office reporting. Page types cover the shapes a package needs: a cover page, countable pages, and rotated pages in landscape for wide lot-level tables. A Table of Contents component builds the contents page from headings and countable pages, and exported PDFs carry bookmarks. For packages that run to dozens of pages, see multi-page document generation.
The lot schedules. Each account's gain and loss schedule is a Data Table bound to the rows the portfolio accounting system supplies, formatted with text formats such as currency;USD;2. A footer or group caption can aggregate a column with Sum, Count or Average, but a footer prints whatever the supplied lines add up to. If the system's total and the sum of its lines differ by a cent, the template will print the sum. The pre-generation total check belongs in the data layer, and the lot-level calculations, including cost basis methods and adjustments, stay with the accounting system. For holdings that do not fit a lot-level table, such as private fund interests, see alternative and illiquid asset reporting.
The reconciliation page. The reconciliation table is a Data Table too, with differences supplied by the data layer. A Custom Style takes an expression and a style, so rows where the difference is not zero can be highlighted for the reviewer. The reasons are text supplied with the data. CxReports prints an explanation; it does not work out the cause of a difference.
Revisions. The revision number and the date of the version it replaces are report parameters, and a text template can print them in the cover note. A Page Visibility Expression based on a parameter shows the "what changed" page only when the package is a revision. The changed lines come from a data source, supplied by whatever compares the two versions. Each Job run keeps its generated PDFs in its run history, which helps for recent reference but is not an archive. A firm that needs to produce what it sent in a previous year should keep its own copy of every package.
Pending documents. Rows in a Key-Value Table have a Hide Condition, so a "pending documents" block appears only for households that have one. The status of each custodian document comes from the data layer.
Running it per client. A Report Generation Job with a repeating data source produces one entry per row. A data source that returns only the households marked ready yields one package per ready household, and the same Job run again later, with a source that returns the late or revised households, produces the follow-up packages. Report parameters bind to columns of the row, and email delivery can take its address from the row. One entry's failure does not stop the others. A Job can hold deliveries for review: entries wait, a reviewer approves or rejects them, and a consolidated review document can be generated across the run, so the awkward households are all in front of the reviewer. CxReports' role-based permissions control who can act on a Job, and the firm's own sign-off record remains its own.
Appending a fixed document. Document Merge attaches a selected PDF, with a start and end page, to a report. That fits a standard supporting document, such as the firm's tax disclosure notice. The documentation does not describe choosing the attached PDF per client from data, so confirm that before planning to append each client's custodian forms. The forms can also be listed on the last page and delivered separately.
Getting Started
| Year-end package need | CxReports mechanism | What stays with your team |
|---|---|---|
| Section per account | Subreport repeated per account | Which accounts belong to the household |
| Contents page and bookmarks | Table of Contents component, countable pages | Section order and naming |
| Wide lot tables | Rotated pages, Data Table | Lot selection, cost basis and adjustments |
| Reconciliation page | Data Table with Custom Style on non-zero differences | The differences and the reasons |
| Revision page | Report parameters, Page Visibility Expression | Comparing versions and keeping what was sent |
| Pending documents | Key-Value Table with Hide Condition | Document status tracking |
| One package per ready household | Job with a repeating data source | Deciding which households are ready |
| Review before release | Hold deliveries for review, consolidated review document | Sign-off |
Documentation:
Another annual, deadline-driven document is covered in marketplace seller payout statements and 1099 generation, and the batch run behind a year-end mailing in batch document generation. To see a year-end package built from your own account structure, request a demo.
This article covers reporting and document design. The figures are illustrative and do not constitute tax, investment or legal advice. Which documents and categories apply, and how gains and income are treated, depends on the client's jurisdiction and circumstances.