# Macro VBA ou Python: qual usar para automatizar a rotina

> Macro VBA ou Python? Veja onde cada um funciona, o risco da automação que só roda num computador e quando a rotina precisa virar serviço com dono e log.

Fonte: https://pervian.tech/blog/macro-vba-ou-python · Pervian Tech · publicado em 2026-10-01

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](https://pervian.tech/blog/substituir-planilhas-por-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](https://pervian.tech/blog/modernizar-sistema-em-access-ou-vba).

## 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](https://pervian.tech/blog/conciliacao-bancaria-automatica).

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](https://pervian.tech/blog/sistema-dependente-de-um-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](https://pervian.tech/blog/senhas-e-chaves-de-api-no-codigo).

### 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

| Critério | Macro VBA | Script Python | Serviço automatizado |
|---|---|---|---|
| Onde roda | Dentro do Excel, na máquina do usuário | Na máquina de alguém ou num servidor | Em servidor ou nuvem, com ambiente controlado |
| Quem dispara | Uma pessoa, com um clique | Uma pessoa ou um agendador | Agendamento, evento ou outro sistema |
| Melhor para | Tarefa individual dentro da planilha | Lote de arquivos, leitura de sistemas e bancos | Rotina da qual vários setores dependem |
| Integração com APIs e bancos | Possível, mas trabalhosa | Natural | Natural, com tratamento de falhas |
| Volume | Limitado pela planilha e pela máquina | Bom | Bom, e pode escalar |
| Log e monitoramento | Raro | Depende de quem escreveu | Parte do projeto, com alerta de falha |
| Controle de acesso | O de quem abre o arquivo | O de quem acessa a máquina | Por usuário, função e permissão |
| Versionamento e testes | Difícil | Natural, se houver disciplina | Obrigatório |
| Custo de começar | Muito baixo | Baixo | Maior: exige projeto e manutenção |
| Risco se a pessoa sair | Alto | Alto, se rodar na máquina dela | Baixo, se houver dono e documentação |

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](https://pervian.tech/servicos/arquitetura-de-software), e a implementação segue a mesma lógica da nossa solução de [automação de processos](https://pervian.tech/solucoes/automacao-de-processos). Outros exemplos estão na categoria [automação](https://pervian.tech/blog/categoria/automacao) 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](https://pervian.tech/#contato).