Controles financeiros e segregação de funções contra fraude interna e externa

Controles financeiros são políticas, processos e mecanismos (manuais e automatizados) que reduzem a probabilidade de perdas por erro, abuso ou fraude, e aumentam a capacidade de detectar rapidamente desvios. Em fraudes internas e externas, o objetivo é o mesmo: impedir que uma única pessoa (ou um único ponto do processo) consiga iniciar, aprovar, executar e ocultar uma transação indevida. A segregação de funções (SoD, do inglês segregation of duties) é o princípio central: dividir responsabilidades críticas entre pessoas e/ou sistemas diferentes, com trilhas de auditoria e limites claros.

Fraude externa costuma explorar brechas de processo (por exemplo, pagamentos fora do fluxo, exceções “urgentes”, falta de validação de dados de fornecedor) e fraquezas de controle (alçadas mal definidas, permissões excessivas, ausência de reconciliação). Fraude interna se beneficia de acesso legítimo e conhecimento do funcionamento da empresa, podendo manipular cadastros, criar exceções, contornar aprovações ou ajustar registros para esconder rastros. Controles financeiros bem desenhados tratam ambos os cenários ao criar barreiras independentes, reduzir privilégios e aumentar a visibilidade.

1) Conceitos essenciais: o que controlar e por quê

1.1 Objetivos de controle em finanças

• Prevenção: impedir que a transação indevida ocorra (ex.: bloqueio de pagamento sem pedido/contrato, alçada obrigatória, travas de alteração de dados bancários).
• Detecção: identificar rapidamente o desvio (ex.: conciliações, relatórios de exceção, alertas de duplicidade, auditoria de alterações em cadastros).
• Correção: reverter/mitigar o impacto e ajustar o processo (ex.: estorno, bloqueio de fornecedor, revisão de permissões, reforço de políticas).

1.2 Segregação de funções (SoD) na prática

SoD não é apenas “duas pessoas assinam”. É separar etapas que, se concentradas, permitem fraude com baixa chance de detecção. Em finanças, as separações clássicas são:

• Iniciação (criar solicitação/pedido, cadastrar fornecedor, lançar nota) ≠ Aprovação (validar necessidade, preço, contrato, alçada) ≠ Execução (pagar, liberar remessa, efetivar transferência) ≠ Registro/contabilização (lançar no razão, classificar contas) ≠ Revisão (conciliação, auditoria, análise de exceções).
• Administração de sistemas (perfis, permissões, parametrizações) deve ser separada de operações financeiras (cadastro, aprovação, pagamento).
• Gestão de fornecedores (cadastro e manutenção) deve ser separada de contas a pagar e de tesouraria.

Quando a empresa é pequena e não há pessoas suficientes para separar tudo, aplica-se SoD compensatória: controles adicionais (revisões independentes, limites menores, auditoria frequente, relatórios automáticos, aprovação por conselho/gestor externo ao processo) para reduzir o risco.

1.3 Triângulo da fraude e como controles financeiros atuam

Fraudes tendem a ocorrer quando há pressão (financeira, metas), oportunidade (brecha de controle) e racionalização (justificativas). Controles financeiros atacam principalmente a oportunidade: reduzem privilégios, aumentam rastreabilidade e tornam a fraude mais difícil de executar e esconder.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

2) Controles-chave por processo financeiro

2.1 Procure-to-Pay (P2P): da compra ao pagamento

O fluxo P2P é um dos mais visados porque conecta demanda interna, fornecedores e saída de caixa. Controles recomendados:

• Pedido de compra obrigatório (quando aplicável) antes de receber e pagar: evita “compras fantasmas” e pagamentos sem lastro.
• Três vias (3-way match): pedido de compra, recebimento (ou aceite do serviço) e nota fiscal/fatura devem bater em quantidade, preço e condições antes do pagamento.
• Catálogo e contratos: itens e serviços recorrentes com preços e fornecedores pré-aprovados reduzem exceções.
• Bloqueio de pagamento por exceção: divergências geram bloqueio automático até correção formal.
• Alçadas de aprovação por valor, categoria e risco (novo fornecedor, adiantamento, pagamento internacional, urgência).
• Separação de funções: quem aprova a compra não deve cadastrar fornecedor nem executar pagamento.
• Controles de adiantamento: adiantamentos exigem justificativa, contrato, aprovação reforçada e prestação de contas com prazo.

