Intercompany Accounting in D365 F&O

Multi-entity transactions, intercompany AR/AP, automated posting across legal entities, consolidation, elimination entries, and the configuration decisions that determine whether your multi-entity close is a manageable process or a monthly investigation.

The Multi-Entity Architecture in D365 F&O

D365 F&O manages multiple legal entities as separate Legal Entities within a single instance. Each legal entity has its own chart of accounts (or shares one through a shared COA structure), its own general ledger, its own subledgers, its own fiscal calendar, and its own period close schedule. Legal entities share the D365 environment but maintain completely separate financial data — a transaction posted in Legal Entity A does not appear in Legal Entity B without explicit intercompany posting.

For organizations with multiple entities that transact with each other, D365 F&O’s intercompany framework automates the cross-entity posting. The intercompany framework supports three primary transaction flows: intercompany trade orders (one entity sells goods or services to another entity, generating matching sales and purchase orders), intercompany journal entries (manual GL entries that automatically create mirror entries in the target entity), and intercompany financial transactions (intercompany payments, netting arrangements, loan management). Each has different configuration requirements and GL behavior.

Intercompany Framework — Core Setup Elements

How Intercompany Trade Orders Flow

The most common intercompany transaction type in D365 F&O implementations is the intercompany trade order — one entity selling goods or services to another. Here’s the complete flow, because understanding each step’s GL impact is what enables Finance to reconcile intercompany balances at period close.

Entity A Creates a Sales Order to Entity B
- Entity A’s order management team creates a sales order with Entity B as the customer. D365 recognizes Entity B as an intercompany customer and automatically creates a corresponding purchase order in Entity B’s books. At this stage, neither entity has any GL posting — the orders are commitments, not financial events. The purchase order in Entity B carries the intercompany price as the expected cost.
- GL Impact: None — orders are commitment documents, not postings
Entity A Posts the Packing Slip / Product Receipt
- When Entity A ships goods, the packing slip posts in Entity A — relieving inventory and recording COGS at the intercompany sales price. Simultaneously, D365 posts a product receipt in Entity B — recording the received inventory at the intercompany cost price. Both inventory subledgers update. The intercompany sale hasn’t been invoiced yet, so no AR or AP entries exist — but both entities’ inventory positions already reflect the physical movement.
- Entity A: Dr. COGS / Cr. Inventory
- Entity B: Dr. Inventory / Cr. IC Accrual
Entity A Posts the Intercompany Sales Invoice
- Entity A invoices Entity B for the shipment. The sales invoice in Entity A creates an intercompany receivable (Due-From Entity B) and records intercompany revenue. Simultaneously, D365 posts the matching purchase invoice in Entity B — recording the intercompany payable (Due-To Entity A) and the expense or inventory cost. Both AR and AP entries now exist on both sides of the transaction, denominated in each entity’s functional currency with automatic foreign exchange conversion if applicable.
- Entity A: Dr. Due-From B / Cr. IC Revenue
- Entity B: Dr. IC Expense or Inventory / Cr. Due-To A
Settlement — Payment or Netting
- The intercompany receivable/payable can be settled by actual intercompany payment (Entity B wires cash to Entity A) or through D365’s intercompany netting feature (multiple intercompany balances across entities are offset against each other, settling the net position in a single transaction). Netting is particularly valuable for organizations with high intercompany transaction volume — it reduces the number of actual cash movements while keeping both entities’ books correctly reflecting settled obligations.
- Entity A: Dr. Cash / Cr. Due-From B
- Entity B: Dr. Due-To A / Cr. Cash

Transfer Pricing — The Finance and Tax Decision That Lives in System Setup

The price at which Entity A sells to Entity B isn’t just an intercompany detail — it’s a transfer pricing policy with tax authority scrutiny in every jurisdiction where those entities operate. D365 F&O supports several pricing methods for intercompany transactions, and the choice belongs to Finance and Tax, not to whoever is configuring the intercompany trading relationship in the system.

Consolidation in D365 F&O — How the Consolidated Close Works

D365 F&O produces consolidated financial statements through a Consolidation process in General Ledger. The consolidation company is a designated legal entity in D365 that receives imported GL balances from subsidiary entities and holds elimination entries. The resulting trial balance in the consolidation entity is the basis for consolidated financial statements.

