Rejeição 1176: confira os itens que formam o total de IBS estornado

Se a nota retornou 1176, peça uma conferência dos valores de IBS estornado no XML enviado. A divergência está entre uma soma dos itens e o total correspondente do documento. Antes de mudar qualquer valor, descubra qual versão do arquivo foi transmitida e quais linhas entraram no cálculo.

A mensagem documental é “Rejeição: Total do IBS estornado difere da soma dos itens”. Esse retorno não informa que o preço da venda está errado, não calcula o crédito fiscal da empresa e não mostra, sozinho, qual item provocou a diferença. A investigação precisa separar a rubrica fiscal específica dos demais valores.

Qual soma pertence à 1176

No texto salvo da NT 2025.002-RTC v1.52, página 71, a W59f-10 identifica o código 1176 para NF-e modelo 55 e NFC-e modelo 65. Ela relaciona o total do IBS estornado à soma dos campos de IBS do grupo de estorno informados nos itens. Modelo e mensagem vêm dessa linha, sem inferência pelo número. [1]

IBS e CBS devem ser conciliados separadamente. Na mesma página, a W59g-10, código 1177, trata da CBS estornada. O IBS regular também tem totalização própria, distinta do estorno. Não some crédito presumido, diferimento, monofasia ou transferência de crédito somente porque seus nomes parecem próximos.

Uma soma correta não comprova que o estorno deveria existir naquela operação. A necessidade e a permissão do grupo dependem de condições próprias. Se a dúvida está no enquadramento ou no direito ao crédito, envolva o responsável fiscal antes de ajustar o arquivo.

Como reconhecer os campos sem criar uma tag

Há uma diferença de nomenclatura nos materiais salvos. A redação da W59f-10 usa gEstornoCred/vIBS. No leiaute da página 27, o campo do item é vIBSEstCred, UB117; no total da página 30, aparece o mesmo nome em W59f. Ambos pertencem ao respectivo grupo gEstornoCred. [1]

Para a conferência, diferencie o valor do item, em IBSCBS/gEstornoCred, do valor total, em IBSCBSTot/gEstornoCred. O suporte deve conferir o leiaute e a versão efetivamente usada pelo emissor, sem renomear tags por tentativa ou copiar uma abreviação da regra para o XML.

Esta elaboração não abriu pacotes de schema nem validou um XML operacional. Os nomes acima são uma identificação documental dos campos; não certificam o formato aceito em cada autorizador. Compare sempre o caminho completo, não apenas a palavra IBS.

Organize uma memória de conferência

Preserve o arquivo rejeitado, a resposta integral, chave, série, número, horário, modelo, UF e ambiente. Identifique também estabelecimento e versão do emissor. Uma tela atualizada depois da tentativa pode apresentar valores diferentes dos enviados.

Solicite uma lista simples: número de cada item, valor de IBS estornado gravado naquele item e soma final. Compare essa soma com o total de estorno de IBS no mesmo XML. Use o arquivo final da tentativa, e não um relatório preparado antes da inclusão ou exclusão de produtos.

Registre a diferença encontrada e confira itens alterados recentemente. Se a integração gerou outro arquivo depois do relatório, localize qual conteúdo chegou ao autorizador. A conferência perde utilidade quando combina itens de uma versão com o total de outra.

O leiaute apresenta valores monetários com duas casas decimais. Peça ao suporte que explique quando arredonda e como soma os valores finais. Não presuma aceitação de R$ 0,01 por existir tolerância em outra rejeição. Uma hipótese sobre cálculo interno precisa ser demonstrada nos arquivos e na memória decimal, sem alterar quantias por tentativa.

Corrija conforme o que os registros mostrarem

O total não acompanhou uma alteração dos itens

Se os valores individuais estão fiscalmente fundamentados, revise a rotina que recalcula a totalização após editar a nota. Gere novamente o documento pelo emissor e confira se o novo total corresponde às linhas finais.

Não distribua a diferença arbitrariamente entre produtos para conservar um total antigo. A correção deve representar os valores verdadeiros, não adaptar a operação ao número que ficou na tela.

