Rejeição 1130: confira as origens dos itens antes de corrigir as referências

Sua NF-e pode reunir produtos que vieram de documentos diferentes, mas isso não significa que essa combinação seja permitida na operação que está sendo emitida. A rejeição 1130 pede conferir as chaves vinculadas aos itens e a finalidade da nota. O caminho é identificar a origem verdadeira de cada produto e verificar as exceções da regra, antes de alterar qualquer referência.

O retorno documentado é “Rejeição: Mais de um documento fiscal referenciado [nItem: 999]”. O número indicado em nItem ajuda a localizar o item apontado pelo autorizador; 999 é a representação usada na documentação. Não trate o aviso como problema de quantidade de produtos ou como impedimento universal de referenciar duas notas.

O que a SEFAZ está comparando

Na NT 2025.002-RTC v1.52, página 69, a regra VC02-30 pertence à autorização da NF-e modelo 55. Ela verifica se existem chaves de acesso diferentes em DFeReferenciado/chaveAcesso, no referenciamento por item. Fora das exceções, deve haver um único documento fiscal de origem. Dois produtos que apontam para itens distintos da mesma nota não representam, por esse motivo, dois documentos diferentes. [1]

Também não basta contar todas as chaves presentes no XML. Referências no nível da nota, no grupo NFref, e referências por item têm validações próprias. A VC02-05 trata do preenchimento simultâneo desses níveis e pode retornar 1010. Já repetir uma mesma combinação de chave e item é assunto da VC02-20, código 1072. Nenhuma dessas situações deve ser corrigida automaticamente como 1130.

A NFC-e modelo 65 tem outro limite: a VC02-04 veda o referenciamento por item e prevê 708. Portanto, a solução deste artigo não deve ser aplicada ao caixa da NFC-e apenas porque há um campo com nome semelhante no sistema.

Três exceções que mudam o diagnóstico

A VC02-30 não se aplica quando o XML identifica:

• tpNFDebito=03, débitos de notas fiscais não processadas na apuração;

• tpNFDebito=07, perda em estoque por perecimento, perda, furto ou roubo;

• finNFe=4, devolução.

Essas exceções afastam essa comparação específica. Elas não dispensam os demais requisitos de referenciamento, classificação e consistência da operação. Uma devolução pode referenciar documentos de origem distintos, mas cada vínculo ainda precisa corresponder ao que realmente foi devolvido.

Não transforme uma venda, um ajuste ou outra operação em devolução ou perda em estoque para conseguir passar pela validação. A finalidade e o tipo de nota devem representar fatos comprovados. Se houver dúvida sobre o enquadramento, o responsável fiscal precisa decidir antes de o suporte ajustar o emissor.

Confira o arquivo que foi transmitido

Preserve o XML rejeitado e a resposta integral, incluindo horário, ambiente e endereço do autorizador. Depois, monte uma relação simples com o número do item atual, produto, chave de origem e eventual número do item original. Essa relação revela se a diferença apareceu no cadastro, na escolha feita pelo operador ou na geração do XML.

Compare as chaves completas com os documentos originais, sem editar seus dígitos. Verifique se uma rotina de cópia reaproveitou a referência da última nota consultada, se uma importação misturou origens e se o documento foi montado por agrupamento de operações. São hipóteses de investigação, não causas que o código comprova sozinho.

Confira também finNFe e, quando pertinente, tpNFDebito. Uma tela pode mostrar “devolução”, enquanto o arquivo enviado conserva uma finalidade antiga. Nesse caso, a divergência entre a operação definida e o XML precisa ser corrigida na origem da geração, não com edição manual do arquivo assinado.

Como agir em cada cenário

Uma referência foi copiada incorretamente

Os documentos e os controles de estoque demonstram que os produtos envolvidos pertencem à mesma origem, mas um item recebeu a chave de outra nota. Corrija o vínculo no emissor para a chave verdadeira e confira o número do item original, quando exigido pelas regras aplicáveis. Gere novamente o XML pelo fluxo do sistema, com a assinatura correspondente ao conteúdo atualizado.