Consolidation Step	Where in D365 F&O	Finance Action Required
1. Close Subsidiary Periods	General ledger → Period close → each subsidiary entity	Confirm all entities have completed their individual period close before triggering consolidation import. One entity with an open period invalidates the consolidated figures by that entity’s outstanding transaction volume.
2. Run Currency Translation	General ledger → Periodic → Consolidate → Consolidate online	Configure translation rates for the period (closing rate for balance sheet, average rate for income statement, historical rate for equity). Translation adjustment posts to designated OCI account — verify this mapping before each consolidation run.
3. Import Subsidiary Balances	General ledger → Consolidate → Consolidate online or Import	Run the consolidation import for each subsidiary entity. Review the consolidation report for any import warnings — account mapping gaps, dimension translation errors, currency conversion anomalies.
4. Post Elimination Entries	General ledger → Journal entries → Consolidation journals	Post elimination journal entries for all intercompany relationships: IC receivables vs. IC payables, IC revenue vs. IC expense, investment in subsidiaries vs. subsidiary equity, intercompany profit in inventory. Use a templated elimination journal structure updated each period rather than rebuilding from scratch.
5. Verify IC Accounts Net Zero	Financial reports → Trial balance with IC account filter	Any intercompany account with a non-zero balance after eliminations indicates either a missing elimination entry or a timing difference in intercompany posting between entities. Investigate and resolve before releasing consolidated statements.
6. Produce Consolidated Statements	Financial reporting (Management Reporter / FR)	Run consolidated P&L, balance sheet, and cash flow from the consolidation entity’s trial balance. Review for reasonableness — consolidated margin should equal the sum of entity margins adjusted for intercompany eliminations.

Intercompany Journaling — When Manual Is Unavoidable

Not every intercompany transaction flows through the automated trade order framework. Allocations, cost recharges, and adjustments that don’t fit the sales order/purchase order structure are often processed as intercompany journal entries directly in the general ledger. D365 F&O supports intercompany journals that post to multiple legal entities simultaneously from a single entry — the originating entity creates the journal, designates the lines that belong to the receiving entity (using the Due-To / Due-From intercompany accounts), and posts. D365 creates the mirror journal in the receiving entity automatically.

The intercompany journal is useful but carries risk: unlike trade orders which flow through AP and AR subledgers with invoice matching controls, intercompany journals post directly to the GL without subledger validation. Errors in intercompany journals — wrong entity, wrong account, wrong period — are harder to detect in subledger reconciliation because there is no subledger. The only reconciliation available is the intercompany account balance on each entity’s trial balance compared to the corresponding account in the counterparty entity. That reconciliation needs to happen at every period close, for every entity pair, before the period is locked.

Five Mistakes That Produce a Consolidated Close Nobody Finishes On Time

⚠️ Intercompany Transactions Posted Manually Without the IC Framework — Different Accounts on Each Side

The intercompany framework isn’t configured because “it seemed complex during implementation,” so the team processes intercompany charges as manual GL journals in each entity separately. Entity A debits Intercompany Receivable Account 1260 and credits Revenue 4700. Entity B’s accountant books the same charge but uses Intercompany Payable Account 2280 instead of 2270 because the setup memo was unclear. At consolidation, the elimination entry tries to zero out 1260 vs. 2270 — but Entity B’s balance is in 2280. The receivable eliminates; the payable doesn’t. Consolidated balance sheet shows a phantom payable from an intercompany transaction that was actually settled six months ago.
Fix: Define the intercompany account structure — exact account numbers and their assignment to each entity pair — as a Finance-owned document before any intercompany posting begins. Make that document the authoritative reference for every accountant at every entity. If the IC framework is not configured, at minimum create a written procedure specifying exactly which accounts to use in each entity for each transaction type. Consistent account use is the prerequisite for elimination entries that work.

⚠️ Intercompany Prices Not Reviewed — Transfer Pricing Documentation Thin or Absent

The intercompany price was set at go-live based on a reasonable estimate and never reviewed. Over three years, the selling entity’s cost structure changed significantly — new overhead, higher labor, facility expansion. The intercompany price didn’t change. The selling entity’s margin on intercompany transactions is now materially different from what it was when the price was set. Transfer pricing documentation, if it exists, describes the original pricing rationale and hasn’t been updated to reflect current cost structure. Tax authorities in the selling entity’s jurisdiction conduct a transfer pricing audit. The question asked is whether the current price reflects arm’s-length terms. The answer requires explaining a pricing rationale that no longer matches current economics.
Fix: Schedule an annual review of intercompany pricing — Finance and Tax together — to confirm that prices still reflect the documented methodology and that the methodology still meets arm’s-length requirements in all relevant jurisdictions. Update the transfer pricing documentation when prices change. Build the pricing review into the annual budget and standard cost update cycle so it happens systematically rather than reactively.

⚠️ Subsidiary Periods Not Synchronized Before Consolidation — Consolidated Statements Reflect Different Time Windows

