Erros IBS/CBS

Esta página é o detalhe completo dos dois motivos de 422 específicos da Reforma Tributária (IBS/CBS) dentro da emissão assistida (resolverTributacao: true). O catálogo enxuto de todos os erros da API (formato RFC 7807, tabela de códigos HTTP, pré-voo do emissor) está em Erros e respostas.

Os dois motivos abaixo aparecem dentro de details.itensNaoResolvidos (NF-e/NFC-e) na resposta 422 de Emissão assistida. Procurando data de obrigatoriedade ou o cronograma da Reforma? Isso está em Reforma Tributária: datas que importam.

Espelho fiscal divergente

Um dos motivos possíveis dentro de details.itensNaoResolvidos. Acontece quando a redução de IBS/CBS que temos espelhada para o NCM não bate com a tabela oficial de classificação tributária para a classe (cClassTrib) daquele mesmo NCM:

{
  "index": 0,
  "motivo": "NCM 21069090: o espelho fiscal está divergente da tabela oficial para a classe 200003 (gravado 60/60/60, oficial 100/100/100); informe ibsCbs.cClassTrib explicitamente ou envie a tributação manualmente. Ref.: https://docs.engineapi.com.br/guides/errors#espelho-fiscal-divergente"
}

Os números entre parênteses são, nesta ordem, IBS-UF / IBS-Municipal / CBS. Por que recusamos antes de transmitir: a SEFAZ valida o percentual de redução de cada tributo contra o cClassTrib do item (NT 2025.002) e rejeita a combinação incoerente: cStat 1034 no IBS-UF, 1046 no IBS-Municipal, 1063 na CBS. Ou seja, o documento não chega a existir de qualquer forma. A diferença é o que você recebe: em vez de um código da SEFAZ sem contexto (produzido por um dado que está do nosso lado, não no seu payload), você recebe este 422 local dizendo qual NCM, quais são os dois números em conflito e o que fazer. Nada é transmitido. Como seguir agora, sem esperar a correção do dado:

Informe o grupo ibsCbs do item no payload (o mesmo shape que a emissão passthrough usa). Item com ibsCbs explícito é override do parceiro: o motor não recalcula nem consulta o espelho para ele.
Ou emita esse item sem resolverTributacao, com a tributação que o seu ERP já tem.

Um mesmo NCM pode pertencer a mais de um anexo de redução com tratamentos diferentes; qual deles vale depende do produto real, não do código NCM. Por isso o cClassTrib explícito resolve o caso: ele diz qual tratamento se aplica àquela mercadoria.

NCM multiclasse

Outro motivo dentro de details.itensNaoResolvidos, e o mais comum em alimento: o NCM aparece em mais de um anexo da LC 214/2025, com percentuais diferentes. Quem decide qual vale é o produto real, não o código: então o motor não escolhe sozinho:

{
  "index": 0,
  "code": "NCM_MULTICLASSE",
  "motivo": "NCM 21069090: este NCM aparece em mais de um anexo da LC 214/2025, com tratamentos diferentes: quem decide é o produto, não o código. Classes vigentes: 200003 (Anexo 1, IBS-UF 100%, IBS-Mun 100%, CBS 100%); 200011 (Anexo 6, IBS-UF 100%, IBS-Mun 100%, CBS 100%, depende de condição da operação); 200033 (Anexo 6, IBS-UF 60%, IBS-Mun 60%, CBS 60%). Informe ibsCbs.cClassTrib com a classe do seu produto, ou envie a tributação manualmente. Ref.: https://docs.engineapi.com.br/guides/errors#ncm-multiclasse",
  "candidatas": [
    {
      "cClassTrib": "200003",
      "nome": "Vendas de produtos destinados à alimentação humana (Anexo I)",
      "anexo": "1",
      "cst": "200",
      "pRedIBSUF": 100,
      "pRedIBSMun": 100,
      "pRedCBS": 100,
      "automatica": true,
      "motivoDescarte": null
    },
    {
      "cClassTrib": "200033",
      "nome": "Anexo VI",
      "anexo": "6",
      "cst": "200",
      "pRedIBSUF": 60,
      "pRedIBSMun": 60,
      "pRedCBS": 60,
      "automatica": true,
      "motivoDescarte": null
    }
  ]
}

