Rejeição no Protheus: como resolver erros de NF-e
As rejeições mais comuns na emissão de NF-e pelo Protheus, o que causa cada uma e como corrigir a parametrização para destravar o faturamento.
No dia a dia de supervisores, analistas fiscais e profissionais de TI, lidar com a emissão de notas fiscais eletrônicas (NF-e) pelo Protheus pode ser desafiador. Apesar dos avanços em automação e integração, os erros e rejeições continuam presentes. Não se trata apenas de um incômodo: rejeições podem paralisar processos de faturamento, gerar retrabalho e até causar problemas com órgãos fiscais. Em nossa experiência na WeePulse, sabemos que identificar rapidamente a origem do erro e adotar soluções práticas faz toda a diferença para garantir tranquilidade ao negócio e conformidade tributária. E, com a Reforma Tributária, essa lista ganha códigos novos ligados aos campos de IBS e CBS, como a 1115 e a 1076. A 1115 chegou a ter data marcada para travar a emissão em produção, mas foi adiada: veja o que mudou no prazo da NF-e sem IBS e CBS, em que data cada documento fiscal entra no cronograma oficial até 2027 e o panorama completo no guia da Reforma Tributária no TOTVS. Há também a família ligada à classificação tributária, como as rejeições 1023 e 1024, que costuma nascer de uma tabela cClassTrib desatualizada. E há a 1111, que é o caso mais confundido de todos: ela não rejeita a nota por falta de IBS e CBS, e sim por informar o grupo de devolução onde ele não cabe, motivo pelo qual continua ativa mesmo com o adiamento. Se é essa que está travando a sua emissão, o passo a passo está em rejeição 1111 no Protheus.
Principais tipos de rejeição em notas fiscais eletrônicas no Protheus
Ao longo dos anos, acompanhamos centenas de cenários relacionados às rejeições nas emissões de NF-e no Protheus. Elas variam desde problemas técnicos até falhas ligadas à parametrização. Destacamos aqui os tipos mais recorrentes que costumam surgir:
- Erros de schema
- Campos obrigatórios não preenchidos ou preenchidos de forma incorreta
- Rejeições específicas por código (destacando: 232, 434, 452, 610, 578 e 703)
Cada tipo de rejeição traz pistas valiosas sobre seu motivo. Por isso, entender esses códigos e suas mensagens ajuda a agir rápido. Vamos detalhar cada situação:
Erros de schema
Esses erros ocorrem quando o XML da NF-e gerado pelo Protheus não segue corretamente o layout definido pela SEFAZ. Costumam ser identificados por mensagens que indicam divergência no padrão esperado. Na prática, pequenas alterações nos campos, formatos de data, casas decimais ou mudanças de layout nacional podem provocar esse bloqueio. Um exemplo frequente é tentar transmitir um documento utilizando schema desatualizado.
Campos obrigatórios
Quando algum campo obrigatório no cadastro do cliente, produto ou próprio documento fiscal está em branco ou incorreto, a SEFAZ recusa a nota imediatamente, apontando com clareza o campo faltante. Isso pode envolver informações como CNPJ, inscrição estadual, CFOP ou CST. Pequenas distrações na parametrização de cadastros são suficientes para interromper a emissão.
Até um dígito a menos pode travar toda a operação.
Rejeições por código
Alguns códigos específicos resumem em poucas palavras problemas maiores. Veja alguns exemplos e o que normalmente estão sinalizando:
- 232: Destinatário não habilitado à operação (ST)
- 434: NF-e com duplicidade de número
- 452: Data de emissão maior que a permitida
- 610: CFOP incompatível com natureza da operação
- 578: CEST obrigatório e não informado
- 703: Código do produto inválido para o segmento
- 1111: Grupo de devolução do IBS da UF informado indevidamente (ver seção dedicada abaixo)
Esses códigos sinalizam que, para além de problemas técnicos, existem inconsistências fiscais e comerciais. Atenção ao cruzamento correto de informações entre sistemas e parametrizações do Protheus faz toda a diferença aqui.
A família de rejeições por CST do IBS e da CBS
Boa parte das rejeições novas da Reforma tem uma causa raiz só: o grupo enviado no XML não bate com o que o CST daquela operação determina. Cada CST carrega indicadores que dizem se um grupo é exigido, proibido ou opcional, e o validador confere isso item a item. A 1021 significa que sobrou, a 1022 que faltou, e há variações para monofásico, transferência de crédito, diferimento e redução de alíquota. O mecanismo completo e a lista das regras estão em CST do IBS e da CBS no Protheus.
A rejeição descrita abaixo é um caso particular dessa família.
Rejeição 1111: a nota que volta por excesso, e não por falta
A rejeição 1111 merece capítulo próprio porque ela inverte a lógica de todas as outras desta lista, e porque é a que mais travou faturamento desde agosto de 2026.
A mensagem completa no monitor é: 014 - NFe não autorizada. 1111/Rejeição: Grupo de devolução do IBS da UF informado indevidamente [nItem: 1]. O número entre colchetes muda conforme o item.
Traduzindo: o seu XML está mandando um grupo de campos que aquela operação não admite. A SEFAZ valida que o grupo de devolução de tributo do IBS da UF, o gIBSUF/gDevTrib, apareça apenas nas situações permitidas. Fora delas, a nota volta.
Repare na diferença que muda tudo: a nota não foi rejeitada por estar incompleta. Ela foi rejeitada por estar completa demais.
Por que ela trava mesmo com a rejeição adiada
Este é o mal-entendido que custou caro para muita empresa. Em 3 de agosto de 2026, o Ato Técnico Conjunto nº 01/2026 adiou o início das validações de IBS e CBS. No esclarecimento de 6 de agosto, a Receita Federal e o Comitê Gestor do IBS foram explícitos: o adiamento vale para que a ausência de campos de IBS e CBS não gere rejeição automática neste momento.
A 1111 rejeita pelo motivo oposto.
| Rejeição por ausência (adiada) | Rejeição 1111 (ativa) | |
|---|---|---|
| O que dispara | Campos de IBS e CBS não preenchidos | Grupo gDevTrib preenchido onde não podia |
| Situação | Suspensa pelo Ato Técnico Conjunto nº 01/2026 | Em vigor, rejeitando |
| Efeito | A nota passa mesmo incompleta | A nota volta |
Por isso a 1111 nunca esteve no grupo de validações adiadas. Há relatos datados de 3 de agosto de 2026 descrevendo rejeição em todas as notas naquele mesmo dia, exatamente quando o mercado comemorava o adiamento. O panorama dos dois relógios está no cronograma dos documentos fiscais com IBS e CBS.
Não adianta procurar no Configurador de Tributos
A reação natural a uma rejeição com nome de tributo é abrir o Configurador de Tributos e revisar regras, TES, CST e cClassTrib. É o caminho certo para a maior parte das rejeições fiscais da Reforma, incluindo a família 1023 e 1024, que costuma nascer de uma tabela cClassTrib desatualizada.
Para a 1111, não é. A montagem do grupo gDevTrib acontece na geração do XML, no fonte, não na regra tributária. Você pode auditar o Configurador linha por linha e não vai encontrar nada, porque não há nada para encontrar ali.
A correção oficial, release por release
A correção da TOTVS tem dois componentes que precisam ser aplicados juntos: o pacote de patch e o fonte NFESEFAZ.
Pré-requisito: o fonte NFESEFAZ precisa estar com data de 29 de julho de 2026 ou superior. Fonte antigo com patch novo não resolve.
| Release do Protheus | Disponibilidade do patch |
|---|---|
| 12.1.2310 | Somente com garantia estendida |
| 12.1.2410 | Somente com garantia estendida |
| 12.1.2510 | Disponível (versão suportada) |
| 12.1.2610 | Disponível |
Junto da correção entra o parâmetro MV_2500240, do tipo data, com valor padrão 03/08/2026. Ele funciona como válvula para quem precisa de mais tempo de teste antes de valer em produção.
Atenção ao mexer nesse parâmetro. A documentação oficial é ambígua neste ponto: o texto orienta configurar a data em uma direção, mas o exemplo numérico aponta para a contrária. O caminho seguro é testar o comportamento em homologação antes de alterar em produção, e não assumir a regra por dedução.
O pacote também inclui a regra I08-141 e altera as regras I08-140, I08-144, VC02-07, VC02-10, UB18-10, UB37-10, UB56-10 e B25-80, além de criar o tipo de nota de crédito 06, Retorno por recusa parcial na entrega.
Quando o patch não resolve
Aplicou o pacote, compilou o fonte e a rejeição continua? Há dois cenários conhecidos.
Ambiente com customização no fonte. Pode aparecer erro de execução apontando incompatibilidade de tipo de parâmetro na montagem do XML de IBS e CBS, tipicamente citando GETXMLGIBSUF, com um parâmetro esperado como caractere chegando como lógico. A causa relatada em campo: a função que monta a nota espera um valor lógico em uma posição específica de um array interno, e customizações que inseriram um elemento no meio desse array empurram o valor uma posição adiante. Não se resolve reaplicando o patch, e sim reconciliando a customização com o fonte novo.
SIGALOJA. Há relatos consistentes de ambientes em que a correção resolveu a emissão pelo SIGAFAT e a rejeição continuou no SIGALOJA. Se a sua operação emite pelos dois caminhos, teste os dois.
O atalho que circula, e por que ele vira passivo
Existe uma solução circulando em fóruns: alterar o fonte para remover o bloco gDevTrib do XML antes da transmissão. Funciona, a tag some e a nota é autorizada. E é aí que mora o problema.
O grupo gDevTrib é obrigatório nas devoluções legítimas. Removê-lo indiscriminadamente significa que, quando a empresa emitir uma devolução de verdade, ela sairá sem o grupo de devolução de tributo. Você troca uma rejeição visível, que trava e avisa, por um documento autorizado e incorreto, que não avisa nada e fica na base.
Se você aplicou esse atalho para destravar o faturamento em agosto, ele ainda está no seu ambiente? Vale checar. Nota autorizada não é sinônimo de nota em conformidade.
Se você está na 12.1.2410 sem garantia estendida
É o cenário mais comum e o mais desconfortável, já que o patch oficial dessa release exige garantia estendida. O que não recomendamos é pegar fonte compilado de terceiros por e-mail ou grupo, colocando em produção um código sem procedência num módulo fiscal.
Os caminhos reais são três: contratar a garantia estendida da 12.1.2410, migrar para a 12.1.2510, que é a versão suportada, ou corrigir o fonte no próprio ambiente com quem conheça a montagem do XML fiscal e garanta que a devolução legítima continue funcionando.
Checklist para destravar a emissão
- Confirme no monitor que a rejeição é 1111 e anote o
nItemapontado - Verifique a data do fonte
NFESEFAZ, que precisa ser 29/07/2026 ou superior - Identifique a sua release e se você tem garantia estendida
- Aplique patch e fonte juntos, nunca só um dos dois
- Teste a emissão em homologação antes de liberar produção
- Teste todos os módulos que emitem, incluindo o SIGALOJA
- Se aparecer erro de tipo de parâmetro, investigue customização no array da nota, não o patch
- Se algum atalho de remoção do
gDevTribfoi aplicado, remova e valide uma devolução real - Só altere o
MV_2500240depois de validar em homologação
Causas comuns das rejeições de NF-e no Protheus
Se, para cada erro, existisse uma solução única e certa, tudo ficaria mais simples. Mas quem trabalha com rotinas fiscais sabe: as causas se multiplicam. Listamos as principais, com base nos casos que já solucionamos no dia a dia da WeePulse:
- Parametrização incorreta dos módulos fiscais
- Problemas com o certificado digital
- Inconsistências na geração do arquivo XML
- Atualizações pendentes de pacotes TOTVS
- Cadastros desatualizados de clientes, produtos ou tributações
Um erro rotineiro, por exemplo, é tentar emitir a NF-e com um certificado digital vencido. Ou então, esquecer de atualizar a tabela de CFOPs na virada de exercícios fiscais.
Entrou uma causa nova nessa lista em 2026: o CNPJ alfanumérico. Empresas abertas a partir de julho passaram a receber CNPJ com letras, e ambiente com máscara ou validação antiga simplesmente não aceita esse cadastro, o que trava a emissão antes mesmo de a nota sair. Veja o que ajustar em CNPJ alfanumérico no Protheus.

