How to Consolidate Data from NetSuite, Dynamics 365 Finance and SAP

Quick answer

To consolidate financial data from NetSuite, Dynamics 365 Finance and SAP, Finance must extract balances and relevant dimensions from each ERP, map them to a common group reporting structure, align periods and currencies, process consolidation adjustments and intercompany eliminations, and validate the consolidated results against the source systems.

A group does not need every subsidiary to use the same ERP before it can produce dependable consolidated reporting. NetSuite, Microsoft Dynamics 365 Finance and SAP may each be performing their local accounting role correctly. The challenge begins when Group Finance must turn three different financial structures into one consistent view of performance.

Exporting data is only the first step. The group must decide how local accounts relate to the group chart of accounts, which dimensions should be retained, how currencies should be translated, how intercompany activity should be identified and who is responsible for reviewing exceptions. Without those rules, a technically successful integration can still produce an unreliable report.

The objective is therefore not simply to connect three systems. It is to create a controlled route from the local ledgers to the consolidated financial statements, management reports, budgets, forecasts and board pack.

Why Multi-ERP Consolidation Is Difficult

Every ERP reflects the operating and accounting decisions made when it was implemented. Two entities in the same group may use different account codes, financial dimensions and closing procedures even when they perform similar activities. Adding a third platform introduces another set of definitions and controls.

• Different charts of accounts. The same expense may be recorded under different codes or levels of detail.
• Different dimensions. One system may use departments and classes while another uses cost centres, profit centres or segments.
• Different calendars. Entities may follow different fiscal years, adjustment periods or close dates.
• Different currencies. Local results must be translated using approved rates and methods.
• Different entity structures. Legal ownership and management reporting hierarchies may not be identical.
• Different intercompany identifiers. The counterparty may be explicit in one ERP and embedded in an account or description in another.
• Different access methods. Each platform offers its own APIs, analytics services, exports and permission model.
• Different levels of detail. One source may provide transaction data while another provides monthly balances.

What Data Should Be Extracted From Each ERP?

The extraction design should begin with the reporting requirement. Monthly management reporting may only require account balances by entity and reporting dimension. Detailed variance investigation, cash flow analysis or intercompany matching may require journal or transaction-level data.

Core financial data

• Legal entity and source system
• Account code and account description
• Accounting date, fiscal period and fiscal year
• Debit, credit and net amount
• Opening and closing balances where applicable
• Transaction currency, local currency and reporting currency
• Journal or transaction identifier
• Posting status and last updated date

Reporting dimensions

• Department or cost centre
• Business unit or profit centre
• Product, customer or channel
• Project or contract
• Region or country
• Intercompany counterparty
• Any local dimension required for group reporting

The extraction should also include control information such as the extraction timestamp, batch identifier and source record key. These fields allow Finance to prove which data was loaded, identify changes between runs and trace a consolidated figure back to its origin.

How Data Can Be Extracted From Each System

NetSuite

NetSuite offers several routes for accessing financial data, including SuiteAnalytics Connect, SuiteAnalytics datasets, REST web services and controlled exports. SuiteAnalytics Connect provides read-only access through supported drivers, while REST web services can execute datasets created in SuiteAnalytics Workbook. Oracle states that the NetSuite2.com analytics data source applies role-based access and is the current data source for SuiteAnalytics Connect (Oracle, 2026a, 2026b).

The appropriate method depends on the required volume, refresh frequency, level of detail and permissions. Finance should define the exact records, fields and filters required rather than extract every available table.

Microsoft Dynamics 365 Finance

Dynamics 365 Finance supports data entities, export projects, financial reporting and several native consolidation methods. Microsoft documents options that include online consolidation, financial reporting, consolidation with import and the export of company balances. It also supports account and financial-dimension mapping when subsidiary data is brought into a consolidated legal entity (Microsoft, 2026a, 2026b).

When Dynamics 365 Finance is one of several ERPs, the main design question is whether the group will consolidate within a Dynamics environment or extract the required balances and dimensions into a separate reporting layer.

SAP

SAP is an umbrella term covering different products, versions and deployment models. For a group using SAP S/4HANA, data may be accessed through standard APIs, integration services, structured exports, SAP Group Reporting or SAP Group Reporting Data Collection. The available route depends heavily on the organisation's SAP architecture and licensing. SAP positions Group Reporting Data Collection as a way to gather financial data for consolidation, including data from entities or systems outside the core environment (SAP, n.d.).

The article uses SAP S/4HANA as the main example, but the extraction design should always be confirmed against the specific SAP product and implementation in use.

Build a Common Group Reporting Structure

The most important design decision is the group model. Local entities can retain their own ledgers, but Group Finance needs a common structure in which equivalent accounts, entities and dimensions have consistent meanings.

• Group chart of accounts
• Legal entity and management hierarchy
• Reporting dimensions and allowed values
• Profit and loss, balance sheet and cash flow classifications
• Intercompany relationships and counterparty codes
• Currency translation rules
• Ownership percentages
• Consolidation adjustment categories
• Budget and forecast structures

Example account mapping

