Por que Receber uma Fatura XML Não Acaba com a Extração Manual de Dados de AP

Na Bélgica, mais de um milhão de empresas se registraram na rede Peppol nas primeiras semanas de 2026. A Croácia processou quatro milhões de faturas eletrônicas nos primeiros vinte e oito dias. Treze países da UE agora exigem faturamento eletrônico obrigatório, e mais sete se juntarão a eles antes do final de 2027. A narrativa que acompanha essas implementações tem sido consistente: faturas XML estruturadas eliminarão a entrada manual de dados, reduzirão erros e proporcionarão processamento direto. Mas quando a Ardent Partners pesquisou 204 organizações de AP para seu relatório State of ePayables de 2025, os números contaram uma história diferente. Apenas 51,4% das faturas chegaram eletronicamente. Apenas 35,4% foram processadas diretamente sem intervenção humana. E 66% das equipes de AP ainda inserem manualmente dados de faturas em seu ERP — um número que subiu em relação ao ano anterior, não caiu. Este artigo examina a lacuna entre o que a fatura eletrônica prometeu e o que as equipes de AP realmente experimentam, e por que essa lacuna é estrutural, não transitória.

A Caixa-Preta: O Que Acontece Depois que uma Nota Fiscal XML Chega na Sua Caixa de Entrada

Uma nota fiscal eletrônica não é apenas um documento digital. É um pacote de dados — um arquivo XML ou UBL estruturado que transporta informações da nota fiscal em campos legíveis por máquina, de acordo com o padrão europeu EN 16931, publicado em 2017 pelo Comitê Europeu de Normalização (CEN/TC 434). O padrão define mais de 160 campos de dados semânticos: número da nota fiscal, data de emissão, identificadores fiscais do vendedor e comprador, quantidades de itens, preços unitários, categorias de IVA, condições de pagamento, endereços de entrega e assim por diante. Na teoria, esse pacote estruturado deveria fluir diretamente do sistema do fornecedor para o ERP do comprador — sem olhos humanos, sem teclado, sem copiar e colar.

A teoria falha logo no primeiro passo: seu ERP.

A maioria dos sistemas ERP — SAP, Oracle NetSuite, Microsoft Dynamics 365, Workday — não processa XML EN 16931 bruto nativamente. Eles esperam dados de nota fiscal em seu próprio formato interno, mapeados para seus próprios nomes de campo, por meio de sua própria API ou modelo de importação. Uma nota fiscal Peppol BIS 3.0 chega como XML UBL 2.1 com uma estrutura de tag como <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>. Seu ERP espera um campo chamado Tipo de Nota Fiscal com um valor de Nota Fiscal Comercial. Alguém — ou algo — precisa traduzir. Essa camada de tradução é o que a narrativa da fatura eletrônica trata como um problema resolvido. Para muitas equipes de AP, não está resolvido. É para onde o trabalho manual se move, não onde termina.

De acordo com o relatório de mercado Billentis/EESPA cobrindo 2019-2025, menos de 20% das empresas enviam faturas eletrônicas estruturadas via EDI ou redes equivalentes. Cerca de dois terços emitem faturas em PDF por e-mail. Mesmo entre as empresas que recebem XML de notas fiscais, os dados raramente chegam ao ERP sem uma etapa intermediária: uma plataforma de middleware, um ponto de acesso Peppol, uma camada de integração ou — no caso dos 66% das equipes de AP que ainda fazem entrada manual — um par de olhos humanos lendo a partir de uma representação visual do XML e digitando em uma tela. A nota fiscal eletrônica é estruturada. A última milha não é.

Uma nota fiscal eletrônica é legível por máquina por design. Seu ERP é legível por máquina por design. O problema é que eles não foram projetados para se lerem. Entre eles existe uma camada de integração que alguém precisa construir, configurar e manter — e para um número surpreendente de equipes de AP, essa camada ainda é uma pessoa.

Uma Fatura, 164 Campos, 6 Que Você Realmente Precisa

A EN 16931 especifica o que uma fatura eletrônica deve ou pode conter, e a lista é extensa: entidades legais do vendedor e comprador, representante fiscal, beneficiário, informações de entrega, instruções de pagamento, detalhes de abatimentos e acréscimos, discriminação de impostos por item, período da fatura, referência do pedido, referência do contrato, referência do projeto e muito mais. Uma fatura EN 16931 totalmente preenchida contém bem mais de 100 pontos de dados distintos em vários níveis hierárquicos aninhados.

