Voltar para o blog

NF-e

Rejeição 1129: confira o valor real da transferência de crédito

Uma NF-e com rejeição 1129 exige conferir o crédito tributário que a empresa pretende transferir e o valor que chegou ao XML. Guarde a remessa rejeitada antes de alterar a nota. Preencher um centavo apenas para sair do zero pode esconder uma transferência sem fundamento ou uma falha na geração do documento.

Blog ALRA
Capa ilustrada da ALRA: Rejeição 1129: confira o valor real da transferência de crédito.

Uma NF-e com rejeição 1129 exige conferir o crédito tributário que a empresa pretende transferir e o valor que chegou ao XML. Guarde a remessa rejeitada antes de alterar a nota. Preencher um centavo apenas para sair do zero pode esconder uma transferência sem fundamento ou uma falha na geração do documento.

A mensagem da NT 2025.002-RTC v1.52 é “Rejeição: Valor do IBS ou da CBS deve ser maior que zero na transferência de crédito. [nItem: 999]”. O item identificado no retorno orienta a investigação; 999 é o marcador documental, não um produto fixo. O guia trata da UB106-40, página 65, na autorização da NF-e modelo 55. [1]

Verifique o grupo e o sentido do “ou”

A condição da regra é a presença de IBSCBS/gTransfCred. Nesse grupo, o valor do IBS, gTransfCred/vIBS, ou o da CBS, gTransfCred/vCBS, deve ser maior que zero.

Se os dois valores estiverem zerados, a condição de valor positivo não é atendida. A redação usa “ou”; não transforme isso em exigência automática de dois tributos positivos. Um zero isolado precisa ser examinado junto do outro campo e da operação verdadeira.

Também não conclua que qualquer valor positivo autoriza a transferência. A regra não cria crédito, comprova saldo disponível ou define o enquadramento fiscal. O montante e o tributo precisam corresponder à documentação confirmada pelo responsável fiscal.

A página 27 identifica gTransfCred, UB106, como transferências de crédito; seus campos são vIBS, UB107, e vCBS, UB108, valores monetários 13v2. Esse crédito não é saldo comercial de cliente, desconto ou pagamento. Os nomes vIBS e vCBS aparecem em outros grupos: conferir apenas o nome final da tag não basta.

Confira a finalidade sem mudar a operação por tentativa

Na mesma página 65, a UB106-30 relaciona gTransfCred à finalidade 6, nota de débito, com rejeição 1133. A UB106-31 trata dos tipos 01, transferência de créditos para cooperativas, e 05, transferência de crédito na sucessão, com rejeição 1168. A página 15 descreve esses campos de identificação.

Essas linhas ajudam a delimitar o cenário documental; não são instruções para escolher uma finalidade ou um tipo que façam a nota passar. Confirme o cabimento real antes de ajustar o emissor. Resolver o valor da 1129 não dispensa as demais validações.

Crédito presumido da operação, ajuste de competência e estorno possuem grupos e regras próprios. Não traga seus valores para gTransfCred só porque também usam a palavra crédito ou campos de IBS/CBS.

Faça uma conferência que possa ser demonstrada

  1. Separe XML enviado, retorno completo, chave, número do item, horário, modelo, UF, autorizador, ambiente e versão do emissor.

  2. Localize gTransfCred naquele item e registre vIBS e vCBS com seus caminhos completos. Compare o arquivo rejeitado, não apenas uma tela recalculada depois.

  3. Verifique finalidade, tipo de nota e classificação com a área fiscal, sem alterar esses dados por tentativa.

  4. Confronte cada valor com a documentação que sustenta a transferência e com a origem utilizada pela integração.

  5. Peça ao suporte que mostre a passagem da origem para o XML, incluindo conversões, preenchimento padrão e formação dos valores monetários.

Se uma nova versão foi gerada após a rejeição, conserve as duas. Elas permitem distinguir uma falha do envio anterior de uma alteração posterior. Um total de tributos exibido na tela não demonstra os valores escritos dentro de gTransfCred.

Corrija conforme a causa comprovada

