Fatura eletrónica para administradores de condomínio: a norma europeia, sem jargão

A fatura do fornecedor faz o mesmo percurso há vinte anos: chega como PDF à caixa de correio do administrador, alguém lê o montante no ecrã, volta a escrevê-lo numa folha de cálculo ou num programa de contabilidade, guarda o PDF numa pasta e espera que as duas coisas se mantenham alinhadas. Multiplique por cada contrato de manutenção do elevador, empresa de limpeza, apólice de seguro e reparação pontual numa carteira de prédios, e voltar a escrever faturas é uma fatia real do back office de um administrador.

Em Portugal, a expressão “fatura eletrónica” não é novidade. Há anos que a maioria das faturas sai de programas de faturação certificados pela Autoridade Tributária e é comunicada à AT. Mas a fatura que chega ao administrador ainda é, quase sempre, um PDF anexado a um email: legível para pessoas, opaco para máquinas.

A fatura estruturada é outra coisa, e está a tornar-se a regra. Nas compras públicas, a fatura eletrónica estruturada já é obrigatória, no formato CIUS-PT, a adaptação portuguesa da norma europeia. Noutros Estados-membros, a fatura estruturada entre empresas já é obrigatória ou está a ser introduzida por fases nesta década, e as novas regras europeias do IVA na era digital (ViDA) empurram toda a União no mesmo sentido. Os prazos variam, mas a direção e a norma de base não. Os administradores de condomínio estão no centro disto: gerir o dinheiro de um prédio implica lidar com fornecedores profissionais, e estes vão enviar cada vez mais dados estruturados, esteja o lado de quem recebe preparado ou não.

A maior parte do que se escreve sobre o tema apresenta-o como um fardo de conformidade. Está mais perto de ser uma oferta. A obrigação força os fornecedores a enviar faturas num formato legível por máquina, o que significa que a era de voltar a escrever faturas pode acabar, se o processo de receção for bem construído.

Uma fronteira clara antes de continuar: este artigo é sobre receber faturas. Emitir faturas em Portugal continua a ser trabalho de um programa de faturação certificado pela AT, e é esse programa que produz o SAF-T. O Kvaro não emite faturas, não é um programa certificado e não produz SAF-T. O que faz é receber as faturas eletrónicas dos fornecedores do condomínio e transformá-las em despesas.

O PDF já não é a fatura

Uma fatura eletrónica estruturada não é um PDF de uma fatura. É um ficheiro de dados estruturados conforme à norma europeia EN 16931: o vendedor, os montantes, as datas, os dados de pagamento, tudo em campos legíveis por máquina. Essa norma única é o que importa. Seja qual for a variante nacional, uma fatura conforme tem por baixo o mesmo modelo de dados essencial, e é por isso que uma ferramenta construída para a norma funciona além-fronteiras.

Na prática, aparecem duas formas da mesma norma:

• XML puro é a forma para máquinas: um ficheiro XML, nas sintaxes UBL ou CII, sem qualquer camada visual. Abra-o num visualizador e vê parênteses angulares. É ilegível de propósito, porque se destina a máquinas. Vários países têm o seu próprio perfil desta forma, como o CIUS-PT em Portugal, mas são dialetos da EN 16931, não mundos à parte.
• O híbrido (Factur-X é o nome mais conhecido) é um PDF de aspeto normal com o XML embutido. A pessoa vê uma fatura; a máquina vê dados. O ponto crucial: a parte que faz fé é o XML embutido, não os píxeis.

O formato híbrido esconde uma armadilha que convém conhecer. Uma fatura híbrida tratada à moda antiga, com olhos humanos a ler o PDF e a voltar a escrever, ignora em silêncio a camada estruturada. Os números na camada visual e no XML devem coincidir, mas a parte legível por máquina é que é a fatura. Um processo que só toca nos píxeis está a tratar uma imagem de uma fatura e a deitar fora a própria fatura.

Receber bem: ler, mostrar, confirmar

O processo de receção correto tem três passos, e só um deles envolve uma pessoa.

Primeiro, o ficheiro entra, XML ou PDF híbrido, e a máquina lê os campos estruturados: quem a enviou, o número da fatura, as datas de emissão e de vencimento, o valor sem IVA, o IVA e o total, a conta para onde pagar. Nada de voltar a escrever, nada de ler números no ecrã.

