NetSuite-native consolidation at scale: when you don't need a classical tool.

The default narrative — and why it is incomplete

For most groups buying NetSuite, the assumption is fixed: the ERP handles the books at entity level, a dedicated consolidation tool handles the group. The category — classical consolidation tools — has decades of pedigree, audit history and statutory depth, and those platforms sit cleanly on top of any ERP estate. For a long time, that was simply the way serious group reporting got done.

But the ERP layer has moved. NetSuite specifically has been building consolidation depth for more than a decade, and the gap between "ERP with a light roll-up" and "real consolidation engine" is no longer where most buyers think it is. Whether you can do consolidation natively in NetSuite — at scale, multi-currency, with partial ownership, statutory depth, audit trail — is no longer a question of platform capability. It is a question of design and expertise.

The customer who runs 70+ entities and four currencies entirely inside NetSuite — no classical consolidation tool, full and partial consolidation handled — is not a thought experiment. It is in production today. The constraint is not the platform. The constraint is who configures it.

What NetSuite natively does

Without naming any specific competitor on the consolidation-tool side, here is the actual feature surface that ships with NetSuite and that, configured correctly, replaces what most groups buy a separate engine for:

• Multibook accounting. Parallel ledgers for local GAAP, IFRS, US GAAP and management views — running on the same source transactions. No reconciliation between two systems, no second posting layer.
• Full multi-currency engine. Period-end and daily FX rates, currency revaluation, CTA tracking, current-rate and temporal translation methods supported on the platform side. Foreign-currency books inside multibook follow the same rate logic consistently.
• Subsidiary hierarchy with native consolidation. Multiple levels deep, with automatic intercompany eliminations between subsidiaries inside the hierarchy. Consolidation runs against any node — group, sub-group, regional roll-up — in any reporting currency, against any of the parallel books.
• Partial consolidation via subsidiary-level ownership. Ownership percentage is a property of the subsidiary record, and proportional consolidation flows from there: full vs. partial vs. equity-method handling lives inside the chart of subsidiaries, not in a parallel tool.
• Top-side consolidation adjustments. Group-level journal entries (re-classifications, audit adjustments, segment alignment) booked at the consolidation entity, tagged, approved, audit-trailed.
• Native consolidated reporting. P&L, balance sheet, cash flow at any node of the hierarchy, in any reporting currency, against any book — all out of the same source ledger that produced the entity-level statements.

That is not "ERP with a roll-up". That is a consolidation engine inside the ERP. The question that decides whether it carries your group is not whether the engine exists. It is whether someone who knows what they are doing has configured it for your reality.

Where system expertise decides — the part most teams do not carry

A standard NetSuite implementation does not give you a clean consolidation. It gives you a roll-up that looks like consolidation until the audit committee starts asking specific questions. The difference between the two is configuration depth — and configuration depth lives at the intersection of NetSuite system knowledge and classical consolidation discipline. That intersection is rare on either side: NetSuite implementers usually do not carry deep consolidation finance, and consolidation finance specialists usually do not carry deep NetSuite. The customers who get hurt are the ones who assume one of the two is enough.

The decisions that determine whether a NetSuite consolidation is audit-ready:

Subsidiary hierarchy design

Tax structure, legal structure, management reporting structure — three different views on the same set of entities, each with its own consolidation implications. The default "one hierarchy fits all" approach breaks the moment statutory and management reporting need to diverge. Designing the hierarchy so that it carries all three views — without re-implementing every time the group restructures — is a discipline.

Ownership-percentage configuration

Partial-consolidation logic is correct if it is set up correctly. Set up at the wrong moment in the entity lifecycle (acquisition, divestment, restructuring), or without proper effective-date handling, and the historical numbers stop reconciling. Audit findings live in this layer.

Multi-currency translation method per book

Current rate, temporal, monetary / non-monetary — each book may need a different approach. NetSuite supports them; the implementation must apply them consistently across multibook, with a documented FX policy that survives a restatement and an external audit. This is finance design, not system configuration.

Eliminations under partial ownership

The default behaviour eliminates 100% inside the hierarchy. Adjusting eliminations to match ownership percentage, particularly for non-controlled stakes and for sub-consolidation steps, requires explicit configuration — and matching journal logic on the consolidated side. Done right, the eliminations carry through period-on-period without manual touch. Done wrong, every close becomes a reconciliation exercise.

