Sharing Is Not Always Caring

Why shared master data is a decision, not a default

Part 6 of our nine-part Multi-Entity ERP series. Previously: One Ledger to Rule Them All

A multi-entity group can get master data wrong in two ways, which mirror each other. The more diversified group’s failure usually begins as a cost-saving idea such as “let’s use one item model for simplicity.” The integrated group’s failure usually begins with a perceived lack of planning, with every company quietly inventing its own version of the same customer, because nobody instructed them not to.

Both failures stem from treating shared master data as a default setting rather than a tactical decision. It is neither automatically good nor automatically bad. However, it is a boundary, and you must draw it on purpose.

Three Real Approaches

Once you recognize that “share everything” or “isolate everything” is not the only answer, three real options remain. Most groups need all three, applied to different kinds of data.

• Share reference data that is genuinely common across the group, such as currencies, units of measure, country codes, and other important things that nobody thinks about
• Isolate master data where the entities are running different businesses, or need separation for risk, confidentiality, or partner reasons
• Replicate with clear ownership when entities legitimately need their own copy with the source of truth specifically defined

When It Is a Relationship, and When It Is Not

A shared customer or vendor master is a gift when it reflects a common economic relationship. If three of your entities all sell to the same national retailer, one customer record with transactional visibility across the group is a strong feature. But the same shared master becomes a liability the moment two of your companies are, functionally, in different businesses selling to buyers who happen to share a parent company’s name. Sharing the record doesn’t create a relationship that didn’t exist previously. Identify a sharing strategy that reflects the economic relationship. This must include guidance for the team on when to use an established account rather than creating a new one.

Items Crossing Lanes Rarely Get Along

While you might be tempted to build one item table, that simplification can be misleading. A chemical plant, alongside a manufacturer and its own aftermarket business, almost never shares a usable item model. When you force them together, the result is an item master that is technically unified but practically useless. Carefully weigh the system functionality to validate differing units of measure, costing and pricing data inputs, and similar areas of distinct data needs. Then, validate that the required analytics can be met and aren’t blurred by sharing items.

Numbering That Travels Without a Passport

A genuinely useful control to build involves number sequences. A document number should be traceable and provide context without anyone having to reference the number series first. If an invoice number, a purchase order, or a journal reference tells you nothing about the origin until you dig into the system, you have built a numbering scheme that isn’t working. The reference numbers should be a clue to system users, not a mystery.

Somebody Must Own the Data

Shared master data is only as good as the answer to a deceptively simple question: “Who is allowed to create a vendor that five companies are about to rely on?” If the answer is “whoever gets there first,” you will eventually end up with duplicate vendors, inconsistent payment terms, and a reconciliation headache nobody wants to deal with. Ownership of shared data is a distinctly critical role and should be strictly enforced.

Partnerships Change the Equation

When a partner or joint venture is involved, restriction is the wisest option. A shared master with a second owner outside of your group is not a setup option; it becomes a contract. Unless you are the managing partner with clear authority over that data, the safer path is to isolate rather than share data. Carefully consider that “we’ll sort out ownership of data later” seems more reasonable before a dispute than during one.

Write the Policy Before the Data Loads

The best and least expensive time to make these decisions is before anyone loads the first conversion file, not after duplicate customers start showing up in testing. A brief, written master data policy outlining what gets shared, what gets isolated, what gets replicated, and who owns each category is far easier to whiteboard early on than to reverse-engineer from a production system six months post go-live.

Once your data boundaries are defined, the next decision is how much of the actual system, modules, processes, the whole toolkit, each entity genuinely needs. Spoiler alert: probably not all of it. This article is up next.

Write your policy before the data loads with our free Master Data Policy table, which lays out what gets shared, isolated, or replicated and who owns each category. Download the Master Data Policy table: