Como funciona a distribuição eletrônica na prática
A maioria das pessoas acha que emitir um documento fiscal eletrônico é só apertar um botão e pronto. A realidade é bem mais chata. O sistema monta o XML, assina com o certificado digital, envia para a SEFAZ, espera a autorização e só então o documento existe de verdade. Depois disso vem a parte que quase ninguém explica direito: como fazer esse documento chegar até quem precisa dele. Eu já vi gente perder horas porque o XML foi autorizado mas nunca saiu da pasta do emissor. Parece bobo, mas é o erro mais comum em operações pequenas que ainda não automatizaram a distribuição.
O que é distribuição eletrônica por camadas
Distribuição eletrônica por camadas é o modelo em que os documentos fiscais trafegam por camadas distintas do sistema: a camada de emissão (seu ERP ou emissor), a camada de transmissão (SEFAZ do seu estado), e a camada de recebimento (destinatário ou consumidor final). Cada camada tem responsabilidades diferentes e regras diferentes. Não é um conceito técnico oficial, é como os profissionais da área acabaram chamando porque descreve exatamente o que acontece quando você emite uma NF-e ou NFC-e.
Distribuição eletrônica por camadas: o que você precisa saber para não errar
A camada de emissão é a sua. Você gera o XML, aplica a assinatura digital com o certificado A1 ou A3, e o sistema prepara a autorização. Aqui mora a primeira armadilha: muitos emitentes usam o mesmo certificado para assinar todo dia sem verificar o estado da cadeia de certificação. Se o certificado raiz ou intermediário vencer, sua autorização cai sem aviso. Eu descobri isso na pior forma numa sexta à tarde quando cerca de 40 notas foram rejeitadas pela SEFAZ com o motivo 216 — certificado revogado — porque o fornecedor do meu PKI havia renovado a cadeia e eu não tinha atualizado o arquivo .p7b no sistema. A camada de transmissão é a SEFAZ. Ela valida a assinatura, confere se o documento está dentro das regras estaduais, aplica a tributação e devolve o protocolou com a autorização ou a rejeição. O tempo médio de resposta varia entre 2 e 8 segundos em condições normais. Quando a SEFAZ está em contingência, isso sobe para minutos ou não responde de todo. Tem estado que entra em contingência semanalmente. É melhor ter um plano B funcionando antes que precise dele.
A camada de recebimento é onde a maioria dos problemas aparece. O destinatário precisa receber o XML completo, ou pelo menos o acesso à chave de distribuição. Na NF-e tradicional, isso significa enviar o XML assinado por e-mail. Na NFC-e, o padrão é o QR Code na nota. Ambos funcionam, mas cada um tem suas limitações.
Como configurar a distribuição passo a passo
Primeiro, certifique-se de que o certificado digital está válido e que a cadeia completa está instalada no servidor de emissão. Verifique isso rodando o comando de teste de cadeia antes de qualquer lote de emissão. Muitos sistemas não avisam quando a cadeia está incompleta — eles só falham na hora H. Segundo, configure o disparo automático de distribuição no seu ERP. Isso significa que, assim que a SEFAZ retornar a autorização, o sistema deve pegar o XML e enviar para o e-mail cadastrado do cliente. Não confie em envio manual. Eu com empresas que faziam isso e perdiam documentos porque o responsável saía de férias e o e-mail ficava travado na fila.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Terceiro, o formato do XML precisa estar correto. A versão do schema tem que bater com a versão que a SEFAZ exige. Eu já vi erro de rejeição 999 porque o XML foi gerado com a versão 4.00 mas enviado para uma SEFAZ que ainda estava em transição e só aceitava 3.10 naquela semana. Verifique a versão antes de cada lote. Quarto, mantenha um log de distribuição. Cada XML enviado, cada e-mail disparado, cada QR Code gerado. Quando o cliente diz que não recebeu, você precisa saber o quê, quando e para onde foi enviado. Sem log, você fica no embargo.
Problemas comuns e soluções
O erro 217 da SEFAZ é o mais frequente em contingência. Ocorre quando o sistema tenta autorizar durante a contingência online mas o certificado não está configurado corretamente para esse modo. A solução é simples: verifique se o certificado possui a flag de contingência habilitada e se o arquivo de certificado de backup está carregado no sistema. A rejeição 958 acontece quando o XML é enviado mas o ambiente de homologação recebe requisição do ambiente de produção. Parece óbvio, mas acontece em integrações mal configuradas. Verifique se o URL de transmissão está apontando para o ambiente correto em cada ambiente.
Um problema que poucas pessoas mencionam: o XML pode estar correto, autorizado, mas o destinatário não consegue validar a assinatura porque a cadeia de certificação dele não reconhece a AC que assinou. Isso acontece frequentemente com certificados de ACs menores ou novas. A solução é garantir que o certificado raiz e intermediários estejam distribuídos junto com o XML, ou usar apenas ACs reconhecidas pelo Banco Central em toda a cadeia.
Limitações que ninguém conta
A distribuição por camadas não funciona bem quando você emite mais de 500 notas por dia em múltiplos estados. Cada SEFAZ tem seu tempo de resposta, seu schema, suas regras de contingência. O sistema precisa lidar com isso de forma independente por estado. Muitos ERPs mais baratos tratam todas as SEFAZs como iguais e aí você perde notas em estados com infraestrutura mais lenta. O formato NFC-e com QR Code também tem limitação prática: o consumidor final nem sempre sabe acessar a consulta por QR Code. Eu vi várias situações em que o cliente reclamou que não recebeu a nota porque achava que era só o DANFE impresso. O XML veio, mas o entendimento era outro. Para B2B, o e-mail com XML completo é mais seguro. Para B2C, o QR Code resolve, desde que o consumidor seja letrado digitalmente.
A camada de recebimento também depende de dados cadastrais corretos. Se o e-mail do cliente está errado no cadastro, a distribuição falha e você não recebe alerta. Configure validação de e-mail no momento do cadastro do cliente. Isso reduz em cerca de 30% os casos de documento não entregue. Se você emite volumes altos, considere usar a via API em vez de e-mail. A maioria dos gateways de NF-e oferece webhook de distribuição, onde o XML é enviado diretamente para um endpoint seu assim que a autorização é concluída. Isso elimina a dependência de servidores de e-mail e reduz o tempo de recebimento para menos de 5 segundos após a autorização.
