Master Data Decides Whether Order Automation Pays Off

The sentence "our master data is clean" comes up in almost every preliminary meeting. It is rarely meant dishonestly and it is almost never true in the sense an automation needs. What people usually mean is completeness: every article has a number, a description, a price. What is actually needed is something else, namely agreement between two systems that hold the same article and do not mean the same thing by it.

In wholesale, that distinction decides the fate of an automation project more often than any technical question. It can be checked before you commission anything, and it is the point where you have the greatest influence on the price.

Where two systems read the same number differently

Suppose a wholesaler holds an article in the order portal by pack, because customers order cartons rather than single pieces. In the inventory system the same article is held in pieces, because stock is counted in pieces and picking also takes single packs out of a carton.

While the connection is being built, somebody does think of that difference. The quantity is converted, five cartons become five hundred pieces. The price passes through untouched, because in both systems it sits in a field that looks identical during mapping. The result is an invoice for five hundred pieces at the carton price.

The critical part is this: taken on their own, both numbers are correct. Five hundred is a valid quantity, the carton price is a valid price. Only the combination is wrong, and no mandatory field checks combinations. The run comes back green, the target system reports success, and the automation did exactly what it was told.

Why this survives every test phase

Errors like this do not hit all articles, only those where the units diverge. In a range of several thousand items that is often a manageable share.

Testing, meanwhile, uses whatever articles are at hand, and those are usually the frequently ordered single piece items where order unit and stock unit already match. For those the result is correct. The error waits inside a product group that never appeared in testing, and becomes visible through a complaint. Months can pass before that happens, and every invoice from that period has to be reworked.

The same mechanism applies to other attributes that get lost in transit. A field is called quantity and holds a number. What is being counted sits in the master data of the source system, in a column nobody needed during mapping. Price basis, currency, discount basis and weight unit behave exactly the same way.

What this means for pricing a proposal

Reconciling master data is a work step of its own. It is not preparation that happens on the side, it is the work in which you determine which system owns which attribute and where conversion takes place.

If that step is missing from the proposal, it has not disappeared. It sits with you, usually unspoken, and it resurfaces in the middle of the build when nobody has time for it any more. That is one of the most common reasons a cheap proposal ends up more expensive than a costly one.

A proposal that includes the step is easy to recognise. It names the fields for which conversion is agreed, and it says what happens when an article lacks that attribute.

What you can check yourself before the first proposal

You can do this work without a supplier, and in a sales meeting it is worth more than any requirements list.

Take twenty articles from each product group, preferring those sold in packs. For each one, put side by side how the ordering system holds it and how the inventory system holds it: which unit the quantity is expressed in, what the price refers to, whether a conversion factor exists and where it is maintained.

You will very likely find three groups. Articles where everything agrees. Articles where a factor exists and is maintained. And articles where the factor lives somewhere in the heads of the sales team. The third group is the one that matters, and its size is the best available indicator of the effort the whole project will take.

The decision only you can make

Which unit governs is not a technical question. It is a decision your company makes, and it has consequences for sales, warehouse and accounting.

Two routes work. Either one system holds the truth and all others convert to it, or every quantity travels together with its unit so that it cannot lose its meaning in transit. The second route is cleaner and more expensive, the first is faster and demands discipline in data maintenance.

What matters is not which route you choose, but that the choice is made before the build and written down. If it is made during implementation, it will be made by somebody who does not know your product range.

Sophera Consulting starts exactly here: before anything is built, the affected fields get a written answer to which system governs, where conversion happens, and what becomes of articles without a factor. Only then does the fixed price follow, with no subscription, including handover and documentation. The entry point is the free automation check.

The recommendation

Spend the half day on the sample before you request proposals. It buys you two things: a solid sense of how large your project really is, and a test for every supplier you talk to.

Then watch the reaction. A supplier who asks about units, conversion factors and price basis before talking about technology is pricing your project. One who assures you it will sort itself out during field mapping is pricing the normal case and will invoice the rest later.