Alçadas de reembolso que sobrevivem a uma auditoria
A política diz que acima de R$ 2 mil aprova o diretor. O processo diz que aprovou quem respondeu primeiro. Enquanto os dois forem coisas diferentes, a evidência sempre vai ser reconstruída de memória.
O auditor pede uma coisa só: mostre quem aprovou a despesa de R$ 3.480 do centro de custo 4102, em que data, sob qual regra e com qual comprovante anexado.
Em muitas empresas, essa pergunta abre uma caça de duas horas. Alguém procura o e-mail. Outra pessoa rola o grupo do WhatsApp até achar o “ok, pode pagar”. O comprovante está numa foto reenviada três vezes. E a política que dizia “acima de R$ 2 mil aprova o diretor” foi cumprida por quem respondeu primeiro.
O problema não é falta de política. É que a política vive num documento e o processo vive em outro lugar. Enquanto os dois não forem a mesma coisa, a evidência sempre vai precisar ser reconstruída de memória — e memória não é prova.
Alçada não é lista de nomes. É regra executável.
A maioria das políticas de reembolso descreve alçada como uma tabela de valores e cargos. Isso basta para publicar no portal interno, mas não basta para virar fluxo. Para o Fluig executar a alçada, cada linha da política precisa responder a quatro perguntas de forma inequívoca:
- Qual é o critério? Valor total, valor por item, centro de custo, tipo de despesa, ou uma combinação deles.
- Quem é o aprovador? Um cargo, um papel na estrutura ou uma pessoa nominal. Papel é melhor: sobrevive a troca de gente.
- O que acontece quando o aprovador é o próprio solicitante? Toda política esquece disso, e é justamente o caso que a auditoria procura.
- Existe cascata? Se acima de R$ 5 mil aprovam gestor e diretor, o fluxo precisa das duas assinaturas registradas, não da última.
Quando essas quatro respostas existem, o gateway em BPMN é a parte fácil. Quando não existem, o desenho técnico vira adivinhação, e o processo entra em produção com um buraco que só aparece na primeira auditoria.

Comece pelos casos de exceção
Vale desenhar primeiro o que a política não cobre. Despesa de diretoria. Reembolso de quem está substituindo o gestor de férias. Item sem nota fiscal, como pedágio manual ou gorjeta. Quilometragem de veículo próprio, que não tem comprovante nenhum e depende de tabela interna. Cada um desses casos vira uma trilha explícita no fluxo ou uma regra de bloqueio no formulário. O que fica de fora do desenho volta como e-mail paralelo.
A trilha precisa existir antes do pedido
Uma trilha de auditoria útil não é um log de banco de dados. É um histórico legível por alguém que não é de TI. No reembolso desenhado no Fluig, cada movimento registra o que importa:
| Evento | O que fica registrado |
|---|---|
| Abertura da solicitação | Solicitante, data, número do chamado, centro de custo e projeto — preenchidos pelo sistema, não digitados |
| Anexo de comprovante | Arquivo preso ao item da despesa, com guarda documental seguindo ISO 9000 |
| Remoção de item | Linha sai do grid, mas a remoção fica no histórico — nada some em silêncio |
| Tomada da tarefa | Nome de quem assumiu; a tarefa trava para os demais aprovadores |
| Decisão | Aprovação com data e alçada aplicada, ou devolução com observação obrigatória |
| Integração | Registro entrando no ERP com centro de custo e projeto corretos |
O detalhe que mais pesa em auditoria é o bloqueio da tarefa. Sem ele, dois gestores abrem o mesmo pedido e o registro fica ambíguo. Com ele, existe uma resposta única para “quem olhou isso”.

