Rejeição 1064: recalcule a alíquota efetiva da CBS com quatro casas

Quando aparece 1064, confira a alíquota que o sistema calculou depois da redução da CBS. A classificação pode estar correta e, ainda assim, o percentual final enviado divergir da fórmula. Para o empresário, o passo útil é pedir uma comparação entre os dados do item, a memória da conta e o XML transmitido, em vez de repetir o envio sem mudar a causa.

A mensagem oficial é “Rejeição: Valor da Alíquota Efetiva da CBS calculado incorretamente [nItem: 999]”. O trecho nItem indica o item afetado. A alíquota efetiva é um percentual; não é o valor da CBS em reais nem o percentual de redução. Essa distinção evita corrigir o campo errado.

Em qual emissão a regra aparece

Este artigo aborda a autorização de NF-e modelo 55 e NFC-e modelo 65 na UB66-10, NT 2025.002-RTC v1.52, página 50. Sua condição é a presença do grupo de redução gCBS/gRed. O campo examinado é pAliqEfet, dentro desse grupo. Outros serviços ou documentos que reutilizem o número 1064 exigem sua própria documentação.

A consulta de 10/10/2026 confirmou o aviso ENCAT de 05/10 que adiou a v1.52 para 26/10 em homologação e 16/11 em produção. A UB66-10 já consta da versão anterior e não apresenta ressalva própria de implementação futura na página examinada. O aviso não prova suspensão das regras herdadas. Confirme UF, autorizador e ambiente do retorno: não houve teste de emissão em todas as UFs nesta revisão.

A fórmula muda na compra governamental em NF-e modelo 55

O ramo com compra governamental se limita à NF-e, modelo 55. A BB01-10 veda gCompraGov na NFC-e modelo 65 e pode retornar 1006. Na NFC-e, este artigo trata do cálculo sem esse grupo; não o inclua para tentar corrigir a 1064. Confirme a operação real e o documento fiscal adequado com o responsável fiscal (NT v1.52, p. 32).

Sem informação do grupo de compra governamental, a fórmula documentada é:

pAliqEfet = pCBS × (1 − pRedAliq / 100)

Com gCompraGov informado, acrescenta-se o fator do redutor próprio:

pAliqEfet = pCBS × (1 − pRedAliq / 100) × (1 − gCompraGov/pRedutor / 100)

pCBS é a alíquota normal da CBS; pRedAliq, o percentual de redução; e pRedutor, o percentual do cenário governamental. Reduzir uma alíquota em determinada proporção não é subtrair diretamente esses números. Também não se pode somar reduções e usar a soma como se fosse o fator exigido pela fórmula.

A observação da UB66-10 exige cálculo com quatro casas decimais e arredondamento na última. A regra não declara aqui uma tolerância monetária de um centavo. Essa margem, presente em outras comparações de valores, não deve ser aplicada à alíquota efetiva. Percentual e dinheiro possuem unidades e validações diferentes.

O que conferir antes de refazer a conta

Preserve XML, retorno, horário e identificação da nota. No item informado, leia gCBS/pCBS, gCBS/gRed/pRedAliq e gCBS/gRed/pAliqEfet. Confira separadamente se existe gCompraGov e qual pRedutor foi transmitido. A conta deve partir dos dados do arquivo enviado, pois a tela atual pode mostrar uma alteração posterior.

Confirme com a equipe fiscal se o enquadramento sustenta a redução e se a compra governamental realmente se aplica. A UB65-10 valida o percentual em relação ao cClassTrib e sua observação 2 determina pRedAliq igual a zero no tratamento de compra governamental ali descrito. Resolver a fórmula não permite ignorar essa condição nem criar um redutor por conta própria.

O grupo de compra governamental possui posição própria no leiaute. Não o acrescente como um subgrupo da CBS para imitar um exemplo de tutorial. O leiaute oficial também coloca pAliqEfet dentro de gRed. Uma estrutura mal formada pode produzir erro de schema antes de chegar à comparação matemática.

Quatro causas que merecem caminhos diferentes

