Auditoria de sinistros no ERP: aviso, reserva (PSL) e pagamento

Auditar sinistros no ERP de seguros é garantir que a esteira operacional de regulação e a contabilidade financeira contem rigorosamente a mesma história. Quando um segurado ou terceiro comunica uma ocorrência coberta, nasce uma cadeia interligada: aviso do evento, constituição da Provisão de Sinistros a Liquidar (PSL), reavaliações periciais, ordens de pagamento financeiro e, finalmente, a liquidação com baixa integral da reserva técnica. Se essa integração falha, o processo é encerrado pelo analista de regulação enquanto o ERP retém saldos contábeis fantasmas ou pagamentos pendentes de baixa.

Segundo a Superintendência de Seguros Privados (SUSEP), que disciplina as provisões técnicas na Circular SUSEP nº 648/2021, a PSL deve refletir com precisão a obrigação esperada por sinistros avisados até a data-base, abrangendo indenizações, despesas com regulação e atualizações monetárias. O Manual de Práticas e Procedimentos Contábeis do Mercado Segurador e a Resolução CNSP nº 496/2026 reforçam que a gestão do passivo atuarial exige rastreabilidade estrita entre regulação e caixa. Este artigo detalha as regras de auditoria que detectam descompassos antes do fechamento.

Resumo rápido

• Todo sinistro avisado deve ter valor de perda estimado e reserva de PSL constituída no ERP na data-base do evento.
• Pagamento de indenização ou despesa não pode ocorrer sem abater ou liquidar a respectiva provisão técnica.
• Sinistro encerrado na operação com saldo residual de PSL em aberto distorce a solvência e infla o passivo da seguradora.
• Ordens de pagamento estornadas, canceladas ou devolvidas pelo banco exigem reabertura imediata da reserva ou reemissão controlada.
• Créditos com salvados, ressarcimentos e franquias deduzidas precisam estar atrelados à pasta do sinistro por chaves de negócio unívocas.

As quatro etapas do ciclo de sinistro no ERP

1. Aviso e estimativa inicial (Constituição da PSL)

Ao registrar o aviso do sinistro, o ERP deve registrar a data do evento (ocorrência), a data do aviso e vincular o processo à apólice ativa, cobertura acionada e item segurado. Nesse mesmo ato, gera-se a estimativa de perda inicial que alimenta a Provisão de Sinistros a Liquidar (PSL). Uma falha comum ocorre quando o aviso é registrado na ferramenta de atendimento ou portal de sinistros, mas a interface contábil não cria a conta patrimonial correspondente no core.

2. Regulação e reavaliação de valor

Durante a regulação, com laudos periciais, vistorias e orçamentos, o valor esperado do dano sofre revisões. O ERP deve armazenar o histórico de todas as suplementações (acréscimos) ou reduções da estimativa, registrando autor, data, justificativa e reflexo imediato na reserva. Despesas diretas de regulação (honorários de reguladores externos, peritos e custas jurídicas) devem ser segregadas conforme a nota técnica da companhia.

3. Liquidação e emissão de ordens de pagamento

Com a indenização deferida, emite-se a ordem de pagamento (OP) ou instrução bancária em favor do segurado, beneficiário ou oficina/fornecedor credenciado. A etapa crítica reside no vínculo: o pagamento precisa consumir diretamente a reserva constituída para aquela cobertura específica, deduzindo eventuais franquias e retendo tributos devidos. Pagamentos lançados como despesas gerais sem baixa da PSL geram duplicidade de impacto no balanço.

4. Baixa de reserva, salvados e encerramento

O encerramento do processo de sinistro só é legítimo quando a obrigação foi cumprida e a reserva de PSL restante for baixada para zero (reversão de saldo excedente ou quitação). Se houver expectativa de recuperação por salvados (venda do bem sinistrado) ou ressarcimento contra terceiros causadores do dano, tais expectativas devem ser registradas em contas transitórias auditáveis até a efetiva entrada em caixa.

