How I Replaced My Purchase Order Spreadsheet With an Evidence-Based System

For one of my ecommerce brands, I’m running 20 to 30 SKUs and anywhere from 5 to 15 purchase orders in flight at any given time: placed, shipped but not received, or just sitting there with payment terms still coming due. Until about six months ago, every bit of that lived in one spreadsheet.

Why a spreadsheet stops working

A spreadsheet is fine for a short list that one person checks. It falls apart once you’re past the point it fits in your head: a vendor who hasn’t acknowledged a $60K order, cargo that’s ready with no inspection booked, a ready date that passed weeks ago with no ship date recorded. Every one of those is a real thing that needs my attention, and a spreadsheet can’t surface any of them on its own. It just holds what the last person typed.

So I rebuilt it as a real relational database: purchase orders, line items, payment milestones, and the vendor documents that come back against each one. One PO with three line items doesn’t live in three spreadsheet rows guessing at each other, it lives in tables that actually relate to each other.

The principle: evidence moves state, not people

The system is built on one rule. A purchase order’s status doesn’t change because I open it and change a dropdown. It changes because evidence showed up: a sales order confirming what the vendor is actually sending, an invoice, an inspection report, a payment going out the door.

In practice, that means I hand a document to an AI agent and it files it. It isn’t making judgment calls. It’s doing the data entry I used to do by hand, reading what a document says and recording it against the right purchase order. Nobody on my team is updating a spreadsheet to produce a status. The system is reading what actually happened and telling me.

Anytime a person is typing a status in by hand, you get drift: the system stops matching reality the moment that person gets busy or forgets. A system that only moves on evidence doesn’t have that problem.

A real example: the sales order that didn’t match

Here’s where it actually paid off. I put in a purchase order for five SKUs with one vendor, all in one order. Their process: once I submit a PO, they send back a sales order confirming exactly what was ordered.

One came back with the quantities swapped on two of the SKUs. SKU A was supposed to be 600 units and SKU B 240. Their sales order had it the other way around, 240 and 600.

That would have been completely wrong, and not what I asked for. But because the system holds both documents against the same PO, checking one against the other was a five-second comparison instead of something I’d have had to remember to do, or catch by accident. Caught before it ever shipped.

What falls out of this for free

None of this was the point when I built it. But storing purchase orders this way, instead of in a spreadsheet, throws off a few things that a spreadsheet just can’t give you:

1. Observed lead time, not the vendor’s word. A vendor can tell me five weeks. My own data might say 6.5, every time. I plan around what’s actually observed, not what I was told.
2. True landed cost, not just the line items. Freight and duty tie back to the actual PO instead of showing up on a bill later that I have to go track down and reconcile by hand.
3. Real accounts-payable timing. Every PO carries its own payment milestones, what’s owed and when, which is the foundation for an actual cash flow projection instead of a guess.
4. Point-in-time reconstruction. I can pick any day in the last six months and know exactly what was on order, what we had on hand, and what was still coming. Bookkeeping that would otherwise take real digging becomes close to trivial.

A spreadsheet can hold a list. It can’t hold a history you can reconstruct, or a cross-check that catches a vendor’s mistake on its own. That’s the difference between tracking data and storing evidence.