Automating the generation of 4,000 investor statements is a solved problem. The harder question is what happens between generation completing and distribution beginning - and whether you have given a human reviewer anything meaningful to actually review.
The answer at most organisations is: not really. The batch completes, the generation log shows 4,000 successes, and distribution is triggered. The assumption is that if the system generated without errors, the reports must be correct. This assumption fails in a predictable and specific way.
System-level errors - a report that failed to generate, a data query that returned an error - are caught automatically. But systematic content errors - a valuation date populated with the wrong period, a disclosure section suppressed when it should appear, a formatting problem that affects every report with more than three holdings - look like successes to the generation system. They are not errors. They are correctly generated reports that contain incorrect content.
The consolidated pre-distribution review exists to catch these. It is the step that makes automated batch generation safe to act on.
Why Human Review Before Distribution Is Not Optional
For a quarterly investor statement or a regulatory filing, the consequences of distributing incorrect documents are not recoverable in the way that a software bug is recoverable. The document has left the bank's control. It is in an investor's inbox. It may have been printed, forwarded, or acted upon.
The operational consequences cascade:
Regulatory exposure. A legally required document that contains incorrect information - wrong period, suppressed disclosure, incorrect holdings - is a regulatory event. The bank cannot simply send a correction and consider the matter closed. It needs a documented explanation of what went wrong, evidence of the remediation, and in some cases a formal notification to the relevant regulator.
Customer communications. An investor who receives a statement showing incorrect holdings or performance will contact the bank. The volume of inbound queries from a batch distribution error - even one that affected a small percentage of accounts - is significant. Customer service teams at period-end are already operating at capacity.
Audit record complexity. The original incorrect document is now part of the audit record. The correction is a separate event that needs to be documented, linked to the original, and explained. A compliance audit that encounters a correction cycle has more questions to ask than one that encounters a clean run.
None of these consequences are proportionate to the time required for a consolidated review before distribution. The review is not the bottleneck. Skipping it is.
The Impossibility Problem: You Cannot Open 4,000 PDFs
The honest constraint that consolidates review addresses is simple: no operations team can individually verify 4,000 statements before a distribution deadline. A single PDF review takes minutes. Four thousand of them, even at two minutes each, is over 133 hours. The quarterly statement cycle does not have 133 hours of review capacity between generation completing and distribution needing to go out.
The consequence of this constraint, at organisations without a structured solution, is one of two failure modes:
Spot-check without structure. Someone opens ten or twenty random reports and checks that they look reasonable. This process catches dramatic errors - a blank report, a missing logo, obviously wrong dates - but misses systematic content errors that affect a specific subset of accounts. The accounts that experienced the error are the ones the reviewer didn't pick.
No review at all. Distribution is triggered automatically once generation completes. This is fast and operationally simple. It is also the approach most likely to result in a distribution error reaching investors.
The consolidated review pack solves this without requiring 133 hours of reviewer time.
The Consolidated Review Pack Pattern
A consolidated review pack is a single document that contains all individual reports assembled in sequence - one after another - into a reviewable artefact. In the Arion PoC scenario: 4,000 investor statements, assembled into a single consolidated PDF.
The reviewer does not read this document from cover to cover. They use it to run a structured review that takes minutes rather than hours.
What consolidated review makes possible:
Systematic error detection through sampling. When 4,000 reports are in a single document, navigating to a random sample of 20 is fast. If a systematic error affects one in ten reports, a 20-report sample has a high probability of surfacing it. Spot-checking in a generated-files folder does not have this property - the reviewer must manually locate, open, and compare individual files.
Visual consistency verification. A reviewer scanning through a consolidated pack quickly develops a pattern expectation for what each report looks like. A report that deviates from that pattern - missing section, different header, unexpected blank area - stands out in a way it would not if opened individually.
Edge case identification. Reports generated from accounts with unusual characteristics - zero holdings, very large numbers of transactions, multi-currency portfolios - are easy to identify and explicitly review in a consolidated pack. The reviewer can search or navigate to known edge case accounts.
Disclosure presence verification. For regulated documents with mandatory disclosure sections, the reviewer can confirm that every report in the pack contains the required disclosures. This check is impractical with individual files; it is feasible with a consolidated document.
What a Reviewer Is Actually Checking
Effective consolidated review is structured around what automated validation cannot catch - content errors that produce well-formed documents. The review checklist should be explicit, short, and consistently applied:
Period correctness. Are all reports showing the correct quarter-end date? Incorrect period dates are a common batch error when parameter configurations are reused across cycles without updating the date values.
Structural completeness. Do all reports contain the expected sections? A conditional logic error that suppresses a holdings section for accounts with certain characteristics will be invisible in the generation log but obvious in the consolidated pack.
Disclosure presence. Are all required regulatory disclosures present in every report? For an investor statement that must carry performance methodology disclosures or risk warnings, the absence of these sections is a compliance problem even if the rest of the report is correct.
Data plausibility. Do the figures look broadly plausible? Zero valuations across all accounts, negative performance figures for a period of positive market returns, or holdings totals that don't match expectations are signals worth investigating before distribution.
Edge case accounts. A short list of known edge cases - the account with 50 holdings, the account that holds only a cash position, the account that recently transferred in - should be explicitly checked. These are the accounts most likely to surface template logic errors.
Branding and formatting consistency. Do all reports carry the correct logo, colour scheme, and header? For multi-fund or multi-entity batches, are each fund's reports using the correct theme?
The Rejection Workflow
Not every consolidated review results in approval. When a reviewer identifies an issue, the workflow needs to support a structured rejection:
Issue documentation. The reviewer records what was found - which accounts are affected, what the error is, the suspected cause. This documentation is part of the audit record for the run.
Root cause resolution. Depending on the error type, remediation might involve correcting source data, fixing a template parameter, or addressing a query logic issue. The scope of the correction determines whether a full rerun is needed or whether only affected accounts need to be regenerated.
Partial or full rerun. For errors affecting a small number of accounts, the corrected reports for those accounts can be generated separately and reviewed before being included in a supplementary distribution. For errors affecting the full batch, a full rerun is required.
State management. The run transitions back to "pending review" rather than directly to "approved for distribution." The remediated batch goes through the same consolidated review step as the original run, not a shorter informal check.
The documentation trail for a rejection and rerun is evidence that the bank's quality control process worked as designed. A regulatory inquiry that encounters a documented rejection and remediation cycle demonstrates more mature governance than one that encounters only successful first-run approvals.
The Consolidated Review as a Workflow State
The pre-distribution review is not just a quality check. It is a formal state in the batch run workflow. The significance of this is operational and governance-related: distribution cannot proceed without an explicit approval action by a named reviewer.
The workflow states for a batch run look like:
Data confirmed → Batch generation triggered → Generation complete → Consolidated review pack available → Review in progress → Approved for distribution → Distribution triggered → Distribution complete
Each state transition is logged: who triggered it, at what time, and - at the approval step - by whom. The approval is an explicit human action, not a timeout or an automatic advance.
This state model matters for the audit record. The generation log alone answers "what was generated." The approval log answers "who confirmed this batch was ready to distribute." For regulated investor communications, both records are necessary.
How CxReports Supports Consolidated Review
Consolidated review document. For a job run that holds deliveries for review, the Generate consolidated review document action stitches the generated batch into a single PDF. For a quarterly statement run, the batch can be assembled into one document for review before the per-investor distribution is released. This is the consolidated review pack. For how watermarks can mark documents as draft, reviewed, final, or confidential, see Watermarks as Document State Control.
Hold deliveries for review. By default, a job's deliveries fire as soon as its documents are generated. Enabling Hold deliveries for review on the job separates the two steps: entries wait in a pending review state, a reviewer approves or rejects them, and only approved entries are delivered. This is what creates the window for consolidated review: generation completes, the consolidated pack is reviewed and approved, and then distribution goes ahead. For what delivery tracking requires once distribution fires, see Delivery Tracking for Regulatory Documents.
Subreports for modular statement construction. For complex investor statements that include holdings tables, performance summaries, and disclosure annexes as separate components, CxReports subreports allow each component to be independently generated and assembled into the parent statement. This modular structure makes it easier to identify which component a systematic error originated from during review.
Job run history for run traceability. Each job run records its start time, per-entry status (including pending review, approved, rejected, and delivery failed), the PDFs produced, and the delivery status of each email. The consolidated review pack corresponds to a specific, identified run. Who triggered the run and with which parameters should be recorded by the calling system or your workflow platform, along with the formal sign-off where your governance requires a named approver record.
Workspace isolation for multi-entity batches. For banks running statements across multiple funds or legal entities, CxReports workspaces keep each entity's templates, data sources, and generated documents separate. The consolidated review pack for each entity is distinct.
Getting Started with CxReports
| Review workflow requirement | CxReports capability |
|---|---|
| Consolidated pack for pre-distribution review | Generate consolidated review document on a held job run |
| Separated generation and distribution steps | Hold deliveries for review, with approve or reject per entry |
| Modular statement components (holdings, performance, disclosures) | Subreports - independently generated, assembled into parent |
| Multi-entity or multi-fund isolation | Workspaces - separate templates, data sources, documents per entity |
| Run traceability for the approval record | Job run history (start time, per-entry status, PDFs, deliveries) |
Documentation:
If you are designing the review and approval workflow for a quarterly statement cycle, book a demo to see how held deliveries and the consolidated review document support a consolidated review step before distribution.