Saldos de Abertura e Migração de Dados ERP | Guia

# Saldos de Abertura e Migração de Dados: O Arranque de ERP que Corre Mal Três Meses Depois

TL;DR: O arranque (go-live) de um ERP raramente falha no próprio dia — falha semanas ou meses depois — tipicamente no primeiro fecho de mês ou de trimestre —, quando o razão não fecha, o armazém não bate certo com o sistema e ninguém sabe se o histórico que falta era suposto estar lá. A causa quase nunca é o software: é uma decisão de âmbito e de data de corte que ninguém escreveu com clareza antes de migrar o primeiro registo.

O padrão: tudo parece bem no dia um

Há um padrão reconhecível na forma como um arranque de ERP corre mal numa operadora, EPC ou empresa de serviços petrolíferos em Angola. No dia do go-live, o sistema arranca. Os utilizadores conseguem emitir uma factura, lançar uma requisição, registar uma entrada de armazém. A equipa de projecto respira de alívio e a atenção do negócio move-se para outra coisa.

O problema aparece semanas ou meses depois, quando alguém tenta fazer algo que exige que os dados migrados estejam completos e correctos: fechar o mês, reconciliar uma conta corrente com um fornecedor, contar fisicamente um armazém de peças críticas, ou responder a um pedido da auditoria sobre um saldo de abertura. É nesse momento que se descobre que o saldo de um cliente não bate com o extracto que o cliente tem, que existem três fichas de artigo diferentes para o mesmo item de inventário, ou que o sistema diz que há 40 unidades de uma peça em armazém quando fisicamente há 12.

Nenhum destes problemas é um "bug" do ERP. São decisões de migração de dados que foram tomadas — ou evitadas — sob pressão de prazo, e que só se tornam visíveis quando alguém tenta usar os dados para algo que exige precisão, não apenas presença.

Migrar saldos não é o mesmo que migrar histórico

A distinção mais importante que um projecto de migração precisa de fazer — e que a maioria não faz explicitamente — é entre saldos e histórico.

Saldos de abertura são os números que o novo sistema precisa de ter no dia da data de corte para que a contabilidade, o inventário e as contas correntes funcionem correctamente a partir desse ponto: o saldo de cada conta do razão, o saldo em aberto de cada cliente e fornecedor, a quantidade e o valor de cada artigo em stock, o valor líquido contabilístico de cada activo fixo. São números agregados, geralmente um por conta ou por item, e têm de fechar exactamente com o sistema antigo na data de corte.

Histórico é a sequência de transacções que produziu esses saldos: cada factura, cada movimento de armazém, cada lançamento contabilístico dos últimos três, cinco ou dez anos. O histórico não é necessário para o sistema novo funcionar operacionalmente a partir do dia um — é necessário para responder a perguntas como "porque é que este cliente tem este saldo", para auditoria, para relatórios plurianuais, ou para litígios contratuais em que é preciso provar uma sequência de eventos.

A confusão entre os dois é a origem de uma parte considerável dos problemas de arranque. Equipas de projecto sob pressão de calendário decidem, correctamente, que não vão migrar dez anos de histórico transaccional linha a linha para o novo sistema — isso seria caro, lento e na maior parte dos casos desnecessário operacionalmente. O erro está em como essa decisão é comunicada e executada: quando "não vamos migrar histórico" se transforma silenciosamente em "não vamos validar os saldos que dependem desse histórico", o projecto herda saldos de abertura que ninguém conferiu contra nada, porque o raciocínio de "isto está fora do âmbito" foi aplicado ao número errado. Os saldos de abertura nunca estão fora do âmbito. O histórico transaccional pode estar.

A prática mais defensável é manter o sistema antigo acessível em modo de leitura — mesmo que só internamente, sem licenças activas de utilização — durante o período em que a auditoria ou uma disputa contratual ainda pode precisar de consultar uma transacção anterior à data de corte. Isto custa uma fracção do que custaria migrar o histórico, e resolve o mesmo problema que a migração completa resolveria.

A data de corte decide o resto do projecto