Exemplo prático: um colaborador tenta aprovar um serviço “consultoria” sem contrato e solicita pagamento imediato. Com 3-way match e exigência de aceite formal do gestor do contrato, o pagamento fica bloqueado até que haja evidência de entrega/aceite e documentação mínima.

2.2 Cadastro e manutenção de fornecedores

Fraudes internas e externas frequentemente passam por alteração de dados bancários ou criação de fornecedor fictício. Controles essenciais:

• Workflow de cadastro com etapas: solicitação (área demandante), validação documental (cadastro), aprovação (compliance/finanças) e ativação (só após validação).
• Validação de dados: CNPJ/CPF, razão social, endereço, dados bancários, beneficiário final quando aplicável, e checagem de duplicidade (mesmo CNPJ, mesmo banco/conta, mesmo endereço).
• Bloqueio de alteração sensível: mudança de banco/conta exige aprovação adicional e registro de evidências.
• Trilha de auditoria: log de quem alterou, quando, o que mudou e por qual motivo.
• Separação: quem mantém cadastro não deve aprovar pagamento nem ter acesso a liberar lotes bancários.

Exemplo prático: um fraudador externo tenta induzir a equipe a trocar a conta bancária de um fornecedor. Mesmo que a solicitação chegue “bem escrita”, o controle impede alteração sem evidências e aprovações independentes, e o log permite investigar tentativas repetidas.

2.3 Contas a pagar e tesouraria

Mesmo com bons controles no P2P, a execução do pagamento é um ponto crítico. Controles recomendados:

• Pagamento em lote com dupla autorização: uma pessoa prepara o lote, outra autoriza no banco/ERP, preferencialmente em perfis diferentes.
• Perfis de acesso por função: preparar ≠ aprovar ≠ liberar ≠ administrar usuários.
• Limites por usuário (valor diário, por transação, por tipo de pagamento) e limites por conta bancária.
• Calendário de pagamentos: pagamentos fora do calendário exigem justificativa e aprovação reforçada.
• Conta bancária dedicada para pagamentos de fornecedores, com saldo controlado (reduz impacto se houver desvio).
• Conciliação diária de extratos e pagamentos, com análise de itens não identificados.

Exemplo prático: um colaborador com acesso excessivo consegue preparar e liberar um pagamento. Ao aplicar perfis separados e dupla autorização, ele até prepara o lote, mas não consegue liberar sem a segunda pessoa, e o evento fica registrado.

2.4 Order-to-Cash (O2C): faturamento e recebimentos

Fraudes também ocorrem na entrada: desvio de recebíveis, concessão indevida de crédito, manipulação de descontos e estornos. Controles úteis:

• Segregação entre quem aprova crédito/limite e quem registra recebimentos/baixas.
• Regras para descontos: descontos acima de certo percentual exigem aprovação e justificativa.
• Controle de estornos: estorno de recebimento e cancelamento de nota com aprovação e evidência.
• Conciliação bancária e conciliação de cartões/adquirentes com relatórios de divergência.
• Monitoramento de contas de clientes: padrões anômalos (muitos estornos, muitos descontos, baixa manual recorrente).

2.5 Folha de pagamento e despesas

Folha e reembolsos são alvos comuns de fraude interna por serem recorrentes e volumosos.

• Folha: segregação entre RH (cadastro de colaboradores), gestor (aprovação de horas/variáveis) e financeiro (pagamento). Auditoria de alterações em dados bancários e eventos variáveis.
• Despesas: política clara, limites por categoria, exigência de comprovantes, auditoria amostral e análise de duplicidade (mesmo recibo, mesmo valor, mesma data).
• Cartões corporativos: limites, MCC (categoria de comerciante) permitido, bloqueio de saques quando não necessário, revisão mensal independente.

3) Controles transversais: o que sustenta todos os processos

3.1 Matriz de alçadas e governança de aprovações

Uma matriz de alçadas define quem pode aprovar o quê, com base em valor, tipo de gasto e risco. Boas práticas:

