CST no ICMS61: código 61, regime e cobrança anterior

CST dentro de ICMS61 aceita somente o texto 61. O código identifica tributação monofásica sobre combustíveis cobrada anteriormente. Não identifica origem da mercadoria, não é CSOSN e não significa simplesmente que o produto é combustível.

Como distinguir 61 de outros códigos monofásicos

A NT 2023.001 v1.60 cria alternativas distintas: ICMS02 trata tributação monofásica própria; ICMS15 combina tributação própria e responsabilidade pela retenção; ICMS53 trata recolhimento diferido; ICMS61 representa cobrança anterior. A identificação da etapa exige documentos da operação, produto/cProdANP e fundamento aplicável. A escolha não pode ser deduzida da existência de uma nota de entrada sem verificar o que ela representa.

O literal é obrigatório no grupo e não aceita 061, 60 ou 500. CST 60 e CSOSN 500 dizem respeito a contextos de cobrança anterior por substituição tributária/antecipação e não são equivalentes estruturais de 61. Para inserir 61, a alternativa deve ser ICMS61; mudar apenas o texto dentro de ICMS60 produziria uma estrutura incompatível.

O Simples Nacional pode apresentar CST 61?

N12-20/590, na NT 2024.001 v1.20, p.12, compara a informação de CST com CRT 1 ou 4, mas exclui os monofásicos 02, 15, 53 e 61. Por isso o uso comprovado de CST 61 não é afastado apenas porque o emitente pertence a esses regimes. Não se deve substituir 61 por CSOSN 102 apenas para satisfazer uma regra de CST convencional.

Na NFC-e, 61 integra a relação de N12-30/766. Na NF-e destinada a não contribuinte, integra a relação de N12-70/508, conforme pp.34–35 da NT monofásica. Pertencer à relação elimina essa incompatibilidade específica; não garante que o produto e a operação atendam às demais regras.

Exemplo: o código e seus campos dependentes

Fragmento sintético parcial, pressupondo CST 61 e origem 0 já definidos. Quantidade fictícia de 40 unidades legais e alíquota fictícia de R$ 1,25 por unidade demonstram R$ 50,00 anteriormente cobrados.

<ICMS61 xmlns="http://www.portalfiscal.inf.br/nfe">
  <orig>0</orig>
  <CST>61</CST>
  <qBCMonoRet>40.0000</qBCMonoRet>
  <adRemICMSRet>1.2500</adRemICMSRet>
  <vICMSMonoRet>50.00</vICMSMonoRet>
</ICMS61>

Origem, quantidade, alíquota específica e valor são informações diferentes. O grupo não contém vBC/pICMS/vICMS próprios de ICMS00. qBCMonoRet tem ocorrência 0–1 no XSD, mas N43a-10/769 exige a quantidade para CST 61, modelos 55/65, com produção a partir de 01/04/2024. Fonte estrutural: XSD PL 010f v1.04.

Como diagnosticar incompatibilidade de CST

Para localizar o código, use /nfeProc/NFe/infNFe/det/imposto/ICMS/ICMS61/CST e o namespace NF-e. Confira o nItem e o XML transmitido, não apenas a configuração visual do produto.

Na rejeição 959/N12-100, confronte o cProdANP real com a tabela monofásica correspondente à data. Na 960/N12-110, confira a tabela e suas alternativas admitidas, incluindo a observação que também permite CST 40/41/50/90. Nenhuma dessas regras conclui, por si, que a alternativa correta é 61.

A atualização de N12-110 na NT 2025.002 v1.52, p.37, excepciona NF-e de crédito (finNFe=5) e de débito (finNFe=6), preservando a observação de CST 40, 41, 50 e 90. Isso é exceção da validação 960, não autorização para escolher outro tratamento sem fundamento. Fonte: NT 2025.002 v1.52.

Se houver 590 apesar do código monofásico, confirme se o XML contém realmente 61, o regime e a regra aplicada pela autorizadora; preserve o retorno para investigar versão ou outra incompatibilidade. Não mude o CRT ou o cProdANP para forçar aceitação. Se a dúvida for sobre a etapa fiscal, reúna documento anterior, produto, quantidade/unidade, data, operação e regime para confirmação contábil. A integração então deve gerar o grupo correspondente à conclusão comprovada.

Qual versão sustenta esta explicação

A estrutura e os exemplos foram conferidos no PL 010f v1.04. A ficha técnica pode oferecer outras versões selecionáveis. Compare o pacote escolhido e o efetivamente usado pelo emissor; uma declaração deste pacote não deve ser atribuída automaticamente a todo XML histórico. Datas de ativação de regras, quando indicadas, pertencem à validação específica e não comprovam a implantação de um pacote em cada autorizadora.