NetSuite consolidated multi-subsidiary reporting, explained

A group controller's least favourite question is is that the consolidated number? In NetSuite OneWorld it is a fair question, because consolidated multi-subsidiary reporting is not one report you run. It is three mechanics firing together: hierarchy rollup, currency translation at consolidated rates, and intercompany elimination. Get one of the three wrong and you produce a figure that looks reasonable, adds up correctly down the column, and is wrong by the size of your intercompany trade.

Consolidated reporting in NetSuite OneWorld

Presenting the combined results of a parent subsidiary and everything beneath it in the subsidiary hierarchy, restated into the parent's base currency, with intercompany transactions removed. The consolidation happens when the report is rendered — the underlying transactions stay in each subsidiary's own books, in their own currency.

How NetSuite builds a consolidated number

Every subsidiary has one base currency, fixed at creation, and sits at one point in a hierarchy. Transactions post to a subsidiary and are stored in that subsidiary's base currency alongside the transaction currency. When you view a financial statement in the context of a parent, NetSuite walks down the hierarchy, gathers the children's balances, and translates each one into the parent's base currency.

The translation is not done at one rate. NetSuite applies a rate type based on the account category, which is the standard current-rate method and the reason your translated balance sheet needs a plug line.

Those rates come from a consolidated exchange rate table that is separate from the currency exchange rates used to price a transaction. It is keyed by accounting period and by subsidiary-to-parent pair, and it holds a current, average and historical rate for each combination. It is seeded from your currency rates and can be overridden per period, and there is a period-close task that calculates it. Until that task has run for a period, treat any consolidated figure for that period as provisional.

Cumulative translation adjustment is not an error

Translate assets at one rate, income at another and equity at a third, and the translated trial balance will not balance. The gap is cumulative translation adjustment. NetSuite carries it as an equity balance so the consolidated balance sheet closes, and there is a separate CTA line associated with elimination activity for the same reason on the elimination side.

Two practical rules. First, CTA moves when rates move, even if no subsidiary did anything, so a swing in CTA is not a finding on its own. Second, if CTA is large relative to the group's net assets, the usual causes are a subsidiary whose base currency was set wrong at creation, or historical-rate accounts that were used for something they should not have been. Neither is fixed by adjusting CTA.

Elimination: why consolidated revenue is never the sum of subsidiaries

If your US entity sells $1.8M of goods to your German entity, group revenue did not go up by $1.8M. NetSuite handles this with an elimination subsidiary: a subsidiary flagged as elimination, sitting under the parent where the consolidation should happen. Accounts that carry intercompany activity are flagged for elimination, counterparty customer and vendor records are linked to the subsidiary they represent, and a period-end task generates reversing entries into the elimination subsidiary.

The elimination subsidiary is not a legal entity. It exists so that the consolidated rollup has something to add that nets the intercompany activity to zero. Which leads directly to the most common reporting error in OneWorld accounts.

• Filtering to your operating subsidiaries excludes the eliminations. Pick your five trading entities from a multi-select and you get the sum of five gross figures. Revenue is overstated by the full intercompany amount, and so is COGS, so operating profit can look almost right while both top lines are inflated.
• Elimination only catches what it is configured to catch. If an intercompany sale posts to an account that is not flagged for elimination, or the customer record is not linked to the counterparty subsidiary, the transaction is invisible to the elimination task and stays in consolidated revenue.
• Elimination runs at period close. Report before the task has run for the period and your consolidated numbers are gross. This is why the month-end close checklist puts elimination before the review step rather than after it.
• Unbalanced intercompany accounts need adjusting separately. Where one side of an intercompany pair posted and the other did not, or posted at a different rate, the intercompany accounts do not net to zero and the difference has to be cleared with an adjustment rather than left for elimination to absorb.

Subsidiary context: two people, two right answers

The same saved report, run by two people, legitimately returns different totals. Consolidated reporting depends on the context the report runs in, and context comes from three places at once: the subsidiary restrictions on the role, the subsidiary selected in the report, and how far down the hierarchy that selection reaches.

How you exclude or include children differs between financial statements, saved searches and queries, so confirm the mechanism in your own account rather than assuming. What does not differ is the consequence: write the scope into the report name. Group consolidated (EMEA parent, incl. children) is a worse name and a better report than Revenue by month.

Why saved searches and SuiteQL do not consolidate for you

This is the part that catches technically strong people. The accounting lines behind a transaction are stored in the subsidiary's base currency. A query that groups a revenue account across subsidiaries and sums it produces a single number composed of euros, dollars and pounds, with no error and no warning.

SELECT s.name        AS subsidiary,
       s.currency    AS base_currency,
       SUM(tal.amount) AS amount_in_subsidiary_base
FROM   transactionaccountingline tal
JOIN   transactionline tl
       ON  tl.transaction = tal.transaction
       AND tl.id          = tal.transactionline
JOIN   transaction t  ON t.id = tal.transaction
JOIN   subsidiary   s ON s.id = tl.subsidiary
JOIN   account      a ON a.id = tal.account
WHERE  tal.posting = 'T'
  AND  a.accttype  = 'Income'
  AND  t.postingperiod = 123
GROUP  BY s.name, s.currency

To make those rows comparable you have to do consolidation yourself: resolve each subsidiary's path to the reporting parent, look up the consolidated rate for the period and the correct rate type for each account category, apply it, and then add or remove the elimination subsidiary depending on the scope you want. That is real work, and it is why the pattern in SuiteQL join examples matters more here than in a single-entity account. If you are keeping such a query, run it through the SuiteQL formatter first — consolidation queries get long, and the joins are where the errors hide.

What good consolidated reporting looks like

• One named consolidated pack per parent, with the subsidiary scope in the title, published to a role rather than emailed. Ad-hoc consolidated reports are how two versions of group revenue end up in the same meeting.
• Consolidated rates confirmed as a close task, before anyone reviews variances. A rate error and a trading error look identical in a variance column.
• Local currency and reporting currency shown side by side for each subsidiary, so a manager can recognise their own numbers. If a country controller cannot find their revenue in the group pack, they stop trusting the pack.
• Elimination shown as a visible column, not netted away. Seeing $1.8M of eliminated revenue is reassuring. Not seeing it is how it goes missing.
• Budget loaded at the same granularity as actuals — same subsidiary, same currency basis. Comparing a consolidated actual against a budget entered in local currency is the most common variance artefact in budget versus actual reporting.
• A named owner for the subsidiary hierarchy. Adding a subsidiary changes every consolidated report beneath the insertion point, and it is usually done by whoever set up the new entity.

The honest cost of getting this right

A clean consolidated answer to something as ordinary as group gross margin by region, last six months, in USD takes a report build, a rate check, an elimination check and a reconciliation to the statutory numbers. For most groups that is a day or two of a qualified accountant's month, every month, repeated because the request always arrives slightly differently. The reporting time savings calculator puts a number on that if you need to justify fixing it.

This is the class of question ERPray is built for: ask what was group revenue by subsidiary last quarter in USD, with intercompany eliminated? and get the answer computed live from your own account, with the SuiteQL it ran shown underneath so you can check which subsidiaries, which rates and which elimination were included, rather than take the number on faith.