Automação de relatórios: como parar de remontar a mesma planilha toda semana e por que dois setores chegam a números diferentes

Dá para automatizar o relatório semanal que hoje é remontado à mão. O que costuma ser mal dimensionado em um projeto de automação de relatórios é onde mora o esforço: quem pede orçamento pensa no gráfico e na formatação, e o tempo está antes disso — em buscar arquivo no ERP (o sistema de gestão), no CRM (o sistema onde o comercial registra cliente, proposta e negociação), na planilha e no extrato bancário, e em fazer cada base falar a mesma língua.

Automação de relatórios: as cinco etapas e em qual delas o tempo realmente vai

O relatório recorrente tem cinco etapas — coleta, padronização, consolidação, cálculo e publicação. A automação de relatórios ataca sobretudo as três primeiras, que costumam concentrar o tempo. Montar o gráfico é a etapa mais curta e a mais visível, e por isso é a que aparece no pedido de orçamento.

A padronização é a etapa que mais engana. Ela inclui a tabela de-para: a tabela que liga o jeito como um sistema chama um cliente, produto ou centro de custo ao código usado no outro. Sem ela, empilhar duas bases produz um total que soma o mesmo cliente duas vezes, com dois nomes.

E é daí que vem o sintoma que o leitor reconhece: a planilha é "remontada" toda semana porque coleta e padronização não deixam resíduo reaproveitável. O que ficou pronto foi o resultado, não o caminho — então a semana seguinte começa do zero.

A lógica geral está em automação de processos. A versão real dessas cinco etapas dentro da sua empresa sai do mapeamento do processo — e costuma ter mais passos do que a lista genérica.

Por que comercial e financeiro fecham números diferentes

Os dois setores puxam do mesmo ERP e chegam a valores diferentes. Com frequência, nenhum dos dois está errado: cada um aplica um recorte, e os dois recortes são legítimos dentro da própria regra.

As causas concretas costumam ser estas:

• Recorte de data: data do pedido, data de emissão da nota, data da entrega e data do recebimento. Quatro datas para a mesma venda, e cada relatório escolhe uma.
• Competência versus caixa: competência reconhece a venda no período em que ela ocorre, independentemente do pagamento; caixa reconhece no período em que o dinheiro entra. O comercial costuma olhar competência; o financeiro, caixa.
• Cancelamento, devolução e nota complementar: quando o mês já fechou, uma área joga o estorno no período original e a outra no período em que o estorno aconteceu.
• De-para de cadastro: o mesmo cliente com dois códigos no ERP, matriz e filial separadas no CRM, grupo econômico contado como um de um lado e como três do outro.
• Imposto, frete e desconto: dentro ou fora do valor que cada área chama de "venda".

Nenhum desses itens se resolve trocando de ferramenta. São diferenças de definição, e elas continuam existindo depois de qualquer implantação.

A consequência prática é desconfortável: enquanto a definição não estiver escrita, automatizar só produz a divergência mais rápido, em mais telas e com mais confiança injustificada. O número errado passa a chegar sozinho, no horário, com aparência de auditado.

O que precisa existir antes de automatizar: definição escrita e fonte oficial de cada número

O pré-requisito é uma ficha curta por indicador. Ela cabe em meia página e não depende de fornecedor nenhum:

1. Nome do indicador, exatamente como ele vai aparecer na publicação.
2. O que ele mede, em uma frase.
3. Fórmula, com numerador e denominador explícitos.
4. Recorte de data: qual das datas disponíveis manda.
5. Filtros de exclusão: pedido cancelado, registro de teste, operação entre empresas do mesmo grupo.
6. Unidade e periodicidade.

Depois da ficha vem a fonte oficial: para cada número, um sistema é o dono. Se faturamento sai do ERP, que é onde o pedido é lançado e faturado — o percurso está em automação de pedido de venda —, o CRM deixa de ser fonte de faturamento mesmo tendo o campo preenchido, e esse campo vai continuar preenchido, com outro valor.

