A faturação eletrónica Fawtara em Omã em 2027: o que precisam os ERP e POS à medida

Omã está a substituir as faturas em papel e em PDF por faturas eletrónicas estruturadas em XML, que passam por um prestador de serviços acreditado e são comunicadas à Oman Tax Authority (OTA). O programa chama-se Fawtara. Os sujeitos passivos com operações anuais acima de 5 milhões de OMR começam a 1 de abril de 2027. Todos os outros sujeitos passivos registados para efeitos de IVA começam a 1 de outubro de 2027.

É no retalho que dói mais. As vendas a consumidores ficam abrangidas no mesmo dia que as vendas entre empresas, e cada venda precisa da sua própria fatura eletrónica. Se o software da sua caixa, o seu ERP ou o seu motor de faturação foi desenvolvido internamente ou muito personalizado, o trabalho de produzir esses documentos é seu.

As datas, e qual se aplica a si

A fonte são as perguntas frequentes sobre o Fawtara da OTA, atualizadas pela última vez a 31 de agosto de 2026. O critério está explicado com clareza. Implementa a partir de 1 de abril de 2027 se se verificar qualquer uma destas condições:

• as suas operações de 1 de abril de 2026 a 31 de março de 2027 ultrapassam 5 000 000 OMR, ou
• as suas operações previstas de 1 de abril de 2027 a 31 de março de 2028 ultrapassam 5 000 000 OMR.

«Se nenhuma se verificar, é obrigado a implementar a faturação eletrónica a partir de 1 de outubro de 2027.»

O que conta para o valor: as operações tributáveis, excluindo ativos fixos, bens e serviços sujeitos a autoliquidação e operações intra-CCG. Um grupo IVA é avaliado ao nível do grupo, não membro a membro. Um não residente só conta as operações realizadas em Omã.

Repare na segunda condição. Uma empresa a crescer em direção aos 5 milhões de OMR pode cair no grupo de abril só por causa da sua previsão. Se estiver perto do limite, conte com abril.

A OTA disponibiliza uma ferramenta de verificação do calendário que recebe o seu VATIN e o seu escalão de operações atual e previsto e mostra um potencial período de implementação. Está identificada como servindo apenas para informação e preparação, por isso trate a resposta como uma orientação e as perguntas frequentes como a regra.

O calendário já mudou uma vez

A própria página HTML de perguntas frequentes da OTA ainda descreve o plano antigo: cem grandes empresas a partir de agosto de 2026, todas as grandes empresas a partir de fevereiro de 2027 e todas as restantes a partir de agosto de 2027. O PDF substitui essas datas por abril e outubro de 2027. Para um primeiro grupo de grandes contribuintes selecionados (Rollout 1), agosto de 2026 continua a ser a data oficial de arranque, com um período de tolerância até ao fim de outubro de 2026 no âmbito de um projeto-piloto.

Uma frase na secção de calendário do PDF diz que o cumprimento obrigatório acima de 5 milhões de OMR produz efeitos a «1 de abril de 2026». Todo o resto do mesmo documento diz 1 de abril de 2027, incluindo a resposta detalhada sobre o âmbito citada acima. Parece um lapso, mas é uma boa razão para trabalhar a partir do documento original e não a partir do resumo de alguém, incluindo o nosso.

Como funciona o Fawtara

O Fawtara assenta no Peppol, com um modelo de cinco cantos:

1. Canto 1: a sua empresa, o vendedor, emite a fatura.
2. Canto 2: o seu prestador de serviços acreditado (ASP) valida-a face às regras de Omã e encaminha-a.
3. Canto 3: o prestador de serviços do comprador recebe-a.
4. Canto 4: o comprador.
5. Canto 5: a OTA, que recebe os dados fiscais dos prestadores de serviços.

O formato é XML, construído segundo as especificações PINT Oman que a OpenPeppol publica (Billing Process versão 1.0.1 à data em que escrevemos). As perguntas frequentes são taxativas: «Uma fatura em PDF não é uma fatura eletrónica.» Pode continuar a imprimir em papel, mas só a fatura eletrónica é uma fatura válida para efeitos fiscais.

Três pormenores das perguntas frequentes condicionam a engenharia:

• O prestador valida, a responsabilidade continua a ser sua. O ASP verifica cada fatura face às regras schematron de Omã, mas «a responsabilidade pela conformidade da fatura continua a caber aos sujeitos passivos».
• Liga-se a um prestador de cada vez. Pede a ligação através do portal Fawtara e pode mudar mais tarde.
• Não há uma API normalizada para os sujeitos passivos. Nas palavras das perguntas frequentes, a ligação de um sujeito passivo «não está normalizada e varia consoante o sistema do prestador de serviços». O seu ERP fala com a interface do seu prestador, não com a OTA.