O cálculo subtraiu o percentual da alíquota. Uma rotina pode tentar executar “alíquota menos redução”, confundindo grandezas. Corrija o cálculo multiplicativo no emissor, mantendo os percentuais fiscalmente cabíveis. Ajustar apenas pAliqEfet manualmente deixa o defeito ativo para a próxima nota.

O sistema ignorou o redutor governamental na NF-e modelo 55. Verifique primeiro se gCompraGov foi enviado corretamente. Se o cenário for cabível, a rotina deve utilizar o segundo fator. Se o grupo foi inserido indevidamente, sua retirada exige confirmação fiscal da operação. Não marque uma venda como governamental só porque essa fórmula produz o valor desejado.

A nota conserva uma alíquota antiga. Depois de atualizar cadastro ou tabela fiscal, um pedido já preparado pode manter o resultado anterior. Compare a origem dos dados, regenere a nota rejeitada pelo fluxo adequado e examine o XML novo. Não altere operações anteriores autorizadas para reproduzir a configuração atual.

A precisão foi perdida durante a geração. A rotina pode calcular corretamente e transmitir apenas duas casas, ou truncar em vez de arredondar. Peça ao suporte os valores antes e depois da serialização. O conserto deve preservar a precisão do campo e o arredondamento da quarta casa, sem mudar base, classificação ou preço da operação.

Exemplo original de conferência

Considere um item fictício com pCBS de 0,9000% e uma redução de 60% fiscalmente cabível, sem compra governamental. O fator remanescente é 0,40. Assim, 0,9000 × 0,40 = 0,3600%. Enviar 0,5400% significaria ter usado um fator de 0,60, como se a redução fosse de 40%, diferente do dado informado.

Em um teste matemático separado de NF-e modelo 55, uma compra governamental hipotética usa pRedAliq igual a zero e um redutor didático de 12,5%. O resultado seria 0,9000 × 1 × 0,875 = 0,7875%. Esse redutor foi escolhido para ilustrar a multiplicação; não é um percentual recomendado para o cadastro, nem comprova vigência ou direito fiscal.

Para verificar a rotina de arredondamento, uma conta didática que produza 0,599985 precisa chegar a 0,6000 com quatro casas. Truncá-la em 0,5999 altera o resultado. O teste de precisão pode ser feito pelo suporte sem modificar uma operação real para reproduzir esses números.

Como confirmar a solução e quando pedir ajuda

Depois da correção, confira novamente os dados e a alíquota efetiva do XML gerado pelo emissor. Recalcule os valores que dependem dela, como CBS e eventual diferimento, e verifique os totais afetados. Corrigir o percentual sem atualizar o restante pode eliminar 1064 e revelar outra rejeição de cálculo.

Faça uma transmissão controlada e examine o retorno completo. Se autorizada, preserve XML e protocolo e confirme o vínculo com a operação. O desaparecimento do código, sozinho, não comprova autorização nem valida o enquadramento tributário escolhido.

Procure a contabilidade para discutir classificação, redução e requisitos de compra governamental. Acione o fornecedor quando houver erro de fórmula, arredondamento, campo enviado ou atualização do documento. Se a conta documental coincide com o XML e a rejeição persiste, encaminhe memória de cálculo, dados do item, arquivo, resposta, horário, UF, autorizador e ambiente. Uma divergência comprovada é mais útil ao atendimento do que uma sequência de reenvios sem diagnóstico.

Fontes

Consulta e revisão documental por IA: 10/10/2026. Sem teste operacional por UF/autorizador e sem publicação externa.

• NT 2025.002-RTC v1.52, página 50, UB66-10 e contexto UB65-10, com leiaute de gCompraGov e gRed nas páginas 17–21; página 32, BB01-10, vedação do grupo na NFC-e.

• Documentos SVRS e aviso ENCAT de 05/10/2026.

• TecnoSpeed, rejeição 1064, TaxUp, relação de regras e NCM Buscador, ficha 1064. Um tutorial e duas fichas/listagens, sem três testes operacionais independentes. Fórmulas conferidas com o documento oficial; estruturas de XML ilustrativas dessas páginas não foram copiadas.