The Report Nobody Wants to Build Every Monday Morning
No is questioning why someone keeps rebuilding the same spreadsheet every week by hand
TL;DR
At most community banks and credit unions, somebody spends part of every Monday morning rebuilding a report by hand: exporting the same files, pasting them into the same spreadsheet, fixing the same formatting problems, and sending the same summary. The spreadsheet was built years ago by someone who has since moved on. This post separates reports that get rebuilt from reports that update themselves, and describes what a narrow fix looks like when the problem is scheduling rather than analysis.
Somewhere in your institution, a person spends part of every Monday morning rebuilding a report. The routine is specific. Export a file from the core. Export a second file from another system. Open the spreadsheet that lives on a shared drive. Paste the first export into the tab where it goes. Notice the dates imported as text again. Fix that. Paste the second export. Refresh the pivot table. Check last week's figure against this week's because one of them looks wrong. Copy the summary into an email. Send it to the same six people.
An hour and a half, give or take. Every week. The same hour and a half.
To make things worse, the spreadsheet was probably built by someone who left company years ago. Nobody fully understands the formulas in columns M through R, so nobody touches them. When the core upgrade changed the export format last spring, a workaround got added rather than a fix, because the fix would have meant understanding columns M through R. Nobody has ever put this on a project list. It is ninety minutes a week, which is small enough to absorb and large enough to matter: roughly two full working weeks a year, spent typing numbers that already exist in systems the institution already owns.
This Problem Is Older Than Most of Your Systems
It is worth establishing that this is not a local failure of organization. It is a well-documented condition of the industry, and institutions have been telling regulators about it directly.
When the federal banking agencies asked for comment on the Call Report, one of the responses came from Bank of Bird-in-Hand, a community bank in Lancaster County, Pennsylvania. Its January 2026 comment letter is short and unusually plain. Asked which parts of the report take the most work, the bank named five specific schedules and explained that manual adjustments to core data are still required because of timing, processing and formatting issues, and because the core system does not have the tools to calculate some line items.
Read that last part again. In 2026, a bank's core system cannot produce certain figures the bank is required to report, so a person calculates them by hand every quarter. The more instructive answer is the next one. Asked whether software exists to automate this work, the bank said yes, and identified upkeep and implementation as the biggest hurdles. Availability was never the problem. The problem is that adopting and maintaining the tool costs more attention than the institution has spare.
That is the honest constraint at this asset size, and it explains why this category of work survives every technology cycle. It is never the top priority, the tools that address it are heavier than the problem justifies, and the person doing the work has already absorbed it into their week. The Call Report is the quarterly, regulated version of this. The Monday report is the weekly, internal version. The mechanism is identical: a number that a system cannot produce in the shape somebody needs, so a person produces it manually, forever.
A Report and a Dashboard Are Not the Same Thing
These two words get used interchangeably, and the difference between them is the whole issue. A report is something a person builds. It requires someone to gather inputs, assemble them, and distribute the result. It exists because that person did the work this week. If they are on vacation, it does not exist.
A dashboard is something that maintains itself. The inputs are connected once, the logic is defined once, and it reflects current data whether or not anyone is thinking about it. If the person who set it up leaves, it keeps working.
Most institutions have reports where dashboards would serve them better. This usually is not a decision anyone made. The report started as a one-time request from an executive who wanted to see something, the person asked built it in the tool they had, the executive found it useful and asked for it again, and a weekly obligation quietly came into existence without anyone ever deciding to create one.
The cost compounds in a way that stays invisible. A report that lives in one person's routine is also a continuity risk. When that person is out, either the report does not go out or someone else attempts it from an undocumented spreadsheet and produces a number that is subtly different, which is worse.
The Narrow Fix: Scheduled, Not Rebuilt
The instinct when a reporting problem finally surfaces is to look at business intelligence platforms. For one weekly report, that is the wrong size of response, and the Bird-in-Hand letter explains why: implementation and upkeep are exactly where these efforts fail.
The contained version does one thing. It connects to the same two data sources the person exports by hand, applies the same transformations they apply every Monday, and produces the same output on a schedule. Same numbers, same layout, same recipients, without the ninety minutes.
The scope is narrow on purpose. It covers one report. It does not restructure the institution's data, replace a reporting system, or require anyone to learn a new interface. Our automation and micro-apps page describes the general approach to tools built at this scale.
The step most people skip is the most valuable one. Before automating anything, somebody has to write down what the spreadsheet actually does, including columns M through R. That documentation is worth something regardless of whether the automation gets built, because right now the institution's understanding of this calculation exists only in a file nobody can read and a former employee's memory.
Sometimes that exercise ends the project early, in a good way. A meaningful share of recurring reports turn out to have a supported equivalent already available in a system the institution owns, unused because the original builder did not know it existed or it did not exist yet in 2021. That is a fifteen-minute fix that has been costing ninety minutes a week for five years.
What This Looks Like in Practice
Consider a $650 million community bank where an operations analyst produces a weekly deposit and loan activity summary for the executive team. Two exports, one spreadsheet, one email, most of Monday morning.
The analyst is good at this. They also know the numbers well enough that the actual insight, the reason the summary exists, takes them about ten minutes at the end. They can see that a category moved and usually know why. That interpretation is the part the executive team values, and it is the part that gets the least time.
With the assembly scheduled, the summary is generated before the analyst sits down. Their Monday starts with reading the numbers rather than producing them. The email they send contains the same figures and considerably more of what those figures mean. The report did not get better because the technology is more sophisticated. It got better because the person who understands the numbers now spends their time on the numbers.
What This Actually Frees Up
The honest answer is not a headcount reduction, and framing it that way tends to kill these projects during the conversation with staff. What it frees up is attention. In most institutions, the people assembling recurring reports are also the people best positioned to interpret them. They know the portfolio, they recognize when something looks unusual, and they can explain a variance without a research project. Assembly consumes the hours that capability should be spent on.
There is also a quieter benefit. Reports that a person builds by hand tend to stay static, because changing one means understanding the spreadsheet. Reports that run on a schedule are easier to adjust, so questions get asked that previously were not worth the effort. The executive who wanted this cut by branch, and decided not to ask because they knew what it would cost someone, can now just ask.
Have a Problem To Solve?
If your team has a Monday routine everyone has quietly learned to live with, that's usually the clearest sign it's worth a second look. The most effective approach is to start small, one problem at a time, rather than looking for a single platform to fix everything at once. Our community financial institutions page covers how this fits alongside other back-office work. If you'd like to talk through what a first project could look like, schedule a discovery call with one of our operations experts.
Frequently Asked Questions
How do we know which recurring reports are worth automating?
Start with frequency multiplied by time, then check who can produce it. A ninety-minute weekly report is roughly two working weeks a year. A four-hour monthly report is about a week. Then ask whether anyone else could produce it if that person were unavailable. Reports that are both time-consuming and dependent on one person are the first candidates, because they carry an operational risk in addition to a cost.
What if nobody understands how the existing spreadsheet works?
Then documenting it is the project, and automation is the second step. This comes up constantly and it is not a reason to postpone. Someone reconstructing the logic from the inputs and outputs produces something valuable on its own, since the institution currently depends on a calculation nobody can explain.
Isn't this what our business intelligence tool is for?
Often yes, and that is worth checking before building anything. Many institutions own reporting capability they are not fully using, sometimes because the report predates the tool. The reason these efforts stall is rarely that the software does not exist. As the Bird-in-Hand letter put it, the hurdles are implementation and upkeep, which is an argument for keeping the first project small rather than for skipping the check.
Does automating a report create examination or audit risk?
Generally the opposite, provided the logic is documented. A scheduled process applies the same calculation every time and produces a record of when it ran and what it used. A manual process depends on one person following the same steps under varying time pressure. The documentation step matters most here: the calculation needs to be written down and reviewed, not simply copied out of an old spreadsheet.
Who should own this, IT or the business unit?
The business unit owns what the report needs to say, and IT owns access and security. Projects that go poorly usually have IT rebuilding a report without the person who understands why a figure is calculated the way it is. Projects that go well start with that person explaining the current process out loud to someone taking notes.
What if the report changes frequently?
Frequent change is an argument for automating, not against it. A report that is rebuilt by hand every week is expensive to modify, so it tends to freeze. One defined in a scheduled process can be adjusted once and stay adjusted. If requirements shift constantly, that is usually a sign the underlying question has not been settled, which is worth resolving before building anything.