D365 Multi-Entity Testing: Automating Intercompany Transactions across Legal Entities

Most D365 Finance testing conversations start with journals, period close, and AP workflows. These are the right places to start, high-frequency, high-stakes processes that break in predictable ways. But for organizations running D365 across multiple legal entities, there is a testing problem that sits above all of those in both complexity and consequence: intercompany transactions.

An intercompany failure is not a module failure. It is a group-level financial reporting failure. When Entity A posts an intercompany sale that Entity B never receives, the consolidated financial statements carry both the revenue and the unexpired liability simultaneously. When an elimination entry is missed at consolidation, intercompany profit is double-counted at group level. These are not test suite gaps that surface as application errors, they surface as audit findings.

And yet, D365 intercompany testing remains one of the most under-automated areas of enterprise ERP quality assurance. The reason is structural: traditional test automation tools operate within a single legal entity. They can confirm that a transaction posted correctly in one entity, but they have no ability to verify whether the matching transaction exists in the other, whether the financial dimensions align, or whether the consolidation will balance.

This guide covers the D365 intercompany models that need testing, the failure patterns that slip through manual testing most consistently, how elimination entries work and why they are the hardest scenario to automate, and what automated D365 multi-entity testing actually looks like with an AI agent that understands the process across entity boundaries.

For context on how multi-entity testing fits within the broader D365 Finance testing landscape, the D365 Finance testing guide covers journal posting, period close, and compliance automation. And the complete guide to Dynamics 365 test automation maps how Finance, Supply Chain, and Sales agents work together across the full D365 estate.

1. Why Multi-Entity Testing Is a Different Problem from Single-Entity D365 Testing

Single-entity D365 Finance testing is already complex. Posting profiles, financial dimensions, tax codes, approval hierarchies, and the configuration surface is vast and the compliance stakes are high. But the test remains contained: you are validating that a transaction within one legal entity produced the correct financial outcome within that entity.

Multi-entity testing introduces a fundamentally different challenge: the correctness of the transaction cannot be assessed by looking at one entity alone. An intercompany sales transaction is only correct if:

• Entity A (selling) has posted a sale with the correct revenue account, VAT treatment, and financial dimensions
• Entity B (buying) has posted a matching purchase with the correct cost account and financial dimensions
• The intercompany receivable in Entity A and the intercompany payable in Entity B balance
• Both entries are in the same period, or the period mismatch is intentional and documented
• The elimination entry that removes both the intercompany revenue and cost at consolidation is generated correctly

Every single one of those conditions requires data from at least two legal entities to verify. No task recording, no RSAT script, no single-entity test automation approach can cover this. RSAT has limitation and it operates within one D365 environment context. RPA bots navigate one screen at a time. Neither has the cross-entity data model awareness needed to validate an intercompany transaction end to end.

“An intercompany transaction is only correct when both sides balance and the elimination entry nets to zero. Testing one side and calling it done is not testing intercompany, it’s testing half a transaction.”

2. D365 Intercompany Models: How Transactions Flow Between Legal Entities

Before building a D365 multi-entity testing strategy, it helps to map the intercompany models your organization actually uses. Each model has a different transaction structure, a different set of accounts involved, and a different elimination requirement at consolidation.

Intercompany Model	How it works in D365	What must validate across both entities
Intercompany Trade	Entity A sells goods/services to Entity B in same group	SD→FI (Entity A) + MM→FI (Entity B) + elimination at consolidation
Shared Services	Central entity provides HR, IT, finance services to all entities	Cost allocation posting in each entity + reciprocal revenue/expense
Cross-Entity Loans	Entity A lends capital to Entity B	Interest accrual in both entities + unrealized gain/loss on FX loans
Cross-Entity Inventory	Transfer of stock between legal entities at transfer price	Inventory valuation in source + destination + profit-in-stock elimination
Management Charges	Holding company charges management fees to subsidiaries	Revenue in parent entity + expense in subsidiaries + tax jurisdiction implications

Most enterprise D365 environments run several of these models simultaneously. A holding company structure might involve shared services cost allocations, management fee billing, cross-entity loans, and intercompany inventory transfers all running in the same reporting period, each requiring a different set of validations and a different elimination treatment.