A correção não consiste em copiar a primeira chave para todos os itens. Ela exige comprovar que essa chave corresponde a cada produto e quantidade vinculados.

Existem duas origens verdadeiras fora das exceções

Se o arquivo representa corretamente origens distintas e a operação não está entre as exceções, a montagem precisa ser reavaliada. Entregue ao responsável fiscal a relação de documentos e itens. Ele deve definir a forma de documentar o caso, incluindo eventual emissão separada quando cabível.

Não apague a segunda referência nem atribua seus produtos à primeira nota. Isso esconderia a divergência no XML e prejudicaria a rastreabilidade. Preserve o documento rejeitado e a decisão que fundamentar a nova organização.

A operação corresponde a uma exceção

Se é uma devolução real ou outro caso listado, confira se os identificadores da exceção estão efetivamente presentes e corretos no XML. Examine a resposta completa para afastar confusão com 1072, 1010 ou outra rejeição.

Persistindo 1130 com uma exceção comprovada, encaminhe os arquivos ao suporte para comparar versão das regras, UF, autorizador e ambiente. A solução não é reduzir artificialmente a quantidade de origens. Pode ser necessária análise da administração tributária sobre a aplicação da validação.

Exemplo hipotético

Uma distribuidora prepara uma operação em que a VC02-30 exige origem única. Os itens 1 e 2 apontam para a NF-e A; o item 3 aponta para a NF-e B. A empresa recebe 1130 e descobre que uma importação reaproveitou a chave B, embora o documento original e o controle de entrada comprovem que o terceiro produto também veio da nota A.

O operador corrige o vínculo demonstrado pelos registros e regenera o XML. Se, em vez disso, o terceiro produto realmente viesse de B, o contador teria de reavaliar a montagem. E, se fosse uma devolução real identificada por finNFe=4, a exceção mudaria o diagnóstico. O mesmo desenho de chaves não produz uma orientação fiscal única.

Calendário e confirmação do resultado

A pesquisa compartilhada de 10/10/2026 registrou a publicação da v1.52 no portal SVRS em 01/10/2026. Nesta revisão houve apenas releitura local dos materiais salvos. O recorte do cronograma registra a VC02-30 entre alterações da v1.51, com previsão de produção em 05/10/2026. O bloco textual da regra na página 69 não apresenta observação própria de implementação futura. O aviso ENCAT de 05/10 adiou para 26/10 em homologação e 16/11/2026 em produção as NTs com homologação inicialmente em 05/10, incluindo as mudanças da v1.52. Isso não prova suspensão de todas as regras anteriores nem ativação uniforme por UF. [1][2]

Após a correção fundamentada, examine o novo retorno. O desaparecimento da 1130 pode revelar outra divergência; autorização exige resposta válida para a chave e o ambiente corretos. Preserve XML autorizado e protocolo, confira os vínculos aos documentos originais e confirme que não surgiu emissão duplicada. Acione o suporte por divergência de geração ou aplicação da regra, e o responsável fiscal por enquadramento ou reorganização da operação.

Fontes

Revisão documental textual por IA: 11/10/2026. Base: recortes e registros de capturas compartilhadas de 10/10/2026. Não houve nova consulta online, inspeção visual de PDF, validação XSD ou teste de emissão por UF/ambiente nesta etapa.

1. NT 2025.002-RTC v1.52, páginas 5–6 e 29, e VC02-30 na página 69.

2. SVRS, aviso ENCAT de 05/10/2026 e lista de documentos.

3. Migrate, referenciamento e mudanças da v1.52 e Inventti, devolução e referenciamento: dois apoios adjacentes com capturas compartilhadas e trechos textuais salvos. A Migrate menciona a 1130 em seu panorama; isso não representa três tutoriais específicos independentes. Os prazos antigos da Inventti não substituem o aviso posterior do ENCAT. A proveniência e os limites estão em fontes.v2.json.