NetSuite architecture for multi-entity finance and manufacturing — designed before it's configured.

One global chart of accounts, shared by every subsidiary rather than duplicated per entity, with access restricted at the subsidiary level. Local statutory detail — cost centres, functional areas, tax codes — is carried through dimensions (department, class, location and custom segments), not through additional GL accounts.

This keeps the account structure small enough to consolidate cleanly, while dimensions carry as much local detail as controlling actually needs.

NetSuite's multi-book accounting posts one subsidiary transaction into more than one accounting book — for example a local statutory book (HGB, or another local GAAP) and a separate IFRS book — using book-specific rules for revenue recognition, depreciation, leases or provisions.

Both books share the same transactions and the same chart of accounts; they diverge only where the accounting standards genuinely diverge. Finance never re-keys a transaction to produce the second set of numbers.

Intercompany transactions post through a dedicated intercompany account structure and, in our designs, a clearing/matching layer so imbalances are visible and traceable during the month, not discovered at close.

At period end, consolidation applies the group's ownership structure — full, proportional or equity-method depending on shareholding — and eliminates intercompany balances and unrealised profit. Currency translation follows the functional-currency rules for each entity, and the resulting cumulative translation adjustment (CTA) is booked in equity, not left as a plug.

The close runs against a task-dependency calendar: subsidiary close tasks must complete before intercompany matching, intercompany matching before consolidation, consolidation before group reporting.

Segregation of duties is enforced through NetSuite's role and permission model — who can post, who can approve, who can view — rather than through manual sign-off sheets, and approval workflows apply materiality thresholds so small entries route faster than large or unusual ones.

In practice, most close delays trace back to three things: intercompany imbalances found late because there was no in-month matching; consolidation adjustments made by hand outside the system; and close tasks with no enforced sequence, so subsidiaries close in any order and consolidation waits on the slowest one.

Fixing the architecture — matching, sequencing and book design — removes the delay without requiring more finance headcount.

Bills of materials are modelled to the level the shop floor actually needs, including phantom items for sub-assemblies that are never stocked, and co-/by-products where a process yields more than one output.

Routings attach the operations, work centres, and standard run and setup times that convert that BOM into a costed, schedulable work order rather than a static parts list.

Standard costing gives controlling a stable cost to plan and price against, with variances (price, usage, rate) surfaced separately rather than buried in the actual cost. We default to standard costing for repeatable production and use actual or average costing where output is genuinely non-repeatable — for example make-to-order work with volatile input pricing.

The decision is made once, at blueprint stage, because switching methods mid-programme is expensive.

Backflush consumption issues components automatically at operation completion, based on the BOM — appropriate where component usage is predictable and shop floor reporting overhead should stay low. Manual issue gives explicit, transaction-level visibility into consumption — appropriate where component substitution, scrap or yield variance needs to be tracked as it happens.

Most manufacturing clients run a mix, by item or by work centre, not one rule for the whole plant.

MRP nets demand against on-hand and on-order supply, time-phases the resulting requirements, and offsets them by lead time to generate planned orders, with safety stock absorbing forecast error on critical items.

Finite capacity loading then checks those planned orders against actual work centre capacity, rather than assuming infinite throughput; where a work centre is the constraint, that's where the plan gets adjusted, not at the BOM level.

We match the valuation method to what the entity actually needs for statutory and management reporting: standard cost for entities running standard costing, average or FIFO where local GAAP requires it or where standard costing isn't viable.

Valuation method is a finance-architecture decision, agreed with controlling and audit before go-live, not a system default left unexamined.

A first subsidiary is built to a template: chart of accounts, dimension structure, tax and reporting logic. Each subsequent country rollout reuses that template and adds only the genuinely local layer — VAT/Intrastat reporting, SEPA payment formats, DATEV export for the German entities, statutory formats elsewhere — rather than re-designing the finance architecture per country.

This is what keeps a ten-country rollout from becoming ten separate implementations.

NetSuite ships two structured releases a year (for example 2026.1 and 2026.2). We test each release in a sandbox against the client's customisations before it reaches production, and maintain a release-notes review specifically for changes that touch finance or manufacturing configuration.

Nothing reaches the live environment without having run in sandbox first.

Through NetSuite's role and permission model — who can create a vendor, who can approve a payment, who can post a journal — configured to match the client's approval matrix, not a generic template.

We review the role model against the client's actual controls requirements (and their auditor's expectations) at blueprint stage, so segregation of duties is enforced by the system rather than relying on people remembering not to approve their own transactions.

The finance and manufacturing architecture decisions made at blueprint stage are documented, not just implemented, so the next person supporting the system — whether that's us in hypercare or an internal team afterwards — can see why the account structure, book setup or costing method is what it is.

That documentation is also what makes an international rollout to the next entity a repeatable exercise rather than a rediscovery project.