candidatas traz todas as classes vigentes daquele NCM, com o anexo que as sustenta e os percentuais de cada tributo: é o suficiente para escolher sem uma segunda requisição. Quando o marcador automatica vem falso, aquela classe só vale se você a informar explicitamente, porque o tratamento dela depende de um fato da operação (adquirente, destinação, habilitação) que o NCM sozinho não revela.

Pergunta de fato para o comerciante

Para parte dos NCMs multiclasse a LC 214/2025 separa as classes por um fato que o comerciante sabe responder: para que o produto é vendido, de que tipo ele é. Nesses casos o item traz também confirmacao_classe_necessaria, com a pergunta e as opções em linguagem de fato, sem número de classe:

{
  "contexto_id": "3fa85f64-5717-4562-b3fc-2c963f66a001",
  "pergunta": "Que sal é este e para que ele é vendido?",
  "opcoes": [
    { "fato": "iodado_consumo_humano", "texto": "Sal iodado, para as pessoas consumirem (sal de cozinha)" },
    { "fato": "mineralizado_racao", "texto": "Sal mineralizado, para fazer ração ou dar a animais de criação (não animais de estimação)" },
    { "fato": "sem_iodo_consumo_humano", "texto": "Sal sem iodo, para as pessoas consumirem" },
    { "fato": "outro_uso", "texto": "Para outro uso (indústria, piscina, limpeza, degelo ou animais de estimação)" }
  ],
  "expira_em": "2026-10-03T15:00:00.000Z"
}

Mostre a pergunta ao comerciante e responda com POST /v1/fiscal/classification/classe/confirm-merchant, enviando issuerId, contextoId e um destes campos:

fato: o identificador da opção escolhida;
resposta: o texto livre do comerciante. O motor só confirma se a resposta trouxer o fato inteiro de uma das opções; resposta parcial, contraditória ou que o motor não conseguiu ler volta status: pendente e nada é gravado.

Confirmado, a resposta traz cClassTrib e a fonte (artigo e item do anexo da LC 214) que sustentam a classe, e a próxima emissão do mesmo item (mesma empresa, descrição, código e EAN) sai com essa classe. Alguns fatos não dão classe reduzida (por exemplo, sal sem iodo ou ração para animal de estimação): a confirmação volta pendente com o motivo, e a saída é falar com o contador ou informar a tributação. A pergunta deixa de valer, e o item pergunta de novo, quando as classes vigentes do NCM mudam. NCM sem um fato da lei que separe as classes não traz pergunta: siga pelas candidatas, abaixo. Dois códigos irmãos aparecem no mesmo lugar:

`code`	Quando
`NCM_MULTICLASSE`	2+ classes vigentes com tratamentos diferentes
`NCM_SEM_CLASSE_AUTOMATICA`	todas as classes do NCM dependem de condição da operação, ou não são admitidas neste modelo de documento
`CCLASSTRIB_INVALIDO_PARA_NCM`	você informou uma classe que não consta dos anexos vigentes daquele NCM, inclusive quando o NCM não tem anexo nenhum (tributação integral)
`CCLASSTRIB_INADMISSIVEL_NO_MODELO`	você informou uma classe que a tabela oficial não admite neste modelo de documento (`indNFe = 0` em NF-e, `indNFCe = 0` em NFC-e). A SEFAZ rejeitaria com `cStat 1025`

Informando só a classe (`ibsCbs.cClassTrib`)

Para desempatar, você não precisa calcular os seis percentuais. Basta informar a classe e ligar a emissão assistida: o motor busca os percentuais oficiais dela:

{
  "resolverTributacao": true,
  "items": [
    { "descricao": "Preparação alimentícia", "ncm": "21069090", "quantidade": 2, "valorUnitario": 5, "ibsCbs": { "cClassTrib": "200003" } }
  ]
}

A resposta declara a classe estampada em tributacao.ibsCbs.classe, com o código, o anexo que o sustenta e a origem da escolha (informada, quando ela veio de você; resolvida, quando o motor elegeu), o que permite auditar depois qual anexo sustentou o número que foi assinado. Três regras deste formato:

ele exige "resolverTributacao": true. Sem a flag ninguém resolve os percentuais, e o grupo iria incompleto para o documento: a API recusa antes com 422 IBSCBS_CLASSE_SEM_RESOLVEDOR;
cClassTrib é o único campo aceito aqui. Qualquer outro (inclusive vBC) devolve 400: a base de cálculo do IBS/CBS neste caminho é sempre o vProd do item, e aceitar um campo que não teria efeito seria pior que recusá-lo;
o grupo ibsCbs completo (com ibsUf, ibsMun e cbs) continua sendo passthrough puro, como sempre foi: o motor não toca nele. Grupo pela metade não vira “dica” em silêncio: falha nos dois formatos e devolve 400 com a mensagem do campo que faltou.

