SAF-T (AO): Como Gerar o Ficheiro Contabilístico a Partir do Seu ERP Sem Reconciliações Manuais | Blog

# SAF-T (AO): Como Gerar o Ficheiro Contabilístico a Partir do Seu ERP Sem Reconciliações Manuais

TL;DR: o SAF-T (AO) de contabilidade é um ficheiro diferente do SAF-T de facturação, tem prazo próprio (10 de abril, dados do exercício anterior) e a facturação eletrónica não o dispensa — só reduz a obrigação de comunicar facturas por SAF-T. Se o seu plano de contas operacional não estiver desenhado para gerar este ficheiro automaticamente, vai fechá-lo à mão todos os anos.

Há uma confusão fácil de fazer, e cara: tratar "SAF-T" como um ficheiro único. Não é. A Administração Geral Tributária (AGT) exige dois ficheiros SAF-T (AO) distintos, com propósitos, estruturas e prazos diferentes — e a reforma trazida pelo Decreto Presidencial n.º 71/25, de 20 de março de 2025, que introduziu a facturação eletrónica obrigatória, tornou essa distinção ainda mais importante de perceber corretamente.

Este artigo é escrito do ponto de vista de quem constrói sistemas ERP para o sector — não do ponto de vista fiscal ou jurídico. O objetivo é explicar o problema real de engenharia: como um ERP que já tem contabilidade, obras/projectos, poços, contratos e inventário consegue produzir este ficheiro sem que a equipa financeira passe semanas a reconciliar números em Excel antes de cada submissão.

Dois ficheiros, dois propósitos

O SAF-T (AO) existe em duas variantes que a AGT trata de forma distinta:

SAF-T de Facturação — extrai os documentos de venda (facturas, notas de crédito/débito, recibos) de um período, com uma estrutura orientada a documentos comerciais.
SAF-T de Contabilidade — extrai a totalidade dos movimentos contabilísticos de um exercício fiscal completo: plano de contas, terceiros (clientes/fornecedores), tabela de impostos e todos os lançamentos do razão geral, com uma chave única associada a cada transação.

São gerados por módulos diferentes do sistema (facturação vs. contabilidade geral), submetidos em momentos diferentes do ano e servem propósitos de fiscalização diferentes. Confundir os dois — ou assumir que resolver um resolve o outro — é o erro mais comum que vemos em equipas que se preparam para a submissão pela primeira vez.

O prazo que importa: 10 de abril, dados do ano anterior

Segundo a EY Angola, o SAF-T (AO) de contabilidade é de submissão obrigatória até ao dia 10 de abril de cada ano, com dados respeitantes ao exercício fiscal do ano transacto — ou seja, o ficheiro entregue em abril de 2026 cobre a totalidade dos movimentos contabilísticos de 2025 (EY Angola).

Há aqui uma nuance de calendário que convém não ignorar, porque muda o que é urgente. A AGT concedeu um período de adaptação: a submissão do ficheiro de contabilidade relativa ao exercício de 2025 é facultativa e não gera penalidades; a obrigatoriedade aplica-se ao exercício de 2026, a entregar em 2027 (KPMG Angola). Isso não é um adiamento do problema — é a única janela em que se pode gerar o ficheiro, ver o que parte, e corrigir o plano de contas sem coima. A estrutura de dados exigida consta do Decreto Executivo n.º 317/20, de 14 de Dezembro.

Este prazo corre em paralelo com o do SAF-T de Inventários, que tem submissão anual prevista para 15 de fevereiro do ano seguinte — embora a AGT já tenha prorrogado esse prazo para 15 de abril de 2026 no que respeita ao exercício de 2025 (EY Angola). Na prática, os dois ficheiros — contabilidade e inventários — acabam a cair praticamente na mesma janela do calendário financeiro, o que aumenta a pressão sobre equipas que ainda dependem de fecho manual.

Não confie de olhos fechados num prazo fixo publicado num blog de terceiros: a AGT tem historial de ajustar datas por comunicado. O que é estável é o princípio — o ficheiro cobre sempre o exercício anterior e é exigido anualmente, não por evento.

Facturação eletrónica não substitui o SAF-T de contabilidade

Esta é a confusão central que o briefing deste artigo pede para desfazer, e a resposta curta é: a facturação eletrónica dispensa parte do SAF-T de facturação, nunca o SAF-T de contabilidade.

O Decreto Presidencial 71/25 e o Decreto Executivo n.º 683/25, de 22 de agosto de 2025 (que define a estrutura de dados do software de facturação e as especificações técnicas do modelo de comunicação), tornam obrigatória a emissão e comunicação de facturas eletrónicas a partir de 1 de janeiro de 2026 para grandes contribuintes, fornecedores do Estado e contribuintes que emitam facturas de valor igual ou superior a 25 milhões de Kwanzas. Para os restantes contribuintes, a obrigatoriedade só entra em vigor a 1 de janeiro de 2027, com adesão voluntária possível durante 2026 (EY Angola; Cegid Angola).

O que muda com a adesão à facturação eletrónica, segundo a Cegid Angola, é que "a partir da adesão à facturação eletrónica, a comunicação de faturas por SAF-T apenas ocorrerá caso a AGT o solicite" — isto é, deixa de haver uma obrigação regular de submeter o SAF-T de facturação, porque a AGT já recebe os documentos em tempo real através do software certificado, com validação a posteriori (Cegid Angola).

Isto não tem qualquer efeito sobre o SAF-T de contabilidade. A contabilidade continua a ser um exercício anual de fecho, consolidação e extração do razão geral — nada disto é substituído por comunicar facturas em tempo real. Uma operadora ou EPC que já tenha aderido à facturação eletrónica e pense que "já trata do SAF-T" está a confundir os dois ficheiros, e vai ser apanhada de surpresa em abril quando lhe pedirem o ficheiro de contabilidade.

O problema real de engenharia: mapear o plano de contas operacional

É aqui que a maior parte do esforço se concentra — e onde a maior parte dos projectos de SAF-T falha silenciosamente até ser tarde demais.

O plano de contas de referência em Angola é o Plano Geral de Contabilidade Angolano (PGCA), aprovado pelo Decreto n.º 82/01, de 16 de novembro, estruturado em classes (existências, terceiros, meios monetários, capital e reservas, proveitos, custos, resultados, entre outras). É a partir desta estrutura que a AGT espera reconhecer as contas no ficheiro SAF-T. O problema é que nenhum ERP de gestão de operações de petróleo e gás usa o PGCA em estado puro.

Um ERP construído para upstream, produção, projectos/contratos, procurement e manutenção normalmente organiza o razão geral com dimensões adicionais sobrepostas ao plano de contas: centro de custo por poço ou campo, código de projeto/contrato (para partilha de custos com parceiros de um Joint Operating Agreement), classe de ativo para MRO e frota, e códigos de imposto retido na fonte aplicados por tipo de fornecedor. Nenhuma destas dimensões existe no PGCA — e o SAF-T não tem campo para "poço" ou "AFE" (Authorization for Expenditure). O trabalho de engenharia é justamente esse: decidir, conta a conta, para onde cada combinação de conta + centro de custo + dimensão analítica é mapeada na estrutura de contas exigida pelo ficheiro, sem perder a granularidade que a operação precisa internamente.

Três problemas concretos aparecem sistematicamente neste mapeamento:

1. Contas "genéricas" a mais. Equipas financeiras, sob pressão de prazos, criam contas de "diversos" ou "outros" para não interromper o fecho mensal. Essas contas não têm correspondência clara no PGCA e obrigam a reclassificação manual retroativa antes de gerar o SAF-T — exatamente o trabalho que o ficheiro devia eliminar.

2. [Multi-moeda](https://wise-hustlers.com/blog/erp-multi-moeda-aoa-usd-operacoes-petroliferas) sem taxa de câmbio rastreável ao lançamento. Contratos em USD, despesas locais em Kwanza, e um SAF-T que exige valores na moeda de reporte com rastreabilidade ao câmbio aplicado em cada transação. Se o ERP guarda apenas o saldo convertido e não a taxa usada linha a linha, a reconciliação tem de ser refeita a posteriori.

3. Chave única por transação. O SAF-T (AO) exige uma chave/hash único associado a cada lançamento. Sistemas onde os lançamentos são editáveis depois de posted, ou onde há reprocessamento de fecho, quebram esta unicidade e geram ficheiros que a AGT rejeita na validação.

Nenhum destes problemas é sobre "gerar XML" — a exportação em si é trivial depois de o modelo de dados estar correto. O trabalho difícil é garantir, mês a mês, que o razão geral operacional já nasce mapeável, e não corrigido à mão em março.

O que corre mal quando a contabilidade vive em Excel

O caso mais difícil é o da empresa de serviços petrolíferos que ainda opera a contabilidade parcialmente em folhas de cálculo, com o ERP a cobrir apenas operações (procurement, inventário, frota) e a contabilidade a ser consolidada manualmente fora do sistema. Aí acumulam-se quatro problemas de uma vez:

O razão geral "oficial" nunca corresponde exatamente ao operacional. Ajustes manuais feitos em Excel para fechar o mês não voltam a ser lançados no ERP, pelo que o SAF-T extraído do sistema fica sistematicamente desalinhado do que foi reportado à AGT no ano anterior.
Não existe chave estável por lançamento. Uma folha de Excel não gera identificadores únicos nem impede reedição de valores já fechados — o requisito mínimo do SAF-T.
O fecho de exercício demora semanas, não dias, porque a reconciliação entre o operacional (ERP) e o contabilístico (Excel) só acontece uma vez por ano, sob pressão do prazo de 10 de abril, em vez de ser um subproduto automático do fecho mensal.
A auditoria à posteriori é impossível de defender. Quando a AGT pede o detalhe de uma linha do SAF-T, a equipa financeira tem de reconstruir manualmente a origem do número — porque o número nunca existiu como um lançamento único e rastreável dentro de um único sistema.

A causa raiz não é falta de disciplina contabilística — é a ausência de um único sistema de registo. Enquanto a contabilidade "real" viver parcialmente fora do ERP, gerar SAF-T vai continuar a ser um projeto anual de reconciliação, não uma exportação.

Como estruturar a extração SAF-T a partir do ERP

A Wise Hustlers constrói e opera o seu próprio ERP para o sector energético. A abordagem que daí resulta trata isto como um problema de engenharia de dados aplicado à contabilidade, e não como uma funcionalidade de "exportar relatório":

1. Um único plano de contas operacional, mapeado ao PGCA na origem. Cada conta nova criada no ERP tem, desde o momento em que é criada, uma correspondência definida com a estrutura de contas exigida — não é um exercício de tradução feito em abril.

2. Dimensões analíticas (poço, contrato, centro de custo) como atributos do lançamento, não como contas separadas. Isto preserva a granularidade operacional sem poluir o plano de contas com contas artificiais criadas só para reporting.

3. Câmbio e chave única geridos ao nível do lançamento, não do saldo. Cada linha do razão geral guarda a taxa aplicada e um identificador imutável, gerado no momento do posting.

4. Geração do ficheiro como job agendado e testável, não como script manual. O SAF-T deixa de ser um evento anual de pânico e passa a ser algo que se pode gerar (e validar contra o exercício anterior) todos os meses, para apanhar desvios cedo.

É este tipo de trabalho — desenhar o modelo de dados contabilístico e as pipelines de extração para que os ficheiros regulatórios saiam corretos da primeira vez — que fazemos no nosso serviço de Data Analytics, aplicado especificamente a ERPs operacionais do sector energético.

Checklist antes da submissão

O plano de contas do ERP tem uma correspondência documentada e testada com a estrutura de contas do PGCA?
Cada lançamento tem uma chave única gerada no momento do posting, e essa chave sobrevive a reprocessamentos de fecho?
As taxas de câmbio aplicadas estão guardadas ao nível da transação, não apenas do saldo final?
Existem ajustes de fecho feitos fora do ERP (Excel, email) que nunca voltam a ser lançados no sistema?
O ficheiro foi gerado e validado contra um exercício fechado antes do prazo de 10 de abril, com tempo para corrigir desvios?
Se a empresa já aderiu à facturação eletrónica, a equipa sabe que isso não dispensa o SAF-T de contabilidade?

Perguntas frequentes

O SAF-T de contabilidade e o SAF-T de facturação têm o mesmo prazo?

Não. Têm estruturas, propósitos e calendários de submissão distintos. O de contabilidade tem prazo até 10 de abril, com dados do exercício anterior; o de facturação passa a ser comunicado apenas a pedido da AGT depois de a empresa aderir à facturação eletrónica.

Se já emito facturas eletrónicas, fico dispensado de gerar SAF-T?

Fica dispensado da submissão regular do SAF-T de facturação. Continua obrigado ao SAF-T de contabilidade todos os anos, porque este cobre o razão geral completo, não apenas os documentos de venda.

A partir de quando é obrigatória a facturação eletrónica?

Desde 1 de janeiro de 2026 para grandes contribuintes, fornecedores do Estado e contribuintes que emitam facturas de valor igual ou superior a 25 milhões de Kwanzas. Para os restantes, a obrigatoriedade entra em vigor a 1 de janeiro de 2027, com adesão voluntária possível em 2026.

O que é mais difícil de resolver tecnicamente — a exportação do ficheiro ou o mapeamento do plano de contas?

O mapeamento. A exportação em XML é um problema resolvido assim que o modelo de dados está correto. O trabalho real está em garantir que cada conta, centro de custo e lançamento no ERP já nasce mapeável à estrutura exigida, sem depender de reclassificação manual antes da submissão.