Sua equipe de Contas a Pagar precisa de seis deles.

Os campos que seu ERP realmente exige para lançamento — nome do fornecedor, número da fatura, data da fatura, valor líquido, valor do IVA, data de vencimento — são um pequeno subconjunto do que o XML contém. Os outros 150+ campos são ruído. Eles existem para validação pela autoridade fiscal, para a lógica de roteamento da rede Peppol, para a conformidade arquivística do fornecedor. Eles não existem para você. Mas toda integração que faz uma importação XML completa os puxa todos, e alguém precisa mapear, validar e manter esses mapeamentos para cada fornecedor, cada país e cada variante de esquema XML.

Essa realidade aponta para um problema econômico contraintuitivo que a maioria dos modelos de ROI de faturamento eletrônico ignora. O custo de configurar e manter mapeamentos completos de esquemas XML em dezenas ou centenas de fornecedores pode exceder o custo de simplesmente extrair os seis campos que você precisa de qualquer formato de documento — XML, PDF ou imagem. A infraestrutura de faturamento eletrônico foi construída para fechar a lacuna de informação da autoridade fiscal. Não foi construída para fechar a lacuna de extração de dados da sua equipe de Contas a Pagar. Esses são dois problemas diferentes, e resolver o primeiro não resolve automaticamente o segundo.

O relatório de pesquisa de faturamento eletrônico da Vertex 2025 entrevistou empresas em mercados obrigatórios e descobriu que a integração de tecnologia é o principal ponto de dor para 55% dos entrevistados, subindo para 63% entre empresas que operam em vários países. Metade de todos os entrevistados sinalizou a governança de dados como uma preocupação significativa. Estas não são empresas que falharam em adotar o faturamento eletrônico. São empresas que o adotaram e agora estão lidando com o que vem depois.

O número de campos em uma fatura eletrônica que sua equipe de Contas a Pagar não precisa não é uma curiosidade técnica. É a razão pela qual a importação XML completa é frequentemente mais cara do que a extração seletiva. Cada campo que você não precisa é um campo pelo qual você paga para mapear, validar e manter — em cada fornecedor, cada esquema e cada ciclo de atualização do ERP.

Quatro Países, Quatro Dialetos XML, Uma Única Caixa de Entrada de AP

EN 16931 é um padrão, não um formato. Ele define o significado semântico dos campos da fatura e permite duas sintaxes: UBL 2.1 e UN/CEFACT Cross Industry Invoice (CII). Cada país então publica uma CIUS — uma Especificação de Uso de Fatura Principal — que adapta o padrão às regras fiscais nacionais, adicionando ou endurecendo requisitos de campo. O resultado é um cenário onde quatro esquemas XML estruturalmente diferentes podem chegar na mesma caixa de entrada e todos serem "conformes com EN 16931", mas serem incompatíveis entre si nos mapeamentos de importação.

País	Esquema / Formato	Base de Sintaxe	Contêiner	O Que o Torna Diferente
Alemanha	XRechnung	UBL 2.1 ou CII	XML Puro	Sem camada visual. Obrigatório para B2G, expandindo para B2B até 2028. O campo para data de serviço não é explicitamente obrigatório, mas o destinatário deve validá-lo conforme §14 UStG (Lei do IVA Alemã) — uma lacuna de conformidade que impede o processamento sem toque.
Alemanha & França	ZUGFeRD / Factur-X	CII D22B	PDF/A-3 com XML incorporado	Formato híbrido. Cinco perfis de MÍNIMO (apenas dados do cabeçalho) a ESTENDIDO (detalhe completo do item de linha). Discrepâncias entre a camada visual do PDF e o XML incorporado são um risco operacional documentado.
Itália	FatturaPA	XML Personalizado	XML Puro via SdI	Anterior ao EN 16931. Obrigatório desde 2019 para todos B2B, B2C, B2G. Usa seu próprio esquema XML com campos específicos italianos (códigos de contratação CIG, CUP) que não têm equivalente em outros esquemas nacionais.
Polônia	KSeF FA(3)	XML Proprietário	XML Puro via plataforma nacional	Modelo de liberação em tempo real. A autoridade fiscal valida cada fatura antes da entrega. O esquema XML é o formato FA(3) — sucessor do FA(2) — e não está alinhado com a sintaxe UBL ou CII.

