Extrair SAF-T PT Faturação para Excel: guia prático

Para extrair SAF-T PT faturação para Excel de forma útil para contabilidade, não basta despejar o XML numa folha. O output de trabalho deve separar o ficheiro em três folhas: Header, com um cabeçalho por documento; Lines, com uma linha por artigo ou serviço faturado; e Tax summary, com a base tributável e o IVA por taxa, tipo de documento e período.

Essa estrutura permite filtrar documentos anulados, rever notas de crédito e notas de débito, validar totais e criar tabelas dinâmicas para conferência com e-Fatura e declaração periódica. O ponto é transformar o SAF-T-PT de Faturação num livro Excel analisável, não substituir o ficheiro oficial nem a submissão no Portal das Finanças.

A própria Autoridade Tributária enquadra o SAF-T(PT) como um ficheiro normalizado em XML para exportar registos contabilísticos, de faturação, documentos de transporte e recibos num formato comum, independentemente do programa usado, na definição oficial do SAF-T(PT) pela AT. Para o gabinete, essa normalização é a oportunidade: TOConline, Moloni, Primavera, PHC, CentralGest, Artsoft ou outro programa certificado podem ter ecrãs diferentes, mas o ficheiro exportado segue uma lógica comum.

O Excel certo para trabalho mensal costuma ter esta leitura:

• Header: uma linha por fatura, nota de crédito, nota de débito ou outro documento relevante, com cliente, data, tipo, estado, hash e totais.
• Lines: uma linha por linha de documento, ligada ao cabeçalho por InvoiceNo, para analisar produtos, descrições, quantidades, preços e IVA linha a linha.
• Tax summary: uma agregação por taxa de IVA, código de imposto, tipo de documento e mês, pronta para revisão e quadratura.

Esta abordagem também evita uma confusão comum: converter SAF-T PT para Excel contabilidade não é o mesmo que validar SAF-T para entrega à AT. A validação confirma se o ficheiro cumpre regras técnicas e fiscais; o workbook serve o contabilista depois da exportação, quando precisa de filtrar, reconciliar, justificar diferenças e preparar trabalho interno com dados verificáveis.

Que campos do XML alimentam cada folha de Excel

A folha Header é a vista de gestão documental. Deve ter uma linha por documento em SourceDocuments/SalesInvoices/Invoice, com campos suficientes para identificar, filtrar e reconciliar o documento: InvoiceNo, InvoiceDate, InvoiceType, CustomerID, DocumentStatus, Hash, ATCUD quando disponível, número de certificação, Period, NetTotal, TaxPayable e GrossTotal. Quando o ficheiro inclui fornecedores ou outras entidades relevantes, os dados de MasterFiles/Supplier podem seguir o mesmo princípio, mas a maioria dos SAF-T-PT de Faturação trabalha sobretudo com MasterFiles/Customer.

Os totais vêm de SourceDocuments/SalesInvoices/Invoice/DocumentTotals. O cliente vem de MasterFiles/Customer, ligado pelo CustomerID. A informação de contexto do ficheiro, como empresa, NIF, período e software de origem, vem de AuditFile/Header. Estes campos não precisam de aparecer todos em todas as análises, mas devem ficar disponíveis no workbook para auditoria interna e para explicar diferenças quando o total do mês não bate à primeira.

A folha Lines é onde a extração ganha valor para análise. Cada SourceDocuments/SalesInvoices/Invoice/Line deve gerar uma linha própria no Excel, repetindo o InvoiceNo para manter a ligação ao cabeçalho. As colunas mínimas são ProductCode, Description, Quantity, UnitPrice, DebitAmount ou CreditAmount, TaxPercentage, TaxCode e SettlementAmount. Quando o produto existe em MasterFiles/Product, convém trazer também a descrição ou código normalizado, porque a linha de fatura pode vir abreviada ou escrita de forma diferente entre clientes.

A folha Tax summary não deve ser uma cópia dos totais de documento. Deve ser calculada a partir das linhas e da TaxTable, agregando por mês, InvoiceType, TaxCode, TaxPercentage, base e imposto. É aqui que a conversão deixa de ser puramente técnica e passa a ser material de trabalho: o contabilista vê a decomposição por taxa normal, intermédia, reduzida, Açores, Madeira ou isenção, conforme o conteúdo real do ficheiro.

Erros que distorcem totais quando o XML é achatado

