ERP multiempresa: um plano de contas e várias moedas

Uma empresa que opera em Espanha e em Portugal está, da perspetiva dos sistemas, a gerir dois regimes estatutários, duas autoridades tributárias, duas convenções de plano de contas com diferenças estruturais reais e — se o reporting consolidado importa, o que é normalmente o caso — uma visão de gestão que tem de reconciliar tudo isso. Acertar nesta estrutura na implementação é consideravelmente mais barato do que corrigi-la depois, porque o plano de contas é o alicerce sobre o qual são construídos todos os relatórios, todas as consolidações e todas as integrações.

A maior parte da dificuldade nestas implementações não é técnica. O NetSuite e as plataformas comparáveis suportam nativamente estruturas multissubsidiária e multimoeda. A dificuldade está numa decisão de design tomada cedo e raramente revista: quanta da divergência estatutária entre jurisdições deve ser absorvida num plano de contas genuinamente local por entidade, face a quanta deve ser forçada dentro de uma única estrutura global em nome da simplicidade da consolidação. Se errar neste ponto, passará anos a lutar contra o seu cumprimento local ou contra o seu reporting consolidado — normalmente contra ambos, em meses alternados.

Por que motivo isto importa

Espanha e Portugal, embora sejam ambos Estados-membros da UE com princípios de IVA amplamente harmonizados, têm convenções estatutárias de plano de contas materialmente diferentes, regimes de reporting digital diferentes e requisitos de faturação diferentes. O Plan General de Contabilidad espanhol e o Sistema de Normalização Contabilística português estão relacionados, mas não são idênticos, e um plano de contas que satisfaz os requisitos de entrega estatutária de um país não satisfaz automaticamente os do outro.

Um plano de contas multientidade mal estruturado produz um custo específico e recorrente: mapeamento manual em cada consolidação, em cada entrega e em cada relatório de gestão. Este trabalho de mapeamento é exatamente o tipo de reconciliação manual discutido noutros artigos desta série como fator de um fecho lento — exceto que aqui se repete em cada ciclo de reporting durante toda a vida da estrutura, porque é o design subjacente que o força e não uma falha temporária de processo.

Existe também uma dimensão de conformidade específica desta região. O regime SII espanhol exige a submissão eletrónica quase em tempo real dos registos de IVA, e Portugal tem os seus próprios requisitos de SAF-T e de faturação estruturada, a avançar numa direção semelhante ao abrigo do impulso mais amplo de reporting digital da UE. Um plano de contas e uma estrutura de códigos de imposto que não correspondem de forma limpa àquilo que o regime de reporting digital de cada jurisdição espera transformam uma entrega rotineira num exercício de tradução manual em cada período. Confirme os limiares e requisitos atuais diretamente com a AEAT e com a Autoridade Tributária portuguesa antes de finalizar o design, dado que estes regimes têm sido alargados e revistos.

Num relance: as decisões estruturais

A resposta intermédia da coluna da direita não é um compromisso por si mesmo — reflete uma distinção real entre aquilo que tem de satisfazer uma autoridade tributária local (que não pode ser forçada a uma convenção estrangeira) e aquilo que tem de suportar a comparação e a consolidação (que precisa de uma estrutura partilhada para ser utilizável de alguma forma).

O que funciona e sobre o que é preciso ser honesto

O que funciona:

Desenhar primeiro a estrutura global e mapear depois os requisitos locais sobre ela — não o inverso. Partir dos requisitos estatutários e tentar forçar uma visão global depois tende a produzir um pesadelo de consolidação, porque planos locais construídos de forma independente raramente se alinham, mesmo em princípio. Partir de uma estrutura global sensata e mapear sobre ela o requisito estatutário de cada jurisdição como uma camada sobreposta dá mais trabalho no início e consideravelmente menos trabalho para sempre depois.

Um segmento de contas intercompanhias dedicado, com correspondência centralizada. As transações intercompanhias entre uma entidade espanhola e uma portuguesa têm de ficar a zero na consolidação, e têm de ter correspondência e acordo antes do fim do período, não de ser descobertas como uma diferença durante ele — é a mesma disciplina de reconciliação contínua discutida no artigo sobre o fecho em cinco dias, aplicada especificamente à relação intercompanhias.

Uma moeda de consolidação e uma política de câmbios documentada, decididas uma só vez. Consolidar em euros (o que é simples, dado que tanto Espanha como Portugal usam o euro, o que elimina uma camada de complexidade que muitos grupos transfronteiriços não têm) continua a exigir uma política documentada para quaisquer transações não denominadas em euros, para os ajustamentos de conversão e para o tratamento das diferenças de câmbio — decidida antecipadamente em vez de discutida em cada fecho.

