Who in the company is responsible for ERP data quality?

Responsibility for ERP data quality sits with the business department that owns the data: sales for customers, purchasing for vendors, product management for items, finance for accounts. IT provides tools and rule checks but owns no content. For this to hold, every data object needs one named responsible person, and executive management must visibly back that assignment.

Why does “IT will take care of it” not work?

IT can check whether a field is filled, but not whether it is correct. Whether a lead time is realistic, a payment term current or a customer a duplicate is something only the business knows. Where data maintenance is dumped on IT, you get formal quality: fields are filled, but nobody trusts the content.

Every month-end close knows the result: reports that have to be debated before anyone believes them. The damage creeps in slowly and is almost always blamed on the system, although it is an organisational gap.

IT can provide the structure, the mandatory fields and the validation rules. What it cannot do is judge whether a customer record is correct in substance or which of two duplicates is the valid one. That decision sits with the business and cannot be delegated.

That is why assigning it to IT fails not on competence but on responsibility. It creates the illusion that the topic has been handed over, and it is exactly that illusion which prevents anyone from genuinely taking it on.

Which roles does a mid-sized company really need?

No data-governance bureaucracy, but three clear roles in lean form: a data owner per object from the business, who owns rules and approvals. Data maintainers who create and change records, with clear workflows. And one coordinator for the whole, often based in controlling or organisation, who holds metrics and rulebook together.

• Data owner per object: decides rules, mandatory depth and disputes
• Data maintainer: creates and changes via workflow, no wild-west record creation
• Coordinator: keeps metrics, rulebook and cleansing cycles together
• Executive management: makes the assignment visible and decides escalations

What matters is the size of the model: a mid-sized company does not need a data governance organisation but named individuals. Two to four data owners for the essential objects are enough, provided they have decision rights and a few hours a month.

How does data quality become measurable instead of felt?

With a few permanently tracked metrics per data object: duplicate rate, share of complete mandatory fields, share of inactive records, age of the last maintenance. Four figures per quarter are enough to see decay early, long before it reaches the close or the customer.

The fixed rhythm is what matters: data quality is not a project that ends, but an operating variable like liquidity. In Business Central these checks can largely be automated, including creation workflows with mandatory fields that stop bad data from arising in the first place.

What matters is less the absolute level than the trend. Whoever collects the same four figures monthly sees deterioration early and can correct course before it shows up in a report or a migration.

And the measurement should run automatically. A figure that somebody compiles by hand stops being collected after three months, and then data quality is a matter of feeling again.

What does AI change about the question of responsibility?

AI sharpens it. AI agents in Business Central work directly on the master data: they capture orders, match invoices, propose postings. Every weakness in the data foundation thus scales from a single manual error into an automated serial error.

That is why the responsibility question is the real AI-readiness question: before an agent prepares decisions, it must be clear who owns the data it works on, and who intervenes when its proposals rest on bad data. AI works on the data foundation, not in its place.

AI sharpens the question, it does not change the answer. An agent works on your master data and does not distinguish between a well-kept record and one that has grown over the years. It applies its rule to both alike and thereby makes your data quality quickly effective, for better or worse.

How do you fill the role in concrete terms?

The role belongs in the business, not in IT, and it needs three things or it stays a title on a slide: a fixed share of working time, real decision rights, and a metric the person is measured against.

For the time share, ten to twenty percent of working time is realistic, more during the cleansing phase. "They can do it alongside" does not work, because data upkeep always ends up behind the day job. The decision rights must be in writing: this person decides on creation rules, mandatory fields and disputes within their object, without escalating every time.

Who do you choose? In every company there is already someone who gets asked when a master record is unclear. That informal authority is the best candidate, because the competence is already there, only the mandate is missing. Formalise what is happening anyway.

What do you do when nobody wants to take the responsibility?

The most common case in practice, and usually a leadership topic rather than a data topic. The reasons are almost always the same three: no time, no authority, no visible benefit. All three are solvable, but only through decisions by executive management.

• No time: put the time share into the objectives and into the calendar, not into goodwill.
• No authority: decision rights in writing, visible to everyone involved.
• No benefit: include the quality metric in the departmental objectives, so that good data visibly contributes to the result.

If executive management will not commit to these three points, the honest conclusion is that data quality is not a goal in this company but a wish. In that case you should not build automation or AI agents on top of it either, because both only amplify what is already in the data.

This clarity is uncomfortable and useful. It prevents a data quality initiative from starting that nobody can carry, and it puts the question where it belongs: at management level and not in IT.