If your organization runs more than one company in Dynamics 365 Business Central, you already know the pain of keeping customer records, vendor lists, chart of accounts, and item masters consistent across all of them. One team updates a vendor's payment terms in Company A. Nobody tells Company B. Three weeks later, someone in finance is reconciling numbers that don't match, and nobody can figure out why.
This is one of the most common operational headaches for businesses with multiple entities, subsidiaries, or franchise locations on Business Central. The good news is that Microsoft addressed this directly with the Master Data Management feature, introduced in the 2023 release wave 1, and it has continued to mature since. Used correctly, it removes the manual, error-prone work of re-entering the same data in every company and replaces it with a controlled, rules-based synchronization process.
This guide walks through exactly how the feature works, how to set it up correctly the first time, the mistakes we see most often during implementation, and how to decide whether the native tool is enough for your business or whether you need something more robust.
What Is Master Data in Business Central, and Why Does Syncing It Matter?
Master data refers to the non-transactional, foundational information that gives context to every transaction your business records. It does not change often, but everything else depends on it being accurate. In Business Central, this typically includes:
- Customers and customer groups
- Vendors and vendor bank accounts
- Items, item categories, and units of measure
- Chart of accounts and dimensions
- Payment terms and payment methods
- Employees
- Resources
When a business operates multiple companies inside the same Business Central environment, whether that's separate legal entities, regional subsidiaries, or divisions that need their own set of books, this data tends to overlap heavily. A vendor that supplies your Texas entity is very likely the same vendor supplying your New Jersey entity. Without synchronization, someone has to manually create and maintain that vendor record twice, and the two records will inevitably drift apart over time through typos, missed updates, or inconsistent naming conventions.
That drift is not a minor inconvenience. It shows up as duplicate vendor payments, inconsistent item costing across entities, broken consolidated reporting, and audit findings that take days to trace back to their source. Synchronizing master data is what keeps a multi-entity Business Central deployment behaving like one coherent business system instead of several disconnected databases that happen to share a login screen.
How Master Data Synchronization Works in Business Central?
The native feature uses a source and subsidiary model, and understanding this model is the key to getting the setup right the first time.
One company is designated as the source company. This is your master record, the single version of truth for the data you want to share. Every other company that needs that data is set up as a subsidiary, and subsidiaries pull the data they need from the source using a scheduled job queue process.
A few structural points matter here, and they are worth understanding before you touch the setup screens:
1. It is a pull model, not a push model: The subsidiary company reaches out and requests updates from the source. The source company does not push changes out to subsidiaries automatically.
2. Synchronization only flows one way per relationship: Microsoft explicitly does not recommend bi-directional synchronization, where a subsidiary also feeds changes back to the source. Doing so creates a real risk of conflicting updates and unwanted overwrites, since the system has no reliable way to determine which change should win when both companies edit the same coupled record.
3. Coupling comes before synchronization: Before Business Central can keep two records in sync, it needs to know that a given customer, vendor, or item in the subsidiary is the same record as one in the source company. This is called coupling, and it is the step most teams underestimate.
4. All companies must live in the same environment: You cannot synchronize master data between companies that sit in separate Business Central environments or tenants using this native feature.
Prerequisites Before You Start
A large share of the setup problems we see trace back to skipping this step. Before opening the Master Data Management Setup page, confirm the following:
| Requirement | Why It Matters |
|---|---|
| All companies exist in the same Business Central environment | The native sync engine cannot bridge separate environments or tenants |
| Users setting this up hold an Essential, Premium, or Basic ISV license | Team Member and Internal Administrator licenses can view but not modify records, so they cannot complete setup |
| Delegated Admin access is not the only access available | This license type cannot schedule the background job queue tasks the sync depends on |
| A clear source-of-truth company has been agreed internally | Without this, teams often argue mid-implementation about which company's data is "correct" |
| Existing master data has been manually reconciled at least once | Coupling works far better when the underlying customer, vendor, and item lists already roughly match |
| A rollback or backup plan exists | The Overwrite Local Change option can permanently replace local edits, so this should never be enabled blind |
That last point deserves emphasis. We have seen teams enable synchronization on a Friday afternoon without validating their data first, only to discover Monday morning that months of locally maintained pricing notes had been silently overwritten by the source company's version. Reconciling your master lists manually first is not a shortcut you can skip.
Step-by-Step: Setting Up Master Data Synchronization
Step 1: Open the Master Data Management Setup Page
In the subsidiary company, use the search icon (Alt+Q), type Master Data Management Setup, and open the related page. Everything for this feature is configured from here.
Step 2: Define the Source Company
In the Source Company field, specify which company this subsidiary should pull changes from. This is a one-time decision per subsidiary and should match the source-of-truth agreement your team made during planning.
Step 3: Enable Synchronization
Turn on the Enable Synchronization toggle and confirm the dialog box. At this point, Business Central scans the source company and identifies which tables and fields are available to synchronize. This does not start moving data yet. It is only preparing the connection.
Step 4: Enable and Filter Tables
Open the Synchronization Tables page from the ribbon. Here you choose exactly which tables you want to bring into sync, such as Customer, Vendor, or Item. You can also apply filters, so if you only want a subset of vendors synced rather than the full list, that is configurable here rather than an all-or-nothing decision.
Step 5: Enable Specific Fields
Within each table, you can choose exactly which fields synchronize, rather than the entire record. Use Enable All Fields or Disable All Fields as a starting point, then fine-tune. If a table includes both a header and lines, such as Account Schedules, make sure you select the key fields on both.
Step 6: Decide on Overwrite Local Change
This setting determines what happens if someone edits a synced record locally in the subsidiary after it has already been coupled. If enabled, the next sync will overwrite that local edit with the source company's version. This is useful when you genuinely want one master version enforced everywhere. It is dangerous if local teams sometimes need to make legitimate local adjustments, such as region-specific pricing. Set this deliberately, not by default.
Step 7: Couple Existing Records
If you already have matching customers, vendors, or items in both companies, use the coupling screen to match them on their key identifying fields. This tells Business Central "this record in Company B is the same as this record in Company A," so future updates apply to the right place instead of creating duplicates. Enabling Synchronize After Coupling and Create New If Unable to Match will handle both existing matches and genuinely new records going forward.
Step 8: Run a Full Synchronization
Once tables, fields, and coupling are configured, go back to the Master Data Management Setup page and select Run Full Synchronization. This is particularly useful when standing up a brand-new subsidiary that should inherit the source company's master data from day one. The Master Data Initial Full Synchronization page will show you which tables completed successfully.
Step 9: Let the Job Queue Handle Ongoing Updates
After the initial sync, Business Central schedules recurring job queue entries that keep coupled records updated automatically whenever the source company changes. You do not need to manually trigger updates going forward, but you should periodically check the Job Queue Entries page for failures.
Which Master Data Tables Should You Actually Sync?
Not every business needs to sync everything. Being selective is often the better strategy, both for performance and for data governance.
| Master Data Type | Typically Synced | Notes |
|---|---|---|
| Customers | Yes, in most multi-entity setups | Especially important when the same customer transacts with multiple entities |
| Vendors | Yes | Prevents duplicate vendor records and payment errors |
| Items | Usually yes | Keep costing methods consistent if entities share a supply chain |
| Chart of Accounts | Often, for consolidated reporting | Critical if the parent company consolidates financials across entities |
| Payment Terms and Methods | Yes | Small table, high consistency value |
| Employees | Sometimes | Depends on whether staff work across entities |
| Dimensions | Case by case | Sync only if reporting structures are meant to be identical across entities |
A good rule of thumb: if inconsistency in a given table would cause a reporting error, a compliance issue, or a duplicate payment, it belongs in your sync scope. If it is genuinely local to one entity, such as region-specific tax settings, leave it out.
Common Errors and How to Fix Them?
| Issue | Likely Cause | Fix |
|---|---|---|
| Sync appears enabled but no data moves | Tables or fields were never explicitly enabled after turning on synchronization | Go to Synchronization Tables and confirm the specific tables and fields you need are set to Enabled |
| Duplicate customer or vendor records after setup | Existing records were not coupled before enabling sync | Run the coupling process before your first full synchronization, matching on key fields |
| Local edits keep disappearing | Overwrite Local Change is enabled and the source company is updating that field | Decide deliberately whether local edits should ever survive a sync, and adjust the setting accordingly |
| Job queue entries show errors | Often a permissions issue, or a record that failed a validation rule in the subsidiary company | Check Job Queue Entries for the specific error message, and confirm the user account running the job has adequate rights |
| Two companies both trying to be the source | Bi-directional sync was configured against Microsoft's recommendation | Redesign the relationship so there is one clear source company per subsidiary chain |
| New company not receiving historical data | Full Synchronization was never run, only ongoing sync was enabled | Run Full Synchronization once to backfill existing records before relying on the job queue for updates |
A Real-World Scenario: What This Looks Like in Practice
To make this concrete, here is a scenario that reflects the kind of engagement we see regularly with distribution and multi-location clients.
A mid-sized distribution business operating three Business Central companies, one for their core US entity and two for regional subsidiaries acquired over the past few years, came to us because their finance team was spending roughly six hours a week manually re-keying vendor and item updates across entities. Worse, a recurring issue where a vendor's updated bank details in one company were not reflected in another had already caused one delayed payment.
We designated their core entity as the source company, reconciled the vendor and item master lists across all three companies to remove existing duplicates, and then configured selective synchronization for Customers, Vendors, Items, and Chart of Accounts, with Overwrite Local Change enabled only for vendor banking and payment term fields, since those specifically needed one enforced version of the truth. Pricing fields were left local, since regional pricing genuinely needed to differ.
Within the first sync cycle, duplicate vendor records dropped to zero, and the manual re-keying work was eliminated entirely. The team's six hours a week became closer to thirty minutes of periodic job queue review. That is the practical value of getting this setup right: it is not just a technical feature, it is hours of manual work removed from a finance team's week, every single week.
Click here to read more case studies.
Native Feature vs Third-Party Master Data Tools
The native Master Data Management feature covers most standard multi-entity scenarios well, and it is included at no additional licensing cost. However, it does have real limitations worth knowing before you commit to it as your long-term solution.
| Capability | Native Business Central Feature | Third-Party Apps (e.g. Global Master Data Sync) |
|---|---|---|
| Cost | Included, no extra license | Additional subscription cost |
| Cross-environment sync | Not supported | Often supported |
| Bi-directional sync | Not recommended, risk of conflicts | Some apps offer managed conflict resolution |
| External system integration (non-BC databases) | Not supported | Frequently supported |
| Error logging and monitoring | Basic, via Job Queue Entries | Often more detailed, with dedicated error dashboards |
| Setup complexity | Moderate, manual table and field configuration | Varies, some offer more guided setup |
| Best fit | Businesses with a handful of companies in one environment, straightforward hierarchy | Businesses with complex, multi-environment, or multi-source structures |
If your company structure is relatively simple, one clear source and a few subsidiaries in a single environment, the native feature is genuinely the right call and adding a paid app on top of it is unnecessary spend. If you are managing companies across separate environments, need bi-directional logic with proper conflict handling, or need to sync with systems outside Business Central entirely, it is worth having a conversation with your implementation partner about whether a dedicated app fits your roadmap better.
Industry Use Cases Worth Knowing
- Wholesale and distribution businesses with regional warehouses set up as separate companies use this to keep vendor and item data aligned so purchasing and costing stay consistent across the network. If this matches your situation, our Wholesale & Distribution team has worked through this exact pattern extensively.
- Manufacturers running separate companies per plant or division rely on synchronized item masters and chart of accounts to keep costing methods and consolidated reporting accurate. We cover related implementation considerations in our piece on Business Central implementation in the manufacturing industry.
- Multi-entity professional services and holding companies typically prioritize chart of accounts and payment terms synchronization to keep consolidated financial reporting clean without forcing every entity to share identical local operational data.
Table of Contents
Frequently Asked Questions
Can I sync master data between two completely different Business Central tenants?
No. The native Master Data Management feature only works within a single environment. Companies in separate tenants require a different integration approach, typically involving APIs or a third-party integration tool.
Does enabling synchronization sync historical transactions too?
No. This feature is built for master data, meaning non-transactional records like customers, vendors, and items. It does not synchronize posted transactions, invoices, or ledger entries.
What happens if I couple the wrong records by mistake?
You can remove an incorrect coupling from the coupling screen. It is far easier to catch this early, so always review coupling matches before running your first full synchronization rather than after.
Is bi-directional synchronization ever a good idea?
Microsoft advises against it because of the conflict risk, and in practice we agree. If you find yourself needing true two-way sync, that is usually a sign you need a more sophisticated integration approach than the native feature offers, not a reason to force bi-directional sync anyway.
How long does the initial full synchronization take?
It depends entirely on how many tables, fields, and existing records you are syncing. A small dataset can complete in minutes. A large item master waith thousands of records and multiple linked tables can take considerably longer, so plan the initial sync outside of business-critical hours.
Getting This Right the First Time
Master data synchronization in Business Central is a genuinely useful, no-cost feature, but the setup decisions you make in the first hour, particularly around which company is your source of truth, which fields should allow local overrides, and how thoroughly you couple existing records, tend to determine whether the feature saves your team hours every week or creates a new mess to clean up.
If your business runs multiple companies in Business Central and you want this configured correctly, validated against your actual data, and monitored properly after go-live, our team at Dynamics Square has done this across distribution, manufacturing, and multi-entity service businesses. You can explore how we approach Business Central implementation, get ongoing support for an existing environment, or talk to our Dynamics 365 consulting team about whether the native feature or a third-party tool fits your structure best.
Schedule a free consultation with our Business Central specialists and get your multi-company data synchronized correctly, without the trial and error.