Dimensões partilhadas onde o negócio é genuinamente comparável, com extensões locais onde não é. Forçar centros de custo ou departamentos idênticos em duas entidades com modelos operacionais genuinamente diferentes produz comparações sem significado. A disciplina consiste em decidir, deliberadamente, que dimensões devem ser partilhadas para uma comparabilidade real e a quais deve ser permitido divergir.

Envolver competência estatutária local em ambas as jurisdições durante o design, e não apenas no momento da entrega. Uma estrutura que parece correta da perspetiva dos sistemas pode ainda assim falhar um requisito específico de entrega estatutária de que nem o consultor de ERP nem a equipa financeira do grupo tinham conhecimento. Os contabilistas locais tanto em Espanha como em Portugal devem revisitar o mapeamento antes de ser construído, não depois.

Sobre o que é preciso ser honesto:

A simetria perfeita entre jurisdições não é alcançável e não deve ser o objetivo. As convenções estatutárias de Espanha e de Portugal diferem de formas reais e não cosméticas, e uma estrutura que finge o contrário em nome da arrumação acabará por falhar um requisito de entrega local. O objetivo é um mapeamento limpo, não estruturas idênticas.

Isto é genuinamente difícil de mudar depois de terem sido lançadas transações contra a estrutura. Reestruturar um plano de contas depois de um ano ou mais de histórico de transações é um projeto a sério, que envolve remapeamento histórico, e é consideravelmente mais caro do que acertar no design desde o início. É uma das poucas áreas do ERP em que "fazer bem à primeira" não é um lugar-comum.

Haverá alterações estatutárias locais e a estrutura tem de as absorver sem um redesenho. Tanto Espanha como Portugal têm alargado ativamente os requisitos de reporting digital nos últimos anos, e uma estrutura demasiado rígida para acomodar um novo código de imposto ou uma nova categoria de reporting sem retrabalho do núcleo terá de ser revisitada mais vezes do que devia. Incorpore flexibilidade de mapeamento de forma deliberada.

As estruturas multientidade aumentam o volume de lançamentos contabilísticos manuais se não forem desenhadas com cuidado, particularmente em torno dos lançamentos intercompanhias e de repartição. Isto liga-se diretamente ao modelo de custos discutido noutros artigos desta série — uma estrutura multientidade mal desenhada é uma das causas mais comuns de um número desproporcionadamente elevado de lançamentos manuais.

A capacidade do software ou do módulo de consolidação varia, e deve ser avaliada como parte do design inicial, não descoberta depois. Algumas abordagens de consolidação tratam a multimoeda e a eliminação multientidade de forma nativa e bem; outras exigem trabalho manual substancial fora do ERP. Compreenda em que categoria se enquadra a abordagem escolhida antes de a estrutura ser finalizada, porque condiciona o design.

Enquadramento de decisão: desenhar ou corrigir a estrutura

Percorra por ordem. Pare na primeira correspondência.

1. Está a desenhar isto antes do go-live ou a corrigir uma estrutura existente?
Se está a desenhar, siga a sequência abaixo por ordem. Se está a corrigir uma estrutura existente, os mesmos princípios aplicam-se, mas conte com um esforço materialmente maior para o remapeamento de dados históricos — orce-o com honestidade em vez de o tratar como uma reconfiguração rápida.

2. Envolveu competência estatutária local em Espanha e em Portugal especificamente para este design?
Se não, faça-o antes de finalizar qualquer coisa. Um consultor de ERP com domínio dos sistemas não substitui o conhecimento de um contabilista local sobre os requisitos estatutários atuais do plano de contas em cada jurisdição.

3. Tem uma moeda de consolidação e uma política de taxas de câmbio documentadas?
Se não, decida-as e documente-as antes de construir o plano. Afeta decisões de estrutura de contas a jusante e não deve ser uma reflexão tardia descoberta na primeira consolidação.

4. Existe uma estrutura de contas intercompanhias dedicada e com correspondência centralizada?
Se não, construa-a explicitamente em vez de permitir que as transações intercompanhias sejam tratadas ad hoc por par de entidades. É uma das decisões estruturais de maior retorno disponíveis e reduz diretamente a carga de reconciliação no fecho.

5. Decidiu deliberadamente que dimensões são partilhadas entre entidades e quais são locais?
Se isto nunca foi uma decisão deliberada, provavelmente foi decidido por omissão na direção para a qual o partner de implementação se inclinou, e vale a pena revisitá-lo explicitamente.

