Superseded Part Numbers and Why Someone Still Checks Every Order

Plenty of parts businesses have already solved order entry. There is a customer portal. Customers look up the part, type the number, and submit the order themselves. It lands in the ERP without anyone on the inside touching a keyboard, and on a good week that covers three quarters or more of the volume.

A person still checks every order before the pick ticket goes to the warehouse.

Not the tricky ones. Not the ones from new accounts. Every order, including the ones that arrived clean through the portal. Ask a parts manager to describe the ideal and you will hear some version of the same sentence: click one button, the order is correct, it goes to the warehouse. Ask whether that is what happens today and the answer is no.

If you run a parts operation you already knew that. What is worth pulling apart is why, because the reason is not the one most people assume, and it decides whether the next piece of software you buy helps or just sits on top of the problem.

Eighty percent are fine. Nobody knows which eighty.

Ask how many orders are fine as submitted and you tend to get the same rough answer: about eighty percent. The rest are where the bottleneck lives.

That sounds like a small problem until you turn it around. Eighty percent turn out fine once somebody has read them. There is no way to know which eighty percent in advance, so the cost is not in fixing the bad ones. The cost is in reading all of them.

This is the most misread number in parts operations. An eighty-twenty split gets heard as "eighty percent flow through untouched," which would mean the manual work only touches a fifth of the day's orders. It does not. It touches all of them. The twenty are what the checking is for. The hundred are what it costs.

Any tool aimed only at making the bad twenty faster to fix is aimed at the wrong number.

What order validation actually catches

Ask what happens at print time and you get a list that has nothing to do with typing errors. It is usually long enough that nobody has ever counted it, and when a business does sit down and flowchart it, the result is a web rather than a checklist.

The recurring ones across parts distribution:

• Flagged parts. Some parts carry a marker meaning stop and read the notes before this ships. It is a small slice of the catalog and it is never the same slice twice.
• Items that get built rather than picked. Hose assemblies are the classic. If it is not on the shelf, the order needs a work order raised for the team that makes it, which is a different process on a different clock.
• Core and exchange items that carry a return obligation the order itself does not mention.
• Territory and channel agreements. Some accounts are only allowed to ship into certain territories, and the order has to be checked against the agreement rather than against inventory.
• An urgent flag against slow shipping. The customer marks the order an emergency and then selects ground. Somebody has to call and find out which one they meant.
• Package and quantity rules, where the catalog quantity and the way the part is actually sold do not line up.

Look at that list and notice what is not on it. Not one of those is a data entry error. The order was captured correctly. Every one of them is a rule about this particular order that the order does not carry and the system has no way to see.

Parts managers tend to name this as one of the biggest hold-ups in the department, and say it is worst when somebody new is being trained. That is the tell. If the checks were written down anywhere a system could read them, training would be the easy part.

Why a superseded part number gets through

Here is the piece that reframes the whole problem.

Most parts ERPs have a supersession field. When it is filled in, it propagates out to the customer portal, so a customer typing in a number from a manual printed fifteen years ago is told at order entry that the part has been replaced. That mechanism works. It is already built, already integrated, already in front of the customer.

The problem is that a lot of supersession knowledge is not in that field. It sits in free-text notes attached to the part, written by different people over many years, and no portal reads free text.

So this is not a missing system. It is an unpopulated field sitting next to the knowledge that belongs in it, in a format nothing can use.

That distinction decides what the project is. If it were a missing system, the answer would be to buy or build one, and you would be looking at a data model, an integration and a vendor. It is not a missing system. The answer is extraction and population: read the free text, work out what it actually says, and load it into the field that already works.

This is also why ordinary validation does not catch it. If a customer orders a part number that was correct two years ago, and both the old and the new number exist in your item master, the order passes every check the ERP knows how to make. Both parts are real. Nothing is malformed. The only thing that knows the order is wrong is the person who has seen that mistake before, and they know it in about four seconds without looking anything up.

Order entry automation solves the wrong problem

The instinct at this point is to go looking for software that automates order entry. This is where these projects go wrong, and they go wrong in a specific way.

A system that reads the incoming order and extracts it perfectly has automated the part that was already working. The portal did that. What you have bought is a faster route to the same manual review.

Worse, a validation tool that checks part numbers against your catalog without knowing what is in the free-text notes will confirm that a superseded number is valid, because as far as the catalog is concerned it is. Your experienced parts person would have caught it. The tool clears it at speed and with confidence, and now the mistake ships.

