Earlier this year, I was recognised by Binary Stream as their Solution Consultant Award Winner 2025 in the Medium Business category. It’s an award I’m proud of, not because of the title, but because it reflects the work we’ve been doing at iCatalyst to bring practical multi-entity expertise to the Australian market.

This post is the first in a series where I’ll share what I’ve learned from designing and delivering Multi-Entity Management (MEM) solutions across multiple organisations for what works, what doesn’t, 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’re not managing separate databases or logging in and out of different companies. You’re 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’s 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

For organisations with three, ten, or fifty entities, this approach doesn’t 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’s 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, cross-entity billing or high volume of intercompany recharges
• You’re scaling through acquisitions, new divisions, or geographic expansion and need a repeatable onboarding model for new entities

You probably don’t need MEM when:

• You have 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 requirements

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’s a company vs. an entity vs. a reporting unit? Get this wrong and you’ll be restructuring mid-implementation.
• Chart of accounts alignment — Entities sharing a consolidated view need a consistent chart of accounts. Variations need to be planned, not discovered.
• Intercompany posting rules — Which transactions trigger intercompany entries? What are the settlement terms? How are shared costs allocated? These rules define your automation layer.
• 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. Retrofitting reporting structures after go-live is expensive.
• 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’s 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 (GST, BAS reporting and intercompany operations)

Final thought

If you’re evaluating MEM or planning a multi-entity Business Central rollout, the design decisions you make upfront will define your long-term success.

That’s what this series is about, getting it right by design.