Earlier this year, I was recognised by Binary Stream as their Solution Consultant Award Winner 2025 in the Medium Business category. It is an award I am proud of, not because of the title, but because it reflects the work we have been doing at iCatalyst to bring practical multi-entity expertise to the Australian market.
This post is the first in a series where I will share what I have learned from designing and delivering Multi-Entity Management (MEM) solutions across multiple organisations. What works, what does not, and what you need to get right from day one.
What is MEM?
Binary Stream’s Multi-Entity Management (MEM) is an extension for Microsoft Dynamics 365 Business Central that consolidates multiple legal entities into a single Business Central instance.
That distinction matters. You are not managing separate databases or logging in and out of different companies. You are operating within one unified environment where:
- Master data is shared. Customers, vendors, items, and fixed assets exist once and are governed centrally.
- Intercompany transactions are automated. Receivables, payables, and journal entries flow across entities in real time.
- Reporting is consolidated. Combined or entity-specific financial reports are available instantly, not after a month-end spreadsheet exercise.
- Security is entity-aware. Users only see and access data relevant to their role and entity.
It is embedded directly into Business Central. No middleware. No synchronisation. No separate system.
The problem MEM solves
Without MEM, organisations managing multiple legal entities in Business Central typically end up with:
- Separate company databases for each entity, each requiring independent maintenance, upgrades, and backups
- Duplicated master data. The same customer or vendor created multiple times across companies, with no single source of truth
- Manual intercompany reconciliation. Journal entries, invoices, and payments processed separately and reconciled by hand
- Fragmented reporting. Consolidated financials built in spreadsheets, often days or weeks after period close
- Painful upgrades. Every version update multiplied by every company database
For organisations with three, ten, or fifty entities, this approach does not scale. It creates risk, increases cost, and slows down decision making.
MEM eliminates these problems structurally, not just operationally.
When do you actually need MEM?
Not every multi-company setup needs MEM. Here is a practical guide.
You likely need MEM when:
- You have three or more legal entities that share customers, vendors, or items
- You need real-time consolidated reporting across entities without manual effort
- You want to centralise accounts payable or receivable processing
- Intercompany transactions are frequent. Shared services, cost allocations, or cross-entity billing
- You are scaling through acquisitions, new divisions, or geographic expansion and need a repeatable onboarding model for new entities
You probably do not need MEM when:
- You have two companies with minimal overlap in customers, vendors, or operations
- Your entities operate completely independently with no shared data, no intercompany transactions, and no consolidated reporting requirement
The key question is: does your organisation operate as one business across multiple legal structures? If yes, MEM is worth serious consideration.
What to get right from day one
This is where most projects succeed or fail, and it happens before a single transaction is posted.
MEM is powerful, but it demands deliberate architecture. These are design decisions, not configuration checkboxes:
- Entity structure. How will your legal entities map into Business Central? What is a company vs. an entity vs. a reporting unit?
- Chart of accounts alignment. Entities sharing a consolidated view need a consistent chart of accounts.
- Intercompany posting rules. Which transactions trigger intercompany entries? What are the settlement terms? How are shared costs allocated?
- Security model. Who sees what? Entity-level security in MEM is flexible, but it needs to be designed around your organisational structure and compliance requirements.
- Reporting requirements. Define what consolidated and entity-level reporting looks like before you build.
- Master data governance. Shared master data is one of MEM’s biggest advantages, but it also means you need clear ownership, approval workflows, and data quality standards from the start.
Every one of these is an architecture decision. They shape everything downstream, from daily operations to month-end close to audit readiness.
What is next in this series
This is the first post in a dedicated Binary Stream MEM series on this blog. Upcoming posts will cover:
- MEM setup patterns and entity design
- Intercompany transaction flows
- Reporting and consolidation design
- Common implementation pitfalls
- Australian-specific considerations such as GST, BAS reporting, and multi-state operations
Final thought
If you are evaluating MEM or planning a multi-entity Business Central rollout, the design decisions you make upfront will define your long-term success.
That is what this series is about. Getting it right by design.