"O que é, afinal, uma rejeição de nota fiscal? Por que ela acontece mesmo quando os dados parecem certos? A reforma tributária vai criar novos motivos de rejeição?"

Essa última pergunta tem resposta certa, e a data já está definida.

Neste artigo, você vai entender o que é uma rejeição de NF-e (um erro na estrutura do XML da nota) e por que a reforma tributária vai gerar uma nova onda delas a partir de 3 de agosto de 2026, quando a validação do IBS e da CBS deixa de ser só teste. Veja quais rejeições devem aparecer e o que fazer.

O que é uma rejeição de nota fiscal

Toda NF-e é transmitida para a SEFAZ como um arquivo XML, um documento estruturado em campos e grupos de campos, cada um com uma regra própria de preenchimento. Antes de autorizar a nota, a SEFAZ roda um conjunto de validações sobre esse XML. Se alguma regra não for atendida, a nota não é autorizada: ela é rejeitada.

Rejeição não é o mesmo que cancelamento. Uma nota rejeitada nunca chegou a existir para o Fisco, então não há nenhum documento para cancelar. O caminho é sempre corrigir o XML na origem e reenviar.

Ainda tem dúvida sobre os status possíveis de uma NF-e? Confira nosso guia completo sobre nota fiscal eletrônica e SEFAZ.

Por trás de toda rejeição está o XML

A causa raiz de praticamente toda rejeição é a mesma: um campo obrigatório que não foi informado, um campo preenchido com valor fora da tabela aceita, ou dois campos que deveriam ser compatíveis entre si e não são.

O XML da NF-e organiza essas informações em grupos. Um grupo reúne os dados de um mesmo assunto: os dados do emitente, os dados de cada item vendido, os impostos que incidem sobre esse item. Dentro de um grupo de imposto, por exemplo, existem campos como o CST (que classifica a situação tributária), a alíquota aplicada e, quando é o caso, o código de benefício fiscal. A SEFAZ verifica cada campo individualmente e também a combinação entre eles.

É por isso que um dado "certo" isoladamente ainda pode gerar rejeição. Um CST válido pode ser incompatível com a alíquota informada. Um código de benefício fiscal pode existir, mas não valer para o CST usado. O erro raramente está em um único campo: está na consistência entre os campos de um mesmo grupo.

Entender essa lógica ajuda a explicar por que a reforma tributária, ao criar grupos e campos novos no XML, também cria novos motivos de rejeição, que ainda nem existem na prática hoje.

Por que a reforma tributária vai criar novos motivos de rejeição

A reforma tributária (EC 132/2023 e LC 214/2025) inseriu no XML da NF-e um grupo inteiro de campos que não existia antes: o grupo do IBS (Imposto sobre Bens e Serviços) e da CBS (Contribuição sobre Bens e Serviços). Desde 2026, esse grupo já aparece nas notas, mas em fase de teste, com alíquota simbólica de 1% (0,1% de IBS e 0,9% de CBS) e sem geração de validações em massa.

Isso muda a partir de 3 de agosto de 2026. A partir dessa data, o preenchimento correto desse grupo passa a ser obrigatório para empresas do regime regular, segundo o cronograma da Receita Federal e as notas técnicas da NF-e. Um campo que hoje pode ficar incompleto sem consequência prática passa a ser motivo de rejeição.

Isso não significa cobrança real de IBS e CBS. A alíquota continua sendo a simbólica de teste (0,1% de IBS e 0,9% de CBS), sem impacto no valor pago pelo cliente. O que muda é a obrigatoriedade de informar o campo corretamente, não o valor do imposto recolhido.

Empresas do Simples Nacional não são afetadas por essa mudança em 2026: a obrigatoriedade do IBS e da CBS para o Simples só começa em 2027.

O que rejeita a partir de 03/08

A partir de 3 de agosto de 2026, deixam de valer as flexibilizações atuais e as rejeições abaixo passam a impedir a autorização de NF-e e NFC-e em produção para empresas do Regime Normal.

