The Map Comes First

Part 4 of our nine-part Multi-Entity ERP series. Previously: You Don’t Need a New Company. You Need a New Column.

This problem arises in almost every multi-entity implementation. The team configures intercompany trade in one direction, feels good about it, and then discovers in later testing that the flow needs to run both ways. This isn’t carelessness. A process workshop wasn’t skipped. The team built the relationship they could see, and related-party flows have a way of hiding other flows that aren’t specifically stated.

The solution is not a better testing script. It is sketching out the whole related-party landscape and unlocking insights before setting up the system.

Volume of Trade Is a Variable

Not every group requires the same amount of intercompany setup, and assuming otherwise can waste effort. Closely integrated companies run reciprocal trade daily, such as transfer pricing, inventory in transit, and an elimination discipline to name a portion of “the works.” Diversified groups need a limited set such as just fees, allocations, cash sweeps, and the occasional dividend. Partnerships and joint ventures often need something else entirely, such as related-party treatment for transactions that leave your environment completely and land in a system you will never touch. This highlights the need to have a right-sized related-party trade infrastructure.

Naming Conventions Matter

Related-party flows are a short list. It genuinely benefits the entire team when you name each one explicitly, rather than labeling everything as simply “intercompany.”

• Goods and inventory that move between entities
• Services and charges, one entity billing another for work performed
• Cash paid on behalf of another entity, then settled later
• Royalties and cost sharing
• Dividends and guarantees

Most groups will not need all five flows. Every group must know which ones apply to their companies and map them accordingly.

Consider Boundary Challenges

Most ERPs automate intercompany beautifully between companies that operate in the same environment. However, these same systems often forget to support intercompany flows outside their boundaries. A related party operating outside will still need a customer or vendor record, a functioning consolidation mechanism, and someone accountable for keeping the two sets of books from silently drifting apart. Automation may stop at the environment boundary, but accounting cannot and does not.

Direction Is Important

Direction creates the most common challenge. Many platforms require an explicit trading relationship definition in both directions, not just one. This is fine when both sides originate transactions; both directions need to be designed, tested, and entries understood by accounting. Model a relationship as reciprocal only when both sides genuinely originate transactions and never force reciprocity onto a one-way flow just to make the setup feel complete. Doing so leaves the possibility that transactions pass through a door nobody intended to leave open.

Establish Distinct Elimination Targets

Related-party account balances recorded in the same accounts as other entity transactions are grueling to eliminate at close, because it is unclear what needs to net out and what does not. Dedicated due-to and due-from accounts with a company ID are a must-have, along with related-party revenue and cost accounts. Unique accounts turn eliminations from an investigation into a clear process. This is a small design decision with a huge impact on how easy your close is every single period following go-live.

Map the Flows That Do Not Exist Yet

If you have been following this series, you already know acquisitions and joint ventures create new related-party pairs the moment the legal agreement commences. In some cases, flows that never existed anywhere in the group are now required. It’s worth mapping those pairs anyway, even in rough form, before the deal is real. It is far easier to sketch “this new entity will likely need a management fee flow and a cash sweep” in a planning session than to uncover it during the first month of ownership, when the team is trying to figure out whether the new company’s system can even talk to yours.

The Map Is an Artifact

The completed related-party flow map is another implementation inventory to keep in your toolkit. The flow should detail what kind of flow it is, which company originates it, which direction it travels, and whether it lives inside or outside your instance, along with all accounts or account classes included. This verifies how your group operates and is a solid gold asset. Keep it current as entities are added or unwound, and the multi-entity problem list gets a lot shorter.

None of the intercompany activity reports cleanly, though, without one more thing in place. A chart of accounts that every entity can genuinely use is a must-have. This chart is tasked with telling two different stories, one for the auditor and one for the board. That is the next article.

Start your map with our free Related-Party Flow Inventory, which captures each flow’s type, originating company, direction, and whether it lives inside or outside your instance. Download the Related-Party Flow Inventory.