A Generix nomeia Jimmy Anidjar como Presidente Não Executivo do Conselho de Administração Saiba mais
Pontos essenciais a reter
Os principais formatos EDI a conhecer são EDIFACT, ANSI X12, GS1/EANCOM, UBL, UN/CEFACT CII e Factur-X. Para uma direção de sistemas de informação, o desafio não consiste em escolher um único standard, mas em orquestrar várias linguagens em função dos parceiros, países e fluxos.
Um formato EDI define a estrutura de um documento eletrónico: segmentos, etiquetas, códigos, regras de cardinalidade, versões e controlos. Se pretender rever o conceito geral antes de entrar na comparação, pode consultar a nossa definição detalhada de EDI. A tabela seguinte centra-se na escolha operacional dos formatos.
| Formato ou norma | Região de utilização frequente | Casos de utilização típicos | Exemplos de mensagens ou documentos | Ponto de atenção para a DSI |
|---|---|---|---|---|
| UN/EDIFACT | Europa, comércio internacional, transportes | Encomenda, aviso de expedição, fatura, instrução de transporte, estado do transporte | ORDERS, ORDRSP, DESADV, INVOIC, IFTMIN, IFTSTA | Gerir as numerosas versões e variantes definidas pelos parceiros |
| ANSI X12 | América do Norte | Supply chain, transportes, saúde, finanças | 850, 855, 856, 810, 204, 214 | Indispensável para parceiros norte-americanos que utilizam X12 |
| GS1/EANCOM | Distribuição, bens de grande consumo, retalho | Order-to-cash, logística de loja, relação fornecedor-distribuidor | ORDERS, DESADV, INVOIC no perfil GS1 | Subconjunto de EDIFACT mais prescritivo e associado aos identificadores GS1 |
| UBL | Faturação eletrónica, contratação pública, redes modernas | Fatura, nota de crédito, encomenda, resposta, catálogo | Invoice, CreditNote, Order | Sintaxe XML; em Portugal, verificar nomeadamente o perfil CIUS-PT e a versão UBL 2.1 no B2G |
| UN/CEFACT CII | Faturação eletrónica EN 16931 | Fatura estruturada, troca interoperável | Cross Industry Invoice | Sintaxe reconhecida pela EN 16931 e utilizada, entre outros, pelo Factur-X; confirmar a aceitação pelo canal de destino |
| Factur-X | Utilização internacional, com forte implantação em França e na Alemanha; formato facultativo em Portugal | Fatura eletrónica híbrida, legível e estruturada | PDF/A-3 com XML CII incorporado | Formato misto útil para conciliar leitura humana e automatização, mas sem perfil português oficial |
As normas EDI históricas, EDIFACT e X12, foram concebidas para cadeias interempresariais altamente industrializadas: encomendas, expedições, faturas, transportes, confirmações e estados. Continuam a ser estruturantes nos ERP, WMS, TMS e plataformas B2B, porque muitas empresas líderes construíram os seus processos de integração em torno destas mensagens.
O EANCOM responde a uma lógica setorial: harmonizar a utilização do EDIFACT no ecossistema GS1, sobretudo na distribuição. UBL, CII e Factur-X respondem mais diretamente às necessidades de faturação eletrónica, conformidade com a EN 16931 e interoperabilidade regulamentar. Nos projetos, importa por isso distinguir o standard técnico, o perfil setorial e o perfil legal aplicável.
Uma arquitetura robusta não trata os formatos EDI como silos. Separa três camadas: o formato recebido ou emitido pelo parceiro, o modelo canónico interno e os conectores para ERP, WMS, TMS, OMS, finanças ou, no contexto da Administração Pública portuguesa, para a solução FE-AP ou para o canal indicado pela entidade contratante. Esta separação facilita as conversões entre EDIFACT, X12, EANCOM, XML, UBL, CII, JSON, CSV ou API sem voltar a desenvolver cada aplicação de negócio.
É também esta a lógica de uma supply chain colaborativa: os clientes não procuram apenas otimizar um sistema interno, mas também garantir a fiabilidade dos dados partilhados entre fornecedores, transportadores, 3PL, clientes e equipas financeiras.
EDIFACT, X12 e EANCOM continuam a ser a base das trocas de supply chain de elevado volume. O EDIFACT domina muitos fluxos internacionais, o X12 estrutura numerosas trocas norte-americanas e o EANCOM adapta o EDIFACT às práticas GS1 da distribuição.
O UN/EDIFACT — Intercâmbio Eletrónico de Dados das Nações Unidas para Administração, Comércio e Transportes — é um referencial de mensagens normalizadas mantido pelo UN/CEFACT. Em 2025, o relatório do presidente do UN/CEFACT confirmou a publicação dos diretórios UN/EDIFACT D.24B e D.25A, bem como das bibliotecas associadas CCL, XML Schema Library e dos modelos de dados de referência D.24B e D.25A, no âmbito dos standards de facilitação do comércio e dos transportes publicados pela UNECE em 2025. A newsletter do UN/CEFACT de dezembro de 2025 confirma igualmente a atualização contínua destes standards na edição de dezembro de 2025.
Na supply chain, o EDIFACT abrange nomeadamente ORDERS para a encomenda, ORDRSP para a resposta, DESADV para o aviso de expedição, INVOIC para a fatura, IFTMIN para a instrução de transporte e IFTSTA para o estado do transporte. A recomendação operacional é documentar com precisão a versão do diretório, o perfil do parceiro e as regras de codificação, porque dois fluxos identificados como «EDIFACT INVOIC» podem ser incompatíveis na prática.
O ANSI X12 é a referência histórica de numerosas trocas B2B na América do Norte. O calendário oficial do X12 indica que um standard ANSI é reavaliado aproximadamente a cada cinco a sete anos, que as versões anuais utilizam um identificador de seis algarismos e que a versão 008070 foi confirmada em janeiro de 2026 e disponibilizada no Glass em março de 2026, de acordo com o calendário X12.
Os transaction sets X12 definem os dados trocados para objetivos de negócio específicos. O diretório X12 inclui, entre outros, os domínios das finanças, saúde, seguros, supply chain, transportes e aeroespacial. Para uma DSI portuguesa ou europeia que trabalhe com distribuidores ou operadores logísticos norte-americanos, a diferença entre EDIFACT e X12 é menos teórica do que contratual: condiciona o onboarding dos parceiros, os testes e a supervisão das rejeições.
O EANCOM é um subconjunto GS1 do UN/EDIFACT. O referencial GS1 indica que o standard em vigor é o GS1 EANCOM 2022, com a última alteração datada de 8 de setembro de 2025 no referencial GS1 EANCOM 2022. Em Portugal, é difundido localmente pela GS1 Portugal — CODIPOR. Na prática, o EANCOM utiliza os identificadores GS1, GLN — Número Global de Localização, GTIN — Número Global de Item Comercial e regras mais enquadradas para os processos de distribuição.
Este enquadramento é útil no retalho e nos bens de grande consumo: uma encomenda a fornecedor, um DESADV com a estrutura palete-volume, uma fatura e as referências dos artigos devem permanecer coerentes entre fornecedor, distribuidor, armazém, transportador e área financeira. O EANCOM deve ser gerido como um perfil de negócio completo, e não como simples EDIFACT genérico.
UBL, UN/CEFACT CII e Factur-X estão no centro dos formatos europeus de faturação eletrónica. Representam a fatura através de dados estruturados conformes com a EN 16931, utilizando sintaxes e perfis de implementação diferentes. Em Portugal, importa distinguir o regime fiscal geral, a comunicação de dados à Autoridade Tributária e Aduaneira e o regime B2G baseado no CIUS-PT e na FE-AP.
UBL, ou Universal Business Language, é uma família XML de documentos empresariais. O índice oficial da OASIS Open apresenta a UBL 2.4 como OASIS Standard de 20 de junho de 2024. A UBL 2.5 CSD03 é datada de 11 de fevereiro de 2026 no diretório OASIS UBL. Para evitar confusões, uma DSI deve distinguir a documentação genérica mais recente da versão exigida por um perfil nacional ou por uma rede.
Em Portugal, a faturação eletrónica na contratação pública utiliza o CIUS-PT — Core Invoice Usage Specification Portugal. A versão CIUS-PT 2.1.1, de 26 de fevereiro de 2021, publica uma representação sintática em UBL 2.1. Por isso, a arquitetura deve registar separadamente a sintaxe, a versão, o perfil de fatura, as regras de validação e o canal de troca.
UN/CEFACT CII, ou Cross Industry Invoice, é uma sintaxe XML de faturação eletrónica. Para aprofundar o conceito sem tornar este guia demasiado pesado, pode consultar a nossa página de glossário sobre UN/CEFACT CII. Nos projetos de e-invoicing, o CII surge diretamente como ficheiro XML ou, indiretamente, como XML incorporado no Factur-X.
A Norma Europeia EN 16931-1:2017 define o modelo semântico dos elementos essenciais de uma fatura eletrónica. Em Portugal, a Diretiva 2014/55/UE relativa à faturação eletrónica nos contratos públicos foi transposta pelo Decreto-Lei n.º 111-B/2017, de 31 de agosto. A Portaria n.º 289/2019, de 5 de setembro, atribui à eSPap a definição dos requisitos técnicos aplicáveis, concretizados no CIUS-PT e nas normas da FE-AP. Embora CII D16B seja uma das sintaxes reconhecidas pela EN 16931, a documentação operacional publicada para a FE-AP utiliza atualmente CIUS-PT em UBL 2.1; a aceitação de CII deve, por isso, ser confirmada com o canal destinatário.
O Factur-X é um formato híbrido: combina um PDF legível por pessoas com um ficheiro XML estruturado incorporado. O comunicado de 10 de junho de 2026 apresentou o Factur-X 1.09 / ZUGFeRD 2.5 e a atualização das listas de códigos da EN 16931 no anúncio do Factur-X 1.09 / ZUGFeRD 2.5. Esta versão foi posteriormente substituída pelo Factur-X 1.09.2 / ZUGFeRD 2.5.2, publicado em 4 de agosto de 2026.
Em Portugal, o Factur-X pode ser utilizado contratualmente se for aceite pelo destinatário e se a fatura respeitar as regras fiscais portuguesas. Não é, contudo, o perfil oficial publicado para a FE-AP. O Decreto-Lei n.º 28/2019, em vigor desde 16 de fevereiro de 2019, admite a emissão eletrónica mediante aceitação do destinatário e prevê mecanismos para garantir autenticidade e integridade, incluindo assinatura eletrónica qualificada, selo eletrónico qualificado ou EDI. Separadamente, os elementos das faturas são comunicados à Autoridade Tributária e Aduaneira ao abrigo do Decreto-Lei n.º 198/2012, nomeadamente através do e-Fatura, web service ou ficheiro estruturado baseado no SAF-T (PT).
| Marco em Portugal | Obrigação ou enquadramento | Impacto nos formatos |
|---|---|---|
| 16 de fevereiro de 2019 | Entrada em vigor do regime geral do Decreto-Lei n.º 28/2019 | Garantir aceitação do destinatário, autenticidade, integridade, legibilidade, arquivo e compatibilidade com os mecanismos fiscais portugueses |
| 1 de janeiro de 2021 | Emissão de faturas eletrónicas pelos grandes fornecedores da Administração Pública | Converter fluxos ERP, EDI INVOIC ou portais de fornecedores para o perfil e canal B2G aplicáveis, nomeadamente CIUS-PT em UBL 2.1 |
| 1 de janeiro de 2027 | Emissão de faturas eletrónicas pelas micro, pequenas e médias empresas e pelas entidades públicas enquanto cocontratantes | Alargar validações, integração com a FE-AP ou canal indicado e comunicação dos elementos das faturas à AT através dos mecanismos aplicáveis |
O formato EDI certo é aquele que o parceiro consegue processar, que o país aceita e que a arquitetura consegue supervisionar. A decisão deve combinar geografia, setor, documento, maturidade dos sistemas de informação e requisitos regulamentares.
A abordagem recomendada consiste em partir do fluxo de negócio e só depois selecionar o formato. Uma encomenda de retalho europeia utilizará frequentemente EDIFACT ou EANCOM; um distribuidor norte-americano poderá exigir X12; uma fatura destinada à Administração Pública portuguesa deverá respeitar o CIUS-PT e o canal indicado pela entidade contratante; um parceiro digitalmente maduro poderá aceitar UBL, CII, API, JSON ou, por acordo, um formato híbrido.
Geografia: EDIFACT para numerosas trocas internacionais, X12 para a América do Norte e perfis nacionais de e-invoicing para a conformidade local.
Setor: EANCOM e GS1 na distribuição, mensagens de transporte para 3PL e expedidores e perfis de faturação para finanças e direção financeira.
Documento: encomenda, ASN, fatura, estado do transporte, nota de crédito ou ciclo de vida da fatura não seguem as mesmas regras.
Maturidade dos sistemas: um parceiro pode operar com EDI histórico, portal, API ou formato híbrido; o objetivo é orquestrar estes níveis sem interromper o processo.
Numa encomenda, o formato deve preservar referências de artigos, locais de entrega, quantidades, preços, datas e condições logísticas. Num DESADV ou ASN, o objetivo é preparar a receção em armazém: volumes, paletes, lotes, SSCC — Código de Série da Unidade Logística —, datas, quantidades e desvios previstos alimentam o WMS.
Numa fatura, as necessidades mudam: conformidade fiscal, menções obrigatórias, reconciliação entre encomenda, receção e fatura e estados do ciclo de vida. Num estado de transporte, o TMS deve receber informação suficientemente normalizada para informar o cliente, recalcular a ETA ou gerir o OTIF. A experiência mostra que o formato deve ser escolhido em função do processo de destino, e não apenas da preferência técnica de um parceiro.
Um standard permite frequentemente várias opções. Segmentos facultativos, códigos de país, unidades, regras de arredondamento, identificadores de parceiros, referenciais de artigos e níveis logísticos criam diferenças significativas. O guia de implementação esclarece o que é obrigatório, proibido, condicional ou específico de um parceiro.
Sem um guia de implementação, o mapping EDI torna-se frágil: uma mensagem sintaticamente válida pode ser rejeitada funcionalmente. Por isso, as regras dos parceiros, conjuntos de testes, confirmações e cenários de anomalia devem ser formalizados logo durante o onboarding.
A complexidade EDI é controlada através da governação: versões documentadas, mappings reutilizáveis, controlos automatizados, supervisão dos estados e capacidade de conversão entre EDI, XML, API e formatos de e-invoicing.
A primeira regra consiste em criar um registo dos fluxos. Para cada parceiro, as equipas devem documentar a mensagem, versão, protocolo, guia de implementação, identificadores, regras de controlo, ambientes de teste e contactos de suporte. Esta governação evita que uma alteração de versão EDIFACT, X12 ou UBL seja tratada como uma simples evolução técnica.
O mapping EDI deve ser versionado como um componente crítico dos sistemas de informação. Traduz a linguagem do parceiro para o modelo interno da empresa e, em seguida, para o ERP, WMS, TMS, OMS ou sistema financeiro. Um bom mapping explicita transformações, valores predefinidos, regras de rejeição, tolerâncias e enriquecimentos de dados.
A supervisão deve abranger mais do que o transporte do ficheiro. Um fluxo marcado como «recebido» pode falhar no parsing, no controlo sintático, na validação de negócio, na integração com o ERP ou na reconciliação com uma encomenda. As confirmações técnicas e funcionais, os estados do ciclo de vida da fatura e as respostas dos parceiros devem ser consolidados numa visão operacional.
Detetar rapidamente uma rejeição sintática, por exemplo uma estrutura EDIFACT incorreta.
Identificar uma anomalia de negócio, como um GLN desconhecido ou uma referência de artigo inexistente.
Dar prioridade aos erros em função do impacto: receção bloqueada, fatura não conforme ou transporte sem seguimento.
Informar as equipas envolvidas com o contexto certo: parceiro, documento, encomenda, fatura e expedição.
A trajetória mais segura consiste em adotar um modelo de integração capaz de converter formatos sem multiplicar interfaces ponto a ponto. Uma encomenda pode entrar em X12, ser traduzida para o modelo interno, alimentar o OMS, desencadear uma ordem no WMS, produzir um DESADV EANCOM e gerar uma fatura UBL ou Factur-X, consoante o país, o parceiro e o canal aplicável.
Esta lógica também prepara evoluções regulamentares. Em Portugal, os requisitos da faturação eletrónica não substituem todos os fluxos EDI históricos: acrescentam perfis, validações, canais e obrigações fiscais aos processos existentes. A conformidade de e-invoicing deve, por isso, estar ligada às cadeias order-to-cash, procure-to-pay e supply chain, em vez de ser tratada como um projeto fiscal isolado.
A Generix integra os formatos EDI numa arquitetura colaborativa: conversão, encaminhamento, supervisão e governação dos fluxos entre parceiros, ERP, WMS, TMS, OMS e, quando aplicável à Administração Pública, FE-AP ou outro canal indicado. O objetivo é assegurar interoperabilidade de ponta a ponta.
A abordagem consiste em centralizar as traduções multiformato no Generix Collaborative Network, em vez de multiplicar conectores específicos em cada aplicação. São suportados formatos como EANCOM, EDIFACT, XML, UBL, HL7, JSON, PDF, CSV, TXT, X12 e formatos legacy, com regras de encaminhamento adaptadas aos parceiros e países.
De acordo com os dados publicados pela Generix, o Generix Collaborative Network abrange mais de 300 interligações ativas em 50 países, disponibiliza 3 000 mappings predefinidos e suporta 25 protocolos de transporte. Estas capacidades ajudam a acelerar o onboarding, mas não substituem o enquadramento de negócio: primeiro devem ser analisados os fluxos, parceiros prioritários e requisitos regulamentares.
Numa supply chain colaborativa, uma mensagem não termina quando é traduzida. Uma encomenda deve alimentar o ERP ou o OMS, preparar as operações no WMS, desencadear instruções no TMS, produzir estados e alimentar a faturação. Para os 3PL, esta continuidade é crítica: onboarding de clientes, operações multicliente, faturação por operação e EDI devem estar alinhados com as operações de armazém. Estes desafios são desenvolvidos no nosso artigo WMS para 3PL, operações multicliente, faturação por operação e onboarding EDI.
Na faturação eletrónica, a integração deve distinguir três componentes do mercado português: o regime fiscal geral do Decreto-Lei n.º 28/2019, a comunicação dos elementos das faturas à AT através do e-Fatura, web service ou ficheiro baseado no SAF-T (PT), e o regime B2G CIUS-PT/FE-AP. A articulação destes componentes com os fluxos EDI existentes evita ruturas entre conformidade fiscal, reporting à AT e processos operacionais.
O diferenciador não consiste em «suportar» uma lista de formatos, mas em torná-los interoperáveis numa rede B2B supervisionada. EDIFACT, X12, EANCOM, UBL, CII e Factur-X devem poder coexistir com API, ficheiros planos, portais e aplicações de negócio, mantendo uma rastreabilidade utilizável pelas equipas de IT, supply chain e finanças.
Para avaliar fluxos EDIFACT, X12, EANCOM, UBL, CII e Factur-X, pode ser analisado o Software EDI Generix. Nos projetos de faturação eletrónica em Portugal, a solução deve ser configurada de acordo com o perfil, o canal, as regras de validação e as obrigações fiscais efetivamente aplicáveis a cada fluxo.
Em resumo
Os principais formatos EDI são EDIFACT, ANSI X12, GS1/EANCOM, UBL, UN/CEFACT CII e Factur-X. EDIFACT e X12 abrangem sobretudo as trocas históricas da supply chain; UBL, CII e Factur-X estão fortemente associados à faturação eletrónica. A escolha depende do país, setor, documento trocado e parceiro.
EDIFACT é um standard das Nações Unidas amplamente utilizado na Europa e nas trocas internacionais, enquanto ANSI X12 é dominante na América do Norte. Ambos abrangem processos comparáveis, mas utilizam governação, sintaxe e códigos de mensagens diferentes: ORDERS ou INVOIC em EDIFACT e 850 ou 810 em X12.
EANCOM não é um standard totalmente separado do EDIFACT: é um subconjunto GS1 do UN/EDIFACT. É muito utilizado na distribuição e nos bens de grande consumo, com regras mais prescritivas para identificadores, artigos, localizações e fluxos logísticos. Em Portugal, o standard é difundido pela GS1 Portugal — CODIPOR.
UBL é uma linguagem XML para documentos empresariais utilizada nas trocas eletrónicas modernas, nomeadamente na faturação eletrónica. Difere da sintaxe EDI histórica baseada em segmentos, mas desempenha uma função comparável: estruturar um documento de negócio para processamento automático. Na contratação pública portuguesa, o CIUS-PT utiliza uma representação sintática em UBL 2.1.
Não. O Factur-X é um formato híbrido facultativo, que pode ser utilizado contratualmente se for aceite pelo destinatário e cumprir as regras fiscais portuguesas. Não é o perfil português oficial da faturação eletrónica B2G: a documentação operacional da FE-AP utiliza atualmente CIUS-PT em UBL 2.1.
Nos fluxos EDI históricos, INVOIC em EDIFACT ou EANCOM continua a ser comum. Para conformidade com a EN 16931, a Generix recomenda considerar UBL 2.1 e UN/CEFACT CII, respeitando os perfis e regras de validação aplicáveis. Na contratação pública portuguesa, a referência operacional é o CIUS-PT em UBL 2.1; Factur-X pode ser usado noutros contextos mediante acordo, mas não substitui automaticamente esse perfil.
DESADV significa despatch advice, ou aviso de expedição. A mensagem anuncia as mercadorias expedidas, quantidades, volumes, paletes e referências logísticas para preparar a receção no armazém e reconciliar encomenda, entrega e fatura.
Um standard admite variantes de versão, perfil, códigos e regras dos parceiros. O mapping EDI alinha a mensagem standard com os dados efetivamente esperados pelo ERP, WMS, TMS, OMS ou sistema financeiro, aplicando simultaneamente os controlos e transformações necessários.
Uma GED para a supply chain liga documentos, dados, estados e provas. Saiba como integrá-la com EDI, e-Fatura, FE-AP e arquivo eletrónico.
A fiabilidade do click & collect depende da sincronização entre stock, OMS, loja, preparação e comunicação com o cliente. Saiba como estruturar o processo e medir o seu desempenho.
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.
