NF-e
Rejeição 1200: alinhe o motivo do débito ao cClassTrib do item
Ao receber a rejeição 1200, separe o XML enviado e a resposta antes de repetir a transmissão. O problema envolve a relação entre o motivo da nota de débito e a classificação tributária de um item. Uma descrição correta na tela não basta quando o arquivo conserva outra combinação.
Ao receber a rejeição 1200, separe o XML enviado e a resposta antes de repetir a transmissão. O problema envolve a relação entre o motivo da nota de débito e a classificação tributária de um item. Uma descrição correta na tela não basta quando o arquivo conserva outra combinação.
A nota de débito fiscal também não é sinônimo de qualquer dívida registrada no financeiro. Seu uso e seu motivo precisam representar a situação definida pelo responsável fiscal. A rejeição aponta uma incompatibilidade de campos; ela não escolhe o enquadramento da empresa nem demonstra direito a crédito.
Identifique a comparação feita pelo autorizador
A mensagem é “Rejeição: cClassTrib incompatível com o tipo de Nota de Débito [nItem: 999]”. O marcador 999 é documental: use o número efetivamente apresentado na resposta para localizar o item.
Na NT 2025.002-RTC v1.52, a UB14-70, página 42, tem coluna de modelo 55 e verifica a compatibilidade quando tpNFDebito está informado. Esse campo fica na identificação da nota; IBSCBS/cClassTrib pertence ao item. O contexto é autorização de NF-e, não consulta cadastral ou registro de evento.
O leiaute da página 15 identifica a finalidade 6 como nota de débito e relaciona seus tipos. Não confunda esses tipos com os da nota de crédito, cuja comparação possui a UB14-80 e o código 1201. A abrangência geral da NT sobre NF-e e NFC-e não estende automaticamente a 1200 ao modelo 65.
Compare com a matriz documental
A transcrição preservada da página 42 contém estas relações:
Tipo de nota de débito | Motivo descrito na NT | cClassTrib indicado |
|---|---|---|
01 | Transferência de créditos para cooperativas | 800002 |
02 | Anulação de crédito por saídas imunes/isentas | 811001 |
03 | Débitos de notas fiscais não processadas na apuração | 811002 |
04 | Multa e juros | Não limitar |
05 | Transferência de crédito na sucessão | 800001 |
06 | Pagamento antecipado | Não limitar |
07 | Perda em estoque | 410030 |
08 | Desenquadramento do Simples Nacional | 811003 |
O quadro explica uma validação específica. Ele não substitui a análise da operação, a tabela de classificações aplicável ou a verificação do CST correspondente. Um código mencionado no documento não concede tratamento fiscal por si só.
Para 04 e 06, “Não limitar” significa que a UB14-70 não fixa um único código. As outras regras continuam relevantes. A UB14-60, também na página 42, restringe determinados códigos aos tipos de débito ou crédito previstos. Por exemplo, ela relaciona 410030 ao débito 07. Não se pode transportar essa classificação para pagamento antecipado apenas porque o tipo 06 não possui vínculo único na UB14-70.
Reconstitua o preenchimento do documento
Confira chave, estabelecimento, modelo, ambiente, horário e versão do emissor. Relacione a resposta à tentativa correta. Uma prévia regenerada depois do erro pode apresentar dados diferentes dos transmitidos.
Depois coloque lado a lado o tipo do cabeçalho e o cClassTrib do item apontado. Verifique a finalidade e os documentos que justificam o débito. Identifique também qual cadastro ou rotina forneceu a classificação: produto, configuração da operação, importação ou cópia de outro documento.
Examine todos os itens que usam a mesma origem de parametrização. Uma seleção feita no cabeçalho não garante que as classificações individuais acompanharam a mudança. Da mesma forma, corrigir o cadastro pode não atualizar uma nota anteriormente preparada.
Preserve essa comparação para o suporte: valor esperado, valor transmitido, origem identificada e documento fiscal que fundamenta a escolha. O número comercial do produto pode diferir de sua posição no XML; evite corrigir outra linha por confundir código interno com nItem.
Corrija o dado errado, mantendo o fato fiscal
O motivo foi confirmado, mas a classificação veio de outra operação. Ajuste a parametrização específica com o fiscal e regenere a nota. Confira os grupos e valores tributários dependentes da classificação. Alterar um código pode exigir recalcular informações relacionadas; não faça substituição manual em arquivo assinado.
O motivo escolhido não corresponde ao documento de suporte. A equipe fiscal precisa definir a identificação correta da operação. Não conserve o motivo errado e adapte o cClassTrib para combinar com ele. O ajuste deve alcançar a finalidade e os demais dados pertinentes, quando necessário.
A operação é multa, juros ou pagamento antecipado. Peça a classificação fundamentada para esse caso. Não reutilize um código reservado a transferência, perda ou desenquadramento como valor padrão. A análise das restrições adicionais precede a transmissão.
A combinação parece compatível e o erro continua. Compare o XML da mesma tentativa com a matriz e verifique o item indicado. Investigue geração antiga, mapeamento ou retorno associado a outro arquivo. Se não houver divergência demonstrável, encaminhe as evidências ao suporte e ao autorizador competente. Não atribua automaticamente falha à SEFAZ nem altere fatos por tentativa.
Exemplo de classificação reaproveitada
Em um caso fictício, a contabilidade comprova uma situação de anulação de crédito por saídas imunes/isentas e define o débito tipo 02. A integração utiliza uma configuração copiada de uma transferência para cooperativa, conservando cClassTrib=800002 no item.
No ambiente que execute a UB14-70, essa combinação contraria sua linha 02, que indica 811001. A equipe documenta a origem do preenchimento, corrige a configuração dessa operação e gera novamente o arquivo. Também confere o CST e os grupos decorrentes.
O exemplo ilustra uma incompatibilidade comprovada entre campos. Não estabelece que qualquer saída isenta autorize aquela nota nem que mudar para 811001 garanta autorização. O fundamento fiscal precisa existir antes do ajuste.
Separe calendário documental de funcionamento real
A base usada aqui é a captura oficial de 10/10/2026 da v1.52, publicada no portal em 01/10. A releitura para esta redação ocorreu em 12/10, sem nova consulta web.
A página 5 inclui UB14-60, UB14-70 e UB14-80 na v1.40, com previsão até 01/07/2026 em homologação e 03/08/2026 em produção. O aviso ENCAT de 05/10, preservado na captura, adia a implantação anunciada da v1.52 para 26/10 e 16/11. Esse comunicado não demonstra suspensão automática do bloco anterior.
Esses registros não comprovam execução em cada UF, autorizador ou ambiente. A pesquisa desta etapa não atualizou a legislação, a tabela dinâmica de classificações ou o funcionamento do emissor.
Confira o resultado e encaminhe a pendência
Após uma correção fundamentada, leia a resposta completa da nova tentativa. Outra rejeição exige outro diagnóstico. Só registre autorização quando houver resultado correspondente à chave e preserve XML e protocolo.
Leve ao fiscal dúvidas sobre motivo, classificação ou direito ao tratamento. Leve ao suporte diferenças entre cadastro e XML, com as comparações preservadas. O desaparecimento do 1200 confirma apenas que essa incompatibilidade deixou de ser apontada naquele retorno.
Fontes
Elaboração v2 em 12/10/2026, somente com provas salvas. Rascunho sem revisão própria, cruzada ou aprovação nesta etapa.
NT 2025.002-RTC v1.52, páginas 5–6, 15 e 42–43: transcrições preservadas, matriz UB14-70 e distinções adjacentes.
Documentos SVRS e aviso ENCAT: capturas de 10/10/2026, relidas localmente; nenhuma consulta atual.
TecnoSpeed, panorama da NT: captura histórica com apoio adjacente sobre classificações e finalidades. Não é confirmação específica da solução 1200 nem prova de recursos do ALRA.
Não foi recuperado corpo rastreável para o confronto prático específico citado na v1. A v2 não alega leitura ou confirmação dessas páginas. O log de falhas, os limites e o parecer anterior permanecem registrados em fontes.v2.json, sem modificar os arquivos anteriores.