A classe que você informa vence a eleição automática, mas não vence a tabela oficial: classe inadmissível no modelo do documento é 422 CCLASSTRIB_INADMISSIVEL_NO_MODELO (a SEFAZ rejeitaria com cStat 1025). Uma classe condicionada a fato da operação (adquirente, destinação, habilitação) é aceita em NF-e (você conhece a operação) e recusada em NFC-e, onde a tabela oficial a marca como não admitida.

Guardar a classe por produto

A escolha vale para o produto, não para a nota. Depois de informar ibsCbs.cClassTrib numa emissão (ou confirmar no painel / em POST /v1/fiscal/classification/classe), o motor guarda a classe no cadastro daquele item naquele emissor. A próxima emissão do mesmo código sem a classe no payload reusa a lembrança, desde que ela continue entre as candidatas vigentes e seja admissível no modelo do documento. Se o conjunto de candidatas do NCM mudar (nova classe divergente, classe removida, alíquota alterada), a lembrança fica pendente e o 422 NCM_MULTICLASSE volta a pedir confirmação, com a lista atualizada. Um emissor nunca herda a escolha de outro.

Quando sua classe derruba uma classe confirmada

A classe que você informa na emissão sempre vence, inclusive quando o produto já tinha uma classe confirmada em POST /v1/fiscal/classification/classe. A emissão não trava, o documento sai com a classe do payload e o cadastro passa a registrar que foi você quem a escolheu. O que a API faz a mais nesse caso: guarda a classe que foi derrubada e devolve o produto em GET /v1/fiscal/classification/pendentes com o motivo deslocou_confirmada, junto da classe anterior e da data do deslocamento:

{
  "itens": [
    {
      "codigo": "SKU-001",
      "descricao": "Preparação alimentícia",
      "ncm": "21069090",
      "cClassTrib": "200033",
      "origem": "informado",
      "motivo": "deslocou_confirmada",
      "cClassTribAnterior": "200003",
      "deslocouEm": "2026-09-17T12:00:00.000Z",
      "candidatas": []
    }
  ]
}

É um aviso, não um bloqueio: serve para alguém conferir qual das duas classes vale para aquele produto. Para fechar o caso, confirme a classe correta em POST /v1/fiscal/classification/classe: a confirmação limpa o marcador e o item sai da lista, valendo tanto para a classe nova quanto para a antiga. Duas coisas que não acontecem:

produto cuja classe anterior não estava confirmada (veio de uma emissão anterior, origem informado) não gera marcador nem entra na lista. É o caso comum de quem manda cClassTrib em toda nota, e enchê-lo de avisos não ajudaria ninguém;
classe confirmada que é reinformada igual continua confirmada, sem marcador e fora da lista.

motivo é um campo aditivo: os valores pendente e candidatas_mudaram continuam com o mesmo significado, e deslocou_confirmada entrou ao lado deles. cClassTribAnterior e deslocouEm vêm null nos outros dois motivos. Para listar as candidatas sem emitir:

POST /v1/fiscal/classes-por-ncm
{ "ncm": "11029000", "modelo": "55" }

A resposta traz candidatas[] com nome, descricao, anexo e percentuais. É o mesmo shape do 422. garantia é sempre false.

Veja também

Erros e respostas: o catálogo completo, RFC 7807, códigos HTTP e pré-voo do emissor.
Cérebro Fiscal: o que é a emissão assistida e como ativar na sua conta.
Changelog fiscal: o que é uma mudança de regra, o 422 na emissão, e os ciclos dos últimos 90 dias.

Comece aqui

Emissão

Tributação

Erros e operação

IA e automação

Conceitos

Migração

Perguntas frequentes

Espelho fiscal divergente

NCM multiclasse

Pergunta de fato para o comerciante

Informando só a classe (`ibsCbs.cClassTrib`)

Guardar a classe por produto

Quando sua classe derruba uma classe confirmada

Veja também

Espelho fiscal divergente

NCM multiclasse

Pergunta de fato para o comerciante

Informando só a classe (ibsCbs.cClassTrib)

Guardar a classe por produto

Quando sua classe derruba uma classe confirmada

Veja também

Informando só a classe (`ibsCbs.cClassTrib`)