Hi Everyone,
We are currently evaluating a significant change to our Salesforce data model and would appreciate guidance from anyone who has implemented a similar solution in a large enterprise environment.
Current Situation
The Account object is our primary master data entity.
Looking for Experience and Best Practices: Splitting Salesforce Account into Separate Business Entities (Commercial Account vs Legal Entity)
If your organisation has implemented a similar transformation, we would greatly appreciate insights on:
- Recommended target architecture.
- Expected level of effort.
- Biggest implementation risks.
- Business processes that were unexpectedly impacted.
- Integration challenges discovered after design.
- Impact on CPQ, contracts, billing, and reporting.
- Data migration strategy and lessons learned.
- Account Hierarchy Impact How did the change affect:
- Parent Account hierarchies
- Rollup reporting
- Account Teams
- Territory Management
- Enterprise Account structure
- How were Opportunities handled? Did Opportunities relate to:
- Commercial Account
- Legal Entity
Any reference architectures, lessons learned, implementation patterns, anti-patterns, or best practices would be extremely valuable.
Thank you in advance for sharing your experience and recommendations.
Hi Ravishankar - having done a couple of these (legal-entity vs operating/commercial splits), the single biggest decision - and the one that drives everything else - is: keep Legal Entity as an Account record type, don't make it a separate custom object.
Recommended target architecture:
- One Account object, two record types: Commercial Account (the selling/operating relationship) and Legal Entity (the contracting/billing/tax party).
- Link them via Account Hierarchy (Parent Account) or a dedicated lookup (Legal_Entity) - hierarchy if it's a clean 1:many, a lookup/junction if a commercial account can map to different legal entities over time or geography.
- Introduce account ROLES on the transactional objects instead of forcing one account: sold-to = Commercial Account, bill-to / contracting party = Legal Entity, via lookups on Opportunity/Quote/Order/Contract.
Why not a custom object for Legal Entity: Contracts (Contract.AccountId), Orders, CPQ, Billing/Revenue Cloud, Assets and Entitlements all reference the standard Account. Making Legal Entity a custom object means losing all of that out-of-the-box and rebuilding it - a huge, avoidable cost. Record types keep standard functionality intact.
Biggest risks:
- Reparenting existing data (Opps, Contacts, Contracts, Assets, Cases) to the correct entity - the hardest part; plan the migration + validation carefully.
- Sharing/visibility: OWD, role hierarchy and territories keyed on Account can shift when the structure changes - re-model sharing deliberately.
- Reporting roll-ups: anything rolling up at account/hierarchy level needs rework for the two-tier model.
- Duplicate/matching rules must distinguish the two record types.
Processes that unexpectedly bite:
- Quote-to-cash is where the split really lands. Decide sold-to (commercial) vs bill-to (legal entity) explicitly and thread it through Opportunity - Quote - Order - Contract - Invoice.
- Territory assignment, approval routing, and case entitlements/SLAs that read Account fields.
- Tax and consent/privacy, which usually belong to the Legal Entity.
CPQ / Contracts / Billing / Reporting:
- CPQ: quote on the Commercial Account, but carry the Legal Entity as bill-to (lookup) so contracts and orders bind to the right party.
- Contract.AccountId points to the Legal Entity (contracting party); keep the commercial relationship as a related lookup.
- Billing/Revenue Cloud: bill-to = Legal Entity.
- Reporting: build for both tiers - commercial performance vs legal-entity consolidation - via the hierarchy/lookup.
Approach / effort:
- Start with an impact assessment: catalog everything referencing Account - objects with Account lookups, flows/triggers/validation rules, reports/dashboards, sharing rules, CPQ & billing config, and every integration keyed on Account Id / External Id.
- Build and validate in a full sandbox, especially the CPQ/billing/reporting flows, before any cutover.
- Phase it, and plan the data migration + External Id/MDM alignment with your ERP (which almost certainly already has a legal-entity / sold-to / bill-to model you'll want to map to).
- For a large enterprise with CPQ + billing + integrations this is typically a multi-month program, not a config change - the data migration and quote-to-cash rework dominate the timeline.
Happy to go deeper on the quote-to-cash role modeling or the sharing re-design - those are where the effort is usually underestimated.
