Rejeição 536: como corrigir a totalização do seguro na NF-e

A rejeição 536 ocorre quando o seguro total da nota não corresponde à soma do seguro informado nos itens do XML. A correção começa pela comparação desses campos e pela confirmação do seguro efetivamente associado à operação. Alterar apenas o número que aparece na tela pode esconder uma falha de integração ou deixar outros totais inconsistentes.

Antes de recalcular, confirme que o retorno é “Total do Seguro difere do somatório dos itens” na autorização de NF-e ou NFC-e. Números de rejeição podem ter outros significados em documentos fiscais diferentes; o código isolado não basta para escolher o procedimento.

Onde está a diferença no XML

A regra W09-10 compara total/ICMSTot/vSeg, identificado como W09, com a soma dos campos det/prod/vSeg, identificados como I16. O primeiro pertence ao resumo da nota; os demais pertencem às linhas de produtos.

O leiaute usa duas casas decimais nesses valores. O seguro do item é um valor monetário total daquela linha. Não deve ser confundido com a taxa percentual usada comercialmente para calculá-lo, com o valor integral da mercadoria segurada ou com o frete.

No MOC, W09-10 abrange modelos 55 e 65 e tem aplicação facultativa. Não há filtro de indTot nessa linha: o indicador que seleciona valores de produtos na W07-10 não deve ser transplantado para a soma do seguro. MOC 7.0, páginas 19, 58 e 121.

A lista da SEFAZ-SP informa W09-10 ativa. Para outros autorizadores, confirme a situação aplicável. Uma regra facultativa na especificação não torna correto enviar totais incompatíveis quando não houver rejeição.

Faça uma conferência que possa ser reproduzida

Separe o XML transmitido e o retorno completo. Anote chave, modelo, ambiente, horário e versão do emissor. Em seguida, relacione todos os itens com o número da linha, seu identificador e o seguro exportado.

Some exclusivamente os valores de vSeg dos itens e compare o resultado com vSeg de ICMSTot. Não some todas as ocorrências da palavra vSeg no arquivo sem observar a hierarquia: isso incluiria o próprio total novamente.

A Dynamicca apresenta justamente a localização do seguro no XML e a comparação entre os dois níveis. Essa conferência é mais confiável para o diagnóstico do que comparar telas abertas antes e depois de uma alteração no pedido.

Exemplo: o cabeçalho manteve outro valor

Uma nota contém seguros de R$ 12,48, R$ 8,32 e R$ 4,20 nos três itens. A soma decimal é R$ 25,00. O total exportado, porém, está em R$ 26,00, produzindo diferença de R$ 1,00.

Verifique a origem dos dois valores. Se os documentos da operação confirmam R$ 25,00 e a distribuição está correta, recalcule o total desatualizado. Se o seguro real era R$ 26,00, investigue qual parcela deixou de ser representada nos itens antes de fazer qualquer ajuste.

Não existe autorização para aumentar um seguro apenas porque esse aumento faz a soma fechar. A decisão sobre o que pertence à operação deve estar documentada; o sistema deve representá-la de forma consistente.

Seguro importado sem distribuição

Um cenário comum de investigação é o pedido carregar, por exemplo, R$ 24,00 de seguro global, enquanto nenhum item recebe vSeg no arquivo fiscal. Isso pode acontecer quando a integração mapeia o total, mas não executa a distribuição.

Confirme se o valor realmente deve constar daquela nota, quais itens participam e qual critério de alocação foi definido. Em seguida, corrija o mapeamento ou a rotina de rateio. Zerar o cabeçalho para eliminar a divergência seria inadequado se a cobrança precisa permanecer documentada.

Quando um item não tem o campo opcional vSeg, não há valor informado a adicionar à soma. Isso é diferente de uma omissão indevida: o diagnóstico precisa estabelecer se aquela linha deveria receber parte do seguro. A Oobj também recomenda conferir os valores por item e corrigir a origem no emissor, usando o XML de análise apenas como evidência.

Campos manuais e atualização incompleta

Confira se algum parâmetro deixou os totais livres para digitação enquanto os itens continuaram sendo calculados automaticamente, ou vice-versa. Nesse caso, uma alteração no seguro, na quantidade ou no conjunto de produtos pode atualizar somente uma parte do documento.

A IOB documenta um cenário em que a liberação de campos manuais desativa cálculos automáticos. A lição prática é verificar quem produz cada valor: o pedido, uma integração, uma rotina de cálculo ou uma digitação. Os nomes das telas variam entre emissores.

Também confirme se o campo visual chamado “seguro” está sendo exportado para vSeg. Uma seção da interface pode reunir frete e seguro, mas isso não torna os campos fiscais intercambiáveis. Não mova a diferença para vFrete ou vOutro sem fundamento na operação.

Rateio, centavos e tributação são verificações diferentes

O rateio deve preservar o seguro real e seguir um critério justificável. A W09-10 exige coerência da soma; ela não determina que toda distribuição seja proporcional ao preço ou que o último item receba sempre qualquer diferença encontrada.

Se três itens equivalentes participam legitimamente de um seguro de R$ 7,00, uma distribuição com R$ 2,33, R$ 2,33 e R$ 2,34 soma exatamente R$ 7,00. Já três parcelas de R$ 2,33 somam R$ 6,99. O tratamento do centavo restante deve fazer parte da regra documentada do sistema, sem mudar o valor contratado.

Algumas fontes práticas mencionam tolerância de R$ 0,01. A linha W09-10 do MOC consultado não estabelece essa margem própria, portanto não conte com ela como garantia para qualquer UF ou ambiente. Procure igualdade entre os valores exportados.

A participação do seguro em bases tributárias depende das regras aplicáveis à operação. A rejeição 536, por si só, não define essa participação. Se houver mudança nos itens, revise os reflexos correspondentes com a área fiscal; não aplique automaticamente a mesma base ou alíquota a todos os produtos.

Como concluir a correção

Depois de ajustar a origem, gere novamente o XML, refaça a soma e confira os outros valores alterados pelo recálculo. Valide a estrutura, assine pelo emissor e retransmita. Guarde o retorno que confirme a autorização, caso ela seja concedida.

Se o arquivo efetivamente enviado já apresenta igualdade, envie ao suporte o XML, a resposta completa e a memória de cálculo por item. Investigue arquivos antigos, processamento de outra tentativa ou alterações feitas depois da exportação. Evite sucessivas retransmissões idênticas sem descobrir a causa.

Atualizado em 09/10/2026, com base nas fontes oficiais e práticas citadas. A conferência documental não certifica a implantação em todas as UFs nem substitui a análise fiscal da operação.