Consider a finance leader overseeing two or three operating companies under common ownership. Each entity has its own bank accounts, its own vendor relationships, and its own reporting obligations. A platform chosen for a single company may handle each entity separately in isolation. Then the ownership group identifies an acquisition target, and the question shifts. It is no longer whether the platform works today. It is whether the platform can carry the organization through what comes next: more legal entities, more transactions flowing between them, and a board that wants a single consolidated view of the whole group at period end.<\/p>\n
The evaluation question is whether the next platform can absorb further acquisitions and higher transaction volume without forcing a complete redesign of the finance process. That is not a crisis. It is a reasonable evaluation question, and it deserves a substantive answer.<\/p>\n
Multi-entity accounting is not simply running the same books twice. Each legal entity needs its own general ledger accounts, its own fiscal calendar, its own posting periods, and its own statutory records for tax and compliance purposes. When Entity A provides services to Entity B, both entities record that transaction correctly from their own perspective. Entity A books revenue; Entity B books an expense. Those entries are accurate for each entity’s standalone financials.<\/p>\n
The problem surfaces at the group level. If you add up each entity’s revenue and expense without adjustment, the internal charge appears twice: once as income and once as cost. The consolidated income statement overstates both revenue and expense, and the balance sheet shows receivables and payables that the group effectively owes to itself. Where the accounting platform does not consolidate across entities, that adjustment work has to be done outside it, which adds steps at period end and makes the group view harder to review and support.<\/p>\n
High transaction volume adds a separate layer of friction. When an acquisition closes, finance has to decide how the new entity’s balances and history are brought into the group’s reporting, and how long the group waits for a complete consolidated view. Where operational volume simply increases, the ability to load accounting data in bulk becomes practical. Entering transactions one at a time can become impractical at volume, and that constraint is felt most sharply when a new entity joins the group mid-year.<\/p>\n
The consequences of an undersized platform are not always dramatic. More often they are cumulative. Where consolidation is assembled outside the system, each close carries that extra assembly and review work. Where intercompany balance reconciliation happens in a spreadsheet, management reporting waits on it.<\/p>\n
For a group planning further acquisitions, the platform question is also a capacity question. A finance team that spends significant time on manual consolidation workarounds has less capacity to support due diligence, integration planning, and the reporting that lenders and boards expect during a period of active growth. The cost of leaving the platform question unresolved is not a single event. It is the accumulated overhead of every period close and every new entity added under a process that was not designed for the structure.<\/p>\n
Before evaluating any specific system, it helps to be clear about what the accounting platform actually needs to support. Four capabilities are material to this evaluation.<\/p>\n
First, the platform must maintain genuinely separate books for each legal entity, with independent general ledger accounts, fiscal calendars, posting periods, and access controls. Entities should be able to operate independently without one entity’s activity affecting another’s records.<\/p>\n
Second, the platform must produce consolidated group financials that combine all entities into a single view, converted to a common reporting currency where entities operate in different currencies.<\/p>\n
Third, the platform must support inter-entity transactions: when one entity invoices another, both sides of the transaction are recorded correctly and the intercompany activity can be identified and removed from consolidated statements through elimination entries.<\/p>\n
Fourth, the platform must support bulk import of accounting transactions, so that high-volume periods and entity onboarding do not require manual entry of every line.<\/p>\n
One important distinction belongs in any honest evaluation: elimination journals are a finance team responsibility, not an automatic system function. The platform should make it straightforward to prepare and post the elimination entries, but the judgment about what to eliminate and when to post it remains with the controller or accountant.<\/p>\n
Versa is an established cloud ERP configured to support multi-entity operations as a standard part of its accounting platform.<\/p>\n
Each legal entity in Versa maintains its own books: its own general ledger accounts, its own fiscal calendar, and its own posting periods. Permissions control which entity a user works in and which accounting actions they can take, so users who work in one operating company do not need access to the consolidation entity unless they help with the group close.<\/p>\n
Consolidated financial reporting in Versa combines all entities marked for consolidation into a single group view. A consolidating currency is set at the firm level, and each entity’s balances are converted into that currency before the consolidated totals are calculated. A group with entities operating in different currencies can produce a single consolidated income statement and balance sheet in the group’s reporting currency.<\/p>\n
Inter-entity transactions are supported as an available add-on that a firm administrator enables. When that feature is active, Versa can be configured so that an invoice in the selling entity automatically creates a corresponding bill in the buying entity, keeping both sides of the transaction in the system without duplicate manual entry. For consolidation, Versa supports a dedicated elimination entity where the finance team posts the journal entries that remove intercompany revenue, expense, and balance sheet amounts from the consolidated view. Versa prepares draft elimination journals that finance reviews and posts; the consolidated financial reports then reflect the adjusted group position. Versa does not post these journals automatically.<\/p>\n
For bulk transaction loading, Versa supports CSV import of accounting transactions, including a full import format that allows transactions to be directed to specific entities within the same file. This is relevant both for high-volume operational periods and for loading accounting transactions in bulk when a newly acquired entity joins the group.<\/p>\n
Versa can also be implemented as the multi-entity system of record while allowing selective integrations with other operational systems where a full replacement is not preferred. The scope, method, and effort of any specific integration with a specialist operational system is something to confirm in the demonstration, rather than assume in advance.<\/p>\n
It is worth being direct about implementation: adding entities and configuring inter-entity workflows in any ERP requires deliberate setup. Versa’s multi-entity capabilities are established and configurable, but a group moving from a single-entity platform should expect a structured implementation process, not an instant switchover. The benefit is that the configuration work is done once, and each subsequent entity addition follows the same established pattern.<\/p>\n
Return to the finance leader from the opening. The acquisition has closed. The new entity is set up in Versa with its own books and its own access controls. The operations team in that entity posts their transactions independently. At period end, the finance leader works through the draft elimination journals in Versa, reviews the intercompany amounts, and posts the elimination entries in the consolidation entity.<\/p>\n
When the board asks for a group view, the finance leader pulls the consolidated report directly, without first reconciling a spreadsheet. When the next acquisition is identified, the question of whether the platform can handle another entity is already answered. And where existing operational systems are staying in place, the conversation about connecting them to Versa is a defined scope question, not an open-ended rebuild.<\/p>\n
If you are evaluating whether Versa fits your group’s structure, the most useful conversation is a walkthrough of a representative multi-entity scenario: how a second or third entity is set up, how an inter-entity transaction flows through both books, how the elimination process works at period end, and how the consolidated report reflects the result. That walkthrough answers the practical questions that a feature list cannot.<\/p>\n