Mapping does not require the subsidiaries to change their local account codes. It creates a governed translation between each source structure and the group reporting model. The mapping should preserve the original account and entity values so that users can trace the result back to the ledger.

Mappings should have owners, effective dates, review status and version history. A new source account should be routed for review rather than silently assigned to a generic category.

Standardise Periods and Closing Status

A consolidated report is only meaningful when its entities refer to compatible periods. A group may have calendar-month entities, a subsidiary with a different fiscal year, and another entity that uses a separate adjustment period.

• Define the official group reporting calendar
• Map every source period to a group period
• Establish cut-off dates for each entity
• Record whether an entity is open, submitted, reviewed or approved
• Control the treatment of adjustment periods
• Refresh the consolidation when a source period is reopened
• Prevent incomplete entities from being presented as final

Close status should be part of the reporting workflow. A refreshed dashboard should not be mistaken for a completed consolidation simply because the underlying connection ran successfully.

Translate Local Currencies

For each entity, Finance must identify the functional currency, the group reporting currency and the approved exchange-rate source. The consolidation model should retain local currency values alongside translated values.

A common policy may use average rates for income statement accounts, closing rates for many balance sheet accounts and historical rates for selected equity balances. Translation differences should be recorded separately and handled according to the group's accounting policy.

The system should make the applied rate visible. Finance should be able to explain whether a movement comes from local performance, a change in exchange rates or a consolidation adjustment.

Match and Eliminate Intercompany Activity

The consolidated group should not report transactions that occurred within the group as external revenue, expense, assets or liabilities. The difficulty is identifying the two sides of an intercompany transaction when they originate from different ERPs.

Common intercompany balances include receivables and payables, revenue and expenses, loans and interest, management fees, dividends, shared-service charges and unrealised profit in inventory.

1. Standardise the counterparty. Assign each group entity a common counterparty identifier and map local values to it.
2. Load both sides. Bring the relevant account, entity, counterparty, currency and document detail into the group model.
3. Match the balances. Compare the receivable with the payable, or the income with the expense, using agreed tolerance rules.
4. Investigate differences. Separate timing, currency, tax, classification and missing-entry differences.
5. Approve corrections. Determine whether the source ledger or the consolidation layer should be adjusted.
6. Post the elimination. Remove the matched internal activity from the consolidated result.
7. Retain the audit trail. Preserve the source balances, difference, adjustment, reviewer and approval record.

Separate Source Entries From Group Adjustments

The consolidated model should distinguish entries imported from the local ledgers from adjustments made by Group Finance. This prevents a top-side journal from being confused with a source-system correction.

• Reclassification journals
• Intercompany eliminations
• Currency translation adjustments
• Purchase accounting adjustments
• Minority interest
• Accounting policy alignment
• Late subsidiary submissions
• Other group-level adjustments

Each adjustment should identify the period, entity, account, currency, preparer, reviewer, explanation, supporting evidence and reversal treatment. Access should be controlled, and approved periods should not be changed without a documented process.

Validate the Consolidated Result

Source-to-report checks

• Do the extracted balances agree with each ERP?
• Were all required entities and periods loaded?
• Did any extraction or mapping fail?
• Do mapped totals still agree with the source totals?
• Can every consolidated balance be traced to an entity and account?

Consolidation checks

• Does the consolidated balance sheet balance?
• Were currency rules applied consistently?
• Were intercompany differences resolved or explained?
• Were all group adjustments reviewed and approved?
• Do ownership and minority-interest calculations agree with the group structure?

Reporting checks

• Do actuals, budgets and forecasts use the same reporting structure?
• Are management reports consistent with the consolidated result?
• Are material variances supported by commentary?
• Is the report version clearly identified?
• Can users distinguish preliminary from final results?

Three Ways to Organise Multi-ERP Consolidation

The right architecture depends on the existing ERP landscape, reporting complexity, internal technical resources and required speed of change. The important point is that the consolidation rules remain visible, governed and owned by Finance.

How Planir Supports Multi-ERP Consolidation

NetSuite, Dynamics 365 Finance and SAP remain the systems of record for their respective entities. Planir provides a governed Finance layer above those source systems for consolidation, management reporting, planning and analysis.

Planir can ingest financial data through native integrations, APIs, SFTP or structured uploads. Finance can then map different charts of accounts into a common model, maintain entity and reporting hierarchies, translate currencies, process intercompany eliminations and compare consolidated actuals with budgets and forecasts.

• Cross-ERP account and dimension mapping
• Multi-entity and multi-currency consolidation
• Intercompany matching and eliminations
• Group-level adjustments and audit history
• Actual, budget and forecast comparisons
• Management, board and investor reporting
• Financial and operational KPI reporting
• Variance analysis and commentary
• Role-based access and controlled workflows
• Traceability from group reports to source data

Example: One Group, Three ERP Systems

Consider a regional group whose Singapore headquarters uses NetSuite, Australian subsidiary uses Dynamics 365 Finance and manufacturing entity uses SAP S/4HANA. Each entity maintains its local chart of accounts and functional currency. Group Finance reports in Singapore dollars and prepares a monthly board pack that compares actual performance with the budget.

