Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 381 · Regra N12-34

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