Rejeição 1111 no Protheus: por que a NF-e trava mesmo com a rejeição adiada

Se o seu Protheus começou a receber a rejeição 1111 e a sua equipe está revisando o Configurador de Tributos há horas sem encontrar nada errado, existe uma explicação: o problema quase nunca está na parametrização. E se você leu que a rejeição da NF-e sem IBS e CBS foi adiada e não entendeu por que a sua nota continua travando, existe uma segunda explicação, mais importante que a primeira.

O adiamento perdoa o que falta. A 1111 pune o que sobra.

Este guia mostra o que a SEFAZ está validando de fato, por que a 1111 sobreviveu ao adiamento de 3 de agosto, qual é a correção oficial para cada release do Protheus e por que o atalho que está circulando em fóruns resolve hoje e cria um problema fiscal depois.

Emissão parada agora? A WeePulse atua no seu ambiente TOTVS já em operação para identificar a origem real da rejeição e aplicar a correção certa para a sua release. Falar com um especialista.

O que é a rejeição 1111

A mensagem completa que aparece no monitor é esta: 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 da nota.

Na documentação oficial da TOTVS, a descrição é direta: uma NF-e foi emitida com o grupo de devolução de tributo IBS da UF, o gDevTrib, mas essa estrutura foi informada de forma indevida segundo as regras de validação.

Traduzindo para o dia a dia: 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, referenciado como gIBSUF/gDevTrib, seja informado apenas em situações permitidas pela legislação e pelas regras de devolução de IBS. Fora dessas situações, 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.

A 1111 faz parte da leva de códigos que nasceu com a Reforma Tributária e que não existia na rotina fiscal do ano passado. Se você está mapeando as rejeições que passaram a aparecer no seu ambiente, o panorama dos códigos mais frequentes está no nosso guia de rejeição no Protheus.

Por que a sua nota trava se a rejeição foi adiada

Aqui está o mal-entendido que está custando 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 relacionadas ao IBS e à CBS nos documentos fiscais eletrônicos. No esclarecimento publicado em 6 de agosto, a Receita Federal e o Comitê Gestor do IBS foram explícitos sobre o alcance da medida: o adiamento vale de forma que a ausência de determinadas informações relacionadas à CBS e ao IBS não resulte, neste momento, em rejeição automática. Nas palavras do próprio comunicado, os documentos fiscais terão a emissão autorizada mesmo quando não contiverem todos os campos relativos à CBS e ao IBS.

O mesmo comunicado deixa claro que não houve suspensão da obrigatoriedade e que o cronograma permanece integralmente válido e sem alterações.

Ou seja: o adiamento é sobre falta de informação. A 1111 é sobre informação enviada indevidamente. São coisas opostas, e por isso a 1111 nunca esteve no grupo de validações adiadas.

	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 atual	Suspensa pelo Ato Técnico Conjunto nº 01/2026, sem data nova divulgada	Em vigor, rejeitando
Efeito prático	A nota passa mesmo incompleta	A nota volta

O campo confirma a leitura. Nos comentários do artigo oficial da TOTVS, 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.

Se você quiser o panorama completo dos dois relógios que estão correndo em paralelo, ele está no nosso cronograma dos documentos fiscais com IBS e CBS, e o contexto do que mudou no prazo está em NF-e sem IBS e CBS.

Não adianta procurar no Configurador de Tributos

Este é o ponto que faz a diferença entre resolver em uma hora ou perder o dia.

A reação natural de quem recebe 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 dúvida aparece textualmente nos comentários do artigo oficial da TOTVS, alguém pergunta se aquilo é erro de parametrização do Configurador ou do fonte que monta o XML, e a pergunta fica sem resposta. A resposta é: é do fonte. A montagem do grupo gDevTrib acontece na geração do XML, não na regra tributária. Você pode auditar o Configurador de Tributos linha por linha e não vai encontrar nada, porque não há nada para encontrar ali.

O nosso guia do Configurador de Tributos continua valendo para o que é de fato parametrização. A 1111 não é.

A correção oficial, release por release