Um processo de sinistro com status "encerrado" no painel operacional não significa nada se o ERP mantiver contas a pagar abertas ou reserva técnica remanescente.

Por que a auditoria de sinistros encontra tantas divergências

• Desacoplamento de sistemas: muitas companhias utilizam plataformas especialistas de regulação de terceiros que se comunicam com o ERP financeiro (como o i4pro) por lotes assíncronos. Falhas de integração deixam sinistros encerrados em um lado e abertos no outro.
• Pagamentos parciais sem ajuste de reserva: quando há indenização parcial ou pagamento de indenização com despesas em momentos distintos, o financeiro baixa o valor pago, mas a regra de recomposição da reserva não recalcula o saldo remanescente.
• Estornos bancários silenciosos: se uma transferência bancária (TED/PIX) para a oficina falha por dados bancários incorretos, o valor retorna ao caixa da seguradora, mas o sinistro permanece fechado na operação, deixando um credor sem receber e uma conta contábil sem conciliação.
• Honorários e custas sem chave de sinistro: notas fiscais de advogados e peritos lançadas diretamente no módulo de contas a pagar sem o número do sinistro ou apólice, impossibilitando a apuração do custo real por evento.
• Reserva técnica negativa: pagamento efetuado com valor superior à reserva previamente cadastrada, gerando saldo invertido de PSL quando o sistema não impede a inconsistência por trava prévia.

Matriz de classificação de exceções em sinistros

• Sinistro encerrado com PSL > 0: criticidade crítica. Passivo atuarial superavaliado. Ação: apurar se houve pendência documental real ou se faltou comando de estorno/reversão da reserva.
• Sinistro encerrado com OP aberta: criticidade crítica. Risco financeiro e judicial. Ação: verificar se a ordem de pagamento foi retida pelo compliance financeiro ou se foi cancelada sem cancelamento do encerramento.
• Pagamento realizado sem baixa em PSL: criticidade alta. Duplicação de efeito de sinistralidade no resultado mensal. Ação: vincular a OP ao registro de reserva e reprocessar o lote contábil.
• Reserva de sinistro sem movimentação há mais de 180 dias: criticidade média. Sinistro estagnado sem laudo ou decisão. Ação: acionar equipe de regulação para atualizar o status pericial ou encerrar administrativamente.
• Salvado recebido em caixa sem baixa no controle operacional: criticidade média. Ativo não conciliado. Ação: cruzar valor depositado no extrato com a pasta do sinistro e atualizar o saldo da recuperação.

Exemplo prático: a reserva fantasma que distorce o fechamento

Considere uma apólice de seguro empresarial em que ocorreu um vendaval com danos ao telhado e estoque. O processo transcorre com os seguintes lançamentos hipotéticos:

• 1. Aviso registrado em 10/05 com estimativa de prejuízo de R$ 80.000,00 → PSL constituída em R$ 80.000,00;
• 2. Vistoria técnica realizada em 25/05 apura prejuízo real coberto de R$ 65.000,00 com franquia obrigatória de R$ 5.000,00 a cargo do segurado;
• 3. Indenização líquida devida aprovada: R$ 60.000,00;
• 4. Em 15/06, o financeiro emite pagamento de R$ 60.000,00 ao segurado e o analista altera o status da pasta para "Encerrado".

Se a rotina do ERP der baixa na reserva apenas pelo montante pago (R$ 60.000,00) e não executar a reversão automática do saldo restante (R$ 20.000,00 da estimativa inicial não consumida), o sistema acumulará R$ 20.000,00 de PSL aberta indefinidamente para um sinistro já arquivado. Em uma carteira com centenas de ocorrências, esse descompasso pode inflar o passivo atuarial em milhões de reais, comprometendo a margem de solvência exigida pela SUSEP.

A fórmula básica de controle contínuo sobre a pasta é: PSL Inicial + Suplementações − Reduções − Pagamentos Efetuados − Reversões = Saldo de PSL. Ao status "Encerrado", a regra deve exigir que o saldo resultante seja rigorosamente zero.

