Rejeição 1174: encontre o estorno zerado no item da NF-e

Ao receber a 1174, localize o item apontado no retorno e compare seus valores de estorno com o cálculo fiscal. O grupo pode estar presente enquanto os valores não atendem à condição exigida. A tarefa inicial é descobrir o que foi enviado, não escolher uma quantia para fazer a mensagem desaparecer.

A descrição documental é “Rejeição: Valor do IBS ou da CBS deve ser maior que zero no estorno de crédito [nItem: 999]”. O marcador 999 representa o número do item na mensagem da regra. Use o número efetivamente devolvido na sua tentativa para encontrar a linha correta.

A condição que pertence à 1174

A NT 2025.002-RTC v1.52, página 66, identifica a UB116-30 para NF-e modelo 55. Quando o grupo gEstornoCred está informado, o valor de IBS ou o de CBS deve ser maior que zero. Pelo menos um positivo atende a essa condição de valor; não se exige que ambos sejam positivos ao mesmo tempo. [1]

Essa comparação não calcula o estorno devido e não confirma o direito ao crédito. Os dois valores precisam corresponder à operação e ao cálculo fundamentado pelo responsável fiscal. Uma quantia positiva sem fundamento não representa uma correção.

Não estenda a 1174 à NFC-e modelo 65: a coluna dessa regra informa 55. Registre UF, autorizador, ambiente e versão do emissor. A linha documental não nomeia uma UF específica, mas sua leitura não comprova implantação atual em todos os ambientes.

Grupo permitido, obrigatório e com valor são questões diferentes

Antes de recalcular, confirme por que o grupo foi incluído. A UB116-10, na página 65, trata de sua presença quando o indicador da classificação o veda; a UB116-20, na página 66, trata da ausência quando ele é obrigatório. A 1174 examina a condição de valor do grupo já informado. [1]

Apagar um grupo obrigatório pode levar a outro problema. Colocar valor positivo em um grupo indevido também não corrige o enquadramento. Solicite ao fiscal a verificação da classificação utilizada e da operação real, sem escolher outro código tributário apenas para mudar o retorno.

Reconheça os campos no arquivo

A redação da UB116-30 usa gEstornoCred/vIBS e gEstornoCred/vCBS, com os identificadores UB117 e UB118. O leiaute da página 27 nomeia esses campos vIBSEstCred e vCBSEstCred, dentro de gEstornoCred. A diferença de grafia entre regra e leiaute precisa ser respeitada. [1]

No item, procure o grupo em imposto/IBSCBS/gEstornoCred. Não copie os valores de transferência de crédito, ajuste de competência ou tributação regular porque também aparecem como IBS e CBS.

O leiaute indica ocorrência 1–1 dos dois valores quando o grupo existe, com formato monetário 13v2. Valor zero, elemento ausente e grupo ausente são situações distintas. Esta elaboração não abriu schemas nem validou XML operacional; o suporte deve conferir a estrutura e a versão realmente utilizadas pelo emissor.

Faça a comparação com a mesma tentativa

Separe XML transmitido, resposta integral e memória do estorno por item. Guarde número, série, chave, horário, estabelecimento e ambiente. Confira se o arquivo pertence à tentativa rejeitada, pois uma tela alterada depois pode mostrar outro conteúdo.

Para o item indicado, anote os dois montantes do cálculo fiscal e os dois gravados no grupo. Se houver diferença, peça o rastreamento entre cálculo e geração do XML. Configuração, integração, campos vazios ou arredondamento são hipóteses de investigação, não causas comprovadas pela mensagem.

Peça também que o suporte explique como trata as casas decimais. Não acrescente R$ 0,01 por tentativa nem importe tolerância de outra rejeição. Corrija um erro demonstrado, preservando os valores verdadeiros.

Escolha a correção conforme a evidência

O cálculo tem estorno, mas o arquivo contém zeros

Se a memória fiscal confirma valor positivo e o grupo enviado apresenta ambos zerados, investigue a leitura dos dados e o mapeamento para os campos próprios. A correção deve transportar os montantes fundamentados, sem compensar a diferença em preço, quantidade ou outro tributo.