O valor legítimo não chegou ao grupo. Uma importação pode manter o montante na origem, mas enviar zero porque buscou o campo errado ou não reconheceu a transferência. São hipóteses a provar. Corrija o mapeamento demonstradamente incorreto e regenere a nota com os valores fiscais confirmados.

O grupo foi preenchido automaticamente sem transferência real. Verifique a configuração e a classificação que levaram à geração de gTransfCred. A decisão sobre cabimento deve partir da análise fiscal. Nem inserir um valor fictício nem retirar o grupo por conveniência resolve a origem do problema. Corrija a configuração apenas conforme a operação efetivamente documentada.

A empresa não consegue justificar o crédito informado. Reúna os documentos e encaminhe a dúvida à contabilidade antes de definir um ajuste. A mensagem de rejeição não serve como prova de direito ao crédito nem como autorização para transferir um saldo estimado.

A conversão monetária zerou o valor. Compare o dado original com o número gravado no XML. Precisão, conversão de texto e arredondamento são hipóteses técnicas, não causas presumidas. O leiaute informa duas casas decimais, mas a UB106-40 não concede tolerância para substituir zero por um valor arbitrário. Não acrescente R$ 0,01 para eliminar o retorno.

Depois de comprovar a causa, corrija a origem pelo fluxo do emissor. Não edite manualmente XML assinado ou documento autorizado. Confira também os campos e totais afetados pela regeneração.

Exemplo fictício de perda do valor na integração

Em um cenário didático, a documentação fiscal confirmada sustenta uma transferência de IBS de R$ 375,40, sem montante de CBS a transferir. A integração conserva o valor em seu registro de origem, mas grava vIBS de R$ 0,00 e vCBS de R$ 0,00 dentro de gTransfCred do item 2.

A equipe compara os registros e comprova que o mapeamento perdeu o IBS. A correção recupera R$ 375,40 no campo correto, mantendo o tratamento da CBS conforme a documentação. Não cria outro crédito para tornar ambos positivos.

O exemplo ilustra a condição de valor positivo e a rastreabilidade. Não define tipo de operação, direito ao crédito, classificação ou possibilidade de autorização atual.

Limites da versão e resultado da correção

A base é a v1.52 preservada em 10/10/2026, publicada em 01/10, com releitura local em 12/10. O aviso ENCAT de 05/10 registra datas gerais de atualização; não comprova aplicação atual da UB106-40 em cada UF ou ambiente. [2]

Na página 65, tolerância de R$ 0,01 e implementação futura aparecem nas linhas monofásicas anteriores, não na UB106-40. Não transporte essas observações nem cronogramas de outros grupos para a 1129.

Confira o XML regenerado e leia o resultado efetivo do autorizador. A ausência da 1129 não equivale a autorização ou legitimidade da transferência. Preserve protocolo e chave quando houver autorização.

Se houver valor positivo demonstrado no grupo correto e a rejeição persistir, entregue ao suporte a remessa, resposta, comparação por item, versão, UF e ambiente. Escale ao responsável fiscal quando faltarem origem, cabimento ou montante comprovados. Sem essas evidências, não altere a realidade da operação para obter aceitação.

Fontes

Elaboração textual por IA em 12/10/2026, sem revisão própria ou cruzada nesta etapa. Capturas históricas de 10/10 e leituras/abertura atuais de arquivos salvos são atos distintos. Sem novo HTTP, render, teste XSD, emissão real ou certificação de vigência por UF.

  1. NT 2025.002-RTC v1.52: página 65, UB106-40, UB106-30 e UB106-31; página 27, gTransfCred/vIBS/vCBS; página 15, finalidade e tipos de nota.

  2. Documentos SVRS e Avisos SVRS: corpos e registros históricos preservados, sem consulta online atual ou implantação individual certificada.

  3. TecnoSpeed, panorama da RTC: corpo salvo descreve gTransfCred como transferência tributária, em apoio adjacente. A busca no corpo não encontrou 1129 ou UB106-40; não há três guias específicos comprovados nesta etapa. Proveniência, hashes e limites em fontes.v1.json.

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.