Integração de faturação eletrónica: Peppol, XRechnung, ZUGFeRD e Factur-X para sistemas que não foram feitos para isso

Comprar um produto de faturação eletrónica é fácil. O problema quase nunca é o produto. É o sistema de gestão de encomendas com doze anos que emite as suas faturas, a lógica de preços que ninguém documentou e o facto de os números das faturas virem de uma stored procedure escrita por alguém que saiu em 2019.

Construímos o conector entre o que a sua empresa realmente usa e o que a obrigação legal exige. Geração de faturas estruturadas, validação, transmissão pela rede, tratamento das faturas recebidas e arquivo, ligados ao seu sistema atual em vez de o substituírem.

As obrigações e quando começam a apertar

A Europa está a passar das faturas em PDF para faturas estruturadas e legíveis por máquina, país a país, antes do pacote europeu IVA na Era Digital (ViDA), que vai harmonizar tudo. As datas que hoje fazem avançar os projetos:

• Alemanha: a receção de faturas eletrónicas estruturadas é obrigatória desde 1 de janeiro de 2025. A emissão passa a ser obrigatória em 1 de janeiro de 2027 para empresas com volume de negócios superior a 800 000 € e em 1 de janeiro de 2028 para todas as outras. Na prática, os formatos são o XRechnung (XML puro) e o ZUGFeRD 2.x (um PDF híbrido com XML incorporado), ambos conformes à EN 16931.
• França: receção, e emissão para grandes e médias empresas, a partir de 1 de setembro de 2026; emissão para PME a partir de 1 de setembro de 2027. A transmissão faz-se através de plataformas registadas, com o Factur-X como formato híbrido comum.
• Bélgica: faturação eletrónica B2B obrigatória através da Peppol desde 1 de janeiro de 2026, com comunicação eletrónica de dados (e-reporting) num modelo de cinco cantos prevista para 2028.
• Polónia: o KSeF, a plataforma nacional de validação prévia (clearance), com o seu próprio esquema XML e o seu próprio calendário.
• Itália: o SdI e a FatturaPA, em funcionamento desde 2019 e ainda o modelo de validação prévia mais exigente da UE.
• Espanha: o Verifactu e as obrigações de faturação da lei Crea y Crece, a avançar em paralelo com os sistemas regionais TicketBAI.

Se vende para vários destes países, não tem um projeto. Tem uma arquitetura e vários adaptadores por país. Encarar o assunto desta forma, ou não, é o que separa uma integração de cinco.

Onde os projetos correm mal

Os dados da fatura não existem na forma que a norma exige. A EN 16931 pede campos que muitos sistemas nunca registaram: uma referência do comprador como deve ser, a discriminação do IVA por taxa e não por linha, condições de pagamento estruturadas, códigos de unidade de um vocabulário controlado. O trabalho de engenharia é reconstruir esses campos a partir do que tem, de forma determinística, para todas as faturas que alguma vez vai emitir.

As falhas de validação chegam tarde demais. Uma fatura rejeitada é uma fatura por pagar. A validação tem de correr antes da transmissão, contra o esquema em vigor e as regras de negócio atuais de cada país, e as falhas têm de chegar a uma pessoa que possa agir, em vez de ficarem registadas num ficheiro.

Receber é mais difícil do que emitir. Toda a gente planeia a emissão e esquece-se de que, a partir da data de receção obrigatória, tem de aceitar faturas estruturadas de todos os fornecedores, em qualquer formato conforme, e fazê-las chegar às contas a pagar sem que alguém tenha de abrir uma a uma.

Numeração e idempotência. Novas tentativas, tempos de espera esgotados na rede e falhas das plataformas são normais. Uma fatura enviada duas vezes com dois números é um problema fiscal, não um problema de software. Isto tem de ficar certo desde o início.

O que construímos

Avaliação e escolha do formato

Um trabalho curto (normalmente de uma a duas semanas) em que analisamos como as suas faturas são realmente produzidas, que obrigações o abrangem e quando, e quais são as suas opções realistas. O resultado é uma recomendação escrita: de que formatos precisa, se o acesso à Peppol deve ser feito através de um fornecedor ou de um ponto de acesso próprio, o que tem de mudar no seu sistema de origem e quanto custa.

Às vezes, a recomendação é que um produto de mercado com um pequeno adaptador resolve o assunto. Preferimos dizer-lho na primeira semana a faturar-lhe seis meses.

Geração e mapeamento das faturas

Construímos a camada de mapeamento dos seus dados de origem para as sintaxes exigidas (UBL e CII ao abrigo da EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF XML), com as derivações de cada campo documentadas para que um auditor e a sua equipa financeira as possam acompanhar. Quando o sistema de origem não consegue de todo fornecer um campo obrigatório, dizemo-lo cedo e desenhamos a forma de o recolher, em vez de inventar um valor por omissão.

Validação antes da transmissão

A validação do esquema, as regras de negócio Schematron e as verificações específicas de cada país correm antes de qualquer coisa sair da empresa. As falhas seguem para uma fila da responsabilidade de uma pessoa, com uma mensagem que diz que campo falhou e porquê, e não um stack trace.

Ligação à rede

Ligação a um ponto de acesso Peppol, através de um fornecedor estabelecido ou com um ponto de acesso próprio, conforme o volume e o grau de controlo de que precisa. Nos países com modelo de validação prévia, integramos diretamente com a plataforma nacional (KSeF, SdI, o ecossistema francês de PDP), incluindo a gestão de certificados e de autenticação, que cada uma destas plataformas faz à sua maneira.

Tratamento das faturas recebidas

Receção, validação e normalização das faturas dos fornecedores numa única representação interna, cruzadas com as notas de encomenda e as guias de receção quando existem, e entregues no seu fluxo de contas a pagar. É normalmente daqui que vem o retorno do projeto, porque elimina uma introdução manual de dados que nunca ninguém mediu.

