How many words does your company have for customer?
Most people say one.
SAP has four. Sold-to, ship-to, bill-to, payer - and the distinction is not pedantry. It exists because somewhere in the world a company orders from one address, receives at another, gets invoiced at a third, and is paid for by a fourth, and the standard has to hold all of that.
And those are only the four it insists on. It has room for the broker, the commission partner, the carrier, and anyone else with a role in the deal.
Most of your people will never need those distinctions. Some of them badly do, and have been quietly getting it wrong for years.
Now run it the other way. If you make cleaning and paper products and sell them through distributors, ask a sales lead who their customers are. You will hear about hotels, office buildings and hospitals, the accounts that buy your product from the distributor. Your business has a name for them: secondary customers. The distributor is the sold-to. The secondary customer is on the distributor’s invoice, not yours. Whether that data ever reaches you depends on the market and on what the distributor is willing to share.
So the gap runs in both directions. SAP is more precise than you in places, and you are more precise than SAP in others, and nobody has ever had to reconcile the two because nobody was ever speaking to the system in words.
Two options, and neither is free
When your word and the vendor’s word disagree, you have exactly two moves.
Align. Teach the organization to use the standard term. This is change management, and it is the kind that actually sticks, because the system reinforces it every day — people learn the word by using the thing. It is also slow, it is unpopular in the places where the old word carries identity, and it does not work at all on a term people have been using since before you implemented.
Bridge. Leave the language alone and make the system carry the translation. This is the option everyone reaches for first, because it appears to cost nothing and upsets nobody.
It costs something. Every term you bridge is a mapping you now own - forever, through every upgrade, in every language you operate in, maintained by someone who has to be told when the business quietly changes what the word means. Bridging is not avoiding the decision. It is choosing the option whose cost arrives later and lands on a different team.
And that cost just multiplied. Until now the translation lived in people. Someone knew that when sales said customer they meant the hotel, and built the report that way. An assistant has no such someone.
There is not one assistant. Every prompt, every Joule skill, every agent, every third-party application with its own AI needs the same translation, and each one gets it separately unless somebody decides otherwise.
SAP’s knowledge graph knows SAP’s model. An ontology you buy knows an industry’s best practice. Meanwhile Microsoft 365 is building its own picture of your vocabulary, every day, from every email, document and meeting your people put through it. None of these agree with each other, and you signed off on none of them.
Every term you keep is a term you now have to teach in every one of those places, and keep teaching.
The test
Which term gets which treatment is not a language question. It is a question about whether the word is carrying meaning or carrying history.
A term is carrying history when the only reason it exists is that it exists. An inherited word from an acquisition. A local convention nobody defends. A habit from a system you retired in 2015. Nothing is lost by changing it, and something is gained - an organization that speaks the same language as the system it runs on has fewer places to be wrong.
A term is carrying meaning when it encodes a distinction your business actually makes and the reference model does not. The secondary customer. Two kinds of promotional order that book margin differently and draw on different budgets. A product status that matters for a regulatory reason specific to your industry. A customer classification that drives how your commercial teams are paid. Flatten those to the standard word and you have not simplified anything. You have deleted information your business needs and will continue to need, and the people who relied on it will build a workaround within a month.
Most organizations cannot currently tell these apart, because telling them apart requires someone who can look at a term and know whether it survives translation. That is not a linguist and it is not a configuration analyst. It is someone who knows the business and the system well enough to recognize when a word is load-bearing.
The part worth being honest about
There is something uncomfortable in the align option and it should be said out loud.
Deciding that your people will stop saying one word and start saying the vendor’s is a cultural intervention conducted on behalf of a software taxonomy. Sometimes that is exactly right - standardization is a large part of why you bought a standard system, and every distinction you preserve is a distinction you maintain. Sometimes it is a company surrendering something that mattered because nobody in the room could articulate why it mattered, and the person who could was not invited.
Both of those happen. They look identical in a workshop.
You have made this decision before
Now the part that should feel familiar.
Most Z-fields in your system record a decision that your business needed a distinction the standard did not make. So do the custom tables, the extensions, the places somebody chose not to use what was delivered. You argued about them. Somebody asked whether standard could work. Somebody else explained why it could not. The ones that survived are the distinctions your organization was prepared to pay to keep.
If your secondary customer is in the system at all, it is there because somebody won that argument.
Your custom fields are your untranslated vocabulary, already made structural.
You have a discipline for this. You called it fit-gap. You have just never run it on words.
Which means you are not starting from nothing, and you are not being asked to learn a new practice. You are being asked to point an old one at something it was never aimed at - with the same tests you always used. Can standard do this? What breaks if we conform? What are we really protecting, and is it worth carrying?
What to do with it
Take a dozen terms. Not a glossary project - a dozen, the ones your people actually say in operating reviews.
For each, write down what your organization means, what the delivered system calls the nearest thing, and whether the gap is history or meaning. That is a workshop, not a program, and the arguments it produces are the deliverable. The terms nobody argues about are the ones to align. The terms that produce a fight are the ones carrying something, and the fight is how you find out what.
Then name an owner for the ones you bridge - because a mapping without an owner is a defect with a delay on it.
And notice what you have when you are done: a list of the distinctions your business makes that the reference model does not. Which is not a vocabulary artifact at all. It is the clearest statement of what makes your operation specific that anyone in your company has ever written down.
Nobody asked for it until the system needed to be spoken to.