O primeiro erro é apagar documentos anulados. Um InvoiceStatus = A deve ficar no workbook, porque faz parte do rasto documental, mas não deve entrar nos totais correntes como se fosse uma fatura válida. A solução prática é uma coluna de estado clara e uma vista de análise que exclua anuladas por defeito, mantendo outra vista para revisão de sequência, hash e justificações.

Notas de crédito e notas de débito também não podem ser tratadas como faturas normais. Uma NC deve reduzir a faturação ou corrigir imposto, enquanto uma ND aumenta ou corrige valores a favor do emitente. Se o conversor deixar todos os GrossTotal como positivos sem sinal analítico, a tabela dinâmica mostra volume bruto, não posição líquida. O workbook deve ter InvoiceType, sinal contabilístico e montantes normalizados para análise, preservando os valores originais para conferência.

As faturas com várias taxas de IVA são outra fonte de erro. Um documento pode ter uma linha a 23%, outra a 6% e uma verba isenta. Se o resumo de IVA for criado apenas a partir do cabeçalho, perde-se a decomposição que interessa para análise fiscal. A base deve vir das linhas: TaxCode, TaxPercentage, DebitAmount ou CreditAmount, SettlementAmount e imposto associado.

IVA de caixa merece marca própria. A fatura existe no SAF-T-PT de Faturação, mas a leitura fiscal depende do regime e do momento relevante para exigibilidade. Para trabalho de gabinete, uma coluna que identifique IVA caixa evita misturar documentos que entram diretamente na análise normal com documentos que exigem revisão adicional.

WorkingDocuments e Payments devem ser tratados como famílias separadas. Um orçamento, consulta de mesa ou documento de trabalho pode ajudar a entender operação e rotatividade, mas não é automaticamente faturação para IVA. Um pagamento com vários PaymentMethod pode explicar recebimento em numerário e cartão no mesmo documento, mas, se for ligado sem regra, multiplica totais na folha. O modelo de Excel deve deixar claro o que é documento fiscal, o que é documento operacional e o que é detalhe de pagamento.

Usar o Excel para IVA, e-Fatura e análise mensal

Quando o workbook está bem estruturado, a primeira leitura é simples: faturação por cliente e por mês na folha Header, detalhe por produto ou serviço na folha Lines, e IVA por taxa na Tax summary. Esta separação permite responder depressa a perguntas que aparecem no fecho: quais foram os clientes com maior volume, que notas de crédito afetaram o mês, que documentos anulados continuam no ficheiro e que taxas de IVA compõem o total.

Para trabalho de IVA, a Tax summary deve separar base tributável e imposto por TaxCode, TaxPercentage, InvoiceType e período. Em muitos casos, essa decomposição ajuda a rever os montantes que vão alimentar a declaração periódica, incluindo leituras por taxa associadas a campos como 1/2, 5/6 e 9/10 quando a operação se enquadra nesses blocos. Quando entram faturas de empreitadas ou subempreitadas, a mesma revisão deve isolar as faturas de subcontratados com autoliquidação do IVA na construção. O Excel não decide o tratamento fiscal; dá ao contabilista uma base rastreável para rever antes de preparar a declaração periódica de IVA a partir de faturas.

A comparação com e-Fatura ganha qualidade quando o SAF-T já está achatado. Depois de descarregar o CSV do Portal das Finanças, o gabinete consegue cruzar NIF, data, número de documento, ATCUD ou QR Code quando existirem no processo, total e imposto com as colunas do workbook; nas compras, o mesmo controlo passa por validar ATCUD e QR Code nas faturas recebidas antes de lançar ou deduzir IVA. As diferenças deixam de ser uma caça manual no XML: aparecem como linhas não conciliadas, totais divergentes ou documentos com estado diferente.

A mesma base serve análise de carteira. Com CustomerID, NIF, nome e período, uma tabela dinâmica mostra rotatividade de clientes, concentração de faturação e clientes sem movimento recente. Quando há inconsistências de master data, por exemplo o mesmo NIF com nomes ligeiramente diferentes, o cruzamento torna-se visível. Esse detalhe é difícil de ver num conversor que entrega apenas uma folha plana sem separação entre documento, linha e cliente.

---

Conversor simples, Excel controlado ou extração assistida

Um conversor SAF-T para Excel chega quando o pedido é pontual: um ficheiro, um mês, colunas standard e pouca necessidade de rever regras. Se o objetivo é apenas abrir o XML e descarregar um XLSX para consulta rápida, a ferramenta mais direta costuma ser a melhor. O risco começa quando o gabinete passa a usar esse output como base recorrente para IVA, análise por cliente ou comparação entre clientes.

