Pontos essenciais a reter
Em 2026, existem quatro áreas de dados que merecem especial atenção nos projetos de faturação eletrónica: NIF/NIPC do cliente, morada completa de entrega quando for necessária ao processo, natureza dos bens ou serviços e regime de IVA aplicável. Estes dados complementam os elementos fiscais e operacionais já exigidos pela legislação portuguesa e devem manter-se íntegros durante qualquer projeto de migração.
Em Portugal, a faturação eletrónica B2B continua, em princípio, sujeita à aceitação do destinatário, nos termos do Decreto-Lei n.º 28/2019, de 15 de fevereiro. O calendário obrigatório é diferente nos contratos públicos: as grandes empresas emitem faturas eletrónicas desde 1 de janeiro de 2021, enquanto as micro, pequenas e médias empresas e as entidades públicas enquanto cocontratantes ficam abrangidas a partir de 1 de janeiro de 2027. Este enquadramento resulta da faturação eletrónica nos contratos públicos, regulada pela Diretiva 2014/55/UE e pela legislação portuguesa aplicável.
As quatro áreas de preparação são as seguintes: o NIF/NIPC do cliente, a morada completa de entrega quando seja necessária para identificar o local servido, a informação sobre a natureza dos bens ou serviços faturados e o regime de IVA aplicável. Quando esteja em causa o Regime de IVA de Caixa, a menção correta é «IVA – regime de caixa»; esta regra não corresponde a uma opção de IVA sobre os débitos. A distinção é essencial para não transformar uma necessidade de dados numa afirmação fiscal incorreta.
Para as equipas financeiras, de sistemas de informação e de integração, a pergunta certa não é apenas «o dado existe?». Passa a ser «que campo o alimenta, a partir de que fonte, com que controlo e com que evidência em caso de rejeição?». É nesta lógica que se posiciona este guia: não como uma definição de fatura eletrónica, mas como uma checklist operacional de validação de campos ERP.
A migração para CIUS-PT, UBL 2.1 ou CII não pode degradar os elementos fundamentais: data de emissão, número sequencial da fatura, identidade e NIF do vendedor e do comprador quando exigível, número da encomenda quando exista, designação dos bens ou serviços, quantidades, preços unitários, taxas de IVA, valores tributáveis e IVA por taxa, condições de pagamento e menções específicas. Devem também ser considerados, consoante o regime aplicável, o QR code, o ATCUD e os requisitos relativos a programas de faturação certificados. Estes dados já costumam existir, mas podem estar distribuídos pelo ERP, aplicação de faturação, cadastro de clientes, módulo fiscal, EDI ou portal de vendas.
O principal risco é perder granularidade durante o processo de mapeamento. Uma fatura em PDF legível por uma pessoa pode ocultar aproximações; uma fatura estruturada enviada para um cliente público, para a FE-AP ou para outro canal eletrónico expõe imediatamente as incoerências. A recomendação é manter uma matriz de correspondência entre os campos anteriores, os novos campos estruturados e as regras de controlo esperadas antes da emissão.
Algumas menções não são sistemáticas, mas continuam a ser críticas. O artigo 36.º do Código do Imposto sobre o Valor Acrescentado prevê, nomeadamente, a expressão «IVA – autoliquidação» quando o adquirente é responsável pelo imposto, a indicação do motivo justificativo da não aplicação do IVA em caso de isenção e a menção «autofaturação» quando o adquirente emite a fatura em nome e por conta do fornecedor. A autofaturação pressupõe, entre outras condições, acordo escrito prévio e aceitação do conteúdo pelo fornecedor.
No ERP, estas menções não devem ser tratadas como texto livre. Devem resultar de regras fiscais documentadas: regime de IVA da entidade, natureza do fluxo, país, estatuto do cliente, natureza das linhas, contrato, Incoterms® 2020 quando aplicáveis e parametrização dos artigos ou serviços. É um ponto central de governação nos projetos de desmaterialização: a conformidade depende tanto dos dados-mestres como do formato.
O processo de mapeamento deve associar cada dado a um campo ERP, a uma fonte-mestra e a um controlo. Sem esta rastreabilidade, uma fatura pode ser tecnicamente válida, mas fiscalmente frágil, ou ser corretamente emitida e, ainda assim, rejeitada pelo destinatário devido a dados incoerentes.
Uma boa tabela de mapeamento distingue os dados de cabeçalho, intervenientes, entrega, linha, IVA e pagamento. Esta estrutura evita concentrar tudo no modelo de impressão da fatura e permite que cada equipa assuma o seu perímetro: finanças, gestão comercial, master data, fiscalidade, sistemas de informação e integração EDI/API.
| Menção ou dado a controlar | Campo ERP de destino | Fonte-mestra recomendada | Erro frequente a evitar |
|---|---|---|---|
| NIF/NIPC do cliente | Identificador fiscal e legal da entidade faturada | Cadastro de clientes / master data de entidades | Utilizar um código interno de estabelecimento como identificador fiscal principal sem uma regra clara |
| Morada de entrega quando diferente | Morada do local entregue ou destinatário logístico | Encomenda, entrega, cadastro de instalações do cliente | Reutilizar automaticamente a morada de faturação em todos os fluxos multi-site |
| Natureza da operação | Tipo de fluxo: bens, serviços ou misto | Artigos, serviços, linhas de encomenda e regras fiscais | Classificar toda a fatura pela atividade do cliente, em vez de analisar as linhas faturadas |
| Regime de IVA de Caixa, quando aplicável | Indicador fiscal da entidade ou atividade | Parametrização de IVA, entidade faturante e condições de venda | Adicionar manualmente a menção sem coerência com o regime fiscal |
| IVA – autoliquidação | Menção fiscal condicional | Regras de IVA, país, estatuto do cliente e natureza da operação | Omitir a menção nos fluxos abrangidos ou ativá-la de forma demasiado ampla |
| Valores tributáveis/IVA por taxa e moeda | Totais fiscais estruturados | Motor de faturação e módulo fiscal | Transmitir apenas um total global, sem discriminação utilizável por taxa |
A fonte-mestra varia consoante o dado. O NIF/NIPC pertence ao cadastro da entidade; a morada de entrega pode vir da encomenda ou da guia de remessa; a natureza da operação depende das linhas; as menções de IVA resultam da parametrização fiscal; determinadas condições de pagamento ou de autofaturação podem vir do contrato. Estas responsabilidades devem ser documentadas antes de alterar as interfaces.
O Decreto-Lei n.º 198/2012, de 24 de agosto define a comunicação eletrónica dos elementos das faturas à Autoridade Tributária e Aduaneira. Para os documentos emitidos desde 1 de janeiro de 2023, a comunicação deve ser efetuada, em regra, até ao dia 5 do mês seguinte. Entre os dados relevantes encontram-se o NIF do emitente e do adquirente quando aplicável, número e data do documento, tipo de documento, valor tributável, taxas, motivo da não aplicação do IVA, imposto liquidado, regime de caixa, documento de origem ou retificado e ATCUD. Num projeto ERP, esta lista constitui uma base de controlo operacional.
Antes da transmissão, os controlos devem combinar regras de presença, formato e negócio. Por exemplo: NIF/NIPC do cliente presente e coerente com a entidade faturada; morada de entrega preenchida quando o processo a exige; natureza dos bens e serviços compatível com as linhas; «IVA – autoliquidação» acionado apenas nos casos previstos; valores discriminados por taxa; moeda indicada; QR code e ATCUD gerados quando sejam aplicáveis.
Os controlos devem ser colocados o mais próximo possível da origem dos dados e complementados no serviço de faturação eletrónica ou no canal utilizado pelo destinatário. O objetivo não é deslocar os erros do ERP para a plataforma, mas criar uma cadeia contínua de qualidade, desde a encomenda até à fatura e à comunicação à AT.
O NIF/NIPC do cliente é o identificador fiscal e legal central a preparar. Os códigos internos de instalações continuam a ser úteis para identificar um estabelecimento, uma morada de entrega ou uma regra de encaminhamento, mas não substituem o NIF/NIPC no campo fiscal esperado.
Nos cadastros ERP, recomenda-se guardar separadamente o NIF/NIPC, os códigos internos das instalações, o número de identificação IVA intracomunitário e, quando necessário, os identificadores internos do cliente. Para uma pessoa coletiva portuguesa, o NIPC corresponde, em geral, ao NIF. No contexto intracomunitário, o número de identificação IVA é normalmente formado pelo prefixo «PT» seguido do NIF e deve ser validado no sistema VIES quando o tratamento fiscal o exigir.
Esta separação evita decisões tardias durante o processo de mapeamento. Também facilita o encaminhamento para os canais eletrónicos definidos pelo cliente e a gestão de grupos com várias entidades. Para aprofundar o enquadramento geral dos formatos e obrigações, deve ser consultado em complemento o conteúdo Fatura eletrónica: definição, formatos e obrigações.
A melhoria da qualidade do cadastro de clientes deve anteceder os testes de aceitação. Os duplicados surgem frequentemente quando vários estabelecimentos do mesmo cliente são criados como entidades independentes ou quando as moradas de faturação e entrega são confundidas. A recomendação é distinguir claramente: entidade legal faturada, estabelecimento entregue, morada de faturação, morada de entrega e canal de encaminhamento.
Os controlos úteis incluem a deteção de NIF/NIPC em falta, do mesmo NIF/NIPC partilhado por várias contas sem justificação, de códigos de instalação incoerentes com a morada, de número de IVA intracomunitário ausente nos casos relevantes e de estatutos de cliente desalinhados com as regras fiscais. Esta etapa envolve tanto as finanças e a gestão comercial como os sistemas de informação.
A faturação eletrónica assenta numa lógica de encaminhamento. É necessário saber para que canal enviar a fatura, para que cliente, com que identificador e segundo que protocolo. No B2G português, o encaminhamento depende da entidade pública, da sua eventual adesão à FE-AP e dos canais que aceita. Os fornecedores devem confirmar os requisitos do destinatário ou utilizar o portal B2AP/FE-AP quando a entidade pública adere a essa solução.
Na prática, as regras de encaminhamento devem ser testadas com os clientes estratégicos, grupos com vários estabelecimentos, clientes públicos e privados de acordo com cada fluxo e situações em que várias entidades jurídicas partilham instalações logísticas. A integração deve ligar o serviço de faturação eletrónica, o ERP e os fluxos B2B existentes, sem pressupor a existência de um diretório B2B nacional único.
Os riscos no ERP encontram-se frequentemente em dados que parecem secundários: local entregue, tipologia das linhas, regime de IVA e parametrização da entidade faturante. São dados operacionais partilhados entre vendas, logística e finanças, mas condicionam a coerência fiscal e comercial da fatura.
No retalho, distribuição especializada, indústria ou logística contratual, a morada de faturação pode ser a da sede ou de uma central de compras, enquanto a entrega se destina a uma loja, armazém, plataforma regional ou instalação do cliente. Mesmo não sendo uma menção geral obrigatória em todas as faturas B2B portuguesas, se o ERP não conservar corretamente esta distinção, a fatura estruturada e o processo de conciliação podem ficar incompletos ou incoerentes.
Os projetos devem auditar as regras de recuperação da morada a partir da encomenda, guia de remessa e cadastro de instalações. Quando intervêm vários sistemas — por exemplo, OMS, WMS, TMS, ERP e EDI —, o dado de entrega deve permanecer rastreável até à fatura. É precisamente aqui que um ecossistema logístico integrado cria valor: a partilha de dados evita correções manuais tardias.
A natureza da operação não deve ser inferida de forma aproximada. Uma fatura pode respeitar apenas a bens, apenas a serviços ou a uma operação mista. Embora o CIVA não imponha uma categoria global de cabeçalho equivalente a «bens/serviços/misto», exige a quantidade e a designação usual dos bens ou serviços, bem como os elementos necessários para determinar a taxa aplicável. O melhor elemento de decisão é normalmente a linha da encomenda ou o artigo/serviço, e não o cliente ou a entidade faturante por si só.
É, por isso, necessário definir uma regra estável para famílias de artigos, tipos de serviço, encargos acessórios, transporte refaturado, instalação, manutenção, notas de crédito e faturas retificativas. Numa operação mista, o ERP deve conservar o detalhe das linhas que permite justificar o respetivo tratamento fiscal.
A menção «IVA – regime de caixa» apenas deve aparecer quando a entidade e a operação estiverem efetivamente abrangidas pelo Regime de IVA de Caixa. A regra deve estar associada à parametrização fiscal da entidade ou atividade relevante e ser propagada para a fatura sem nova introdução manual. As equipas financeiras devem validar esta configuração antes dos testes de aceitação.
O risco clássico consiste em acrescentar a menção num modelo de impressão ou campo livre sem controlar a realidade fiscal. Com a faturação eletrónica, esta abordagem torna-se frágil: a menção visível, o dado estruturado e o contexto fiscal têm de estar alinhados.
Os testes devem demonstrar que os dados estão corretos em cenários reais. Validar apenas CIUS-PT, UBL 2.1 ou CII não é suficiente: é necessário simular casos simples, mistos, condicionais, retificativos e rejeições do canal de destino.
Um plano de testes robusto deve abranger, no mínimo, os seguintes cenários:
Cada cenário deve ser verificado na representação visual, no ficheiro estruturado, nos dados enviados ao serviço ou canal de faturação eletrónica e no retorno de estado. As equipas de finanças, gestão comercial, IT, fiscalidade e master data devem participar nestes testes.
Em Portugal, não existe um estatuto geral equivalente a uma plataforma privada com exclusividade legal para emitir, transmitir e receber todas as faturas B2B e comunicar os dados fiscais. A FE-AP, disponibilizada pela ESPAP, I. P., serve a faturação da Administração Pública. A faturação eletrónica nos contratos públicos é regulada pela Diretiva 2014/55/UE, transposta pelo Decreto-Lei n.º 111-B/2017 e organizada pelo Decreto-Lei n.º 123/2018, de 28 de dezembro.
Os testes devem, portanto, integrar os controlos antes do envio, as validações do canal ou plataforma, os estados do ciclo de vida, as rejeições, as correções e as reemissões. O serviço de faturação eletrónica não substitui a qualidade do ERP: protege a transmissão e reforça os controlos numa cadeia coerente.
Uma rejeição não deve ser corrigida apenas fatura a fatura. Deve desencadear uma análise da causa: campo em falta, fonte-mestra incorreta, regra de mapeamento incompleta, cadastro do cliente desatualizado, parametrização fiscal insuficiente ou regra de encaminhamento errada. A correção deve ser registada e, quando necessário, refletida nos dados-mestres.
Para gerir a entrada em produção, recomenda-se um dashboard simples: número de faturas testadas, taxa de rejeição, causas de rejeição, tempo de correção, campos mais frequentemente incorretos e responsáveis pelos dados. Esta governação transforma a conformidade numa melhoria duradoura do processo order-to-cash.
Ligar o ERP, o serviço de faturação eletrónica e a rede B2B reduz as rejeições ao tratar os dados como um ativo partilhado. A conformidade não deve permanecer isolada nas finanças: depende também das encomendas, entregas, cadastros de clientes, regras fiscais e trocas entre sistemas e parceiros.
Os dados de faturação revelam uma realidade simples: a fatura é o último elo de um processo mais amplo. O NIF/NIPC vem do cadastro do cliente, a morada de entrega da execução logística, a natureza dos bens ou serviços das linhas de venda, as menções de IVA da parametrização fiscal e o encaminhamento do canal acordado com o cliente.
Uma organização em silos pode gerar correções tardias, dispendiosas e repetitivas. Em contrapartida, uma organização integrada partilha os mesmos dados entre ERP, EDI/API, clientes, fornecedores e serviços de faturação. O objetivo é garantir a conformidade através da qualidade dos dados de ponta a ponta, e não apenas através de uma validação final.
O serviço de faturação eletrónica da Generix pode suportar a emissão, receção, comunicação dos dados fiscais aplicáveis e trocas entre sistemas e parceiros. Integra-se na gestão histórica de fluxos B2B e EDI, útil para o processo de mapeamento, onboarding de parceiros e continuidade das trocas. Para enquadrar o papel deste tipo de serviço antes de um projeto, pode ser consultado o conteúdo Plataforma de faturação eletrónica: definição e função.
Num projeto ERP, o valor está na articulação entre dados legais, fluxos estruturados, controlos, estados e trocas com parceiros. A fatura eletrónica não deve ser tratada como um simples conector: deve integrar-se nos processos order-to-cash, procure-to-pay e de comunicação fiscal.
A conformidade mínima consiste em produzir um ficheiro aceite. Uma abordagem mais robusta procura reduzir litígios, acelerar correções, tornar os dados-mestres mais fiáveis e disponibilizar estados utilizáveis pelas equipas financeiras e de apoio ao cliente. Esta lógica é particularmente importante para organizações com várias entidades, vários locais ou um elevado nível de interligação com clientes e parceiros.
Antes da entrada em produção, devem ser auditados os campos do ERP, as regras fiscais, os cadastros de clientes e os fluxos B2B. Para assegurar a emissão, receção, comunicação fiscal e os controlos de conformidade campo a campo, pode ser avaliado o serviço de faturação eletrónica da Generix e discutido com as equipas o plano de implementação.
Em resumo
Devem ser assegurados os elementos exigidos pelo CIVA, incluindo data e número sequencial, identificação e NIF das partes quando aplicável, descrição e quantidade dos bens ou serviços, valores tributáveis, taxas e montantes de IVA e o motivo da não aplicação do imposto. No ERP, também devem ser preparados o NIF/NIPC do cliente, as moradas relevantes, a natureza das linhas, o regime de IVA e os dados necessários à comunicação à AT.
Não foi estabelecido em Portugal um identificador legal de estabelecimento equivalente ao SIRET. O NIF/NIPC identifica a entidade legal. No entanto, o ERP deve conservar códigos internos próprios para gerir estabelecimentos, moradas de entrega, instalações do cliente e regras de encaminhamento.
Não existe uma obrigação geral portuguesa que imponha a morada de entrega em todas as faturas B2B. Ainda assim, deve ser conservada quando for necessária ao processo comercial, logístico ou contratual. Os casos multi-site, armazéns, lojas e plataformas logísticas devem ser testados especificamente.
O CIVA não exige uma categoria global «bens/serviços/misto», mas exige a designação dos bens ou serviços e os elementos necessários para determinar a taxa aplicável. No ERP, a regra deve basear-se nos artigos, serviços e linhas de encomenda, e não numa seleção manual ao nível do cabeçalho.
A menção aplica-se quando a entidade e a operação estão efetivamente abrangidas pelo Regime de IVA de Caixa. Deve estar associada à parametrização fiscal da entidade faturante ou da atividade relevante e ser controlada antes da emissão.
Sim. A menção «IVA – autoliquidação» continua necessária quando o adquirente é responsável pelo pagamento do imposto. Deve ser acionada por regras fiscais condicionais e verificada antes da transmissão pelo canal de faturação eletrónica.
Os campos prioritários são o cadastro de clientes, NIF/NIPC, números de IVA intracomunitário, moradas de faturação e entrega, natureza dos bens e serviços, regras de IVA, menções condicionais, QR code, ATCUD, formatos de saída e mapeamento para o serviço de faturação eletrónica. Para cada campo, a auditoria deve identificar uma fonte-mestra e um responsável pelos dados.
Os testes devem abranger vários cenários: fatura normal, entrega numa morada diferente, serviço abrangido pelo Regime de IVA de Caixa, autoliquidação, operação mista, documento retificativo e rejeição pelo canal de destino. Cada teste deve verificar o dado de origem, o ficheiro estruturado, a transmissão e o retorno de estado.
Saiba como gerir stocks, escolher entre FIFO, FEFO e LIFO e acompanhar os KPI que protegem a disponibilidade, o serviço e a fiabilidade do inventário.
Compare soluções WMS através de uma grelha ponderada que abrange funções, integração, automatização, escalabilidade, TCO, suporte e risco do projeto.
Trabalhe com a nossa equipa para criar a sua pilha de software da cadeia de abastecimento ideal e adaptá-la às suas necessidades empresariais específicas.
