What to Do When a Customer Part Number Will Not Map to Your SAP Material Master

Building a review-and-approve step instead of letting AI guess

A purchase order lands from Vantage Air Systems at 7:40 on a Tuesday morning. Fourteen line items, a delivery date three weeks out, nothing unusual about any of it. Thirteen lines sail straight through into SAP and become a sales order before the coffee is finished.

Line seven does not.

The part number on that line reads VAS-4471-B. It is a completely valid part number. It is just not yours. It belongs to Vantage, it lives in Vantage's engineering system, and it has appeared on every drawing and every requisition inside their building for the last nine years. Somewhere in your material master sits the thing they actually want, carrying the number 100047821 and the description "Housing, Bearing, 45mm, Cast Iron, Machined." Nobody has ever written down that these two numbers describe the same physical object.

So the order stops. And what happens in the next ninety seconds determines whether you ship the right part, the wrong part, or nothing at all.

This is the single most common place where document automation in an SAP order-to-cash process quietly falls apart. Not in reading the PDF. Reading the PDF is close to solved. The part that breaks is the handful of line items where the customer's part number has no clean home in your material master, and the system has to decide what to do about it. Most teams handle that moment badly, in one of two directions. Either they let the matching engine pick its best guess and post it, or they let the whole document collapse into an exception folder that somebody works through by hand at the end of the shift.

Both are expensive. There is a third option, and it is the one worth building.

Why customer part numbers never line up, and never will

It is tempting to treat this as a data hygiene problem that somebody should have fixed years ago. It is not. It is a structural feature of how businesses buy from each other.

Your customer's ERP emits their part numbers because that is what their engineers, their planners and their maintenance crews use. Their bill of materials is written in their numbering scheme. Their stockroom labels are printed in their numbering scheme. When their purchasing system generates a requisition, it has no reason to know or care what you call the item internally.

Ask a large customer to switch to your numbering and you will discover exactly how much leverage you have. For a distributor buying from forty suppliers, adopting forty numbering schemes is not a project, it is a punishment. For an aerospace or automotive buyer whose part numbers are baked into approved drawings and certification records, changing them is not a preference question at all. Those numbers cannot move.

So the translation has to happen on your side. SAP has known this for a very long time, which is why the customer material info record exists. It is a simple, sturdy idea. For a given customer, in a given sales area, customer part number VAS-4471-B means material 100047821. Once that record exists, every future order from Vantage carrying that part number resolves instantly, prices correctly, and posts without a human touching it. 

The whole problem, then, reduces to one question. What do you do the very first time a part number shows up that has no such record?

What actually happens today when the number is not there

Follow the order through and the picture gets uncomfortable.

If the order arrives by EDI, the inbound message hits your system, the translation step looks for VAS-4471-B, finds nothing, and the document fails with a processing error. It sits in a queue. Somebody in IT or on the EDI support desk sees it, works out that it is a business data issue rather than a technical one, and forwards it to customer service. Two days later a rep opens it, squints at the description, asks a colleague, and types in a material number. The customer, meanwhile, has heard nothing.

If the order arrives as a PDF attached to an email, which is still how an enormous share of B2B orders travel, the rep is doing the translation from the start. They read the line, they search the material master by description, they get eleven results, and they pick one. Often they pick correctly, because they have been doing this for eleven years and they remember that Vantage always means the cast iron version. That knowledge lives in their head. It is not written anywhere. When they retire, or take a week off, it leaves the building with them.

Now add an AI extraction layer on top of that process without changing anything else. The document gets read perfectly. Every field comes off the page cleanly. And then the same unanswered question arrives at the same wall, only faster and in higher volume. Speed does not help you here. Speed just means you reach the ambiguous line item sooner.

The instinct at this point is to let the model resolve it. It has the customer part number, it has the customer's description text, it has your entire material master, and it can produce a ranked list of candidates with a similarity score in milliseconds. Take the top one. Post it. Move on.

That instinct is where the real money gets lost.

The three ways a confident guess goes wrong

A matching engine that guesses is not wrong often. That is precisely what makes it dangerous. A process that fails loudly every time gets fixed. A process that is right ninety-four percent of the time produces a slow, steady drip of errors that nobody traces back to the source.