O indicador também precisa de alguém que assine a definição. Isso não é formalidade: divergência encontrada depois volta para quem definiu, não para quem construiu a automação. Sem dono, toda discrepância vira suspeita de bug e o projeto passa a defender o número em vez de entregá-lo.

Quando dois setores precisam de recortes diferentes de propósito, o caminho não é forçar um número único. É publicar os dois, com nomes distintos — "venda faturada por competência" e "recebimento por caixa" —, e explicar a diferença dentro da própria publicação, onde as duas pessoas vão olhar.

Como o dado sai de cada sistema: API, exportação agendada, banco e quando só existe a tela

A hierarquia é a mesma de qualquer integração, aplicada ao caso de leitura:

1. API documentada de consulta — a interface que o próprio sistema publica para outro programa buscar o dado. Quando existe, resolve.
2. Relatório agendado pelo próprio sistema, enviado por e-mail ou depositado em pasta compartilhada ou em FTP (protocolo de transferência de arquivos).
3. Consulta ao banco de dados ou, melhor, a uma réplica de leitura — cópia do banco mantida atualizada e usada só para consulta.
4. Exportação manual padronizada — alguém ainda clica, mas o arquivo é sempre o mesmo.
5. Robô de tela, no fim da fila.

Relatório tem uma particularidade a favor: a operação é só de leitura, então não há risco de gravar errado no sistema de produção. O risco muda de lugar — passa a ser a carga sobre a fonte e a janela de extração, porque duas fontes lidas em momentos diferentes podem não descrever o mesmo instante.

Consulta direta ao banco em horário de pico pesa no sistema que a operação está usando. Combine o horário com quem administra o ambiente e, quando houver réplica, use a réplica.

No extrato bancário, os caminhos são o arquivo OFX (Open Financial Exchange, formato de extrato que a maioria dos bancos exporta), o arquivo de retorno em layout CNAB — o padrão de troca de arquivos com o banco, que traz as baixas de cobrança e pagamento e é o mesmo arquivo usado na automação do contas a pagar — ou a API do banco. Quando só há PDF do internet banking, a conversa muda de lugar: vira leitura de documento, e é só aí que a IA entra — o critério está em IA na automação de processos.

O mapa completo dos caminhos está em integração de sistemas, e o que o robô de tela cobra depois de pronto está em o que é RPA.

Perguntas para fazer a cada fornecedor de sistema antes de orçar:

• O sistema exporta relatório agendado, sem alguém clicar?
• Existe API de leitura documentada, e o acesso é cobrado à parte?
• A consulta devolve o período fechado ou o acumulado até agora?
• Há limite de linhas por exportação ou de chamadas por período?

Onde guardar o consolidado — e o que uma ferramenta de BI resolve de verdade

São três destinos possíveis: a planilha de destino que o time já usa, um banco de dados intermediário ou uma ferramenta de BI — Business Intelligence, software de visualização e análise que lê dados já organizados.

A planilha de destino é a resposta certa com mais frequência do que parece: poucas linhas por período, time que já trabalha nela, ninguém disposto a aprender ferramenta nova e leitura igual toda semana. Automatizar a escrita na planilha que já existe entrega o ganho sem projeto de plataforma.

A planilha deixa de servir quando o histórico fica longo, o recálculo trava, mais de uma pessoa edita ao mesmo tempo ou passa a ser necessário rastrear quem mudou o quê. Os sinais e os caminhos de saída estão em quando a planilha deixa de ser suficiente.

O BI resolve visualização, corte por dimensão, distribuição de acesso e atualização programada do painel. É bom nisso.

O BI não resolve o de-para entre cadastros, a divergência de definição, a fonte que só entrega PDF nem a linha que não casou. O conector nativo cobre a extração fácil e para exatamente no ponto em que o trabalho começa.

Daí a consequência: painel bonito sobre coleta manual continua sendo coleta manual. O que muda é que ele passa a quebrar de forma mais visível, na frente de mais gente.

