Business Central master data management for multi-company groups

Why groups need Business Central master data management

In a group with several companies, one vendor often supplies more than one entity. Each entity sells many of the same items. When every company keeps its own copy, the copies drift apart. Numbers differ. So do names and payment terms. Consolidated reporting then needs a mapping table that someone must keep current.

Intercompany trade suffers too. A sales order in one company becomes a purchase order in another. That works only if item numbers line up or a cross-reference exists. One version of each shared record, kept in one place, removes a whole class of reconciliation work.

How master data management works in Business Central

Business Central includes a master data management feature for companies in the same environment. In each receiving company, you open Master Data Management Setup. You choose the source company and enable the sync. The setup lists the tables and fields, and you can adjust them. Microsoft supplies a sensible default list.

An initial sync matches existing records. After that, job queue entries carry changes from the source company to the subsidiaries. The flow is one way, from source to receivers. You decide per table, and per field, whether the receiving company takes the value or keeps its own.

Deciding what is central and what stays local

The technical setup is the smaller half. The larger half is agreeing which fields belong to the group and which belong to each company. An item's number, description and base unit are natural group fields. Its reordering policy, vendor and standard cost may differ by entity.

We run a workshop per record type. The outcome is a simple table of field, owner and central or local. We also settle who may create a new record in the source company. Then we agree how a subsidiary asks for one. A slow request process is what tempts people to create local duplicates.

Rolling out Business Central master data management to existing companies

Turning on sync for companies that already hold data needs preparation. First, records must be matched between source and receiver, usually on number. That way, existing customers and items are coupled, not duplicated. If numbering differs between companies, we resolve that beforehand. Renumbering gets careful planning, in a sandbox.

We rehearse the whole sequence in a sandbox copy. We align the numbers and run the initial sync. Then we inspect what was coupled, created and failed. Next, we change a few source records and confirm they arrive. Only when the result is clean do we repeat it in production.

Limits of the built-in approach and the alternatives

The standard feature covers companies within one environment. Some groups have entities in different environments, often because of different localizations. They need another route. That can be an add-on built for cross-environment replication. Or it can be an integration built on API pages that pushes approved records outward. Both routes need the same ownership rules.

Master data that starts outside the ERP is a different case. Say product data lives in a product information system, or customer data in a CRM. Then Business Central should receive it, not compete with it. We say which pattern fits your landscape before any setup begins. So Business Central master data management never fights your other systems.

Business Central master data management questions

Can changes flow back from a subsidiary to the source company?

Not with the standard feature, which syncs in one direction. Shared fields are maintained in the source company. That is a deliberate design. A single place of truth keeps the records consistent. Subsidiaries ask the owner for changes, and the request process we set up keeps that quick and clear for everyone.

Can a subsidiary keep its own values in some fields?

Yes. The sync is configured by table and by field. Fields left out of the sync stay under local control. So an entity can hold its own prices, planning settings or posting groups on a shared record. We list the local fields in the ownership table, so nobody is unsure which values may differ.

Does Business Central master data management work between different environments or tenants?

The built-in setup is for companies inside the same environment. Across environments, we use a suitable add-on or an API integration. The ownership rules stay the same. Only the transport differs. We help you pick the route that suits your entities, and we test it on sample records before we use it for real.

What happens to records that already exist in both companies?

During the initial sync, they are matched and coupled. Later changes then update the existing record. Matching depends on consistent numbers. That is why we align numbering before the sync. We list records with no match for your decision. You decide each merge, and nothing is duplicated by accident.

Do we need Business Central master data management with one company?

The sync feature is for groups. Even so, a single company still gains from the governance side. That means templates, naming rules, limited creation rights and a named owner for each kind of record. Those habits prevent duplicates and gaps from the start, and they make a later second company far easier.

Related multi-company services

Shared master data underpins the rest of a group setup. The pages below cover building the companies, trading between them, combining their results and cleaning the records before they sync. Read them next if your Business Central master data management plan is part of a bigger group project, so each step builds on the one before. For the product detail, see Business Central documentation on Microsoft Learn.