Faturação eletrónica nos EAU a 1 de julho de 2027: preparar um ERP próprio para a Peppol

A partir de 1 de janeiro de 2027, as empresas dos Emirados Árabes Unidos com receitas anuais de 50 000 000 AED ou mais têm de emitir e receber as suas faturas B2B e B2G em XML estruturado, enviadas através de um Accredited Service Provider pela rede Peppol. Todas as que ficam abaixo desse limiar seguem-se a 1 de julho de 2027, e têm de nomear um prestador até 31 de março de 2027. As entidades públicas entram em produção a 1 de outubro de 2027.

A partir da sua data de arranque, a fatura fiscal é o XML. O PDF que o seu sistema envia hoje por email só continua a ser necessário em paralelo, para os clientes que ainda não estão na rede.

Se as suas faturas saem do Zoho, do Tally, do Wafeq ou de um produto de pacote semelhante, a maior parte disto é trabalho do seu fornecedor. Os três constam, eles próprios, da lista de prestadores acreditados do Ministério das Finanças. O seu trabalho é escolher um prestador, fazer a adesão através do EmaraTax e limpar os dados dos clientes.

Este artigo é para as empresas cujas faturas saem de um sistema que é delas: um ERP desenvolvido internamente, uma instalação personalizada ao ponto de já não aceitar atualizações, um motor de faturação interno. Ninguém fornece o conector para estes casos. As UAE Electronic Invoicing Guidelines dizem-no claramente: as empresas têm de «concluir as personalizações dos sistemas internos e começar a testar a transmissão dos dados das faturas».

As datas

As fases são definidas pela Decisão Ministerial n.º 244 de 2025, na redação em vigor:

A primeira linha indicava inicialmente 31 de julho de 2026. A Decisão Ministerial n.º 66 de 2026 passou-a para 30 de outubro de 2026 e não mexeu na data de arranque. A tabela das orientações ainda mostra a data antiga, por isso leia os dois documentos em conjunto.

A adesão voluntária está aberta a todos desde 1 de julho de 2026, o que conta para o plano mais abaixo.

O que está abrangido

A faturação eletrónica aplica-se a qualquer pessoa que exerça atividade nos EAU, independentemente de estar registada para efeitos de IVA. Uma empresa sem registo de IVA emite faturas comerciais eletrónicas, e não faturas fiscais, através da mesma rede.

As operações B2B, B2G, G2B e G2G estão incluídas. As vendas a consumidores ficam de fora até o Ministro decidir o contrário, e uma empresa que só vende a consumidores não está, para já, sujeita ao sistema. Há exclusões estreitas para a atividade soberana do Estado, os bilhetes de passageiros das companhias aéreas e os serviços financeiros isentos de IVA.

Se gere um grupo IVA, há uma concessão que importa: as operações entre membros do mesmo grupo têm um período de tolerância de 24 meses a contar de 1 de janeiro de 2027. Cada membro continua a fazer a adesão separadamente, com o seu próprio TIN, e as faturas para terceiros estão abrangidas a partir da data normal.

O modelo de cinco cantos, visto a partir do seu ERP

Os EAU usam um modelo de cinco cantos:

1. Canto 1: a sua empresa, o fornecedor.
2. Canto 2: o seu Accredited Service Provider (ASP).
3. Canto 3: o ASP do seu comprador.
4. Canto 4: o seu comprador.
5. Canto 5: a Federal Tax Authority (FTA), a autoridade tributária federal.

O seu sistema fala com uma única parte: o seu ASP. Envia os dados da fatura num formato acordado com ele. O ASP valida-os, converte-os para o XML dos EAU se for preciso, entrega-os ao ASP do comprador e, em paralelo, comunica os dados fiscais à FTA. O ASP do comprador valida o que recebeu e também o comunica. As confirmações voltam até si ao longo da cadeia.

Essa comunicação usa um documento Peppol separado, o UAE Tax Data Document, que a especificação Peppol descreve como «usado tanto pelo emitente como pelo destinatário da fatura para comunicar uma fatura». É o seu ASP que o constrói. Do seu lado fica o tratamento do que volta: a confirmação de que o lado do comprador aceitou a fatura, a confirmação de que a FTA recebeu os dados fiscais, e as falhas de uma e de outra.

O ASP trata do transporte, da cifragem, da pesquisa de participantes e do UUID que identifica cada fatura de forma única. A responsabilidade de calcular cada valor da fatura continua a ser sua, tal como a de recolher o identificador Peppol do seu comprador. O seu prestador valida a fatura. Não a corrige.

Nomeia exatamente um ASP, para o envio e para a receção.

O que o seu sistema tem de produzir

O formato

Os EAU usam o Peppol PINT-AE: XML UBL, com uma especificação de faturação e outra, separada, de autofaturação (ambas na versão 1.0.4 no momento em que escrevemos). Não há código QR. Não pode acrescentar campos próprios; tudo o que for específico de um setor é acordado com o seu ASP.

Os campos que costumam faltar nos sistemas antigos

O Ministério publica uma lista de campos obrigatórios: 51 para uma fatura fiscal eletrónica. Estes são os que costumam dar trabalho:

