The Spreadsheet at the Center of Your Treasury Is a Liability, Not an Asset.

Every bank has one. Sometimes it's the loan tracker that's been open on the same laptop since the early 2000s — loans added manually, archived by hand, no real-time visibility into anything. Sometimes it's the covenant testing file, a macro-driven workbook that an underwriter built to survive a system that couldn't do the math. Sometimes it's the reconciliation sheet that someone updates every night before they leave.

These spreadsheets didn't appear overnight. They were built by smart people solving real problems with the tools available at the time. The loan tracker at one bank we spoke with was built by the same ops leader who's now responsible for the entire loan servicing function. For years, it worked fine.

The question isn't whether the spreadsheet worked then. It's what it's costing now.

What "Manual" Actually Means at Scale

When banks describe their treasury and lending operations as "manual," the word tends to undersell the reality.

At one community bank we spoke with, covenant tracking lives in a macro-driven spreadsheet paired with a tickler system that flags when a test is due — but does none of the actual math. Every test produces a manual memo, and every memo has Excel charts embedded to build out the credit file record. A lender on that team put it plainly: the testing itself isn't the hard part. It's the collection loop — chasing down tax returns from borrowers, waiting on brokerage statements, re-entering data from financial documents into the core and then again into a Word document — manual actions that eat up valuable time.

Global debt service coverage testing makes it worse. A single borrower with ownership stakes in four or five entities requires pulling tax returns for each one, running individual add-backs and debt analyses, then combining them into a picture of consolidated cash flow. All of it done by hand. All of it living in a file that one person built, one person understands, and one person has to maintain.

At another institution, the wire transfer process works like this: a commercial client submits a wire through online banking. Someone on staff manually pulls it, re-enters it into the correspondent system, then re-enters it again into the wire system. A spreadsheet is used to track which wires were entered where. A callback verification follows for fraud prevention.Callback outcome is marked in the spreadsheet. Every wire, every time.

These aren't edge cases or outliers. They're the standard operating model at a significant number of community and regional banks — built up over years of reasonable workarounds and staff who knew how to make things work despite the tools, not because of them.

The spreadsheet problem gets framed as an efficiency issue, but it's also a risk issue.

When the logic for a critical process — covenant testing, floor plan tracking, reconciliation, draw management — lives in a file that one person built, the institution has a single point of failure it may not fully recognize. When that person leaves, or gets promoted, or retires, the institutional knowledge walks out with them. The spreadsheet stays. The understanding of why it's built the way it is, what the edge cases mean, which formula breaks under which conditions — there is a risk of it being gone.

Audit exposure compounds this. A reconciliation process that happens at end of day, in a spreadsheet, by hand, is not the same as a process with a permanent transaction log, real-time exception flagging, and a trail that a regulator can follow. The outcome might look the same on a quiet month. On a month where something goes wrong — a wire hits twice, a return gets missed, a disbursement doesn't match the ledger — the difference between a documented automated process and a manual one becomes significant very quickly.

One bank we spoke with cited regulatory pressure on disbursement controls as a concern. Their construction draw process — assembling draw packages, coordinating inspections, collecting lien waivers, wiring funds — is entirely manual, with no system tracking state-specific lien exposure windows across their operating states. The process works until it doesn't. And when it doesn't, the exposure is a major risk.

The Spreadsheet That Actually Needs Solving

Let's be honest for a second. Spreadsheets built the modern financial system. Before there was software, there was Excel. Before Excel, there were literal spreadsheets — paper, pencil, a very patient accountant. Some of the most sophisticated financial modeling in the world still happens in a workbook someone emailed around. There's nothing inherently wrong with a spreadsheet.

And not everything needs to be automated. If a process runs ten times a year, takes twenty minutes, and the risk of it going wrong is low — leave it alone. Automating something that doesn't de-risk the institution or cut the manual work by an order of magnitude isn't solving a problem. It's creating a new one, with an implementation timeline and a vendor relationship attached.

But.

We all know the spreadsheet that has crossed a line. The one that's been open so long it has its own folder in someone's personal drive. The one with tabs that reference other tabs that reference a third tab nobody touches because something broke in 2019 and everyone just works around it. 

That's the one worth solving.

What Replacing the Spreadsheet Actually Means

The banks that have moved past the spreadsheet problem haven't done it by buying expensive platforms that require eighteen-month implementations and a ripped-out core. The ones that moved fastest did it by identifying the most acute single-point-of-failure and replacing it with something that can run without tribal knowledge.

In practice, that means transactions matching automatically against ledger entries in real time, with exceptions flagged immediately rather than discovered at month-end. It means covenant tests running against structured data rather than manually re-entered figures, with alerts going out before a deadline is missed rather than after. It means draw packages moving through a documented workflow rather than email threads, with lien exposure tracked by state rather than by memory.

None of that requires replacing the core. It requires acknowledging that the spreadsheet at the center of the process isn't a tool anymore — it's a risk.

‍