The duplicate PO problem: catching five-figure mistakes automatically
Duplicate POs, double-paid invoices, an extra zero on an order — why manual purchasing leaks five figures, and the anomaly checks that catch it in seconds.
Duplicate POs and their cousins — the double-paid invoice, the extra zero, the wrong-unit order — persist because most purchasing runs on systems with no memory: nothing compares today’s order against last week’s, so the only control is a busy human having a good day. Add a check that runs at creation and again at payment, and the whole category of five-figure fat-finger mistakes gets caught while it’s still free to fix.
The community evidence is painfully specific. An electrician running a job with a 101° fever ordered 48 non-refundable floorboxes — twice, a week apart, on two separate POs for the same project: “it sure felt like the easiest one to NOT make. But I made it anyway.” The same “most expensive mistake” threads catalogue the rest of the family: an extra zero turning $80k of screws into $800k; a unit-of-measure slip buying five years of packaging tape; and, at the top of the range, a single Excel formula pointing at the wrong cell producing a “$7M Excel error” — after which, as the poster put it, “everyone recognized we should not be running that much money through Excel.”
Why these mistakes are structural, not personal
Read enough of the stories and the pattern is never “a careless person.” It’s:
No memory in the loop. The PO system (or the email thread doing its job) has no idea the same items shipped to the same project last Tuesday. Nothing asks the one question a colleague looking over your shoulder would.
Retyping as workflow. Every hop — quote to PO, PO to spreadsheet, invoice to payment — is a keystroke opportunity. The $7M error wasn’t a purchasing decision; it was a cell reference. The €750k production halt in the same thread was a US-vs-EU date format.
The double-pay twin. The duplicate PO’s quieter sibling is the duplicate invoice — same work, resubmitted, new number, paid again because sixty days passed and nobody compares. Vendor-side fee games and honest resubmissions look identical to an AP inbox with no history.
Approval theatre. “Get everything in writing” — the thread’s consensus fix — protects the person, not the money. A signature on a duplicate PO is a well-documented duplicate.
The checks that actually catch it
The controls are unglamorous pattern-matching, valuable only because they run every time:
- At creation: does this PO resemble a recent one — same vendor, overlapping items, same project, close in time? Flag it before it’s sent. The floorbox electrician needed exactly one prompt: “You ordered these on the 12th — proceed?”
- At invoice arrival: does this invoice match a PO (and only one)? Does the amount fit the agreement? Have we seen this number, or this number-with-a-suffix, before? (Tolerance rules for the near-misses are their own craft.)
- At payment: is this payout suspiciously similar to a recent one — same party, same amount, days apart? The last gate, and the cheapest place a duplicate ever gets caught.
- Against the pattern: is this order an outlier for this vendor at all — 10× the usual quantity, a unit price that jumped, a unit of measure that changed? The extra-zero and UOM mistakes die here.
None of this requires an ERP migration. It requires the documents and the payments to flow through something that remembers — and checks.
Where Fynex runs these checks
Fynex sits on the money chain, so the checkpoints come built in. AI invoice analysis reads every incoming invoice against your POs, that vendor’s history and their usual rates — duplicates, near-duplicates, drift and quantity outliers get flagged before the payment run, with the reference they violate attached. On the outbound side, payouts that mirror a recent payment to the same party wait for a human look before money moves — and since anything that moves money waits for your approval anyway, the flag costs seconds, not process.
The electrician’s conclusion was the right one: the mistake felt like the easiest one not to make, and he made it anyway — because on a feverish Tuesday, any human will. The fix was never better humans. It’s a system that remembers the 12th on the 19th, and asks.