Multi-subsidiary ERP: one chart of accounts, many currencies

A company operating in Spain and Portugal is, from a systems perspective, running two statutory regimes, two tax authorities, two chart of accounts conventions with genuine structural differences, and — if consolidated reporting matters, which it usually does — one management view that has to reconcile all of it. Getting this structure right at implementation is considerably cheaper than fixing it afterward, because the chart of accounts is the foundation every report, every consolidation and every integration is built on top of.

Most of the difficulty in these implementations is not technical. NetSuite and comparable platforms handle multi-subsidiary, multi-currency structures natively. The difficulty is a design decision made early and rarely revisited: how much of the statutory divergence between jurisdictions should be absorbed into a genuinely local chart of accounts per entity, versus how much should be forced into a single global structure for the sake of consolidation simplicity. Get this wrong and you spend years fighting either your local compliance or your consolidated reporting — usually both, on alternating months.

Why this matters

Spain and Portugal, while both EU member states with broadly harmonised VAT principles, have materially different statutory chart of accounts conventions, different digital reporting regimes, and different invoicing requirements. Spain's Plan General de Contabilidad and Portugal's Sistema de Normalização Contabilística are related but not identical, and a chart of accounts that satisfies one country's statutory filing requirements does not automatically satisfy the other's.

A poorly structured multi-entity chart of accounts produces a specific, recurring cost: manual mapping at every consolidation, every filing, and every management report. This mapping work is exactly the kind of manual reconciliation discussed elsewhere in this series as a driver of a slow close — except here it recurs at every reporting cycle for the life of the structure, because the underlying design forces it rather than a temporary process gap.

There is also a compliance dimension specific to this region. Spain's SII regime requires near-real-time electronic submission of VAT records, and Portugal has its own SAF-T and structured invoicing requirements moving in a similar direction under the EU's wider digital reporting push. A chart of accounts and tax code structure that does not map cleanly to what each jurisdiction's digital reporting regime expects turns a routine filing into a manual translation exercise every period. Confirm current thresholds and requirements directly with AEAT and the Portuguese Autoridade Tributária before finalising design, as these regimes have been extended and revised.

At a glance: the structural decisions

The middle-ground answer in the right-hand column is not a compromise for its own sake — it reflects a real distinction between what needs to satisfy a local tax authority (which cannot be forced into a foreign convention) and what needs to support comparison and consolidation (which needs a shared structure to be usable at all).

What works, and what to be honest about

What works:

Designing the global structure first, then mapping local requirements onto it — not the reverse. Starting from statutory requirements and trying to force a global view afterward tends to produce a consolidation nightmare, because local charts built independently rarely align even in principle. Starting from a sensible global structure and mapping each jurisdiction's statutory requirement onto it as an overlay is more work up front and considerably less work forever after.

A dedicated intercompany account segment, matched centrally. Intercompany transactions between a Spanish and a Portuguese entity need to net to zero on consolidation, and they need to be matched and agreed before period end, not discovered as a difference during it — this is the same continuous reconciliation discipline discussed in the five-day close article, applied specifically to the intercompany relationship.

One consolidation currency and a documented rate policy, decided once. Whether you consolidate in euros (straightforward, since both Spain and Portugal use the euro, which removes one layer of complexity many cross-border groups do not have) still requires a documented policy for any non-euro transactions, translation adjustments, and the treatment of exchange differences — decided in advance rather than argued about at each close.

Shared dimensions where the business is genuinely comparable, local extensions where it is not. Forcing identical cost centres or departments across two entities with genuinely different operating models produces meaningless comparison. The discipline is deciding, deliberately, which dimensions should be shared for genuine comparability and which should be allowed to diverge.

Engaging local statutory expertise in both jurisdictions during design, not just at filing time. A structure that looks correct from a systems perspective can still fail a specific statutory filing requirement neither the ERP consultant nor the group's finance team was aware of. Local accountants in both Spain and Portugal should review the mapping before it is built, not after.

What to be honest about:

Perfect symmetry between jurisdictions is not achievable and should not be the goal. Spain and Portugal's statutory conventions differ in real, non-cosmetic ways, and a structure that pretends otherwise for the sake of tidiness will eventually fail a local filing requirement. The goal is a clean mapping, not identical structures.

This is genuinely difficult to change once transactions have been posted against it. Restructuring a chart of accounts after a year or more of transaction history is a real project involving historical remapping, and it is considerably more expensive than getting the design right initially. This is one of the few areas in ERP where "get it right the first time" is not a platitude.

Local statutory changes will happen and the structure needs to absorb them without a redesign. Both Spain and Portugal have been actively extending digital reporting requirements in recent years, and a structure too rigid to accommodate a new tax code or reporting category without core rework will need revisiting more often than it should. Build in mapping flexibility deliberately.

