Annual Interest and Tax Certificates at Banks
Summary
Annual interest certificates look like a simple batch run until customers who do not fit one row arrive: accounts opened or closed mid-year, joint holders, migrated products. Getting them right means shaping the data per customer, account and period, calling the run finished only when three counts agree, and numbering each reissue so the bank can say which version a customer received. For operations and compliance leaders at banks.
On the second Monday of January, the contact centre at a bank with 220,000 savings customers takes three kinds of call. Some customers have not received their annual interest certificate. Some have received one that shows only half a year of interest. A few have received two, with different totals. The bank's batch ran over the weekend and, by its own count, finished. What it did not do was handle the customer whose savings account was migrated to a new product in June, so that her interest sits in two accounts with two numbers; the customer who closed an account in March; or the joint holders, one of whom received a certificate showing the full interest and the other nothing.
None of those are rare at this volume. A bank with 220,000 customers has thousands of migrated accounts, mid-year closures and joint holders, and each one is a customer who calls. This post is about the three places where an annual certificate run goes wrong: the shape of the data, how the bank knows the run is finished, and what happens after the first version goes out.
One Certificate Is Several Rows
A certificate looks like one document per customer: a name, a tax year, a total of interest. The data behind it is one row per customer, per account, per period. The total is a sum of those rows, and every exception is a case where the number of rows is not one.
A customer with a savings account closed on 14 June and a successor account opened on 15 June, on a different product, has two rows. A certificate that prints only the current account shows $688.07 of interest. The customer earned $1,100.25 over the year:
| Account | Period | Interest |
|---|---|---|
| Savings account (closed 14 June) | 1 January to 14 June | $412.18 |
| Premium savings account (opened 15 June) | 15 June to 31 December | $688.07 |
| Total for the year | $1,100.25 |
The certificate has to show both lines, with the period each covers, and a total that equals their sum. A reader who sees only the second line believes the bank under-reported. A reader who sees two lines and no explanation of why there are two will call to ask.
Joint accounts raise a different question. Interest of $1,100.25 on an account with two holders may be reported to each holder in equal shares, by a stated allocation, or in full to a primary holder, depending on the bank's policy and the rules that apply. If the split is equal, the figures are $550.13 and $550.12, because one cent has to go somewhere. Which holder receives the extra cent, and whether the certificate says anything about it, is a decision made before the template is built. The template then prints each holder's share, with the account identified as joint, and each holder has their own certificate generated from their own row.
Two principles follow. The shape of the data is decided upstream, in the system that calculates and allocates interest, and the template presents what it is given, one section per account and period, as many as there are. And the exception cases need to be in the test data, because a test run of fifty ordinary customers proves nothing about the ones who will call.
When Is the Run Finished?
The second problem is knowing when the run is complete. A single annual run is one of the few documents a bank produces where the deadline is fixed, the volume is at its highest, and a late or wrong document can affect the customer's own filing. A run that "finished" and left 3,000 customers without a certificate is not finished.
It helps to define completion in advance as three numbers that must agree. The first is the number of customers the source data says are eligible, according to the bank's own eligibility rules, including any minimum interest threshold. The second is the number of certificates generated. The third is the number delivered or otherwise made available. When the first two disagree, something was missed or failed in generation. When the second and third disagree, something failed in delivery. The difference is a list of named customers, and working that list is the bank's last step before it calls the run done.
Three practices make this manageable.
Start only when the data is final. Year-end interest postings, accruals and any late adjustments should be complete before the run starts. A run that begins on a fixed date, whether or not posting has finished, produces certificates that will be revised. The start should come from a signal in the source system, not from a calendar.
Run a pilot segment first. Before the full run, generate a small segment chosen to include the awkward cases: a migrated account, a mid-year closure, a joint holder, a customer with no email address. A reviewer can check each of those in a few minutes. Reading 220,000 certificates is not possible, so the review has to be targeted.
Separate generation failures from delivery failures. A certificate that failed to generate needs the data or template fixed and the customer re-run. A certificate that generated but failed to send, because of a rejected address or a mailbox problem, needs only the delivery retried. Treating both as "failed" and re-running everything doubles the volume and risks sending duplicates.
Reissues and Corrections
After the run, certificates change. An interest adjustment posts late. A holder's name was wrong. A customer asks for another copy because the first went to an old address. The bank then has two obligations: produce a document, and be able to say afterwards which version each customer was sent.
The first is a design question. A reissued certificate should identify itself as such, with an issue number and the date of the issue it replaces, so a customer or an accountant holding two PDFs can tell which one is current. A line such as "Issue 2, replaces issue 1 dated 28 January" gives the reader what they need. It appears only on reissues, and it needs a data field that says which issue this is.
The second is a records question, and the template does not answer it. The bank needs, in its own system, a record per customer and tax year of which issue was produced, when, to which address or channel, and ideally a copy of the document itself. A bank that can produce that record has an answer to "what did you send me in January?". A bank that has only a folder of PDFs and the knowledge that a run happened does not.
Customers also ask for copies. A request through the portal, a branch or the contact centre is a different pattern from the annual run: one customer, one year, right now. It needs to produce the same certificate the run would have produced, from the same template and the same data, and to be recorded in the same way as any other issue. Handling it through a separate hand-built path is how a reissued certificate ends up with a different layout from the original.
How This Maps to CxReports
Here is how those pieces map to CxReports. Each mechanism is described as documented, with the boundary of what CxReports does and does not do stated where it matters.
The certificate itself. One section per account and period is a repeating element or subreport driven by the rows the source system supplies. The interest lines are a Data Table with column formats such as currency;USD;2, and a footer or group caption can aggregate a column with Sum. A footer prints whatever the supplied lines add up to, so the total on the certificate should come from the system that calculated it, with a check that the supplied total equals the sum of its lines. The allocation between joint holders, the rounding of the odd cent, and the eligibility rules all stay in the source system. Rows that apply only sometimes, such as the "Issue 2, replaces issue 1" line or a joint account note, sit in a Key-Value Table, where each row has a Hide Condition. A whole page, such as an explanatory page for a migrated account, can be shown or hidden with a Page Visibility Expression based on parameters.
The annual run. A Report Generation Job with a repeating data source produces one entry per row, so a source that returns one row per eligible customer (or per holder) produces one certificate each. Report parameters bind to columns of the row, and a parameter can narrow the data source, which is how the pilot segment is run before the full one. A schedule can start the run, or the source system can start it through the API when interest posting is complete, with scheduled generation turned off. Email delivery can take its address from the row, and a delivery condition can skip customers with no address, in which case the delivery does not fire. How those customers receive a paper or portal copy is the bank's own process.
The three counts. A run's status reports how many entries are queued, completed, in error and waiting for review, and the run history shows the status of each entry and each delivery. That gives the second and third counts directly, and the first comes from the source data. One entry's failure does not stop the others. A failed delivery can be retried on its own without regenerating the PDF, which is the separation between generation and delivery failures described above. There is no single action that re-runs a whole run; a fresh generation is a new run.
An archive copy. An entry can fan out to more than one delivery, for example an email to the customer and an upload of the PDF to Google Drive or SharePoint. The second delivery is one way to put a copy in storage the bank controls. The run history is a working view of recent runs, not a long-term archive, and the record of which issue each customer was sent, with its retention period, is kept in the bank's own systems.
Review before release. A Job can hold deliveries for review: entries are generated and wait, a reviewer approves or rejects them, and a consolidated review document can be generated across the run. For a run this size the practical use is the pilot segment and the exception cases. CxReports' role-based permissions control who can act on a Job. The compliance sign-off remains the bank's own record.
On-demand reissue. The API's export endpoints generate a report for a given set of parameters and return the PDF directly. A portal or contact-centre system can call the endpoint with the customer, the tax year and the issue number, and receive the certificate from the same report the run uses. The same call can select the language through the lang option, an accessible PDF where a customer needs one, and, with the POST version, an encrypted PDF with a password. Export returns the file and does not send it: the calling system delivers it, or a Job configured for email is started through the API. Who is allowed to request a certificate for which customer is decided by the calling system before it asks. The CxReports token belongs to a user, so an integration should use a dedicated user with only the access it needs.
Getting Started
| Annual certificate need | CxReports mechanism | What stays with your team |
|---|---|---|
| Several accounts and periods per customer | Repeating section or subreport, Data Table | The interest calculation and period segmentation |
| Reissue and joint-holder notes | Key-Value Table with Hide Condition, Page Visibility Expression | Allocation rules and issue numbering |
| One certificate per customer | Job with a repeating data source | Eligibility rules and the start signal |
| Pilot before the full run | Job parameter narrowing the data source | Choosing a segment with the awkward cases |
| Completion check | Run status and per-entry history | The eligible count and the exceptions list |
| Archive copy | A second delivery to Google Drive or SharePoint | Retention and the record of issues |
| Review before release | Hold deliveries for review | Sign-off |
| Reissue on request | API export with parameters, returning the PDF | Who may request what, and the record of the issue |
Documentation:
For the batch mechanics behind a single large run, see batch document generation. Other annual documents with a fixed deadline are covered in marketplace seller payout statements and 1099 generation and payroll and benefits statements. To see an annual certificate built from your own account and product structure, request a demo.
This article covers reporting and document design. The figures are illustrative. What each certificate must contain, when it must be issued, and how interest is allocated between holders depends on the jurisdiction and the bank's policy, and is determined by its compliance team. Nothing here constitutes legal or tax advice.