What is the difference between master data and transactional data?

Master data describes the entities involved in business events, such as a customer or a product. Transactional data records the events themselves, such as an order or an invoice, and depends on master data for its context.

Does a mid-sized company need an MDM software platform?

Not necessarily at the start. Many organisations begin with clear ownership, definitions and data quality rules inside their existing ERP or CRM, and introduce a dedicated hub once several systems need to share the same records.

Which identifiers should a Luxembourg supplier or customer record hold?

For a Luxembourg company, typically the RCS number, the VAT number with the LU prefix and, for entities active in financial markets, the LEI. Each should be validated against its official source rather than typed in freely.

What is a golden record?

A golden record is the consolidated, trusted version of an entity built by matching and merging records from several systems. It is the reference that reports and processes should use.

Which MDM style is the easiest to start with?

The registry and consolidation styles are generally the quickest and least invasive, because they leave source systems unchanged. Coexistence and centralised styles give more control but require more integration and process change.

Master data management for mid-sized companies in Luxembourg: where to start

MDM means one trusted, owned version of customer, supplier, product and legal-entity data. What it covers, the warning signs and how a mid-sized company can start.

For a mid-sized company in Luxembourg, master data management (MDM) means agreeing who owns the shared records about customers, suppliers, products and legal entities, and keeping one trusted version of them across ERP, CRM and finance systems. Under the EU definition in Commission Recommendation 2003/361/EC, a medium-sized enterprise has fewer than 250 staff, which is usually too small for a large MDM programme but large enough to suffer from duplicate and conflicting records. The practical answer is to start with governance on one or two domains and add tooling only when it is needed.

What counts as master data

The DAMA-DMBOK body of knowledge distinguishes master data, the core business entities that take part in transactions, from transactional data (orders, invoices, payments) and from reference data (code lists such as countries, currencies or status codes). Master data changes less often than transactions, but every transaction depends on it.

Domain	Typical content	Luxembourg-specific attributes
Customer	Name, legal form, addresses, contacts, payment terms	RCS number and LU VAT number for business customers
Supplier	Name, bank details, addresses, contracts	RCS number, LU VAT number, LEI where applicable
Product or service	Codes, descriptions, units, prices, tax category	VAT treatment
Material	Specifications, units of measure, storage and safety attributes	Depends on sector
Legal entity	Group companies, branches, ownership	RCS number, LEI, VAT number
Employee and location	Organisational units, sites, cost centres	Personal data under GDPR

Identifiers that matter in Luxembourg

RCS number. The Registre de commerce et des sociétés is managed by Luxembourg Business Registers (LBR), and filings are published on the RESA platform. Amendments to a company’s articles must be filed within one month, so registered details can change and need periodic checks.
VAT number. An EU VAT identification number starts with the country code, LU for Luxembourg, and can be checked for validity in the European Commission’s VIES system.
LEI. The Legal Entity Identifier is a unique 20-character code under ISO 17442, managed by the Global Legal Entity Identifier Foundation (GLEIF). It carries “who is who” and “who owns whom” data and must be renewed annually.

In banking, the Basel Committee’s BCBS 239 principles of January 2013 explicitly call for single identifiers and unified naming conventions for legal entities, counterparties, customers and accounts (paragraph 33).

Symptoms of poor master data

The signs are usually visible long before anyone uses the term “master data”:

the same customer or supplier exists several times, under slightly different names;
invoices or reminders go to outdated addresses;
VAT numbers are missing, outdated or invalid;
sales, finance and operations report different customer or product counts;
month-end closing depends on manual reconciliation in spreadsheets;
nobody can say which system holds the correct version of a record.

For customer and contact data, this is also a compliance issue: GDPR Article 5(1)(d) requires personal data to be accurate and, where necessary, kept up to date.

Governance before tooling

A costly mistake is buying a platform before deciding who decides. An MDM tool can match, merge and distribute records, but it cannot settle whether a dormant account is still a customer or which department may create a new supplier. Those are governance questions:

Ownership. One accountable business owner per domain, with a steward who maintains the data day to day (see data owner vs data steward).
Definitions. A short, agreed definition of each entity and its critical attributes.
Creation and change process. Who may create or change a record, with which mandatory fields and validations.
Quality rules. Measurable rules such as “every business customer has a valid VAT number”.

Implementation styles

Four implementation styles are commonly described. They differ in where master data is authored and whether the hub writes back to source systems.

Style	Where data is authored	Writes back to sources?	Fits when…
Registry	In the source systems	No; the hub holds cross-references and identifiers	Many systems, low appetite for change
Consolidation	In the source systems	No; the hub builds a golden record for reporting	The main need is consistent reporting and analytics
Coexistence	In the hub and in the sources	Yes, synchronised	Several operational systems must share clean records
Centralised (transaction)	In the hub, as system of record	Yes, the hub publishes to subscribing systems	Strong central control over creation of customers, suppliers or products

Registry and consolidation are cheaper and quicker; coexistence and centralised styles give more control but demand more integration and process change. A company that runs a single ERP may be able to achieve a “centralised” result inside that ERP, by restricting who creates records and enforcing validations, without a separate hub.

How to start

Pick one domain with visible pain, typically customer or supplier.
Name the owner and the steward for that domain.
Profile the data: count duplicates, missing identifiers and invalid VAT numbers, so the starting point is measured.
Agree definitions and a creation process, including validation of RCS, VAT and LEI against official sources.
Clean the existing records and set up regular monitoring of the quality rules.
Decide on tooling only after these steps, choosing the least complex implementation style that solves the problem.

Where outside help is needed to extend the approach to a second or third domain, support for master data management programmes should cover both governance and implementation, not only the software.

What to do now

List the systems in which customer, supplier and product records are created today.
Check a sample of supplier records for valid LU VAT numbers in VIES and current RCS details.
Name an owner and a steward for the domain that causes the most rework.
Write down three to five measurable quality rules and report on them monthly.
Postpone any platform decision until ownership, definitions and the creation process are agreed.