Por dentro: agendamento, janela de fechamento, linha que não casou e fonte que não respondeu

O gatilho aqui é horário — relatório não espera evento. O que precisa ser decidido é qual horário: fechamento do dia, madrugada de segunda ou o dia útil seguinte ao fechamento contábil.

Depois vem a janela de fechamento. O número de ontem pode mudar hoje, porque lançamento atrasa, nota é cancelada e conciliação chega depois. É preciso decidir se o relatório é foto congelada do período ou se ele se reprocessa quando a fonte muda — e, nos dois casos, gravar a data e a hora da extração dentro do próprio relatório.

Se ele se reprocessa, entra a idempotência: rodar de novo o mesmo período não pode duplicar linha nem somar duas vezes. A rodada substitui o período inteiro em vez de acrescentar ao que já estava lá.

Linha que não casou nunca entra por aproximação. Ela vai para uma aba ou fila de exceção, com o motivo escrito, e o total publicado informa quanto ficou de fora. Relatório que esconde o não conciliado é pior do que relatório nenhum, porque ninguém desconfia dele.

Fonte que não respondeu tem duas saídas possíveis: repetir a tentativa e, se ainda falhar, publicar com marcação explícita de fonte ausente ou não publicar. A escolha entre as duas precisa estar definida antes, não no dia em que o sistema cair.

Cada rodada deixa registro de execução: o que entrou, o que falhou, quantas exceções e quanto tempo levou.

E a virada não é de um dia para o outro. O automático roda em paralelo ao manual por alguns ciclos, e os dois são comparados linha a linha antes de desligar o manual. A divergência encontrada nessa fase costuma ser definição, não bug — e é exatamente por isso que ela vale o esforço.

Indicadores de processo: medir com o dado que a própria automação já registra

Automação que registra execução produz, sem esforço adicional, dado sobre o próprio processo. Quatro medidas úteis saem do registro:

• Tempo de ciclo: quanto tempo entre o gatilho e a publicação, e em qual etapa a espera se concentra.
• Volume: quantos itens por período, com a sazonalidade visível.
• Retrabalho: quantas vezes o mesmo período foi reprocessado e por quê.
• Exceção: percentual de linhas que não casaram e quais fontes mais geram exceção.

O uso prático é a leitura da tendência. Taxa de exceção caindo ao longo dos meses é sinal de que o de-para amadureceu. Taxa subindo de repente é sinal de que alguma fonte mudou — campo renomeado, layout alterado, cadastro novo entrando sem padrão.

Esses números também são o que torna a decisão de investir discutível em vez de intuitiva: sem tempo de ciclo, volume e retrabalho medidos, a conta de retorno é chute.

Quando automatizar o relatório não se paga

Relatório mensal, uma hora de trabalho, número que ninguém contesta: não é candidato a projeto.

Outros sinais de que não é hora:

• A definição do indicador muda todo mês.
• A fonte principal vai ser trocada nos próximos meses.
• O cadastro está tão desalinhado que o de-para não estabiliza.
• O relatório é olhado uma vez e ninguém decide nada com ele.

O teste mais barato antes de contratar qualquer coisa é uma pergunta: quem toma qual decisão com aquele número? Relatório sem decisão associada não precisa ser automatizado — precisa ser descontinuado.

Quando vale, mas o projeto inteiro é grande demais, a automação parcial costuma resolver boa parte: automatizar só a coleta e a padronização, e deixar consolidação e formatação na mão. É onde o tempo se concentra e, em geral, a parte mais barata de construir.

A segunda parcial possível é automatizar apenas as fontes que têm API ou exportação agendada e manter a fonte difícil manual por enquanto, com o lugar dela já reservado no arquivo consolidado.

Se quiser uma leitura do seu caso, descreva pelo WhatsApp quais sistemas alimentam o relatório, com que frequência ele é feito e quanto tempo leva. A análise começa por aí — e às vezes termina em "ainda não vale a pena".