Why Data Quality Drives the Price of an Automation More Than the Software Does

Two companies automate the same process, taking in orders that arrive by different channels. One receives a quote in the low four figures, the other in the high four figures. The platform is identical in both cases. The difference almost always lies in the condition of the data the automation is supposed to work with.

That is the uncomfortable part. The biggest cost driver in an automation project sits inside your company, not at the supplier, and it can be assessed before any quote is written.

The gap between technically correct and actually usable

Addresses are the clearest example. Suppose a medical supplier delivers to hospitals and care homes. The order names the recipient as one block of text with the hospital, the ward, a contact person, the building and the delivery gate on separate lines. What reaches the order system is company name, street and city. Everything in between drops out, because the target field holds forty characters and because the source never delivered separate fields.

The shipment is delivered. Tracking reports success, with a timestamp and a signature. The parcel sits in central goods receipt and nobody knows where it should go. The address was formally correct and deliverable. It simply was not complete enough to arrive inside the building.

With amounts, an error surfaces at month end. With appointments, at the latest with the customer. With addresses it surfaces when someone in logistics starts resolving cases by hand, and that hand work appears in no report. It just keeps growing.

Free text is the most expensive data format

The origin of nearly all of these problems is a decision nobody consciously made. A piece of information travels through the chain as free text.

That happens faster than people expect. A contact form has a three line address box. A portal delivers the shipping address as one string with line breaks. A block of text is extracted from a PDF order. In all three cases the automation has to guess which line means what, and every guess is a rule someone has to write, test and later maintain.

The same applies to other fields. A quantity without a unit. A requested delivery date written into a sentence. A pack size hidden in the article description. Each field is cheap on its own, and together they are the reason a project overruns.

What you can read from your own data

Take a hundred recent transactions and count three things.

First, how many arrived fully structured, with separate fields for customer number, article number, quantity, unit and delivery address. Second, in how many cases someone in the back office added, corrected or phoned to clarify something. Third, which pieces of information routinely appear only inside free text.

No other document helps you more in a quoting conversation. It turns the question of cost from an estimate into a calculation, and it makes quotes comparable because every supplier works from the same picture.

Data quality is not the automation's job

A common hope is that the automation will straighten the data out. That is possible and within limits sensible, but it is the more expensive order of work and in some cases the more dangerous one.

An automation that quietly corrects addresses, interprets quantities or guesses customer numbers produces exactly the class of error nobody notices. The better sequence is the other way round. First define which fields a transaction needs at minimum in order to be processed automatically. Then route everything that fails that condition into a clarification queue rather than into an assumption.

Automation rate drops at the start, and that is correct. An automation that handles eighty percent reliably and hands over twenty percent cleanly is worth more than one that handles everything and is wrong five percent of the time.

The target system sets the harder limit

Data quality is usually discussed at the source. The tighter constraint often sits at the other end. An order system has a forty character field for the additional address line and a twenty character field for the customer's own order reference. Anything longer is truncated or rejected, depending on the system, and both are a problem. Rejected creates a clarification case, truncated creates a silent error.

So establish before the build which field lengths and mandatory fields the target system imposes and whether they can be extended. A phone call to the vendor answers that. It decides whether a piece of information can survive the chain at all, and accounting for it afterwards costs considerably more than knowing it in advance.

Where investing in master data actually pays

Not every field deserves the same attention. The work pays where an error becomes visible outside the company or moves money. Delivery addresses including the extra line and the delivery point, units of measure and conversion factors, customer numbers and payment terms.

It pays less on fields that are only ever read internally. Making that distinction in advance saves more than any negotiation over a day rate.

The recommendation

Settle two things in writing before the first quote. Which fields a transaction must contain in order to run automatically. And who inside your company decides what happens to the transactions that fail that condition.

With those two decisions you get comparable quotes instead of rough numbers. Without them you pay a buffer that the supplier has to include, because the state of your data is unknown to him.

Sophera Consulting reviews real transactions before quoting, records mandatory fields, clarification paths and exceptions in writing, and only then names a fixed price, with no subscription. The entry point is free via the automation check.