Reason Code: Other
A PO comes in for cut stock. One line on it. Qty 1, 12 FT. One twelve-foot length.
The item is sold by the foot, so the desk keys a quantity of 12. The shop reads 12, cuts twelve pieces at the default one-foot length, bands them, and ships them. Two days later the customer opens the box, finds twelve one-foot pieces, and calls.
They can’t use them. Cut stock doesn’t go back on the shelf, so the twelve pieces are scrap. The CSR writes an RMA, cuts a credit, enters a no-charge order for one twelve-foot length, and gets to the reason code field.
The dropdown has six choices. Pricing. Damaged. Shortage. Quality. Customer Error. Other.
There is no “we keyed it wrong.” There never is. So the CSR picks Other, or picks Customer Error because the customer is the one who called, and then types in the note field: Cust wanted 1 pc at 12 ft, we entered 12 ea. Cut stock, no restock. Reship 1 x 12′ NC.
Same two numbers on the PO and the order, 12 and 1, in the opposite order. That sentence is the entire story. It says what happened, who did it, and what it cost. And it went into a field no report has ever read.
Multiply by a year.
WHERE THE EVIDENCE GOES
An order entry mistake never gets written down as one. It gets written down as whichever of these it turned into:
A credit memo. Reason code picked from a list built for accounting. Note field holds the real reason.
An RMA. Reason code picked from a different list. Note field holds the real reason. Plus the returned item, the quantity, and a pointer back to the original order line.
A no-charge reship. A $0 sales order with “reship” or “NC” in the notes. No reason code at all. Never touches the credit or return tables.
A freight claim. Filed with the carrier. Lives in email.
The twelve-foot order above touched three of the four. Four tables, four dropdowns, and the one thing they share is a free-text field nobody has ever reported on.
The reason codes were designed so finance could post the credit to the right account. They were never designed to tell you why the order was wrong, and they don’t. The note was.
Here’s why it ended up this way, and I was around for most of it. Before large language models, the only thing a report could count was a coded field. It could sum a dropdown. It could not read a sentence. So ops reporting grew up around codes, and the note field became the place you typed the truth and then forgot about it. The error rate on the monthly report was whatever share of credits got coded to an order entry reason, and most places that’s a code nobody picks. So the rate came out near zero. And the report was the only report, so everyone believed it.
The credit memo tells you money went back. The RMA tells you what came back, and it points at the original order line. Put the returned goods next to the order line next to the customer’s PO and you can tell the difference between “they ordered wrong” and “we keyed it wrong,” which is the whole question. On the twelve-foot order: what came back matches the order line (12 EA). The order line does not match the PO (1 x 12 FT). That’s a keying error, and the RMA proves it without anyone having to admit anything. The credit memo alone can’t. It just says Other.
The credit is the visible cost. The scrap is the second. The freight on the reship is the third. On the twelve-foot order all three landed in different tables under different codes, and not one of them under the name of the thing that actually happened. That is how a desk with a real error rate of a few percent reports one under one.
This Week, Try This: Three Exports, One Read
First, the thing you are already thinking, and the answer is no.
Don’t fix the dropdown. Adding “Order Entry Error” to the list and telling the desk to pick it won’t work. The person choosing the code is the person who made the mistake, or sits next to them. Coded fields record what people were willing to admit at the moment of keying. The note field is more honest because nobody expected it to be read. Leave it alone and read it.
1. Pull the exports
All three go back 180 days, not 90. Credits and returns are far fewer than orders and you need enough of them to see a pattern.
Credit memos. Customer, date, amount, reason code, the note or memo text, and the invoice or order it references.
RMAs. Customer, date, reason code, the note text, returned item and quantity with unit of measure, disposition (restock, scrap, return to vendor), and the original sales order and line it references. Then, from that order line, the item, quantity and unit of measure as entered. If your ERP stores the customer’s PO text or attaches the PO document to the order, include the line as it appeared on the PO. If it doesn’t, the order line is enough for a first pass.
If your RMA export only carries the order number and not the line, add the order number and pull the lines from a separate order export. One extra join. Not a blocker.
No-charge orders, optional but worth it. Sales orders from the same period with a $0 total, or an order type of no-charge or reship. Same columns as a normal order export plus the notes. Most desks won’t think of this one, and it’s the cleanest evidence of an error there is, because nobody cuts a free order for a customer who ordered wrong.
Drop all of it in a working folder.
2. The read, which is the point
Here are three exports from the last 180 days: credit
memos, RMAs, and no-charge orders. Do this.
1. For every record, read the note text and classify
the root cause into one of these:
- Keyed wrong item
- Keyed wrong quantity or unit of measure
- Keyed wrong ship-to or ship date
- Pricing
- Customer ordered wrong or changed their mind
- Damaged in transit
- Warehouse picked or shipped wrong
- Quality or defect
- Cannot tell from the note
Use only what the note says. Do not infer from the
reason code.
2. Build a table: rows are the reason code the desk
picked, columns are the root cause you classified.
Show counts and dollar totals in each cell.
3. Post the table, then list every record where the
picked reason code and your classification disagree,
with the note text beside it.
4. Do not edit, reclass, or delete anything in the
source files. This is a list for a human to read.
The table in step two is the payoff. Down the left side, the six things the desk was allowed to say. Across the top, what actually happened. The cell where “Customer Error” meets “Keyed wrong quantity or unit of measure” is the one to look at first. The twelve-foot order is in it.
3. Let the RMA settle the argument
The note can be wrong too. A CSR under pressure writes “customer ordered wrong” because it’s the easier sentence. So for the RMAs, don’t take the note’s word for it. Check it against the three lines.
Take the RMA export.
1. For each RMA, compare three things: what came back,
what was on the original order line, and what was on
the customer's PO line if it is present. Compare item,
quantity, and unit of measure on each.
2. Apply these rules:
- Returned goods match the order line, but the order
line does not match the PO: we keyed it wrong.
- Returned goods match both the order line and the
PO: the customer ordered it or changed their mind.
- Returned goods do not match the order line: the
warehouse picked or shipped the wrong thing.
- PO line not available: say so and fall back to the
note classification from before.
3. Treat a unit of measure mismatch as a keying error
even when the number matches. 12 EA against 12 FT is
wrong. 12 EA against 1 x 12 FT is wrong.
4. Post every RMA where this check disagrees with the
note, with all three lines shown side by side.
This is the step that turns a reading exercise into evidence. The note said one thing. The three lines say another. When they disagree, the lines win.
Four things come out of this.
Your actual order entry error rate. Records classified as keyed wrong, over total orders in the period. Ask the desk to guess first. Then ask what the monthly report says. Then show them the table.
The reclass. How much of “Other” and “Customer Error” was actually us. In dollars, because that’s the number that survives a meeting.
The unit of measure line on its own. Pull it out of the table and look at it separately. Feet and each. Cases and each. Pairs and each. It is usually the largest single keying category, and it’s the one the dropdown is least able to describe, because the number on the order was right. Only the unit was wrong.
The three buckets under one name. Credits plus scrap plus no-charge reships, all traced to order entry, summed once. Nobody on the desk has ever seen this number because it has never lived in one place.
4. Make it run weekly
Same shape as the last three issues, but weekly, not daily. Credits and returns don’t arrive fast enough to justify a morning check. Schedule the ERP to drop the three exports for the trailing 30 days into the working folder every Friday, and set the read up as a scheduled task in Claude Cowork for Monday morning. Same prompt, smaller file, one extra line: compare this month’s table to last month’s and say what moved.
Every Monday morning, do this.
1. Open the newest credit memo, RMA and no-charge
exports in the working folder. They cover the last
30 days. If nothing is newer than your last run, say
so in one line and stop.
2. Classify every new record by root cause using the
note text, then check each RMA against its order
line and PO line as before.
3. Post the reason-code-versus-root-cause table for the
month, with counts and dollars.
4. Under it, one line per account with two or more
keying errors this month.
5. Compare to last month's table and say in two or
three sentences what moved. If nothing did, say so.
Do not pad it.
The difference between this and the monthly report you already get: the monthly report sums a dropdown. This reads the sentence under it.
An Honest Take
Here is what I actually think. The reason code was built for the accountant, and for twenty years it was the only thing in the record a computer could count, so it became the truth by default. Nobody decided that. It was the only field with a report behind it.
The note underneath was written by the person who actually knew what happened, and it was written honestly for the exact reason it was never read: there was no consequence to telling the truth in a field nobody looked at. That is the most reliable data in your ERP, and it has been sitting in a text column since the day you went live.
So demote the dropdown. It routes the credit to a GL account and that’s all it was ever good for. Report on the note. And expect the order entry line to be a lot bigger than the monthly report ever said, because the report could only count what people were willing to code, and nobody codes “I keyed it wrong.”
One more thing, and this is the only place I’ll say it. Your customers never had this problem. Their supplier scorecard doesn’t have your dropdown on it. Every one of those credits went in their column as your error, and their number has been right the whole time.
And yes, if the keyed-wrong line turns out to be the big one, that’s what we sell, so weigh it accordingly. But the read is worth doing whether you buy anything or not. You can’t fix a number you’ve been reporting as zero.
The Bottom Line
There is a note field in your credit memo table that has been telling you your real order entry error rate for as long as you’ve had an ERP, and no report has ever read it.
The dropdown above it was built for finance. It has six choices and none of them is the truth.
Pull the three exports. Run the read. The cell where “Customer Error” meets “Keyed wrong unit of measure” has a number in it, and somewhere in that cell is a customer who wanted one twelve-foot length.
The PO said 1 x 12 FT. The order said 12 EA.
Both numbers were on the page. A person read them in the wrong order and the credit memo got coded Other. Y Meadows reads the PO line the way it was written, quantity and unit together, checks it against the unit of measure rules for that item and that customer, and stops the mismatch before anyone keys a line.
If you’d like to see what the keyed-wrong column looks like on your own orders, our team will walk you through it.