Here is what the failures actually look like.

The near twin. Your material master holds three bearing housings at 45mm. One is cast iron, one is ductile iron, one is cast iron with a food-grade coating for a dairy customer. The descriptions differ by four characters in a sixty-character field. Similarity scoring cannot separate them, because by every measure of text similarity they are nearly identical. A human who knows that Vantage builds air handling units and has never once ordered the food-grade variant separates them instantly. The model picks whichever one sits highest in the index. Ship the coated version and you have given away margin. Ship the uncoated version to the dairy customer and you have a contamination issue.

The part that moved. VAS-4471-B has been a stable part number at Vantage since 2017. On your side, material 100047821 was superseded eighteen months ago by 100051203, which has a revised seal groove. The old material is still in the system, still technically valid, flagged for discontinuation, with four units sitting in a bin in Rack 12. A matching engine that scores on text alone will happily find the old record and score it as a perfect match, because it is a perfect match, to a part you no longer want to sell. The order posts. The four remaining units ship. The customer receives parts that do not match the drawing revision their assembly line is running.

The unit that shifted. This one is the quietest and the most costly. The customer part number refers to a case of ten. Your material is priced and stocked as each. The description matches, the material number is right, and the only thing wrong is a factor of ten sitting in the quantity field. The order posts for 40 pieces instead of 400. Or 400 instead of 40. Nothing in the document looks broken. Nobody catches it until a short shipment arrives at a customer dock or a warehouse picks four cases of something that was supposed to be four pieces. There is no error message anywhere in that chain, because from the system's point of view nothing went wrong.

There is a fourth case worth naming, because it is the one that most clearly shows why guessing is the wrong architecture. Sometimes the customer part number does not correspond to a single material at all. It is a kit number, or an assembly their planner buys as one line, which on your side explodes into three separate materials with three separate prices. No amount of confidence scoring produces a correct answer here, because the correct answer is not on the list of things the model was choosing between. The only correct behavior is to stop and ask.

A system that always produces an answer will always produce an answer to this question too. That is the flaw. Not accuracy. Architecture.

What a review-and-approve step actually looks like

The phrase "human in the loop" gets used so loosely that it has stopped meaning anything. In practice it often describes a screen that shows a rep a ranked list of five material numbers and asks them to click one. That is not review. That is asking a person to rubber-stamp a guess, with none of the information they would need to catch a bad one. Given a list of five near-identical descriptions and a queue of ninety documents, any human being alive clicks the top result.

A review step earns its place when it puts the reviewer in a better position than the model was in. That means showing the things a similarity score cannot see.

Start with what the customer actually wrote. Not a cleaned-up, normalized version of it, but the raw line as it appeared on their document. Part number, their description, quantity, unit, their price if they printed one, and the line number. Reps catch an enormous amount from the customer's own free text. "REPL FOR AHU-7 PER DWG 44102-C" tells a rep that this is a replacement part for a specific unit, which narrows the candidates immediately, and means nothing at all to a text similarity model.

Then show the history. Has this customer ordered from this part number before under a different name? What did you ship them last time? What did the previous three orders from this account look like? In most cases the answer is sitting in your own shipping history, and putting it on screen turns a guess into a recall.

Then show the candidates with their differences highlighted, not their similarities. This is the piece almost everybody gets backwards. If three materials are ninety-seven percent identical, the reviewer does not need to see the ninety-seven percent. They need the three percent, pulled out and displayed in large type. Material A is cast iron, Material B is ductile iron, Material C carries the food-grade coating. Put the distinguishing attributes side by side and the decision takes four seconds instead of forty, and the error rate falls, because the reviewer is looking directly at the thing that matters.

Then show the consequences. What is this line worth? Is this material flagged for discontinuation? Is there a successor part? Is stock available? Does this customer have a contract price on one of these materials and not the others? A contract price sitting on exactly one of three candidates is close to a definitive answer, and no similarity score will ever surface it.

