The Next Satisfying Spreadsheet You Receive May Be the One You Should Trust Least

You have probably already reviewed a file like this one.

A borrowing-base report. Thousands of rows. One row for every car loan in the portfolio. Each row carries a VIN, an outstanding principal balance, a delinquency bucket, a last-payment date, and a status field — current, 30-day, 60-day — that determines whether the loan counts as eligible collateral.

The formatting is consistent. The balances look right. The VINs pass a check-digit test. There are no typos.

Your analyst spends an hour on it. Maybe two. The totals foot. The delinquency mix falls within the eligibility limits in your credit agreement. Nothing looks wrong. The file gets approved. Cash goes out the door.

Now ask yourself: what did the review actually check?

In most organizations, the answer is the visible cells. Column values. Row totals. Delinquency distributions. That kind of review catches arithmetic errors. It catches sloppy data entry. It does not catch a file that was designed to pass it.

Tricolor's alleged fraud, as prosecutors describe it, was a manual operation. Employees entered fake payments one by one. Executives edited status fields row by row. One of the lenders eventually caught it by noticing something simple: loans that were reported as current were not showing declining balances. If borrowers are actually making payments, the principal balance goes down. These balances were not moving. The spreadsheet said one thing. The cash flow said another.

That kind of manipulation — done by human hands, one cell at a time — tends to leave traces. A formula gets overwritten with a typed number. A last-modified timestamp does not match the export date the company claims. A column is slightly misaligned from a copy-paste. An experienced reviewer who digs past the surface can sometimes find the seams.

That is the kind of fraud our review processes were designed for.

Here is what concerns us now: a different kind of fraud is becoming possible, and it does not leave those seams.

We want to be clear about something. These are two separate problems.

What prosecutors describe at Tricolor involved real loans in a real servicing system. The alleged manipulation was applied to real data. AI-generated fraud is a different animal altogether — fabricating whole files that were never connected to a real loan, a real car, or a real borrower in the first place.

But the person sitting across from the spreadsheet faces the same question either way: is there anything real behind these numbers?

A recent joint study by the Association of Certified Fraud Examiners and SAS found that 75% of anti-fraud professionals reported increases in AI-driven document fraud over the prior two years. This is not a forecast. It is already happening.

Most people think of an Excel file as a grid of cells. It is not. Under the hood, an Excel file is a compressed archive — a collection of XML files, calculation records, relationship maps, and metadata that most users never open and most review processes never touch. That internal structure carries evidence of how the file was actually built: whether formulas were overwritten, whether sheets were hidden from view, whether the file's own creation history matches the story you were told about how it was produced.

A person committing fraud by hand rarely thinks to clean those internal records. An AI tool does not create them in the first place. The practical consequence is the same. If your review begins and ends with the visible cells, you are looking at the part of the file that is easiest to fake.

Our practice reviews workbooks for lenders, auditors, attorneys, and finance teams. The first question we ask is never whether the grand total foots. It is whether the file is what it claims to be.

The four questions below are the kind we ask on every engagement. We are sharing them because we believe every organization that relies on critical spreadsheets should be asking them too. In our experience, most are not.

There is a sentence from the Tricolor indictment that stays with us. One lender noticed that loans reported as current did not show declining balances. That is not a sophisticated forensic technique. It is a basic question: does the data behave the way real data should behave?

The Tricolor case showed what happens when no one asks that question — or when the question is asked too late. Delinquent loans made to look current. Collateral pledged more than once. Backup records allegedly fabricated to support the story the spreadsheet was already telling.

That fraud was committed by hand, and it eventually left traces.

AI-generated files may not. The formatting slips, the overwritten formulas, the timestamps that do not match — the things experienced reviewers were trained to look for — may not be there at all. Not because someone cleaned them up, but because they were never created.

Both problems end in the same place. A spreadsheet arrives. It looks right. The question is whether your process can tell you if the numbers in that file are connected to anything real.

The discipline of looking beneath the visible cells is not new. But for anyone who relies on a borrowing-base file, a collateral schedule, or a loan tape to move money, it has never mattered more.