Rejeição 933: confira a MVA enviada com outra modalidade de base da ST

A rejeição 933 ocorre quando o item informa percentual de Margem de Valor Agregado do ICMS-ST, mas a modalidade enviada para determinar essa base não é MVA. A mensagem é “Informada modalidade de determinação da BC da ST diferente de MVA e informado o campo pMVAST”. O nItem indicado na resposta ajuda a localizar o produto que precisa de conferência.

Antes de apagar o percentual, descubra qual parte está errada. Pode haver uma MVA enviada indevidamente ou uma modalidade incorreta no XML. A solução precisa corresponder à tributação real, preservando os fatos da operação.

A combinação verificada pela SEFAZ

A N18-20, na página 20 da NT 2019.001 v1.70, documenta a rejeição na autorização de NF-e modelo 55. Se modBCST for diferente de 4, não deverá ser preenchido pMVAST. A linha classifica a regra como facultativa e informa que sua aplicação é opcional a critério da UF.

O MOC 7.0, Anexo I, página 111, mantém esse mesmo predicado. A existência da regra não demonstra ativação uniforme em todas as UFs e ambientes. Confira o retorno completo, o serviço utilizado e o modelo do documento; o número 933 isolado não basta para aplicar esta orientação a outro documento fiscal.

No grupo de ICMS do item, modBCST identifica a modalidade da base da substituição tributária e pMVAST identifica o percentual da MVA. Não confunda modBCST com modBC, referente ao ICMS próprio. As tabelas desses campos são diferentes: para a ST, MVA corresponde ao código 4, e não ao zero utilizado em outra tabela.

Confira o arquivo efetivamente transmitido

Guarde o XML da tentativa, a resposta completa, a chave, o horário, o ambiente e a identificação do autorizador. Localize o item pelo atributo nItem e compare a modalidade com a presença de pMVAST no grupo de tributação usado naquele produto.

Uma tela de cadastro atual pode mostrar dados diferentes dos gravados na nota. Verifique se houve importação de pedido, uso de uma regra fiscal antiga ou alteração feita depois da preparação do documento. O cadastro do produto, o pedido e o XML precisam ser analisados em conjunto.

Diminuir o percentual ou substituí-lo por zero não equivale a retirar a informação do XML. Se a modalidade correta difere de 4, uma tag pMVAST ainda presente mantém a combinação que deve ser investigada. Confira como o emissor representa um campo sem preenchimento; não presuma que uma tela zerada gerou ausência da tag.

Quando a modalidade diferente de MVA está correta

Com a modalidade confirmada pela contabilidade, investigue por que o percentual foi levado ao arquivo. Um cadastro pode conservar MVA de operação anterior, uma integração pode sempre gerar o campo ou a regra fiscal selecionada pode ter reaproveitado parâmetros incompatíveis.

Corrija a origem responsável pelo preenchimento indevido e atualize a nota rejeitada pelo fluxo do emissor. Depois confirme que pMVAST não aparece naquele grupo do item. A alteração precisa alcançar a tentativa atual e evitar a repetição em novos pedidos.

Isso não significa remover toda a tributação de ST. Base, alíquota e valores correspondentes devem continuar de acordo com o enquadramento verdadeiro. O código 933 questiona a combinação entre modalidade e MVA; ele não dispensa imposto nem determina sozinho qual modalidade usar.

Quando a modalidade deveria ser MVA

Pode acontecer de o percentual estar correto, mas a configuração gerar outra modalidade. Nesse caso, apagar MVA para satisfazer a mensagem esconderia a causa. Peça ao responsável fiscal que confirme o enquadramento e corrija a seleção da modalidade no cadastro ou na integração.

Se a conclusão fundamentada for utilizar MVA, confira modBCST=4 e o percentual aplicável no novo arquivo. A rejeição não informa qual percentual deve ser escolhido. Não use valores de exemplos, de outro produto ou de uma venda anterior sem comprovar sua aplicação à operação.

