By Hugh O. Stewart 

If you operate with a multi-entity structure using legacy accounting software designed for a single-entity structure, you lose a significant amount of time manually entering duplicate transactions between instances, performing difficult reconciliations and consolidations, and resolving the inevitable error correction that accompanies the exercise. Additionally, you’re likely doing a lot of reporting work in external spreadsheets. 

Switching to a multi-entity accounting platform like Sage Intacct can streamline your workflows and provide improved visibility into your revenue and expenses by entity and other dimensions.  

However, migrating historical accounting transactions from a single-entity system to a multi-entity system requires a careful data restructuring effort to ensure your historical data behaves properly in the new system. 

Platform Transition specializes in migrating historical accounting data from more than 80 legacy systems into Sage Intacct, and we have robust processes to support the transition from a single-entity setup to multi-entity. 

In this article, we’ll look at where single-entity legacy accounting systems fall short in multi-entity environments, how Sage Intacct overcomes those shortfalls, and how Platform Transition bridges the gap between single-entity and multi-entity environments during accounting data migrations.  

Legacy Systems Break Down When You Split Revenue and Expenses Across Entities 

Running multiple entities in a legacy system like QuickBooks pushes the software beyond what it was built to handle, and you run into big problems when you try to share revenue and expenses between entities.  

For example, let’s say that Entity A pays the phone bill for Entity A, Entity B, and Entity C. To properly record that expense, you need a way to indicate that the expense was split between three entities, and that Entity B and Entity C owe Entity A. In most legacy systems, you can reference multiple entities in a single transaction by using classes or account codes. What you can’t do is automatically generate the balancing inter-entity payables and receivables that keep each entity’s accounting records accurate.  

When you’re unable to accurately record shared expenses and shared revenue, it can make one entity look more profitable than it is. A common workaround is to produce consolidated reports that don’t break down the revenue or expenses by entity. While these consolidated reports are generally considered acceptable, they provide no insight into the overall performance of each entity.  

Sage Intacct Handles Multi-Entity Accounting Natively 

Sage Intacct was built with multi-entity environments in mind. This saves a lot of time and enables more detailed and more accurate reporting at every level.  

Inside Sage Intacct, individual accounts payable transactions can be allocated across multiple entities. This eliminates the need for an AP clerk to log in and out of separate entity instances to enter the same transaction from multiple perspectives. The system automatically generates the required due-to and due-from entries behind the scenes to keep each entity in balance. 

Platform Transition Bridges the Gap with Historical Balancing Transactions 

Migrating to Sage Intacct can solve the reporting challenges of a multi-entity accounting from your cutover date going forward, but if you want to run detailed period-over-period reports, you’ll need to migrate your historical transactions as well.  

And migrating historical accounting transactions that were entered into a single-entity system with a lot of workarounds presents some challenges. Fortunately, at Platform Transition, we have handled thousands of these migrations and have developed robust processes to handle these situations.  

Our data migration process restructures your historical data so it behaves as if it had originally been entered in Sage Intacct with proper intercompany balancing. We convert historical transactions and generate the appropriate balancing entries so that each entity’s books reflect what should have happened when the transaction was originally recorded due to Sage Intacct’s ability to historically record automatic due-to and due-from entries for transactions that incorrectly span multiple entities. 

To support continuity in your reporting for auditors and stakeholders, we also perform an Elimination Entity Migration. This recreates the consolidated reporting view that your leadership, auditors, and stakeholders are used to seeing from the legacy system, which validates the success of the migration. After the migration has been accepted, you can switch to reporting on entity-level financials.  

Legacy Systems Force Duplication of Master Data 

Multi-entity accounting requires a sophisticated master data structure that legacy accounting tools can’t support.  

If you’re running multiple instances of a legacy system to support multiple entities, you can’t share vendors or customers across them. Each entity maintains its own vendor list, customer list, item list, and chart of accounts. If the same vendor serves five entities, you have to create a separate vendor record for each entity. 

Some teams try to maintain order by assigning unique GL codes per entity or embedding entity identifiers directly into account numbers. Others build department or cost center information into the chart of accounts itself. Their chart of accounts might have six variations of “Deferred Revenue” because each department has its own version. 

This approach leads to an unwieldy chart of accounts. Plus, if you want to track your total expenses with one vendor across all entities, you have to manually consolidate the vendor balances from each entity in Excel.  

Sage Intacct Simplifies Master Data Management  