Antes de qualquer decisão técnica sobre mapeamento de campos ou scripts de extracção, o projecto precisa de responder a uma pergunta de negócio: qual é a data de corte (cutover date) exacta — dia, e nalguns casos hora — em que o sistema antigo pára de ser a fonte de verdade e o sistema novo assume?

Esta decisão determina praticamente tudo o resto:

Que saldos têm de fechar. Os saldos de abertura do novo sistema têm de corresponder exactamente ao saldo de fecho do sistema antigo nessa data — nem um dia antes, nem um dia depois, porque qualquer transacção lançada num dos dois sistemas e não no outro produz uma diferença que alguém vai ter de encontrar e explicar meses depois.
Que período fica "em trânsito". Entre o corte dos dados extraídos e o go-live real há sempre um intervalo — dias, por vezes semanas — em que o negócio continua a operar. As transacções desse período (facturas emitidas, recepções de armazém, pagamentos) têm de ser lançadas manualmente em ambos os sistemas ou capturadas num processo de "mopping up" explícito, com responsável e prazo definidos, não deixadas para "alguém tratar disso depois".
Que activos e contratos plurianuais exigem tratamento especial. Um contrato de Joint Interest Billing ou um AFE com despesa acumulada a meio do ano fiscal não pode simplesmente reiniciar em zero na data de corte — o saldo acumulado tem de migrar como um saldo de abertura, mesmo que o histórico das transacções que o compõem fique no sistema antigo.
Que reconciliações têm de estar concluídas antes de a decisão ser tomada, não depois. Escolher a data de corte antes de saber se as contas correntes de fornecedores batem certo é decidir a data errada — a decisão devia ser condicionada ao estado real dos dados, não ao calendário do projecto.

Uma operadora com produção alocada por parceiro, como descrevemos com mais detalhe em contabilidade de produção upstream e alocação de barris, sente isto de forma particularmente aguda: a data de corte tem de coincidir com um fecho de período de produção, ou a alocação de barris a cada parceiro fica dividida de forma ambígua entre dois sistemas.

Os quatro falhanços clássicos

1. Dados-mestre duplicados

O problema mais comum não é a falta de dados — é o excesso. Um cliente que existe como três fichas diferentes porque foi introduzido três vezes ao longo de dez anos com pequenas variações no nome ou no NIF. Um artigo de inventário que existe como duas referências separadas porque duas pessoas diferentes o criaram em dois módulos diferentes do sistema antigo. Um fornecedor que aparece uma vez com o nome completo e outra vez com a abreviatura.

Cada duplicado migrado para o sistema novo não desaparece — multiplica-se. Um saldo de cliente que devia estar numa ficha aparece dividido em duas, nenhuma das quais reflecte a posição real. Um relatório de inventário mostra duas linhas para o mesmo parafuso, cada uma com uma quantidade parcial. A deduplicação de dados-mestre — clientes, fornecedores, artigos, activos fixos — tem de acontecer antes da extracção para o novo sistema, não depois, porque corrigir duplicados já com transacções lançadas em cima deles é uma operação de fusão de registos muito mais arriscada do que simplesmente não os duplicar em primeiro lugar.

2. Saldos que não fecham

Um saldo de conta corrente de cliente ou fornecedor no sistema antigo raramente é um número limpo. É normalmente a soma de anos de facturas, notas de crédito, pagamentos parciais e ajustamentos manuais — alguns dos quais podem ter sido lançados incorrectamente há anos e nunca corrigidos, simplesmente porque o saldo agregado "parecia" certo.

Migrar esse saldo agregado sem o reconciliar primeiro contra os extractos reais dos clientes e fornecedores significa migrar o erro, não corrigi-lo. E ao contrário do sistema antigo, onde um saldo desviado podia ser tolerado durante anos porque ninguém olhava para ele de perto, o sistema novo torna o problema visível rapidamente — porque os processos novos de reconciliação, de cobrança ou de retenção na fonte dependem de esse saldo estar correcto desde o dia um. Isto é especialmente relevante para retenções na fonte sobre serviços, onde o imposto retido e declarado tem de bater com o que consta da contabilidade — ver o que descrevemos em retenção na fonte sobre serviços petrolíferos e o que o ERP tem de calcular.

A reconciliação de saldos de abertura contra fontes externas e independentes — extractos bancários, confirmações de saldo com fornecedores, balancetes assinados pelo contabilista certificado do exercício anterior — não é um passo opcional de qualidade; é o único mecanismo que separa "o número que o sistema antigo dizia que era" de "o número que é realmente verdade".

3. Inventário que existe no sistema e não no armazém

Este é o falhanço mais caro de descobrir tarde, e também o mais previsível de evitar. O sistema antigo diz que há uma determinada quantidade de uma peça em stock; o armazém físico tem uma quantidade diferente. A diferença acumula-se ao longo de anos por razões banais — consumo não registado em manutenções de emergência, devoluções não lançadas, transferências entre armazéns registadas só num dos dois lados.

Migrar a quantidade do sistema sem uma contagem física prévia significa migrar a ficção, não o inventário real. Para operações com peças críticas de manutenção — o cenário que descrevemos em manutenção e MRO offshore, onde o inventário que ninguém consegue ver a tempo pode parar uma unidade — este tipo de discrepância tem um custo operacional directo: uma peça que o sistema diz estar disponível mas que fisicamente não existe transforma-se numa paragem não planeada no pior momento possível.

Há também um argumento regulatório concreto para levar isto a sério em Angola: o Decreto Presidencial n.º 71/25 criou a obrigação de submeter à Administração Geral Tributária um ficheiro SAF-T de inventário, com quantidade e valor contabilístico do stock a 31 de Dezembro do exercício anterior, até 15 de Fevereiro de cada ano (art. 24.º, n.º 1, alínea d)). É obrigatório para todos os contribuintes, mesmo os que não têm inventários. O primeiro ficheiro, com referência a 31 de Dezembro de 2025, teve o prazo prorrogado pela AGT para 15 de Abril de 2026 (EY Angola); segundo a Cegid, a AGT esclareceu ainda que o incumprimento relativo a 2025 não dará lugar a penalidades. Este ficheiro exige precisamente o que a migração devia ter garantido à partida: reconciliação entre o inventário físico, o registo contabilístico e a posição fiscal (Cegid). Um arranque de ERP que herda uma discrepância de inventário não resolvida está a herdar também um risco de conformidade que só se torna visível no ano seguinte, quando o ficheiro tiver de ser submetido.

A contagem física de inventário antes da migração não é um exercício de auditoria interna que se pode adiar — é o único momento em que corrigir a discrepância custa uma tarde de contagem, em vez de meses de investigação sobre porque é que os números nunca batem certo.

4. Histórico que ninguém validou porque estava "fora do âmbito"

A decisão de não migrar histórico transaccional completo é frequentemente correcta. O erro é assumir que "fora do âmbito da migração" significa também "fora do âmbito da validação". Se o histórico não vai ser migrado, mas os saldos de abertura derivam desse histórico, alguém tem de validar explicitamente que a soma das transacções históricas — mesmo ficando no sistema antigo — efectivamente produz o saldo que está a ser transportado para o sistema novo. Sem essa ponte documentada, o saldo de abertura é uma afirmação, não um facto verificado.

Isto importa particularmente para activos fixos com depreciação acumulada de vários anos, para contratos plurianuais e para qualquer posição que uma auditoria externa vá querer reconstruir. Um auditor que pede a origem de um saldo de abertura não aceita "é o que o sistema antigo dizia" como resposta — quer ver a reconciliação.

Um plano de validação que resiste à pressão do prazo

Fase	O que valida	Quando acontece
Limpeza de dados-mestre	Deduplicação de clientes, fornecedores, artigos, activos; um registo único por entidade real	Antes da extracção, nunca depois
Reconciliação de saldos	Cada saldo de abertura confirmado contra uma fonte externa independente (extracto bancário, confirmação de fornecedor, balancete assinado)	Antes da data de corte ser fixada
Contagem física de inventário	Quantidade real em armazém vs. quantidade no sistema antigo, por localização	Nas semanas imediatamente antes do corte
Ponte de histórico	Prova documentada de que o saldo migrado é a soma correcta do histórico não migrado	Antes do go-live, arquivada para auditoria
Gestão do período em trânsito	Lançamento duplicado ou processo de "mopping up" para transacções entre o corte de dados e o go-live real	Definido com responsável e prazo antes do corte
Carga de ensaio (dry run)	Migração completa para um ambiente de teste, validada linha a linha pelos donos de negócio, não só pela equipa técnica	Pelo menos um ciclo completo antes do go-live real

Nenhuma destas fases é opcional se o objectivo é um sistema que ainda está de pé três meses depois do arranque. Um erro frequente em projectos de modernização é comprimir estas fases para caber num prazo fixado antes de se saber o estado real dos dados legados — o que é ao contrário: o prazo devia depender do que os dados exigem, não o inverso.

Onde a experiência de motor ajuda

A Wise Hustlers desenvolve o Enerxia, o seu ERP para o sector petrolífero angolano — com módulos que cobrem upstream, poços, produção, projectos e contratos, aprovisionamento, fornecedores, inventário, MRO, manutenção, frota, logística, HSE, qualidade, recursos humanos, formação, finanças, fiscalidade e conformidade. Essa amplitude de módulos é relevante aqui por uma razão concreta: os problemas de migração de dados raramente ficam contidos num único módulo. Um saldo de inventário incorrecto afecta o custo de produção reportado; um saldo de cliente duplicado afecta a cobrança e a análise de risco de crédito; um activo mal migrado afecta a depreciação e o relatório fiscal. Projectar a migração módulo a módulo, sem visibilidade de como os dados atravessam o sistema inteiro, é uma das razões pelas quais problemas de dados descobertos num módulo só aparecem meses depois noutro.

Quando o sistema legado é antigo, mal documentado, ou uma colecção de folhas de cálculo e sistemas paralelos acumulados ao longo de anos — o cenário que tratamos com mais detalhe em sair do Excel e migrar operações petrolíferas para um ERP sem parar a produção — o trabalho de modernização legada não é apenas técnico: é decidir, dado por dado, o que é saldo, o que é histórico, e o que nunca deveria ter sido considerado "fora do âmbito". É esse o tipo de trabalho que fazemos em projectos de modernização de sistemas legados.

Perguntas Frequentes

Quanto tempo demora uma migração de dados para ERP?

Não há um número genérico responsável — depende inteiramente do estado dos dados-mestre, do número de contas a reconciliar e da profundidade de histórico que a auditoria exige manter acessível. Um projecto com dados-mestre limpos e poucas contas correntes por reconciliar é um exercício diferente de um com dez anos de duplicados acumulados. Qualquer fornecedor que dê um prazo fixo antes de ver o estado real dos dados legados está a adivinhar, não a estimar.

Precisamos mesmo de migrar todo o histórico transaccional?

Normalmente não. A prática mais defensável é migrar saldos de abertura reconciliados e manter o sistema antigo acessível em modo de leitura para consultas pontuais de histórico, em vez de replicar anos de transacções linha a linha no sistema novo. A decisão de não migrar histórico é legítima — o que não pode acontecer é essa decisão ser usada para justificar não validar os saldos que esse histórico produziu.

O que é o SAF-T de inventários e porque é que interessa a um projecto de migração?

É o ficheiro electrónico que as empresas em Angola têm de submeter anualmente à AGT, até 15 de Fevereiro, com a posição de inventário — quantidade e valor contabilístico — a 31 de Dezembro do ano anterior, ao abrigo do Decreto Presidencial n.º 71/25. O primeiro, referente a 31 de Dezembro de 2025, foi submetido em 2026 com prazo prorrogado para 15 de Abril. Interessa a uma migração de dados porque exige exactamente o que um bom projecto de migração já deveria ter feito: reconciliar o inventário físico com o registo contabilístico antes de confiar nos números.

Como se decide a data de corte certa?

A data de corte deve coincidir com um fecho de período contabilístico ou de produção já estabelecido — fim de mês ou fim de trimestre — e só deve ser fixada depois de as reconciliações de saldo e a contagem física de inventário estarem concluídas, não antes. Fixar a data primeiro e tentar fazer as reconciliações caber nesse prazo é a ordem errada de decisões.

Saldos de Abertura e Migração de Dados: O Arranque de ERP que Corre Mal Três Meses Depois