Passo a passo para auditar sinistros de forma contínua

1. Mapeie os elos da cadeia. Identifique as tabelas e entidades do ERP onde residem: aviso, reservas, reavaliações, ordens de pagamento, notas de prestadores e encerramento.
2. Exija a chave de negócio única. Nunca permita que um pagamento de sinistro transite sem o número do sinistro, número da apólice, código da cobertura e beneficiário cadastrados.
3. Valide a precedência das datas. A data da ocorrência deve ser menor ou igual à data do aviso, que deve ser anterior ou igual à data de liquidação e pagamento.
4. Cruze ordens de pagamento contra o extrato. Toda ordem emitida deve ser comprovada por débito em conta liquidado pelo banco. Se houver estorno, o sinal de alerta deve ser disparado.
5. Automatize o rastreio de processos encerrados. Rode verificações periódicas buscando qualquer sinistro marcado com status de encerramento que ainda mantenha saldo na conta de PSL ou no contas a pagar.
6. Controle prazos da Resolução CNSP 496/2026. Monitore a contagem de 30 dias para manifestação de cobertura e os 30 dias para liquidação/pagamento após a entrega dos documentos essenciais.

Como o Kitopus apoia a auditoria de sinistros

O Kitopus conecta-se de forma somente leitura ao banco de dados da operação de seguros (como bases SQL Server do i4pro) e executa rotinas contínuas de checagem. A plataforma detecta automaticamente sinistros encerrados com pendências financeiras, apura divergências entre reservas e pagamentos e calcula o impacto financeiro envolvido.

Para aprofundar os impactos da regulação recente de sinistros, leia nosso artigo sobre a Resolução CNSP 496/2026 e a operação de sinistros. Se você busca regras preventivas para o core de seguros, conheça o guia de como encontrar inconsistências no i4pro e veja nossa solução comercial de auditoria contínua no ERP i4pro e software de auditoria para seguros.

Limites e governança

A reconciliação de dados operacionais e financeiros não substitui o juízo atuarial nem as decisões do comitê de regulação e jurídico. A metodologia de constituição de PSL por estimativa individual ou estatística segue a Nota Técnica Atuarial registrada pela seguradora. O papel da auditoria de dados é apontar quebras de integridade, atrasos no repasse e saldos sem contrapartida, assegurando que a equipe atue tempestivamente antes da consolidação regulatória.

Perguntas frequentes

O que significa um sinistro encerrado com pendência financeira?

É uma inconsistência no ERP em que o processo de sinistro recebeu baixa ou encerramento na esteira de regulação, mas ainda possui saldo em aberto na Provisão de Sinistros a Liquidar (PSL), ordens de pagamento não quitadas ou despesas de prestadores não vinculadas.

Qual o impacto de manter saldo de PSL em sinistros já pagos?

Manter saldo em PSL após o pagamento infla artificialmente as provisões técnicas da seguradora, penaliza o resultado contábil mensal e reduz a margem de solvência da companhia perante as exigências prudenciais da SUSEP.

Como tratar pagamentos estornados pelo banco em sinistros?

Quando o banco devolve um pagamento (dados bancários incorretos ou conta encerrada), o ERP não deve manter o sinistro como quitado. A pendência financeira deve reabrir a obrigação no sistema até que os dados sejam regularizados e um novo pagamento seja liquidado.

Como a Resolução CNSP nº 496/2026 se relaciona com a auditoria de sinistros?

A norma define marcos claros de até 30 dias para regulação e manifestação de cobertura e até 30 dias para liquidação e pagamento. A auditoria deve acompanhar essas datas no ERP para assegurar conformidade e evitar passivos regulatórios.

O Kitopus executa alterações de status de sinistro no ERP?

Não. O Kitopus atua com acesso somente leitura (read-only), identificando divergências e gerando tarefas de tratativa para que a equipe interna regularize os lançamentos pelos canais oficiais do ERP.