Your ERP handles intercompany. Ask who books the other side.

Ask how an ERP handles intercompany transactions and the answers that rank list the same parts: due to and due from accounts, entries paired across entities, a reconciliation, and an elimination at consolidation. All of that is correct, and none of it answers the question that decides how your month end goes. When one entity posts a charge to another, what makes the matching entry appear in the second entity's books, who has to act on it, and what do the two ledgers show in the meantime?

What the profiles say

Of the 55 systems Stackmark profiles, 9 carry a sourced line that names intercompany. Read field by field, those lines say that intercompany exists: that eliminations are automated, that intercompany transactions are built into the financials, that multi-entity and intercompany accounting come with a given edition. None of the 9 says how the receiving entity's side of a transaction is created, whether anyone there has to approve it, or how a disagreement between the two sides is caught.

The gap is not a quirk of the dataset. Product pages describe intercompany as an outcome. The help pages behind them show that the one word covers mechanisms that work quite differently, and the difference decides who does what at month end.

One word, three mechanisms

Oracle Fusion Cloud ERP and Dynamics 365 Business Central both handle intercompany by their own documentation. They make the other side in different ways.

• Balancing lines inside one ledger. In Oracle Fusion General Ledger, a journal that is out of balance by legal entity is balanced by intercompany balancing rules, which build the intercompany receivable and payable lines from account templates you set up. The lines are created as the journal is processed, and no one in the second entity has to act on them. Oracle's implementation guide also cautions that a balancing rule cannot be modified once created; it can only be end dated and replaced.
• An outbox and an inbox between companies. In Business Central, posting an intercompany journal or document puts a corresponding line in the sender's intercompany outbox, from which it is sent to the partner's inbox. The partner accepts, rejects or cancels it. Accepted lines become documents or journals in the partner company, which still have to be opened and posted. A rejected line goes back, and the sender has to post a correction to the original. Invoices cannot be sent until they are posted, and a sales invoice sent this way arrives as a purchase invoice. Partners in the same database can be set to accept automatically.
• Invoices on both sides. In Oracle's multitier intercompany operations, the transaction type on an intercompany agreement decides whether a transfer goes straight to the general ledger or is invoiced through Receivables and Payables. Release 26C added autoapproval of these transactions, but they still default to manual approval, and creating the intercompany Payables invoice remains manual by default.

Where the two ledgers disagree

Only the first mechanism books both sides in one step. In the other two there is a window in which one entity has posted and the other has not, because the line is sitting in an outbox, an inbox or an approval queue. Inside that window the amount one entity says it is owed has no matching amount owed in the other entity's books, and the difference is real until somebody acts on it. That is exactly what an intercompany reconciliation exists to find.

The window is not a defect. An entity with its own finance team may want to check a charge before it lands in its books, and some groups want an invoice on each side. The point is that the window exists in some designs and not in others, its length depends on people rather than software, and a demonstration that posts one entry and then opens a consolidated report skips straight over it.

Five tests for the demonstration

Ask each shortlisted vendor to run one charge between two of your entities, with a user from each entity signed in as themselves, and to answer these on screen.

• Post a management charge from the parent to a subsidiary. What appears in the subsidiary's books, at what moment, and did anyone in the subsidiary have to act?
• Have the subsidiary reject it. Where does it go, and what does the parent have to post to undo its side?
• Change the amount on the receiving side before it is accepted. Is that allowed, and what records the difference?
• Run the same charge between two entities that keep their books in different currencies. Which rate does each side use, and who chose it?
• At month end, show the report that lists intercompany items posted on one side and not yet on the other, by pair and by age.

The answers sort a shortlist quickly. A system that generates both sides at once has no window to manage, but its balancing rules carry the whole weight, so ask who maintains them and what happens when a new entity is added. A system with an inbox needs a named owner for that inbox in every entity, written into the close calendar. A vendor that cannot show the one sided report has told you how the reconciliation will be done: by hand, in a spreadsheet, at the end of the month.

To put the five tests to every shortlisted vendor in the same words, open the requirements builder, mark financial management as a must have, and paste the tests into the notes step. They travel with the Markdown, CSV and Excel exports, so each vendor runs the same charge.