1. Extract the source data. Balances and required dimensions are loaded from each ERP after the local close.
2. Validate the loads. Control totals are compared with each source ledger.
3. Apply the group mappings. Local accounts, entities and dimensions are translated into the common reporting structure.
4. Align the periods. Source periods and close statuses are mapped to the group calendar.
5. Translate the currencies. Local balances are converted into Singapore dollars using approved rate rules.
6. Match intercompany balances. Counterparty balances are compared and exceptions are investigated.
7. Apply eliminations and adjustments. Approved group entries are recorded separately from source data.
8. Compare actuals with the plan. The consolidated result is analysed against budgets and forecasts.
9. Prepare the reports. Management and board outputs are refreshed from the governed model.
10. Review and approve. Finance explains material movements and approves the final reporting version.

No ERP needs to be replaced for this process to work. The value comes from placing a consistent reporting and consolidation model above the existing source systems.

Common Mistakes

• Treating extraction as consolidation. Moving balances into one location does not resolve mappings, currencies, eliminations or controls.
• Discarding the source account. A group mapping should never remove the route back to the local ledger.
• Loading insufficient detail. Monthly net balances may not support intercompany matching or detailed variance analysis.
• Using inconsistent counterparty codes. Intercompany matching becomes unreliable when entities cannot identify one another consistently.
• Applying exchange rates without visibility. Finance must be able to identify which rates and methods were used.
• Overwriting mappings. Changes should have effective dates, ownership and version history.
• Mixing source and group journals. Local corrections and consolidation adjustments should remain distinguishable.
• Reporting before every entity is ready. A successful refresh does not mean every subsidiary has completed its close.
• Rebuilding the process in spreadsheets. Spreadsheets can support analysis, but should not be the only location for mappings, approvals and audit history.
• Choosing architecture without Finance ownership. The group model must reflect Finance policy, not only technical convenience.

The Final Takeaway

Consolidating data from NetSuite, Dynamics 365 Finance and SAP is not primarily an ERP replacement project. It is a Finance data governance project. The group needs a common reporting structure, controlled mappings, consistent currency and elimination rules, clear review responsibilities and a dependable route from each source balance to the final report.

A multi-ERP landscape can continue to support local operating requirements while Group Finance works from one consolidated view. The deciding factor is whether the reporting layer can bring the data together without losing control, context or traceability.

Planir allows organisations to retain the systems that support their local operations while giving Group Finance one controlled environment for consolidation, reporting, planning and analysis.

Frequently Asked Questions

Can NetSuite, Dynamics 365 Finance and SAP data be consolidated together?

Yes. Data from the three ERPs can be consolidated when the required balances and dimensions are extracted, mapped to a common group structure and processed using consistent currency, elimination and adjustment rules.

Do all entities need the same chart of accounts?

No. Each entity can retain its local chart of accounts. Group Finance needs controlled mappings from every local account to the common group chart of accounts.

Should data be consolidated at transaction or account-balance level?

It depends on the reporting requirement. Balance-level data may be sufficient for recurring statements, while transaction or journal detail may be needed for intercompany matching, audit support and detailed analysis.

Can entities with different fiscal calendars be consolidated?

Yes. Every local period must be mapped to a common group reporting calendar, and the treatment of cut-off dates and adjustment periods must be defined.

How are multiple currencies handled?

The model retains local values and translates them into the group reporting currency using approved rate types and accounting policies. Translation differences are recorded separately.

How should intercompany activity be matched across ERPs?

Use common entity and counterparty identifiers, load both sides of the transaction, compare them using agreed tolerances, investigate differences and retain the resulting elimination audit trail.

Is a data warehouse required?

No. A data warehouse is one possible architecture. A financial reporting, consolidation or FP&A platform can also connect the ERP data and apply the required Finance rules.

Should the group replace its ERPs first?

Usually not. If the local systems maintain dependable accounting records, the group can add a consolidation and reporting layer above them.

What does Planir replace in this process?

Planir does not replace the local ledgers. It replaces manual consolidation, mapping and reporting work that would otherwise sit across disconnected spreadsheets and files.

References

Microsoft. (2026a). Consolidation and elimination overview. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/finance/budgeting/consolidation-elimination-overview

Microsoft. (2026b). Export subsidiary data to files. Microsoft Learn. https://learn.microsoft.com/en-us/dynamics365/finance/general-ledger/export-subsidiary-data-to-file

Oracle. (2026a). SuiteAnalytics Connect. Oracle NetSuite. https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/chapter_3963845427.html

Oracle. (2026b). Working with SuiteAnalytics datasets in REST web services. Oracle NetSuite. https://docs.oracle.com/en/cloud/saas/netsuite/ns-online-help/section_156577938018.html

SAP. (n.d.). SAP Group Reporting Data Collection. SAP Help Portal. Retrieved September 2, 2026, from https://help.sap.com/docs/SAP_S4HANA_CLOUD/90c07e91c7a64f328be3fd6b48955b13/7cff56484fb94f04975b0580d27039ff.html