Recovery Files: The $1.2 Million Hiding in a Falling Steel Price

Every recovery has a story. Some are quick: a duplicate payment, a missed credit, done. Others take real detective work. This is one of the good ones: a $1.2 million recovery that had been building, invisibly, for years. To keep everyone anonymous, we’ll call the supplier ABC Corporation and leave our client unnamed.

The setup

Our client bought steel. A lot of it. ABC Corporation was one of their largest suppliers, so the volume of transactions between them was enormous, and steel, like most metals, is priced off an index that moves every month. Each month a new purchase order was created for that month’s buying, at that month’s price.

Three details about how they worked together turned out to matter more than anyone realized:

• Two-way match with auto-generated invoices. When goods arrived, our client received them into their system, and the system automatically generated an invoice from the quantity received, cross-referenced to the PO, and paid it. There was never a supplier invoice number in the process.
• Monthly blanket POs with no quantity controls. Each month’s PO was essentially an open bucket for that month: no line-level quantity limits.
• “Apply the receipt to the oldest PO.” The receiving department had a standing instruction: when goods came in, apply the goods receipt to the oldest open purchase order.

Hold onto that third one.

The first red flag

It started, as these often do, with a statement we couldn’t get. ABC first sent us only a single outstanding balance for our client. We pushed back and asked for a full statement. What came back was an apology and an explanation: their system had trouble producing one, because our client’s two-way match meant there were no supplier invoice numbers to tie anything to. On ABC’s side, they’d simply been applying our client’s cash to open invoices without matching it to specific ones. Their AR ledger for this account was enormous: invoices, payments, adjustments, and returns all piled up as separate line items. A mess.

When we finally got the detail and started matching ABC’s invoices to our client’s payments, the numbers didn’t line up. Not by a little, but by a lot. Something was clearly wrong.

The investigation

We went PO by PO, month by month, comparing what the PO said the price should be against what was actually paid. They were two different numbers, over and over, and at first we couldn’t explain why. The pricing was right there on the index. The receipts were right there in the system. So where was the drift coming from?

Then it clicked, and it came back to that standing instruction.

The “aha”

Remember: goods received were applied to the oldest open PO, and those POs were monthly blanket buckets priced off a metal index that changed every month. Now picture what happens when the price of steel is falling month after month, which it had been for the better part of a year.

Goods physically received this month got applied to an older PO, one created when the index, and therefore the price, was higher. So the system paid this month’s steel at last month’s higher price. Month after month, as the index kept dropping, our client kept paying yesterday’s price for today’s metal. Sometimes the timing worked the other way and they underpaid. But with a falling market, the overpayments dominated.

No single transaction looked wrong. Each receipt matched a real PO; each PO had a real, index-based price. You could only see the problem by stepping back and watching the whole pattern move over time. And because neither our client nor ABC was reconciling at that level, it had been quietly running for years. Neither side had any idea.

The recovery

We netted it all out, the overpayments against the underpayments across years of activity, and the balance owed to our client came to $1.2 million.

Then we did what we always do after a find like this: we went looking for other suppliers that worked the same way. We found a few. This one was the bulk of it, but it was not the only one.

So what did our client do?

Finding the money was only half the win. Once we showed them how it happened, they closed the hole for good:

• Monthly POs are now closed at month-end. With each month’s PO closed on schedule, the receiving department can no longer apply a new goods receipt to an old, higher-priced PO. Receipts have to go against the current month’s PO, at the current month’s price.
• Receiving was trained on what to watch for. The well-intentioned “apply it to the oldest PO” habit at the center of all this was replaced with a process that reflects how the pricing actually works.

That’s the part I like best. The $1.2 million was real money. But closing the process gap means it won’t quietly rebuild over the next few years. Recovery turned into prevention.

Why it stayed hidden and what actually found it

Here’s the part I want AP and finance leaders to take away. Nothing in this scenario would trip a standard control. There were no duplicate invoice numbers, because there were no supplier invoice numbers at all. Every payment matched a valid PO. A generic duplicate-payment scan, or an AI told to “go find errors,” would sail right past it, because on a transaction-by-transaction basis nothing was an error. The money leaked in the space between three ordinary process decisions: auto-generated invoices, blanket POs without quantity controls, and “apply it to the oldest PO.”

Finding it took understanding how all three interacted, and knowing from experience where that combination tends to go wrong. That’s not a report you run. It’s a thing you learn from doing this for 25 years.

Think a supplier relationship in your books might be drifting like this one? Start a no-cost Proof of Value. We only get paid a percentage of what we recover.