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 em seus 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 aumentou em relação ao ano anterior, não diminuiu. Este artigo examina a lacuna entre o que o faturamento eletrônico prometeu e o que as equipes de AP realmente experimentam, e por que essa lacuna é estrutural, não transitória.
Principais Conclusões
- As obrigatoriedades de faturamento eletrônico prometem acabar com a entrada manual de dados — mas 66% das equipes de AP (contas a pagar) ainda inserem dados de faturas manualmente em seu ERP, e esse número aumentou em 2025.
- Quatro esquemas XML estruturalmente diferentes podem chegar na mesma caixa de entrada e todos estarem em conformidade com a EN 16931 — porque o padrão foi escrito para interoperabilidade com autoridades fiscais, não para o que seu ERP realmente espera.
- Executar um pipeline de extração de leitura de conteúdo colapsa XRechnung alemão, Factur-X francês, FatturaPA italiano e PDFs enviados por e-mail nas mesmas seis colunas — nenhum deles precisa de um mapeamento XML por país, e o ImageToTable.ai lida com todo o lote de formatos mistos em uma única execução.
A Caixa-Preta: O Que Acontece Depois que uma Fatura XML Chega na Sua Caixa de Entrada
Uma fatura eletrônica não é apenas um documento digital. É um pacote de dados — um arquivo XML ou UBL estruturado que transporta informações da fatura em campos legíveis por máquina, de acordo com a norma europeia EN 16931, publicada em 2017 pelo Comitê Europeu de Normalização (CEN/TC 434). A norma define mais de 160 campos de dados semânticos: número da fatura, 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, entre outros. 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 de forma nativa. Eles esperam dados de fatura em seu próprio formato interno, mapeados para seus próprios nomes de campo, através de sua própria API ou modelo de importação. Uma fatura Peppol BIS 3.0 chega como UBL 2.1 XML com uma estrutura de tag como <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>. Seu ERP espera um campo chamado Tipo de Fatura com o valor Fatura 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 faturas XML, 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 uma representação visual do XML e digitando em uma tela. A fatura eletrônica é estruturada. A última milha não é.
Uma fatura 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 mutuamente. 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, Apenas 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 para 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 apontou 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 campos. 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.
Isso não é um argumento contra a fatura 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 projetado para interoperabilidade entre autoridades fiscais, não entre o ERP do seu fornecedor e o seu.
Se você está criando um pipeline de importação XML separado para cada país onde seus fornecedores operam, está resolvendo um problema que se multiplica a cada nova exigência. A alternativa — ler o que está realmente na fatura, e não qual esquema a gerou — reduz todos os quatro países a um único pipeline de extração.
O PDF Que Não Vai Embora
O cronograma de obrigatoriedade da fatura eletrônica está acelerando. A Bélgica entrou em vigor em janeiro de 2026 com escopo quase universal. A Polônia seguiu em fevereiro para grandes contribuintes. A França ativa em setembro de 2026 para grandes e médias empresas. A obrigatoriedade B2B da Alemanha é implementada gradualmente até 2028. Para um detalhamento de cada prazo e sua base legal, veja nossa linha do tempo de obrigatoriedade da fatura eletrônica na Europa.
Mas toda obrigatoriedade 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 obrigatoriedade de fatura eletrônica da UE. Esses fornecedores continuarão enviando 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 varejo estão totalmente fora do escopo da fatura eletrônica estruturada — e, no entanto, esses documentos frequentemente chegam aos fluxos de trabalho de contas a pagar para reconciliação de despesas.
- Pequenas empresas têm prazos estendidos ou isenções permanentes. A França adia as obrigações de emissão para microempresas para setembro de 2027. A implementação gradual da Alemanha baseada em limites significa que empresas abaixo de certos níveis de faturamento não têm obrigação alguma. Muitas vezes, são exatamente esses fornecedores de cauda longa cujas faturas já consomem mais tempo de processamento.
- Relacionamentos existentes com fornecedores não mudam 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. Sua obrigatoriedade não muda os sistemas deles — muda 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 eletrônica. Os 48,6% restantes — anexos PDF, papel digitalizado, corpos de e-mail, faxes — representam uma metade estrutural do volume de faturas que nenhum prazo de obrigatoriedade levará a zero. Mesmo na Itália, onde o sistema SdI é obrigatório desde 2019 e processa mais de 2 bilhões de faturas eletrônicas anualmente, faturas PDF transfronteiriças continuam chegando diariamente. A obrigatoriedade garante a declaração ao governo. Não garante uma caixa de entrada de contas a pagar limpa.
O relatório State of Invoice Automation 2026 da Gennai coloca o índice de automação total em 8% das equipes financeiras. Oito por cento. Após duas décadas de desenvolvimento de fatura eletrônica, após bilhões em investimento de mercado, após treze obrigatoriedades europeias em vigor. A lacuna não é um inconveniente transitório. É a condição operacional permanente de uma função global de contas a pagar.
As obrigatoriedades de fatura eletrônica fecham a lacuna de informação da autoridade fiscal. A lacuna de extração de dados da sua equipe 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 cauda longa de empresas que sua obrigatoriedade não cobre. Esses canais não estão se fechando. São características estruturais do comércio global.
Um Único Pipeline para Ambos os Mundos
Se sua equipe de contas a pagar usa um fluxo para faturas XML e outro para faturas PDF, você não automatizou o processamento de faturas. Você dobrou o número de fluxos que sua equipe precisa manter, cada um com seus próprios pontos de falha, superfície de integração e requisitos de treinamento. A alternativa não é abandonar a conformidade com a fatura eletrônica. É executar um único pipeline de extração que lida tanto com XML estruturado quanto 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 nome de coluna foi projetado. Em vez de criar mapeamentos de esquema XML por país, você define os campos que seu ERP realmente precisa — Fornecedor, NF, Data, Líquido, ICMS, Vencimento — uma vez. Esses seis nomes de coluna se tornam o alvo de extração para todo 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 escaneada em papel de um fabricante chinês ou um PDF enviado por e-mail de uma PME nacional ainda não coberta pela obrigação.
O mecanismo importa. Diferente da importação baseada em esquema, que exige conhecimento preciso de cada estrutura de tag XML, a Extração por Coluna Personalizada lê o conteúdo do documento — os dados reais da fatura — e localiza os valores que correspondem às suas definições de coluna, entendendo o que cada campo significa, não onde ele está em uma hierarquia XML. Uma fatura UBL que escreve o número da nota como <cbc:ID>INV-2026-0451</cbc:ID> e um PDF que imprime "Invoice INV-2026-0451" no canto superior direito produzem o mesmo resultado de extração na sua coluna NF. Sem mapeamento de esquema. Sem configuração específica por país. Um único pipeline.
Para um olhar mais aprofundado sobre como essa abordagem funciona em diferentes formatos de fatura, idiomas e convenções numéricas, consulte nosso guia sobre extrair dados de faturas com diferentes formatos em uma única tabela unificada.
Os arquivos são processados com segurança 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 uma pessoa lê um PDF e digita valores em um ERP. Ela 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 escaneadas em papel de fornecedores transfronteiriços — defina suas colunas uma vez, processe todo o lote em uma única execução e receba uma planilha com todas as 40 notas fiscais 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 de 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 papel e 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, uma coleção de mapeamentos XML frágeis por país, ou um único pipeline que lê o que está na nota fiscal, independentemente de como ela chegou 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 seria.