Rejeição 957 na NFC-e: confira o processo de emissão e a exceção de Santa Catarina

A rejeição 957, “Tipo de emissão incompatível com o Processo de Emissão”, aponta uma incompatibilidade na identificação de como a NFC-e foi produzida. No serviço de autorização, a regra B26-50 da NT 2023.002 v1.01 se aplica ao modelo 65. O diagnóstico depende dos campos enviados no XML e da UF: corrigir a impressora ou trocar um número na configuração sem reconhecer o processo real pode manter o problema ou criar outra inconsistência.

A regra tem uma exceção expressa para Santa Catarina. Por isso, a orientação de preencher sempre o processo com zero, encontrada em explicações anteriores, precisa ser limitada ao caso em que o documento realmente foi gerado por aplicativo do contribuinte.

O que a regra compara

O campo tpEmis identifica a forma de emissão; o campo procEmi identifica o processo utilizado. São informações diferentes. Já verProc registra a versão do aplicativo, não uma modalidade que possa substituir os outros dois campos.

A B26-50 prevê a rejeição quando, na NFC-e, ocorrem simultaneamente estas condições:

• tpEmis é diferente de 3, correspondente ao Regime Especial Nota Fiscal Fácil, NFF;

• procEmi é diferente de 0, emissão com aplicativo do contribuinte.

Entretanto, para a UF de Santa Catarina, a própria linha determina que essa regra não se aplica quando procEmi é 1 ou 2, processos de emissão pelo Fisco. O primeiro identifica a nota avulsa pelo Fisco; o segundo, a nota avulsa emitida pelo contribuinte com seu certificado digital por meio do site do Fisco.

Essa exceção não transforma qualquer emissão em nota avulsa. Também não significa que informar tpEmis=3 autorize o documento: o uso da NFF precisa corresponder ao processo efetivamente adotado, e as demais validações continuam aplicáveis.

Versão e alcance da exceção

A versão 1.01 da NT 2023.002 documenta a emissão de NFC-e por aplicativo de nota avulsa em Santa Catarina. Seu cronograma informa implantação em testes até 19 de janeiro de 2026 e em produção até 2 de fevereiro de 2026. Essas datas são o calendário publicado; não demonstram que uma tentativa específica foi processada corretamente nem confirmam a habilitação de determinado emitente.

Na análise de um retorno, identifique a UF, o ambiente e a versão efetivamente usada pelo autorizador. Se uma emissão avulsa legítima de SC, com processo 1 ou 2, receber a 957, apresente o XML e a exceção documentada ao suporte responsável. Não converta o processo para zero apenas para esconder a divergência.

O leiaute atual também descreve procEmi=4 para o Provedor de Assinatura e Autorização, PAA. A existência desse valor no schema não libera seu uso indistinto na NFC-e: a NT 2026.001 contém condições próprias e rejeita o modelo 65 na faixa de séries do PAA. Esse mecanismo não deve ser tratado como uma nova exceção genérica à 957.

Como localizar a origem do problema

Comece pelo retorno completo, preservando cStat, xMotivo, chave, ambiente e horário da transmissão. Confirme que se trata da autorização de uma NFC-e e que a mensagem corresponde à 957. Números de retorno, isoladamente, não identificam todas as regras de todos os serviços fiscais.

Depois, confira no XML efetivamente transmitido os valores de mod, tpEmis, procEmi e verProc. Compare-os com a origem do documento: aplicativo do contribuinte, NFF ou processo de nota avulsa. Um rótulo apresentado na tela não basta para provar qual valor foi serializado na requisição.

Se houve atualização do emissor, migração de cadastro ou integração entre sistemas, peça ao suporte que examine o mapeamento desses campos. Uma configuração herdada de outro processo pode explicar a combinação enviada, mas essa é uma hipótese a verificar nos registros, não uma causa universal da rejeição.

Também diferencie a 957 da rejeição 370, tratada na regra B26-30 para o processo pelo Fisco. A relação de formas de emissão dessa outra regra não serve como autorização geral para usar SVC na NFC-e. Não misture validações vizinhas nem suponha uma ordem garantida de retorno entre elas.

Corrija a informação conforme a emissão real

Considere um exemplo didático: um aplicativo do contribuinte gera uma NFC-e de emissão normal, fora da exceção catarinense, mas transmite procEmi=2 por erro de mapeamento. Confirmada essa origem, o ajuste consiste em fazer o sistema representar corretamente o aplicativo do contribuinte, com procEmi=0. Não se trata de escolher o código que “passa”, e sim de corrigir uma informação que não descrevia o processo realizado.

Faça a correção no gerador ou na integração responsável e produza novamente o XML com a assinatura correspondente. Não edite manualmente um XML já assinado. O exemplo não exige mudar produtos, valores, CFOP, CST ou dados do destinatário, nem garante que outras validações serão atendidas.

Se o processo real for NFF ou avulsa, encaminhe a divergência ao responsável por esse fluxo. Não simule NFF, altere a UF ou mude o modelo do documento para contornar a regra. A operação e o meio de emissão precisam permanecer compatíveis com os fatos e com a autorização aplicável.

Confira o resultado antes de encerrar

Após o ajuste, confira o novo retorno e a situação da chave. Se houve timeout, perda de resposta ou outra tentativa anterior, recupere a situação no serviço apropriado antes de decidir pela retransmissão. Um retorno 957 não prova, por si só, que nenhuma tentativa anterior tenha produzido autorização.

Não conclua que o número está livre, que é necessário cancelar outra nota ou que a operação foi autorizada apenas porque a 957 desapareceu. Guarde o resultado final e o protocolo quando existir. Para suporte, forneça os valores dos campos, a UF, o ambiente, a versão do emissor e um XML compartilhado por canal seguro, sem enviar senha ou chave privada de certificado.

Fontes

• NT 2023.002 v1.01, páginas 3–5 e 8: cronograma, emissão avulsa em SC e B26-50.

• NT 2026.001 v1.02b, páginas 10–12: processo PAA e limites por modelo.

• Índice de notas técnicas do Portal Nacional.

• Buscador NCM: ficha 957, NS Tecnologia: análise da versão 1.00 e resposta sobre a 957 e Oobj: quadro de regras, trecho B26-50. São apoios de profundidades diferentes; os textos anteriores que omitem a exceção de SC devem ser confrontados com a versão 1.01.

• NDD: contexto da alteração da versão 1.01 em Santa Catarina.