• Alçadas por faixa de valor e por categoria (ex.: TI, marketing, consultoria, serviços críticos).
• Regras para exceções: urgência não elimina controle; apenas muda o caminho (aprovação reforçada e registro).
• Substituições: delegações temporárias documentadas, com prazo e escopo.
• Proibição de autoaprovação: o solicitante não aprova a própria solicitação.

3.2 Gestão de acessos e SoD em sistemas (ERP, banco, plataformas)

Fraude frequentemente depende de permissões excessivas. Controles:

• Privilégio mínimo: cada perfil tem apenas o necessário.
• Revisão periódica de acessos: pelo menos trimestral para áreas críticas; revogar acessos de desligados imediatamente.
• SoD automatizada: regras que impedem combinações tóxicas (ex.: cadastrar fornecedor e liberar pagamento).
• Contas administrativas separadas e monitoradas; uso apenas quando necessário.
• Logs e monitoramento: alertas para ações sensíveis (alteração de dados bancários, criação de fornecedor, mudança de alçada, liberação manual).

3.3 Reconciliações, trilhas e evidências

Reconciliação é um controle de detecção poderoso porque compara fontes independentes.

• Conciliação bancária diária ou semanal, conforme volume.
• Conciliação de fornecedores: extratos de fornecedor versus contas a pagar, especialmente para fornecedores críticos.
• Conciliação de impostos: guias pagas versus apuração, evitando pagamentos duplicados ou indevidos.
• Trilhas de auditoria: anexar evidências no ERP (contrato, pedido, aceite, nota, aprovação) reduz “aprovações no verbal”.

3.4 Relatórios de exceção e analytics

Além do controle transacional, use relatórios para encontrar padrões improváveis:

• Pagamentos duplicados (mesmo valor/data/fornecedor, notas parecidas).
• Pagamentos fora do horário ou em dias incomuns.
• Fornecedores com mesma conta bancária ou mesmo endereço.
• Sequência de notas “redondas” (valores repetidos) e fracionamento para ficar abaixo da alçada.
• Concentração de aprovações em um único aprovador ou em um único centro de custo.

4) Passo a passo prático: implantando segregação de funções e controles financeiros

4.1 Passo 1: mapear processos e pontos de decisão

Liste os processos críticos: P2P, cadastro de fornecedores, contas a pagar/tesouraria, O2C, folha/despesas. Para cada um, desenhe o fluxo real (não o “oficial”), incluindo exceções: urgências, adiantamentos, pagamentos manuais, ajustes contábeis.

• Identifique onde há entrada de dados (cadastro, lançamento), aprovação, execução e revisão.
• Marque quais etapas hoje são feitas pela mesma pessoa ou pelo mesmo time sem revisão.

4.2 Passo 2: identificar “combinações tóxicas” (SoD conflicts)

Crie uma lista de combinações proibidas. Exemplos comuns:

• Cadastrar/alterar fornecedor e aprovar pagamento.
• Lançar fatura e aprovar a própria fatura.
• Criar usuário/perfil no ERP e operar pagamentos.
• Registrar recebimento e conceder desconto/estorno sem revisão.

Transforme isso em regras no sistema quando possível, e em regras de processo quando não for.

4.3 Passo 3: desenhar a matriz de alçadas e o fluxo de aprovações

Defina:

• Quem aprova por valor e categoria.
• Quando é necessária segunda aprovação (ex.: novo fornecedor, alteração bancária, adiantamento, pagamento internacional, pagamento fora do calendário).
• Quais evidências são obrigatórias em cada etapa (contrato, aceite, nota, justificativa).

Padronize o que é “urgente”: urgência deve ter motivo, aprovador adicional e registro; não deve virar atalho permanente.

4.4 Passo 4: ajustar perfis de acesso e implementar travas

Traduza o desenho de SoD em permissões:

• Crie perfis por função (cadastro, contas a pagar, tesouraria, contabilidade, auditoria).
• Remova acessos genéricos e permissões “temporárias” que viraram permanentes.
• Implemente travas: 3-way match, bloqueio por exceção, limites por usuário, necessidade de dupla autorização no banco.

Se o sistema não suportar travas, implemente controles compensatórios: relatórios diários de alterações sensíveis e revisão independente.

4.5 Passo 5: estabelecer rotinas de revisão e conciliação

