As 10 rejeições mais recorrentes da SEFAZ: causas técnicas e como sua integração resolve cada uma

Guia técnico para times de software house identificarem e corrigirem rapidamente as rejeições que mais aparecem em produção.

O contexto: por que mapear rejeições recorrentes economiza semanas de suporte

Toda software house que integra emissão fiscal chega a um ponto parecido. O volume de NF-e ou NFC-e cresce, e um pequeno grupo de rejeições passa a concentrar a maior parte dos chamados de suporte. Não são erros aleatórios. São padrões que se repetem porque nascem de decisões de arquitetura, de dados cadastrais mal validados ou de premissas erradas sobre o comportamento da SEFAZ.

Este guia reúne 10 rejeições que aparecem com frequência em operações reais, organizadas por natureza técnica em vez de ordem de volume. A lógica é simples. Erros de schema pedem uma solução. Erros de sincronismo de relógio pedem outra, completamente diferente. Tratar os dois como “só mais uma rejeição da SEFAZ” é o motivo pelo qual times gastam meses corrigindo o que poderia ser resolvido em uma tarde.

Duas dessas rejeições merecem atenção redobrada. Elas não são bugs antigos, são sintoma direto do modelo IBS/CBS da Reforma Tributária entrando em produção. Quem entender a causa agora evita retrabalho quando o volume dessas rejeições específicas crescer.

Erros de schema e estrutura do XML

Rejeições de schema são as mais previsíveis de resolver, e também as mais fáceis de diagnosticar errado quando a mensagem de erro vem truncada ou genérica.

CST inválido para o grupo de tributação usado

A rejeição 225 aparece, entre outras variações de schema, quando o CST informado para PIS ou COFINS não existe para o subgrupo utilizado. Um exemplo típico é usar CST 70 dentro do grupo PISNT ou COFINSNT, quando esses subgrupos só aceitam os códigos 04, 05, 06, 07, 08 e 09.

O campo afetado é o CST, dentro dos grupos PIS e COFINS, em imposto. A solução é direta: consultar a tabela de CST válidos para cada subgrupo antes de gerar o XML, e não depois de recebê-lo rejeitado. Para uma operação isenta de PIS, por exemplo, o subgrupo PISNT com CST igual a 07 é o código correto.

Sistemas que fazem essa validação apenas em runtime, sem checagem prévia contra uma tabela local atualizada, tendem a repetir esse erro toda vez que uma nova combinação de regime tributário aparece na base de clientes.

Elemento filho inválido no schema XSD

A rejeição 215 aparece quando o XML contém uma tag que não está prevista na posição esperada pelo schema. A mensagem de erro costuma ser longa, listando o elemento problemático e a lista de elementos válidos naquela posição.

O campo é variável, a própria mensagem de rejeição indica o caminho exato da tag inválida. A solução envolve ler o detalhe da rejeição com atenção, confirmar que a tag existe no schema da versão em uso, e validar o XML contra o XSD antes de transmitir, não depois.

Vale um ponto de atenção aqui. Quando a mensagem cita elementos como IBSCBS, IBSCBSTot ou qBCMonoRet como “inválidos”, isso costuma indicar algo mais específico do que um erro de digitação. Esse é o assunto da próxima seção.

Rejeições que já são sintoma da Reforma Tributária

Esta é a seção mais importante deste guia para quem está adaptando a integração ao novo modelo tributário. Duas rejeições, tratadas isoladamente, parecem apenas mais um erro de schema ou de cálculo. Vistas juntas, elas mostram o mesmo fenômeno de dois ângulos diferentes.

Quando o schema rejeita campos do modelo IBS/CBS

No padrão da rejeição 215, descrito na seção anterior, um caso específico merece destaque. Quando a mensagem de rejeição aponta tags como IBSCBS dentro do grupo imposto, IBSCBSTot dentro de total, ou qBCMonoRet dentro de ICMSTot como elementos não esperados, o sistema não está diante de um erro de digitação comum.

Essas tags são exatamente os campos do novo modelo tributário da Reforma. O que costuma acontecer é uma integração tentando inserir campos do modelo IBS/CBS em um XML que ainda segue a estrutura de schema vigente para NF-e ou NFC-e sem a migração de versão correspondente. O schema em uso simplesmente não reconhece essas tags naquela posição, porque ainda não foi atualizado para o layout que as suporta.

