Já revisei dezenas de ERPs em clientes — SAP, Oracle EBS, Totvs Protheus, Senior, Microsiga antigo, alguns sistemas próprios em Progress 4GL. Diferenças enormes na tecnologia. Mas os problemas são quase sempre os mesmos.
Tem oito riscos que aparecem com tanta frequência que poderia ser checklist universal. Todos têm em comum: parecem operacionais, mas são organizacionais. E todos são evitáveis.
Vou te contar quais são.
Risco 1: Usuários com acesso de emergência habilitado permanentemente
O famoso "firefighter" do SAP. Ou o usuário admin temporário do Oracle que foi criado em 2018 e nunca removido. Acesso de emergência é um conceito legítimo — pra resolver problemas urgentes fora do horário, com aprovação posterior — mas só faz sentido se for de fato temporário.
O que eu vejo: emergency access permanente, sem revisão, usado regularmente. Vira backdoor de superusuário. Sem auditoria. Sem accountability.
Como evitar: emergency access com prazo de expiração automática (24h, 48h). Aprovação formal antes da liberação. Auditoria completa de tudo que foi feito durante o período. Revisão mensal de todos os acessos emergenciais concedidos.
O processo de emergency access que o auditor aceita
Pra emergency access ser aceito como controle valido, ele precisa ter:
- Solicitacao formal antes da concessao (mesmo que email)
- Aprovacao por gestor com nivel suficiente
- Prazo de expiracao automatica (24h ou 48h tipicamente)
- Log completo de tudo que foi feito durante o periodo
- Relatorio pos-uso entregue ao gestor solicitante
- Revisao mensal de todas as concessoes emergenciais no comite
Empresa que tem esse fluxo passa limpo. Empresa que mantem firefighter permanentemente ativo nao.
Risco 2: Mudanças em produção sem registro de aprovação
Já comentei em vários artigos, mas vale repetir porque é o mais comum. Mudança feita por desenvolvedor, DBA ou consultor externo direto em produção, sem ticket, sem aprovação documentada.
O risco operacional: você não sabe quem fez o quê, quando, por quê. Se algo quebrar uma semana depois, ninguém consegue rastrear.
O risco de auditoria: ressalva certa.
Como evitar: processo formal de change management. Ferramenta de ticket (mesmo que simples). Aprovador definido por tipo de mudança. Janela de mudança definida. Registro de execução obrigatório.
Risco 3: Processos batch sem log de execução
O ERP roda dezenas (às vezes centenas) de processos batch — fechamento contábil, geração de faturas, atualização de estoque, cálculo de comissão, integração com bancos. Muitos rodam de madrugada. Ninguém vê.
Se um job falha e ninguém percebe, o dado fica errado. Ajuste manual depois pode ou não funcionar.
Como evitar: inventário formal de todos os jobs batch críticos. Responsável nomeado por cada um. Notificação automática em caso de falha. Verificação diária de execuções (mesmo que automatizada). Auditoria mensal dos jobs que falharam e como foram tratados.
Os jobs que mais causam surpresa
Os jobs batch que mais geram surpresa em auditoria:
- Jobs criados ha 10+ anos por gente que ja saiu da empresa
- Jobs com privilegios excessivos (rodam como root ou DBA sem necessidade)
- Jobs sem responsavel atual identificado
- Jobs que dependem de pasta ou arquivo que pode mudar sem aviso
- Jobs sem tratamento de erro (falha e ninguem ve)
Inventario formal salva esse cenario. Sem inventario, voce nao sabe nem o que tem rodando.
Risco 4: Segregação de funções no papel mas não no sistema
A política diz que quem cria fornecedor não pode aprovar pagamento. O ERP não tem regra técnica que impede isso. Usuário do financeiro tem ambos os perfis ativos. Auditoria reprova.
Política sem implementação é teatro. Vejo demais.
Como evitar: matriz formal de SoD. Implementação técnica (perfis incompatíveis bloqueados no sistema). Onde a tecnologia não suporta, controle compensatório documentado.
A política não controla nada por si só. O que controla é a fronteira técnica que impede a violação ou o controle compensatório que detecta antes do dano se concretizar.
Risco 5: Dados mestres alterados sem aprovação
Cadastro de cliente, cadastro de fornecedor, plano de contas, tabela de preço, condição de pagamento — esses são dados mestres do ERP. Mudança neles afeta todos os módulos. E geralmente são alterados por usuário operacional sem aprovação formal.
Exemplo real que já vi: vendedor cadastrou novo cliente com condição de pagamento de 90 dias (a padrão é 30). Faturou R$ 800 mil pra esse cliente. Cliente sumiu. Ninguém aprovou aquela condição diferenciada. Prejuízo total.
Como evitar: workflow de aprovação para alteração de dados mestres críticos. Aprovação por gestor da área antes da efetivação. Log de todas as alterações com motivo registrado.
Outros dados mestres que precisam de aprovacao
Alem dos classicos, outros dados mestres importantes:
- Cadastro de centro de custo (afeta DRE inteira)
- Cadastro de empresa/filial (afeta contabilidade)
- Configuracao de aliquota fiscal (afeta cada nota)
- Estrutura de comissao (afeta folha)
- Politica de desconto maxima (afeta margem)
- Configuracao de integracao bancaria (afeta tesouraria)
Cada um desses tem workflow proprio. Mudanca sem aprovacao formal causa estrago contabil ou fiscal.
Identifique seus riscos antes que o auditor identifique com o checklist ERP.
Fazer o Checklist de Auditoria ERP →Risco 6: Customizações fora do padrão sem documentação
ERP padrão (SAP, Oracle, Totvs) costuma ter 20-40% de customizações no cliente médio. Programas ZTABs em SAP, formulários custom em Oracle, ADVPLs em Totvs.
Cada customização é um ponto de risco se não documentada: quem fez, quando, com qual objetivo, qual a lógica de negócio.
Quando o auditor pergunta sobre o programa Y_INVOICE_BR que ninguém sabe o que faz, é problema.
Como evitar: inventário formal de customizações. Para cada uma: documentação técnica, lógica de negócio, responsável funcional, motivo da customização. Revisão anual pra eliminar customizações obsoletas.
Risco 7: Interfaces e integrações sem reconciliação
O ERP recebe dados de outros sistemas (ponto eletrônico, e-commerce, sistema de produção, banco). Manda dados pra outros (BI, sistema fiscal, sistema de pagamento).
Em cada interface, dados podem se perder, se duplicar, se corromper. Sem reconciliação periódica, ninguém percebe.
Eu já vi caso real: integração com banco perdia 0,3% das transações de cobrança por mês. Em volume baixo, ninguém notava. Acumulado de 18 meses: R$ 380 mil em recebimentos não conciliados.
Como evitar: reconciliação automática diária para interfaces críticas. Relatório de exceções tratado por responsável. Auditoria mensal das reconciliações.
Reconciliacao automatica: como fazer simples
Reconciliacao automatica nao precisa de ferramenta cara. O modelo basico:
- Job diario que conta registros enviados/recebidos em cada interface
- Comparacao com baseline ou contagem esperada
- Tolerancia configurada por interface
- Alerta automatico se variacao acima de tolerancia
- Tratamento documentado por responsavel
- Revisao mensal das exceções no comite
Empresa com isso evita prejuizos como o de R$ 380 mil que mencionei. Investimento: 40-80 horas de desenvolvimento. Retorno: praticamente garantido.
Risco 8: Falta de teste real de continuidade
A empresa tem plano de continuidade. Tem backup. Tem ambiente de DR. Mas nunca testou. Quando testar de verdade (geralmente num desastre real), descobre que algo não funciona.
Cliente meu, indústria, teve incidente de ransomware em 2023. Plano de continuidade impecável no papel. Na hora do desastre: backup do servidor de aplicação OK, backup do banco corrompido (problema no script de backup há 4 meses, ninguém detectou). 5 dias de paralisação. Prejuízo R$ 2,4 milhões.
Como evitar: teste de restore completo pelo menos anualmente, em ambiente isolado. Simulação de DR (failover real, não só documentação) anual. Relatório de teste documentado. Lições aprendidas tratadas no próximo ciclo.
O padrão que une todos esses riscos
Olhei esses 8 riscos lado a lado em dezenas de auditorias. O denominador comum é claro:
Controles que existem na intenção mas não na operação rotineira.
A empresa tem política. Tem ferramenta. Tem processo desenhado. Mas no dia a dia, ninguém executa consistentemente. O controle vira figura de retórica. Quando a auditoria vem, a teatro cai.
A solução nunca é mais política, mais ferramenta, mais processo. A solução é ritualização da execução. Frequência definida. Responsável nominado. Evidência produzida e arquivada. Revisão periódica do ritual.
É chato. É repetitivo. Mas é o que separa empresa com controle real de empresa com controle no papel. E o auditor sabe ler essa diferença em 20 minutos de conversa com qualquer gerente.
O caminho não é blindar a empresa contra o auditor. É construir controles que funcionam de verdade. O auditor vira detalhe.
O calendario de rituais que sustenta controle real
Pra cada empresa que atendo, monto um calendario anual de rituais de controle. Tipico:
- Diario: revisao de alertas criticos, conferencia de jobs noturnos
- Semanal: revisao de incidentes da semana, status do plano de tratamento de risco
- Mensal: conciliacao de acessos, revisao de mudancas em producao, revisao de excecoes de SoD
- Trimestral: revisao de acessos privilegiados, teste amostral de controles, auditoria interna leve
- Semestral: revisao pela direcao, atualizacao de matrizes de risco e SoD
- Anual: auditoria interna completa, teste de restore, simulacao de DR, revisao de politicas
Esse calendario, seguido com disciplina, mantem o controle vivo. Sem ele, controle degrada e auditoria descobre. Com ele, controle sobrevive e auditoria passa.
Veja também
Guia CompletoO que a Big Four vai procurar no seu ERP — e como se preparar antes que ela chegue
Auditores de Big Four têm um roteiro. ERP com Oracle, SAP ou Totvs: os pontos de verificação são os mesmos. Saiba o que eles procuram e o que você precisa ter pronto.
Como ImplementarComo preparar seu ERP para auditoria em 60 dias (sem reescrever processos)
60 dias é pouco para implementar controles do zero. Mas é suficiente para organizar o que já existe, documentar o que funciona e fechar os gaps críticos.
Perguntas frequentes
Quais são os riscos mais comuns em auditorias de ERP?
Os 8 mais frequentes: 1) Usuários genéricos compartilhados sem rastreabilidade. 2) Acesso excessivo ao módulo financeiro. 3) Mudanças em produção sem aprovação documentada. 4) Falta de segregação entre ambiente de desenvolvimento e produção. 5) Relatórios customizados sem controle de versão. 6) Interfaces sem validação de integridade. 7) Ausência de log de auditoria ativo. 8) Dependência de superusuários para operações rotineiras.
Como funciona a segregação de funções no ERP?
Segregação de funções (SoD) significa que a mesma pessoa não pode controlar todo um processo crítico. No ERP financeiro: quem cria fornecedor não pode aprovar pagamento; quem lança nota fiscal não pode conciliar a conta; quem configura parâmetros não pode executar transações. O ERP deve ter perfis de acesso que impeçam essas combinações conflitantes — e o auditor vai testar isso com matriz de SoD.
O que acontece quando a auditoria de ERP encontra problemas graves?
Depende da gravidade. Problemas remediados antes do fim da auditoria com evidência adequada geralmente resultam em não-conformidade menor. Problemas com histórico de recorrência ou que colocam em dúvida a integridade dos dados financeiros podem resultar em opinião adversa ou com ressalva — que precisa ser divulgada publicamente em empresas de capital aberto.
Os riscos invisíveis: o que aparece sem aviso
Tem categoria de risco que não aparece nas planilhas tradicionais de risco — risco oculto até virar problema. Em auditoria de ERP, três se repetem com frequência:
Risco de drift de processo. O processo documentado em 2022 não é o que acontece em 2025. Mudanças informais foram acumulando — exceções que viraram regra, atalhos que viraram padrão. O processo escrito e a prática divergem. Auditor olha planilha de evidência e percebe inconsistências com o documento.
Como mitigar: revisão semestral obrigatória dos donos de processo, confrontando documentação com prática. Atualização imediata da documentação ou correção da prática.
Risco de competência única. Aquele DBA que conhece o ERP customizado fundo. Aquele analista que sabe a regra de cálculo do bônus. Quando ele sair, o processo cai. Auditor identifica essa dependência e sinaliza como deficiência de continuidade.
Como mitigar: rotação obrigatória de tarefas, documentação operacional viva, backup técnico em todos os processos críticos.
Risco de integração silenciosa. Aquela integração que ninguém mais lembra de quem fez. Aquele job batch que roda à meia-noite e ninguém sabe quem agendou. São pontos cegos no controle — o auditor encontra e questiona.
Como mitigar: inventário formal de integrações e jobs com responsável claro, ativos ou candidatos à desativação.
O risco que vem da consultoria externa
Tem um padrão interessante: empresa contrata consultoria pra preparar auditoria, e a consultoria deixa o terreno mais arriscado que antes. Como?
Consultoria genérica chega com checklist padrão de 200 itens. Aplica todos. Documenta tudo. A empresa fica com documentação inflada — política, procedimento, fluxograma — mas sem capacidade interna de manter. Quando o consultor sai, o "sistema de gestão" começa a degradar imediatamente. Em 12 meses, a documentação está desatualizada e a próxima auditoria identifica isso.
Pior cenário: consultoria opera no modelo "preparar para passar a auditoria". Empresa passa. Consultoria vai embora. No próximo ciclo, sem consultor, ressalvas voltam. Empresa contrata consultor de novo. Ciclo de dependência crônica que custa caro.
O modelo que funciona: consultoria treina equipe interna durante a implementação. Entrega capacidades, não só artefatos. Documentação proporcional à capacidade de manutenção. Após o engajamento, há ritual interno que sustenta o trabalho. Custo aparente é maior (consultoria mais sênior, treinamento incluído), mas o custo total nos 5 anos seguintes é significativamente menor.
O risco da auditoria sem follow-up
Última categoria que poucos discutem: o risco de não tratar adequadamente os achados de uma auditoria anterior. Quando o auditor encontra um achado, ele documenta como recomendação. No próximo ciclo, ele verifica: foi corrigido?
Empresa que ignora recomendações tem três consequências cumulativas. Primeira: achado recorrente vira "deficiência material" automaticamente — agravante na nota do relatório. Segunda: o auditor passa a ter desconfiança estrutural sobre a empresa, ampliando a amostra e a profundidade dos testes (custo extra de honorários). Terceira: o board cobra ações concretas, e quem deixou passar fica exposto.
O que funciona: plano formal de remediação para cada achado, com responsável, prazo e marco verificável. Reporte trimestral ao comitê de auditoria. Encerramento documentado com evidência. Se o achado não pode ser remediado no curto prazo, plano explicito de mitigação e horizonte temporal claro.
Investimento em rastreamento de achados: 40-100 horas/ano de governance. Retorno: redução estrutural da exposição em auditorias futuras.