Impacto dos pacotes e schemas desatualizados
Manter o Protheus com os pacotes e schemas atualizados é mais do que uma recomendação: é pré-requisito para garantir que o sistema esteja apto a processar e emitir documentos dentro das últimas normas fiscais. Uma simples defasagem nesses arquivos pode gerar rejeições automáticas pela SEFAZ, muitas vezes com mensagens pouco claras ao usuário final. Isso porque as legislações mudam frequentemente, ajustando layouts e exigências de campos e validações.
Como usar validações internas e o CCC para solucionar pendências
O módulo de validação interna do Protheus, junto ao Centro de Consulta de Cadastro (CCC), são ferramentas preciosas para identificar rapidamente inconsistências. Sugerimos alguns passos que normalmente seguimos quando há dúvidas:
- Rodar a validação interna antes de tentar transmitir qualquer NF-e
- Verificar pendências no CCC, especialmente relacionadas a dados fiscais e cadastros
- Revisar logs detalhados no monitor de documentos fiscais eletrônicos
- Consultar o manual dos parâmetros e notas técnicas TOTVS disponíveis
Na maioria das vezes, essas validações antecipam o problema e já direcionam para o ajuste correto, evitando a recorrência de erros. A consulta ao CCC também é útil para checar a situação cadastral de clientes e fornecedores diretamente junto à SEFAZ, tornando a emissão mais confiável.
Como configurar parâmetros e campos de cadastro no Protheus para diferentes cenários fiscais
Pela nossa vivência diária, sabemos que uma das principais causas de erro é a configuração inicial ou modificações posteriores nos parâmetros do Protheus. É importante que os responsáveis pelo sistema estejam atentos ao seguinte:
- CFOP e CST corretamente atribuídos conforme o tipo de operação
- Revisão dos impostos vinculados a cada produto (ICMS, IPI, PIS, COFINS, etc.)
- Vínculo correto de clientes e fornecedores aos seus estados e situações tributárias
- Certificado digital vigente e corretamente inserido nos parâmetros do sistema
- Preenchimento dos campos obrigatórios, especialmente em mudanças de legislação
Um bom uso do Configurador de Tributos do Protheus pode ajudar imensamente nessas tarefas, trazendo clareza e documentação de todas as parametrizações feitas.
Passos para correção rápida de erros e boas práticas para prevenir rejeições
Quando surge uma rejeição na hora da emissão, agimos de forma sistemática para que a resolução seja a mais rápida possível. Nossa sugestão de roteiro, baseada em nossa experiência na WeePulse:
- Ler a mensagem de erro e identificar o código de rejeição
- Pesquisar o significado do código na documentação oficial da TOTVS e SEFAZ
- Revisar os parâmetros associados ao erro dentro do Protheus
- Checar cadastros recentes que podem estar com informações incompletas
- Verificar a validade do certificado digital
- Testar a emissão novamente após correção
Evitar retrabalho significa corrigir o erro na origem e documentar o ajuste para futuras consultas. Notamos que alguns erros se repetem porque não há um histórico registrado de soluções já adotadas. Por isso, sugerimos manter sempre um controle interno atualizado.
Exemplo prático de resolução
Vamos a um cenário comum: ao tentar emitir uma NF-e de venda interestadual, surge a rejeição “578 – CEST obrigatório e não informado”. Nesse caso, seguimos os passos:
- Entramos no cadastro do produto e adicionamos o CEST corretamente conforme tabela da SEFAZ
- Rodamos novamente a validação interna e transmitimos a NF-e
- Transmitido com sucesso. Documentamos a causa e orientação para equipe fiscal
Cada ajuste bem documentado previne o mesmo erro em lançamentos futuros. Isso faz parte da nossa rotina.
Boas práticas para evitar rejeições em NF-e
Com o tempo, percebemos que pequenas ações diárias podem evitar o acúmulo de problemas e rejeições no Protheus. Aqui estão algumas rotinas que gostamos de partilhar com nossos clientes:
Revisar regularmente os cadastros de produtos, clientes e fornecedores- Realizar testes de emissão antes do fechamento do mês ou ciclo fiscal
- Atualizar o sistema com pacotes, schemas e tabelas disponibilizadas pela TOTVS
- Fazer treinamentos periódicos para a equipe responsável pelas parametrizações fiscais
- Manter backup dos cadastros principais para consultas emergenciais
Manutenção constante evita surpresas indesejadas no faturamento.
Agindo preventivamente, conseguimos reduzir consideravelmente a incidência de erros críticos. E quando a legislação muda, respondemos com agilidade ajustando todo o ecossistema Protheus, sempre trazendo as novidades para nossos clientes antes dos prazos limites.
Recomendações para atualização e suporte técnico
No universo TOTVS, conforme vivenciamos na WeePulse, manter-se atualizado é sinônimo de segurança jurídica e operacional. Por isso, alertamos sempre nossos clientes sobre as seguintes recomendações:
- Assinar e acompanhar todos os comunicados técnicos e notas da TOTVS
- Validar a instalação correta de cada pacote ou atualização sugerida
- Consultar canais oficiais e parceiros certificados para dúvidas de implantação
- Acionar o suporte especializado sempre que a identificação do erro não for suficiente para uma correção segura
Além disso, recomendamos investir em automação fiscal, tema que abordamos em detalhes em nosso artigo sobre automatização de rotinas fiscais, trazendo ganhos para a rotina e integridade dos dados.
Como a WeePulse pode ajudar?
Nós, da WeePulse, conhecemos as dores de quem precisa garantir fluidez, integridade e agilidade na emissão de NF-e. Com nosso time, é possível ter:
- Diagnóstico rápido das causas das rejeições e bloqueios na emissão
- Implementação de boas práticas de parametrização fiscal
- Atualização contínua do ambiente com foco em segurança e compliance
- Treinamentos personalizados para suas equipes de TI e fiscal
- Outsourcing, suporte, modernização e integração do seu Protheus com outras soluções do ecossistema TOTVS
Nossa atuação é sempre sob medida, independentemente do porte ou segmento da empresa, com atenção a detalhes que fazem diferença nos custos operacionais e na imagem da organização frente ao fisco.
Quando falamos de integração de módulos e atualização tecnológica, também disponibilizamos materiais completos como nosso guia de atualização Protheus e um detalhamento de como usar o TOTVS SmartView para relatórios fiscais.
O que mais podemos aprender para melhorar o uso do Protheus?
Nossa equipe incentiva a pesquisa contínua. No nosso blog de Protheus compartilhamos soluções para dúvidas comuns e dicas práticas para obter mais dos sistemas TOTVS. Acreditamos que a colaboração com nossos clientes fortalece o ecossistema e reduz significativamente o número de falhas e rejeições nas rotinas fiscais.
Soluções compartilhadas geram resultados duradouros.
Fontes oficiais sobre a rejeição 1111
- TOTVS, Central de Atendimento: Rejeição 1111 - Grupo de Devolução do IBS da UF informado indevidamente [nItem: 999], Cross Segmentos, Backoffice Protheus
- Comitê Gestor do IBS: Receita Federal e Comitê Gestor do IBS esclarecem adiamento das regras de validação dos documentos fiscais eletrônicos, 06/08/2026
- Ato Técnico Conjunto nº 01/2026
- Ato Conjunto RFB/CGIBS nº 4, de 30/07/2026 (DOU de 31/07/2026)
Conclusão
Gerenciar e emitir notas fiscais eletrônicas no Protheus exige atenção e atualização. Observamos na prática que a maioria dos erros decorre de detalhes esquecidos: campos obrigatórios, cadastros incompletos, parâmetros mal ajustados ou falta de atualização do sistema. No ambiente TOTVS, agir preventivamente é a melhor estratégia para garantir que o ciclo da NF-e seja concluído sem obstáculos.
Se você busca tranquilidade na gestão fiscal, adotar boas práticas e contar com especialistas experientes é um diferencial valioso. A WeePulse está pronta para apoiar sua empresa, seja na resolução de rejeições, atualização do Protheus ou na implementação de novos módulos. Agende uma conversa, compartilhe seus desafios e venha descobrir como podemos somar ao seu negócio.
Perguntas frequentes sobre rejeição Protheus
O que causa rejeição no Protheus?
Rejeição no Protheus pode ser causada por parametrização incorreta, cadastros incompletos, falhas na configuração de CFOP, CST, informações fiscais, problemas com certificado digital vencido ou inválido e arquivos XML incompatíveis com o schema exigido pela SEFAZ. Atualizações pendentes e erros humanos no preenchimento de dados também são causas frequentes.
Como corrigir rejeição de NF-e no Protheus?
Para corrigir rejeição de NF-e no Protheus, é fundamental identificar o código de erro apresentado, revisar parametrizações e cadastros relacionados à mensagem, atualizar certificados e schemas, ajustar os campos obrigatórios e retransmitir a nota após as correções. Sempre mantenha um histórico das ações tomadas para futuras referêcias.
Quais são os erros mais comuns de rejeição?
Os mais comuns envolvem campos obrigatórios não preenchidos, schema desatualizado, duplicidade de número de NF-e, CFOP ou CST incompatível, ausência de CEST, datas fora do permitido, ou cadastro incorreto de cliente e produto. Esses problemas são facilmente evitáveis com revisões periódicas e atualizações no sistema.
Como evitar rejeição de nota fiscal eletrônica?
Evitar rejeição de NF-e envolve manter cadastros atualizados, revisar parâmetros fiscais, instalar os pacotes e schemas mais recentes, validar todas as informações antes da transmissão, realizar testes preventivos e capacitar as equipes envolvidas na rotina fiscal. A manutenção preventiva é indispensável.
O que significa a rejeição 1111 na NF-e?
A rejeição 1111 significa que o grupo de devolução de tributo do IBS da UF, o gDevTrib, foi informado no XML de uma operação que não admite esse grupo. É rejeição por informação enviada indevidamente, não por informação faltando.
A rejeição 1111 foi adiada junto com as outras regras de IBS e CBS?
Não. O Ato Técnico Conjunto nº 01/2026 adiou as validações que rejeitam pela ausência de campos de IBS e CBS. A 1111 rejeita pelo motivo oposto, o envio indevido do grupo de devolução, e continua ativa.
A rejeição 1111 é erro de parametrização do Configurador de Tributos?
Não. A 1111 tem origem na geração do XML, no fonte, e não na regra tributária. Revisar TES, CST ou cClassTrib não resolve, porque o grupo gDevTrib é montado na etapa de geração do documento.
Posso remover a tag gDevTrib do XML para liberar a nota?
Não é recomendado como solução. O grupo gDevTrib é necessário nas devoluções legítimas, e removê-lo da geração do XML faz com que devoluções reais saiam sem o grupo de devolução de tributo. A nota passa, mas sai incorreta.
Onde encontrar soluções para erros Protheus?
As soluções estão disponíveis em manuais oficiais da TOTVS, materiais especializados como os publicados pela WeePulse, blogs e treinamentos. No nosso blog de Protheus, disponibilizamos guias e orientações práticas para resolver diferentes tipos de erros rapidamente.
Continuar lendo
Posts relacionados
SmartView Protheus: como criar relatórios sem ADVPL
O SmartView é o gerador de relatórios do Protheus que substituiu o TReports. Veja os pré-requisitos, como instalar e como montar um relatório sem programar.
ICMS ST no Protheus: como configurar no Configurador de Tributos
Passo a passo para configurar o ICMS ST no Protheus pelo Configurador de Tributos: NCM, MVA, alíquotas, CST e perfis, para a nota não ser rejeitada.
Principais problemas no ERP Protheus e como solucionar
Confira soluções para problemas comuns no ERP Protheus da TOTVS, como lentidão, erros de customização e integrações falhas.