Intercompany Transaction Automation

The problem

A group running fifteen legal entities in one Dynamics 365 Finance & Operations tenant should get intercompany accounting almost for free. In practice, month-end says otherwise. Shared costs are allocated by hand: someone builds a spreadsheet, splits the invoice across entities, and keys a journal in each company. Recharges follow the same route. Native intercompany accounting handles the paired journal well when the transaction fits its shape, but it does not allocate, it does not schedule, and it does not tell you at 9am on the fourth working day which of your due to and due from balances no longer agree.

So the group builds a reconciliation workbook. It pulls trial balances from every entity, pivots the intercompany accounts, and produces a variance list that someone then investigates transaction by transaction. The causes are always the same handful — a journal posted in one company and not the other, a currency revaluation applied on one side, a reversal that only reversed once, a posting to the wrong counterparty entity — but finding them consumes days that the close does not have. Centralised payments make it worse: entity A pays a vendor invoice belonging to entity B, and the resulting intercompany position has to be tracked and settled separately.

What ECOSIRE builds

ECOSIRE builds an intercompany automation and reconciliation extension for Dynamics 365 Finance and Supply Chain Management, written in X++ as an extension model with no overlayering.

Allocation and recharge templates

You define reusable intercompany templates: a source (a main account range, a ledger dimension combination, a cost centre, a project, or a specific vendor invoice pattern), a set of destination legal entities, and an allocation basis — fixed percentage, fixed amount, or a driver such as headcount, revenue or a statistical measure held in a dimension. A template also carries the accounts and financial dimensions to use on both the due to and the due from side, the description convention, and the approval requirement.

When a source transaction posts, or when a scheduled run executes, the engine builds the paired journals for every destination entity. Because it uses the standard ledger journal framework and the intercompany accounting setup, everything downstream — posting profiles, financial dimension defaulting, ledger dimension validation, subledger journal entries, financial reporting — behaves natively.

Scheduled and event-driven runs

Recurring recharges run as SysOperation batch jobs on your own recurrence: monthly management fees, shared service allocations, IT cost splits. Event-driven allocations are triggered by posting events on the source document through event handlers, so a shared cost is pushed out the moment the originating invoice posts rather than at period end. Every run produces a proposal that can be reviewed and adjusted before posting, or posted automatically where you have decided the rule is safe to trust.

Approval and control

Proposals route through the standard Dynamics 365 workflow framework, so intercompany postings above a threshold need a named approver, with the delegation, escalation and work item behaviour your organisation already uses. Segregation is respected: the approver in the destination entity can be required to accept a charge before it posts in their books, which is usually the political blocker to automating intercompany at all.

Due to / due from reconciliation

A reconciliation workspace matches intercompany balances pair by pair across legal entities, in transaction currency and in accounting currency, and shows the difference with the underlying transactions behind it. Matching is automatic where the engine created both sides — every generated pair carries a shared reference so the match is deterministic rather than heuristic. For transactions created outside the engine, matching runs on configurable criteria: amount, date window, counterparty entity, document reference and dimension values. Unmatched items are aged and assigned, so the exception list is a work queue rather than a spreadsheet tab.

Elimination and centralised payments

Elimination journal proposals are generated from matched intercompany positions for use in your consolidation entity, using the standard elimination rule structures. For groups using centralised payments, the extension tracks vendor invoices paid by one entity on behalf of another, generates the corresponding intercompany positions, and supports periodic net settlement between entities so the group is not shuffling cash for every individual charge.

Reporting

Reconciliation status, ageing, unmatched items and run history are exposed as data entities over OData, so group finance can build the intercompany dashboard in Power BI rather than rebuilding the workbook each month.

Who it is for

Groups running multiple legal entities inside one Dynamics 365 Finance & Operations tenant where intercompany volume is high enough that manual journals hurt: shared service centres, holding structures with management recharges, multi-country groups allocating regional costs, and organisations that pay vendors centrally on behalf of subsidiaries. It suits finance teams whose close is delayed by intercompany investigation, and controllers who cannot currently answer how much is unmatched without building a report.

If you run two legal entities with a handful of intercompany journals a month, standard intercompany accounting will serve you and this is overspecified.

How delivery works

This is built for your group, not downloaded.

1. Scoping call. We map your entity structure, your intercompany account pairs, your existing allocation rules and spreadsheets, your currency handling, your approval expectations, and how your consolidation entity works. 2. Fixed quote. A written scope and a fixed price, with the build window stated. Nothing starts until you approve it. 3. Build. Typically one working week given the entity count and rule complexity involved. Development happens against your platform and application version in a dedicated model. 4. Install in test. Deployed into your sandbox via your LCS project. We configure your templates and account pairs, then run a parallel close against a real prior period so you can compare the engine's output line by line against what your team produced manually. 5. Production. After sign-off on the parallel run, the package goes to production through your release process. We attend the first live period close. 6. Support. A support window from go-live covers defects and questions, and typically spans at least the first month-end. Additional templates and rules are quoted as enhancements.

You receive the X++ source and the technical documentation, so your team owns it afterwards.