Macro VBA ou Python: qual usar para automatizar a rotina

Toda empresa tem pelo menos uma: a planilha com um botão "Processar" que alguém do financeiro criou anos atrás. Ela importa o extrato, cruza com o contas a receber, formata o relatório e manda para a diretoria. Funciona, economiza horas por semana e ninguém quer mexer. Até o dia em que a pessoa sai de férias, o Office é atualizado ou o banco muda o layout do arquivo.

Quando a equipe começa a falar em "profissionalizar" essa rotina, a pergunta costuma vir em forma de ferramenta: reescrever a macro em VBA de um jeito mais organizado ou passar tudo para Python? A dúvida é legítima, mas a linguagem é a parte menos importante da resposta. O que decide é onde a automação vai rodar e quantas pessoas dependem do resultado.

Abaixo, os dois caminhos lado a lado, o terceiro que aparece quando a rotina cresce e sinais concretos para escolher.

Resposta curta: macro VBA é uma boa escolha para tarefa individual, que começa e termina dentro do Excel, executada por quem a usa. Python é melhor quando a rotina processa arquivos em lote, lê sistemas e bancos de dados ou precisa rodar sozinha, em horário marcado, fora da máquina de alguém. Quando vários setores dependem do resultado, a pergunta deixa de ser "VBA ou Python" e passa a ser quem é o dono da automação, onde ficam os logs e quem tem acesso a ela.

Por que tanta rotina da empresa vive em macro

A macro nasce perto do problema. Quem sofre com a tarefa repetitiva é quem conhece a planilha, tem o Excel aberto o dia inteiro e descobre que dá para gravar uma sequência de passos e repetir com um clique. Não precisa pedir orçamento, abrir chamado nem esperar a fila da TI.

Esse é o mérito real do VBA: ele colocou automação na mão de quem opera. O problema está no que acontece depois:

• A rotina ganha usuários. O relatório que era do analista passa a ser esperado pelo gerente, pela diretoria e pelo contador.
• A rotina ganha regras. Cada exceção vira um If a mais, e a lógica de negócio passa a morar em módulos que só uma pessoa leu.
• A rotina ganha dependências. A macro abre outra planilha, numa pasta de rede, com um nome de arquivo fixo, que alguém renomeou na semana passada.

Quando isso acontece, a planilha deixou de ser ferramenta pessoal e virou um pedaço do sistema da empresa, sem ninguém ter decidido isso. É o mesmo movimento descrito em quando trocar planilhas por um sistema, só que com código escondido dentro do arquivo.

O que o VBA faz bem e onde ele quebra

Onde o VBA é a ferramenta certa

• Manipular a própria planilha. Formatar, filtrar, mover dados entre abas, gerar gráficos, preparar a versão de impressão. O VBA conhece o Excel por dentro, e isso é difícil de superar para tarefas desse tipo.
• Interação com o usuário. Um formulário simples, um botão, uma validação na hora em que alguém digita. A pessoa vê o resultado na tela e corrige na hora.
• Zero infraestrutura. Não precisa instalar nada além do Office que a empresa já usa. Para uma tarefa pequena e pessoal, isso pesa muito.

Onde ele começa a quebrar

• Depende de uma sessão do Excel aberta. A macro roda quando alguém abre o arquivo e clica. Agendar execução sem ninguém por perto é possível com improvisos, mas fica frágil.
• Volume. Processar muitos arquivos ou muitas linhas dentro de uma planilha deixa a máquina lenta e aumenta a chance de travamento no meio do processo.
• Integração com outros sistemas. Chamar APIs, ler bancos de dados e tratar formatos como JSON e XML é viável, mas dá trabalho e costuma depender de componentes do Windows que variam de máquina para máquina.
• Políticas de segurança. Muitas empresas bloqueiam ou restringem macros por padrão, porque arquivos com macro são um vetor conhecido de ataque. O comportamento exato depende da versão do Office e das políticas configuradas pela TI; vale confirmar o cenário atual com o fornecedor e com quem administra o ambiente.
• Versionamento. O código fica dentro do arquivo .xlsm. Comparar versões, saber quem mudou o quê e voltar atrás exige disciplina que quase nunca existe.

Se a empresa já tem um sistema inteiro construído em cima de Excel e VBA ou de Access, o problema é maior que uma rotina, e o caminho está em como migrar um sistema Access para a web sem parar a operação.

O que muda com Python: arquivos, APIs, bancos e agendamento

Python é uma linguagem de uso geral, gratuita, com um ecossistema grande de bibliotecas para ler e escrever planilhas, CSV, PDF, XML e JSON, conversar com bancos de dados e chamar APIs. A diferença principal para o VBA não é sintaxe. É que o script não precisa do Excel aberto para existir.

