Intercompany Is the Blind Spot in Your D365 Regression Strategy
Multi-entity organisations test everything except the process most likely to break in the close. Here is why intercompany defeats most D365 test automation, and what actually covers it.
Ask a functional consultant which D365 Finance and Operations processes they trust their regression suite to catch, and you will hear a confident list. Order to cash. Procure to pay. Inventory. Month end journals. Then ask about intercompany, and the confidence usually drops. Most teams know their intercompany coverage is thin. Fewer can explain why it is so hard to fix. The honest answer is that intercompany is not one process. It is two mechanisms that interact across a boundary that most test tooling was never built to cross, and it tends to surface late, in the close, when there is no time left to investigate.
Two mechanisms that people treat as one
The first source of trouble is conceptual. In D365 Finance and Operations, intercompany is handled by two separate systems that are easy to conflate. Intercompany trade runs through sales orders and purchase orders: raise an intercompany purchase order in one legal entity and the system generates the matching intercompany sales order in the other, then keeps the confirmation, packing slip, and invoice in step across both. Intercompany accounting is a different animal entirely. It creates the ledger side, the Due to and Due from postings, and it drives daily journals, vendor invoice journals, ledger allocations, and centralised payments made on behalf of subsidiaries.
A single business event touches both. A sale that originates in one entity and fulfils from another moves goods and documents through the trade mechanism and settles through the accounting mechanism, often in more than one currency. If your test only asserts that the order posted, you have validated a fraction of what actually happened. The parts you did not check are exactly the parts that drift after an update.
The assertion has to cross the entity boundary
This is the structural problem, and it is where most automation quietly gives up. A meaningful intercompany test is not a statement about one company. It is a statement about two or more at once. Did the intercompany sales order generate in the destination entity with the correct pricing. Did the Due from post in the originating entity and the Due to post in the destination entity, to the right main accounts, with the trading partner dimension set. Do the two sides reconcile. Answering that requires a test that can sign in to one legal entity, act, then move to another and verify, then compare the results across both.
Record and replay tooling, RSAT included, operates comfortably inside a single company context. It can prove that a step ran. It struggles to make an assertion that spans legal entities, because the recording was captured in one company and the verification lives in another. So teams end up testing each entity in isolation and assuming the join between them holds. The join is precisely what breaks.
The gotchas that make coverage directional
Intercompany also carries setup asymmetries that a naive test will miss. Relationships are directional: configuring Company A to transact with Company B does not permit Company B to originate transactions back to A. That reciprocal setup is a common go-live defect and an even more common regression, because a configuration change in one release can quietly disturb one direction while leaving the other intact. Coverage therefore has to be directional too. Testing A to B is not testing B to A.
Layer on the details that decide whether the postings are actually correct. Unique Due to and Due from main accounts per company, which Microsoft recommends specifically to keep reconciliation and elimination clean at consolidation. Trading partner dimensions carried as fixed dimensions. Multiple accounting currencies across entities, with the exchange treatment that implies. Each of these is a place where a Wave release can shift a default, and none of them is visible from a single company vantage point.
Why it stays untested
Intercompany is under-tested for reasons that have nothing to do with whether teams understand it. Setting up the test itself is hard. A realistic intercompany scenario needs coordinated master data and open documents in more than one entity at the same time, so the data preparation alone deters people. And the process is rarely exercised in daily transactions the way order to cash is. It concentrates around period end, allocations, and settlement, which means when something is wrong, it is discovered during the close, under deadline, by the senior finance people who can least afford to spend a day tracing a Due to that did not match its Due from.
That timing is the trap. D365 ships several updates a year, two of them major. A change lands, the standard smoke tests pass, the release goes through, and the intercompany fault sits dormant until the next close weeks later. By then the update is long accepted and the investigation starts from cold. This is the pattern behind most abandoned D365 test suites: not that the tests were wrong, but that the hardest, highest-consequence process was the one nobody managed to cover, so the suite never earned trust where it mattered most.
Construction versus assembly
The reason intercompany defeats teams is the same reason most D365 testing stalls. We treat every test as something to construct from scratch. For a single-company process that is merely slow. For a cross-entity chain it is close to impractical, because the person authoring it has to choreograph the whole sequence by hand: create in one entity, verify generation in the second, progress the documents on both sides, then assert the ledger reconciles across the pair. Very few teams have the time or the automation skill to build that, so they do not, and the blind spot persists.
The shift that changes the economics is to stop constructing and start assembling. The intercompany choreography is not unique to any one client. The chain of order, generation, confirmation, receipt, invoice, and reconciliation follows the same logic in almost every multi-entity deployment. If those journeys already exist as pre-built assets, the consultant is no longer writing cross-entity automation. They are selecting the intercompany journey that matches their scenario, configuring it to their legal entity pairs, their currencies, and their account structure, and automating from there. The expertise that matters, which is knowing how the entities are meant to behave, becomes the whole job. The plumbing is already done.
What that looks like in practice
Virtuoso QA's Composable Asset System for D365 is built on this principle. It provides 1,000+ pre-built D365 test journeys across Finance, Supply Chain Management, Commerce, Customer Engagement, Business Central, Human Resources, and Project Operations, including the multi-entity flows that teams most often leave uncovered. Because the journeys assert outcomes rather than replay a single recording, they can validate both sides of an intercompany chain and confirm that the trade documents and the Due to and Due from postings agree. Consultants configure them to their own entity structure in natural language that reads the way they already describe the process, so coverage of the hardest area in F&O becomes a matter of days rather than a project nobody has budget for.
The wider point holds beyond intercompany. Any process whose correctness only reveals itself across a boundary, between entities, between currencies, between the trade layer and the ledger, is exactly the process that construction-based testing leaves exposed and assembly-based testing covers first. Intercompany is simply the clearest case, because it is the one your close depends on and the one your current suite is most likely to be missing.
See the intercompany and multi-entity journeys in the D365 Composable Library, and how consultants configure them to their own legal entity structure, at virtuosoqa.com/solutions/composable-library-dynamics-365.