Pontos essenciais
Em 2026, quatro frentes de dados devem ser priorizadas no ERP: CNPJ do destinatário, local completo de entrega quando diferente, classificação e códigos fiscais da operação e parametrização dos tributos aplicáveis. Elas se somam aos campos já exigidos pelo documento fiscal utilizado, que devem permanecer íntegros durante qualquer migração.
No Brasil, a conformidade fiscal depende diretamente da qualidade dos dados utilizados pelo ERP. Por isso, projetos de NF-e e NFS-e devem ser tratados como projetos de governança de dados, e não apenas como iniciativas de integração ou emissão de documentos. A Nota Fiscal Eletrônica — NF-e, modelo 55 — foi instituída pelo Ajuste SINIEF 07/05, publicado e vigente desde 5 de outubro de 2005. Para serviços, a Nota Fiscal de Serviço eletrônica de padrão nacional — NFS-e — é regida pela Resolução CGNFS-e nº 3, de 30 de agosto de 2023, vigente desde 1º de setembro de 2023. Não existe, porém, um único documento B2B aplicável a todas as operações: é preciso selecionar NF-e, NFC-e, NFS-e ou outro DF-e conforme o fluxo, o tributo e a jurisdição. Em um caso específico de 2026, ME e EPP optantes pelo Simples Nacional que emitem notas de serviços devem observar a obrigatoriedade do Emissor Nacional de NFS-e a partir de 1º de setembro de 2026.
As quatro frentes práticas são: o CNPJ do destinatário, com suporte ao formato alfanumérico para novas inscrições; o Grupo G — Identificação do Local de Entrega — da NF-e quando o endereço for diferente do endereço do destinatário; a definição do modelo e dos códigos fiscais adequados à operação, sem reduzir a análise a uma classificação genérica entre mercadorias e serviços; e a parametrização do fato gerador, das bases, dos tributos e das responsabilidades aplicáveis. Para a NF-e, o Ajuste SINIEF 07/05 e o Manual de Orientação do Contribuinte — MOC 7.0 — definem o leiaute e as regras de validação. Para a NFS-e nacional, devem ser observadas a Resolução CGNFS-e nº 3/2023 e a documentação técnica publicada pelo Comitê Gestor da NFS-e.
Para as equipes de finanças, TI e integração, a questão não é apenas se a informação existe. É preciso saber onde ela está cadastrada, quem é responsável por sua manutenção, quais validações se aplicam e como ela será auditada em caso de rejeição. Este guia segue essa lógica: não como uma definição de nota fiscal eletrônica, mas como uma checklist de execução campo a campo.
A migração de interfaces ou leiautes não deve prejudicar os fundamentos: data de emissão, número e série, identificação do emitente e do destinatário, pedido de compra quando aplicável, descrição dos produtos ou serviços, quantidades, valores unitários, natureza e códigos da operação, bases de cálculo, alíquotas e valores dos tributos, formas de pagamento e informações adicionais exigidas. Esses dados fazem parte dos grupos estruturados dos leiautes NF-e/NFC-e definidos pelo MOC 7.0 e, no caso da NFS-e, dos leiautes DPS/NFS-e. No Brasil, os totais devem considerar os tributos efetivamente aplicáveis, como ICMS, IPI, ISSQN, PIS/Cofins e, conforme o cronograma da reforma tributária, IBS/CBS. Muitas dessas informações já existem, mas podem estar distribuídas entre ERP, solução de faturamento, cadastro de clientes, motor fiscal, EDI ou portal de vendas.
O principal risco é a perda de granularidade durante o mapping. Uma representação auxiliar da NF-e (DANFE) por uma pessoa pode ocultar aproximações; um XML estruturado submetido ao sistema autorizador expõe imediatamente inconsistências. A recomendação é manter uma matriz de correspondência entre os campos antigos, os campos estruturados atuais e as regras de validação esperadas antes da emissão.
Algumas informações não são sistemáticas, mas continuam críticas. Responsabilidade ou retenção tributária, substituição tributária, isenção, imunidade, não incidência, suspensão e diferimento dependem do tributo, do produto ou serviço, da operação e da jurisdição. Na NF-e, esses tratamentos são materializados por códigos fiscais, como CST ou CSOSN, e, quando exigido, pelo Código de Benefício Fiscal e por informações complementares definidas pela unidade federada. Em hipóteses específicas, o destinatário também pode emitir uma nota fiscal de entrada, mas isso não deve ser tratado como um mecanismo genérico de autofaturamento.
No ERP, essas situações não devem ser tratadas como texto livre. Elas precisam resultar de regras fiscais documentadas: regime tributário da entidade, natureza do fluxo, origem e destino, status do cliente, modelo de documento, CFOP, códigos de produto ou serviço, contrato, regras Incoterms® 2020 quando aplicáveis e parametrização dos itens ou serviços. Esse é um ponto central de governança em projetos de desmaterialização: a conformidade depende tanto do cadastro e do motor fiscal quanto do formato.
O mapping deve relacionar cada dado a um campo do ERP, um sistema de origem e um controle. Sem essa rastreabilidade, um documento pode ser tecnicamente válido, mas fiscalmente frágil, ou ser rejeitado pelo sistema autorizador por inconsistência de dados.
Uma boa tabela de mapping distingue dados de cabeçalho, participantes, entrega, linhas, tributação e pagamento. Essa estrutura evita concentrar tudo no modelo de impressão e permite que cada equipe assuma seu escopo: finanças, vendas, master data, fiscal, TI e integração EDI/API.
| Dado a controlar | Campo ERP de destino | Fonte de dados recomendada | Erro frequente a evitar |
|---|---|---|---|
| CNPJ do destinatário | Identificador cadastral do participante faturado | Cadastro de clientes / master data de parceiros | Usar o CNPJ de outro estabelecimento sem uma regra clara para matriz e filial |
| Local de entrega quando diferente | Endereço do local entregue ou do recebedor logístico | Pedido, entrega, cadastro de sites do cliente | Repetir automaticamente o endereço de faturamento em todos os fluxos multiestabelecimento |
| Modelo e códigos da operação | Tipo de documento, CFOP, natureza e códigos fiscais por linha | Itens, serviços, linhas do pedido e regras fiscais | Classificar todo o documento pela atividade do cliente, ignorando as linhas faturadas |
| Momento e tratamento tributário | Indicadores fiscais da entidade e da operação | Motor fiscal, entidade emissora e condições comerciais | Adicionar uma observação manual sem coerência com o fato gerador e o regime tributário |
| Responsabilidade, retenção ou substituição tributária | Grupos e códigos fiscais condicionais | Regras tributárias, origem e destino, status do cliente e natureza da operação | Omitir o tratamento nos fluxos abrangidos ou aplicá-lo de forma excessivamente ampla |
| Bases e valores dos tributos por alíquota e moeda | Totais fiscais estruturados | Motor de faturamento e módulo fiscal | Transmitir somente um total global, sem detalhamento fiscal utilizável |
A origem dos dados varia conforme o dado. O CNPJ pertence ao cadastro do parceiro; o local de entrega pode vir do pedido ou do documento de entrega; o modelo e os códigos da operação dependem das linhas; os grupos tributários vêm da parametrização fiscal; e determinadas condições de pagamento ou hipóteses de emissão pelo destinatário podem decorrer do contrato e da legislação aplicável. A abordagem recomendada é documentar essas responsabilidades antes de alterar as interfaces.
Para mercadorias, o Ajuste SINIEF 07/05 e o Manual de Orientação do Contribuinte — MOC 7.0, especialmente o Anexo I — Leiaute e Regras de Validação da NF-e e da NFC-e — definem os dados estruturados e as respectivas validações. Para serviços abrangidos pelo padrão nacional, a referência é a Resolução CGNFS-e nº 3/2023 e a documentação técnica da NFS-e. Esses leiautes incluem identificadores, número e série, data de emissão, natureza e códigos da operação, linhas, bases e valores fiscais, pagamento e endereços condicionais. Para um projeto ERP, essa documentação se torna a base do controle operacional.
Antes da transmissão, os controles devem combinar regras de presença, formato e negócio. Por exemplo: CNPJ do destinatário presente e coerente com o participante faturado; local de entrega preenchido quando diferente; modelo, CFOP e códigos fiscais compatíveis com as linhas; responsabilidade ou retenção acionada somente nos casos previstos; bases e valores detalhados por tributo e alíquota; moeda informada quando aplicável.
A recomendação é posicionar esses controles o mais perto possível da origem do dado e complementá-los na camada de integração e antes do envio ao autorizador. O objetivo não é deslocar os erros do ERP para a SEFAZ, o Ambiente Nacional ou o sistema municipal, mas criar uma cadeia contínua de qualidade, do pedido à emissão e ao compartilhamento com a administração tributária.
O CNPJ do destinatário é o dado cadastral central a preparar. O próprio número identifica a entidade e o estabelecimento: a raiz representa a organização, enquanto as posições 9 a 12 identificam a ordem do estabelecimento. Por isso, o ERP precisa controlar qual CNPJ completo deve ser usado em cada operação, entrega e documento fiscal.
No cadastro do ERP, recomenda-se armazenar separadamente o CNPJ completo de cada estabelecimento, a Inscrição Estadual, quando aplicável ao ICMS, a Inscrição Municipal utilizada no contexto do ISSQN e os identificadores internos do cliente. O CNPJ é a identificação cadastral nacional; a Inscrição Estadual e a Inscrição Municipal atendem a finalidades fiscais próprias e não são substitutos genéricos do CNPJ.
Essa separação evita decisões tardias durante o mapping. Também facilita a seleção do documento fiscal, do estabelecimento destinatário e do ambiente autorizador adequado. Para aprofundar o quadro geral de formatos e obrigações, consulte também o conteúdo Nota fiscal eletrônica: definição, formatos e obrigações em 2026.
A qualidade do cadastro de clientes deve ser tratada antes da homologação. Duplicidades aparecem com frequência quando vários estabelecimentos da mesma organização são criados como parceiros independentes sem uma hierarquia, ou quando os endereços cadastral, de cobrança e de entrega são confundidos. A recomendação é distinguir claramente: organização faturada, estabelecimento destinatário, endereço cadastral, local de entrega e canal ou sistema autorizador.
Os controles úteis incluem a detecção de CNPJ ausente, raiz de CNPJ compartilhada por várias contas sem hierarquia, estabelecimento incompatível com o endereço, Inscrição Estadual ou Municipal ausente nos casos pertinentes e status do cliente desalinhado das regras fiscais. A preparação para o CNPJ alfanumérico também deve fazer parte dos testes de interface e validação. Essa etapa envolve finanças, vendas, área fiscal e TI.
O documento fiscal eletrônico depende de uma lógica de roteamento. É necessário saber qual modelo emitir, para qual CNPJ ou CPF, por qual estabelecimento e para qual ambiente transmitir. No Brasil, não existe um diretório baseado na escolha de uma plataforma privada pelo cliente. A NF-e é transmitida à administração tributária autorizadora da unidade federada ou a uma SEFAZ virtual; a NFS-e pode envolver o Emissor Público Nacional, um emissor local e o Ambiente de Dados Nacional, conforme o contexto aplicável.
Na prática, as regras devem ser testadas com clientes estratégicos, grupos com múltiplos estabelecimentos, destinatários públicos ou privados e casos em que diferentes pessoas jurídicas compartilham centros de distribuição ou locais logísticos. A camada de integração deve relacionar corretamente ERP, ambientes autorizadores e fluxos B2B existentes.
Os riscos do ERP aparecem em dados que parecem secundários: estabelecimento entregue, tipologia das linhas, enquadramento tributário e parametrização da entidade emissora. São dados operacionais compartilhados entre vendas, logística e finanças, mas que condicionam a conformidade do documento fiscal.
No varejo, na distribuição especializada, na indústria ou na logística contratual, o endereço cadastral pode ser o da matriz ou de uma central de compras, enquanto a entrega ocorre em uma loja, centro de distribuição, plataforma regional ou unidade do cliente. Na NF-e, o Grupo G — Identificação do Local de Entrega — deve ser preenchido quando o local for diferente do endereço do destinatário. Se o ERP não preservar essa distinção, o XML pode ficar incompleto ou incoerente.
Os projetos devem auditar as regras de obtenção do endereço a partir do pedido, do documento de entrega e do cadastro de locais. Quando vários sistemas participam do fluxo — por exemplo, OMS, WMS, TMS, ERP e EDI —, o local de entrega deve permanecer rastreável até o documento fiscal. É justamente nesse ponto que uma supply chain integrada gera valor: o compartilhamento dos dados evita correções manuais tardias.
A classificação da operação não deve ser inferida de forma aproximada. Um faturamento pode envolver somente mercadorias, somente serviços ou componentes combinados, mas o Brasil não utiliza um campo geral obrigatório que simplesmente classifique o documento nessas três categorias. O tratamento correto depende do modelo fiscal, da Natureza da Operação, do CFOP, dos códigos de produto ou serviço e dos grupos tributários de cada linha. O melhor gatilho costuma ser a linha do pedido e o cadastro do item ou serviço, e não apenas o cliente ou a entidade emissora.
É necessário definir regras estáveis para famílias de itens, tipos de serviço, despesas acessórias, frete refaturado, instalação, manutenção, devoluções, documentos complementares e ajustes. Em um fluxo combinado, o ERP deve selecionar os documentos e códigos coerentes e preservar o detalhamento das linhas que justifica o tratamento adotado.
Não existe no Brasil uma opção geral equivalente à tributação da prestação pelo regime de débitos que deva aparecer como uma observação padronizada. O ERP deve determinar separadamente o fato gerador, o momento da incidência, as bases e as responsabilidades para ICMS, ISSQN, IPI, contribuições federais e, conforme o cronograma da reforma tributária, IBS e CBS. A regra deve estar no motor fiscal da entidade ou da atividade correspondente e ser propagada ao documento sem redigitação. A área fiscal precisa validar essa parametrização antes da homologação.
O risco clássico é incluir uma frase no modelo de representação auxiliar ou em um campo livre sem verificar sua compatibilidade com a realidade fiscal. Com documentos eletrônicos estruturados, essa abordagem é frágil: o texto, os códigos, os grupos XML e o contexto tributário precisam estar alinhados.
A homologação deve comprovar que os dados estão corretos nos cenários reais. Testar apenas o esquema XML oficial ou padrões comerciais como UBL e CII não basta: é necessário simular situações simples, combinadas, condicionais, corretivas e rejeições do autorizador. UBL e CII podem ser usados em intercâmbios comerciais, mas não substituem os leiautes fiscais oficiais da NF-e ou da NFS-e.
Um plano de homologação robusto deve cobrir, no mínimo, os seguintes cenários:
Cada cenário deve ser verificado na representação visual, no arquivo estruturado, nos dados transmitidos ao ambiente autorizador e no retorno de status. Recomenda-se envolver finanças, vendas, TI, fiscal e responsáveis por cadastros nessa homologação.
No modelo brasileiro, a autorização fiscal não depende de uma categoria única de plataformas privadas. A NF-e é transmitida à administração tributária autorizadora da unidade federada ou a uma SEFAZ virtual. No padrão nacional da NFS-e, o fluxo pode envolver o Emissor Público Nacional, emissores locais e o Ambiente de Dados Nacional. Esses ambientes executam validações formais e retornam autorizações, rejeições e eventos, mas não substituem a responsabilidade do contribuinte pela correção das informações fiscais.
A homologação deve, portanto, integrar controles antes do envio, validações do autorizador, estados do ciclo de vida, rejeições, correções e reemissões. O ambiente autorizador não substitui a qualidade do ERP: ele protege a transmissão e reforça os controles dentro de uma cadeia coerente.
Uma rejeição não deve ser corrigida apenas documento por documento. Ela precisa iniciar uma análise de causa: campo ausente, origem dos dados incorreta, regra de mapping incompleta, cadastro de cliente desatualizado, parametrização fiscal insuficiente ou roteamento errado. A correção deve ser registrada e, quando necessário, aplicada também ao cadastro ou à regra de origem.
Para controlar o go-live, recomenda-se um painel simples: número de documentos testados, taxa de rejeição, causas de rejeição, tempo de correção, campos com mais erros e responsáveis pelos dados. Essa governança permite utilizar a conformidade como mecanismo contínuo de melhoria do processo order-to-cash.
Conectar ERP, ambiente autorizador e rede B2B reduz rejeições ao tratar os dados como um ativo compartilhado. A conformidade não pode permanecer isolada na área financeira: ela também depende de pedidos, entregas, cadastros de clientes, regras fiscais e intercâmbios entre sistemas.
Os dados obrigatórios dos documentos fiscais revelam uma realidade simples: a nota fiscal é o último elo de um processo mais amplo. O CNPJ vem do cadastro do cliente, o local de entrega vem da execução logística, os códigos da operação vêm das linhas de venda, os grupos tributários vêm do motor fiscal e o roteamento depende do modelo fiscal, do estabelecimento e da jurisdição aplicável.
Uma organização em silos pode gerar correções tardias, caras e repetitivas. Em contrapartida, uma cadeia integrada compartilha os mesmos dados entre ERP, EDI/API, clientes, fornecedores e ambientes autorizadores. A conformidade deve ser protegida pela qualidade dos dados de ponta a ponta, e não apenas por uma validação final.
A integração entre ERP, motor fiscal, autorizadores e parceiros deve apoiar a emissão, o recebimento, o intercâmbio de documentos fiscais e as trocas B2B, respeitando o documento aplicável e a arquitetura do autorizador. A experiência com fluxos B2B e EDI é útil para o mapping, o onboarding de parceiros e a continuidade das trocas. Antes do projeto, é necessário delimitar o papel do ERP, do motor fiscal, da integração, da SEFAZ, dos ambientes nacionais e dos sistemas municipais.
Em um projeto ERP, o ponto central é a articulação entre dados fiscais, fluxos estruturados, controles, status e intercâmbios com parceiros. A nota fiscal eletrônica não deve ser tratada como um simples conector: ela precisa fazer parte dos processos order-to-cash, procure-to-pay e de reporte fiscal.
A conformidade mínima consiste em produzir um arquivo aceito. Uma abordagem mais robusta procura reduzir divergências, acelerar correções, aumentar a confiabilidade dos cadastros e tornar os status utilizáveis pelas equipes de finanças e atendimento ao cliente. Essa lógica é especialmente importante para organizações com várias pessoas jurídicas, estabelecimentos, unidades operacionais ou conexões intensivas com clientes e parceiros.
Em 2026, audite os campos do ERP, as regras fiscais, os cadastros de clientes e os fluxos B2B. Para assegurar emissão, recebimento, compartilhamento fiscal e controles campo a campo, estruture uma arquitetura que conecte ERP, motor fiscal, integração EDI/API e os ambientes autorizadores aplicáveis.
Em resumo
As quatro frentes prioritárias são o CNPJ do destinatário, o local de entrega quando diferente, o modelo e os códigos fiscais da operação e a parametrização dos tributos aplicáveis. A lista exata depende do documento utilizado — NF-e, NFC-e, NFS-e ou outro DF-e —, da operação, do tributo e da jurisdição.
O documento deve utilizar o CNPJ ou CPF do destinatário conforme o leiaute e a operação aplicáveis. No CNPJ, a raiz identifica a organização e as posições 9 a 12 identificam o estabelecimento. Por isso, o ERP deve manter o CNPJ completo de cada matriz ou filial e selecionar o estabelecimento correto.
Não. Na NF-e, o Grupo G — Identificação do Local de Entrega — deve ser preenchido quando o local for diferente do endereço do destinatário. Operações com vários estabelecimentos, centros de distribuição, lojas e plataformas logísticas precisam ser testadas especificamente.
O Brasil não utiliza um campo geral que simplesmente classifique o documento como mercadorias, serviços ou operação mista. O ERP deve selecionar o documento fiscal adequado e aplicar Natureza da Operação, CFOP, códigos de produto ou serviço e grupos tributários com base nos itens, serviços e linhas do pedido, evitando uma escolha manual genérica.
O fato gerador, a incidência, as bases e as responsabilidades devem ser parametrizados separadamente para cada tributo aplicável, como ICMS, ISSQN, IPI, contribuições federais e, conforme o cronograma da reforma tributária, IBS e CBS. A regra deve vir do motor fiscal e ser validada antes da emissão.
Essas situações devem ser acionadas somente quando a operação e a legislação aplicável as exigirem. A substituição tributária, as retenções e outras responsabilidades precisam resultar de regras fiscais condicionais, códigos e grupos estruturados, e não de uma observação manual adicionada ao documento.
Os campos prioritários são cadastro de clientes, CNPJ e inscrições fiscais, endereços cadastrais e de entrega, modelo do documento, CFOP e demais códigos da operação, regras tributárias, benefícios e retenções condicionais, formatos de saída e mapping para o ambiente autorizador. Cada campo deve ter uma origem dos dados e um responsável pelo dado.
A homologação deve cobrir NF-e padrão, entrega em endereço diferente, NFS-e de serviços, fluxo combinado, responsabilidade ou benefício fiscal, documento complementar ou substituto e rejeição intencional. Cada teste deve verificar o dado de origem, o arquivo estruturado, a transmissão e o retorno de status.
Entenda como controlar a disponibilidade, o giro e a acuracidade do estoque com FIFO, FEFO, inventários, KPIs e uma visão unificada dos canais.
A eficiência do click & collect depende de estoque confiável, separação priorizada, notificações sincronizadas e uma área de retirada preparada para os picos.
Trabalhe com nossa equipe para criar sua pilha ideal de software de cadeia de suprimentos e adaptá-la às suas necessidades comerciais exclusivas.