Sage Intacct offers much-needed flexibility around master data management. You can create shared vendors, customers, employees, and GL accounts at the Top Level and make them available across selected entities. If you want to see your combined spending with a particular vendor across multiple entities, you can run a report right from Sage Intacct. However, if you want to keep vendor records separate by entity, you can also enter them at the Entity Level. 

You can also simplify your chart of accounts in Sage Intacct. Instead of embedding department or cost center information into your GL account numbers, you can track revenue and expenses by department or location by using dimensions such as Class or Department. With this approach, one deferred revenue account can replace six and still offer the same granular insights. 

Platform Transition Supports Multi-Entity Conversions with Robust Data Mapping 

Your implementation team will configure Sage Intacct to handle the master data structures you need. But if you’re migrating historical transaction data from a legacy system into Sage Intacct, you get to systematically map all of your old master data structures to the new structures in Sage Intacct. 

At Platform Transition, we support that effort during our data mapping step. During mapping, you can merge obsolete accounts, eliminate unnecessary segments, and simplify structures that only existed to compensate for the limitations of your legacy software. 

We also address duplicate vendors, customers, and items through our process called The Duplicate Suppression System^™. Duplicate master data is common in multi-entity environments, especially when entities operated in separate files. Our unique process analyzes extracted transactional data and compares names, addresses, Tax IDs, and other attributes to identify likely duplicates before anything is loaded into Sage Intacct. 

By the time your data enters Sage Intacct, your master lists are unified, standardized, and ready to support shared workflows across entities. 

Manual Multi-Currency Consolidations Are Risky and Time Consuming 

Multi-currency consolidations require the ability to handle fluctuating exchange rates, variable accounting rules per jurisdiction, and resolve rounding errors. Legacy systems simply can’t handle these complex processes well, so multi-currency consolidations often have to be done manually in spreadsheets. In addition to being a significant time suck, teams also have to worry about version control and data entry errors. 

Sage Intacct Automates Currency Translation for Consolidations 

Sage Intacct’s Global Consolidation module automatically handles currency conversions, inter-entity transactions, local tax reporting, and more. You can generate reports in the currency that best suits your needs, and it will use automatically computed live exchange rates from the currency library OANDA to perform the conversions.  

Platform Transition Offers Three Options for Multi-Currency Migrations  

If you operate multiple entities within multiple currencies, you have to choose one of three options for handling currency conversions when migrating your historical financial data.  

Option 1: Migrate All Transactions in the Base Translated Currency 

The simplest and cheapest option is to use the base-currency translated results provided by the standard reports in your legacy system. Let’s say you’ve done business in five currencies, but for your migration, you leverage the fact that your legacy system’s base currency reports all settled transactions in USD. You proceed as if the transactions had always happened in USD, except that your legacy system will add a single foreign exchange transaction to resolve all variances for each affected transaction.  

The benefits of this method are that you avoid rounding errors in your consolidated reports. The downside is that you lose visibility into local currency transaction details for each transaction. That visibility can often be very helpful. For example, if you want to lock in a particular exchange rate by buying currency futures contracts, you may need to know how much business you have done in a particular currency over the last few years to know how to design your contract purchase.  

Option 2: Migrate Transactions Using Actual Conversion Rates   

If you choose to keep your transactions in their original local currencies, you’ll get to choose a method for resolving exchange rate variances during the data import. If you use the actual exchange rates reflected on each transaction (as opposed to an average rate for all banks on that date), your reporting will more closely match what actually happened. However, you’ll rack up significant rounding errors on your reports that can compound into variances of thousands or even tens of thousands of dollars.  

Option 3: Use the Exchange Rate Date Method 

If your legacy system used the OANDA centralized currency library, you have the option of using the Exchange Rate Date Method to convert each transaction into your base currency for reporting purposes. You’ll migrate each transaction in its original currency, but during the import, Sage Intacct will ignore the exchange rate found on the transaction and impose the OANDA rate instead.  

This can keep rounding error variances between the legacy system and the target system to a minimum (although they will likely still exist because of minor differences in how the calculations are performed in each system). However, using this method means that your reporting is less true to reality.  

Migrate to Multi-Entity Accounting Software with Ease 

Platform Transition specializes in converting complex, multi-entity, multi-currency historical accounting data into a structure that behaves as if it was entered correctly inside Sage Intacct from day one. We reconcile intercompany activity, eliminate duplicate master data, streamline your chart of accounts, handle currency conversions, and ensure your historical transactions reflect your new dimensional architecture.  

Schedule a meeting or request a quote to start planning your move to multi-entity accounting software today.