Rejeição 385: confira os dados de ST no grupo ICMSSN900

A rejeição 385 ocorre quando o documento abrangido pela regra N12a-34 utiliza CSOSN 900 e informa dados de ICMS-ST no grupo ICMSSN900. O campo apontado pela validação é ICMSSN900/modBCST, que identifica a modalidade de determinação da base da substituição tributária. Antes de remover informações, descubra se houve preenchimento indevido ou se a operação foi levada a um documento inadequado.

O contexto é a autorização de NFC-e, modelo 65. A NT 2026.002 v1.11 amplia a regra para NF-e 55 com DANFE Simplificado Tipo 2, tpImp=6. Isso torna incompleta a recomendação antiga de apenas mudar de NFC-e para NF-e: é preciso verificar também o tipo de impressão e as características fiscais da operação.

O nome correto ajuda a localizar o problema

Algumas telas e artigos abreviam o grupo como “ICMS900”. No XML da regra, o nome é ICMSSN900, ligado ao CSOSN 900. Não o confunda com ICMS90, associado ao CST 90 e à rejeição 381.

O número do código tributário também importa. CST e CSOSN pertencem a classificações diferentes. Acrescentar ou retirar um zero não representa uma correção válida. Regime do emitente, classificação do item e estrutura do XML precisam ser analisados em conjunto.

No retorno, localize cStat 385 e nItem. Depois, confira o item correspondente no XML transmitido. A posição pode ser diferente do código do produto no estoque. Trabalhar sobre outro item deixa a causa original intacta e ainda pode alterar uma tributação que estava correta.

Presença do campo não é só valor do imposto

N12a-34 é marcada como obrigatória e identifica a informação de dados de ST por modBCST dentro de ICMSSN900. Por isso, zerar a base ou o imposto não é uma solução suficiente quando a estrutura continua sendo enviada.

Também não basta deixar uma caixa visual vazia. O ERP pode preencher a tag automaticamente a partir de uma natureza de operação, de um cadastro compartilhado ou de uma regra importada. A prova da correção está no XML regenerado, não apenas na aparência da tela. Apagar modBCST isoladamente e manter os demais campos da sequência pode gerar erro de schema; a estrutura inteira precisa permanecer coerente.

A análise deve distinguir destaque de ST nessa estrutura e imposto cobrado em etapa anterior. A mensagem 385 não declara que mercadorias sujeitas à substituição tributária jamais possam ser vendidas ao consumidor. Ela identifica uma combinação concreta de grupo, campos e documento. O eventual uso de CSOSN 500 exige fundamento próprio; não é uma troca automática para qualquer item rejeitado.

Antes de corrigir, confirme duas coisas

Primeiro, o CSOSN 900 é fiscalmente adequado à operação e admitido no contexto estadual? Na lista geral de N12a-20, sua aceitação é uma exceção a critério da UF. O fato de o sistema oferecer o código não comprova a permissão.

Segundo, os dados de ST precisam existir nessa operação? Se foram gerados por engano, o responsável fiscal pode validar sua retirada e o suporte deve corrigir a origem da geração. Se forem necessários, o procedimento exige revisar o documento e o enquadramento aplicáveis, sem suprimir imposto devido.

Uma aceitação estadual de CSOSN 900 não dispensa N12a-34. Da mesma forma, a ausência da rejeição 383 não representa autorização para preencher livremente o grupo ICMSSN900. Cada verificação tem seu objeto.

Exemplo: configuração indevida herdada no caixa

Uma empresa do Simples Nacional, que não é MEI, utiliza CSOSN 900 em uma situação validada por seu responsável fiscal e admitida pela UF. A regra comercial do sistema, porém, herda dados de ST de outro tipo de operação. O item enviado contém modBCST e recebe a rejeição 385.

A equipe compara a operação aprovada com o cadastro que gerou o XML. Confirmado que os campos foram acrescentados indevidamente, ajusta a regra de origem, atualiza o item e regenera o documento. Depois verifica outras mercadorias sujeitas à mesma configuração para evitar repetição.

Se a análise demonstrar que os dados de ST eram necessários, essa remoção deixa de ser uma solução. O responsável fiscal deverá orientar o documento e os campos adequados ao caso. Não se deve escolher entre manter ou apagar imposto apenas conforme o formato de nota desejado pelo atendente.

O que muda para MEI e NF-e 55

Para CRT=4 e idDest diferente de 3, há uma restrição adicional: N12a-81 aceita apenas CSOSN 102 e 300 na NFC-e. A NT 2026.002 v1.11 também aplica esse recorte à NF-e 55 com tpImp=6. Portanto, o CSOSN 900 não se torna uma opção geral para MEI nesses documentos, mesmo quando uma UF o admite em outros cenários.

Uma NF-e 55 fora do DANFE Simplificado Tipo 2 não é alcançada por N12a-34 apenas por utilizar ICMSSN900. Isso não significa que todo preenchimento esteja permitido: continuam existindo regras de regime, destinatário, finalidade e tributação. A mudança de documento deve ser fiscalmente adequada e acompanhada do preenchimento correto dos demais campos.

Cronograma sem adiamento generalizado

No MOC 7.0, a regra aparece para modelo 65. A NT 2026.002 v1.11 documenta a ampliação e a inclui no conjunto com homologação prevista para 01/07/2026 e produção para 03/08/2026.

A mesma versão adia para 14/12/2026 somente I08-180, BA02-35 e VC02-40. Não é correto concluir que a 385 foi adiada junto. O índice SVRS consultado em 10/10/2026 ressalva possíveis alterações de datas; confira o autorizador e a versão realmente utilizada.

Não há, no texto de N12a-34 examinado, a exceção histórica de emissão anterior a 01/04/2016 que aparece nas regras vizinhas de CSOSN. Não transfira uma exceção entre linhas da tabela nem altere a data de emissão para tentar utilizá-la.

Checklist para finalizar

Antes de reenviar, confirme o enquadramento aprovado, o XML corrigido e os efeitos do ERP em estoque e financeiro. Alguns produtos exigem procedimentos específicos para editar notas com lançamentos já efetuados. Evite estornos ou novas movimentações indiscriminados.

Após a transmissão, verifique o retorno de autorização e arquive o protocolo com o XML correspondente. Se surgir outra rejeição, examine a nova regra, sem concluir que toda a tributação já estava validada. Registre a causa e a correção da parametrização para que o próximo atendimento não dependa de apagar campos manualmente.

Fontes e data da conferência

Revisão em 10/10/2026; PDFs preservados em 09/10/2026: MOC 7.0, p.108, NT 2024.001 v1.20 e NT 2026.002 v1.11, pp.3,16–17, no índice SVRS. Apoio operacional lido: Oobj, Invoisys e Bling. Sugestões genéricas de trocar para modelo 55 ou remover ST foram qualificadas conforme as regras e a operação real.