Nesses casos, a pergunta deixa de ser converter o ficheiro: passa a ser obter sempre o mesmo workbook, com as mesmas folhas, os mesmos sinais e as mesmas colunas. Um contabilista que trabalha com dezenas de clientes precisa de consistência: Header separado de Lines, Tax summary calculada por linha, colunas para anuladas, NC/ND e IVA caixa, e uma forma de rever exceções sem reconstruir o ficheiro todos os meses.

A pesquisa por SAF-T-PT para Excel sem programa costuma esconder duas necessidades diferentes. Uma é evitar instalações locais, sobretudo quando o gabinete tem vários colaboradores ou máquinas. A outra é não ficar preso ao export de um único software de faturação. O SAF-T resolve parte desse segundo problema porque cria uma base comum entre programas certificados, mas o Excel final continua a precisar de regras próprias do gabinete.

Invoice Data Extraction entra noutra camada do trabalho financeiro. Não substitui um conversor SAF-T XML, não valida o ficheiro para a AT e não substitui o programa certificado que exporta o SAF-T. O seu papel é a extração de dados de faturas para Excel quando o gabinete tem faturas, recibos, extratos ou outros documentos financeiros em PDF, JPG ou PNG que ficam fora do SAF-T ou precisam de tratamento paralelo. Aí, prompts reutilizáveis, escolha de campos, nomes de colunas e output em Excel, CSV ou JSON ajudam a manter o mesmo modelo de dados em documentos que não vêm num XML normalizado.

Esta distinção evita escolhas erradas. Para SAF-T bruto, a conversão deve respeitar o schema e preservar o rasto fiscal. Para documentos financeiros não estruturados, a extração deve ser orientada por campos e regras. Para o trabalho mensal completo, os dois fluxos podem alimentar o mesmo ambiente de Excel, desde que as origens e limitações de cada um fiquem claras.

Fluxo recomendado para gabinetes com vários clientes

Num gabinete com clientes em TOConline, Moloni, Primavera, PHC, CentralGest, Artsoft e outros programas certificados, o SAF-T-PT funciona como camada de unificação. A origem muda, o ecrã de exportação muda, mas o ficheiro mensal segue uma estrutura comum. O ganho está em transformar essa estrutura num workbook standard do gabinete, sempre com as mesmas folhas e regras. Quando, fora do SAF-T, o cliente entrega apenas relatórios em PDF do ERP — extrato de conta, balancete ou razão — vale a pena ter um fluxo paralelo para passar relatórios PDF do Primavera BSS para Excel preservando débito, crédito e saldo.

O fluxo mensal pode ser direto. Receber o SAF-T de Faturação por cliente e período. Guardar o XML original no arquivo digital, com NIF, mês, origem e data de receção. Converter para o workbook standard. Rever totais de Header contra DocumentTotals. Confirmar sinais de NC/ND, documentos anulados, IVA de caixa e taxas de IVA. Guardar o Excel final com versão e estado de revisão, para que outra pessoa consiga perceber que ficheiro foi usado e que exceções ficaram assinaladas.

Um padrão de nome de ficheiro com NIF, ano, mês, origem e estado evita dúvidas quando há reenvio de SAF-T ou correção após fecho — e o mesmo princípio vale para colunas de cliente, período, origem e observações de revisão na folha.

O SAF-T não cobre toda a contabilidade do cliente. Extratos bancários continuam a exigir outro fluxo, por isso faz sentido manter um modelo separado para converter extratos bancários PDF para Excel. A área de payroll também vive fora do SAF-T de Faturação; quando o gabinete trata salários, pode precisar de extrair recibos de vencimento para preparar a DMR. Recibos verdes de prestadores, faturas de fornecedores em PDF e documentos de suporte seguem a mesma lógica — quando a entrada é um lote de faturas em PDF, transformar essas faturas em linhas de Excel com NIF, base e IVA por documento cobre o que fica fora do SAF-T, e extrair retenção na fonte de recibos verdes de fornecedores ilustra a versão do método aplicada ao lado dos pagamentos a categoria B. Cada origem tem o seu método, mas o destino deve ser uma base estruturada e conferível.

Para gabinetes, a disciplina não está em escolher uma única ferramenta para tudo. Está em definir que dados entram no workbook, que regras tratam exceções e que rasto fica guardado para justificar o trabalho meses depois.