Arquivo e trilho de auditoria

Conservação conforme do documento estruturado original, num formato e durante um prazo que cumprem as regras alemãs GoBD, a conservazione sostitutiva italiana ou as regras equivalentes dos países onde opera, com o percurso de recuperação testado, e não apenas presumido.

Sistemas com que integramos

SAP ECC e S/4HANA, Microsoft Dynamics 365 e Business Central, Odoo, NetSuite, Sage, Infor, Xero, interfaces DATEV e (na maioria dos casos) um sistema feito à medida ou muito modificado, central para o funcionamento do negócio, que não vai ser substituído por causa de uma obrigação legal. Trabalhamos em .NET, Java, PHP, Python, Node.js e, quando é isso que temos à frente, em tecnologias mais antigas.

Se gere um marketplace, uma plataforma de subscrições ou um motor de faturação que emite faturas por programação e em grande volume, é exatamente o caso para o qual estamos preparados: a fatura é gerada pelo seu código, por isso a conformidade tem de estar no seu código.

O que não fazemos

Não vendemos software de faturação nem somos um programa de contabilidade. Se é uma pequena empresa à procura de uma ferramenta que emita faturas conformes, compre uma: DATEV, sevDesk, Lexware e uma dúzia de outros fazem isto bem e custam uma fração de um projeto de integração.

Fale connosco quando a fatura for produzida por um sistema que já é seu, quando as regras de vários países tiverem de coexistir ou quando o volume obrigar a que isto funcione sem ninguém a vigiar.

Como decorre o trabalho

Avaliação, de uma a duas semanas, a preço fixo, e termina com uma recomendação escrita e num plano orçamentado.

Construção, normalmente de seis a doze semanas para um primeiro país, conforme a qualidade dos dados de origem. Trabalhamos no seu repositório, com a sua estratégia de branches, com a sua equipa, e deixamos testes feitos.

Piloto, com faturas reais enviadas a um pequeno grupo de contrapartes em paralelo com o processo atual, até a taxa de falhas estar onde deve estar.

Passagem à produção e suporte, com a fila de falhas monitorizada e alguém responsável por ela, durante o primeiro fecho do mês e a primeira declaração de IVA, que é quando surgem as perguntas que realmente importam.

Normas que seguimos

A EN 16931 e as suas sintaxes (UBL 2.1, UN/CEFACT CII), o Peppol BIS Billing 3.0 e a infraestrutura de transporte Peppol, o XRechnung e o validador KoSIT, os perfis ZUGFeRD 2.x e Factur-X, a FatturaPA, o KSeF e as propostas do ViDA que vão definir o que vem depois de 2030.

Perguntas frequentes

Quando se aplica exatamente a obrigação alemã de faturação eletrónica à nossa empresa?

A receção aplica-se a todas as empresas alemãs desde 1 de janeiro de 2025. A emissão aplica-se a partir de 1 de janeiro de 2027 se o volume de negócios do ano anterior tiver ultrapassado 800 000 €, e a partir de 1 de janeiro de 2028 nos restantes casos. A obrigação abrange as operações B2B nacionais; o tratamento da faturação transfronteiriça e B2C é diferente e convém confirmá-lo com o seu consultor fiscal.

Qual é a diferença entre XRechnung e ZUGFeRD?

O XRechnung é XML puro, definido pelo setor público alemão e obrigatório nas faturas a entidades públicas. O ZUGFeRD 2.x é híbrido: um documento PDF/A-3 com os mesmos dados estruturados incorporados, para que uma pessoa leia o PDF e uma máquina leia o XML. Ambos são conformes à EN 16931. Na prática comercial B2B alemã, a preferência vai para o ZUGFeRD; muitos compradores aceitam os dois.

Precisamos de um ponto de acesso Peppol próprio?

Normalmente não. A maioria das empresas liga-se através de um fornecedor de ponto de acesso já existente, o que é mais barato e mais rápido. Ter um próprio faz sentido com grandes volumes, quando precisa de controlar a camada de transporte ou quando presta serviços de faturação a terceiros.

Podem trabalhar com o nosso fornecedor atual de faturação eletrónica?

Sim, e muitas vezes esse é o modelo certo. O fornecedor trata da transmissão e da adesão à rede, e nós construímos tudo o que fica entre o seu sistema e a API dele: o mapeamento, a validação, as novas tentativas, o tratamento de falhas e a reconciliação.

O que acontece às faturas que falham a validação?

Vão para uma fila com uma explicação legível do campo que falhou e da regra que não cumpriu. Desenhamos essa fila com cuidado, porque nos primeiros meses depois do arranque é a parte mais usada do sistema, e uma fila mal feita transforma um projeto de conformidade num processo manual permanente.

Como evitam enviar a mesma fatura duas vezes?

Com uma chave de idempotência estável, derivada da identidade da fatura e mantida em todas as novas tentativas, e com um registo de transmissões que faz fé sobre o que foi enviado. Qualquer nova tentativa reutiliza o identificador original, em vez de gerar um novo.

Começar

Diga-nos para que países fatura, quantas faturas emite, aproximadamente, por mês e o que as produz hoje. Dizemos-lhe que obrigações o abrangem, por que ordem e se isto é um conector ou um projeto.

Contacte-nos para marcar uma avaliação de prontidão para a faturação eletrónica.

Serviços relacionados

• Desenvolvimento para entrada no mercado da UE: o resto do quadro regulamentar para vender na Europa
• Modernização de ERP e saída do SAP ECC: quando a obrigação de faturação eletrónica chega a meio de uma migração
• Manutenção de sistemas e código legados: para o sistema que produz as faturas