From Spreadsheets to NetSuite for a Multi Entity Business

A growing business often reaches a point where spreadsheets connect the information its accounting and operational tools cannot bring together cleanly. Finance maintains entity mappings, operations reconciles shared records and management reporting depends on a few people who understand the workbook logic.

The case for moving to NetSuite should focus on that operating complexity. More entities, currencies and shared processes can increase the need for consistent data and controlled workflows. They also make migration harder if the team treats every spreadsheet as an authoritative source.

Before committing, establish which problems the new operating model must solve and how each entity's balances, open items and reporting relationships will be proved.

Identify the real migration trigger

Look for recurring work that creates material delay, dependency or uncertainty. Examples include inconsistent account mappings between entities, manual intercompany reconciliations, duplicated customer records and reports that cannot be traced back to approved books.

Measure the consequences. How long does the consolidation or management reporting process take? Which adjustments depend on one person's knowledge? How often does a late change require rebuilding the report? These observations create a stronger case than a general dislike of spreadsheets.

Some businesses can improve their existing processes through better ownership and controls. Others need a broader system change. The decision should consider implementation capacity and ongoing administration as well as the functionality the business hopes to gain.

Inventory the spreadsheets and source systems

List the workbooks and applications involved in accounting, operational processing and reporting. For each, identify the owner, purpose, update frequency, source data and downstream users. Distinguish original records from transformations and management adjustments.

A spreadsheet may contain a mix of imported balances, formulas, manual corrections and presentation logic. Those components should not all become migrated transactions. Determine which information belongs in NetSuite, which logic should become an approved process and which records need controlled archive access.

Preserve the evidence behind material adjustments. A number that appears only in a consolidated workbook needs an explanation and an owner before it is treated as a migration input.

Define scope entity by entity

Create a migration record for each entity covering base currency, source accounts, open receivables and payables, relevant inventory or assets, reporting dimensions and interfaces. Identify shared customers, suppliers and intercompany relationships.

Keep local accounting and tax requirements assigned to the appropriate advisers and regional workstreams. A general migration checklist cannot establish jurisdiction-specific treatment. The cross-entity plan should show where those decisions affect data, configuration and tests.

Agree the cutoff and source snapshot separately where entities have different operating calendars or dependencies. Then explain how the group will manage the transition without losing a coherent reporting boundary.

A hypothetical two-entity example

Consider a business with Entity A reporting in US dollars and Entity B reporting in euros. This example is illustrative and does not describe a real customer or current exchange rates.

Entity A's approved open receivables are USD 30,000 and its open payables are USD 18,000. Entity B's approved open receivables are EUR 20,000 and its open payables are EUR 12,000. The migration team preserves those local control totals instead of adding them into a meaningless mixed-currency total.

Both entities use an account called consulting income, but their source account codes differ. The controller approves a mapping to the intended target account structure while preserving the entity and relevant reporting dimensions. A second account contains both service income and reimbursed costs; it requires an explicit classification decision before mapping.

Entity B also has a USD 1,000 customer invoice with an approved carrying value of EUR 900 at the migration cutoff. The 0.90 EUR-per-USD relationship is invented for this example. The team records the transaction currency, remaining transaction amount, base-currency value and relevant date or rate evidence required by the approved design.

The acceptance test checks that the migrated open item supports the expected future collection process and that its accounting agrees with the approved opening position. The team does not replace the carrying value casually with a convenient rate. Finance determines the appropriate accounting treatment and any required adjustments.

Finally, the entities have reciprocal intercompany items. The migration pack pairs them by entity, counterparty, reference, currency and amount. Any difference is explained before group reporting relies on the result.

Build mappings that survive the transition

Use stable identifiers for accounts, customers, suppliers and intercompany counterparties. Record one-to-one, many-to-one and split mappings explicitly. A merged target record may simplify operations but requires clear treatment of the source references needed for audit and customer service.

Separate natural-account classification from reporting detail. If a spreadsheet encodes department, region and product line inside an account code, decide which attributes belong in the target account and which belong in dimensions. Validate the decision with actual reporting requirements.

Version the mapping and control who can change it. A late mapping update can affect balances, reports and previously completed tests across both entities. The change should trigger a defined review and retest scope.

Reconcile before consolidating the answer

Prove each entity's trial balance and supporting populations first. Then test the cross-entity reporting and intercompany treatment required by the design. A consolidated total can conceal equal and opposite errors between entities.

For open items, reconcile by entity, customer or supplier, transaction currency and relevant aging category. Review credits, partial payments and disputed items separately. They often expose assumptions that a simple invoice total would miss.

For currency-related reporting, have finance define the expected rates, dates, rounding and treatment of differences. The implementation team should demonstrate the approved result with representative transactions rather than infer policy from whichever output the system produces.

Rehearse the cutover boundary

The cutover test should include activity arriving from every retained source. Confirm which system owns each transaction before and after the cutoff, how late entries are handled and who checks for omissions or duplication.

Run representative first-day tasks in both entities. Ask users to find a migrated invoice, apply an approved receipt in the test environment, inspect an intercompany balance and reproduce a required management report. Verify permissions and entity visibility as part of the exercise.

Retain controlled access to the information that remains outside NetSuite. Test retrieval of a historical document or adjustment explanation before retiring the old operating process. An archive that nobody can use does not satisfy the business need for access.

Questions finance leaders ask

Should every spreadsheet become a system feature?

No. Classify the workbook's data, calculations, controls and presentation separately. Some functions belong in the future operating process, while others may remain as controlled analysis or historical records.

Can we use one mapping for every entity?

Use a consistent target model where appropriate, but validate each source account and local requirement. Identical labels do not always mean identical accounting content.

Why reconcile local currencies separately?

Each entity's approved books need to be proved on their own basis. Cross-entity reporting adds further rules and can otherwise conceal errors through aggregation or offsetting differences.

What should determine the migration date?

Readiness, operating constraints, required approvals and the ability to execute and reconcile the cutover. A convenient calendar date is useful only when those dependencies support it.

Replace fragile handoffs with a controlled design

Bring your entity map, reporting workbooks and reconciliation gaps to CuriousRubik. A focused NetSuite migration discussion can clarify which information, controls and responsibilities need to move together.