Rejeição 922: confira o documento de origem da contranota de produtor

Se a empresa está emitindo uma nota de entrada para registrar uma compra de produtor rural e recebe o código 922, confira qual documento foi vinculado como origem. O problema está no tipo de referência da contranota. Corrigir preço, quantidade ou imposto sem investigar esse vínculo não trata a causa apontada.

A NT 2019.001 admitia NF-e ou nota de produtor modelo 4; a NT 2026.002 v1.11 retirou a segunda opção. O índice oficial SVRS, conferido em 15/10/2026, lista a v1.11, com aviso sobre possíveis alterações de datas. Isso sustenta a referência documental, sem certificar ativação individual por UF. Preserve o XML enviado e identifique versão, ambiente e regra aplicada antes de corrigir. [1][2]

A redação de 2026 e a anterior

Na NT 2026.002 v1.11, página 10, a BA10-50 apresenta “Rejeição: Contranota de Produtor só pode referenciar NF-e”, após desconsiderar os trechos riscados. A referência ao modelo 4 foi retirada da condição e da mensagem. A linha permanece documentalmente facultativa, a critério da UF; não houve confirmação de sua aplicação individual. [1]

A NT 2019.001 v1.70, página 15, conservava “Rejeição: Contranota de Produtor só pode referenciar NF-e ou NF de Produtor Modelo 4”. Nesse contexto anterior, havia a chave da NF-e em refNFe e os dados da nota de produtor em refNFP. Os três guias práticos consultados ainda reproduzem a possibilidade de modelo 4. Essa orientação histórica não substitui a alteração oficial de 2026. [2]

Não são dois problemas independentes só porque o texto mudou: trata-se da evolução documental da mesma BA10-50, no serviço de autorização da NF-e modelo 55. O código não é uma regra geral de autorização de NFC-e modelo 65.

Quando a nota é identificada como contranota

A identificação utilizada pela BA10-50 vem das observações anteriores, que levam à BA10-20. Na versão de 2026, contranota é nota de entrada, tpNF=0, com finalidade normal, finNFe=1, e remetente da mesma UF com inscrição de produtor rural. Nesse documento, uso e controle são opcionais a critério estadual. Não há exceção adicional expressa na linha BA10-50; tipo e finalidade delimitam o cenário. [1]

Por isso, comece verificando se a operação realmente corresponde a essa situação. O nome usado no cadastro do fornecedor não substitui a inscrição e o enquadramento fiscal. Uma devolução tem finalidade própria; não deve virar emissão normal para encaixar nesse diagnóstico. Da mesma forma, mudar a nota de entrada para saída altera o fato informado, não corrige uma referência inadequada.

A página 3 inclui a BA10-50 nos ajustes da v1.10, com testes em 01/09/2026 e produção em 05/10/2026. A v1.11 adia para 14/12/2026 apenas I08-180, BA02-35 e VC02-40. O cronograma não confirma execução ou ativação atual em cada UF, autorizador e ambiente. Confirme a aplicação concreta com o autorizador responsável. [1]

O que comparar antes de alterar a nota

Reúna o documento do produtor, o XML efetivamente transmitido e a resposta integral da SEFAZ. Registre a UF do emitente, o autorizador, o ambiente e o horário. Depois confira:

• Modelo da nota que a empresa está emitindo: 55.

• Tipo e finalidade: tpNF e finNFe.

• UF e inscrição do produtor, comparadas com os documentos cadastrais.

• Cada ocorrência de ide/NFref, incluindo a tag realmente gerada.

• Modelo, emitente e situação do documento vinculado.

Uma tela pode mostrar “nota de produtor” e gerar refNFe corretamente, quando a origem é eletrônica. Também pode mostrar um número correto e gerar refNFP porque a espécie documental foi importada de um cadastro antigo. A evidência decisiva é o arquivo enviado, confrontado com a origem verdadeira. Não edite manualmente um XML já assinado.

Como tratar os cenários mais comuns

A origem é NF-e, mas o sistema gerou outra referência

Se existe NF-e modelo 55 correspondente à compra, confira seu XML e sua chave verdadeira. Corrija a classificação do documento de origem ou o mapeamento da integração para gerar o vínculo adequado em refNFe. O ajuste deve preservar produtor, mercadoria, valores e operação.

Não basta trocar o rótulo do modelo. Os dados precisam pertencer ao documento recebido. Uma chave copiada de outra compra pode ter formato válido e ainda assim produzir um vínculo fiscal incorreto. Após ajustar o cadastro, gere novamente a nota rejeitada pelo emissor e examine todas as referências, não apenas a primeira.

O documento recebido é realmente modelo 4

A solução histórica não pode ser aplicada automaticamente. A NT 2026.002 documenta também a BA10-10, obrigatória para modelo 55, vedando refNFP com retorno 682. A implementação concreta não foi testada nesta elaboração. A facultatividade estadual da BA10-50 não autoriza concluir que essa outra vedação possa ser ignorada. A presença de refNFP no esquema XML 010f também não significa permissão fiscal para utilizá-lo nessa operação. [1]