A mesma mensagem de rejeição também pode citar uma falha de hash no campo hashCSRT, dentro de infRespTec. Essa é uma validação separada, ligada à assinatura do responsável técnico, e não tem relação direta com o modelo IBS/CBS. Vale isolar as duas causas ao investigar, porque tratar as duas como o mesmo problema atrasa o diagnóstico.

A solução prática passa por identificar exatamente qual versão de schema o ambiente está usando no momento da emissão, e garantir que campos do modelo novo só sejam inseridos quando a integração já estiver na versão de schema que os suporta. Misturar tags de gerações diferentes de layout no mesmo XML é a causa raiz mais comum desse padrão.

Cálculo da alíquota efetiva do IBS fora da fórmula esperada

A rejeição 1035 aparece quando o campo pAliqEfet, dentro do grupo gIBSUF, não corresponde ao valor que a SEFAZ calcula a partir dos parâmetros informados.

A regra de validação exige duas fórmulas, dependendo do contexto da operação. Sem o grupo de compra governamental informado, o cálculo é:

pAliqEfet = pIBSUF × (1 − pRedAliq / 100)

Com o grupo de compra governamental informado, entra um terceiro fator:

pAliqEfet = pIBSUF × (1 − pRedAliq / 100) × (1 − pRedutor / 100)

Onde pIBSUF é a alíquota vigente do IBS de competência da UF, pRedAliq é o percentual de redução de alíquota do cClassTrib, e pRedutor é o percentual de redução aplicável em compra governamental.

O ponto que mais gera rejeição não é a fórmula em si, é a precisão do arredondamento. O campo pAliqEfet precisa ser preenchido com exatamente 4 casas decimais. Um cálculo correto de 5,7000 rejeitado por vir informado como 5,7 é um padrão que se repete com frequência enquanto a camada de cálculo não trata esse arredondamento como obrigatório.

A solução é recalcular a alíquota efetiva aplicando a fórmula correta para o contexto da operação, com ou sem compra governamental, e garantir que a rotina de geração do XML sempre force 4 casas decimais nesse campo específico, com arredondamento na última casa.

Sistemas que tratam esse campo como um número de precisão livre, em vez de um valor com formato fixo exigido pela SEFAZ, vão continuar vendo essa rejeição toda vez que o resultado do cálculo tiver menos de 4 casas.

Erros de dados cadastrais e regras fiscais

Diferente das rejeições de schema, esta categoria nasce de dados incorretos ou desatualizados, não de estrutura do XML.

NCM inexistente na tabela vigente

A rejeição 778 ocorre quando o NCM informado no grupo prod não existe na tabela NCM vigente da Receita Federal. Isso costuma acontecer quando a base de produtos do sistema emissor não é atualizada com a mesma frequência que a tabela oficial muda.

A solução envolve consultar a tabela NCM vigente diretamente no portal da Receita Federal e usar o código correto de 8 dígitos no campo NCM. Um exemplo prático: para camisas de algodão masculinas, o código correto é 62052000, e não uma variação desatualizada ou mal digitada.

Times que mantêm uma tabela NCM local sem rotina de sincronização periódica tendem a acumular esse tipo de rejeição conforme produtos novos entram no catálogo do cliente.

CFOP inválido para NFC-e

A rejeição 725 aparece porque a NFC-e, identificada pelo campo mod igual a 65, aceita apenas CFOPs de venda ao consumidor final. Um erro comum é usar CFOPs interestaduais, da faixa 6xxx, ou de exportação, da faixa 7xxx, em uma NFC-e, quando esse modelo de documento não admite esse tipo de operação.

O campo afetado é o CFOP, dentro do grupo prod. Para uma NFC-e de venda ao consumidor, os códigos corretos incluem 5102, 5405 e 5929, todos de operações internas destinadas ao consumidor final.

A solução prática é validar, antes de gerar o XML, se o CFOP escolhido é compatível com o modelo de documento. Uma regra simples de validação cruzada entre mod e CFOP evita esse padrão de forma sistemática.

Erros de sincronismo e numeração