The testing implication: there is no single intercompany test scenario that covers all models. Each model requires its own validation logic, its own expected posting structure, and its own elimination check. Building a comprehensive D365 intercompany testing suite means mapping every model in use and building specific agent scenarios for each one.

3. The Most Common Multi-Entity Failures, and Why They Slip Through Manual Testing

Multi-entity failures share a common characteristic: they pass every entity-level test while failing at the group level. Each individual transaction looks correct when inspected in isolation. The problem is only visible when you look at both sides simultaneously, and most testing approaches never do that.

Failure type	What happens	Risk level
Imbalanced intercompany posting	Entity A posts sale correctly; Entity B never receives the matching purchase. Consolidation imbalance. Surfaced at audit, not during testing.	Significant risk, inflates both revenue and expenses in consolidated P&L
Elimination entry missing	The intercompany profit is not eliminated on consolidation. Revenue is double-counted at group level.	High, directly affects consolidated financial statements
Currency mismatch at settlement	Entity A bills in USD; Entity B books in GBP. Exchange rate applied at different dates creates an unrealized gain/loss that isn’t captured correctly.	Medium-high, affects group FX position reporting
Transfer pricing outside agreed range	Intercompany goods transferred at a price outside the agreed transfer pricing range. Tax authority challenge risk.	High, tax compliance and audit exposure
Posting period mismatch	Entity A posts the sale in December (Period 12); Entity B posts the purchase in January (Period 1 of next year). Group trial balance doesn’t close cleanly.	High, period-end close failure, financial restatement risk
Financial dimension inconsistency	Cost centre or project dimension on Entity A’s posting doesn’t match the expected mapping in Entity B. Management reporting distorted.	Medium, affects management accounts and cost attribution

The posting period mismatch failure is worth highlighting specifically, because it is the one that causes the most damage at year-end close. An intercompany sale posted on December 31st and the corresponding purchase posted on January 2nd means the selling entity closes Period 12 with a receivable that has no matching payable in the buying entity’s Period 12. The period closes. The imbalance carries forward. The auditors find it three weeks later.

Manual testing does not catch this because the test for the selling entity passes (sale posted correctly) and the test for the buying entity passes (purchase posted correctly). Nobody is running a test that simultaneously checks whether both transactions are in the same period and whether the group balance is clean. That is exactly what automated D365 multi-entity testing with AI agents provides.

4. Elimination Entries: The Hardest Thing to Test and the Most Dangerous Thing to Miss

Elimination entries are the mechanism by which intercompany transactions are removed from the consolidated financial statements. When Entity A sells to Entity B, the sale appears as revenue in Entity A’s standalone accounts and as a cost in Entity B’s standalone accounts. At the group level, these two entries cancel each other out, if they didn’t, the consolidated P&L would include revenue and cost that are purely internal to the group and have no economic substance.

Getting elimination testing right requires understanding three distinct scenarios that each work differently:

Revenue and cost elimination

The most common elimination: intercompany sales revenue in the selling entity is matched against intercompany cost of sales in the buying entity. Both are eliminated at consolidation. The test needs to confirm that the elimination entry has been generated at the correct amount, in the correct accounts, and that the post-elimination consolidated P&L no longer contains any intercompany balance.

Profit-in-stock elimination

When goods are transferred between entities at a transfer price that includes a profit margin, and those goods are still in inventory at period end, the unrealised profit must be eliminated. This is one of the most technically complex intercompany elimination scenarios because the calculation depends on the closing inventory balance in the buying entity, which is only known at period end, and on the gross margin embedded in the transfer price.

Manual testing almost never covers profit-in-stock elimination because it requires real-time inventory data from the buying entity and the transfer pricing margin to calculate the correct elimination amount. An AI agent that understands the inventory data model in D365 can pull the closing inventory balance and apply the margin automatically.

Intercompany loan elimination