Na prática, isso abre quatro possibilidades:

• Processar arquivos em lote. Ler todos os extratos de uma pasta, todos os XML de nota fiscal do mês ou todos os relatórios exportados por um sistema, consolidar e gerar uma saída única.
• Ler e escrever em sistemas. Buscar dados direto do banco do ERP, de uma API de banco ou de um sistema de mercado que ofereça integração, em vez de depender de alguém exportar e colar.
• Rodar sem ninguém por perto. O script pode ser agendado em um servidor ou em nuvem para rodar toda madrugada, a cada hora ou quando um arquivo novo chegar.
• Ser testado e versionado. O código vive em arquivos de texto, entra num repositório, tem histórico de mudanças e pode ter testes automatizados.

Um exemplo típico é a conciliação: em VBA, costuma virar uma planilha pesada que alguém roda toda manhã; em Python, pode virar um processo agendado que deixa pronta a lista de exceções. O raciocínio completo está em conciliação bancária automática.

Python também tem custos que precisam entrar na conta. Alguém precisa instalar e manter o ambiente, controlar versões de bibliotecas e saber ler o código. Se o script é escrito por um analista e roda no notebook dele, a empresa trocou uma macro frágil por um script frágil. A linguagem mudou; o risco é o mesmo.

Risco operacional: a automação que só roda no computador de uma pessoa

Este é o ponto que mais pesa na decisão e o que menos aparece na conversa. A pergunta certa não é "em que linguagem está", mas "o que acontece se essa máquina ou essa pessoa sumir amanhã".

Sinais de que a rotina já virou risco operacional:

• Só uma pessoa sabe executar. Quando ela falta, o relatório atrasa ou não sai.
• Roda numa máquina específica. Porque lá está instalada a biblioteca certa, o driver do banco ou o atalho para a pasta de rede.
• Ninguém sabe quando falhou. Se a rotina quebrar às três da manhã, alguém só descobre quando o resultado não aparece, e às vezes nem isso, porque o resultado aparece errado.
• Não há registro do que foi feito. Não dá para responder "quais arquivos foram processados ontem" ou "por que esse título foi baixado".
• O resultado alimenta decisões de outras áreas. Comissão, cobrança, compra, folha. Erro ali não é inconveniente; é prejuízo ou retrabalho.

Quando dois ou mais desses sinais aparecem, a automação precisa de três coisas que nem a macro nem o script solto oferecem sozinhos: dono (uma pessoa ou equipe responsável por manter), log (registro de cada execução, com sucesso, falha e o que foi processado) e controle de acesso (quem pode rodar, quem pode alterar, quem vê o resultado). É a mesma lógica de sistema dependente de um único programador: o conhecimento precisa sair da cabeça e da máquina de uma pessoa.

Segurança e manutenção: senhas em planilha, versões e testes

Senhas e credenciais

Para buscar dados de um sistema, a automação precisa de credencial. Em macros, é comum encontrar usuário e senha do banco de dados escritos no código ou numa aba oculta. Em scripts Python, a senha aparece no próprio arquivo ou num texto ao lado. Nos dois casos, quem copia o arquivo leva a senha junto.

O certo é guardar credenciais fora do código, em variáveis de ambiente ou num cofre de segredos, com um usuário de serviço que tenha só a permissão necessária. O tema está detalhado em gestão de segredos: senhas e chaves de API fora do código.

Versões

"Relatorio_final_v3_agora_vai.xlsm" não é controle de versão. Seja qual for a ferramenta, a empresa precisa saber qual versão está em uso, o que mudou e como voltar à anterior se der errado. Com Python, isso é natural com um repositório de código. Com VBA, dá para exportar os módulos e versionar, mas quase ninguém faz.

Testes

Rotinas que mexem com dinheiro ou cadastro merecem testes: arquivos de exemplo com o resultado esperado, rodados a cada alteração, para evitar o clássico "corrigi uma regra e quebrei outra". Python tem ferramentas consolidadas para esse hábito; no VBA, o suporte nativo é pequeno e quase tudo depende de disciplina manual.

Tabela comparativa: macro VBA x script Python x serviço automatizado

A tabela mostra uma escada, não uma competição: subir antes da hora é desperdício; ficar no degrau errado tempo demais é risco.

Quando escolher cada um

Fique com a macro VBA quando

• A tarefa é de uma pessoa, para uso dela, e começa e termina na planilha.
• O resultado não alimenta outra área nem decisão financeira relevante.
• O volume é pequeno e a execução manual não incomoda.
• A política de segurança da empresa permite macros e a TI sabe que elas existem.

Prefira um script Python quando