Também não altere CST, CSOSN, NCM ou CEST apenas para passar pela validação. Esses dados precisam representar o produto e a operação reais. A regra inversa, N18-10/932, verifica modalidade 4 com ausência de pMVAST; ela não é motivo para preencher MVA onde ela não cabe.

Exemplo hipotético

Uma empresa prepara uma NF-e para um produto cuja modalidade de base da ST foi confirmada como diferente de MVA. A integração conserva um percentual de configuração antiga e o envia em pMVAST, apesar de gerar modBCST diferente de 4. A resposta identifica o item com o código 933.

A equipe compara o XML com a orientação fiscal e confirma que o campo remanescente está indevido. Corrige o mapeamento, atualiza a nota e verifica a ausência de pMVAST no arquivo regenerado. Mantém a modalidade e os demais valores corretos. O exemplo não define tributação para um produto real nem garante autorização após a correção.

Aplicação facultativa e situação documental

Na consulta de 16/10/2026, a página oficial paulista de regras apresenta N18-20/933 como inativa. O registro não identifica na própria linha um ambiente específico ou uma data de implantação. Ele é uma informação documental deSP, sem autorizar conclusão sobre todas as UFs.

Se um caso concreto apresentar retorno diferente do esperado, reúna resposta, regra, versão e ambiente para esclarecimento pelo canal competente. Não atribua a tabela estadual a outra UF nem interprete a aplicação facultativa como licença para enviar dados tributários incoerentes. Esta pesquisa não certifica o comportamento operacional individual dos autorizadores.

Como confirmar a correção

Gere novamente o XML e sua assinatura pelo emissor. Não edite manualmente um arquivo já assinado. Faça a transmissão controlada depois de corrigir a causa e examine a resposta para a chave e o ambiente correspondentes.

Se houver autorização, preserve o protocolo e os arquivos. Se surgir outro retorno, investigue seu motivo específico; desaparecer o 933 não comprova autorização. O suporte deve analisar falhas de mapeamento, dados antigos ou geração indevida da tag. A contabilidade deve definir modalidade e percentual aplicáveis. Uma divergência persistente entre retorno e documentação deve ser encaminhada à SEFAZ com as evidências reunidas.

Fontes e limites

Pesquisa em16/10/2026, sem emissão ALRA, teste de autorizador, consulta de cliente real ou compilaçãoXSD.

• NT 2019.001 v1.70: HTTP20016/10 reutilizado; páginas5/20 inteiras textuais lidas. PNG20 existente realmente visto nesta sequência665/666, mesmo hash. N18-20Facult55 íntegra, sem copiar exceções de cBenefRBC. Histórico1.20 tornaN18-10/20 facultativas; não é cronograma individual atual.

• MOC7Anexo I: HTTP20015/10 reutilizado; páginas27/111 textuais completas lidas, sem alegar PNG111. Schemas oficiais, pacote010f15/10: declarações reaisICMS10/modBCST/pMVAST e tipoTDec_0302a04Opc lidas. Ausência e zero distintos; anotação do tipo diz não aceitarzero, mas pattern admite0.00, sem inferir rejeiçãoXSD universal.

• SEFAZ/SP, regras de validação: HTTP20016/10 reutilizado de929; HTMLda linhaN18-20/933/Inativa realmente extraído e lido, sem afirmar ambiente/data não explicitados ou implantação individual.

• TecnoSpeed933, WEB23–106 inteiro lido,13/03/2025, direto403 separado. O XML rotulado correto ainda contémmodBCST3+pMVAST7.00 e está incompleto; não adotado como solução.

• Omie933, WEB8–31 eHTML200 corpos inteiros lidos,29/01/2026; TOTVSLogix933, WEB54–67 corpo inteiro lido,13/12/2021, HTTPdireto403 separado. Três guias específicos lidos. VDP10068/0696, telas e nomes externos não são passosALRA; limpar percentual só após confirmar modalidade correta.

Seis caches2026 pesquisados sem932/933/N18-10/N18-20/pMVAST; busca delimitada não prova ausência global. Pauta original individualizada por hash; diretório original vazio sem artigo histórico local. Sem novas imagens, capa ou publicação.