NF-e e NFC-e
Rejeição 1069: reconcilie a base, a alíquota e as deduções da CBS do item
Se a emissão voltou com a rejeição 1069, o valor da CBS enviado em um item não corresponde à conta definida para os campos daquele item. Antes de tentar novamente, confira a base, a alíquota utilizada e os valores de diferimento e devolução tributária, quando aplicáveis. A diferença pode estar no cadastro, no cálculo…
Se a emissão voltou com a rejeição 1069, o valor da CBS enviado em um item não corresponde à conta definida para os campos daquele item. Antes de tentar novamente, confira a base, a alíquota utilizada e os valores de diferimento e devolução tributária, quando aplicáveis. A diferença pode estar no cadastro, no cálculo ou no arquivo efetivamente transmitido.
A mensagem oficial é “Rejeição: Valor da CBS difere do calculado [nItem: 999]”. O trecho nItem aponta o item a investigar. Não significa necessariamente erro em todos os produtos nem divergência no total da nota.
Entenda exatamente o que a regra compara
O contexto deste guia é a autorização de NF-e, modelo 55, e NFC-e, modelo 65. A UB67-10, da NT 2025.002-RTC v1.52, página 52, verifica o valor vCBS quando o grupo CBS, gCBS, está informado. Seu objeto é o valor da CBS do item, diferente do tributo regular da CBS em gTribRegular, tratado pela rejeição 1068. NT oficial, página 52.
Sem grupo de redução, a fórmula é:
vCBS = (gIBSCBS/vBC × (pCBS / 100)) − vDif − vDevTrib
Se houver gCBS/gRed, o cálculo deve usar a alíquota efetiva desse grupo:
vCBS = (gIBSCBS/vBC × (pAliqEfet / 100)) − vDif − vDevTrib
Assim, vBC é a base, pCBS é a alíquota da CBS e pAliqEfet é a alíquota efetiva quando informado o grupo de redução. vDif e vDevTrib representam valores monetários de diferimento e devolução tributária. Não são percentuais nem descontos comerciais. A regra admite tolerância de R$ 0,01 para mais ou para menos.
Não acrescente outras deduções à fórmula por semelhança com um manual antigo. Também não use a alíquota efetiva regular de gTribRegular: esse campo pertence a outro cálculo. A presença de grupos especiais deve ser examinada segundo suas regras próprias, sem transferir uma exceção para qualquer venda.
Faça a conferência com o documento enviado
Preserve o XML e o retorno completo antes de alterar a nota. Identifique o item, seu produto, modelo, chave, UF, autorizador, ambiente e horário. Uma resposta de homologação não comprova como o documento se comportará em produção; cada tentativa precisa ficar vinculada ao ambiente correto.
No item rejeitado, registre os campos de base e do grupo CBS. Verifique se existe gRed. Se existir, use pAliqEfet; caso contrário, use pCBS. Confira os valores dos grupos gDif e gDevTrib, quando presentes, e compare a conta com gCBS/vCBS. Observe o que o XML contém, não apenas o número exibido na tela.
Depois, confira o enquadramento com o responsável fiscal. Um cálculo pode estar matematicamente consistente e ainda usar uma base ou classificação inadequada à operação. A alíquota precisa corresponder ao período e ao tratamento fiscal cabível; não se deve adotar um percentual único para todos os itens apenas porque um exemplo usa esse número.
Quatro cenários frequentes
Há redução, mas a conta usou a alíquota sem redução
Se o XML informa gRed, a UB67-10 muda o campo utilizado na multiplicação. Uma integração que sempre calcula com pCBS pode gerar um valor maior que o esperado mesmo que a alíquota efetiva esteja escrita corretamente no arquivo.
Confirme se o grupo e a redução são cabíveis para a classificação da operação. Em seguida, corrija o cálculo para consumir pAliqEfet e recalcule o item. Se a alíquota efetiva também estiver errada, sua apuração precisa ser corrigida antes; ela possui validação própria, a 1064. Não retire uma redução legítima apenas para evitar a comparação.
O diferimento ou a devolução não entrou na conta
O valor bruto obtido pela base e alíquota deve receber as deduções previstas na fórmula. Investigue se vDif ou vDevTrib foi omitido na subtração, descontado duas vezes ou confundido com um percentual.
Peça ao responsável fiscal que confirme a existência e o valor de cada parcela. Diferimento, devolução tributária e desconto na venda têm funções distintas. Não crie uma dessas parcelas para fechar a conta nem zere um valor válido para conseguir emissão. O emissor precisa gerar os grupos coerentes com o cenário fiscal real.
A nota ficou com um cálculo anterior
Uma alteração de quantidade, valor, desconto ou cadastro pode modificar a base sem atualizar a CBS já calculada. O erro também pode ocorrer quando a tela recalcula, mas a integração exporta um valor armazenado antes da mudança.
Atualize a nota rejeitada pelo procedimento do emissor, refaça o cálculo e gere um novo XML. Se o conteúdo mudar, ele deve passar novamente pela assinatura do sistema. Compare os arquivos anterior e novo para confirmar que o item foi atualizado; editar diretamente um XML assinado não é o fluxo adequado de correção.
A divergência aparece apenas nos centavos
Confira a precisão utilizada no cálculo e os arredondamentos intermediários. Quantidades e valores unitários com várias casas podem revelar uma diferença entre a base calculada internamente e a base que foi enviada.
A conta de diagnóstico deve utilizar os campos efetivos do XML. Se a diferença ultrapassar um centavo, investigue a rotina de cálculo. Se estiver dentro da tolerância e a rejeição persistir, reúna os números e a resposta para o suporte; não atribua imediatamente o problema à SEFAZ.
Exemplo original com redução
Uma operação fictícia tem base de R$ 2.480,00, alíquota da CBS de 0,9000% e alíquota efetiva de 0,3600% em um grupo de redução considerado cabível pelo responsável fiscal. Sem diferimento ou devolução tributária, a conta com a alíquota efetiva produz R$ 8,928, expresso monetariamente como R$ 8,93.
O XML, porém, contém R$ 22,32 de CBS: a integração multiplicou a base pela alíquota de 0,9000%. A correção consiste em usar o campo efetivo já previsto no grupo de redução e regenerar o item, depois de conferir o enquadramento. Esses percentuais servem apenas para demonstrar o erro; não determinam a tributação de outra venda.
Cronograma e confirmação do resultado
Na consulta de 10/10/2026, a versão atual localizada foi a v1.52. O aviso ENCAT de 05/10 adiou sua implantação para 26/10/2026 em homologação e 16/11/2026 em produção. A UB67-10 já constava em versões anteriores e não traz nota própria de implementação futura na página 52. O adiamento não significa suspensão automática da 1069. Tampouco foi comprovada sua ativação individual em todas as UFs. Avisos oficiais SVRS.
Após corrigir, confira a fórmula no XML novo e faça o envio pelo fluxo do emissor. Leia o novo retorno: outra rejeição exige diagnóstico próprio. O encerramento depende da autorização e do protocolo correspondentes à chave correta, com o arquivo autorizado preservado.
Acione o suporte se o cálculo não chegar ao arquivo, vários itens repetirem o erro ou a comparação correta continuar rejeitada. Procure o responsável fiscal para dúvidas de base, classificação, alíquota e deduções. Envie os campos, cálculos e retornos pelo canal adequado, protegendo dados sensíveis. A correção deve reparar a informação errada, preservando os fatos da operação.
Fontes
Consulta e revisão documental por IA: 10/10/2026. Não houve teste de emissão por UF ou ambiente.
NT 2025.002-RTC v1.52, páginas 5–6, 50 e 52; UB67-10 e regra adjacente UB66-10.
Documentos SVRS e aviso ENCAT de 05/10/2026, versão e cronograma.
TecnoSpeed, rejeição 1069, Sankhya, rejeição 1069 e TOTVS, rejeição 1069, apoio prático de três publicadores distintos. A TOTVS remete também à Sankhya, portanto não são três provas técnicas independentes. Menus, versões dos produtos e generalizações de alíquota não substituem a regra oficial ou a análise fiscal da operação.