Pular para o conteúdo
Fiscal ProBiblioteca
Rejeição 536 · Regra W09-10

Rejeição 536: total do seguro difere da soma dos itens

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 536, regra W09-10, aponta divergência entre o total de seguro da nota e a soma dos valores de seguro declarados nos itens. É uma conferência da representação monetária no XML da NF-e ou NFC-e, e não uma conclusão sobre a validade de uma apólice ou sobre quem contratou o seguro.

Onde estão o total e as parcelas de seguro

O total está em total/ICMSTot/vSeg, campo W09. Cada parcela fica em det/prod/vSeg, campo I16. A regra é facultativa nos modelos 55 e 65 e compara W09 com a soma de I16.

Seguro e frete são campos diferentes: vSeg não é vFrete, mesmo que ambos tenham sido calculados a partir da mesma entrega. A W09-10 não estabelece o filtro indTot=1 da validação de total de produtos; não exclua parcelas por importar esse critério de outra regra. Também não some automaticamente todo prêmio de uma apólice externa: a conferência desta rejeição considera as parcelas representadas na nota, cujo conteúdo precisa corresponder à operação confirmada.

Exemplo de seguro dividido entre itens

Exemplo sintético com valores assumidos apenas para conferência: três itens recebem R$ 4,80, R$ 3,20 e R$ 2,00 de seguro. A soma é R$ 10,00. Se ICMSTot/vSeg informa R$ 12,00, a diferença é R$ 2,00. Procure uma parcela omitida ou um total que corresponda a uma composição anterior; a conta, sozinha, não determina qual valor de origem está certo.

Se o terceiro item foi removido do documento, o conjunto final contém R$ 4,80 + R$ 3,20 = R$ 8,00. Manter o total antigo de R$ 10,00 cria divergência de R$ 2,00. A totalização precisa usar os itens efetivamente presentes no XML. Na serialização, use ponto decimal: 4.80, 3.20, 2.00, 10.00.

Como distinguir rateio de erro de campo

Compare o valor confirmado para a operação, as parcelas depois do rateio e os campos finais. Se o rateio gravou o seguro em vFrete por erro de mapeamento, o total vSeg pode estar correto na origem, mas o XML não contém as parcelas I16 correspondentes. A correção pertence ao mapeamento dos campos, sem trocar a natureza real da despesa.

Se um valor foi convertido de centavos para reais duas vezes, uma parcela de 250 centavos pode virar R$ 0,025 antes do arredondamento, quando a representação monetária correta dessa quantia seria R$ 2,50. Confirme a unidade da origem antes de aplicar a conversão. Não presuma que um valor pequeno é sempre efeito de arredondamento.

O que conferir sobre precisão e ausência

Os valores monetários declarados têm duas casas decimais. Some os valores que realmente foram serializados e investigue separadamente perdas no rateio. A W09-10 consultada não enuncia uma margem própria; não transporte tolerâncias de outras validações. Fechar a soma de maneira determinística é diferente de esconder uma diferença.

Se vSeg do item está ausente, confira a origem para distinguir parcela inexistente de falha de serialização. Zeros explícitos devem ser preservados quando fazem parte dos dados válidos. A 536 não decide se o seguro integra uma base tributária: para essa dúvida, reúna contratação, cobertura, operação e valores e confirme o tratamento com o responsável fiscal antes de alterar os parâmetros.

Leitura do XML e confirmação do resultado

A nota operacional depende do conjunto real de itens e do seguro confirmado. O exemplo textual reconcilia parcelas e total sem fabricar apólice, produto ou documento fiscal. 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.

Fontes oficiais