Rejeição 385: ICMSSN900 com ST na NFC-e ou DANFE Tipo 2

A rejeição 385, regra N12a-34, verifica NFC-e com CSOSN 900 e informação de ICMS-ST, identificada pela presença de ICMSSN900/modBCST. O problema é a combinação de modelo, grupo e campo no item; reduzir um valor de imposto a zero não elimina a informação que dispara essa regra. MOC, página 108 A NT 2026.002, versão 1.11, amplia esta mesma regra para NF-e 55 com DANFE Simplificado Tipo 2, tpImp igual a 6. NT 2026.002, página 16

Nesta página: Qual campo precisa ser localizado? · Aceitar CSOSN 900 também permite sua informação de ST? · Exemplo: valor zerado com modalidade ainda exportada · Como verificar a solução técnica?

Qual campo precisa ser localizado?

No XML original, confirme modelo 65, ou modelo 55 com ide/tpImp igual a 6, e localize NFe/infNFe/det/imposto/ICMS/ICMSSN900/modBCST no item indicado pelo retorno. modBCST é a modalidade de determinação da base do ICMS-ST. Não é modBC, que trata da base do ICMS próprio, nem pMVAST, que informa um percentual de margem quando aplicável.

A N12a-34 é obrigatória nesse contexto de modelo 65 ou modelo 55 com tpImp igual a 6. Ela não depende de uma comparação de valor de vICMSST maior que zero: o enunciado identifica a informação por modBCST. Um campo preenchido com zero continua presente. Não extrapole essa vedação para todo grupo ICMSSN900 em qualquer modelo. MOC, leiaute ICMSSN900 e N12a-34

A ampliação para o modelo 55 depende do DANFE Simplificado Tipo 2; não vale para toda NF-e indistintamente. O cronograma dessa atualização indica homologação em 01/07/2026 e produção em 03/08/2026, sem comprovar ativação individual de um autorizador. NT 2026.002, páginas 3 e 16

Aceitar CSOSN 900 também permite sua informação de ST?

Não. A N12a-20 permite a aceitação de 900 na NFC-e a critério da UF. A N12a-34 examina especificamente a presença da informação de ICMS-ST nesse grupo. São verificações diferentes: uma permissão do código não dispensa a restrição de campos.

Também não confunda ST calculada na operação, com modBCST e vICMSST, e ICMS cobrado anteriormente, representado por campos de retenção anterior em outros grupos. Trocar o grupo apenas para evitar a mensagem seria uma decisão tributária sem evidência. MOC, páginas 107–108 e leiautes do ICMS

Exemplo: valor zerado com modalidade ainda exportada

Cenário sintético: a configuração interna deixa a modalidade da base de ST preenchida e o emissor exporta modBCST no ICMSSN900 de uma NFC-e. O valor de ICMS-ST foi zerado por outra rotina, mas modBCST permaneceu. A condição da 385 continua representada no XML.

Compare a presença do campo em três pontos: configuração vigente, objeto enviado ao gerador e XML assinado submetido. Se o tratamento confirmado não comporta essa informação e a origem já a exclui, a persistência no arquivo pode indicar reaproveitamento de objeto ou serialização. Se a operação efetivamente exige informação incompatível com o documento, confirme o enquadramento e o documento cabível com o responsável fiscal; não apague informação verdadeira. O exemplo textual é suficiente para distinguir presença de zero, sem fabricar nota operacional.

Como verificar a solução técnica?

Preserve o original e o retorno completo. Corrija a origem comprovadamente divergente do tratamento confirmado, regenere e compare o grupo inteiro, não apenas o valor final. Verifique que campos de ST não foram herdados de outro item.

Não altere CSOSN, modelo ou valores reais para forçar aceitação. Não edite XML assinado ou documento autorizado. Em resultado de envio incerto, confirme o estado da tentativa antes de repeti-la; a eliminação da 385 não garante aprovação das demais validações.

Fontes oficiais

• MOC 7.0 Anexo I — versão 7.00: pp. 107–108 N12a-20/N12a-34; leiaute ICMSSN900 e grupos de retenção anterior.
• Autorização com alerta e estrutura do protocolo — versão NT 2026.002 v1.11: p. 3 cronograma; p. 16 regra específica ampliada; p. 17 N12a-81.