Rejeição 1066: confira o CST dentro da tributação regular

Sua nota pode ter o CST principal corretamente preenchido e ainda receber a rejeição 1066. O problema apontado está em outro campo: o CST informado dentro do grupo de tributação regular do IBS e da CBS. Antes de alterar produtos, valores ou o enquadramento principal, localize o item e compare esse campo com a tabela oficial.

O retorno é “Rejeição: CST do IBS e da CBS informado no grupo de tributação regular inexistente [nItem: 999]”. O nItem identifica o item rejeitado. A mensagem não afirma que a empresa é inexistente nem que seu cadastro na SEFAZ está irregular: a existência verificada é a do código tributário informado.

Dois CSTs com funções diferentes

O item possui a situação tributária principal em IBSCBS/CST. Quando o enquadramento exige a demonstração da tributação regular, existe também IBSCBS/gIBSCBS/gTribRegular/CSTReg. Este segundo código identifica a tributação de referência demonstrada no grupo, caso não seja cumprida uma condição resolutória ou suspensiva.

Confundir esses campos pode levar a uma correção no lugar errado. Mudar o CST principal para um código que não exige o grupo pode descaracterizar a operação. Copiar o CST principal para CSTReg também não é uma regra geral: a tributação de referência deve ser definida para o caso concreto pelo responsável fiscal.

A NT 2025.002-RTC v1.52 estabelece a regra UB69-10, página 52, para autorização de NF-e modelo 55 e NFC-e modelo 65. Quando gTribRegular é informado, a regra verifica se CSTReg existe na Tabela de Indicadores de CST do IBS e CBS. Trata-se de um controle de existência do código, e não de comprovação completa da correção fiscal da operação.

Como reconhecer o problema no arquivo enviado

Separe o retorno completo da SEFAZ e o XML efetivamente transmitido. Registre modelo, ambiente, data, autorizador e item. Uma mensagem apresentada por um validador interno também deve ser identificada como tal: o número exibido pelo software, sozinho, não comprova que a SEFAZ recebeu aquele arquivo.

No item apontado, localize gTribRegular e veja o conteúdo de CSTReg. Compare o valor com a configuração fiscal de origem e com a tabela oficial. A consulta atual feita em 10/10/2026 contém, por exemplo, o CST 000, denominado Tributação integral. Sua presença demonstra que o código existe; não o transforma em escolha automática para qualquer tributação regular.

Confira o valor como código textual. Os zeros iniciais fazem parte da representação de códigos como 000, 010 e 011. Uma integração que transforma códigos em números e depois exporta “0” em vez de “000” pode criar uma falha de formato. Essa falha deve ser examinada pelo suporte, mas não se deve afirmar que sempre retornará 1066: a validação de esquema pode impedir o processamento antes da regra fiscal.

Verifique ainda qual tabela a integração consulta. CST de ICMS, PIS, COFINS ou CSOSN não substitui o domínio do IBS/CBS. Códigos numericamente parecidos podem existir em uma tabela e faltar em outra, ou ter significado diferente.

Correção por cenários

O CST regular foi digitado incorretamente. Peça ao responsável fiscal o código correto e sua justificativa. Corrija a parametrização que alimenta o documento, mantendo a operação real. Não escolha o primeiro código disponível apenas porque a tabela o aceita. Depois, confira cClassTribReg, alíquotas e valores regulares para evitar um conjunto contraditório.

A integração buscou outra tabela tributária. O suporte deve rastrear a transformação entre o cadastro, o cálculo e a geração do XML. O ajuste precisa fazer CSTReg receber a situação de IBS/CBS definida para a referência regular. Preserve os registros anteriores para demonstrar a causa. Uma correção somente na tela da nota pode deixar o erro reaparecer nas próximas emissões.

O código foi perdido ou substituído durante a exportação. Compare o valor antes da geração com o conteúdo do arquivo transmitido. Verifique zeros iniciais, campos padrão, regras de preenchimento e conversões. Corrija a origem da transformação e gere novamente o documento pelo emissor. Não remende um XML assinado, pois seu conteúdo e a assinatura precisam corresponder.

A tabela interna está desatualizada. Confira a publicação oficial utilizada e a data de atualização do sistema. A equipe deve carregar dados consistentes e verificar se a classificação aplicável ao documento continua permitida. Não atribua automaticamente a divergência a atraso da SEFAZ: primeiro comprove os valores enviados e as versões comparadas.

O grupo foi informado sem ser cabível. A presença de gTribRegular é uma decisão ligada ao indicador da classificação principal. Retirar o grupo somente será adequado se a análise fiscal confirmar que ele não deve constar. Quando é exigido, removê-lo pode gerar 1065; quando é vedado, sua inclusão é examinada pela 1114. A correção da 1066 não consiste em ocultar o campo que está errado.

Exemplo original de uma falha de integração

Uma distribuidora fictícia prepara uma NF-e cujo enquadramento exige tributação regular. A contabilidade definiu a referência tributária, mas uma integração importou para CSTReg um código mantido em sua tabela interna de ICMS. O grupo foi enviado e a SEFAZ retornou 1066 no item 4.

A equipe compara o cadastro fiscal aprovado com o XML e identifica a origem trocada. Corrige o mapeamento para o domínio do IBS/CBS e regenera a nota. O teste de conferência verifica o CST regular, a classificação regular e os cálculos; produto, quantidade e destinatário não são modificados para contornar a validação. O exemplo não determina qual CST usar: essa decisão pertence ao enquadramento verdadeiro da operação.

Resultado e encaminhamento

Confirme que o novo XML contém o valor aprovado pelo fiscal em CSTReg e que ele existe na tabela oficial pertinente. Confira também o item apontado e eventuais outros itens afetados pela mesma integração. Registre a comparação antes/depois, a versão utilizada e o novo retorno.

Se a 1066 desaparecer e surgir 1067, o próximo diagnóstico é a existência de cClassTribReg. Se aparecer erro de cálculo, examine o tributo e a regra indicados. Eliminar uma rejeição não assegura autorização, nem prova que todas as informações estão certas.

Acione o suporte para divergência entre tela e XML, erro de domínio ou atualização da tabela. Acione o contador para definir a tributação de referência ou revisar o enquadramento. Se o código oficial, a configuração e o XML coincidirem e o autorizador continuar rejeitando, encaminhe evidências ao atendimento fiscal da UF correspondente.

Vigência e limites deste diagnóstico

Em 10/10/2026, a versão atual localizada na lista SVRS é a v1.52, publicada em 01/10. O aviso ENCAT de 05/10 adiou a implantação anunciada dessa versão para 26/10 em homologação e 16/11 em produção. A UB69-10 já constava em versões anteriores e não traz nota individual de implementação futura na página 52. O aviso não demonstra suspensão dessa regra herdada. Sua aplicação deve ser confirmada pelo retorno real, considerando UF, autorizador e ambiente; não houve teste de emissão nesta revisão.

Fontes

Consulta e revisão documental por IA: 10/10/2026.

• NT 2025.002-RTC v1.52, UB69-10 e regras vizinhas, p.52.

• SVRS: tabela oficial CST/cClassTrib, documentos atuais e aviso ENCAT de 05/10/2026.

• Migrate: rejeição 1066, NS7: rejeição 1066 e Buscador NCM: gTribRegular e campos. São três publicadores distintos; o terceiro apoia a estrutura e as regras, sem substituir a tabela oficial ou definir o CST de uma operação.