Customer hierarchies in Business Central

For B2B sellers, a single customer organisation often has multiple locations, billing relationships, and decision-makers. Business Central's standard data model doesn't natively support deep customer hierarchies the way Dynamics 365 Sales does, but several built-in patterns cover most needs.

The standard patterns.

• Bill-to / Sell-to customer. The most common hierarchy. A sales order's Sell-to Customer is the operational customer (the location, the buyer); the Bill-to Customer is who's invoiced (typically the parent, the holding company, the central accounts payable office). One bill-to can have many sell-tos. Posting hits the bill-to's customer ledger; the sell-to is recorded for operational reporting.

• Ship-to address. Each sell-to customer can have multiple Ship-to Addresses — different warehouses, branch offices, or end-destinations. A sales line can override the customer's default ship-to. Useful when the customer is one company but ships go to many sites without each being a separate customer record.

• Customer template grouping. Customers are grouped through Customer Price Group, Customer Discount Group, Customer Posting Group, Currency Code, Salesperson Code, Country Code. These aren't hierarchies but they enable bulk operations and reporting across grouped customers.

Dimensions as hierarchy. Many BC implementations use dimensions to express customer hierarchy: a Customer Group dimension (Parent A, Parent B, Parent C) attached to each customer record propagates onto every transaction. Reports group by the dimension; the parent-level total rolls up across all child customers automatically.

Native parent-child field. BC has no out-of-the-box parent-child customer field. Customers needing it usually:

• Add a custom Parent Customer lookup field via a per-tenant extension.
• Use the Customer Hierarchy ISV apps available on AppSource.
• Sync the hierarchy from Dynamics 365 Sales (where account hierarchies are first-class) via the standard connector.

Common scenarios.

• Retail chain customer. Parent customer holds the master agreement and billing relationship; child customers represent individual stores receiving deliveries. Use bill-to/sell-to with the parent as bill-to.

• Multi-entity group customer. A customer group with multiple legal entities, each placing its own orders and paying its own invoices. Use separate customer records linked via a Customer Group dimension; no bill-to relationship.

• Holding company structure. Parent receives invoices; multiple operational subsidiaries place orders. Use bill-to / sell-to with operational subsidiaries as sell-tos.

• Franchise. Franchisor as parent; franchisees as children, often with different ownership structures. Hierarchy expressed through dimensions; pricing may differ per franchisee.

Pricing across hierarchy. Customer-specific pricing is per customer; the bill-to / sell-to pair allows price negotiation at the bill-to level applying to all sell-tos, but BC's standard pricing engine resolves at sell-to. For consistent pricing across a customer family, either:

• Use a customer price group that includes the family.
• Apply the same trade agreement at the bill-to and replicate to sell-tos.
• Use ISV extensions for deeper hierarchical pricing.

Reporting. Reports respect customer hierarchy through:

• Bill-to customer field for posted-document analysis.
• Customer Group dimension for cross-customer roll-ups.
• Power BI with custom relationships joining BC data to a customer-hierarchy dataset maintained separately.

Common pitfalls.

• No hierarchy strategy — every customer is independent, no roll-up reporting possible.
• Bill-to / sell-to wrongly used — confusion about which is which leads to wrong posting and wrong customer balances.
• Hierarchy data not maintained — mergers and acquisitions in the customer base aren't reflected; reports misrepresent.

Operational reality. For complex hierarchies, BC's standard model has limits. If hierarchy is central to the business — chain retail, holding-company customers, multi-entity groups — plan for Dynamics 365 Sales as the relationship system, with BC as the financial system, the two integrated. Inside BC alone, dimensions and bill-to/sell-to cover the standard patterns adequately.