Rejeição 730: NFC-e com Inscrição Suframa

A rejeição 730 indica que a NFC-e contém a Inscrição Suframa do destinatário, informação que não deve ser enviada nesse documento. Confira o XML transmitido e procure o campo ISUF dentro de dest. O preenchimento pode ter vindo de um cadastro utilizado também na emissão de NF-e, mas a origem precisa ser confirmada antes de qualquer alteração.

Resolver o retorno não significa apagar uma inscrição verdadeira do cliente. A correção depende de duas verificações: se a NFC-e é o documento adequado à operação e se sua geração incluiu indevidamente o campo. Preserve o cadastro e os documentos que sustentam o tratamento fiscal da venda.

Qual é a regra da rejeição

A regra E18-10 do MOC 7.0, Anexo I, página 87, associa o código 730 à presença da Inscrição Suframa em dest/ISUF na NFC-e, modelo 65. Ela está classificada como obrigatória. O quadro não condiciona esse retorno a um valor mínimo, a um benefício destacado ou a um dígito verificador incorreto.

O caminho completo do campo é infNFe/dest/ISUF. Não confunda essa informação com dest/IE, a Inscrição Estadual, ou dest/IM, a Inscrição Municipal. Também não remova dados da empresa emitente: o grupo apontado pela regra é o do destinatário.

Essa distinção orienta o diagnóstico. Trocar os dígitos de ISUF, substituir a inscrição por zeros ou tentar corrigir seu tamanho não resolve a presença indevida na NFC-e. O procedimento deve impedir a inclusão do campo no documento em que ele não é permitido, desde que o modelo escolhido corresponda à operação real.

O que a mensagem não comprova

O código 730 não declara que a inscrição do cliente foi cancelada, que seu cadastro está irregular ou que ele perdeu um benefício. A condição verificada é a presença do dado naquele modelo. A situação cadastral e o enquadramento tributário exigem suas próprias verificações.

Na mesma página do MOC, a regra E18-20 trata do dígito verificador da Inscrição Suframa na NF-e modelo 55, com código 235. Já a E18-30, também para o modelo 55, trata da relação entre inscrição informada e UF ou município do destinatário, com código 251. Esses diagnósticos não devem ser apresentados como a causa da 730.

A NT 2025.002 v1.52, página 36, também apresenta a E18-30 no contexto da NF-e. Isso não amplia para a NFC-e a possibilidade de informar ISUF. Tampouco transforma uma inscrição existente em comprovação de direito a incentivo em toda operação realizada com aquele cliente.

Confirme o documento antes de retirar o campo

Uma informação cadastral pode ser necessária em determinada NF-e e indevida em uma NFC-e. Por isso, uma rotina que copia todos os campos do cliente para qualquer documento merece revisão. Excluir a inscrição do cadastro geral pode comprometer operações futuras em que esse dado seja necessário.

Se a venda foi preparada com tratamento relacionado à Suframa, consulte o responsável fiscal antes de retirar a inscrição. A análise deve considerar o documento adequado e os requisitos reais da operação. Não abandone uma exigência fiscal nem altere produtos, valores, tributação ou destinatário apenas para conseguir transmitir um cupom.

Se for necessário outro documento, a emissão deve seguir o procedimento definido para esse cenário. Não transforme uma NFC-e em NF-e editando o modelo no XML ou na chave de acesso. O emissor precisa gerar o documento correto, com sua estrutura, identificação e assinatura correspondentes.

Como investigar a origem do preenchimento

Separe o XML enviado e a resposta completa do autorizador. Anote chave, número, série, horário, ambiente e UF. Confirme que a mensagem e o arquivo pertencem à mesma tentativa; um XML visualizado depois da correção pode ser diferente daquele que recebeu a rejeição.

Verifique mod=65 e a presença de dest/ISUF. Compare o conteúdo com o cadastro do cliente, os dados importados e a configuração usada pela integração. A existência do número na tela não prova que ele foi transmitido; da mesma forma, ocultar um campo na tela não garante sua ausência no XML.

Identifique se houve cópia automática, uso de um valor padrão, associação ao cliente errado ou confusão entre inscrições. Essas são hipóteses de investigação, não conclusões produzidas pelo código 730. Corrija apenas a causa demonstrada pelos dados da tentativa.

Ajuste e retransmissão

Confirmada a adequação da NFC-e à venda, ajuste a geração específica do modelo 65 para não enviar ISUF do destinatário. Preserve a inscrição verdadeira no cadastro usado pelas demais operações. Se a informação veio de uma integração, confira também a transformação realizada entre a entrada dos dados e o XML final.

No ALRA, encaminhe o XML e o retorno ao suporte quando não estiver claro qual rotina incluiu a inscrição. A orientação deve ser baseada no arquivo e na configuração realmente utilizados, sem reproduzir nomes de menus de outros emissores. Dúvidas sobre o documento ou o benefício devem ser tratadas com o responsável fiscal.

Após o ajuste, gere novamente o XML pelo emissor e confira o conteúdo antes da transmissão. Não altere manualmente um arquivo já assinado. Se uma tentativa anterior ficou sem resposta conclusiva, esclareça sua situação antes de criar outra nota para a mesma venda.

Exemplo de correção fundamentada

Uma loja fictícia recebe 730 em uma NFC-e após importar um cliente que possui Inscrição Suframa. A equipe identifica dest/ISUF no arquivo transmitido e confirma que a integração copiou esse campo do cadastro compartilhado com a NF-e.

Se a análise fiscal confirmar que a venda pode ser documentada por NFC-e, a equipe corrige a geração desse modelo e conserva o cadastro verdadeiro. Se a operação exigir outro tratamento, resolve essa necessidade antes de retirar a informação. O exemplo não concede benefício nem determina o documento adequado apenas pela existência da inscrição.

Como conferir o resultado

Compare o arquivo gerado com a resposta da nova tentativa. Se a 730 persistir e ISUF não estiver no XML examinado, verifique fila, ambiente, horário e eventuais transformações posteriores. Comprovada a divergência, envie as evidências ao suporte e, quando necessário, ao atendimento do autorizador.

Na conferência documental de 15 de outubro de 2026, não foi identificada nas atualizações examinadas uma dispensa expressa da E18-10. Calendários de outras regras não devem ser usados para afastá-la. A saída da rejeição 730, isoladamente, também não garante autorização: confirme o resultado efetivo e preserve o XML com protocolo quando autorizado.

Fontes

• MOC 7.0, Anexo I — páginas 15 e 87, campo E18 e regras E18-10, E18-20 e E18-30.

• NT 2025.002 v1.52 — página 36, regra E18-30 para NF-e e documentação SVRS.

• Apoios operacionais confrontados com a regra oficial: Oobj, TecnoSpeed e Dynamicca.