Rejeição 381: ICMS90 com ST na NFC-e ou NF-e com DANFE Tipo 2
Revisão editorial em 15 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 381, regra N12-34, ocorre na NFC-e modelo 65 ou na NF-e com DANFE Simplificado Tipo 2 (tpImp=6), quando o item usa CST=90 e informa dados do ICMS por substituição tributária no grupo ICMS90. A condição apontada no MOC é a presença de ICMS90/modBCST. A aceitação de CST 90 pela UF não elimina essa restrição.
Qual campo evidencia os dados de ICMS-ST
Localize det/imposto/ICMS/ICMS90/CST e det/imposto/ICMS/ICMS90/modBCST. modBCST é a modalidade de determinação da base de cálculo do ICMS-ST. Não é o valor do imposto nem a modalidade da base do ICMS próprio, chamada modBC.
A N12-34 atual é obrigatória para NFC-e ou NF-e com DANFE Simplificado Tipo 2 (tpImp=6), conforme a NT 2026.002 v1.11. Ela não exige valor positivo de imposto para caracterizar a condição descrita: um gerador que informa modBCST por padrão pode incluir o bloco de dados mesmo quando outros números ficam zerados. Compare a presença efetiva dos campos e o grupo correto, preservando a diferença entre zero e ausência.
Por que CST 90 permitido pela UF ainda pode ser rejeitado
A N12-30/766 permite CST 90 a critério da UF na relação de códigos da NFC-e ou NF-e com DANFE Simplificado Tipo 2 (tpImp=6). A N12-34 faz outra verificação, dentro do grupo. Logo, “CST 90 aceito” significa passar por uma condição de domínio, e não poder informar qualquer campo disponível em ICMS90.
Não confunda cálculo de ICMS-ST da operação com informação de retenção anterior em outros grupos, como ICMS60. Essa distinção técnica não recomenda migrar o item para outro CST: o tratamento deve estar confirmado pela operação e pelo responsável fiscal.
Exemplos de grupo padrão e decisão fiscal pendente
Cenário sintético: uma NFC-e com CST 90 confirmado para a operação é gerada por uma rotina que sempre cria os campos de ICMS-ST, incluindo modBCST, mesmo sem dado aplicável de origem. A rejeição pode ser reproduzida verificando a presença desse campo. Corrija a montagem contextual do grupo depois de comprovar quais dados pertencem ao item; não altere o XML assinado manualmente.
Em outro cenário, os dados de ST foram calculados porque a operação realmente foi parametrizada assim. A 381 não determina que o imposto deva ser apagado. Confirme a natureza da operação, o modelo documental cabível e os parâmetros tributários com o responsável fiscal antes de modificar cadastro ou grupo.
Como verificar a correção sem confundir as mensagens
Se a origem está correta e o XML contém dados extras, teste a geração do grupo com o mesmo cenário e examine os campos resultantes. Se a origem contém informação contraditória, resolva a contradição antes do gerador. Se o código completo do retorno for 382, confira também CFOP/CST, porque é outra comparação.
A 381 não calcula imposto nem define modalidade de base. Reúna modelo, UF, CST, campos de ST, produto e natureza da operação para confirmar o parâmetro pendente. Não substitua o grupo, zere valores ou mude CFOP apenas para eliminar a mensagem.
Leitura do XML e confirmação do resultado
O XML operacional de ICMS90 depende dos dados tributários reais do item. A comparação textual mostra CST e presença de modBCST sem construir um grupo fiscal com parâmetros presumidos. Localize os caminhos indicados usando o namespace oficial http://www.portalfiscal.inf.br/nfe; em documento processado, a estrutura começa em /nfeProc/NFe/infNFe, e no XML enviado, em /NFe/infNFe. Preserve o XML original e o retorno integral em acesso autorizado.
Corrija a origem comprovada no cadastro, na operação ou no gerador, conforme o diagnóstico. Gere e confira novamente o documento antes de qualquer transmissão autorizada, preservando zeros explícitos e a diferença entre ausência e valor informado. XML válido no schema não comprova autorização. Se houve timeout ou resultado incerto de tentativa anterior, esclareça o processamento antes de novo envio; quando houver autorização, preserve o documento e seu protocolo.
Alcance atual e cronograma do DANFE Tipo 2
Na redação atual, esta regra alcança a NFC-e, modelo 65, ou a NF-e, modelo 55, quando utiliza DANFE Simplificado Tipo 2 (ide/tpImp=6). Na NF-e modelo 55, o tipo de impressão é condição cumulativa; não generalize a restrição ou exigência para toda NF-e. Os exemplos desta página com modelo 65 continuam válidos dentro desse alcance. Confirme ide/mod e ide/tpImp no XML efetivamente enviado; não altere o modelo ou o tipo de impressão para contornar a regra.
A ampliação para NF-e com DANFE Simplificado Tipo 2 pertence ao recorte da NT 2026.002 com previsão de homologação em 01/07/2026 e produção em 03/08/2026. O adiamento para 14/12/2026 na versão 1.11 alcança somente I08-180, BA02-35 e VC02-40; não adia estas regras de grupos. Cronograma não comprova implantação individual pelo autorizador.
Fontes oficiais
- MOC 7.0 Anexo I — 7.00: p. 100 N12-34/N12-30; leiaute ICMS90, modBC / modBCST.
- NT 2023.001 — 1.60: p. 34 N12-30 atual.
- NT 2026.002 — v1.11: p. 3 cronograma específico do DANFE Tipo 2; p. 16 regra N12-34 e alcance; tabela do cronograma conferida visualmente.