• A rotina processa muitos arquivos ou muitos registros.
• Os dados vêm de sistemas, bancos ou APIs, e não de alguém colando na planilha.
• A tarefa precisa rodar em horário fixo ou sem ninguém por perto.
• Há alguém com conhecimento técnico para manter o código, e o script vai rodar num ambiente que não depende de um notebook específico.

Transforme em serviço automatizado quando

• Duas ou mais áreas dependem do resultado.
• Uma falha silenciosa gera prejuízo, atraso de pagamento ou erro em cobrança.
• A rotina usa credenciais de sistemas importantes.
• Auditoria, contador ou cliente podem pedir evidência do que foi processado.
• A pessoa que criou a automação é a única que sabe mantê-la.

E quando a ferramenta pronta é a melhor escolha

Antes de escrever qualquer código, vale checar se a rotina já não é resolvida por algo que a empresa tem ou pode contratar. Se o trabalho é importar, limpar e juntar dados de arquivos para dentro de uma planilha, o próprio Excel tem o Power Query, que faz isso com etapas registradas e atualização com um clique, sem macro. Muitos ERPs e sistemas financeiros de mercado oferecem importação de extrato, conciliação, relatórios agendados e APIs de integração. Plataformas de automação low-code, vendidas como serviço, conectam sistemas conhecidos sem programação. Quando o processo é comum e o fornecedor cobre o caso, usar o recurso pronto costuma ser mais barato de manter do que qualquer script. Confirme com o fornecedor o que o produto faz hoje, porque esses recursos mudam com frequência.

O código próprio faz sentido quando a regra é específica da empresa, quando envolve vários sistemas que não conversam entre si ou quando a ferramenta pronta exigiria tantos contornos que o resultado vira outra planilha frágil.

Perguntas frequentes

Python substitui o Excel?

Não. Python não substitui o Excel como ferramenta de análise e consulta do dia a dia; ele substitui a macro quando a rotina precisa processar muitos arquivos, ler sistemas ou rodar sozinha. É comum o script Python ler e gerar planilhas, deixando o Excel como ponto de entrada e de saída para quem usa o resultado.

Preciso saber programar para automatizar com Python?

Sim, alguém precisa. Um script Python exige quem instale e mantenha o ambiente, controle as versões das bibliotecas e entenda o código quando algo mudar. Se o script for escrito por um analista e rodar só no notebook dele, a empresa troca uma macro frágil por um script frágil, com o mesmo risco operacional.

Macro VBA é segura?

Depende de onde vem e de como é usada. Arquivos com macro são um vetor conhecido de ataque, e muitas empresas bloqueiam ou restringem macros por padrão. Além disso, é comum a macro VBA guardar usuário e senha do banco de dados no código ou numa aba oculta, expondo a credencial a qualquer pessoa que copie o arquivo.

O Power Query substitui a macro VBA?

Em parte. O Power Query, que vem no próprio Excel, resolve bem rotinas de importar, limpar e juntar dados de arquivos numa planilha, com etapas registradas e atualização com um clique, sem macro. Formatação, interação com o usuário e automações que vão além de preparar dados continuam pedindo VBA ou outra ferramenta.

Dá para agendar uma macro VBA para rodar sozinha?

Dá, mas fica frágil. A macro VBA depende de uma sessão do Excel aberta, então agendá-la sem ninguém por perto exige improvisos na máquina do usuário. Quando a rotina precisa rodar em horário fixo, um script Python num servidor ou um serviço automatizado com log e alerta de falha costuma ser o caminho mais confiável.

Como a Pervian Tech ajuda a decidir e a tirar a rotina da planilha

Começamos por um diagnóstico inicial gratuito: listamos as rotinas automatizadas que existem, quem depende de cada uma, onde rodam, quais credenciais usam e o que acontece quando falham. Muitas vezes a conclusão é que boa parte delas pode continuar como está, e só algumas precisam mudar de degrau.

Quando a ferramenta que a empresa já tem ou um produto de mercado resolve, recomendamos esse caminho. Quando a rotina tem regra própria ou atravessa vários sistemas, desenhamos a automação como serviço, com dono, log, alerta de falha, controle de acesso e credenciais fora do código. Esse desenho é parte do nosso trabalho de arquitetura de software, e a implementação segue a mesma lógica da nossa solução de automação de processos. Outros exemplos estão na categoria automação do blog.

O trabalho segue em fases: diagnóstico, prova com uma rotina, migração gradual e acompanhamento. O investimento é definido sob consulta, depois de entender as rotinas e os sistemas envolvidos. Se a sua empresa depende de uma planilha com um botão "Processar" que só uma pessoa entende, fale com a gente.