Quando o comprador é um consumidor ou uma empresa que ainda não está na rede, o seu prestador continua a comunicar os dados fiscais à OTA, e o cliente recebe a fatura como hoje. As exportações vão da sua empresa para o seu prestador e deste para a OTA.

Quem já está coberto

Se o fornecedor do seu ERP ou POS é ele próprio um prestador acreditado, ou disponibiliza um conector para um, a maior parte deste artigo não é problema seu. As perguntas frequentes dizem que os sistemas ERP «podem ser mantidos com base no acordo que os sujeitos passivos tenham com os seus prestadores de serviços acreditados», e num sistema de mercado esse acordo cabe ao fornecedor. O seu trabalho são os dados mestre e os testes.

Também pode tornar-se o seu próprio prestador de serviços. Os critérios de acreditação incluem um registo comercial omanense com atividades de informática, um capital social realizado mínimo, historial de atividade e certificação ISO/IEC 27001, e as perguntas frequentes acrescentam a aprovação nas baterias de testes Peppol eDelivery e PINT OM. Isso serve as empresas de software. Não é um atalho para um retalhista.

Este artigo é para todos os outros: empresas cujas faturas saem de um ERP à medida, de um sistema de caixa interno, de um motor de faturação acoplado a uma base de dados antiga, ou de uma filial que ainda passa faturas à mão.

O que tem de mudar no seu software

Mapear os dados das faturas para o PINT Oman

A orientação das perguntas frequentes sobre o mapeamento cabe numa linha: use as especificações PINT de Omã. No modelo semântico, os campos específicos de Omã (com o prefixo BTOM) são onde vai a maior parte do esforço:

• Um UUID para cada documento (BTOM-002). Tem de ser RFC 4122 versão 5, que se baseia num nome. Derive-o de algo estável, como a entidade jurídica, a filial, a caixa e o número do documento, e uma submissão repetida produz o mesmo UUID em vez de uma segunda fatura.
• Um tipo de transação da fatura (BTOM-001). É uma string de 20 posições em que cada posição é um indicador: fatura completa, fatura simplificada, autofaturação, emitida por terceiros, exportação, operação assimilada, autoliquidação na importação de serviços, regime da margem, comércio eletrónico, importação de bens, operação em zona especial, pré-pagamento e outros. Pode ser assinalado mais do que um. O seu sistema tem de saber quais se aplicam a cada fatura, e a maior parte dos ERP nunca guardou essa informação.
• Identificadores do vendedor e do comprador com um código de esquema: registo comercial, número de identificação fiscal, cartão de identificação civil, passaporte, número aduaneiro de importador ou número de licença de zona especial.
• Moeda. A moeda da fatura, a moeda de contabilização do IVA, a taxa de câmbio entre elas e o total do IVA na moeda de contabilização têm todos campos próprios.
• Listas de códigos para a isenção de IVA, os motivos de taxa zero, os tipos de serviço e as subdivisões do país.

Conte que as linhas das faturas se mapeiem sem problemas e que os dados mestre não. Fichas de clientes sem VATIN, números de registo comercial em falta, motivos de isenção em texto livre e moradas sem código de região têm de ser limpos antes da primeira fatura real.

Tratar cada venda como um documento

É esta a regra que muda os sistemas POS: «Não são permitidas faturas consolidadas nas transações B2C. Tem de ser emitida uma fatura eletrónica separada para cada fatura.» Nada de resumo ao fim do dia. Uma loja que regista 3 000 vendas por dia envia 3 000 faturas eletrónicas por dia.

As perguntas frequentes dão 24 horas para as submissões B2C e tempo real para as submissões B2B. Para uma caixa, isso significa:

• O POS gera o XML (ou passa a venda a um serviço que o faça) no momento da venda, com o seu UUID. Há um campo de UUID do recibo separado para o B2C (BTOM-004).
• Uma fila de armazenamento e reenvio guarda os documentos quando a rede ou o prestador estão em baixo e esvazia-se dentro das 24 horas.
• Alguém recebe um alerta quando um documento continua por enviar ao fim de poucas horas, não ao fim de vinte e três.

Compare os preços dos prestadores com o seu volume antes de assinar. As perguntas frequentes dizem que cada prestador define o seu modelo, que «pode incluir mensalidades, taxas por transação ou outras modalidades de preço». Com os volumes do retalho, uma taxa por documento é uma linha do orçamento.

B2B em tempo real

Nas faturas entre empresas, a submissão é em tempo real. O seu ERP lança a fatura, o prestador valida-a e o resultado volta. Isso muda o fluxo das faturas de duas formas. Os erros de validação passam a aparecer no momento do lançamento, por isso alguém na área financeira precisa de um ecrã que mostre a rejeição e lhe permita corrigi-la. E a numeração das faturas, o UUID e a lógica de repetição têm de estar certos desde o primeiro dia, porque um timeout seguido de um reenvio às cegas é a receita para faturas duplicadas.

