Replacing Mail Merge and Spreadsheet-Built Documents
Summary
Many firms produce monthly client documents from a Word template, an Excel sheet and one person who knows the hand edits. Migrating means writing those hidden rules down, rebuilding the highest-volume document first, and running old and new side by side for a cycle. AI can draft the layout but cannot know the rules. For operations and finance leaders.
On the third working day of the month, a firm sends 380 clients their account summary. The person who normally runs it is on leave, so a colleague opens the Word template, points it at the Excel sheet and merges. The result looks fine. What the colleague does not know is that the regular operator fixes about twenty letters by hand every month: deleting the deposits paragraph for clients who made none, removing the old address line for clients with a pending change, and nudging the table for the household whose long name pushes the signature block onto a page of its own. This month none of that happens. Three clients receive a paragraph describing a deposit that never occurred. One of them calls.
Nothing in the merge failed. The process depended on rules that lived in one person's routine, and the tools had no place to keep them. This post is about moving a document like that to an automated report. There is no legacy reporting product to map from, so the starting point is the documents and routines the firm actually has.
What Breaks, and Why It Is Hard to See
A mail merge has a simple model: one row of data fills one copy of a document. That model holds up while every recipient looks alike. It starts to bend when recipients differ, and the bending shows up in two places.
The document stops fitting the data. A table with a different number of rows for each recipient, a name that runs to three lines, a paragraph that applies to some clients and not others: each of these needs a decision the merge cannot make, so a person makes it, document by document. The layout also moves with the content. A page that fits the average client overflows for the one with fourteen holdings, and a clean merge preview says nothing about the exceptions because the exceptions are not in the first few records. Getting one PDF per recipient out of the merge, rather than one combined file, typically takes a further step such as a macro or an add-in, which is one more thing that works until the person who set it up leaves.
The process lives in a person. The steps are known to one or two people: which sheet is current, which filter to apply, which clients to skip, what to check before sending. Changes to the template happen in the file itself, so the version in use is the one somebody last saved, and a file named "statement_final_v7" is a sign that no one can say which version went out in March. Afterwards there is little to look at. The sent folder shows what went out, and nothing shows what should have gone out, so a missing recipient or a wrong paragraph surfaces only when a client mentions it.
Neither problem is a flaw of Word or Excel. Both tools are doing what they were designed to do. The cost comes from asking a personal productivity tool to be a production process, and the cost grows with volume, with the number of variations, and with how often the one person who understands the whole thing is unavailable.
Migrating Without a Legacy Tool to Map From
A migration off a reporting product usually starts with a list of templates to convert. Here there is no such list, because these documents were never registered anywhere. The first job is to find them.
Inventory the documents, not the files. For each document that goes to clients or partners on a regular basis, write down who receives it and how many, how often, where the data comes from, who runs it, and what is done by hand. The last column is the one that matters. A short example of what it looks like:
| Document | Volume | Where the data lives | Hand edits today | Who runs it |
|---|---|---|---|---|
| Monthly account summary | 380 a month | Sheet exported from the accounting system | Delete deposits paragraph when there are none; fix long names | One person in operations |
| Fee notice | 60 a month | Sheet kept by finance | Replace the fee table by hand for clients on a special rate | A finance analyst |
| Welcome pack | About 15 a month | Typed into Word from the CRM | Paste each client's details | Whoever onboarded the client |
| Year-end confirmation | 380 once a year | Same sheet as the summary | Different wording for clients who closed an account | One person, with a checklist |
Pick the first document by volume and hand edits together. The welcome pack is the easiest to rebuild and saves the least. The monthly summary has the most volume and the most hand edits, which means it carries both the largest saving and the largest risk, and that makes it the right first target. A migration that starts with the easy document tends to stall after it, because the harder ones are still waiting and nothing has been learned about them.
Write the hand edits down as rules before building anything. "Delete paragraph three for clients with no deposits" is a rule. "Fix the long names" is a symptom, and the rule behind it might be a column width, a font size or a page break. This step is the slow one, and nothing downstream can replace it. A rebuilt template reproduces the rules that were supplied to it. The ones that stayed in someone's head or in a spreadsheet macro that has not been opened in two years are not in the template, and they come back as errors in the first live run.
Run old and new side by side for one cycle. Produce the month's documents both ways and compare three things: who received one (the recipient lists should match, and where they do not, one list is wrong), the figures for a sample of clients chosen to include the awkward cases, and whether each written rule shows up in the output. Expect some differences to be the old process's errors, found for the first time because something is now being compared against it. Decide which output is right in each case, record the decision, and once a full cycle matches, stop using the old path for that document. If the spreadsheet remains available as a delivery method, it will be used.
Where AI Helps the Move, and Where It Does Not
The slow part of rebuilding a document is usually not the thinking. It is reproducing a layout that already exists: the header, the table, the signature block, the spacing, in a new tool, from nothing. This is where an AI design assistant can save time. Given a description of the current layout, or a screenshot or PDF of an existing document, it can produce a structural first draft that a person then reviews and corrects, instead of building each document from a blank page.
The limits are specific.
The draft is a draft. The assistant has a layout to copy, but it has no way to know that the figure in the third column is the closing balance rather than the opening one, or that a particular paragraph only applies to certain clients. Connecting data and checking that the right field feeds the right place stays with the document owner, and so does the wording of anything a client reads. A visually faithful draft that binds to the wrong field is more dangerous than an obviously rough one, because it looks finished.
It does not know the rules that were never written down. If a spreadsheet macro silently drops a certain kind of client, or an operator has always skipped a particular account, the screenshot shows none of that. This is the same gap as in the previous section, and no tool closes it. It is closed by the person who runs the process telling someone.
And attaching a file means sending it somewhere. A screenshot, PDF or data sample given to an AI assistant goes to whichever model provider the organisation has configured. Using a blank version of the document, or one filled with invented clients, avoids sending a live client record to a third party, and that choice belongs to the firm, ahead of any template work.
How This Maps to CxReports
Here is how the migration steps map to CxReports. Each mechanism is described as documented, with the boundary stated where it matters.
Getting the data in. The documented data source types are SQL, API, JSON, CSV, JavaScript and MongoDB, so an Excel workbook is exported to CSV or JSON first. A CSV or JSON data source holds pasted static content, which is enough to prove a rebuilt template against last month's sheet. For a recurring run, the data should come from wherever the sheet's contents originated, through an SQL or API data source, or be supplied with the request: the API accepts a data payload when a report is generated, and a Job run accepts params and data. Whether that source is clean, current and complete is not something the template can check.
The merge step as a Job. A Report Generation Job with a repeating data source produces one entry per row, which is the merge. Parameters bind to columns of the row, a schedule can start the run, and an email delivery can take its address from the row. A delivery condition can skip rows with no address instead of failing them. The steps the one person used to remember are now settings on the Job that anyone with access can read.
Layout that follows the data. A Data Table renders however many rows its data source returns, with column formats and group captions or footers where a section needs them. The template is designed once for the exceptions as well as the average client, and it is previewed against awkward records before it goes live. For documents that run to several pages, see multi-page document generation.
Conditional content without hand edits. The "delete this paragraph for clients with none" rule becomes a condition. A page can be shown or hidden with a Page Visibility Expression based on parameters, a row in a Key-Value Table has a Hide Condition, and a cell in a custom table has a Visible Expression. Each one needs the rule to be written down first, and a template with the wrong condition applies the wrong rule consistently.
A review gate for the side-by-side cycle. A Job can be set to 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, which is useful for the comparison cycle. CxReports' role-based permissions control who can act on a Job, and the decision that the new output is correct enough to replace the old remains the firm's own.
Change control and a record of the run. Data Export saves the workspace's reports, templates, themes and related configuration as a file, so exporting before a change gives a copy to store with the change record. Keeping that copy and noting what changed and why is the firm's own routine. The Job's run history shows the status of each entry and each delivery and keeps the PDFs the run produced, so a missing recipient shows up as a missing entry. It is not a long-term archive. A firm that must keep the documents themselves for years needs its own storage for them.
The AI Assistant. The assistant works inside the report editor, and a person needs a role with the AI permission, plus an AI integration configured in the workspace with the provider's API key (OpenAI, Anthropic, Google or DeepSeek are supported). It accepts attachments: PNG, JPEG and WebP images, PDFs (not with DeepSeek) and JSON or CSV files, up to three per message. PDFs are uploaded to the AI provider, which keeps them for a period that depends on the provider, and the assistant reads the full text of JSON and CSV files, so their content is sent to the model. When it creates a data source from an attached file, the data source holds the file's exact content, which is another reason to attach anonymised data. The assistant does not edit themes or workspace settings. Business rules that have been written down can be stored as an AI Skill linked to the report, which is then included automatically in conversations about it. Whatever the assistant builds is a first draft for the owner to check.
Getting Started
| Mail merge world | CxReports mechanism | What stays with your team |
|---|---|---|
| Excel sheet as data | CSV or JSON data source for a trial; SQL, API or request data for recurring runs | The quality and currency of the data |
| One row, one document | Job with a repeating data source | Deciding who receives what |
| Sending the results | Email delivery from the row, with a delivery condition | Address quality and recipient consent |
| Hand edits per client | Page Visibility Expression, Hide Condition, Visible Expression | Writing the rules down and approving them |
| Rebuilding the layout | AI Assistant draft from a description, screenshot or PDF | Data binding, wording and review |
| The version people used | Data Export before each change | The change record |
| Checking the first cycle | Hold deliveries for review, with a consolidated review document | Sign-off on the comparison |
Documentation:
For the wider case for moving off manual processes, see the ROI of switching from manual to automated reporting, and for the batch run behind a monthly mailing, batch document generation. The same phased approach, applied to a legacy reporting product, is described in Crystal Reports migration with AI. To see one of your own merge documents rebuilt, request a demo.
This article covers reporting and document design. The examples are illustrative; confirm any regulatory or contractual requirements for your documents with your compliance team.