Por que receber uma fatura XML
não elimina a extração manual de dados de contas a pagar
Na Bélgica, mais de um milhão de empresas se registraron na rede Peppol nas primeiras semanas de 2026. A Croacia processou quatro milhões de faturas eletrónicas nos seus primeiros vinte e oito dias. Trece países da UE agora exigem facturação eletrónica obrigatoria, e sete más se unirán antes do final de 2027. A narrativa que acompanha estas implementaciones tem sido consistente: as faturas XML estruturadas eliminarán a entrada manual de dados, reducirán erros e entregarán processamento direto. Pero quando Ardent Partners pesquisó 204 organizações de contas a pagar para o seu informe State of ePayables 2025, os números contaron uma história diferente. Só 51,4% das faturas chegaron eletrónicamente. Só 35,4% se processaron diretamente sem intervenção humana. E 66% das equipes de contas a pagar ainda inserem manualmente os dados das faturas no seu ERP — uma cifra que subió em relação ao ano anterior, não baixó. Este artigo examina a lacuna entre o que a facturação eletrónica prometió e o que as equipes de contas a pagar realmente experimentan, e por que essa lacuna é estrutural, não transitoria.
Principais Conclusões
- Os mandatos de facturação eletrónica prometem eliminar a entrada manual de dados — pero 66% das equipes de contas a pagar ainda inserem manualmente os dados das faturas no seu ERP, e esse número subió em 2025.
- Quatro esquemas XML estruturalmente diferentes podem chegar na mesma caixa de entrada e todos ser conformes com EN 16931 — porque o padrão foi escrito para a interoperabilidade das autoridades fiscais, não para o que seu ERP realmente espera.
- Executar um único pipeline de extração por leitura de conteúdo colapsa o XRechnung alemán, o Factur-X francés, o FatturaPA italiano e os PDFs enviados por correo eletrónico nas mesmas seis colunas — nenhuno deles precisa de um mapeo XML por país, e ImageToTable.ai maneja 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 em que seus fornecedores operam, você está resolvendo um problema que se multiplica a cada nova exigência. A alternativa — ler o que está realmente na fatura, em vez do esquema que a gerou — reduz todos os quatro países a um único pipeline de extração.
O PDF Que Não Vai Embora
O cronograma das exigências de faturamento eletrônico 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 empresas de grande e médio porte. A exigência B2B da Alemanha é faseada até 2028. Para um detalhamento de cada prazo e sua base legal, consulte nosso cronograma de exigências de faturamento eletrônico na Europa.
Mas toda exigência contém exclusões, e essas exclusões produzem um resíduo de PDF que nenhum prazo futuro eliminará. O padrão é consistente entre as jurisdições:
- Fornecedores transfronteiriços estão isentos. Uma empresa alemã que recebe faturas de um fornecedor dos EUA ou da China não é coberta por nenhuma exigência de faturamento eletrônico da UE. Esses fornecedores continuarão enviando PDFs, anexos de e-mail e faturas em papel indefinidamente.
- Transações B2C são excluídas. Faturas de consumo, recibos e transações de varejo estão totalmente fora do escopo do faturamento eletrônico estruturado — e, no entanto, esses documentos frequentemente chegam aos fluxos de trabalho de contas a pagar para conciliação de despesas.
- Pequenas empresas têm prazos adiados ou isenções permanentes. A França adia as obrigações de emissão para microempresas para setembro de 2027. A implementação faseada baseada em limites da Alemanha significa que empresas abaixo de certos níveis de faturamento não têm obrigação alguma. Esses são frequentemente exatamente os fornecedores de cauda longa cujas faturas já levam mais tempo de processamento.
- Relacionamentos com fornecedores existentes não mudam da noite para o dia. Um fornecedor integrado para EDI em 2015 pode não ter incentivo para migrar para o Peppol BIS 3.0. O fluxo de trabalho de PDF deles funciona. Sua exigência 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 no faturamento eletrônico. Os 48,6% restantes — anexos PDF, papel escaneado, corpos de e-mail, faxes — representam uma metade estrutural do volume de faturas que nenhum cronograma de exigências reduzirá 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 exigência garante a comunicação ao governo. Ela 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 faturamento eletrônico, após bilhões em investimento de mercado, após treze exigências 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 obrigações de faturamento eletrônico fecham a lacuna de informações da autoridade fiscal. A lacuna de extração de dados da sua equipe de contas a pagar persiste por meio 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 cobre. Esses canais não estão se fechando. Eles são características estruturais do comércio global.
Um Pipeline para Ambos os Mundos
Se a sua equipe de contas a pagar executa um fluxo de trabalho para faturas XML e outro para faturas em PDF, você não automatizou o processamento de faturas. Você dobrou o número de fluxos de trabalho que sua equipe precisa manter, cada um com seus próprios pontos de falha, sua própria superfície de integração, seu próprio requisito de treinamento. A alternativa não é abandonar a conformidade com o faturamento eletrônico. É executar um único pipeline de extração que lida tanto com XML estruturado quanto com PDF não estruturado pela 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 projetado. Em vez de criar mapeamentos de esquema XML por país, você define os campos que seu ERP realmente precisa — Fornecedor, Nº da Fatura, Data, Líquido, IVA, Data de Vencimento — uma única vez. Esses seis nomes de colunas se tornam 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 fornecedor francês, uma fatura em papel escaneada de um fabricante chinês ou um PDF enviado por e-mail de uma PME doméstica ainda não coberta pela obrigação.
O mecanismo importa. Diferentemente da importação baseada em esquema, que exige conhecimento preciso de cada estrutura de tag XML, a Extração de Colunas Personalizadas 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 fatura 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 Nº da Fatura. Sem mapeamento de esquema. Sem configuração específica por país. Um único pipeline.
Para uma análise mais aprofundada de como essa abordagem funciona em diferentes formatos de fatura, idiomas e convenções numéricas, consulte nosso guia sobre extração de dados de faturas com diferentes formatos em uma 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.