If you have ever split one invoice across multiple companies, you already know that multi-entity accounting is not a rare edge case. It is normal work.
For many Dynamics GP teams, this shows up consistently in accounts payable, expense allocations, shared services, and at every month-end close. The organizations we work with range from holding companies with several subsidiaries to nonprofits managing multiple EINs to shared-services operations where one entity purchases on behalf of many. One senior services organization we know splits a single vendor order across 45 different centers, each operating as its own legal entity. For their accounting team, the vendor invoice split is not a special project. It is Tuesday.
When that workflow runs smoothly, close moves faster, and exceptions are easier to catch. When it does not, the team absorbs the cost in extra steps, extra logins, and extra cleanup every single month.
This article examines how Dynamics GP, Business Central, and Acumatica handle that work, using a scenario most finance teams will recognize.
The scenario
A vendor invoice comes in for a shared expense. The parent entity receives the bill. The cost needs to be distributed across multiple legal entities. The accounting team needs to allocate the expense correctly, generate the intercompany due-to and due-from entries, maintain a clean audit trail, and get to consolidated reporting at month-end without rebuilding the picture in a spreadsheet.
That is the job. The details vary, but the work’s shape is consistent across organizations.
For each platform, we are looking at how many steps it takes to complete one cross-entity transaction and how much switching between companies is required. We are also looking at how intercompany balancing entries are handled, what the audit trail looks like when someone needs to trace a transaction later, and what consolidated reporting actually requires at month-end.
How Dynamics GP handles it
GP has supported intercompany journal transactions for a long time, and many teams have run multi-entity workflows reliably on it for years. The capability is real. The friction is also real.
In a standard GP multi-entity environment, the workflow for that vendor invoice looks something like this. The AP team enters the invoice and allocates the amounts to the appropriate accounts and entities. Then they create the intercompany entries needed to balance across companies. To confirm that everything is posted correctly on both sides, the user physically logs out of one company and logs in to another. If the transaction touches five entities, that means five separate logins to verify five separate postings. If something goes wrong mid-process, a broken intercompany link or a batch that needs recovery, the cleanup happens across multiple databases rather than in one place.
Some addressed this by adding a third-party product that consolidated all companies into a single database and allowed users to switch between them without logging out.
Out of the box, GP can handle the work. It asks more of the team than the underlying transaction complexity requires.
One place this becomes visible is during an audit. When an auditor wants to trace an intercompany transaction in GP, the AP entry lives in one company’s database, and the due-from entry lives in another. Someone has to pull both and connect them manually. It is not a process failure. It does add time to something that is already time-sensitive.
What to expect in Business Central
Business Central is the default assumption for many GP customers considering a move. It is still Microsoft. For teams that have spent years in GP, it can feel like the logical next step.
For single-entity or simple two-entity environments, BC handles the work reasonably well. Where teams run into greater complexity is when cross-entity transactions are frequent, and the accounting team processes them repeatedly as part of normal AP and close work.
In standard Business Central, the multi-entity workflow involves what BC calls an Intercompany Inbox and Outbox. When a transaction needs to affect a second company, the user in Company A sends the intercompany document. A user in Company B then goes to the Intercompany Inbox, reviews what came in, and accepts it before it posts to Company B’s books. For a low-volume environment, this is manageable. For a team splitting vendor invoices across multiple entities on a daily basis, it adds a significant number of steps and requires someone on the receiving end to actively work through the inbox before the transaction is complete.
Consolidated reporting across entities is another area worth evaluating carefully before committing. BC’s standard toolset handles company-wide reporting well. For true cross-entity consolidated financials, most implementations end up bringing in additional configuration or a third-party solution. That is not a disqualifier, but it is a planning decision that should happen before go-live rather than after.
It is also worth noting that BC’s multi-entity capabilities are relatively recent additions to the product. Teams should verify that the specific workflows they rely on most are supported in the version and configuration they are evaluating, ideally by walking through their actual transaction scenario in a demo environment rather than making assumptions.
How Acumatica handles it
Acumatica’s approach to multi-entity work starts from a different architectural assumption. Companies and branches in Acumatica exist within the same database and the same tenant. They are not separate environments that need to communicate with each other. There are different views of a structure that already shares a foundation.
In practice, this changes how the AP invoice split works. The user enters one AP bill, allocates the expense lines to the appropriate branches or companies, and releases the document. Acumatica automatically generates the due-to and due-from entries based on the configured intercompany relationships. There is no inbox. There is no second user in another company who needs to accept the transaction. Both sides of the entry appear in the same document, are tied to the same reference number, and are visible in the same audit trail.
When an auditor needs to trace that transaction later, they click into the AP bill and see the full picture. The vendor liability, expense allocations, and intercompany balancing entries are all available without switching environments or pulling records from multiple databases.
Moving between entities in Acumatica is closer to filtering than switching systems. Users who need to work across companies do so without logging out and back in. The experience is closer to taking one hat off and putting another on than to closing one application and opening another.
Consolidated reporting is a standard output in a multi-entity Acumatica environment. Finance leadership can view results at the branch level, the company level, or rolled up across the full structure from the same system, without a separate tool or a manual assembly process.
One thing worth setting expectations on: getting to this level of automation requires upfront configuration work. The intercompany relationships, the due-to/due-from rules, and the chart of accounts structure all need to be set up correctly before the automation pays off. That investment is real. Once it is in place, the ongoing transaction overhead is substantially lower than what most GP teams are used to.
The same invoice, three ways
Here is how the vendor invoice split scenario plays out in each system at a practical level.
In GP, the AP team enters the invoice, allocates amounts, manually creates intercompany journal entries, and logs in and out of each company to confirm that postings landed correctly on both sides. Month-end reconciliation means verifying due-to and due-from balances across separate databases. The process works. The overhead is real and compounds as the entity count increases.
In Business Central, the AP team enters the invoice in Company A and initiates the intercompany transaction. The counterpart in Company B goes to the Intercompany Inbox, reviews the incoming document, and accepts it before it posts. If consolidated reporting is needed across all entities, it requires additional setup or tooling beyond standard BC. The workflow is functional, but it involves more handoffs than teams coming from GP typically anticipate.
In Acumatica, the AP team enters one bill, allocates the expense lines to the appropriate branches or companies, and releases it. The system generates the intercompany entries. No inbox. No second acceptance step. Consolidated reporting pulls from the same data without a rebuild. The user who processed the transaction can hand an auditor a single document that tells the full story.
What happens when you add a new entity
For a CFO considering an acquisition or a new operating entity down the road, this is worth a few minutes of evaluation now.
Adding a new entity in GP or BC typically involves setting up a new company environment, configuring accounts, establishing intercompany relationships, and, in BC, establishing inbox and outbox connections. It is a project.
In Acumatica, adding a branch to an existing multi-entity structure is a distinct task. Because the companies already share a database and a configuration foundation, the new entity inherits a significant amount of what is already in place. The intercompany rules extend to include it. Reporting rolls it up automatically once it is added to the right structure.
For organizations that are actively growing or expect to be, this difference compounds over time.
A real example
One of our clients, CD Management, recently completed a migration from GP to Acumatica involving 9 entities. Their accounting team had been managing intercompany transactions in GP for years, a process that worked but required consistent manual effort on every transaction that crossed entity lines.
Shortly after go-live, a staff member processed a multi-entity transaction that had previously taken 20 to 30 minutes of manual work each time it came up. After completing it in Acumatica, she looked up and asked: “Is that it?”
That moment captures the difference bigger than any feature comparison. The transaction was not simpler. The accounting behind it was identical. What changed was how much of the mechanical work the system handled versus how much the person had to manage manually.
We are working to obtain additional details and a direct quote from this client and will update this section once they are confirmed.
A question worth asking in any demo
If multi-entity transactions are a regular part of how your finance team operates, ask any vendor you are evaluating to walk through this exact scenario in a live demo.
Not a slide.
An actual transaction, one vendor invoice split across multiple entities, with the intercompany entries visible and the consolidated report pulled at the end.
The differences between systems tend to show up immediately when you watch them happen in real time.
Talk through your situation
Every multi-entity environment is a little different. If you are evaluating what comes next after GP and want to talk through how your specific structure would work in Acumatica ERP, we are happy to have that conversation.