A loan from Entity A to Entity B creates a financial asset in Entity A’s balance sheet and a financial liability in Entity B’s. At consolidation, both must eliminate to zero. If the loan is in a foreign currency, the exchange rate applied must be consistent between entities, a mismatch creates a group-level FX imbalance that affects consolidated equity.

Elimination testing is the scenario most likely to generate an external audit finding, and the scenario least likely to be covered by automated testing in most D365 environments. The gap is not because teams don’t know it matters. It’s because single-entity tools cannot run it.

5. How Sofy Validates Both Sides of Every Intercompany Transaction in One Agent Run

The architectural difference between Sofy’s Finance Agent and single-entity test tools is not one of configuration, it is one of data model understanding. Sofy’s agent does not operate within one legal entity context and then switch to another. It understands the group structure, the intercompany relationships between entities, and the expected posting behaviour at both ends of every intercompany transaction before the test begins.

What a Sofy intercompany test run looks like in practice:

1. Step 1, Process mapping: The agent maps the intercompany relationship being tested, which entities are involved, which intercompany model applies, and what the expected posting structure is on both sides.
2. Step 2, Selling entity validation: The agent triggers the intercompany transaction in the selling entity (Entity A) and validates the posting, revenue account, financial dimensions, VAT, posting period.
3. Step 3, Buying entity validation: Without switching environments or requiring a second test script, the agent validates the matching transaction in the buying entity (Entity B), purchase account, financial dimensions, and matching period.
4. Step 4, Balance confirmation: The agent validates the intercompany receivable (Entity A) and payable (Entity B) against each other, confirming they match in amount, currency, and period.
5. Step 5, Elimination check: If consolidation is in scope, the agent validates that the elimination entry has been generated at the correct amount and in the correct accounts, and that the post-elimination consolidated balance is clean.

Each step produces a field-level assertion log, not a pass/fail status, but the specific data values checked and their expected vs. actual results. For multi-entity Finance testing, this distinction matters as much as it does for single-entity journal testing: a green checkmark does not tell a controller or an auditor which accounts were used, which period the entries landed in, or whether the elimination ran at the right amount.

For a deeper look at what field-level financial assertion logs look like and why they matter for compliance, the D365 Finance testing guide covers this in the context of journals, period close, and the evidence-vs-confidence distinction that auditors care about.

6. D365 Multi-Entity Testing Checklist: 6 Scenarios to Automate Before Every Wave

Building a D365 multi-entity test suite incrementally is the most practical path. Start with the scenarios that carry the highest consolidation risk, the ones that cause audit findings, and expand from there.

#	Scenario	What to validate	Priority
1	Intercompany sales transaction (both sides)	Posting in selling entity + matching purchase in buying entity + intercompany payable/receivable balance	High
2	Elimination entry at consolidation	Intercompany revenue and COGS eliminated at group level, no double-counting in consolidated P&L	High
3	Intercompany profit-in-stock elimination	Unrealized profit on intercompany inventory transfers eliminated before period close	High
4	Foreign currency intercompany settlement	Exchange rate applied consistently at both entities, unrealized gain/loss captured correctly	High
5	Shared services cost allocation	Cost allocation posted in each subsidiary + reciprocal revenue in shared services entity	Med
6	Management fee billing cycle	Monthly management charge raised, posted, and matched across parent and subsidiary entities	Med

A note on sequencing: scenarios 1 and 2 form the core intercompany validation pair and should always be automated together. A test that validates the intercompany sale (scenario 1) without validating the elimination (scenario 2) is incomplete, the sale could be correct while the elimination fails, and the consolidated P&L would still be wrong.

Scenarios 3–6 can be added incrementally over successive release wave cycles. By the third wave, most teams have full coverage of their active intercompany models with minimal ongoing maintenance, because Sofy’s Finance Agent self-heals on UI changes without requiring test suite rebuilding.

The broader D365 test automation strategy, how multi-entity Finance testing integrates with Supply Chain, Sales, and cross-module workflows, is covered in Sofy’s complete guide to Dynamics 365 test automation. For the full ERP testing picture across SAP and D365 environments, the ERP test agents hub maps how module-specific agents work together across a multi-platform ERP estate.

Frequently Asked Questions