O fluxo também corre no sentido inverso. Quando a sua empresa é a compradora, as faturas eletrónicas de fornecedores que já estão no Fawtara chegam em XML através do seu prestador, e as contas a pagar precisam de uma forma de as importar.

Códigos QR no recibo impresso

O código QR é gerado pela sua empresa (canto 1), não pelo prestador. É obrigatório em todas as transações B2C, completas ou simplificadas, e aparece na fatura legível por pessoas, não no XML. A OTA tenciona usá-lo para verificar faturas através de uma aplicação móvel. Quanto ao conteúdo, as perguntas frequentes remetem para o Apêndice D do documento Peppol Oman Architecture (versão 1.0.2): obtenha esse apêndice antes de alguém redesenhar um recibo. Os modelos de recibo e os controladores das impressoras fazem parte deste projeto.

Notas de crédito, devoluções e correções

Uma vez emitida, uma fatura eletrónica é ajustada emitindo uma nota de crédito ou de débito eletrónica. A especificação tem campos para o UUID da fatura original e para um código de motivo (BTOM-031 e BTOM-032), por isso um reembolso na caixa tem de conseguir encontrar a venda original.

Importações e autofaturação

As importações de bens e serviços são comunicadas como faturas em autofaturação. Se o seu fluxo de compras regista importações sem emitir nenhum documento, aparece aí um passo novo.

Arquivo

O arquivo continua a ser seu. As perguntas frequentes dizem que a OTA não devolverá a informação das faturas aos sujeitos passivos, e o Peppol não guarda documentos. Guarde juntos o XML validado, a resposta do prestador e a versão impressa, segundo as regras de conservação da legislação do IVA.

Um plano a contar a partir do prazo

As perguntas frequentes dizem que a OTA contacta os participantes de cada fase pelo menos seis meses antes da respetiva integração. Para o grupo de abril, isso é agora.

Se começa a 1 de abril de 2027:

1. Outubro de 2026: confirme o seu grupo com a ferramenta de verificação e com o critério das perguntas frequentes. Liste todos os sistemas que emitem faturas: o ERP, cada POS, o checkout de comércio eletrónico, a faturação de alugueres ou subscrições e qualquer livro de faturas manual.
2. Novembro de 2026: escolha um prestador. Peça a documentação da API e um ambiente de testes antes de assinar, e pergunte pelo volume B2C, pelo preço por documento, pelo funcionamento offline e pelo aspeto das respostas de validação. Peça a ligação através do portal Fawtara.
3. Dezembro de 2026 a janeiro de 2027: desenvolvimento. Mapeamento de campos, geração de UUID, lógica do tipo de transação, a fila do POS, códigos QR, fluxo das notas de crédito, faturas recebidas. Corra as regras schematron de Omã, disponíveis nos ficheiros do PINT Oman, na sua própria pipeline de testes, para que as falhas apareçam no desenvolvimento e não no prestador.
4. Fevereiro de 2027: testes de ponta a ponta no ambiente de testes do prestador, com exemplos reais de todos os tipos de transação que de facto emite, incluindo os mais incómodos (exportações, devoluções sem recibo, moeda estrangeira).
5. Março de 2027: um ensaio em produção com uma filial ou uma linha de negócio, um plano de passagem e uma escala de suporte para as primeiras semanas.

Se começa a 1 de outubro de 2027, a sequência é a mesma, com seis meses de diferença: prestador escolhido até ao fim do primeiro trimestre, desenvolvimento no segundo, testes concluídos até agosto. Não gaste a folga. A limpeza dos dados demora sempre mais do que alguém prevê.

O que continua incerto

As datas já mudaram uma vez e podem voltar a mudar. Planeie com base no PDF de 31 de agosto de 2026 e consulte os documentos da OTA todos os meses, em vez de se fiar nas notícias. A base legal é a Decisão 189/2026, que altera o Regulamento Executivo da Lei do IVA. As perguntas frequentes dizem que serão aplicadas sanções ao abrigo da legislação do IVA a partir do início da obrigação, mas não indicam montantes, por isso nós também não.

As especificações também têm versões. O site do Peppol indica os processos PINT OM de faturação, autofaturação e dados fiscais na versão 1.0.1, sem data de publicação. A data que mostra, 29 de julho de 2026, é a data de publicação do PDK 1.4.4 na mesma página, não das especificações de Omã. Fixe a versão com que desenvolve e consulte a página para saber se há novas.

Onde obter ajuda

Desenvolvemos o conector entre o sistema que de facto usa e o formato que a obrigação exige: mapeamento de campos, lógica de UUID e de numeração, filas do POS, validação na sua pipeline e integração com o prestador que escolher. O nosso serviço de integração de faturação eletrónica cobre esse trabalho e, quando o obstáculo é o próprio ERP, a modernização de ERP é por onde se começa.

Se está no grupo de abril e ainda não escolheu um prestador, escreva para office@c9group.dev.