Se sua empresa opera na Alemanha, França, Itália e Polônia — uma presença que descreve milhares de empresas europeias de médio porte — sua caixa de entrada de AP recebe quatro esquemas XML estruturalmente diferentes que todos se autodenominam faturas eletrônicas. Você precisa de quatro mapeamentos de importação separados, quatro conjuntos de regras de validação e quatro pipelines de manutenção que quebram sempre que uma autoridade fiscal nacional atualiza seu esquema. A cadência de atualização não é teórica. A migração do KSeF da Polônia de FA(2) para FA(3) exigiu que todo sistema integrado remapeasse suas definições de campo. A França atualizou seus requisitos PPF entre a fase piloto de 2025 e o lançamento em 2026. A especificação XRechnung da Alemanha está na versão 3.0.1 no início de 2026.

Este não é um argumento contra a faturação eletrónica. É um argumento contra a suposição de que receber dados estruturados significa receber dados na sua estrutura. O padrão EN 16931 foi concebido para a interoperabilidade entre autoridades fiscais, não entre o ERP do seu fornecedor e o seu. A camada CIUS nacional existe precisamente porque o código fiscal de cada país exige campos, códigos e validações diferentes. A interoperabilidade a nível fiscal não garante interoperabilidade a nível do fluxo de trabalho de contas a pagar (AP) — e a lacuna entre essas duas coisas é onde as equipas de AP vivem todos os dias.

Se está a criar um pipeline de importação XML separado para cada país onde os seus fornecedores operam, está a resolver um problema que se multiplica a cada nova obrigação legal. A alternativa — ler o que está realmente na fatura, em vez de qual esquema a gerou — reduz todos os quatro países a um único pipeline de extração.

O PDF Que Não Vai Desaparecer

O cronograma das obrigações de faturação eletrónica está a acelerar. A Bélgica entrou em vigor em janeiro de 2026 com âmbito quase universal. A Polónia seguiu em fevereiro para grandes contribuintes. A França ativa em setembro de 2026 para empresas grandes e médias. A obrigação B2B da Alemanha é faseada até 2028. Para uma análise detalhada de cada prazo e sua base legal, consulte o nosso cronograma de obrigações de faturação eletrónica na Europa.

Mas toda obrigação contém exclusões, e essas exclusões produzem um resíduo de PDF que nenhum prazo futuro eliminará. O padrão é consistente entre jurisdições:

Fornecedores transfronteiriços estão isentos. Uma empresa alemã que recebe faturas de um fornecedor dos EUA ou da China não é abrangida por nenhuma obrigação de faturação eletrónica da UE. Esses fornecedores continuarão a enviar PDFs, anexos de e-mail e faturas em papel indefinidamente.
Transações B2C estão excluídas. Faturas de consumo, recibos e transações de retalho estão totalmente fora do âmbito da faturação eletrónica estruturada — e, no entanto, estes documentos chegam frequentemente aos fluxos de trabalho de AP para reconciliação de despesas.
Pequenas empresas têm prazos alargados ou isenções permanentes. A França adia as obrigações de emissão para microempresas até setembro de 2027. A implementação faseada da Alemanha baseada em limites significa que empresas abaixo de certos níveis de faturação não têm qualquer obrigação. Estas são frequentemente exatamente os fornecedores de cauda longa cujas faturas já demoram mais tempo a processar.
Relações com fornecedores existentes não se convertem da noite para o dia. Um fornecedor integrado para EDI em 2015 pode não ter incentivo para migrar para Peppol BIS 3.0. O fluxo de trabalho de PDF deles funciona. A sua obrigação não muda os sistemas deles — muda a sua obrigação de reportar, não a obrigação deles de formatar.

Os dados da Ardent Partners confirmam a escala: apenas 51,4% das faturas chegam eletronicamente, e esse número reflete duas décadas de progresso na faturação eletrónica. Os restantes 48,6% — anexos PDF, papel digitalizado, corpos de e-mail, faxes — representam uma metade estrutural do volume de faturas que nenhum prazo de obrigação reduzirá a zero. Mesmo em Itália, onde o sistema SdI é obrigatório desde 2019 e processa mais de 2 mil milhões de faturas eletrónicas anualmente, as faturas PDF transfronteiriças continuam a chegar diariamente. A obrigação garante a comunicação ao governo. Não garante uma caixa de entrada de AP limpa.