The consolidation run happens on the 8th business day after month-end. Three of five subsidiaries have closed their periods. The other two are still processing transactions. Finance runs consolidation anyway because “the two slow entities are small.” The consolidated income statement combines three entities’ complete January data with two entities’ partial January data — the two slow entities’ last few days of January transactions aren’t included. The consolidated margin shows an anomaly. Leadership asks why. The answer involves explaining that the consolidated statements don’t actually represent the same time period for all entities, which is a difficult conversation about why the consolidation process was run against an incomplete data set.
Fix: The consolidated period close checklist must include a confirmation step — written, from the controller or CFO of each entity — that the entity’s period is fully closed before the consolidation import runs. No exceptions for “small entities” or “the amounts won’t be material.” Consolidated financial statements have an implicit representation that all entities’ data covers the same period. Violating that representation, even for immaterial entities, creates a process integrity problem that matters more than the dollar amount.

⚠️ Intercompany Profit in Inventory Not Eliminated — Consolidated Gross Margin Overstated

Entity A manufactures goods at $40 unit cost and sells them to Entity B at $60 (intercompany price). Entity B holds those goods in inventory at $60. In Entity A’s standalone books, the $20 margin per unit is earned at shipment. In Entity B’s standalone books, the goods are in inventory at $60. In the consolidated statements, the goods should be in inventory at $40 (the group’s actual cost) — Entity A’s margin shouldn’t be recognized until the goods are sold to a third party outside the group. If the intercompany profit in inventory isn’t eliminated, consolidated inventory is overstated by $20 per unit of intercompany-sourced goods still in Entity B’s warehouse, and consolidated gross margin is prematurely inflated by the same amount.
Fix: Calculate the intercompany profit in inventory at each period close — units of intercompany-sourced goods in Entity B’s ending inventory multiplied by the per-unit intercompany margin. Post an elimination journal entry in the consolidation entity to reduce consolidated inventory and eliminate the corresponding intercompany revenue. Track this elimination separately from the standard AR/AP elimination so it can be reversed and recalculated each period as inventory levels change.

⚠️ Currency Translation Adjustment Flowing to P&L Instead of OCI — Distorting Consolidated Income

The consolidation entity’s translation adjustment account is mapped to a P&L account rather than Other Comprehensive Income. Every period, the foreign exchange impact of translating subsidiary balances into the group reporting currency runs through consolidated income — adding noise to the income statement that has nothing to do with operational performance and everything to do with exchange rate movements. Leadership asks why consolidated net income fluctuates when the business is performing consistently. The answer involves explaining that $800K of “income” this quarter is a translation mathematics artifact, not operating performance — a conversation nobody wants to have after the financials have been distributed.
Fix: Before running the first consolidation, confirm that the translation adjustment GL account is designated as an OCI account in the consolidation entity’s chart of accounts. Verify the mapping in the consolidation setup under General Ledger → Setup → Consolidation → Translation accounts. Run a test consolidation in a sandbox entity and confirm that the translation adjustment posts to OCI — not to retained earnings, not to the income statement. This is a setup verification step, not an assumption.

Do This / Don’t Do This

✓ Do This

Configure the intercompany framework before any intercompany transaction needs to process
Define intercompany accounts (Due-To / Due-From) in a Finance-owned document, by entity pair
Involve Tax in transfer pricing policy before configuring intercompany prices in D365
Review transfer pricing annually and update documentation when cost structure changes
Require written confirmation from each entity controller that periods are closed before consolidation runs
Run the Intercompany Accounting reconciliation report at every period close before consolidation import
Calculate and eliminate intercompany profit in inventory at each period close
Verify translation adjustment routes to OCI, not P&L, before first live consolidation
Build elimination journal templates — do not rebuild from scratch each period
Maintain a consolidation checklist of every required elimination by entity pair and transaction type

✗ Don’t Do This

Skip the IC framework because it seemed complex — manual IC journals without consistent account mapping produce unsolvable reconciliation problems
Set intercompany prices without tax counsel involvement
Let transfer pricing documentation age without annual review
Run consolidation with any entity’s period still open
Ignore the intercompany reconciliation report between period close and consolidation
Skip the intercompany profit in inventory elimination — it overstates consolidated inventory and income
Accept the default translation adjustment account mapping without verifying it routes to OCI
Process intercompany adjustments as manual GL journals without a consistent account procedure

Up Next:

Intercompany covers the multi-entity layer — how D365 connects legal entities in the same instance. Next we’re going into cost accounting at the operational level: Cost Accounting and Cost Management in D365 F&O — the Cost Accounting module, cost objects, cost allocation hierarchies, overhead calculation, and how D365’s dedicated cost accounting layer produces management P&L reporting that the GL alone can’t deliver. For Finance teams who need allocation-adjusted profitability analysis by product line, department, or cost center beyond what financial dimensions provide.

Until then — confirm your IC accounts are consistent across every entity pair, run your intercompany reconciliation before consolidation, and get Tax involved in transfer pricing before the system is configured, not after the audit notice arrives.

— Bobbi

D365 Functional Architect · Recovering Controller