NF-e e NFC-e
Rejeição 476: confira a UF dos emitentes antes de reorganizar o lote
A rejeição 476 indica que o código de UF de uma nota difere daquele informado na primeira nota do mesmo lote de autorização. O problema pode estar no agrupamento feito pelo emissor, especialmente quando uma integração atende estabelecimentos de estados diferentes. A correção deve preservar a identidade fiscal de cada…
A rejeição 476 indica que o código de UF de uma nota difere daquele informado na primeira nota do mesmo lote de autorização. O problema pode estar no agrupamento feito pelo emissor, especialmente quando uma integração atende estabelecimentos de estados diferentes. A correção deve preservar a identidade fiscal de cada documento e organizar a transmissão conforme o serviço utilizado.
Não altere a UF de uma empresa para fazer todas as notas parecerem do mesmo estado. Também não conclua que o endereço do cliente está errado: essa comparação considera a UF do emitente, e não a do destinatário.
O que a regra compara
No XML, cUF fica no grupo de identificação ide e representa o código da UF do emitente. A regra B02-20 compara essa informação com a da primeira NF-e do lote. O MOC 7.0 a classifica como obrigatória para modelos 55/65, mas acrescenta uma delimitação essencial: a validação faz sentido unicamente para a SEFAZ Virtual, que atende várias UFs e precisa evitar lotes misturados. MOC 7.0, Anexo I, página 75.
Essa observação impede interpretar “obrigatória” como prova de que todo autorizador estadual devolve 476 em qualquer cenário. A infraestrutura compartilhada também não transforma todos os estados atendidos em uma única UF fiscal.
A primeira nota serve como referência de comparação. Ela não fornece um valor que deva ser copiado para as demais. Se o sistema reuniu documentos de estabelecimentos legitimamente situados em estados diferentes, o erro está na composição daquele envio, mesmo que cada cadastro esteja correto individualmente.
Primeiro confirme qual lote foi transmitido
A fila exibida no ERP não é necessariamente o lote recebido pelo autorizador. Uma tela pode mostrar dezenas de documentos que serão enviados separadamente. O inverso também acontece: documentos selecionados em telas diferentes podem ser reunidos pelo componente de transmissão.
Peça ao suporte o envelope enviNFe efetivamente enviado, a ordem dos documentos, o modelo de cada nota e seus valores de cUF. Registre o endereço do serviço, o ambiente de produção ou homologação e a versão do emissor. Esses dados permitem verificar se houve mistura na origem, na mensageria ou numa tentativa posterior.
Em um exemplo hipotético, duas filiais usam um mesmo sistema central. Cada filial possui sua própria UF correta, mas uma rotina agrupa as notas apenas pelo horário de envio. Se as UFs diferem, esse agrupamento precisa ser revisto. A solução não é mudar os estabelecimentos informados nas notas.
NF-e e NFC-e não têm hoje a mesma liberdade de agrupamento
A presença dos modelos 55/65 na regra histórica não autoriza usar o antigo fluxo de lotes múltiplos para a NFC-e. A NT 2023.002 eliminou sua requisição assíncrona e estabeleceu uma única NFC-e por lote. A GAP03a-4 prevê retorno 126 quando são enviadas várias. NT 2023.002 v1.01, páginas 4 e 7.
Portanto, para modelo 65, “separar por UF” sozinho não basta: o envio deve respeitar a estrutura unitária e síncrona aplicável. Se uma integração atual relata 476 para uma única NFC-e, preserve a solicitação e a resposta completas. É necessário confirmar se o programa realmente enviou apenas um documento e se associou a resposta à tentativa correta.
Para modelo 55, a NT 2025.001 tornou obrigatório o processamento síncrono quando há uma única NF-e no lote. A versão 1.03 indica implantação em produção em 13 de outubro de 2025 para essa alteração, relacionada à rejeição 452. Assim, dividir um lote pode exigir ajuste simultâneo no tratamento da resposta. NT 2025.001 v1.03, páginas 6 e 8.
Nenhuma dessas mudanças justifica acrescentar notas fictícias ou repetir documentos para completar um lote. Processos especiais podem impor outras restrições de quantidade; a configuração precisa seguir o modelo e o processo efetivamente usados.
Uma sequência segura de correção
Confirme cStat 476 e a mensagem completa no retorno da autorização. Não use apenas um número apresentado pela tela do ERP.
Compare o cUF de cada documento com o da primeira nota do envelope. Verifique os estabelecimentos reais envolvidos.
Se houve agrupamento indevido, corrija a rotina de formação dos lotes. Preserve as informações fiscais corretas das notas.
Se o próprio cadastro estiver errado, valide o dado com a documentação do estabelecimento antes de regenerar o XML. Uma mudança em informação assinada exige geração e assinatura pelo fluxo normal do emissor.
Confira modelo, serviço, ambiente e quantidade. Uma única NF-e e uma única NFC-e exigem atenção à resposta síncrona, sem reaproveitar configurações antigas automaticamente.
Reconcilie as tentativas anteriores antes do reenvio. Consulte resultados pendentes e verifique individualmente quais documentos foram autorizados ou rejeitados.
Após a nova transmissão, registre o resultado de cada nota. O desaparecimento da 476 não garante autorização nem elimina outras validações.
Como distinguir problemas próximos
A 226 compara a UF do emitente com a UF do serviço autorizador. A 476 compara documentos dentro do lote. Já a 765 trata da mistura de NF-e e NFC-e no mesmo envio. Uma mensagem não substitui a outra, embora uma configuração incorreta possa produzir rejeições diferentes ao longo das tentativas.
O guia da Berga ajuda a reconhecer filas de filiais misturadas. A Brasil NFe destaca a separação por cUF. A Fiscal Pro relaciona o código à B02-20. Essas orientações precisam ser combinadas com as notas técnicas posteriores; não autorizam lotes múltiplos de NFC-e nem garantem sucesso após reenviar.
Se todos os valores conferirem, encaminhe ao fornecedor o envelope e o retorno da mesma tentativa, por canal seguro. Não envie certificado, senha ou chave privada. O objetivo é corrigir a organização do envio e conhecer o resultado fiscal de cada documento, sem modificar a operação para acomodar uma falha de integração.
Base documental consultada em 10/10/2026; PDFs oficiais preservados de 09/10/2026. Sem teste operacional em todas as UFs.