O relatório de 2026 da Gennai sobre o Estado da Automação de Faturas coloca o número de equipas financeiras com automação total em 8%. Oito por cento. Após duas décadas de desenvolvimento de faturação eletrónica, após milhares de milhões em investimento de mercado, após treze obrigações europeias em vigor. A lacuna não é um inconveniente transitório. É a condição operacional permanente de uma função global de AP.

As obrigações de faturação eletrónica fecham a lacuna de informação da autoridade fiscal. A lacuna de extração de dados da sua equipa de contas a pagar persiste através de um conjunto totalmente diferente de canais — comércio transfronteiriço, transbordamento B2C, inércia de fornecedores e a longa cauda de empresas que a sua obrigação não abrange. Estes canais não estão a fechar. São características estruturais do comércio global.

Um Único Pipeline para Ambos os Mundos

Se a sua equipa de contas a pagar executa um fluxo de trabalho para faturas XML e outro para faturas PDF, não automatizou o processamento de faturas. Duplicou o número de fluxos de trabalho que a sua equipa precisa de manter, cada um com os seus próprios pontos de falha, a sua própria superfície de integração, o seu próprio requisito de formação. A alternativa não é abandonar a conformidade com a faturação eletrónica. É executar um único pipeline de extração que lida tanto com XML estruturado como com PDF não estruturado através da mesma lente, produzindo o mesmo esquema de saída independentemente do formato recebido.

Esta é a abordagem para a qual o modelo de extração por nomes de colunas foi concebido. Em vez de construir mapeamentos de esquemas XML por país, define os campos de que o seu ERP realmente precisa — Fornecedor, N.º Fatura, Data, Líquido, IVA, Data de Vencimento — uma vez. Esses seis nomes de colunas tornam-se o alvo de extração para cada documento que entra no pipeline, seja um XML Peppol BIS 3.0 de um fornecedor belga, um PDF híbrido Factur-X de um vendedor francês, uma fatura em papel digitalizada de um fabricante chinês, ou um PDF enviado por email de uma PME nacional ainda não abrangida pela obrigação.

O mecanismo é importante. Ao contrário da importação baseada em esquemas, que requer conhecimento preciso de cada estrutura de tag XML, a Extração Personalizada de Colunas lê o conteúdo do documento — os dados reais da fatura — e localiza os valores que correspondem às suas definições de coluna, compreendendo o que cada campo significa, não onde se situa numa hierarquia XML. Uma fatura UBL que escreve o número da fatura como <cbc:ID>INV-2026-0451</cbc:ID> e um PDF que imprime "Fatura INV-2026-0451" no canto superior direito produzem o mesmo resultado de extração na sua coluna N.º Fatura. Sem mapeamento de esquema. Sem configuração específica por país. Um único pipeline.

Para uma análise mais aprofundada de como esta abordagem funciona em diferentes formatos de fatura, idiomas e convenções numéricas, consulte o nosso guia sobre extrair dados de faturas com diferentes formatos para uma tabela unificada.

JPG/PNG/PDF Extração por IA

Os ficheiros são processados de forma segura e não são armazenados.

Perguntas Frequentes

A fatura eletrônica não elimina totalmente a necessidade de extração de dados?

Ela elimina uma categoria de extração de dados — aquela em que um humano lê um PDF e digita valores em um ERP. Mas não elimina a necessidade de uma camada de tradução de dados entre o esquema XML do fornecedor e a estrutura de campos do seu ERP. Para empresas que construíram e mantêm essa camada de tradução em todos os seus fornecedores e países de operação, a fatura eletrônica realmente proporciona o processamento direto. Os dados da Ardent Partners mostram que apenas 8% das equipes financeiras atingiram esse estado. Para os outros 92%, uma camada de extração que lê tanto XML quanto PDF pelo mesmo mecanismo substitui dois fluxos de trabalho manuais separados por um automatizado.

Não posso simplesmente criar mapeamentos de importação XML uma vez por país e pronto?

