NF-e
Rejeição 1144: confira os dois grupos de compras governamentais no XML
Se a NF-e retornou 1144, confira se o documento identifica a compra governamental e, ao mesmo tempo, envia a composição tributária correspondente nos itens. A rejeição aponta um bloco de IBS e CBS presente sem o grupo que identifica a operação governamental. Antes de preencher ou excluir informação, confirme qual…
Se a NF-e retornou 1144, confira se o documento identifica a compra governamental e, ao mesmo tempo, envia a composição tributária correspondente nos itens. A rejeição aponta um bloco de IBS e CBS presente sem o grupo que identifica a operação governamental. Antes de preencher ou excluir informação, confirme qual operação a empresa está documentando.
A mensagem preservada na NT 2025.002-RTC v1.52 é “Rejeição: Grupo de informações da composição do valor do IBS e da CBS em compras governamentais informado indevidamente [nItem: 999]”. O item indicado no retorno ajuda a localizar o bloco. O marcador 999 é da mensagem documental, não um produto fixo a procurar.
O que a regra verifica
A UB82a-30, página 53, está indicada para NF-e modelo 55, no conjunto de regras de validação para autorização da nota. Ela combina gCompraGov não informado com gTribCompraGov informado indevidamente no item, grupo identificado como UB82a. [1]
Os nomes parecidos representam informações diferentes. No leiaute da página 17, gCompraGov pertence ao grupo de compras governamentais, ligado à identificação da nota. A página 22 descreve gTribCompraGov como a composição do valor do IBS e da CBS em compras governamentais, na tributação do item.
Portanto, informar a composição em um item não substitui a identificação da operação no documento. Uma tela marcada como “compra governamental” também não comprova que gCompraGov foi enviado no XML.
A linha da 1144 não determina CST numérico, alíquota, percentual de redução ou direito tributário. Tampouco autoriza classificar uma venda comum como compra governamental apenas para eliminar o retorno. Este guia não estende a condição à NFC-e 65, NFS-e ou eventos homônimos.
Distinga a 1144 dos retornos próximos
Na página 52, a 1141/UB82a-10 examina gCompraGov presente e a composição gTribCompraGov ausente. A 1144 trata da situação inversa de presença dos dois grupos.
A 1142/UB82a-20, página 53, compara as somas de valores quando gTribCompraGov foi informado. A tolerância de 0,04 dessa comparação não é uma solução para a 1144. Zerar valores ou ajustar centavos não faz um grupo presente desaparecer.
A exceção relacionada a ind_gIBSCBS=0 aparece na continuação da UB82a-10, fora do quadro UB82a-30. Não a transplante para a 1144. As regras de monofasia que seguem na página também têm contextos próprios e não definem esta incompatibilidade.
Reúna evidências antes de alterar a nota
Preserve o XML transmitido, o retorno integral, a chave, o horário e o item indicado. Registre UF, autorizador, ambiente e versão do emissor. Identifique homologação e produção separadamente; uma resposta de um ambiente não comprova o comportamento do outro.
Confira no arquivo efetivamente enviado a ausência ou presença de gCompraGov. Depois, localize gTribCompraGov nos itens. Compare o conteúdo com a tela, os dados gravados e a configuração utilizada na geração.
Peça ao responsável fiscal a confirmação do enquadramento. Nome do cliente, descrição do cadastro ou seleção de uma opção na interface não bastam para definir o tratamento da operação. Examine os documentos e os fatos que sustentam a classificação.
Investigue cópia de uma nota anterior, importação, parâmetro compartilhado ou transformação da integração. São hipóteses a verificar, não causas comprovadas para toda ocorrência. O suporte deve demonstrar de onde veio o bloco e por que a identificação não chegou ao XML.
Corrija conforme o cenário demonstrado
A operação não é uma compra governamental
Se a análise fiscal confirma que esse enquadramento não pertence à operação, localize a configuração que incluiu gTribCompraGov. Corrija a origem do preenchimento e regenere o documento pelo emissor.
Retirar o bloco indevido não significa apagar todos os dados de IBS e CBS. Preserve as informações tributárias efetivamente necessárias à operação. Evite um ajuste global que remova a composição também de documentos que precisam dela.
A compra governamental é real, mas sua identificação não foi gerada
Com a operação confirmada, confira os dados que devem alimentar gCompraGov. O leiaute descreve informações como tipo de ente, redução e tipo de operação com o ente governamental. Elas devem decorrer da análise fiscal e da documentação, não de valores escolhidos por tentativa.
O suporte precisa corrigir a origem da omissão e conferir a geração completa. Não inclua o grupo apenas para tornar coerente um cálculo que ainda não foi validado. Identificação, composição e demais requisitos precisam representar o mesmo fato.
A tela e o cadastro estão corretos, mas o arquivo diverge
Compare a seleção atual com os dados conservados na nota. Um documento preparado antes de uma atualização pode guardar uma configuração antiga; uma integração também pode sobrescrever informações durante a geração.
Corrija o ponto demonstrado, gere um novo XML e confira os dois grupos. Não edite manualmente um arquivo assinado nem copie dados de outra operação autorizada. A eliminação da primeira rejeição não demonstra que o restante do documento está correto.
Exemplo fictício
Uma empresa prepara uma NF-e 55 de venda comum, com enquadramento confirmado pela contabilidade. A nota não possui gCompraGov, mas um modelo de importação copiado de uma operação governamental inclui gTribCompraGov no item 2. A combinação corresponde à 1144.
A equipe confronta a configuração com o XML, encontra a inclusão indevida e corrige o modelo usado para aquela operação. Regenera o documento, preservando os tributos pertinentes à venda e sem acrescentar uma identificação governamental artificial.
O caso é hipotético. Ele ilustra uma origem possível do erro, sem determinar CST, percentual ou benefício. Se a operação fosse realmente governamental, a investigação e a solução documental seriam diferentes.
Vigência, resultado e escalonamento
A base é a v1.52 salva na pesquisa compartilhada de 10/10/2026, com publicação registrada em 01/10. O aviso ENCAT de 05/10 preservado anuncia 26/10 em homologação e 16/11 em produção para as atualizações citadas; não comprova suspensão das regras herdadas ou ativação particular da UB82a-30. [2]
Nesta elaboração de 12/10 houve leitura local e inspeção real dos PNGs documentais 52 e 53 já salvos. Não houve consulta online, emissão ou validação XSD. Confirme a aplicação concreta com o autorizador e o ambiente envolvidos.
Após corrigir, confira o novo arquivo e a resposta integral. A 1144 pode desaparecer e outra inconsistência ser apontada. Só registre autorização quando houver resultado válido e protocolo da chave correspondente.
Acione o suporte quando configuração e geração divergirem; a contabilidade quando houver dúvida sobre o enquadramento; e o autorizador quando persistir incompatibilidade demonstrada entre retorno e condição documentada. Encaminhe as evidências preservadas, evitando novas tentativas sem causa identificada.
Fontes
Primeira elaboração documental por IA: 12/10/2026, sem revisão própria, cruzada ou aprovação nesta etapa. Consultas/capturas são históricas de 10/10; a inspeção atual dos PNGs existentes não é renderização nova nem recuperação de atos individuais antigos. Sem teste operacional por UF, direito fiscal individual ou funções ALRA comprovados.
NT 2025.002-RTC v1.52, página 53, UB82a-30; páginas 17 e 22 para os grupos; página 52 para a distinção da 1141. PNGs 52/53 inspecionados; demais campos cotejados em TXT.
Documentos oficiais SVRS e Avisos SVRS, conforme registros compartilhados de 10/10; seção de validações no TXT da página 30 e notas gerais no da página 6.
Capturas locais de TecnoSpeed, panorama RTC e Tax360, versões RTC: apoios gerais adjacentes, sem três tutoriais específicos da 1144 demonstrados. Não fundamentam direito, cálculo individual ou menus do ALRA; proveniência e limites em fontes.v1.json.