• Endereços eletrónicos das duas partes. O seu endpoint é 0235 seguido do seu TIN de 10 dígitos, que são os primeiros 10 dígitos do seu TRN. O do seu comprador segue o mesmo padrão, o que significa um campo novo em cada ficha de cliente e alguém para recolher os valores. Há endpoints predefinidos para os casos particulares: 0235:9900000098 quando o comprador ainda não está no sistema, 0235:9900000099 para um comprador estrangeiro sem ID Peppol, 0235:9900000097 para as operações assimiladas (deemed supplies).
• Registo legal do vendedor. O número de registo e o respetivo tipo, de um conjunto fixo: TL (licença comercial), EID (Emirates ID), PAS (passaporte) ou CD (decisão do Conselho de Ministros). Numa fatura comercial, o registo do comprador também é obrigatório.
• Moradas estruturadas, incluindo a subdivisão do país (o emirado), do vendedor e do comprador.
• Condições de pagamento como dados. Uma data de vencimento e um código de meio de pagamento em todas as faturas.
• Unidades codificadas e dados de preço completos em todas as linhas. Um código de unidade de medida, preço bruto, preço líquido e quantidade base do preço. As unidades guardadas como texto livre («pcs», «caixa de 12») precisam de uma tabela de correspondência.
• Categoria fiscal por linha, mais uma discriminação por categoria: taxa normal, isento, fora do âmbito, autoliquidação, taxa zero ou regime da margem. As faturas de autoliquidação interna incluem também um texto explicativo e o tipo de bens.
• Montantes em AED, sempre. O montante do IVA e o montante a pagar de cada linha, em AED, seja qual for a moeda da fatura. Uma fatura em moeda estrangeira precisa ainda da moeda de contabilização do imposto e do respetivo total com IVA em AED, à taxa do Banco Central.
• Indicadores do tipo de operação. Oito posições, cada uma com 1 ou 0: zona franca, operação assimilada, regime da margem, fatura resumo, fornecimento contínuo, faturação por agente identificado, comércio eletrónico, exportações. Podem estar várias ativas na mesma fatura, e cada uma traz requisitos próprios. Um cliente numa zona franca, por exemplo, exige também os dados do beneficiário.

Há uma regra que merece um caso de teste próprio: o arredondamento aplica-se ao total da fatura, a duas casas decimais, e não ao nível da linha ou da categoria fiscal. Se o seu código de faturação arredonda cada linha ou cada taxa de IVA, teste-o com faturas reais antes que o seu prestador o faça.

Os códigos de mercadorias HSN são, para já, opcionais, com uma data de obrigatoriedade ainda por anunciar. Se vende bens, acrescente-os enquanto já está a mexer no ficheiro de artigos.

Notas de crédito, adiantamentos e retenções

• Não são permitidas faturas com total negativo. Um crédito tem de ser emitido como nota de crédito eletrónica, e isso inclui uma fatura resumo cujo saldo seja um crédito.
• Uma nota de crédito pode referir várias faturas anteriores e pode abranger só parte de uma delas. Os descontos de volume passam por notas de crédito com o código de motivo correspondente.
• Não existe categoria para faturas provisórias. Cada fatura provisória é uma fatura eletrónica completa, ajustada mais tarde por uma nota de crédito ou por uma fatura adicional.
• Os adiantamentos têm uma fatura fiscal no momento em que são recebidos. A fatura final cobre apenas o saldo remanescente e refere a fatura do adiantamento.
• As retenções podem ser tratadas faturando o valor líquido da retenção e emitindo depois uma fatura separada quando o montante retido se vence.

A receção, de que toda a gente se esquece

O mesmo ASP recebe as faturas dos seus fornecedores. A partir do arranque, chegam em XML e têm de entrar nas contas a pagar. Essa é muitas vezes a metade maior do trabalho, porque mexe na conferência com as encomendas e nas aprovações, e não apenas num modelo de documento.

Os seus grandes fornecedores entram em produção a 1 de janeiro de 2027 e vão pedir-lhe o identificador. Enquanto não estiver em produção, enviam para o endpoint predefinido e entregam-lhe também uma fatura fiscal normal, por isso nada se estraga do seu lado.

Trabalhar com um Accredited Service Provider

A lista do Ministério mostrava 65 prestadores acreditados, mais 5 pré-aprovados ainda em avaliação final, quando a consultámos a 10 de outubro de 2026. A Decisão Ministerial n.º 168 de 2026, anunciada a 9 de outubro e em vigor desde 1 de outubro, substitui as antigas regras para os prestadores: a acreditação passa a ser direta, sem fase de pré-aprovação, e um prestador pré-aprovado tem 30 dias a contar de 1 de outubro para concluir a acreditação, sob pena de perder a pré-aprovação. Escolha a partir da lista de acreditados, não da de pré-aprovados. A adesão é iniciada por si, não pelo prestador: o administrador da conta EmaraTax da empresa abre a secção de faturação eletrónica, seleciona o prestador e é encaminhado para o portal deste. Assine primeiro o contrato e confirme que os dados da empresa no EmaraTax estão atualizados.