Uma linha ficou fora da soma ou foi contada duas vezes

Compare a relação de itens do XML com a memória do cálculo. Um filtro pode ter excluído determinado registro, ou uma integração pode ter incluído a mesma linha duas vezes na totalização. São possibilidades, não causas comprovadas pelo código.

Peça ao suporte o rastreamento entre os itens e o campo total. Corrija a seleção ou o cálculo quando os registros demonstrarem a falha. Não crie estorno em item que não o possui apenas para alcançar a soma desejada.

O estorno de um item foi calculado incorretamente

A igualdade entre itens e total pode esconder valores fiscais errados. O responsável fiscal precisa confirmar a origem do estorno e a quantidade efetivamente cabível. Depois da correção fundamentada, recalcule o conjunto.

Não mude classificação, finalidade, preço ou outro tributo somente para eliminar a 1176. Se o problema for outra regra de preenchimento, trate-a pelo seu próprio contexto.

Foi utilizada outra rubrica ou a soma já parece conferir

Confira se o cálculo buscou IBS regular ou CBS em vez de IBS estornado. Examine os caminhos completos dos campos e a versão do documento. Se a soma do arquivo transmitido corresponde ao total e o retorno persiste, reúna a evidência para suporte e autorizador.

Não edite o XML depois de assinado nem altere documento já autorizado. A geração, a assinatura e a eventual retransmissão devem seguir o fluxo do emissor, com o histórico preservado.

Exemplo fictício

Uma empresa prepara NF-e em operação cujo estorno foi fundamentado pelo responsável fiscal. Os três itens apresentam R$ 4,18, R$ 2,09 e R$ 1,73 de IBS estornado. A soma é R$ 8,00, mas o total enviado permanece em R$ 6,27, calculado antes da terceira linha.

A equipe confirma os valores, identifica a falta de recálculo e corrige a rotina. O novo arquivo totaliza R$ 8,00 sem modificar os fatos ou os preços para combinar com o total anterior. O exemplo demonstra uma diferença aritmética; não comprova direito ao estorno, emissão real ou autorização.

Resultado e limites do calendário

Após a correção, faça uma tentativa controlada e leia o retorno completo. O desaparecimento da 1176 não equivale à autorização. Quando houver resultado autorizador, confira protocolo, chave e ambiente, preserve o XML e seu vínculo com os documentos da operação.

Leve ao suporte os arquivos, a soma por item e a diferença identificada. Procure a contabilidade para valores e cabimento. Se outra rejeição aparecer, investigue sua condição específica, sem repetir envios idênticos indefinidamente.

No histórico salvo, W59f-10 está no pacote 1.30, com homologação até 24/11/2025 e produção prevista em 02/02/2026. O aviso ENCAT de 05/10 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 herdadas. [2]

As capturas são de 10/10/2026. Esta elaboração de 12/10 usou apenas materiais locais, sem consulta online, inspeção de imagem, novo render, teste XSD ou emissão. Não comprova implantação atual por UF/autorizador. Observações futuras de outros totais não foram usadas como dispensa da conferência de estorno.

Fontes

Elaboração v2 por IA em 12/10/2026, sem revisão própria/cruzada ou aprovação desta versão. Capturas históricas e leitura atual são atos distintos.

1. NT 2025.002-RTC v1.52: TXT p.71/W59f-10, 55/65, IBS estornado; leiaute TXT p.27/UB117 e p.30/W59f, suplementos locais já existentes. PDF somente hash; nenhuma validação de schema ou observação visual nova.

2. Documentos SVRS e Avisos SVRS: corpos salvos e registros históricos; cronograma TXT p.5–6.

3. Apoios locais adjacentes: TecnoSpeed, Tax360 e ATVI. Não são três tutoriais específicos da 1176.

A referência TOTVS e a crítica editorial atribuída a ela na v1 não são usadas nesta v2: não há corpo/ato recuperável comprovado no conjunto cotejado. Não se declara inexistência universal da página. A versão anterior e sua cruzada negativa permanecem preservadas; proveniência e limites constam em fontes.v2.json.