Top-side adjustments and audit trail

Group-level journals — re-classifications, audit adjustments, IFRS-versus-local-GAAP deltas, segment-reporting alignment — must flow through a defined process, with tagging, approval, and a trail that holds up under external audit. The system supports it. The implementation has to design it.

Reconciliation between books and to consolidation

Local books → group book → consolidated reporting: at each step, a reconciliation must hold. Designing those reconciliation points — and instrumenting the close so that breaks are caught early — is the difference between "closes in eight days" and "closes when controlling can finally agree on the numbers".

The reference: 70+ entities, four currencies, no classical tool

The reference engagement inside the group: a customer with more than 70 legal entities, mixed full and partial consolidation, operating in four currencies, in a services-led industry.

The state we found:

• Group consolidation was running in Excel, over multiple days every period — built up by a small team that understood the data flow but could not scale the process or hand it over cleanly.
• NetSuite was already in place at entity level. The consolidation step lived outside the system, despite the platform supporting it natively.
• Vendor proposals on the table: licence and implement a classical consolidation tool on top of NetSuite. Six- to seven-figure ranges across licence and implementation, depending on the vendor.

What we built — and what the customer is operating today:

• Full and partial consolidation native in NetSuite, across the 70+ entities, with partial-ownership logic correctly applied at subsidiary level and the hierarchy designed to carry tax, legal and management views.
• Four currencies translated correctly per book and per reporting line, with CTA tracking and currency revaluation runs against a documented FX policy.
• Eliminations and top-side adjustments flowing through the system rather than as Excel deltas — with audit trail, approvals and tagging at every step.
• Partially automated period close — what used to take multiple days of Excel reconciliation is now mostly system-driven, with a controlled, documented list of remaining manual adjustments that the team owns rather than improvises.
• Licence profile: Financials First Premium plus SuiteProjects — the existing NetSuite stack the customer already had, augmented for the services-business reality of the operation. No additional consolidation-tool licence. No second subscription, no parallel implementation, no recurring interface maintenance.

The classical consolidation tool that prior vendors had proposed never went into the budget. The savings — annual licence fees, implementation cost, ongoing parallel maintenance — are recurring. The audit trail and reconciliation discipline that the team was supposed to gain from a dedicated tool came from the design of the NetSuite consolidation itself.

When a classical consolidation tool is still the right answer

This is where the advisory honesty matters: we do not claim NetSuite-native consolidation is the right answer for everyone. There are real cases where a dedicated consolidation engine still earns its keep:

• Highly regulated financial-services consolidation — banks, insurers, asset managers. Solvency, IFRS 9, regulatory-reporting depth: the dedicated platforms still hold an edge, and the regulator expects to see them.
• Very large, very heterogeneous system landscapes. When the group runs five different ERPs across seventeen countries because of acquisition history, no single ERP becomes the consolidation source — and a tool that sits above all of them is the right architectural answer.
• Statutory or sector-specific consolidation depth that NetSuite does not natively cover — particular local-GAAP standards, sector regulations, public-sector consolidation.
• Integrated planning and consolidation. When the business is doing serious driver-based planning that needs to land in the same system as consolidation, the dual-purpose dedicated platforms have a real advantage.

For everyone else — and "everyone else" includes a great many multi-entity, multi-currency groups that the conventional narrative suggests need a dedicated consolidation tool — the right answer is to do consolidation inside NetSuite, properly. That is a delivery question. It is not a licence-procurement question.

What this changes for the buyer

A separate consolidation tool is a permanent addition to the cost stack. The licence cost is annual. The implementation cost is one-time but six- to seven-figure. The interface cost between ERP and consolidation tool is recurring — every period close, every audit, every restatement runs through it. And the second-system risk is non-zero: every place where reconciliation has to hold between two engines is a place where audit findings tend to live.

If the ERP can carry the consolidation, and the implementation expertise is genuinely present, not adding the second tool is the higher-quality architectural answer. It just requires the depth on the implementation side that most NetSuite resellers and most consolidation-tool implementers do not, individually, hold.

That depth — the intersection of NetSuite system knowledge and classical consolidation discipline — is one of the things the group exists to provide. If your organisation is currently evaluating a dedicated consolidation tool on top of NetSuite, the alternative deserves a one-hour conversation before a licence is signed.