Last, make the decision cheap to record and hard to get wrong. One click to approve. One click to pick a different candidate. One click to say "none of these, send it back to the customer." And a required note field on the third option, because the reason a line could not be mapped is the most valuable piece of data your process will produce all week.

The write-back is the whole point

Here is the part most implementations skip, and skipping it is what turns a review queue into a treadmill.

When the reviewer confirms that VAS-4471-B means material 100047821 for this customer, that decision has to be written back into the customer material info record. Permanently. Automatically. As part of the approval, not as a separate housekeeping task that somebody is supposed to do later.

Do this and the next order from Vantage carrying VAS-4471-B never reaches a human being again. It matches on the first pass, prices correctly, and posts. The review step has converted a recurring cost into a one-time cost, and it has moved knowledge out of a rep's memory and into a system record that survives holidays, resignations and reorganizations.

Skip it and you will review the same part number every month forever. Worse, you will train your team to believe that the review queue is pointless busywork, which it now genuinely is.

The compounding effect here is larger than people expect. Unmapped part numbers cluster heavily. They cluster around new customers, around new product introductions, and around the first few orders after a customer updates their own catalogue. For a stable account, the number of distinct part numbers in play is finite and usually small. A distributor who sends you two hundred order lines a month is probably drawing on sixty or seventy distinct parts. Map those once and the account approaches full automation within a quarter.

The curve is steep at the start and flattens fast. Month one on a new account might send half the lines to review. Month two, fifteen percent. By month four you are down to the genuine exceptions, which are new parts and changed parts, and that is a number that never goes to zero and never needs to.

Who reviews, and how to stop the queue becoming a graveyard

A review step with no owner is a folder where orders go to age.

The people best placed to make these decisions are almost never in IT. They are the customer service reps and order entry specialists who already know the accounts. They know Vantage builds air handlers. They know which distributor always orders in cases. They have the phone number of the buyer and permission to call. Put the queue in front of them, in the system they already work in, and most decisions resolve in under two minutes.

Some decisions do not belong to them, and the design has to admit that. When the question is whether a superseded part should be substituted, or whether a customer's kit number should be exploded into three lines, the right answer sits with product management, engineering, or the account owner. Build a second lane for those, with a named owner and a way to escalate without leaving the screen. What you must not do is force a customer service rep to either guess or stall, because they will do one of the two and neither is good.

Give the queue a clock. Every item in review is attached to a customer order with a promise date, and the review step consumes part of that promise. A line that has been waiting six hours on a next-day order is a different emergency from a line waiting six hours on a six-week lead time item. Sort by urgency against the delivery commitment, not by arrival time, and tell the customer early when a line is genuinely unresolvable. A buyer who hears on Tuesday that one line needs clarification is a buyer with options. A buyer who finds out on Friday has a problem.

And set a hard rule that nothing ages out into an auto-decision. If an item has been sitting for a day, the answer is to escalate it to a person, never to let a timer expire into a guess. Timers that resolve into automatic decisions are the same failure as letting the model decide, wearing a different hat.

Setting thresholds by consequence, not by a single number

Most teams configure one confidence threshold, apply it to everything, and then spend the next six months arguing about where to set it. Too high and the review queue floods. Too low and errors leak through. There is no correct value, because the question is wrong.

The threshold should move with what a mistake costs.

A three-dollar consumable on a standing replenishment order, where the customer orders the same thing every month and a wrong pick gets caught on the next delivery, can run on a permissive threshold. The cost of an error is a credit memo and an apology.

A safety-critical component going onto a certified assembly cannot run on any automatic threshold at all. Not because the model is bad at it, but because the cost of being wrong once outweighs the cost of reviewing every single one. Some categories of material should route to review on every first-time mapping, permanently, by policy.

Between those two poles, the useful variables are line value, material criticality, whether the customer is new, whether the part is new, and whether a successor part exists. A first-time part number from a first-time customer deserves review even at high confidence, because you have no history to check the answer against. The same part number from a nine-year account with forty prior orders is a much safer automatic decision.

The practical version of this is three or four tiers rather than a continuous scale. Tier one auto-posts. Tier two reviews. Tier three reviews with a named senior owner. Tier four goes back to the customer. Write down which materials and which accounts sit in which tier, review that list quarterly, and you will have something far more defensible than a number somebody set once and nobody remembers choosing.

