Intercompany Accounting in D365 BC -

How the IC Inbox and Outbox Work and What Finance Must Configure for Multi-Entity Accuracy

How BC Intercompany Works

The BC intercompany framework operates through a hub-and-spoke model. Each BC company that participates in intercompany transactions is configured as an IC Partner. When one entity posts a transaction that involves another entity — a purchase invoice from a subsidiary, an expense allocation from the parent, a management fee charge — it creates an entry in the counterpart’s IC Inbox. The counterpart entity accepts the entry from its Inbox, and the matching transaction posts automatically.

The result, when it works correctly: one entry in the originating entity, one matching entry in the counterpart entity, and a balanced due-to/due-from relationship between them. At consolidation time, the intercompany balances eliminate against each other cleanly because both sides of the transaction were driven from the same source.

The IC Inbox Workflow Finance Must Own

The IC Inbox requires active management. When a sending entity creates an IC transaction, it lands in the counterpart’s Inbox. Someone in the receiving entity must accept it, review the account mapping, and post it. If nobody processes the Inbox, the balance in the due-to/due-from accounts is incomplete and the intercompany reconciliation doesn’t balance.

Consolidation Without a Consolidation Module

BC doesn’t have a dedicated consolidation module in the way that D365 F&O or a dedicated consolidation tool does. What BC has is a Business Unit consolidation approach: you create a consolidation company, map subsidiaries as business units, and run the Consolidate function to pull trial balances from each subsidiary into the consolidation company. Intercompany eliminations have to be posted as manual journal entries in the consolidation company.

For organizations with straightforward structures — a holding company and two or three wholly-owned subsidiaries in the same currency — the BC consolidation approach works. For organizations with complex minority interests, partial ownership, multiple currencies, and sophisticated elimination requirements, the native BC approach will reach its limits quickly. Know which category you’re in before you commit the consolidation process to native BC tools.

Five Intercompany Mistakes That Create Elimination Problems

Five IC Configuration and Process Mistakes — All Visible at Consolidation Time

IC Chart of Accounts mapping not configured — every inbox item requires manual account assignment
- When the IC Chart of Accounts mapping is missing, every item that lands in an entity’s Inbox shows a blank GL account. The receiving entity has to manually assign the account on every single transaction. This is error-prone, slow, and means the automation that makes IC worthwhile doesn’t exist. Map the IC Chart of Accounts before the first transaction is sent. It takes an hour to configure and saves that hour every month for the life of the implementation.
IC Inbox not processed at period end — intercompany balances are incomplete
- The sending entity closes the period with IC transactions posted. The receiving entity has 14 unprocessed Inbox items. The due-to balance in the sending entity is 40K. The due-from balance in the receiving entity is 00K. The reconciliation difference is the unprocessed Inbox. Every period that ends with unprocessed Inbox items produces an elimination that doesn’t balance and requires manual adjustment. Clear the Inbox before closing each period.
Single IC account used for all entity relationships — eliminations require manual analysis
- One IC Receivable account and one IC Payable account for all intercompany relationships. At consolidation time, the elimination entry is against the combined balance — you can’t tell from the account how much relates to which entity. To produce entity-level reconciliation, Finance runs a subledger analysis of IC transactions by partner. That analysis takes three hours. Separate IC accounts by entity relationship and the elimination is mechanical — the balance in Entity A’s IC Receivable / Entity B eliminates directly against the balance in Entity B’s IC Payable / Entity A.
Currency differences in IC balances not reconciled
- Entity A is USD-functional and charges Entity B (CAD-functional) a USD management fee. The due-from in Entity A is 0,000 USD. The due-to in Entity B is 8,500 CAD — the CAD equivalent at the rate on the transaction date. At consolidation in USD, Entity B’s balance translates at the closing rate, which may differ from the transaction date rate. The translation difference is a legitimate FX item, but it needs to be identified explicitly and eliminated correctly. Treat IC currency differences as a discrete elimination item, not a reconciling unknown.
IC transactions posted as manual journals instead of using the IC framework
- The IC framework requires setup and discipline. Manual journals are faster in the moment. So someone posts the management fee as a manual journal in both entities — debit expense in Entity B, credit revenue in Entity A — without using IC Partners or the Inbox/Outbox workflow. The amounts are equal, but the IC Reconciliation report doesn’t see them as intercompany. They don’t appear in the IC balance analysis. At consolidation, Finance finds elimination entries that don’t correspond to the IC subledger and spends two hours tracing them back to manual journal entries from three months ago. Use the IC framework. Every time.

Up Next:

We’ve been focused on the Finance configuration layer throughout this series. The final topic in this group addresses how Finance stays current as BC evolves: BC Release Wave Management—How Finance Governs Upgrades, Feature Flags, and the Annual Release Cycle—the BC release wave cadence, how the Feature Management page gives Finance control over which new capabilities are enabled in production, and the five release management failures that turn a Microsoft product enhancement into a Finance operational disruption.

— Bobbi

D365 Functional Architect · Recovering Controller

Thank you for reading!

If a post helped you solve a real problem, share it with a Finance colleague who is in the middle of an implementation or a post-go-live optimization. If you have a topic the blog series did not cover, reach out. There is always one more post worth exploring.

If you are interested in learning more, here are a few of my latest posts: