+
When the liquor license writes the org chart.
A national events operator runs ~85 venues across multiple states, with a separate legal entity behind every state liquor license. One all-inclusive guest package therefore splits across several companies. Multi-Entity Management for Microsoft Dynamics 365 Business Central collapsed those companies into one, with entities kept distinct as a dimension.
~85
venues across multiple US states.
3
expense patterns live at once, routed by hand.
1
unified company after Multi-Entity Management (MEM) for Microsoft Dynamics 365 Business Central.
This national events company operates roughly 85 venues across multiple states. Its model is all-inclusive: a client books one package at a per-guest price, and that price covers the venue, catering, décor, and bar service. One fee, one invoice, and one experience.
But then it gets complicated: Because of the alcohol service, legal entity structure must follow the state-specific liquor license.
So in practice, there is one brand. Financially there are multiple companies, each of which must hold the right revenue, pay from the right account, buy from the right vendors, and close on the right calendar.
Alcohol is regulated state by state.
Many states require the license to be held by a specific legal entity.
The states restrict who may purchase alcohol on that license.
The states also require alcohol revenue to be recognized in the licensed entity.
Every time an operator crosses a state line, it essentially sets up another beverage company.
| Food revenue | → | Parent operating company |
| Liquor revenue + tax liability | → | Local beverage company |
|
|
The solution |
Entity ownership is declared at the header of every document and journal, so it is explicit from the outset. Where a line belongs to a different entity than the header, the balancing entries appear on their own. Allocation templates spread a single transaction across entities by percentage, fixed amount, or variable amount, and work across journals and documents alike — which is what makes shared national vendor spend distributable back to the venues that consumed it.
Per-entity master data restrictions mean a beverage entity that may not transact with a given vendor never sees that vendor in the lookup. Combined with allowable dimension combinations — restricting which entity and location values may be posted against a given GL account — the licensing rules become configuration rather than tribal knowledge.
Payment batches operate in either centralized mode, where disbursements draw from the parent entity’s bank account regardless of which entity owns the underlying transaction, or decentralized mode, where each entity pays from its own account. The mode is a property of the batch, so a pay run is routed simply by which batch it is filed into — and the offsetting intercompany entries are generated either way. That covers all three of the operator’s expense patterns without a separate process for each.
Multiple fiscal year ends are supported concurrently. Eliminations can be posted with automatic reversal on a defined date, giving a ledger record behind the consolidated view — an option the team can adopt at its own pace, since consolidation in the reporting layer remains perfectly valid. Because every transaction carries the entity anchor, per-entity and consolidated reporting come from one dataset, and the group’s FP&A platform pulls from the same anchor.
MEM AI answers intercompany questions in plain language — what one entity owes another, and whether both sides of an intercompany trade agree — and returns a structured table spanning multiple entities, with drill-downs to the underlying transactions, without anyone building a report first.
 |
+ | |
Compare |
| Requirement | Standard BC | With Multi-Entity Management |
|---|---|---|
| Intercompany balancing | Possible by dimension, but due-to/due-from entries aren’t generated automatically. | Due-to/due-from entries are injected automatically at posting — configured once. |
| Entity-level security | Achievable, but requires extensive customization. | Governed directly by the entity dimension. A user with rights to three entities sees only those three. |
| Master data control | Any user can select any vendor, customer, or GL account, regardless of entity. | Per-entity allow lists. Ineligible vendors don’t appear in the lookup at all. |
| Entity-specific setup | No native concept of entity-level settings. | Each entity carries its own bank account, document numbering, and configuration. |
| Eliminations | Handled downstream in the reporting layer. | Calculated automatically, reviewable before posting, and reverse on a defined date. |
| Cross-entity documents | Manual creation of the matching document in the other company. | Entities transact as virtual customers/vendors of each other; the companion document is created automatically. |
| Reporting | Build it yourself. | Any report can run per-entity or across entities in real time, including consolidated views and FP&A extraction. |