An automation system can only act on rules and data it can actually see. Point one at an operation whose real rules live in free text and in people's heads and you do not get your expert's judgment at scale. You get the average of everything your team has ever done under pressure, applied consistently, including the wrong calls.

A note on the numbers you will be shown while evaluating this. There is a lot of published research on what a manual order costs, and almost all of it is published by companies selling order automation software. The figures range from eight dollars an order to over a hundred depending on whose page you are reading, which tells you they are not measuring the same thing. Ask any vendor quoting one where the number came from, what it counted, and whether an operation like yours was in the sample. Your own two numbers, taken from your own week, are worth more than all of it.

What to automate instead: invert the check

The better answer is usually described by the people doing the work, before anyone proposes it. Map out the exceptions and have the system say wait, this one needs checking, instead of a person walking the whole process on every order.

That is the inversion. Today a person reads a hundred orders to find twenty. The goal is a system that reads a hundred orders and hands a person the twenty, with the reason attached.

Three things have to be true for that to work, and only one of them is software.

The exceptions have to be enumerated. Not described in a meeting, enumerated. "Check the shipping if it looks odd" is not a rule a system can apply. "Flag any order marked urgent where the selected shipping method is ground" is.

The knowledge in free text has to become data. This is the unglamorous half and usually the larger one. It is reading notes written by a dozen people over fifteen years, deciding what each one actually means, and getting it into a field. Document AI is genuinely good at this part, and it is the one place in the project where the technology is the answer rather than the wrapper around it.

A person stays in the loop and stays in charge. The system's job is to clear the routine orders and route the flagged ones with an explanation attached. It is not to approve orders. When it is wrong, that is a rule to fix, and the person who catches it is the same person who used to catch everything.

We built this pattern into a document system for a construction contractor, in a completely different domain: the deterministic items are generated automatically and the judgment items are flagged for a person, who reviews every one before it is used. The work that made it possible was not the AI. It was writing down the rules that had never been written down.

The hard part nobody warns you about

Enumerating the exceptions is harder than it sounds, and not for the reason you would expect.

Your expert will describe the rules as simpler and more consistent than they are. That is not carelessness, it is the opposite. The exceptions are the things they have stopped noticing, because handling them became automatic years ago. Ask for the rule and you get a clean summary. The real thing has four edge cases attached that only surface when you test the summary against actual orders.

The practical answer is not to interview harder. It is to take whatever your expert tells you and check it against their own data before building anything. Pull a few hundred real orders from the last quarter, apply the stated rule, and compare it against what actually happened. Every disagreement is either a gap in the rule or an inconsistency in past practice, and you want both before either one is in production.

Expect to do this more than once. The second pass is usually where the useful rules come from.

One constraint to check before you plan anything

If any part of your plan involves writing back into the ERP, find out what your vendor's API actually costs and how long it takes to switch on. Ask in writing, and ask for a date.

I have seen an ERP vendor quote well over a year just to enable API access for a customer already paying for the system. At that lead time, anything that has to write into the ERP live is off the table for a first phase, whatever the budget is.

That is not a reason to stop. It is a reason to design the first phase to read exports and documents and write nothing back. A system that reads a daily export, applies your rules and hands a person a flagged list with reasons attached delivers most of the value and depends on nobody else's release schedule. You connect it properly later, when the API turns up.

Most projects find this out after the design is finished. It is a ten-minute question at the start.

If you are standing up a parts operation from scratch

Some companies reading this are building a parts division rather than fixing one, with a small catalog and no software chosen yet. Different problem, and a much better position to be in.

The thing to get right early is not the software. It is the discipline that every rule which decides whether an order is correct gets recorded as data at the moment it is created, rather than as a note or a habit. Supersessions go in the supersession field. Territory rules go somewhere a system can read them. Whatever "this customer is different" means gets a field rather than a memory.

That costs almost nothing at a thousand parts. It is a project at fifty thousand, and by then the people who know the rules have been applying them from memory for years.

Where to start

You do not need a vendor to find out whether this applies to you. You need one afternoon and two numbers.

Count how many orders came in last week, and how many of them a person read before they shipped. If those two numbers are close to each other, your order entry is solved and your order validation is not, and that is the thing worth fixing.

Then ask the person doing the checking what they are looking for, and write down every answer. When they say "it depends," that is not a non-answer. It is the most valuable sentence in the conversation, and the next question is what it depends on.

If what you end up with looks like a web rather than a checklist, that is normal, and it is the real starting point. Let's talk about what it takes to get it out of people's heads and into a system that only asks them about the twenty percent.