Ask anyone who's tried to buy a house with a sibling, split a bill with a group of friends, or figure out who's actually in charge at a family business, and they'll tell you the same thing: Relationships are complicated. The same person can be your business partner and your brother-in-law. Your landlord might also be your client. Your biggest competitor in one market might be your most important distributor in another.
Businesses have exactly the same problem at a far greater scale. In enterprise software, we have a name for it: multi-role business partner relationships. And it's one of the hardest, most persistently underestimated problems in master data management.
The same company wearing different hats
Here's a scenario that plays out every day inside large enterprises: A distributor buys finished goods from you and also supplies you with raw materials. A single order might be placed by the head office, shipped to a regional warehouse, invoiced to a shared services center, and paid by a completely different entity in the group. All four of those parties are legitimate, correct, and might need to be governed differently: credit terms for one, delivery windows for another, payment terms for a third.
Most systems weren't built for this. A customer relationship management (CRM) tool assumes a company is a customer. An enterprise resource planning (ERP) system's vendor master assumes a company is a supplier. When the same legal entity needs to be both, most platforms respond by creating two disconnected records — one for each hat — and hoping nobody ever has to reconcile them.
But someone eventually has to, because no amount of careful data entry can fix an architectural problem.
Why organizations are so much harder than individuals
A person can usually only play so many roles at once. An organization has no such limit, and that's exactly where this problem stops being an edge case and starts being the default.
A single legal entity might sell through five sales areas, each with its own pricing and terms. It might be taxed differently in every jurisdiction it operates in, and subject to a different regulatory regime in each. It might show up in your systems as a sold-to party in one transaction and a ship-to party in another, a bill-to in a third and a payer in a fourth: sometimes all four on the same order, sometimes split across four different entities in the same corporate family. Add multiple brands, a few acquisitions, and a couple of regional ERPs, and what started as "one customer" is now a web of roles and relationships that nobody in the business can fully see, let alone govern by hand.
This is precisely where it gets unwieldy fast — not because anyone did anything wrong, but because the complexity is real, and most platforms were never designed to model it as complexity. They were designed to model it as noise, to be cleaned up later. It never quite gets cleaned up later.
Two different kinds of "role" — and why the difference matters
Untangling this starts with recognizing that "role" actually means two different things, and conflating them is where most data models quietly break down.
Business Partner Role answers this question: What is this entity? A company can hold more than one of these at once: It can be a customer and a supplier simultaneously, on the same record, in the same system. This is the classic multi-role business partner problem, and it's a classification question: Which business functions and transactions is this entity permitted to participate in?
Interaction Role answers a completely different question: What capacity is this entity acting in, toward another specific entity, for this transaction? This is where ship-to, bill-to, sold-to, and payer live. A single company can hold several Interaction Roles across a single order, and the entity fulfilling one role often isn't the entity fulfilling another. Crucially, these relationships need to be validated, not just recorded. If a ship-to role requires a payer role on the other end of the relationship, that has to be enforced at the point the relationship is created, not discovered during a reconciliation report three weeks later.
Most vendors blur these two concepts into one flat idea of "role" and hope the difference doesn't matter. It always matters. One is about what an entity is; the other is about what it's doing, to whom, right now.
Who gets to see what
Complexity does not stop at knowing which roles a party holds. Once an enterprise operates through dealers, franchises, or a network of regional affiliates, a second question shows up right behind the first: Who is allowed to see this, and who is allowed to change it?
A large distributor network might have dozens of affiliates, each managing its own set of business partners, some of which are shared across two or more affiliates working the same account in different countries. That raises two separate requirements.
First, security. An affiliate should generally only see the business partners it is authorized to see, and different users may need different levels of access to different domains of the same record. Someone who manages sales data on an account might have no business editing its finance data, and some users should only be able to review and approve, not create or change anything at all.
Second, scope. An affiliate needs to see both the master data that is genuinely shared enterprise-wide, where a company's legal name and VAT number do not change depending on who is looking, and the data that is deliberately local to them, where a shared field might legitimately hold different values from one affiliate to the next.
Neither of these is a "nice to have" for a business of this shape. Get either wrong and you either expose data an affiliate should not see or force every affiliate into a one-size-fits-all field that fits nobody well.
The honest answer is that STEP, our trusted intelligence platform, has the flexibility and governance mechanisms to solve this properly — node-level security, domain-scoped roles, approval-only access, and contextual attribute management are all native capabilities, not workarounds. Exactly how they get configured, which affiliate structure, which data domains, which approval chains, is a conversation worth having directly, because that configuration should match how your business actually operates rather than a generic template.
If you're migrating to SAP S/4HANA, you can't dodge this
For any organization moving to SAP S/4HANA, this stops being a theoretical data modeling question and becomes a mandatory design decision. S/4HANA unifies customer and supplier management into a single business partner (BP) construct: one entity, one or more BP roles, governed centrally. If your existing master data was built around separate, disconnected customer and vendor records, that reconciliation has to happen before or during the migration. It doesn't optionally go away.
This is exactly the ground STEP is built to stand on. STEP supports the SAP business partner data model natively, including BP roles, partner functions, and BP relationship categories, so organizations migrating to S/4HANA aren't forced to choose between matching SAP's model and keeping the master data governance they already rely on. Whether the right approach for your organization is a single unified business partner object or separate customer, supplier, and contact person object types is itself a governance decision, not a limitation, and it's one STEP is designed to support either way. If you want the technical detail on how this maps through, our documentation covers it in full.
Why this matters more now than it used to
For years, this was a data quality issue: annoying, but survivable with enough manual cleanup. That's changing fast.
AI agents don't do manual cleanup. An agent asked to optimize a supply chain, resolve a billing dispute, or flag a compliance risk needs to traverse relationships to reason about them, which is a major evolution from just clean records. It needs to know which entity is really responsible for this invoice, which warehouse is really the ship-to for this order, and which subsidiary is really the counterparty in this contract. If those relationships aren't modeled with meaning, an AI agent is working with a map that has all the towns marked but none of the roads drawn in.
This is the thinking behind STEP's semantic data graph and our MCP Server: master data that stores the governed, typed relationships between what exists, available to AI agents as a reasoning substrate — not just a lookup table.
The takeaway
Relationships were always complicated. What's changed is how much now depends on getting them right, and how quickly the cost of getting them wrong shows up, whether that's a shipment sent to the wrong entity or an AI agent confidently acting on a relationship that was never actually valid.
Master data that only knows what a company is was always going to be incomplete. The businesses solving this now are the ones investing in master data that also knows what a company does: in every Business Partner Role it holds, every Interaction Role it plays, and every relationship that connects them.