A TOTVS publicou a correção. Ela 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 para clientes com garantia estendida
12.1.2410	Somente para clientes com garantia estendida
12.1.2510	Disponível (versão atualmente 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, que corresponde à data de início da obrigatoriedade das novas regras em produção. 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 específico: o texto orienta configurar uma data em uma direção, mas o exemplo numérico que acompanha a orientação aponta para a direção contrária. Enquanto isso não estiver esclarecido, o caminho seguro é testar o comportamento em homologação antes de alterar o parâmetro em produção, e não assumir a regra por dedução.

O pacote também traz mudanças de validação que vale conhecer antes de subir:

• Regra incluída: I08-141
• Regras alteradas: I08-140, I08-144, VC02-07, VC02-10, UB18-10, UB37-10, UB56-10 e B25-80
• Novo 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? Você não está sozinho, e há dois cenários conhecidos.

Ambiente com customização no fonte

Depois de aplicar a correção, pode aparecer um erro de execução apontando incompatibilidade de tipo de parâmetro em uma chamada interna da montagem do XML de IBS e CBS, tipicamente citando GETXMLGIBSUF e um parâmetro que era esperado como caractere e chegou como lógico.

A causa relatada no campo é boa de saber: a TOTVS mudou o comportamento do fonte de montagem do XML fiscal, e a função que monta a nota espera um valor lógico em uma posição específica de um array interno. Ambientes que receberam customização inserindo um elemento no meio desse array empurram o valor lógico uma posição adiante, e a chamada quebra.

Isso não se resolve reaplicando o patch. Resolve-se reconciliando a customização com o fonte novo, o que exige olhar o código do seu ambiente. É exatamente o tipo de situação em que um Protheus muito customizado cobra o preço da customização em toda virada de leiaute fiscal.

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. Validar só o faturamento e liberar dá uma falsa sensação de resolvido.

A solução que circula, e por que ela vira passivo

Existe um atalho circulando em fóruns e grupos: alterar o fonte para remover o bloco gDevTrib do XML antes da transmissão. Funciona. A tag some, a validação não dispara e a nota é autorizada.

E é justamente aí que mora o problema.

O grupo gDevTrib é obrigatório nas operações de devolução legítimas. Removê-lo indiscriminadamente da geração do XML significa que, quando a sua empresa emitir uma devolução de verdade, ela vai 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.

O próprio autor do paliativo, no artigo oficial da TOTVS, alerta que se trata de socorro imediato e que a remoção precisa ser desfeita, porque devoluções precisam da tag.

Se você aplicou esse atalho para destravar o faturamento em 3 de agosto, ele ainda está no seu ambiente? Vale checar hoje. Nota autorizada não é sinônimo de nota em conformidade, e essa distinção é a lição central deste momento da Reforma.

Se você está na 12.1.2410 sem garantia estendida

Este é o cenário mais comum e o mais desconfortável. O patch oficial da 2410 exige garantia estendida, e boa parte das empresas que estão nessa release não tem.

O que não recomendamos: pegar fonte compilado de terceiros por e-mail ou grupo, prática que apareceu várias vezes nos comentários do artigo oficial. Você coloca em produção um código sem procedência, sem saber o que mais foi alterado nele, num módulo fiscal.

Os caminhos reais são três:

1. Contratar a garantia estendida da 12.1.2410 para voltar a receber atualizações oficiais.
2. Migrar para a 12.1.2510, que é a versão atualmente suportada. Vale olhar isso como decisão de ciclo de vida, não como reação à rejeição, porque toda nova fase do cronograma da Reforma vai repetir esse impasse. O nosso guia de atualização do Protheus ajuda a dimensionar o esforço.
3. Corrigir o fonte no seu ambiente, com quem conheça a montagem do XML fiscal e consiga garantir que a devolução legítima continue funcionando.

A terceira opção destrava rápido, mas só é segura com validação em homologação e com o registro do que foi alterado, para não virar dívida técnica na próxima nota técnica.

Checklist para destravar a emissão

1. Confirme no monitor que a rejeição é 1111 e anote o nItem apontado
2. Verifique a data do fonte NFESEFAZ, precisa ser 29/07/2026 ou superior
3. Identifique a sua release e se você tem garantia estendida
4. Aplique patch e fonte juntos, nunca só um dos dois
5. Teste a emissão em homologação antes de liberar produção
6. Teste todos os módulos que emitem na sua operação, incluindo o SIGALOJA
7. Se aparecer erro de tipo de parâmetro na montagem do XML, investigue customização no array da nota, não o patch
8. Se algum atalho de remoção do gDevTrib foi aplicado em agosto, remova e valide uma devolução real
9. Só altere o MV_2500240 depois de validar o comportamento em homologação

Como a WeePulse ajuda

A 1111 é um caso exemplar do que a gente faz todo dia: uma rejeição cuja causa está em um lugar diferente de onde todo mundo procura, num ambiente que já está em operação e não pode parar.

Atuamos em Protheus, RM e Datasul já implantados, com:

• Diagnóstico da origem real da rejeição, separando fonte, customização e parametrização
• Aplicação da correção certa para a sua release, com validação em homologação
• Reconciliação de customizações com fontes novos a cada nota técnica
• Suporte e sustentação (AMS) para as próximas fases do cronograma da Reforma
• Revisão do ambiente fiscal antes das datas, e não depois da nota travar

Se o seu faturamento está parado agora, ou se você aplicou um paliativo em agosto e quer saber o que ele deixou para trás, fale com um especialista.

Perguntas frequentes sobre a rejeição 1111

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. É uma 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 documentos pela ausência de campos de IBS e CBS. A 1111 rejeita pelo motivo oposto, o envio indevido do grupo de devolução, e por isso 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.

Como corrigir a rejeição 1111 no Protheus?

Aplique o pacote de correção da TOTVS correspondente à sua release junto com o fonte NFESEFAZ com data de 29 de julho de 2026 ou superior. Os dois precisam ser aplicados em conjunto, e a emissão deve ser testada em homologação e em todos os módulos que emitem nota.

Apliquei o patch e a rejeição continua. O que pode ser?

Os dois cenários mais relatados são customização no fonte que desloca a posição de um valor lógico no array da nota, o que gera erro de tipo de parâmetro na montagem do XML, e ambientes em que a correção funcionou no SIGAFAT mas não no SIGALOJA.

Posso remover a tag gDevTrib do XML para liberar a nota?

Não é recomendado como solução. O grupo gDevTrib é necessário nas operações de devolução legítimas, e removê-lo da geração do XML faz com que devoluções reais sejam emitidas sem o grupo de devolução de tributo. A nota passa, mas sai incorreta.

Estou na release 12.1.2410 sem garantia estendida. O que fazer?

O patch oficial da 12.1.2410 exige garantia estendida. As alternativas são contratar a garantia, migrar para a 12.1.2510, que é a versão atualmente suportada, ou corrigir o fonte no próprio ambiente com validação em homologação. Pegar fonte compilado de terceiros sem procedência não é uma opção segura para um módulo fiscal.

Fontes oficiais

• 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)
• TDN TOTVS: Ciclo de Vida de Software, TOTVS Linha Protheus