Para um sistema à medida, as perguntas que decidem o projeto são técnicas:

1. O que aceita o prestador? O seu próprio payload de API, uma troca de ficheiros, ou XML PINT-AE gerado por si. O formato próprio do prestador dá menos trabalho hoje; o seu próprio PINT-AE permite-lhe mudar de prestador sem reconstruir a correspondência de dados.
2. Como voltam as confirmações? Webhook, polling, ficheiro? Ambos os tipos devem ficar na ficha da fatura, com o UUID que o ASP atribui.
3. O que acontece numa nova tentativa? Os timeouts acontecem. Reenviar uma fatura não pode criar uma segunda, por isso acorde a forma de detetar duplicados e mantenha o seu próprio registo de transmissões como prova do que foi enviado.
4. Há um sandbox onde possa testar rejeições, e não apenas o caminho em que tudo corre bem?
5. Como lhe chegam as faturas recebidas? E o que acontece enquanto o seu lado está em baixo?
6. Faz o arquivo por si? Pode fazê-lo, por contrato, mas a obrigação de conservação continua a ser sua. Os registos podem ficar fora dos EAU, desde que possam ser apresentados à FTA completos e legíveis.

As orientações enumeram o que os testes devem cobrir: o envio dos dados da fatura ao ASP, a entrega ao comprador, a confirmação da troca, a receção da fatura de um fornecedor, a comunicação do ASP à FTA e a confirmação dessa comunicação. Teste o caminho de falha de cada um, não só o de sucesso.

As coimas

A Decisão do Conselho de Ministros n.º 106 de 2025 fixa-as:

• Não implementar o sistema, incluindo não nomear um prestador a tempo: 5 000 AED por mês ou fração de mês.
• Não emitir e transmitir uma fatura eletrónica, ou uma nota de crédito eletrónica: 100 AED por cada uma, com um limite de 5 000 AED por mês civil.
• Não notificar a FTA de uma falha do sistema, ou não informar o seu ASP de alterações aos seus dados de registo: 1 000 AED por dia.

Nenhuma destas se aplica às faturas emitidas voluntariamente antes da sua data obrigatória.

Um plano de nove meses até 1 de julho de 2027

No início de outubro de 2026, uma empresa abaixo do limiar tem nove meses. Chega para um sistema à medida, se o trabalho começar agora.

1. Outubro a novembro de 2026: análise de lacunas. Exporte um ano de faturas e notas de crédito, classifique-as por categoria, cenário, categoria fiscal e moeda, e registe de onde virá cada campo obrigatório.
2. Novembro a dezembro de 2026: escolher um prestador. Faça uma lista curta com base nas perguntas técnicas acima, assine e obtenha acesso ao sandbox. 31 de março de 2027 é a data-limite, não o objetivo.
3. Dezembro de 2026 a fevereiro de 2027: construção. Alterações aos dados mestre e recolha dos identificadores dos clientes, a correspondência de dados, a validação antes do envio, o tratamento das confirmações, uma fila de falhas com um responsável e o processamento das faturas recebidas.
4. Fevereiro a março de 2027: adesão através do EmaraTax, terminando com o seu identificador de participante. Conclua bem antes de 31 de março.
5. Abril a maio de 2027: testes de ponta a ponta com o prestador: os seis passos, incluindo as falhas e as notas de crédito.
6. Maio a junho de 2027: arranque voluntário. As coimas não se aplicam às faturas voluntárias, por isso esta é a fase mais barata para encontrar os últimos problemas. Acorde a sequência com o seu prestador.
7. 1 de julho de 2027: obrigatório. Mantenha a fila de falhas com pessoas atribuídas até à primeira declaração de IVA.

Se pertence ao grupo das grandes empresas e ainda não começou, tem até 30 de outubro de 2026 para nomear um prestador e menos de três meses para entrar em produção. Os passos são os mesmos, comprimidos em semanas, e o formato de entrada do próprio prestador é provavelmente o caminho mais rápido.

O que ainda pode mudar

As datas já mudaram uma vez, as orientações vão na versão 1.1, e as versões do PINT-AE mudam, sendo os prestadores obrigados a usar a mais recente. Mantenha a correspondência de dados num único módulo, atrás de uma interface sua, para que uma atualização da especificação não toque no código de faturação. Os códigos HSN vão passar a ser obrigatórios a dada altura, e o B2C só fica de fora até nova decisão.

Nada disto é motivo para esperar. As decisões estão em vigor e a tabela de coimas está publicada.

Onde obter ajuda

Construímos a ligação entre o sistema que produz as suas faturas e o prestador que as envia: a correspondência de dados, as alterações aos dados mestre, a validação, o tratamento das confirmações e das novas tentativas, e o processamento das faturas recebidas nas contas a pagar. O nosso serviço de integração de faturação eletrónica descreve como esse trabalho decorre e, se a obrigação chegar a meio da substituição de um sistema, veja a modernização de ERP.

Se as suas faturas saem de um sistema para o qual ninguém vende um conector, escreva para office@c9group.dev.