What to measure

Four numbers tell you whether this is working.

First-pass match rate is the share of order lines that resolve without a human. This is the number that should climb steadily as mapping coverage grows, and the one to report upward. Track it per account as well as overall, because the overall figure hides a new account drowning in exceptions.

Review queue volume and age tells you whether the middle lane is functioning or backing up. Volume falling over time is healthy. Volume flat with age climbing means you have an ownership problem, not a matching problem.

Decision time per item measures whether your review screen is any good. If reps average four minutes per line, they are hunting for information the screen should have given them. Watch three reps work the queue and you will find the missing field inside an hour.

Reversal rate is the sharpest quality signal and the one nobody tracks. It is the share of approved mappings that later get changed, because somebody shipped the wrong part or the customer complained. A rising reversal rate means the review step is producing confident wrong answers, which is worse than no review step at all, because it launders a guess into an approval. If this number moves, the fix is almost always in what the screen shows, not in the people clicking.

The first thirty days of a new account

New customer onboarding is where this design pays for itself most visibly, and where the absence of it hurts most.

A new account arrives with a catalogue of part numbers, none of which exist in your mapping tables. Without a designed review step, the first month is chaos. Orders fail, reps improvise, mappings get created inconsistently by whoever happened to handle each order, and the account forms its first impression of your company around a series of small errors.

With a review step, the same month is a mapping exercise with a visible finish line. The first orders route heavily to review, which is expected and fine. Every decision writes back. The queue thins week over week. And by the time the account is a quarter old, it runs at the same automation rate as accounts you have served for a decade.

If the customer will send a catalogue or a cross-reference file up front, even a rough one, load it and review it in bulk before the first order arrives. Reviewing two hundred mappings in one sitting with a good screen takes an afternoon. Reviewing them one at a time, under order pressure, across four reps and six weeks, takes far longer and produces worse results.

The audit trail nobody thinks about until they need it

Every approval should record who decided, what they saw, and when. This sounds like compliance overhead until the first time you need it.

A customer disputes a shipment nine months later and claims they ordered the coated version. The mapping record shows their part number, their original document text, the candidates presented, the person who approved, and the timestamp. That conversation lasts five minutes instead of five days.

An auditor asks how material substitutions are controlled in your order process. You have a documented decision path with named approvers rather than a shrug and a story about how experienced the team is.

And internally, the trail is your training data. Every approval and every correction tells you where the matching engine is weak, which material families keep producing near twins, and which customers send the messiest documents. That feedback is how first-pass match rate goes up. Without it, the matching quality you launch with is roughly the matching quality you keep.

For the team that will build it

The mapping lives in the customer material info record, maintained through the standard customer material info transactions and stored per sold-to party and sales area. Inbound EDI orders carry the customer part number in the item reference segment of the ORDERS message under the customer material qualifier, and a missing mapping is what produces the failed-IDoc status your EDI desk already knows well. The write-back step creates or updates that info record as part of approval. Substitution of superseded parts is a separate mechanism from part number translation and should be evaluated after the mapping resolves, not folded into it, so that "which material does this customer mean" and "which material should ship instead" stay as two distinct questions with two distinct owners.

The review step is an asset, not a cost

The framing that kills this design in budget meetings is that a human review step is a failure of automation. It is the opposite. It is the part of the system that decides what automation is allowed to be confident about.

A matching engine with no review step has exactly one behavior available to it. Answer. It will answer the easy lines and the hard lines with the same posture, and you will never find out which was which until a customer tells you.

A matching engine with a real review step has three behaviors. Answer, ask, and refuse. That third one matters more than it looks. The ability to say "this part number does not correspond to anything I can sell you, please confirm" is not a limitation of the system. It is the thing that makes the other ninety-two percent trustworthy.

Build the queue. Show the evidence, not the score. Write the decision back the moment it is made. Give the queue a clock and an owner. Then watch the volume shrink month over month, which is exactly what should happen, because every unmapped part number is a question you only ever have to answer once.