Preserve a nota recebida e encaminhe o caso ao responsável fiscal e ao suporte, incluindo a data da operação. É necessário definir o procedimento cabível para documentar essa aquisição e manter a rastreabilidade. Não crie uma chave eletrônica para um documento em papel, não altere sua data e não peça uma segunda emissão sem analisar o documento já existente.

Há referências misturadas ou importadas

Uma compra pode carregar a origem correta e um cupom ou documento antigo indevidamente incluído pela integração. Confira cada vínculo. Retire somente o comprovadamente incorreto, preservando documentos válidos e o histórico da alteração. Se a origem legítima estiver entre as referências vedadas na redação documental aplicável, obtenha uma solução fiscal completa; apenas apagar o vínculo não documenta a aquisição.

Um exemplo de investigação

Uma cerealista fictícia compra 800 quilos de produto de um agricultor da mesma UF e prepara a entrada normal. O produtor entregou uma NF-e autorizada, mas uma importação classificou a origem como nota em papel. O emissor gerou a referência inadequada e recebeu 922.

A equipe compara o XML original do produtor com a referência transmitida. Confirma que existe NF-e modelo 55 da aquisição, corrige a espécie importada e regenera a entrada com a chave desse documento. Quantidade, fornecedor e valor permanecem os mesmos. O exemplo descreve uma falha de cadastro; não autoriza converter uma nota modelo 4 verdadeira em NF-e.

Como verificar o resultado e quando escalar

Se houver dúvida sobre o resultado de um envio anterior, consulte a situação da chave antes de repetir a emissão. Faça uma nova transmissão controlada depois da correção comprovada. Leia o retorno completo: eliminar o 922 não significa que as demais validações foram atendidas. Confirme a chave, o ambiente e o protocolo do documento efetivamente autorizado, quando houver autorização, e preserve o vínculo da compra no sistema.

Se a referência correta já está no XML, ou a origem é modelo 4, encaminhe os arquivos ao suporte e à contabilidade. Peça confirmação da versão implementada, da configuração estadual e do procedimento cabível para aquela operação. Nesta elaboração não houve teste do autorizador; não deduza que a opção estadual da BA10-50 dispense outras vedações documentadas.

Fontes e limites

Pesquisa e revisão textual em 15/10/2026, horário de Brasília. Novos corpos práticos e reuso identificado de capturas oficiais desse dia. Sem emissão de teste, procedimento estadual individual certificado ou teste de telas do ALRA.

1. NT 2026.002 v1.11, páginas 3, 9 e 10: PDF HTTP 200 de 15/10, textos de cache correlacionado. PNGs documentais existentes 9 e 10 inspecionados nesta elaboração; leitura visual válida da página 3 realizada nesta conversa, no artigo 787, reutilizada explicitamente. Confirmados os riscos que retiram modelo 4, a definição da contranota e a separação entre 922 e 682.

2. NT 2019.001 v1.70, página 15: contraponto histórico lido em cache textual correlacionado ao PDF preservado. Sem nova captura HTTP ou inspeção visual dessa página; não é usado para afirmar permissão atual de modelo 4.

3. SVRS — Documentos NF-e: captura HTTP 200 de 15/10 e leitura WEB recente nesta conversa, no 787, reutilizadas por hash. Entrada v1.11 de 01/10/2026 e aviso sobre datas não comprovam implantação uniforme. O esquema 010f confirma os caminhos ide/NFref/refNFe e refNFP, sem substituir as regras de negócio ou validar XML externo.

4. Omie: corpo textual completo HTTP 200 e WEB, de 30/01/2026. Ainda admite modelo 4 e não explicita finalidade normal; prevalece a NT atual. Menus e sugestão de documentos relacionados pertencem ao Omie, sem imposição de duas referências ou reprodução de telas no ALRA.

5. TOTVS: corpo textual WEB completo, de 04/10/2021, separado do acesso direto HTTP 403. Orientação histórica para Protheus a partir de 12.1.25 e TSS 12, com espécies NFP/SPED e campos próprios. Não demonstra solução atual para modelo 4, procedimento do ALRA ou necessidade universal de criar duas entradas. Imagens não foram inspecionadas.

6. NS7: corpo textual específico completo WEB, sem data editorial explícita, separado da tentativa direta HTTP 406. A orientação de revisar origem e vínculo é útil; a aceitação de modelo 4 permanece histórica e não foi adotada como solução atual.

Busca focal em seis caches de NTs de 2026 localizou BA10-50 nas páginas 3 e 10 da NT 2026.002; ocorrências adicionais de “922” pertencem a CFOPs, não a esta rejeição. Ausência em outros caches não prova vigência universal. As leituras atuais não autenticam atos antigos. Históricos preservados, cruzada independente pendente e publicação não realizada.