RPA de planilha vs motor de match aprendido: por que RPA falha

Empresa contratou consultoria de RPA pra automatizar conciliação. Bot abre planilha, copia célula, cola noutra planilha, faz cruzamento. Funcionou nos 2 primeiros meses. Mês 3, adquirente mudou layout do relatório. Bot quebrou. Mês 4, novo relatório de Pix. Bot quebrou de novo.

Controller pergunta: "vale ficar mantendo RPA ou tem alternativa?". Sim, tem — e a diferença é estrutural. RPA é automação superficial. Motor de match aprendido é automação por compreensão. Por isso RPA falha previsivelmente.

O que RPA de planilha entrega

RPA (Robotic Process Automation): bot que imita ação humana em interface (cópia, colagem, cliques).

Pontos fortes:

• Sem mudar sistema: roda em cima de qualquer ERP
• Rápido pra implementar: dias-semanas
• Visível: humano vê o bot trabalhando
• Custo inicial baixo: ferramentas comoditizadas
• Não exige TI integrar API: trabalha em interface

Pontos fracos:

• Frágil: mudança de layout quebra
• Sem compreensão: bot não sabe o que está fazendo, só como clicar
• Manutenção alta: cada mudança = re-script
• Casos novos quebram: se aparece transação tipo X que bot não viu, falha
• Logs ruins: difícil entender por que bot errou
• Não aprende: repete erro indefinidamente

O que motor de match aprendido entrega

Sistema que entende transação (não interface): valor, data, descrição, fonte, padrão.

Pontos fortes:

• Robusto a mudança de layout: modelo lê dado, não interface
• Compreensão de transação: sabe que "antecipação Cielo" = padrão específico
• Casamento difícil: valor próximo, data deslocada, IA decide
• Aprende: padrão emerge, classificação melhora
• Auditável: decisão tem trilha por regra/modelo
• Lida com formato novo: modelo generaliza

Pontos fracos:

• Custo inicial maior: licença + configuração
• Curva de adoção: controller precisa confiar
• Dependência de fornecedor: modelo, atualizações, suporte

A comparação direta

| Critério | RPA | Motor de match | |---|---|---| | Robustez a mudança | Frágil | Robusta | | Casamento difícil | Limitado | Forte | | Aprendizado | Não | Sim | | Manutenção | Alta | Baixa | | Auditabilidade | Limitada | Forte | | Logs | Frágeis | Estruturados | | Tempo até falhar | 2-6 meses | Anos |

A diferença não é "10% melhor". É arquitetural.

Por que RPA falha previsivelmente

RPA opera em interface. Interface é instável:

• Adquirente atualiza layout do relatório → bot quebra
• ERP roda atualização → bot quebra
• Janela vira pop-up → bot quebra
• Coluna muda de posição → bot quebra

Cada mudança exige re-script. Empresa que adota RPA contrata manutenção contínua. Custo escondido é grande.

Motor de match opera em dado. Dado é estável:

• Adquirente muda layout mas continua mandando "valor, data, descrição, status"
• Motor lê os campos por significado, não por posição
• Mudança de layout não quebra
• Novo padrão é aprendido, não quebrado

A diferença é a camada onde a automação acontece.

O exemplo concreto

Stone muda relatório de antecipação. Adiciona coluna "ajuste regional" entre "taxa base" e "taxa de operação".

Com RPA:

• Bot tava configurado pra ler "taxa base" da coluna 5, "taxa de operação" da coluna 6
• Agora coluna 5 = "taxa base", coluna 6 = "ajuste regional", coluna 7 = "taxa de operação"
• Bot pega valor errado, soma errado, conciliação errada
• Controller percebe semana depois
• Consultoria re-scriptiza bot
• 2-4 dias perdidos

Com motor de match:

• Modelo lê pela descrição da coluna, não posição
• "Taxa de operação" continua "taxa de operação", onde quer que esteja
• Conciliação segue
• Modelo registra novo campo "ajuste regional" automaticamente
• Zero impacto operacional

Diferença em uma mudança. Em ano, dezenas dessas em adquirentes diferentes.

Quando RPA ainda faz sentido

Sinais consolidados:

• Volume baixo, mudanças raras
• Fonte de dado muito estável (sistema interno fechado)
• Sem orçamento pra motor dedicado
• Curva de aprendizado limitada
• Fluxo simples (sem casamento difícil)

Tipicamente: tarefa interna fechada, não conciliação multi-fonte.

Quando motor de match virou prioridade

Sinais consolidados:

• 3+ fontes de dado (adquirente, banco, marketplace)
• Mudanças frequentes nos relatórios
• Casamento difícil aparece (valor próximo, data deslocada)
• Volume crescente
• RPA atual quebrando recorrentemente

Quando 2+ presentes, motor de match vira ROI imediato.

O erro comum

Erro 1: empresa investe em RPA pra conciliação. Em 6-12 meses, custo de manutenção come economia.

Erro 2: empresa adia motor de match "porque RPA tá rodando". Em 12-24 meses, descobre que pagou consultoria por aluguel + custo de erro acumulado.

A virada é aceitar que RPA não foi feito pra conciliação multi-fonte.

O que NÃO resolve

• RPA "mais sofisticado". Mesma arquitetura, mesmo problema.
• Consultoria pra manter bot. Custo crescente, ROI decrescente.
• Continuar manualmente. Já vimos esse filme.

O que resolve é motor de match aprendido — IA que entende transação, não interface.

Quando vale priorizar a virada

Sinais:

• RPA quebra mais de 2x por trimestre
• Custo de consultoria de RPA crescendo
• Conciliação ainda atrasada apesar do RPA
• Adquirentes novos chegando

Quando 2+ presentes, migrar é estratégico.

Próximo passo

Motor de match aprendido (IA entende transação, generaliza padrão, aprende) é o caminho honesto pra conciliação multi-fonte robusta. A FELGOR Match implementa esse fluxo. Se quiser ver aplicado no contexto da sua operação, agende um diagnóstico de 30 minutos com os fundadores.