Devolver é parte do desenho, não uma falha
Fluxo de reembolso que só tem caminho de aprovação empurra a correção para fora do sistema. O gestor liga, pede o ajuste por mensagem e aprova depois. E a devolução, que é o momento mais informativo do processo, nunca é registrada.
A trilha de correção precisa ser desenhada com observação obrigatória do gestor, notificação imediata ao solicitante e retorno ao mesmo processo, sem abrir um novo número. Assim as duas partes olham o mesmo histórico, na mesma ordem. E quando alguém sai da empresa, o registro continua onde estava.
O processo que só tem caminho de aprovação não é mais simples. Ele só empurrou a parte difícil para fora do sistema.
A integração com o ERP fecha a evidência
Aprovar dentro do Fluig e digitar de novo no Protheus, no RM ou no Datasul reabre o risco no último metro. Dois registros que ninguém concilia viram duas versões do mesmo fato. A integração resolve isso ao transportar valor, centro de custo, projeto e a referência do processo para o ERP, mantendo o vínculo entre o pagamento e a solicitação que o originou. Quando o auditor parte do lançamento contábil, ele chega ao aprovador. Quando parte do aprovador, chega ao pagamento.
Um roteiro curto para revisar o seu desenho
- Escreva a alçada em formato de regra, com critério, papel aprovador e comportamento na exceção.
- Liste os tipos de despesa e marque quais exigem anexo obrigatório para passar do formulário.
- Defina o cálculo de quilometragem por veículo ou categoria dentro do sistema, não em planilha auxiliar.
- Desenhe a devolução com observação obrigatória antes de desenhar a aprovação.
- Escolha o ponto exato de integração com o ERP e o campo que amarra o registro ao processo.
O teste dos dois minutos
Pegue o último reembolso acima da alçada do gestor e tente responder, sem abrir e-mail: quem aprovou, sob qual regra, com qual comprovante, e em quanto tempo. Se a resposta depender de perguntar para alguém, o desenho precisa de revisão.
Nada disso exige plataforma nova. O Fluig que a empresa já licenciou executa esse desenho, com as regras da casa, sem mais uma mensalidade de SaaS somando no fim do ano. O trabalho está em transformar a política escrita em fluxo desenhado em BPMN, versionado e integrado.
Onde a Future Station entra
A Future Station é consultoria independente de Fluig, com mais de 46 mil horas em TOTVS Gestão e Fluig e mais de 500 processos White Label pré-configurados, reembolso entre eles. O time parametriza a alçada da sua empresa, conecta o fluxo ao Protheus, RM ou Datasul e mantém o ambiente sob monitoramento 24/7 com o Future Prime. Clientes como KRYPTUS, TRACBEL, DASS, FERTIMAXI e ESTRUTURAL já rodam processos desenhados assim.
Perguntas frequentes
O que uma alçada precisa ter para virar fluxo no Fluig?
Quatro respostas inequívocas: qual é o critério (valor, centro de custo, tipo de despesa), quem é o aprovador em forma de papel e não de pessoa, o que acontece quando o aprovador é o próprio solicitante, e se existe cascata com mais de uma assinatura obrigatória.
Por que registrar a devolução importa tanto?
Porque a devolução é o momento mais informativo do processo. Quando ela acontece por telefone ou mensagem, a correção sai do sistema e o histórico fica com um buraco. Com observação obrigatória e retorno ao mesmo número de processo, as duas partes olham a mesma linha do tempo.
O que é o bloqueio de tarefa e por que ele pesa em auditoria?
É a trava que impede dois aprovadores de assumirem a mesma solicitação. Sem ela, o registro fica ambíguo sobre quem de fato analisou o pedido. Com ela, existe uma resposta única para “quem olhou isso”.
Precisa comprar uma ferramenta nova de despesas?
Não. O Fluig que a empresa já licenciou executa o desenho completo, com as regras da casa. O trabalho está em transformar a política escrita em fluxo modelado em BPMN, versionado e integrado ao ERP.

Igor Rodrigues
Tech Lead · Future Station · +10 anos em TOTVS Fluig
Modelagem BPMN, datasets, integração REST e SOAP com Protheus e RM. Alçada em cascata e bloqueio de tarefa são detalhes que ele resolve no desenho, antes de virarem achado de auditoria.
Mostre como a sua alçada funciona hoje
A gente devolve o desenho de como ela ficaria dentro do Fluig, com a trilha pronta antes de a auditoria pedir e a integração amarrada ao seu ERP.
