That PO Number Is On 14 Orders
A purchase order comes in Tuesday by email. Somebody enters it. Wednesday the same PO comes in again, this time as a portal notification, or a fax, or the buyer forwarding it “just to confirm you got this.” Somebody else enters it.
Both orders pick. Both ship. The first anyone on your side hears about it is a call from the customer’s receiving dock asking why there are two pallets.
You’ve seen that one. It costs freight both directions, a credit memo, a restock, and a phone call nobody enjoys. It’s annoying, and it’s visible, and visible problems get fixed eventually.
Here is the version that doesn’t.
Your third largest account runs on a blanket PO. One number, issued in January, covering every release for the year. Forty, sixty, a hundred orders all carry the same PO number, on purpose, because that’s how their procurement works. So when release 31 arrives twice, three days apart, nothing about it looks wrong. Same PO as the other thirty. Same customer. Same part numbers as last month. The second copy is indistinguishable from the normal flow of the account.
And it ships.
YOUR ERP ALREADY CHECKS FOR THIS
SAP has a standard message for it. Sage 100 has a setting. Dynamics, Epicor, JD Edwards, Oracle, IFS, NetSuite, QuickBooks: every one of them either ships a duplicate customer PO check or has a user forum full of people asking for one.
Almost every one of them is a warning, not a block. Because the vendors know some customers reuse one PO number on purpose.
So on a blanket account, the warning fires constantly. Ninety-nine times it means nothing. The hundredth time, it’s an actual duplicate.
The one control the system gave you fires constantly on exactly the accounts where the duplicate is hardest to see. By the third month nobody reads it. The warning didn’t fail. It got trained out of the people using it.
There’s no industry statistic for how often this happens, and I looked. What there is, instead, is a dozen ERP vendors who each independently decided this problem was common enough to build a guardrail for, and a dozen support forums full of their customers asking how to make the guardrail stricter. That’s not evidence of a rare problem. It’s evidence that the cost lands in three different buckets, freight, credit memos and returns handling, and nobody adds them up under one name.
The freight is the part you can see. The part you can’t is what the double does to the account. Their receiving has to sort it out. Their AP gets two invoices against one release and puts both on hold, so now you’re not getting paid for the order that was right, either. The buyer explains to their own manager why the supplier sent two. You pick up a mark on a scorecard you’ve never been shown.
And the customer’s fix, more often than not, is to move you onto their portal so “this doesn’t happen again.” Which is last week’s issue, arriving through the side door.
This Week, Try This: One Export, Two Sorts
First, the thing you are already thinking, and the answer is no.
Don’t start by turning the warning into a hard block. On a blanket account a hard block stops every legitimate release, and the workaround the desk invents inside a week (a suffix, a dash, a release number tacked onto the PO field) destroys the one field you need for matching. The check isn’t the fix. Knowing your actual duplicate rate is. Nobody has that number, and it takes about an hour to get.
1. Pull the export
Every sales order from the last 90 days. Customer, customer PO number, order date, order number, line items with quantities, ship-to. Nothing exotic. Every ERP in that box above will hand you this in five minutes, and it’s probably a report somebody already runs for a different reason.
Drop it in a working folder. That’s the whole setup.
2. The first sort, which finds the easy ones
Group by customer and PO number. Any PO number that appears on more than one order goes on a list. Then split the list in two by hand, from memory, which takes ten minutes and is the only part of this a person has to do:
Blanket accounts. Customers you know reuse a PO number across releases. Set them aside for step three.
Everyone else. For these, a repeated PO number is a duplicate until somebody proves otherwise. This is your list of orders that shipped twice, or came within a click of it.
Most desks assume this second list will be empty. It rarely is.
Here is a 90-day sales order export. Do this.
1. Group orders by customer and customer PO number.
2. List every customer PO number that appears on more
than one order. For each, show: customer, PO number,
the order numbers, the order dates, and the days
between the first and last order.
3. Separate the list into two groups using the
Blanket Accounts sheet in the working folder:
- Group A: customers on the Blanket Accounts sheet
- Group B: everyone else
4. Post Group B first, sorted by days-between, smallest
first. Orders entered within 5 days of each other
under the same PO number go at the top.
5. Do not delete, merge, or edit any order. This is a
list for a human to check.
If you don’t have a Blanket Accounts sheet, you’ll write one in about four minutes as part of this step. Which is worth noticing. Most desks have never actually listed which customers run on blankets. It lives in two people’s heads, which is the Denise problem from August in a different coat.
3. The second sort, which is the actual payoff
Now the blanket accounts. The PO number is expected to repeat here, so it tells you nothing. You match on what the number was hiding.
Same customer, same PO number, same line items and quantities, entered within a few days of each other. Release 31 and release 32 will differ somewhere. Different parts, different quantities, a different ship-to. Release 31 entered twice will not.
Take Group A from the previous step.
1. Within each customer and PO number, compare orders
pairwise on line items and quantities.
2. Flag any pair where the line items and quantities
match exactly, or match on every line but one, and
the order dates are within 7 days of each other.
3. For each flagged pair show: customer, PO number,
both order numbers, both order dates, the ship-to on
each, and whether each has shipped.
4. Post the flagged pairs as a list. If there are none,
say so in one line. Do not pad it.
Three things come out of this, and the third one is the one to keep.
Your actual duplicate rate. Flagged pairs over total orders in the period. Ask the desk to guess before you run it. The guess is low.
Which door the second copy came in. Look at the flagged pairs and check where each order originated. Email, then portal. Email, then fax. Email, then the buyer forwarding the same PDF with “confirming” in the subject. The pattern tells you where duplicates actually come from, and that’s a better fix than any warning box, because it’s upstream of the keying.
A written list of your blanket accounts. You made it in step two without meaning to. Keep it. It’s the first time it has existed outside somebody’s memory.
4. Make it run every morning
Everything above is an audit. It tells you what already shipped twice. Useful, once. The version that saves you money is the one that finds the second copy while it’s still in the pick queue.
Same logic, smaller input, one extra condition. Most ERPs will schedule a saved report to drop a file on a share or email it to an address, so have it export orders entered in the last 10 days, same columns as before plus a shipped flag, into the working folder every night. Then set the check up as a scheduled task in Claude Cowork to run on weekdays before the desk gets in.
Ten days is the right window. The second copy almost always lands within a few days of the first, because it’s the same buyer forwarding the same PDF or the portal notification catching up to the email. Anything older is either a real release or a duplicate that already shipped, and the audit covers those.
Every weekday morning, do this.
1. Open the newest orders export in the working folder.
It holds orders entered in the last 10 days. If there
is nothing newer than your last run, say so in one
line and stop.
2. Take every order entered since your last run and
compare it against all other orders in the file with
the same customer and customer PO number.
3. For customers on the Blanket Accounts sheet, a match
also requires the same line items and quantities, or
the same on every line but one. For everyone else,
the PO number alone is a match.
4. Keep only pairs where at least one order has not
shipped.
5. Post the pairs: customer, PO number, both order
numbers, both entry dates, which one has shipped, and
the line items that matched. Put the pair with the
earliest ship date at the top.
6. If there are no pairs, write one line saying so. Do
not pad it. Do not cancel, hold, or edit any order.
The difference between this and the warning box is where it lands. The warning fires mid-entry, on the screen of the person typing, at the exact moment clicking OK is the fastest way forward. This lands on a list, before pick, in front of someone whose job that morning is to read it.
An Honest Take
Once the list exists, the instinct is to tighten the control. Make the warning a block. Add a second approval on blanket accounts. Don’t. Every one of those adds friction to a hundred legitimate orders to catch one duplicate, and the desk will route around it inside a month, because the desk’s job is to get orders in. You already ran that experiment. The warning box was it.
Here is what I actually think. Duplicate orders are not a data entry problem. They’re a channel problem. The same PO arrives twice because it came in two doors, and the doors don’t know about each other. As long as one person’s memory is the only thing connecting the inbox, the portal and the fax machine, a check at the point of keying is a check on the symptom.
The fix is upstream. Every order, from every channel, lands in one place before anyone keys anything, and that place is what recognizes the repeat. And yes, that’s what we sell, so weigh it accordingly. But you cannot dedupe what you never saw arrive in one place, whoever you buy it from.
The Bottom Line
There is a list of orders in your ERP right now that shipped twice, or came within one click of it, and the system flagged every one of them on the way in.
The blanket accounts are where they hide best, because the warning fires there every day and has meant nothing for a long time.
Run the audit once to learn your rate. Then put the morning check in place. Somewhere in the orders entered this week there is a release that came in twice, and as of this morning both copies are still unshipped.