Rejeições fiscais
Rejeição 1173: confira por que o estorno não chegou ao item
Quando a NF-e retorna 1173, encontre o item indicado e confira o XML da tentativa rejeitada. A mensagem aponta a falta do grupo de estorno de crédito em um cenário que exige sua presença. Antes de acrescentar valores, identifique qual condição acionou essa obrigação e se ela representa a operação real.
Quando a NF-e retorna 1173, encontre o item indicado e confira o XML da tentativa rejeitada. A mensagem aponta a falta do grupo de estorno de crédito em um cenário que exige sua presença. Antes de acrescentar valores, identifique qual condição acionou essa obrigação e se ela representa a operação real.
A descrição oficial é “Rejeição: Grupo de Estorno de Crédito não informado [nItem: 999]”. O 999 é o marcador documental do número do item. Na sua investigação, use o número recebido no retorno e preserve o arquivo correspondente; uma informação existente na tela pode não ter sido transmitida.
Identifique qual condição exige o grupo
Na NT 2025.002-RTC v1.52, página 66, a UB116-20 identifica a rejeição 1173 para NF-e modelo 55. Ela trata do grupo gEstornoCred ausente quando o cClassTrib possui indicador ind_gEstornoCred=1 ou quando tpNFDebito=07, perda em estoque. [1]
São dois caminhos de obrigatoriedade. O tipo 07 é uma condição própria, não uma dispensa do grupo. Para investigar, registre a classificação enviada, o indicador correspondente e o tipo de débito. Não conclua que o grupo pode faltar apenas porque examinou um desses campos.
O alcance documental desta regra é 55. A presença indevida do grupo, examinada pela UB116-10, possui coluna 55/65, mas esse alcance não foi estendido à 1173. Confira modelo, serviço de autorização, UF, autorizador e ambiente do caso antes de aplicar a orientação.
Confira a operação antes de configurar o emissor
Peça ao responsável fiscal a confirmação do enquadramento e dos valores a estornar. O indicador da classificação orienta a presença do grupo; a rejeição não fornece uma fórmula nem determina quanto crédito foi efetivamente apropriado.
Se a situação envolve perda, reúna seus registros e os documentos relacionados aos bens. O leiaute identifica finNFe=6 como nota de débito e tpNFDebito=07 como perda em estoque. Um nome interno como “baixa” não comprova que o documento fiscal tenha essa identificação. [1]
Solicite também a conferência da tabela de classificação compatível com a emissão e registre sua versão. Não troque cClassTrib, finalidade ou tipo de débito somente para retirar a exigência. A correção deve representar os fatos, inclusive quando o cadastro anterior estava errado.
Localize a estrutura correta
O leiaute da página 27 coloca gEstornoCred, UB116, sob o grupo IBSCBS do item. Sua ocorrência estrutural é 0–1, condicionada à operação; isso convive com a obrigação da UB116-20 em determinados cenários. “Opcional no leiaute” não significa que possa ser omitido em qualquer nota. [1]
Quando o grupo existe, o leiaute prevê vIBSEstCred e vCBSEstCred, UB117 e UB118, com ocorrência 1–1 e formato monetário 13v2. A regra vizinha de valor usa a grafia abreviada vIBS/vCBS; não transforme essa abreviação em tags por tentativa.
Grupo ausente, grupo com campos faltando e valores zerados são situações distintas. Esta elaboração não abriu schemas nem validou XML operacional. O suporte deve conferir o leiaute e a versão utilizada pelo emissor, sem copiar números da tributação regular, transferência de crédito ou ajuste de competência.
Compare cadastro, cálculo e arquivo da mesma tentativa
Preserve a resposta integral, XML enviado, chave, número, série e horário. Identifique estabelecimento, ambiente e versão do emissor ou integração. Uma configuração corrigida depois pode não corresponder ao conteúdo que recebeu a rejeição.
Para cada item apontado, compare classificação, tipo de documento, memória do estorno e presença do grupo. Se a tela possui os dados e o XML não, peça ao suporte o rastreamento da geração. Verifique também se uma nota preparada antes da alteração foi reaproveitada sem atualização.
Mapeamento incompleto, configuração não aplicada ou descarte de um grupo com valores zero são hipóteses técnicas. O código não comprova nenhuma delas. Registre qual comparação demonstrou a falha antes de alterar a rotina.
Corrija segundo a causa demonstrada
A classificação está correta e exige o grupo
Com o cálculo fiscal fundamentado, revise a geração de gEstornoCred no item correspondente. Os dois valores devem vir da memória aprovada pelo responsável fiscal, com a estrutura prevista no leiaute.
Gere novamente pelo emissor e confira o arquivo final. Não substitua a classificação por outra sem estorno para encobrir uma falha de geração, nem preencha valores copiados de outra nota.
O documento corresponde a uma perda em estoque
A UB116-20 exige o grupo para o tipo 07. As exceções desse tipo às UB116-10 e UB116-30 não eliminam essa obrigação. A dispensa da condição de positividade da 1174 também não define o valor fiscal de toda perda. [1]
Mesmo se o cálculo tiver resultado zero, não descarte automaticamente o grupo obrigatório. Confirme o tratamento com o fiscal e a estrutura com o suporte. Não invente centavos para tornar um campo positivo.
O documento recebeu classificação ou tipo incorreto
Corrija o dado que não representa a operação, depois da análise fiscal. Uma operação sem perda não deve ganhar um estorno fictício porque recebeu tipo 07 por engano; uma perda real não deve ser convertida em venda para evitar a exigência.
Depois da correção, reavalie as duas condições da UB116-20. Mudar um tipo de débito incorreto não elimina uma obrigação que ainda decorra do indicador da classificação correta.
O grupo aparece no arquivo, mas o retorno continua
Confirme se o XML examinado é o que foi transmitido e se o grupo pertence ao item devolvido. Compare o arquivo final com a resposta e procure versões diferentes na integração.
Se a presença estiver comprovada e a divergência persistir, encaminhe os arquivos, horários, ambiente e versões ao suporte e ao atendimento do autorizador. Não edite XML assinado ou documento autorizado para testar uma hipótese.
Exemplo fictício
Uma NF-e possui itens com classificações distintas. Para o item 4, a equipe fiscal confirma uma classificação cujo indicador exige estorno e fundamenta os valores de IBS e CBS. A integração, porém, gera o grupo apenas para o primeiro item e omite o grupo do item 4.
A equipe compara cálculo e arquivo, identifica a seleção incorreta e corrige a integração. O novo documento inclui o grupo no item correspondente, sem trocar a classificação ou inventar perda. O exemplo ilustra uma falha possível; não comprova enquadramento, crédito ou emissão real.
Confira o resultado dentro dos limites documentais
Examine o retorno completo depois da correção. A ausência da mensagem 1173 não equivale à autorização. Preserve eventual protocolo autorizador, chave, ambiente e XML correspondente; outra rejeição deve ser investigada em seu contexto.
No cronograma histórico salvo, a UB116-20 está no conjunto v1.30: 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 herdadas. [1][2]
As capturas são de 10/10/2026. A elaboração de 12/10 usa materiais locais e não confirma implantação atual por UF/autorizador. Procure o suporte para diferença entre dados e arquivo; envolva o fiscal para enquadramento, documentos e cálculo.
Fontes
Elaboração v2 por IA em 12/10/2026, sem revisão própria, cruzada ou aprovação desta versão. Sem consulta online nova, inspeção de imagem, render, abertura de schema ou emissão.
NT 2025.002-RTC v1.52: TXT p.66/UB116-20 e UB116-30; p.65/UB116-10; p.27/UB116–118; p.18/IBSCBS; p.15/finalidade e tipo; p.5–6/cronograma. PDF somente conferido por hash.
Documentos SVRS e Avisos SVRS: corpos históricos e aviso ENCAT.
Omie: 1173: apoio específico com corpo salvo. Seus caminhos de tela e frase de sucesso não foram atribuídos ao ALRA.
Erpworks: 1174 e TecnoSpeed: RTC: apoios adjacentes, sem contar três tutoriais específicos da 1173 ou adotar configurações de outros emissores.
TOTVS 1173 e Sankhya tipo 07 da v1 não fundamentam a v2: faltam corpos/atos comprovados dessas atribuições no conjunto cotejado. O 403 histórico documentado é da URL TOTVS; nenhum HTTP foi atribuído à URL Sankhya tipo 07. A v1 e a cruzada negativa permanecem preservadas.