Segundo, esses campos são-lhe apresentados de forma simples e legível. Isto importa sobretudo no XML puro, que sem este passo é uma parede de parênteses angulares com a qual ninguém consegue trabalhar, mas importa também nos híbridos: o que vê é o que a camada da máquina diz de facto, e não o que o PDF por acaso mostra.

Terceiro, confirma, uma vez, e a fatura torna-se um rascunho de despesa nas contas do prédio, com o montante e o fornecedor lidos da fatura. A partir daí, vive a vida normal de uma despesa: espera pelo extrato bancário, a linha do pagamento é associada a ela e o seu estado calcula-se sozinho, como deve acontecer com todas as despesas do condomínio.

Um ficheiro entra, uma confirmação, uma despesa lançada. É toda a superfície manual do processo.

Porque é que a confirmação não é opcional

Uma pergunta justa: se a máquina lê tudo, porquê confirmar? Porque não lançar as faturas automaticamente assim que chegam?

Porque a leitura é fiável e a responsabilidade não se delega. Uma fatura pode estar perfeita para a máquina e mesmo assim estar errada: um duplicado, um montante que não bate com o contrato, um serviço que nunca foi pedido, ou fraude pura e simples. A fraude com faturas de IBAN alterado é um padrão real e crescente, e o ecrã de confirmação é exatamente onde morre: o IBAN lido está diante de uma pessoa que sabe qual foi sempre a conta da empresa do elevador. Um processo que lança sozinho elimina o único momento em que se aplica o critério do administrador, que é aquilo que o prédio realmente paga.

Por isso, o desenho certo é deliberado: a máquina faz toda a leitura, a pessoa toma a única decisão. Qualquer coisa mais automática otimiza precisamente aquilo que importa até o fazer desaparecer.

Guarde o original, não a apresentação

As regras de conservação de documentos obrigam a guardar faturas durante vários anos, e aqui aplica-se a mesma lógica do formato híbrido: o que tem de ser preservado é o ficheiro original, o XML ou o PDF híbrido exatamente como foi recebido, não uma captura de ecrã, não a versão legível, não uma nova exportação. A apresentação é uma conveniência para hoje; o original é o registo para o auditor daqui a sete anos.

Por isso, a ferramenta de receção deve guardar o original de forma imutável, ao lado da despesa em que se transformou, e ser sempre capaz de devolver exatamente os bytes que chegaram. Se uma ferramenta regenera ou “limpa” as faturas guardadas, está a guardar a sua própria obra gráfica em vez do documento.

Para onde vai a fatura a seguir

O ganho discreto de receber faturas como dados está em tudo o que vem depois. A despesa confirmada junta-se à cadeia de movimentos do prédio, o que significa que:

• Os condóminos podem vê-la. A fatura ocupa o seu lugar na lista de comprovativos do prédio, onde um condómino que analisa as contas do ano pode abrir o documento real por trás de cada linha.
• O relatório de contas absorve-a. O fecho do ano deixa de exigir uma caça às faturas, porque cada fatura de fornecedor já está categorizada nas contas. O ciclo completo está no guia do exercício do condomínio.
• O contabilista recebe dados limpos. Uma exportação de lançamentos leva a despesa, com as suas categorias, ao contabilista, com o documento original disponível a pedido.

Conte os toques humanos em todo este percurso: um. A fatura foi confirmada uma vez, e todos os que a usam depois, condóminos, assembleia, contabilista, auditor, leem registos derivados desse único facto confirmado.

O que ainda não existe, e porque vale a pena começar na mesma

Há dois canais de entrega que ainda estão a amadurecer no mercado: a receção automática de faturas que chegam por email, e a rede Peppol para troca de faturas estruturadas, que se está a tornar a camada de transporte comum entre os Estados-membros. Hoje, a base fiável é o carregamento: o ficheiro da fatura, chegue como chegar, entra na ferramenta e o processo acima trata do resto.

Essa base já é a vitória toda. O custo da fatura eletrónica nunca foi o clique de carregar, foi o voltar a escrever, as pastas desalinhadas, a caça às faturas todos os janeiros. Tudo isso acaba no dia em que o processo de receção passa a ler os dados estruturados em vez de ser o administrador a fazê-lo. A obrigação pôs os fornecedores a fazer a metade difícil; a metade da receção é agora uma escolha.