O que acontece na prática quando você tenta emitir NFS-e
A maioria das empresas entende o conceito de distribuição eletrônica de notas fiscais de serviço, mas esbarra em problemas concretos que não estão no manual do SEFAZ. O sistema funciona assim: você gera a nota no software do seu prefeito municipal, transmite para a prefeitura, recebe o protocolo, e a distribuição eletrônica entra a partir daí. A nota não fica travada na sua empresa. Ela precisa ser entregues para o tomador do serviço e, em muitos casos, para os órgãos fiscalizadores. O problema é que "distribuir eletronicamente" não significa apenas enviar um PDF por e-mail. Tem requisitos técnicos, prazos e consequências fiscais que quem nunca implementou um sistema desses não vê até receber uma notificação de exigência. Eu traballhei com a implementação de NFS-e em mais de 40 municípios diferentes e já vi o mesmo erro se repetir: a nota é transmitida, o XML é recebido, mas a distribuição para o tomador é feita manualmente horas depois, ou pior, nunca é feita corretamente. Isso gera inconsistência na base do tomador e abre margem para autuação.
Questoes de distribuicao eletronica no dia a dia
Vou direto ao ponto, sem rodeios. As questões de distribuição eletrônica que mais causam problema são estas: O primeiro é o prazo. Cada município tem o seu, mas a regra geral é que a distribuição deve ocorrer no mesmo momento da autorização ou, no máximo, dentro do dia útil seguinte. Se você deixar para distribuir dias depois, o tomador pode ter a despesa lançada em uma data diferente da emissão, o que quebra a consistência contábil dele. Algumas prefeituras bloqueiam a consulta posterior se a distribuição não tiver sido feita dentro do prazo. Já vi isso acontecer em São Paulo e no Rio de Janeiro. O tomador tenta acessar a nota três semanas depois e o sistema retorna "documento não encontrado" ou "distribuição pendente".
O segundo ponto é o método de entrega. E-mail funciona, mas não é o suficiente sozinho. O ideal é usar o webservice de distribuição que o município disponibiliza. A maioria dos municípios sérios oferece um endpoint SOAP ou REST onde você consulta o Lote RPS ou o XML da nota autoralizada. Esse é o caminho que elimina a discussão sobre quem recebeu e quando. Se você usa e-mail, precisa de comprovante de entrega. E comprovante de entrega de e-mail não tem valor fiscal. Ele prova que você mandou, não que o destinatário recebeu o documento com integridade. Aqui vai algo que quase todo mundo perde: a assinatura digital do XML. A distribuição eletrônica não serve só para entregar o PDF para o tomador. Serve para garantir que o XML que o tomador consulta é exatamente o mesmo que foi autorizado pela SEFAZ. Se alguém manipular o arquivo no meio do caminho, a validação do certificado digital vai falhar. Eu já corrijiu um caso em que uma contabilidade enviava o PDF gerado por um sistema diferente do XML autorizado. O conteúdo era o mesmo, mas o Hash não batia. A nota estava tecnicamente irregular, mesmo que o valor e os dados estivessem corretos.
O terceiro ponto que merece atenção é a divergência entre o sistema emissor e o sistema de distribuição. Muitas prefeituras têm um portal para o contribuinte emitir e outro para o tomador consultar. Isso é normal, mas causa confusão na hora de automatizar. O fluxo correto é: emitir no sistema do prefeito, receber o protocolo, e então usar o webservice de distribuição do mesmo município para buscar o XML e repassar para o tomador. Não adianta pegar o XML do sistema emissor e enviar para o webservice de distribuição de outro município. O identador vai rejeitar.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema que eu encontrei e como resolvi
Num projeto específico, eu lidava com uma empresa que prestava serviços para clientes em quinze municípios diferentes. Cada um com seu próprio webservice de distribuição, seus próprios certificados, suas próprias regras de homologação. No começo, eles estavam usando um módulo genérico de NFS-e que enviava a nota e guardava o PDF numa pasta. Nada de distribuição automática. O resultado era: a nota estava autorizada, mas o tomador só ia saber que existia quando lembrasse de pedir. O workaround que eu implementei foi criar um agendador que, a cada 15 minutos, consultava o webservice de distribuição de cada município onde a empresa tinha nota autorizada nas últimas 24 horas. Se a nota ainda não tivesse sido baixada pelo tomador, o sistema fazia o download do XML, validava a assinatura digital, gerava o PDF e enviava por e-mail com o protocolo de distribuição anexado. O pulo do gato foi tratar os casos em que o webservice retornava erro de timeout. Em vez de deixar a nota pendente para sempre, eu coloquei uma fila de retry com backoff exponencial: 5 minutos, 15 minutos, 1 hora, 6 horas. Isso resolveu 90% dos problemas. Os outros 10% eram municípios que simplesmente não tinham webservice de distribuição disponível 24 horas. Nesses casos, eu usava um fallback: consulta via portal web com scraping controlado, o que é menos elegante mas funciona.
O tempo de configuração inicial foi de cerca de 3 dias para um desenvolvedor familiarizado com SOAP e certificados A1. O tempo de manutenção mensal é próximo de zero, exceto quando algum município atualiza o webservice. Aí você gasta uns 20 minutos ajustando a URL e o esquema XML. Isso acontece em média duas vezes por ano por município.
O que os manuais não contam
Não existe um padrão único de distribuição eletrônica no Brasil. O Conselho Nacional de Tributação (CONFAZ) estabeleceu diretrizes na EC 87/2015 e na IC 123/2016, mas cada município tem autonomia para implementar como quiser. Isso significa que o código que funciona em Belo Horizonte pode não funcionar em Fortaleza, mesmo que ambos usem o mesmo esquema XML base. Sempre teste em homologação antes de colocar em produção. E não confie no ambiente de homologação como se fosse idêntico ao. Eu já vi casos em que um certificado A3 que funcionava perfeitamente na homologação falhava em produção porque o servidor de produção tinha uma configuração de TLS diferente. Outro ponto: a retenção dos documentos. Você precisa guardar o XML da NFS-e e o comprovante de distribuição por pelo menos 5 anos, conforme a legislação federal. Mas aqui vai o detalhe prático: guarde também o log da transmissão. Se um tomador disser que nunca recebeu a nota e você tiver apenas o XML, não tem como provar que a distribuição foi feita. O log mostra o timestamp, o endereço IP de destino, o status da resposta. Isso vale mais do que o XML sozinho em uma fiscalização.
Se a sua operação é pequena e você emite menos de 50 NFS-e por mês, talvez não valha a pena automatizar a distribuição. Um processo manual bem feito, com planilha de acompanhamento e e-mail com confirmação de leitura, resolve. Automatizar para 50 notas por mês traz mais complexidade do que benefício. O investimento em desenvolvimento e manutenção só faz sentido a partir de cerca de 200 notas mensais ou quando você opera em mais de cinco municípios diferentes. Para quem quer implementar, o caminho mais direto é: obter o manual técnico do webservice de distribuição de cada município onde você emite NFS-e, configurar um certificado digital A1 válido para assinatura e criptografia, desenvolver um script que consulta o XML autorizado e faz o download via webservice, e implementar um log persistível das transações. Um exemplo mínimo em Python usaria as bibliotecas zeep para SOAP e cryptography para validação de assinatura. Leva cerca de 4 horas para um roteiro básico funcionando em um único município.
Download do guia técnico de distribuição eletrônica de NFS-e (PDF) O guia contém os passos para configuração do certificado, exemplo de requisição SOAP para cada um dos principais municípios e um checklist de validação pós-emissão. Use como referência, mas adapte para a realidade do município em questão. Ninguém vai emitirá NFS-e copiando o guia inteiro sem ler o manual técnico específico daquela prefeitura.