Multi-entity structures increase manual journal entry volume if not designed carefully, particularly around intercompany and allocation entries. This connects directly to the cost model discussed elsewhere in this series — a poorly designed multi-entity structure is one of the more common causes of a disproportionately high manual entry count.

Consolidation software or module capability varies, and this should be evaluated as part of the initial design, not discovered afterward. Some consolidation approaches handle multi-currency and multi-entity elimination natively and well; others require substantial manual work outside the ERP. Understand which category your chosen approach falls into before the structure is finalised, because it constrains the design.

Decision framework: designing or fixing the structure

Run in order. Stop at the first match.

1. Are you designing this before go-live, or fixing an existing structure?
If designing, follow the sequence below in order. If fixing an existing structure, the same principles apply but expect materially more effort for remapping historical data — budget for it honestly rather than treating it as a quick reconfiguration.

2. Have you engaged local statutory expertise in both Spain and Portugal specifically for this design?
If not, do this before finalising anything. A systems-literate ERP consultant is not a substitute for a local accountant's knowledge of current statutory chart of accounts requirements in each jurisdiction.

3. Do you have a documented consolidation currency and exchange rate policy?
If not, decide and document this before building the chart. It affects account structure decisions downstream and should not be an afterthought discovered at first consolidation.

4. Is there a dedicated, centrally matched intercompany account structure?
If not, build this explicitly rather than allowing intercompany transactions to be handled ad hoc per entity pair. This is one of the highest-return structural decisions available and directly reduces close-time reconciliation burden.

5. Have you deliberately decided which dimensions are shared across entities and which are local?
If this was never a deliberate decision, it was probably decided by default in whichever direction the implementation partner defaulted to, and it is worth revisiting explicitly.

6. Does your tax code structure map cleanly to each jurisdiction's current digital reporting requirements?
If uncertain, verify directly against AEAT's current SII requirements and the Portuguese AT's current SAF-T and invoicing requirements — these have been extended over recent years and a structure designed even a few years ago may need updating.

7. All of the above addressed and consolidation is still manual and painful?
The constraint is likely your consolidation tooling rather than the chart of accounts design itself. Evaluate whether your ERP's native consolidation capability matches your actual complexity, or whether a dedicated consolidation module or tool is warranted.

Indicative cost and effort

Get a quote for a scoped design or remediation estimate.

Frequently asked questions

Can NetSuite handle Spanish and Portuguese statutory requirements natively?
NetSuite supports multi-subsidiary, multi-currency structures and has localisation capability for many jurisdictions, but the specifics of current statutory support should be verified directly against Oracle's current documentation and confirmed with local accountants for your specific requirements, since localisation depth varies and requirements change.

Should each subsidiary have its own chart of accounts or share one?
Neither extreme works well in practice. The structure that holds up is a shared global chart with a statutory mapping overlay per jurisdiction — shared enough for consolidation, mapped precisely enough to satisfy each local filing requirement.

How do we handle the fact that Spain and Portugal both use the euro but have different statutory reporting?
Shared currency removes one layer of cross-border complexity but does nothing for the statutory chart of accounts and digital reporting divergence, which is a separate dimension entirely. Do not assume currency alignment simplifies the structural design — it simplifies only the currency conversion aspect.

What is the biggest mistake you see in these implementations?
Designing the chart of accounts around whichever jurisdiction the implementation partner or finance lead is most familiar with, then forcing the other jurisdiction's requirements to fit afterward. This produces a structure that serves one country well and the other poorly, discovered only when the poorly served country's filing requirements are not met.

How often should this structure be reviewed?
Alongside any material change — new entity, new jurisdiction, a material change in either country's digital reporting regime — and at minimum annually as a discipline, given how actively both Spain and Portugal have been extending statutory digital reporting requirements in recent years.

Closing — Next steps

A multi-entity chart of accounts is one of the few ERP design decisions that is genuinely expensive to change after the fact, which makes it worth the extra weeks of design effort and local statutory review before any transaction is posted against it. The structure that holds up over time is rarely the simplest one and rarely the most locally faithful one — it is the one that maps deliberately between the two.

If you are already live and suspect your structure is wrong: the honest diagnostic is how much manual work your last consolidation required. If it involved a spreadsheet reconciling two charts of accounts by hand, the structure — not the close process — is the underlying problem.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication. Statutory details should be confirmed directly against current AEAT and Portuguese AT guidance, as requirements are actively evolving.

• Oracle NetSuite, multi-subsidiary and OneWorld documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (Spain), Suministro Inmediato de Información (SII) — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), SAF-T (PT) and invoicing requirements — https://info.portaldasfinancas.gov.pt
• European Commission, VAT in the Digital Age (ViDA) — https://taxation-customs.ec.europa.eu
• Atypical Tech engagement experience, multi-entity Iberian NetSuite implementations