Pode, e algumas organizações fazem isso. O custo de manutenção é o que a maioria das estimativas iniciais subestima. As autoridades fiscais nacionais atualizam seus esquemas — a Polônia migrou de FA(2) para FA(3), a especificação XRechnung da Alemanha está na versão 3.0.1, os requisitos PPF da França evoluíram entre o piloto e o lançamento. Cada mudança exige testes de regressão em toda a base de fornecedores. Para uma empresa que opera em quatro países com 200 fornecedores, o programa de manutenção de mapeamento é uma despesa operacional recorrente, não um projeto de TI único. Uma abordagem de extração visual contorna isso por não depender de nenhuma estrutura de tag XML — ela lê os dados em si, não o esquema que os entregou.

E quanto aos fornecedores que enviam versões XML e PDF da mesma fatura?

Isso é comum com formatos híbridos ZUGFeRD/Factur-X, que incorporam uma camada de dados XML dentro de um contêiner PDF/A-3. A camada PDF e a camada XML podem divergir — o PDF pode conter um detalhamento completo de itens de linha enquanto o XML é um perfil MÍNIMO sem itens de linha, ou o XML pode refletir uma versão corrigida enquanto o PDF mostra a original. Uma abordagem de extração visual lê o conteúdo renderizado real, que é a versão que sua equipe de contas a pagar veria e verificaria. Ela também detecta discrepâncias que uma importação XML cega perderia.

Como funciona o processamento em lote quando tenho uma mistura de notas fiscais em XML e PDF?

Com um pipeline de extração unificado, o processamento em lote trata XML e PDF como dois formatos de entrada para o mesmo trabalho. Carregue uma pasta com 20 XMLs Peppol de fornecedores belgas, 15 PDFs enviados por e-mail de fornecedores nacionais e 5 notas fiscais digitalizadas de fornecedores internacionais — defina suas colunas uma vez, processe o lote inteiro em uma única execução e receba uma planilha com todas as 40 notas em colunas consistentes. Não há pré-classificação por formato, nem fluxos de trabalho separados, nem redigitação manual para a parte do lote em PDF.

Essa abordagem funciona especificamente com o Peppol?

Sim. O Peppol é uma rede de transporte, não um formato de nota fiscal. O formato de arquivo real é UBL 2.1 XML estruturado de acordo com o Peppol BIS Billing 3.0. Uma abordagem de extração visual lê os dados da nota fiscal a partir da camada de conteúdo, independentemente de ter chegado via Peppol, e-mail, portal do fornecedor ou qualquer outro canal. A rede Peppol resolve o problema de entrega — levar a nota fiscal do fornecedor até você. A camada de extração resolve o problema dos dados — levar os dados da nota fiscal para o seu ERP na estrutura que seu ERP espera.

A Métrica Que Importa

A indústria de faturamento eletrônico mede o progresso pela cobertura de mandatos: quantos países, quantas empresas, quantas notas fiscais passam por plataformas governamentais. Essas métricas medem a conformidade fiscal — um objetivo legítimo e importante. Elas não medem o que as equipes de contas a pagar realmente se importam: quantas notas fiscais foram lançadas no ERP hoje sem que um humano tocasse em um teclado.

Se esse segundo número for menor do que o esperado após seu investimento em faturamento eletrônico, o problema não é que você escolheu a plataforma errada. É que as plataformas de faturamento eletrônico foram projetadas para resolver um problema diferente. O seu não é a lacuna entre o papel e o digital. É a lacuna entre "chegou no formato certo" e "chegou nos campos certos". Essas são duas lacunas separadas. Fechar a primeira nunca fecharia a segunda.

A camada de extração que fica entre sua plataforma de faturamento eletrônico e seu ERP não é uma ponte temporária para um futuro totalmente automatizado. É a infraestrutura permanente de um mundo onde as notas fiscais dos fornecedores chegam em múltiplos formatos, de múltiplas jurisdições, sob múltiplos regimes regulatórios — e sempre chegarão. A questão é se essa camada de extração é uma pessoa, um conjunto frágil de mapeamentos XML por país, ou um único pipeline que lê o que está na nota fiscal, independentemente de como ela chegou até lá.

Teste em suas próprias notas fiscais. XML e PDF, no mesmo lote, contra as colunas que seu ERP realmente precisa. Veja se a lacuna entre "recebido" e "lançado" diminui para o que o mandato de faturamento eletrônico sempre sugeriu que aconteceria.

Por que Receber uma Fatura XMLNão Acaba com a Extração Manual de Dados de AP

Principais Conclusões