In the basement of the museum where I work, there is a legendary filing cabinet known as the “Ledger of Lies.” Officially, every 19th-century textile and every fragment of Roman pottery is cataloged in a million-dollar SQL database that requires three layers of authentication and a specific VPN to access.

It is a masterpiece of information architecture. But if you actually want to know where the 1840s Jacquard loom is-specifically, which conservation bench it is currently sitting on and who accidentally spilled coffee near it-you do not log into the database. You look at the yellowing index card taped to the side of that filing cabinet.

This is a law of human systems: the more rigid the official tool, the more the actual work migrates to the shadows.

The Migration to Shadow IT

I see this same phenomenon play out in the world of equipment finance, though the stakes involve millions in depreciating assets rather than moth-eaten tapestries. Every lender of a certain size has a “real” system. They have spent years and seven-figure sums implementing a core platform that promises a single version of the truth.

Yet, if you sit with a portfolio manager or a collections head long enough, they will eventually minimize the browser window containing the “official” portal to reveal a workbook named PORTFOLIO_MASTER_v11_USE_THIS_ONE.xlsx.

It was last modified yesterday at 4:52 p.m. It has 26 tabs. One of them is named “DO NOT DELETE” in all caps, and it contains the residual assumptions for 340 units that the core system apparently cannot be trusted to handle. This spreadsheet was built by a senior analyst who left the company in 2022, and yet it remains the most important piece of technology in the building. It is where the actual decisions get made.

Digital Kudzu or Human Survival?

There is a tendency among technology leaders to view these spreadsheets as a symptom of immaturity, a kind of digital kudzu that needs to be cleared away. They are seen as “shadow IT,” a security risk, or a lack of discipline. But this perspective misses the point entirely.

Spreadsheets do not win because users are lazy or disorganized. They win for a reason that has nothing to do with immaturity: they are the only tool in the building that a person who understands the problem can change on the day they understand it.

I recently won an argument about the origin of a specific silk weave. I was entirely wrong, technically speaking-the weave was Flemish, not French-but I won because I was the only one in the room who had the physical catalog from the 1994 exhibition. I had the “tool” that gave me the answer in seconds, while everyone else was waiting for the official archives to be fetched.

Winning while being wrong is a strange, hollow feeling, but it taught me something about speed. In an environment where things are moving, the person with the fastest tool becomes the authority, regardless of whether that tool is “official.”

The Speed of Thought vs. The Speed of Tickets

In equipment finance, a lender might realize at 10:00 a.m. on a Tuesday that they need to offer a specific type of mid-life contract modification to a client who is struggling with seasonal cash flow. They look at the enterprise platform.

To add that specific logic-to adjust the billing schedule, the tax treatment, and the residual buyout trigger-requires a “change request.” That request goes to a steering committee. It is prioritized for the Q3 release. It requires a vendor ticket.

The user cannot wait for Q3. They have a customer on the phone right now. So, they open the grid. They write a formula. They create a new tab. By 10:15 a.m., they have an answer. The spreadsheet has won.

Clay vs. Stone: The Flexibility Deficit

To understand why this is such a persistent problem, you have to look at how a payoff quote actually gets generated in the wild. In a perfect world, a customer calls and asks what it would cost to buy out their lease three months early. The system should just spit out a number. But in reality, the process is a messy digression of “what ifs.”

The “how it actually works” process looks something like this: The operator pulls the base contract data from the core system. Then, they check the “suspense” account to see if there are any unallocated payments that haven’t been applied yet-perhaps a check that arrived yesterday with a confusing reference number.

“No legacy system is designed to handle that specific sequence of human nuances in real-time. The operator handles it by pulling the raw data into Excel, where they can manipulate the cells like clay.”

They look at the local tax rules for the state where the equipment is currently located, which might have changed since the lease started. Finally, they apply a “goodwill” discount on the late fees because the customer has been loyal for five years. The enterprise platform is a stone monument; the spreadsheet is a pile of LEGOs.

Honoring the Grid

The tragedy of the enterprise platform is that it loses a competition against a grid of cells because it treats “configuration” as a professional service rather than a core user capability. When every adjustment requires a consultant or a developer, the software is effectively dead to the user. It becomes a place where data is stored, but not where work is done.

This is why I find the modern shift toward API-first, self-service architecture so compelling. It isn’t about “eliminating” the spreadsheet; it’s about building a system that honors why the spreadsheet exists in the first place.

If a lender’s own team can configure a new delinquency workflow or a custom payment schedule without waiting on a vendor release schedule, the need for the shadow workbook begins to evaporate.

A Map of Failure

I think back to my “Ledger of Lies” in the museum basement. We eventually replaced it, but we didn’t do it by banning index cards. We did it by giving the curators a mobile tablet that let them update the database instantly, from the conservation floor, with the same ease as writing on a card. We had to make the official system as responsive as the shadow system.

When you look at the “DO NOT DELETE” tabs in your own organization, don’t look at them as failures of IT policy. Look at them as a map of where your official system has failed your people. Those spreadsheets are the exact coordinates of the functionality your users actually need. They are telling you, in no uncertain terms, that the speed of their thinking has outpaced the speed of your software.

The serious question for any COO or CIO is never “How do we delete these files?” It is “Why did our expensive system lose a competition against a grid of cells?” The answer is almost always a lack of control.

Pivot in Hours, Not Months

When a lender is forced to wait for a vendor’s roadmap to implement a change in their own business logic, they are effectively being told that their expertise is secondary to the software’s architecture.

In a world where interest rates shift, supply chains break, and equipment values fluctuate, a lender needs to be able to pivot in hours, not months. If your servicing platform cannot handle an in-life amendment or a complex payoff calculation without a ticket, you aren’t running an enterprise; you’re running a very expensive filing cabinet.

I’ve learned that being right is often less important than being useful. I might have been wrong about that loom, but having the information at my fingertips allowed the work to continue. A spreadsheet might be “wrong” from a data governance perspective-it might be fragile, disconnected, and prone to human error-but it is useful in a way that a frozen enterprise system is not.

From Monuments to Tools

The goal of the next generation of financial technology isn’t to create a “perfect” system that accounts for every possible future scenario. That’s impossible. The goal is to create a system that is flexible enough to let the user navigate the scenarios as they happen.

It’s about moving the “DO NOT DELETE” tab into the core logic of the business, where it can be audited, secured, and scaled, without losing the human speed that made it necessary in the first place.

A monument is something you look at; a tool is something you use to change your environment. When the servicing platform finally catches up to the spreadsheet, it won’t be because the spreadsheet was “defeated.” It will be because the software finally learned to move at the speed of a human being with a problem to solve.