Who is Responsible for Data Quality in System Integration?

Webshop orders are entered into the ERP, then into the warehouse, and finally into the invoicing system. On paper, all systems are connected, yet daily corrections of item numbers are needed, shipping data is missing, and the management report shows different inventory than what's in the warehouse. This raises the question: who is responsible for data quality in system integration?

The short answer: not solely the IT team, not solely the system integrator, and not solely the administrator who first recorded the data. Data quality is a business responsibility that requires technical and operational controls. If this is not clearly designated, integration merely speeds up the transfer of errors from one system to another.

Integration does not automatically correct data

The task of system integration is to transfer and synchronize information according to defined rules. This can include orders, partner data, product master data, prices, inventory, manufacturing status, or billing information. However, just because data technically moves from System A to System B does not mean it is business-useful.

If the same product appears under three different item numbers, integration cannot inherently know which is correct. If a phone number is optional in the webshop but mandatory in the carrier system, someone must decide what happens with the incomplete order. If sales enter unique customer names while finance invoices based on legal names, duplicated partner records are not a technological error.

Therefore, data quality should not be treated as a single error category. In practice, accuracy, completeness, consistency, timeliness, and clarity all matter. Even yesterday's accurate inventory data can cause problems when a fulfillment promise needs to be made to a customer today.

Who is responsible for data quality in system integration in practice?

Responsibility is shared but cannot be vague. Each critical data group needs a business owner, an operational responsible, and a technical responsible. This does not necessarily mean three different people in a 20-person company, but all three perspectives must be present.

The business data owner decides what the correct data is

The business data owner understands the meaning and implications of the data. For example, the commercial manager may be responsible for customer and pricing data, the warehouse manager for inventory and product master operational rules, and the financial manager for billing and tax data.

This does not mean they must manually correct every record. Their task is to declare which data is official, in what form it should be recorded, what constitutes an acceptable deviation, and what should happen in case of an error. For example, they decide when a new product can reach a sellable status and who can approve the unit of measure or tax rate in the product master.

Without a business data owner, IT is often forced to make business decisions. In such cases, a developer or system administrator chooses a logic to replace missing information. This may seem quick but can result in questionable operations later: the system does what was set up, but not necessarily what the business needs.

The process owner is responsible for correct data creation

Data errors most often do not originate in the integration layer. They occur earlier: during order intake, procurement, receipt, product upload, or importing an Excel file. The process owner examines where, who, and under what circumstances the data is recorded.

Let's take a simple example. The warehouse regularly receives orders without the correct shipping method specified. The solution is not necessarily for the warehouse to keep calling sales or for the integrator to write another exception rule. First, it's important to understand why the data is missing. Is the field not mandatory in the webshop? Does customer service enter the order from an email? Is it unclear which carrier can be used for which product?

A good process owner seeks the cause of the error rather than the speed of error correction. This reduces repetitive administration for colleagues and the risk that an experienced employee keeps all exceptions in mind.

IT and the integrator are responsible for the technical data path

The technical responsible ensures that the accepted business rules operate reliably between systems. This includes field mapping, identifier management, mandatory field checks, error handling, logging, permissions, and monitoring.

The system integrator's responsibility is particularly significant when systems interpret the same data differently. A date can be a fulfillment date, an order date, or an expected delivery date. An "active" product may mean it can appear in the webshop, but also that the warehouse can release it. These should not be assumed.

The technical implementation must also make it visible if something did not go through. Quietly failing synchronization is particularly dangerous. If an order does not enter the ERP due to incorrect data, the team should not be informed by a dissatisfied customer or an Excel summary prepared during daily closing. There should be a designated error queue, notification, and a clear responsible for processing it.

Without a source system, debates remain unresolved

For data managed in multiple systems, the principle is that every significant data point should have a designated primary source. This does not mean that all data can only exist in one place. It means that if there is a discrepancy, it should be known which system's data is authoritative.

The product master may belong to the ERP, while the webshop only displays and supplements it with marketing content. The source of customer communication consent may be the CRM, while billing data comes from the financial system. For inventory data, however, it must be precisely defined whether the physical warehouse management system, the ERP, or a manufacturing system is considered authoritative.

Designating the source system sometimes involves uncomfortable decisions. It may mean that a department loses the freedom to modify data in its own spreadsheet. In return, the situation where three managers send each other three different revenue or inventory numbers on a Friday is eliminated. The goal is not centralization for its own sake, but a reliable basis for decision-making.

Responsibility must be translated into measurable operations

"Paying more attention to data" is not a data quality system. Management should choose a few business-relevant metrics: how many orders arrive with incomplete data, how many partner records are duplicated, how long it takes to resolve an integration error, how many manual corrections are needed in a month, and what is the discrepancy between inventory data in systems.

Not every error is worth immediately reducing to zero. Handling a rare, low-value exception may cost more than the error itself. The situation is different if the discrepancy affects billing, deadline fulfillment, production planning, or compliance obligations. Therefore, the acceptable quality level should be determined based on business risk.

It is worth holding regular, brief reviews with the participation of business, operations, and IT. Not as a technical status meeting, but with specific questions: which data error caused the most rework, where has a new manual workaround developed, which rule no longer reflects actual operations? In a growing company, last year's correct process can easily become this year's bottleneck.

Data quality is essentially operational discipline

Ultimately, management is responsible for data quality in system integration, as they must designate ownership and decision-making frameworks. The business data owner is responsible for the meaning of the data, the process owner for its correct creation, and IT and the integrator for ensuring the information reaches the right place in a verifiable, secure, and traceable manner.

If these roles are clear, integration will not be an invisible, uncertain background process. It provides an operational foundation on which the team can build growth with fewer corrections, faster decisions, and more predictability.