B2B Customer Hierarchy: Why One Customer Is Never One Record

Because in B2B, one customer is rarely one record. A single buying organisation exists as a sold-to in your ERP, a company account in your commerce platform, an account object in your CRM, and a separate customer identity in your marketplace. None of those systems is wrong. Each models the customer for a different job, and a B2B customer 360 assembled from all four inherits four incompatible definitions of who the customer is.

The number is not broken. The definition is missing.

A B2B customer 360 is a hierarchy, not a record

Consumer commerce has it easy. One person, one email, one loyalty ID, and entity resolution is mostly a spelling problem.

B2B has a parent company, subsidiaries acquired at different times, divisions with their own budgets, delivery locations that never place an order, authorised buyers who come and go, a negotiated contract that may or may not cover the subsidiaries, and a procurement identity arriving through a punchout catalog with no obvious link to any of it.

Count what one mid-sized buying organisation legitimately produces across a common B2B stack:

• SAP issues a sold-to party, a bill-to party, and a separate ship-to partner for every delivery location.
• Adobe Commerce creates a company account with its own identifier, plus a contact record for each authorised buyer.
• Salesforce holds a parent account and a child account per subsidiary, often created by different sellers in different years, sometimes with the hierarchy field left blank.
• Mirakl assigns a customer identity per storefront, with no shared key back to the ERP.

For a company with three subsidiaries and six delivery sites, the count runs past a dozen records before anyone has made a data-entry error. Every one of those records is correct inside the system that created it.

Then someone asks what that customer spent last year.

Why generic entity resolution does not finish the job

Databricks publishes a Customer Entity Resolution solution accelerator, and it does what it says. It fuzzy-matches records that refer to the same entity, which handles the spelling problem well: “Acme Industrial Supply,” “ACME Industrial Supply Co,” and “Acme Ind. Supply” collapse into one.

That is the easy half.

The hard half is that two records can be matched perfectly and still roll up wrongly, because matching answers a different question than the business is asking. Matching tells you two records refer to the same company. It does not tell you if that company’s orders should count toward the parent’s total, and that is where the money is.

The rollup depends on the question

Ask four teams at an industrial distributor if a subsidiary’s purchases count toward the parent, and you get four answers. All four are right.

Rebate accrual follows the contract. The contract names which legal entities accrue, and it frequently excludes subsidiaries acquired after signing, or excludes marketplace purchases entirely.

Credit exposure sits with the legal entity, because finance can only collect from the party that signed.

Territory credit belongs to the ship-to, because that is the site the rep actually calls on, regardless of who gets invoiced.

Growth and churn signal tracks the buying centre, a group of people who may span two legal entities and appear in none of your hierarchy fields.

A single B2B customer 360 table cannot serve all four. The common failure is building one, picking whichever rollup the first stakeholder asked for, and then watching three other teams quietly return to their own spreadsheets. The platform reports adoption. The business reports that the numbers are wrong. Both are telling the truth.

How to tell if this is your problem

You do not need a project to find out.

1. Ask your warehouse for total spend on your largest account for last year. Ask your ERP the same question. Compare the two numbers, and if they match, compare the second largest.
2. Count distinct customer records sharing an email domain or a tax ID. That count is your floor rather than your ceiling, because it misses every subsidiary trading under a different name.
3. Pull last year’s rebate accrual for one large account and trace which system decided which purchases counted. If the answer involves a spreadsheet, the rule is not in any system.
4. Ask who owns the definition of a parent account. If the answer is a person rather than a written rule, the definition changes when that person leaves.

The last check predicts the other three.

What to fix first

Write the rollup rules down before building anything. Not an architecture diagram. A plain sentence per question: for rebate accrual, these entities count and these do not, and here is the contract clause that says so. Most organisations discover at this point that the rules were never agreed, only assumed, and that the assumptions differ by department. That discovery is worth more than the pipeline it delays.

Then pick one question rather than all four. Rebate accrual is usually the right first choice, because it has money attached and a contract to arbitrate disputes, so the definition can be settled by reading rather than by meeting.

And put the resolved hierarchy in the governance layer rather than inside a report. Unity Catalog is the right home for it on Databricks, because the next four things anyone builds, churn scoring, whitespace analysis, credit review, and seller performance, all need the same answer, and none of them should be re-deriving it.

The part no platform ships

Databricks will store, govern and serve this answer at any scale you need, once somebody decides what the answer is. Deciding is the work, and it belongs to people who know the commercial terms, the contract language, and why one division was set up as its own legal entity years ago.

That knowledge does not live in the data team. It rarely lives in any single place. Getting it written down, agreed, and encoded is the unglamorous first mile of every B2B data programme, and skipping it is the most common reason a technically sound implementation produces numbers nobody trusts.

It is the same pattern that shows up when AI pilots stall at the commerce layer rather than at the model. The technology was never the constraint.

McFadyen Digital builds and operates B2B commerce and marketplace systems for distributors, manufacturers and marketplace operators, and is a Databricks partner.