Esta categoria reúne rejeições ligadas a tempo, sequência e referência entre documentos, não a conteúdo fiscal em si.

Data-hora de emissão à frente do horário da SEFAZ

A rejeição 703 acontece quando o campo dhEmi, no grupo ide, vem com uma data-hora posterior ao horário de recebimento no servidor da SEFAZ. A causa raiz costuma ser simples: o relógio do servidor emissor está adiantado em relação ao horário oficial.

A solução tem duas camadas. O ajuste no documento é no campo dhEmi, no grupo ide, que precisa refletir a data-hora real da operação, nunca um valor futuro em relação ao servidor SEFAZ. A causa raiz, no entanto, costuma estar fora do XML: o relógio do servidor emissor adiantado. Por isso a correção definitiva é sincronizar o relógio via NTP, usando um servidor como pool.ntp.br, e configurar essa sincronização de forma permanente, não corrigir a data manualmente a cada ocorrência.

Número da faixa de inutilização já utilizado

A rejeição 241 acontece ao solicitar a inutilização de uma faixa de numeração quando um ou mais números dessa faixa já foram usados em NF-e autorizadas ou canceladas. Os campos envolvidos são nNF e serie, no grupo ide, usados na composição do pedido.

A solução passa por consultar a SEFAZ para identificar quais números da faixa pretendida já foram utilizados, e ajustar o pedido para incluir apenas os números realmente livres. Um exemplo prático: se a faixa 100 a 110 foi solicitada para inutilização, mas o número 105 já foi autorizado, o pedido correto separa em dois: 100 a 104, e 106 a 110.

Sistemas que geram o pedido de inutilização sem antes consultar o status real da numeração tendem a repetir esse erro sempre que há gaps não intencionais na sequência.

NF-e referenciada não encontrada na base da SEFAZ

A rejeição 217 acontece quando um documento referencia outra NF-e, por exemplo em uma devolução ou complemento, e a chave de acesso informada não existe na base da SEFAZ. A rejeição aponta o campo refNFe, dentro do grupo NFRefItem.

A solução envolve conferir os 44 dígitos exatos da chave de acesso, e confirmar que a NF-e referenciada foi de fato autorizada antes de ser usada como referência. Um erro de transcrição em um único dígito da chave já é suficiente para gerar essa rejeição.

Quando o erro parece da SEFAZ, mas nem sempre é

Duas rejeições desta lista retornam mensagens que soam como falha de infraestrutura da SEFAZ. Na prática, a causa real pode estar na infraestrutura do servidor, mas também pode estar no seu documento ou na sua integração. Diferenciar os dois casos é o que evita horas perdidas tentando resolver do lado errado.

Erro não catalogado

A rejeição 999 retorna um código genérico, acompanhado de uma mensagem técnica como falha de conexão com banco de dados no lado do servidor. O código não aponta um campo específico do layout, e é aí que mora a armadilha. Ele pode ter duas origens bem diferentes: um erro interno de infraestrutura do servidor da SEFAZ, ou um erro de preenchimento no próprio documento que não se encaixou em nenhum código catalogado.

Por isso a investigação tem dois caminhos. Se o serviço da SEFAZ estiver instável, a solução é capturar a mensagem completa, aguardar alguns minutos e retransmitir o mesmo documento sem alterações. Mas se o serviço estiver normal e a rejeição persistir, o mais provável é erro de preenchimento, e aí vale revisar o documento inteiro campo a campo, já que a mensagem não indica onde está o problema. Checar o status do WebService no portal de disponibilidade da SEFAZ ajuda a decidir por qual caminho começar.

Evento duplicado que a SEFAZ não localiza

A rejeição 573 aparece em eventos, como cancelamento ou carta de correção, quando o sistema detecta o evento como duplicata, mas não encontra o evento original na base. A mensagem soa como inconsistência do lado da SEFAZ, mas a causa real costuma estar na integração.

O padrão que gera essa rejeição é o seguinte. A integração envia um evento, ele é autorizado, e em seguida envia o mesmo evento de novo sem incrementar o número de sequência. O primeiro evento, que estava autorizado, acaba descartado, e o documento passa a exibir apenas o evento rejeitado. Consultar a situação da nota não resolve, porque o problema não é de processamento pendente, é de sequência repetida na origem.

