O fluxo de mensageria fiscal e o gargalo da duplicidade na entrada
Quem projeta módulos fiscais em software houses e precisa manter a recepção de documentos em dia conhece a rotina: o ERP faz a sincronização de entrada, mas o mesmo documento fiscal aparece duplicado na fila de processamento, gerando inconsistências no estoque, lançamento repetido no contas a pagar e escrituração distorcida no fechamento fiscal. Quando uma empresa recebe centenas de operações diárias, o volume de eventos e XMLs transitando por diferentes pontas transforma o processo de entrada em um ponto crítico de falha se o sistema não possuir uma estratégia refinada de deduplicação de documento fiscal.
A duplicação raramente tem como origem uma nota autorizada duas vezes de forma idêntica pela administração tributária. De acordo com o Manual de Orientação do Contribuinte, o MOC 7.0 da NF-e, a própria SEFAZ aplica travas imediatas no momento da emissão por meio da Regra de Validação 2B08-20, que devolve o cStat 204 para rejeitar qualquer documento cuja chave de acesso já conste na base fazendária. O problema de recepção repetida, portanto, ocorre nas etapas subsequentes, provocadas por consultas concorrentes no Web Service de distribuição, múltiplos canais de captura paralelos (como caixa postal de e-mail e mensageria direta) e atualizações sucessivas do mesmo documento que trazem novos eventos atrelados.
Por que a chave de acesso de 44 dígitos não basta para deduplicar
A abordagem primária adotada pela maioria dos desenvolvedores consiste em definir a chave de acesso de 44 dígitos numéricos como índice único no banco de dados. Essa chave, estruturada conforme o MOC 7.0 com UF, ano e mês, CNPJ emitente, modelo, série, número, tipo de emissão, código numérico e dígito verificador, parece suficiente à primeira vista, mas essa unicidade falha quando o sistema precisa lidar com o ciclo de vida completo do documento fiscal.
A primeira fragilidade surge na distinção entre o resumo do documento e o documento completo. Segundo a Nota Técnica 2014.002, que padroniza o Web Service NFeDistribuicaoDFe, a SEFAZ disponibiliza inicialmente ao destinatário um evento de resumo (resNFe) contendo apenas informações básicas, como valor total, data de emissão e digest value. Se o sistema receptor registrar a chave de 44 dígitos como chave primária estrita e rejeitar qualquer payload subsequente sob a mesma chave, ele bloqueia a posterior chegada do XML completo da NF-e (procNFe), que só é liberado pela SEFAZ após a manifestação do destinatário. O sistema acaba armazenando apenas o resumo financeiro, ficando sem o arquivo XML completo com o detalhamento dos itens e a tributação por produto.
A segunda fragilidade envolve a concorrência entre emissões normais e em contingência. Conforme previsto no MOC 7.0, a Regra de Validação 2B08-10 gera o cStat 539 para rejeição por duplicidade com diferença na chave de acesso quando há coincidência de CNPJ emitente, modelo, série e número, mas alteração no código numérico (cNF) ou no tipo de emissão. Se o fornecedor tentou emitir em contingência e depois transmitiu a nota normal, ou vice-versa, o ERP receptor pode receber dois arquivos com chaves de 44 dígitos distintas para a mesmíssima operação mercantil, gerando duplicidade física nos cadastros internos mesmo com chaves tributárias diferentes.
A sincronização via NSU e as armadilhas no Web Service de distribuição
A consulta de documentos fiscais por destinatários opera de forma sequencial baseada no Número Sequencial Único (NSU). Conforme estipula a Nota Técnica 2014.002, cada consulta ao método de distribuição pode retornar lotes de até 50 documentos por requisição. O que muitos desenvolvedores não preveem é que o mesmo documento fiscal pode gerar múltiplos registros com NSUs distintos ao longo do tempo. Toda vez que uma carta de correção eletrônica é registrada, um cancelamento é homologado ou o destinatário registra um evento de manifestação, a SEFAZ cria um novo NSU com aquele evento específico apontando para a mesma chave de acesso.
Quando o software de mensageria não separa a camada de controle de NSU da camada de persistência mercantil, cada novo NSU recebido é interpretado como um novo documento a ser gravado, multiplicando a nota fiscal nas tabelas operacionais. Existe também a regra de negócio sobre a frequência de requisição: conforme determina a Nota Técnica 2014.002, quando a consulta retorna o cStat 137 indicando que não há novos documentos localizados, o sistema integrado deve aguardar obrigatoriamente o intervalo de 60 minutos antes de disparar nova requisição com o mesmo NSU, sob pena de bloqueio temporário do CNPJ pela SEFAZ por consumo indevido através do cStat 656.
Aliado a isso, há o limite de custódia da própria SEFAZ. De acordo com a Nota Técnica 2014.002, os documentos fiscais eletrônicos e seus resumos ficam disponíveis no Ambiente Nacional apenas pelo prazo de 90 dias a contar de sua recepção pela autoridade tributária. Caso a software house ou a empresa destinatária enfrente instabilidades e permaneça mais de 60 dias sem realizar requisições ao Web Service, a geração de novos NSUs para aquele contribuinte entra em suspensão, voltando a responder apenas após o envio de uma nova solicitação.
A estrutura técnica de uma chave composta para deduplicação
Para evitar lançamentos repetidos sem impedir a chegada de atualizações legítimas, a software house precisa adotar uma estrutura de persistência baseada em chave composta, desmembrando a chegada física do arquivo da gravação contábil do documento. Sistemas voltados à gestão e mensageria de DF-e, a exemplo do e-Malote, utilizam critérios estruturados de recepção para garantir que o fluxo de entrada conviva harmoniosamente com o repositório fiscal do ERP.
Uma arquitetura consistente de deduplicação deve considerar três eixos fundamentais:
- Identificação mercantil de negócio: A unicidade do negócio físico deve ser avaliada pela combinação dos campos CNPJ do emitente + Modelo + Série + Número do documento. Essa combinação impede que o mesmo fornecedor fature a mesma mercadoria duas vezes sob chaves de acesso com códigos numéricos divergentes (como no cenário do cStat 539), protegendo os saldos de estoque e a conciliação financeira do destinatário.
- Identificação do ciclo de vida e formato: O sistema deve distinguir o estágio do arquivo recebido através da composição Chave de Acesso (44 dígitos) + Tipo de Objeto (resumo resNFe, XML completo procNFe ou evento procEventoNFe) + Protocolo de Autorização. Essa granularidade garante que a chegada prévia de um resumo não aborte o recebimento do XML integral, permitindo o enriquecimento progressivo dos dados sem sobrescrever indevidamente status anteriores.
- Versionamento de eventos: Para eventos associados, como cartas de correção e cancelamentos, a chave lógica necessita anexar o Tipo de Evento (tpEvento) e o Número Sequencial do Evento (nSeqEvento) vinculados à chave de acesso principal. O processador atualiza a situação do documento originário (alterando o status para cancelado, por exemplo) em vez de empilhar uma nova nota de entrada.
Além da estruturação no banco de dados, o processo deve gerenciar o canal concorrente. Muitas empresas recebem o XML por e-mail enviado diretamente pelo fornecedor e, minutos depois, puxam o mesmo arquivo via Web Service de distribuição da SEFAZ. A rotina de ingestão precisa checar a existência do digest value contido na assinatura digital do XML: se o hash do arquivo for idêntico e o protocolo de autorização conferir com o registro já integrado, o segundo arquivo deve ser marcado como réplica de mensageria e arquivado na custódia de segurança sem disparar os gatilhos de validação do ERP.
Para garantir que esse ciclo não seja descontinuado por prazos operacionais, o destinatário também deve observar as regras de validação legal. Conforme o Ajuste SINIEF nº 07/2005, atualizado pelo Ajuste SINIEF nº 43/2023, o destinatário tem o prazo limite de 180 dias contados a partir da data de autorização da NF-e para efetuar a manifestação conclusiva, como a Confirmação da Operação, a Operação não Realizada ou o Desconhecimento da Operação. Implementar o ciclo completo de deduplicação protege a empresa contra erros operacionais e cumpre integralmente os requisitos normativos do SPED.
Perguntas frequentes sobre deduplicação de documentos fiscais
Por que a SEFAZ autoriza notas com chaves diferentes para a mesma venda?
A SEFAZ não autoriza duas notas idênticas, mas quando o emissor inicia a geração em contingência e depois emite em modo normal devido a falhas de conexão, os documentos ganham códigos numéricos (cNF) ou tipos de emissão distintos, gerando chaves de 44 dígitos diferentes para a mesma nota que podem passar nas travas básicas do ERP se o sistema não validar os campos CNPJ, série e número.
O que causa o bloqueio por consumo indevido (cStat 656) no Web Service de distribuição?
O bloqueio ocorre quando o sistema continua consultando o Web Service repetidamente após receber o retorno cStat 137, sem respeitar o intervalo obrigatório de 60 minutos determinado pela Nota Técnica 2014.002.
Qual a diferença entre deduplicar pelo hash do XML e pela chave de acesso?
A chave de acesso identifica o documento tributário formalmente, enquanto o hash (digest value) valida a integridade exata daquele arquivo específico assinado. Deduplicar pelo hash impede que cópias idênticas vindas de canais diferentes (como e-mail e distribuição SEFAZ) sejam processadas duas vezes, mas não substitui a validação dos campos fiscais.
Até quando um documento fiscal pode ser recuperado via Web Service pelo destinatário?
Segundo a Nota Técnica 2014.002, os documentos fiscais eletrônicos e resumos ficam disponíveis no Ambiente Nacional da SEFAZ para distribuição pelo prazo de 90 dias a partir da sua recepção.
Acompanhe a Reforma sem virar especialista. A IT Works envia por e-mail as principais notícias e insights tributários da semana. Para receber, assine a Newsletter da Reforma no formulário desta página.
Juristas, contadores e especialistas fiscais dedicados em tempo integral ao acompanhamento da legislação. É o mesmo time que mantém a base de mais de 15 milhões de produtos que sustenta as soluções da IT Works.