IBS/CBS não informado (código 1115)

É a rejeição mais direta da nova regra: o grupo de tributação do IBS/CBS (regra UB12-10) está ausente no XML da nota, quando deveria estar presente.

Como evitar: confirme que o emissor está preenchendo o grupo de IBS/CBS em toda nota emitida a partir de 3 de agosto de 2026.

CST incompatível com o cClassTrib informado (código 1024)

Acontece quando o CST do IBS/CBS e o código de classificação tributária (cClassTrib) informados na mesma nota não combinam entre si. Um exemplo comum é um CST de tributação integral combinado com um cClassTrib de redução ou de imunidade.

Como evitar: consulte a tabela de compatibilidade entre CST e cClassTrib antes de configurar as regras fiscais dos seus produtos e serviços no emissor.

Grupo de redução de alíquota Estadual do IBS não informado (código 1033)

Quando a operação tem direito a um benefício fiscal, mas esse benefício não está refletido nos campos do Grupo UB (o grupo de redução de alíquota estadual do IBS), a nota é rejeitada.

Como evitar: verifique se o emissor está traduzindo corretamente o benefício fiscal da operação para os campos de redução de alíquota do IBS estadual.

Grupo de redução de alíquota Municipal do IBS não informado (código 1074)

É a mesma inconsistência do código 1033, só que na esfera municipal: o benefício fiscal não aparece refletido no grupo de redução de alíquota municipal do IBS.

Como evitar: confirme se o emissor também preenche o grupo municipal, e não só o estadual, quando a operação tem benefício fiscal.

Grupo de redução de alíquota da CBS não informado (código 1079)

Mesma lógica dos códigos 1033 e 1074, agora aplicada à CBS: o benefício fiscal da operação não é refletido no grupo de redução de alíquota da CBS.

Como evitar: trate os três grupos de redução (estadual, municipal e CBS) como uma verificação única sempre que a operação tiver benefício fiscal.

Inconsistência de cClassTrib em tributação monofásica (códigos 1106 / 960)

Está ligada às regras LA01-30 e N12-110, que tratam de cenários de tributação monofásica, aplicáveis principalmente a combustíveis. O cClassTrib informado não é compatível com o regime monofásico da operação.

Como evitar: se sua empresa opera com combustíveis ou outros produtos sujeitos à tributação monofásica, revise com atenção extra as regras de cClassTrib para esse regime.

Todas essas rejeições já têm artigo dedicado na nossa central de ajuda, com o passo a passo de como resolver cada uma. Acesse a central de ajuda da Treeunfe e busque pelo código da sua rejeição.

O que fazer quando a nota é rejeitada

1. Leia a mensagem de rejeição completa, não só o código. A descrição indica exatamente qual campo ou grupo falhou na validação.

2. Volte à configuração fiscal do produto ou serviço no seu sistema emissor e confira se o campo apontado está preenchido e compatível com os demais campos do mesmo grupo.

3. Corrija o XML na origem, ajustando o campo apontado na mensagem de rejeição, e envie a nota novamente.

4. Reenvie e confirme o novo status pela chave de acesso antes de emitir o DANFE para o cliente.

Se o seu emissor atual não foi atualizado para os novos campos da reforma tributária (grupo de IBS/CBS, CST e cClassTrib específicos), as rejeições a partir de 3 de agosto vão se repetir, mesmo que você corrija o XML manualmente todas as vezes. Nesse caso, o problema não está na sua operação: está no sistema que você usa para emitir. Utilizar um emissor 100% adaptado à reforma antes dessa data evita acumular retrabalho logo na largada da nova regra.

A reforma tributária está criando novos campos no XML da NF-e, e cada campo novo é um novo motivo possível de rejeição. O Treeunfe NFe já está atualizado para o grupo de IBS/CBS e valida CST, cClassTrib e alíquota antes de a nota ser enviada à SEFAZ. Teste gratuitamente por 7 dias, sem compromisso e sem cartão de crédito.