A solução prática, quando isso acontece, é baixar o XML do documento diretamente na SEFAZ e reimportá-lo para reconciliar o estado dos eventos. A correção definitiva, porém, é na integração: garantir que cada novo evento sobre a mesma nota incremente o número de sequência, para não reenviar eventos duplicados. É um ajuste de código no lado de quem integra, não uma falha a aguardar do lado da SEFAZ.

Perguntas Frequentes

1. Rejeições de schema, como CST inválido ou elemento filho inválido, sempre indicam bug na minha integração?
   Na maioria dos casos, sim. Mas quando a mensagem cita tags do modelo IBS/CBS, como IBSCBS ou IBSCBSTot, o problema costuma ser de versão de schema em uso, não de lógica de negócio. Vale checar isso antes de tratar como bug comum.

2. Por que a rejeição 1035, do cálculo de alíquota efetiva do IBS, aparece mesmo quando a fórmula está certa?
   O motivo mais comum é arredondamento. O campo pAliqEfet exige exatamente 4 casas decimais. Um valor matematicamente correto, mas informado com menos casas, é rejeitado do mesmo jeito.

3. Erros de infraestrutura da SEFAZ, como falha de conexão, têm algum SLA de resolução?
   Não há SLA público documentado para esses casos. A prática recomendada é checar o portal de disponibilidade da SEFAZ, aguardar, retransmitir, e abrir chamado apenas se o erro persistir além de um intervalo razoável. Vale lembrar que, se o serviço está normal e a rejeição continua, provavelmente não é infraestrutura, e sim algo no próprio documento a revisar.

4. Rejeições de CFOP inválido em NFC-e acontecem só por erro de digitação?
   Nem sempre. Um padrão comum é a base de produtos ou regras fiscais do sistema não diferenciar corretamente entre CFOPs válidos para NF-e e para NFC-e, gerando o mesmo CFOP para os dois modelos de documento.

5. Vale a pena validar o XML contra o XSD antes de transmitir, mesmo em produção estável?
   Vale, principalmente durante períodos de transição de schema, como o que a Reforma Tributária está trazendo. Validação prévia evita boa parte das rejeições de elemento filho inválido antes que o documento chegue à SEFAZ.

6. Como priorizar a correção entre essas 10 rejeições?
   Comece separando o que é retry do que é correção. Parte das rejeições de infraestrutura se resolve apenas retransmitindo depois de uma instabilidade passageira da SEFAZ. Mas cuidado com dois casos que enganam: a rejeição 999 pode ser erro de preenchimento no documento, não instabilidade, e a rejeição 573 quase sempre exige corrigir a lógica de sequência de eventos na integração. Já as rejeições de schema e cálculo, como as ligadas ao IBS/CBS, merecem prioridade maior porque tendem a crescer em volume conforme a transição da Reforma avança.

Migrate ao seu lado em conformidade fiscal

Mapear rejeições recorrentes é trabalho contínuo, principalmente com o modelo IBS/CBS entrando em produção junto com o schema tradicional. A janela para ajustar a integração antes que o volume dessas rejeições específicas cresça é agora.

Boa parte dessas 10 rejeições se repete pelos mesmos motivos, independente do porte do cliente. Foi para tratar esse tipo de problema de forma sistemática que a Migrate desenvolveu o InvoiCy Audit Pro, um portal de validação de documentos NF-e e NFC-e. A plataforma valida o XML ou JSON do documento fiscal contra uma base de rejeições já mapeadas, e conta com a MIA, nossa inteligência artificial, para apoiar o diagnóstico de casos menos triviais. Em prosa simples, é uma camada a mais de checagem antes de o documento chegar à SEFAZ.

Referências

BRASIL. Receita Federal. Nota Técnica NF-e/NFC-e 2025.002, versão 1.36. Portal Nacional da NF-e. https://www.nfe.fazenda.gov.br

BRASIL. Receita Federal. Consulta pública de disponibilidade do Ambiente Nacional. https://www.nfe.fazenda.gov.br/portal/disponibilidade.aspx

BRASIL. Receita Federal. Tabela NCM vigente. https://www.gov.br/receitafederal

BRASIL. Rede Nacional de Sincronismo de Ponteiros (NTP.br). https://pool.ntp.br