6. A sua estrutura de códigos de imposto corresponde de forma limpa aos requisitos atuais de reporting digital de cada jurisdição?
Se tem dúvidas, verifique diretamente contra os requisitos atuais do SII da AEAT e contra os requisitos atuais de SAF-T e de faturação da AT portuguesa — foram alargados nos últimos anos e uma estrutura desenhada mesmo há apenas alguns anos pode precisar de atualização.

7. Tudo o acima está resolvido e a consolidação continua a ser manual e penosa?
A restrição está provavelmente nas suas ferramentas de consolidação e não no design do plano de contas em si. Avalie se a capacidade nativa de consolidação do seu ERP corresponde à sua complexidade real, ou se se justifica um módulo ou uma ferramenta de consolidação dedicados.

Custo e esforço indicativos

Peça um orçamento para uma estimativa delimitada de design ou de remediação.

Perguntas frequentes

O NetSuite consegue cobrir nativamente os requisitos estatutários espanhóis e portugueses?
O NetSuite suporta estruturas multissubsidiária e multimoeda e tem capacidade de localização para muitas jurisdições, mas os detalhes do suporte estatutário atual devem ser verificados diretamente contra a documentação atual da Oracle e confirmados com contabilistas locais para os seus requisitos específicos, dado que a profundidade da localização varia e os requisitos mudam.

Cada subsidiária deve ter o seu próprio plano de contas ou partilhar um?
Nenhum dos extremos funciona bem na prática. A estrutura que se aguenta é um plano global partilhado com uma camada de mapeamento estatutário por jurisdição — partilhada o suficiente para a consolidação e mapeada com precisão suficiente para satisfazer cada requisito de entrega local.

Como lidamos com o facto de Espanha e Portugal usarem ambos o euro mas terem reporting estatutário diferente?
Partilhar a moeda elimina uma camada de complexidade transfronteiriça, mas não faz nada pela divergência no plano de contas estatutário e no reporting digital, que é uma dimensão completamente separada. Não assuma que o alinhamento de moeda simplifica o design estrutural — simplifica apenas o aspeto da conversão de moeda.

Qual é o maior erro que veem nestas implementações?
Desenhar o plano de contas em torno da jurisdição que o partner de implementação ou o responsável financeiro melhor conhece, e forçar depois os requisitos da outra jurisdição a encaixar. Isto produz uma estrutura que serve bem um país e mal o outro, algo que só é descoberto quando os requisitos de entrega do país mal servido não são cumpridos.

Com que frequência deve esta estrutura ser revista?
Em conjunto com qualquer alteração material — nova entidade, nova jurisdição, uma alteração material no regime de reporting digital de qualquer um dos países — e, como disciplina, no mínimo anualmente, dado o quão ativamente tanto Espanha como Portugal têm alargado os requisitos estatutários de reporting digital nos últimos anos.

Fecho — Próximos passos

Um plano de contas multientidade é uma das poucas decisões de design de ERP que é genuinamente caro alterar a posteriori, o que torna valiosas as semanas adicionais de esforço de design e de revisão estatutária local antes de qualquer transação ser lançada contra ele. A estrutura que se aguenta ao longo do tempo raramente é a mais simples e raramente é a mais fiel localmente — é aquela que mapeia deliberadamente entre as duas.

Se já está em produção e suspeita que a sua estrutura está errada: o diagnóstico honesto é quanto trabalho manual exigiu a sua última consolidação. Se envolveu uma folha de cálculo a reconciliar dois planos de contas à mão, o problema de fundo é a estrutura, não o processo de fecho.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem fricção, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o encaminhamento de exceções, o processamento de documentos e a reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis e com automonitorização.

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

Fontes

Os URL são de nível de editor e devem ser verificados antes da publicação. Os detalhes estatutários devem ser confirmados diretamente contra as orientações atuais da AEAT e da AT portuguesa, dado que os requisitos estão a evoluir ativamente.

• Oracle NetSuite, documentação de multissubsidiária e OneWorld — https://docs.oracle.com/en/cloud/saas/netsuite/
• Agencia Tributaria (Espanha), Suministro Inmediato de Información (SII) — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), SAF-T (PT) e requisitos de faturação — https://info.portaldasfinancas.gov.pt
• Comissão Europeia, VAT in the Digital Age (ViDA) — https://taxation-customs.ec.europa.eu
• Experiência de projetos da Atypical Tech em implementações NetSuite multientidade ibéricas