• Diário: conciliação bancária (ou ao menos verificação de saídas), pagamentos liberados, alertas de alteração de fornecedor.
• Semanal: relatório de exceções (pagamentos manuais, urgências, fracionamentos), análise de duplicidade.
• Mensal: fechamento com reconciliações, revisão de fornecedores novos/alterados, revisão de acessos e de combinações tóxicas.

4.6 Passo 6: testar controles com cenários de fraude

Faça testes controlados (tabletop) com exemplos:

• Tentar cadastrar fornecedor com dados incompletos: o fluxo bloqueia?
• Tentar alterar conta bancária: há aprovação adicional e log?
• Tentar pagar sem pedido/aceite: o sistema impede ou sinaliza?
• Tentar fracionar pagamentos: o relatório detecta?

Registre falhas e corrija o desenho. Controles que “existem no papel” mas não funcionam no dia a dia são um risco.

5) Cenários típicos de fraude e como os controles quebram a cadeia

5.1 Fornecedor fictício criado por insider

Um colaborador cria um fornecedor e emite faturas falsas para receber pagamentos. Controles que reduzem o risco:

• Cadastro com validação documental e checagem de duplicidade.
• SoD: quem cadastra não aprova nem paga.
• Relatórios: fornecedores novos pagos nos primeiros 30 dias, pagamentos para contas bancárias repetidas.
• 3-way match e exigência de aceite do serviço por gestor responsável.

5.2 Alteração de dados bancários de fornecedor real

O fraudador tenta redirecionar pagamentos. Controles:

• Bloqueio de alteração sensível com aprovação reforçada.
• Log e alerta automático para time de controle.
• Período de “quarentena” opcional: alterações bancárias só valem após X dias, exceto com aprovação extra.

5.3 Pagamento duplicado ou indevido por falha de processo

Nem toda perda é fraude intencional; erros operacionais também geram prejuízo e podem ser explorados. Controles:

• Validação de duplicidade (nota, valor, data, fornecedor).
• Conciliação e relatórios de exceção.
• Bloqueio de pagamento sem referência única (ID de fatura) e sem documentação.

6) Indicadores e evidências para auditoria contínua

Para manter controles vivos, defina indicadores (KPIs/KRIs) e evidências mínimas:

• % de pagamentos fora do fluxo (manuais, urgentes, sem pedido/aceite).
• Tempo médio entre alteração de cadastro e primeiro pagamento.
• Número de alterações bancárias por mês e por responsável.
• Concentração de aprovações (um aprovador aprovando volume atípico).
• Exceções de 3-way match e motivos recorrentes.
• Resultados de revisão de acessos: quantos acessos removidos, quantos conflitos SoD corrigidos.

Guarde evidências de execução: relatórios assinados digitalmente, tickets de aprovação, logs exportados, checklists de conciliação. Em incidentes, a diferença entre “achamos que controlamos” e “temos evidência de controle” é decisiva.

7) Modelos práticos (checklists) para aplicar no dia a dia

7.1 Checklist de pagamento (antes de liberar)

• Existe documento base (pedido/contrato/aceite) anexado?
• Fornecedor está ativo e sem pendências?
• Dados bancários não foram alterados recentemente sem aprovação reforçada?
• Há divergência no 3-way match? Se sim, está formalmente justificada e aprovada?
• Pagamento está dentro do calendário e da alçada?
• O lote terá dupla autorização e ficará registrado?

7.2 Checklist de manutenção de fornecedor

• Solicitação tem justificativa e responsável interno?
• Documentos mínimos foram validados?
• Checagem de duplicidade realizada (CNPJ, conta bancária, endereço)?
• Alteração sensível passou por aprovação adicional?
• Log e evidências anexados?

7.3 Checklist mensal de SoD e acessos

• Há usuários com perfis incompatíveis (combinações tóxicas)?
• Há contas genéricas compartilhadas?
• Há acessos de desligados ou terceiros fora do prazo?
• Há permissões temporárias sem data de expiração?
• Relatórios de alterações sensíveis foram revisados e arquivados?

Exemplo de regra simples de SoD (pseudo): SE usuario.temPermissao("CAD_FORNECEDOR") ENTAO bloquearPermissao("LIBERAR_PAGAMENTO"); SE usuario.temPermissao("LIBERAR_PAGAMENTO") ENTAO bloquearPermissao("ALTERAR_DADOS_BANCARIOS_FORNECEDOR");