Gere novamente o documento pelo fluxo do emissor e compare o arquivo final. Uma mudança na configuração não garante que um XML preparado anteriormente tenha sido atualizado.

Somente um tributo tem valor positivo

Confirme com o responsável fiscal que essa composição está correta. Para a condição da UB116-30, não é necessário criar estorno no outro tributo apenas para torná-lo positivo. Isso não dispensa os demais campos e validações nem comprova autorização.

Ambos os valores zero refletem o cálculo

Mantenha a memória do resultado e peça a análise do documento, da classificação e do cabimento do grupo. Não invente um centavo nem exclua o grupo sem verificar sua obrigação. A mensagem não decide, sozinha, qual tratamento fiscal deve substituir a tentativa.

A operação é realmente perda em estoque

A UB116-30 tem exceção expressa para tpNFDebito=07. O leiaute identifica 07 como perda em estoque e finNFe=6 como nota de débito. A UB116-20 continua exigindo o grupo nesse cenário. A exceção afasta esta condição de positividade; não declara que toda perda deve apresentar valores zero. [1]

Confira os campos e os documentos da perda. Não transforme outra operação em perda para alcançar a exceção. Se a identificação estiver correta e o retorno persistir, encaminhe o XML e a resposta ao suporte para conferir ambiente e versão.

Exemplo fictício

Uma empresa prepara NF-e para uma operação cujo cálculo de estorno foi fundamentado pelo fiscal. No item 2, a memória indica IBS de R$ 9,45 e CBS de R$ 0,00. A integração, porém, grava ambos como 0,00 no grupo de estorno.

A comparação identifica um campo de origem vazio. O suporte corrige o mapeamento e o novo arquivo passa a apresentar os valores da memória. Não cria CBS positiva nem muda a operação para perda. O exemplo ilustra uma falha possível; não estabelece fórmula, direito fiscal ou resultado de emissão real.

Confira o próximo retorno e o calendário aplicável

Depois da correção, acompanhe a resposta completa. O desaparecimento da 1174 não equivale à autorização. Quando houver resultado autorizador, preserve protocolo, chave, ambiente e XML correspondente. Evite editar XML assinado ou documento autorizado.

No cronograma salvo, a UB116-30 está enumerada no conjunto v1.30 com homologação até 24/11/2025 e produção em 02/02/2026. O aviso ENCAT de 05/10/2026 remarca as atualizações enumeradas da v1.52 para 26/10 em homologação e 16/11 em produção; não demonstra suspensão geral das regras anteriores. [1][2]

As capturas são históricas, de 10/10/2026. A elaboração de 12/10 usa materiais locais e não confirma implantação atual por UF. Acione o suporte para divergência entre cálculo e arquivo; envolva o fiscal quando faltar fundamento para o estorno.

Fontes

Elaboração v2 por IA em 12/10/2026. Sem revisão própria, cruzada ou aprovação desta versão; sem nova consulta online, inspeção de imagem, render, teste XSD ou emissão.

1. NT 2025.002-RTC v1.52: TXT salvos p.66/UB116-30 e UB116-20, p.65/UB116-10, p.27/UB117–118, p.15/finalidade e tipo de débito, p.5–6/cronograma. PDF apenas conferido por hash nesta elaboração.

2. Documentos SVRS e Avisos SVRS: corpos históricos, versão e aviso ENCAT de 05/10/2026.

3. Erpworks: rejeição 1174: corpo específico salvo, tratado como apoio; procedimentos do Protheus não foram atribuídos ao ALRA.

4. TecnoSpeed: RTC e ATVI: v1.52: apoios adjacentes, sem contar três tutoriais específicos da 1174 ou adotar suas datas gerais como implantação desta regra.

Sankhya e TOTVS da v1 não fundamentam esta nova redação: não foi recuperado corpo comprovado para suas atribuições no conjunto cotejado. Os registros de falha histórica, a v1 e sua cruzada negativa permanecem preservados em fontes.v2.json; não se afirma inexistência universal dessas páginas.