Rejeição 450: confira o modelo, o serviço e o evento antes de corrigir

A rejeição 450, identificada pela mensagem “Modelo da NF-e diferente de 55”, pode aparecer na autorização de uma nota e em determinados eventos. A solução depende da solicitação que o sistema enviou. Transformar uma NFC-e em NF-e apenas para desaparecer o aviso pode criar um documento inadequado à operação.

O primeiro cuidado é separar três informações: o modelo real do documento, o serviço acionado e a regra aplicável àquela versão. NF-e é modelo 55; NFC-e é modelo 65. Já B06-30, B07-10 e P12-32 são identificadores de regras, não outros códigos de retorno.

Na autorização, comece pelo endereço de envio

O MOC descreve na B06-30 uma situação específica: quando a SEFAZ utiliza ambientes separados, uma NFC-e é encaminhada ao serviço de autorização da NF-e. Essa verificação é facultativa e vinculada à separação adotada pelo autorizador. Não se deve apresentar essa condição como uma proibição genérica de documentos modelo 65 em todo serviço fiscal. MOC 7.0, Anexo I, página 75.

Nesse caso, o empresário precisa verificar se a venda foi corretamente classificada e se o emissor selecionou o destino correspondente. Se o documento deveria ser uma NFC-e, o reparo pode estar no roteamento para o serviço de NFC-e. Se a operação exige NF-e, será necessário corrigir sua preparação pelo fluxo apropriado, com revisão fiscal, e não apenas substituir um número no arquivo.

A orientação da TecnoSpeed ajuda a localizar o campo mod e mostra que a rota da integração pode definir o modelo. A Berga destaca a escolha do endereço conforme UF, modelo e ambiente. A tabela da Oobj reproduz a condição de ambientes separados. Esses materiais apoiam a investigação; nenhum autoriza mudar a natureza fiscal da venda.

Em eventos, a chave precisa pertencer ao documento correto

Um evento é uma solicitação relacionada a uma nota já identificada por sua chave. Nesse fluxo, conferir somente o campo mod de um XML de emissão não basta: é preciso examinar a chave enviada em chNFe, o tipo de evento e sua versão.

As especificações de Comprovante de Entrega e de seu cancelamento, eventos 110130 e 110131, apresentam a regra P12-30 com retorno 450 quando o modelo não é 55. O mesmo ocorre nos eventos de Insucesso na Entrega e seu cancelamento, 110192 e 110193. São quatro verificações documentadas em serviços determinados, sem autorização para estender a restrição a todos os eventos. NT 2021.001 v1.01, páginas 8 e 12 e NT 2023.005 v1.02, páginas 9 e 14.

Uma hipótese prática é a seleção do cupom de uma venda no lugar da NF-e cuja entrega está sendo registrada. A correção consiste em localizar o documento efetivamente relacionado ao fato. Não altere os dígitos da chave de uma NFC-e para fazê-la parecer modelo 55: a chave identifica um documento específico e precisa continuar correspondendo a ele.

Nem todo trecho antigo continua válido

O evento Ator Interessado, código 110150, exige atenção diferente. Na NT 2020.007 v1.40, a antiga P12-30A, associada à 450 e à exigência exclusiva do modelo 55, aparece riscada. A especificação apresenta J02f com retorno 618 para modelo diferente de 55 e 65.

Por isso, encontrar o texto antigo em uma extração de PDF não prova que ele permanece aplicável. Também não significa que a 450 foi extinta nos eventos de entrega citados acima. Cada serviço tem seu próprio conjunto de verificações. Um retorno inesperado exige comparar o XML, a versão do evento e o autorizador, preservando a resposta para análise técnica. NT 2020.007 v1.40, página 9.

Há um contexto específico do PAA

A NT 2026.001 v1.02b prevê outras situações para o mesmo código. Na autorização, B07-10 verifica modelo 65 combinado com série reservada ao Provedor de Assinatura e Autorização, entre 970 e 989. No registro de evento, P12-32 faz essa verificação sobre a chave de acesso. O documento identifica o modelo como não permitido para o PAA nessas condições.

A nota técnica indica essas duas validações nos ambientes autorizadores de NF-e e NFC-e. Seu cronograma registra produção em 5 de outubro de 2026, mas a data documental não comprova, sozinha, a ativação de cada ambiente. O diagnóstico deve considerar o retorno recebido e o serviço efetivamente utilizado. Não se corrige a situação adotando uma série comum ou declarando outro processo de emissão apenas para escapar da validação. NT 2026.001 v1.02b, páginas 3, 12 e 16.

Sequência segura para resolver

1. Guarde o cStat, a mensagem completa, o horário e o XML da solicitação rejeitada, sem divulgar dados reais em canais públicos.

2. Identifique se o retorno veio da autorização ou de um evento. Neste último, anote tpEvento e verEvento.

3. Confirme modelo, UF, ambiente de homologação ou produção e endereço do serviço. Uma configuração correta em teste pode estar errada em produção.

4. Confira a série e a existência de processo PAA, quando pertinente. Não atribua toda 450 ao endereço do Web Service.

5. Corrija o mapeamento, o documento selecionado ou a configuração comprovadamente incorreta. Faça a nova geração e assinatura pelo emissor responsável.

6. Se houve tentativa anterior sem resposta conclusiva, consulte o processamento ou a situação do documento antes de reenviar. Uma falha de comunicação não demonstra rejeição fiscal.

7. Verifique o retorno final da nova solicitação. Resolver a 450 não impede que outra inconsistência seja identificada depois.

Como evitar repetição

Mantenha configurações separadas por documento, serviço, UF e ambiente. Testes de integração devem incluir autorização e os eventos realmente utilizados pela empresa, com chaves fictícias apropriadas ao ambiente de homologação.

O controle mais útil é registrar por que cada solicitação foi encaminhada àquele serviço. Assim, uma falha pode ser corrigida na origem, sem mudanças manuais de modelo, série ou chave que comprometam a rastreabilidade da operação.

Base documental consultada em 10/10/2026. PDFs oficiais preservados de 09/10/2026; versões e rasuras conferidas. A análise não certifica disponibilidade operacional universal.