Um agente de conciliação bancária é um sistema de software que lê o extrato do banco em formato OFX, lê os lançamentos registrados no ERP e tenta casar cada transação bancária com o lançamento correspondente, apontando o que sobrou nos dois lados. Na versão com IA, o agente não só compara valores exatos: ele usa um modelo de linguagem para ler o histórico das transações, reconhecer padrões e propor o pareamento quando os valores não batem ao centavo. O que separa um agente sério de um brinquedo é o desenho das etapas de aprovação humana, que continuam obrigatórias.
O ponto de partida técnico é o formato OFX, um padrão aberto de troca de dados financeiros que existe desde 1997 e é mantido hoje por um consórcio ligado à Financial Data Exchange (FDX). Sem entender o que vem dentro do arquivo OFX e como ele difere de um CSV, não dá para projetar o cruzamento com as faturas do ERP.
Resumo rápido
- O que é: agente que cruza extrato bancário em OFX com os lançamentos do ERP.
- Formato OFX: padrão aberto de troca de dados financeiros, XML nas versões 2.x.
- OFX x CSV: OFX traz estrutura e tipos definidos; CSV traz só texto delimitado.
- Papel da IA: casar transações quando o valor não bate exatamente e ler históricos.
- Regra de ouro: aprovação humana obrigatória antes de qualquer baixa no ERP.
- Integração: por exportação e importação de arquivo; webhooks só quando documentados.
O que é o formato OFX
OFX é a sigla de Open Financial Exchange, um padrão aberto para sistemas cliente-servidor e APIs em nuvem trocarem dados financeiros e executarem transações entre instituições financeiras e aplicações. Ele foi anunciado em 16 de janeiro de 1997 pela Microsoft, pela Intuit e pela CheckFree, e a primeira especificação saiu em 14 de fevereiro do mesmo ano, segundo a página oficial do OFX mantida pela FDX em financialdataexchange.org/about-fdx/ofx-work-group.
Três fatos do padrão importam para quem vai montar o agente:
- A sintaxe mudou. As versões 1.0 a 1.6 usavam SGML. A partir da versão 2.x, o OFX passou a ser baseado em XML. Na prática, um arquivo OFX moderno tem tags e uma estrutura que qualquer parser de XML consegue ler.
- A governança mudou. Em 2019, o consórcio do OFX passou a integrar a Financial Data Exchange (FDX), que hoje mantém a especificação. A FDX descreve sua missão como unificar o setor financeiro em torno de um padrão comum para acesso seguro e permissionado a dados financeiros de consumidores e empresas.
- A especificação é pública. A FDX publica a especificação em PDF. Hoje ela é dividida em OFX Banking 2.3 e OFX Tax 2026.0, e a versão de banco pode ser baixada em OFX Banking Specification v2.3.
A autenticação também evoluiu. A partir do OFX 2.2, o padrão passou a oferecer um modelo de autenticação por token OAuth, além dos mecanismos anteriores. Isso interessa diretamente a quem constrói agentes que puxam extrato do banco, porque afeta como o agente se autentica na fonte.
O que vem dentro de um arquivo OFX
Um arquivo OFX de extrato de conta traz, em estrutura, duas partes principais. Uma seção de identificação da conta e do período, e uma lista de transações. Cada transação, por sua vez, carrega campos padronizados, e são esses campos que o agente usa para o cruzamento.
| Elemento OFX | O que representa | Uso no agente |
|---|---|---|
| Banco e conta | Instituição e número da conta | Saber de qual conta veio o extrato |
| Período (data inicial e final) | Janela de tempo do extrato | Definir o intervalo a conciliar |
| Transação | Uma linha de lançamento | Unidade de cruzamento |
| Identificador da transação | Código único daquela linha | Evitar conciliar a mesma linha duas vezes |
| Tipo | Débito, crédito ou outro | Saber o lado do dinheiro |
| Data | Data da transação | Janela de busca do par no ERP |
| Valor | Montante da transação | Estoque da tolerância de diferença |
| Nome e memória | Contraparte e histórico | Campo principal de trabalho da IA |
O campo de memória (o histórico da transação) é onde a IA mais agrega. É nele que aparece, por exemplo, o nome de um fornecedor abreviado, um número de nota ou uma referência a um contrato, informação que o casamento por valor exato não aproveita.
OFX e CSV: por que não são a mesma coisa
Muitos bancos oferecem exportação tanto em OFX quanto em CSV, e a diferença entre os dois muda o desenho do agente.
| Critério | OFX | CSV |
|---|---|---|
| Estrutura | Campos definidos por especificação | Linhas e colunas definidas pelo banco |
| Tipo dos dados | Padronizado pelo padrão | Depende do layout do arquivo |
| Identificador de transação | Faz parte da estrutura | Pode existir ou não, a critério do banco |
| Diferenças entre bancos | Menores, por usar o mesmo padrão | Grandes, cada banco formata do seu jeito |
| Uso típico no agente | Fonte mais estável e estruturada | Precisa de parsing por banco |
O OFX tende a dar menos dor de cabeça porque a especificação padroniza os nomes e os tipos dos campos. Um CSV, por outro lado, é só texto com separadores, e cada banco decide o layout: ordem das colunas, formato de data, uso de vírgula ou ponto no decimal. Isso obriga a escrever e manter um parser por banco, o que é o tipo de trabalho que ninguém quer multiplicar.
A arquitetura do agente de conciliação
Um agente de conciliação bancária bem desenhado separa o que é determinístico do que é probabilístico. Casamento exato de valor com data não precisa de IA. Já o pareamento aproximado é onde o modelo de linguagem ajuda. A arquitetura abaixo trata cada camada com a ferramenta certa.
- 1. Ingestão. Receber o arquivo OFX do banco e os lançamentos exportados do ERP. Registrar origem, período e conta.
- 2. Parsing do OFX. Ler a estrutura do arquivo e extrair conta, período e a lista de transações com todos os campos.
- 3. Normalização. Converter valores para número e datas para um formato único, para que banco e ERP falem a mesma língua.
- 4. Casamento exato. Casar as transações em que valor, data e tipo batem sem ambiguidade. Etapa puramente de regra, sem IA.
- 5. Casamento assistido por IA. Nas transações que sobraram, o modelo lê o histórico e propõe o par mais provável, com um grau de confiança.
- 6. Fila de revisão. Tudo que a IA propôs e tudo que ficou sem par vai para uma fila humana, nunca direto para o ERP.
- 7. Aprovação humana. Uma pessoa confirma ou rejeita cada proposta. Só o que for aprovado gera efeito no sistema.
- 8. Baixa no ERP. A conciliação aprovada é aplicada, por importação de arquivo ou pelo mecanismo que o ERP oferecer.
- 9. Log e auditoria. Registrar quem aprovou o quê, quando e com base em qual sugestão.
A ordem importa. O casamento exato primeiro reduz o volume que chega à IA, e a IA reduz o volume que chega ao humano. Cada camada existe para poupar a seguinte.
Onde a IA realmente ajuda
Vale ser específico sobre o que a IA faz bem nesse fluxo, e o que ela não deve fazer.
Onde ajuda: casar uma transação bancária com um lançamento do ERP quando o valor bate mas a data tem poucos dias de diferença; reconhecer que um histórico abreviado do banco, como o nome de uma operadora de cartão, corresponde a um lançamento lançado com outro nome no ERP; agrupar estornos e tarifas; e sugerir o plano de contas mais provável para um lançamento sem par.
O que não deve fazer: dar baixa definitiva sem revisão, decidir sozinho em casos de valor alto ou fora do padrão, e reescrever lançamentos contábeis. A IA propõe, a pessoa decide. Isso não é uma limitação temporária: é uma decisão de controle, coerente com o princípio contábil de que cada lançamento precisa de responsável.
As etapas de aprovação humana obrigatórias
O desenho das aprovações é o que impede o agente de virar um passivo. Um arranjo defensável tem três níveis de controle.
| Etapa | O que acontece | Regra de bloqueio |
|---|---|---|
| Revisão do casamento exato | Amostragem das conciliações automáticas | Sinalizar se a taxa de erro amostral subir |
| Revisão do casamento por IA | Humano confirma ou rejeita cada proposta | Nada entra no ERP sem aprovação explícita |
| Alçada por valor | Transações acima de um limite exigem aprovador sênior | Bloqueio automático acima do teto |
A alçada por valor é a peça mais prática. Uma tarifa de alguns reais pode ser aprovada em lote. Já uma transferência de valor alto nunca deveria depender só da confiança no modelo. Definir esse teto é uma decisão de gestão, não de tecnologia, e deve sair da política de controles internos da empresa.
Integração com o ERP
Aqui vale uma ressalva importante: não existe uma resposta única de integração, porque cada ERP tem seu próprio conjunto de recursos, e inventar nomes de APIs de sistemas específicos seria errar o alvo. O que se pode afirmar com segurança é o padrão geral.
Por arquivo. O caminho mais universal e mais fácil de auditar. O agente gera um arquivo em um formato que o ERP aceita, geralmente CSV ou um layout de importação padronizado, e uma pessoa faz a importação. Essa abordagem tem uma vantagem de controle: a importação é um ato deliberado, com um arquivo rastreável.
Por integração direta. Quando o ERP oferece interface programática documentada, o agente pode enviar as conciliações aprovadas sem passagem manual pelo arquivo. Isso só deve ser feito sobre uma API que o próprio fornecedor documenta, seguindo as regras dele de autenticação e de limite de uso.
Por webhooks. Webhooks servem para o ERP avisar o agente de um evento, como um lançamento novo aprovado. Mas webhook é recurso que precisa estar documentado pelo fornecedor para existir. Só conte com ele quando a documentação oficial do ERP confirmar o recurso. Se a recepção de eventos vier por webhook, vale tratar a validação do evento como assunto de segurança, como se discute em webhooks: validar assinatura.
Em qualquer um dos casos, o dado financeiro passa por sistemas diferentes, e isso exige cuidado com quem tem acesso ao quê. Sobre esse ponto, vale ler o material do portal sobre segurança e LGPD na implantação de IA.
Exemplo: transportadora em Goiânia com cartão corporativo
Considere uma transportadora de médio porte em Goiânia que dá cartão corporativo a dezenas de motoristas. As compras de combustível e pedágio aparecem na fatura do cartão e no extrato da conta que paga a fatura, enquanto a equipe financeira lança cada despesa no ERP à mão, a partir de notas e comprovantes.
O agente entra em duas frentes. Na primeira, ele lê o extrato em OFX da conta e tenta casar cada pagamento da fatura com o lançamento correspondente. Na segunda, ele olha as transações individuais do cartão e propõe o centro de custo e o motorista para cada uma, com base no histórico e no nome do estabelecimento. O que não bate entra numa fila de revisão, e o financeiro aprova ou corrige.
O ganho está em reduzir o tanto de linha que chega à mão humana, não em eliminar a conferência. É um cenário ilustrativo, para mostrar o critério de desenho. Quanto de fato se economiza depende do volume de transações, da qualidade dos históricos e de quanto o ERP aceita receber de forma automática, e só um piloto com os dados reais responde isso.
Erros comuns
- Dar baixa automática no ERP. Conciliar sem aprovação humana transforma qualquer erro do agente em erro contábil registrado.
- Tratar OFX e CSV como iguais. O OFX tem estrutura padronizada; o CSV muda de banco para banco e exige parser próprio.
- Ignorar a versão do OFX. Versões 1.x usam SGML, versões 2.x usam XML. Ler uma com o parser da outra quebra.
- Presumir webhook do ERP sem documentação. Só use integração por evento se o fornecedor documentar o recurso.
- Não guardar o identificador da transação. Sem ele, a mesma linha pode ser conciliada duas vezes.
- Deixar a IA decidir em valores altos. Defina alçada por valor e bloqueie o que passar do teto.
- Cruzar sem normalizar data e valor. Banco e ERP em formatos diferentes geram milhares de falsos não casados.
Perguntas frequentes
O que é OFX, em uma frase?
É um padrão aberto para trocar dados financeiros entre bancos e aplicações, criado em 1997 e hoje mantido pela Financial Data Exchange. Nas versões 2.x, o arquivo é baseado em XML, o que facilita o parsing.
OFX é melhor que CSV para conciliação?
Em geral sim, porque a especificação padroniza os campos e reduz as diferenças entre bancos. O CSV depende do layout de cada instituição, o que obriga a escrever um parser por banco. Se você pode escolher, o OFX tende a dar menos manutenção.
O agente pode dar baixa sozinho no ERP?
Não deveria. O desenho recomendado é que o agente proponha o casamento e uma pessoa aprove. A baixa só acontece depois da aprovação, com log de quem aprovou e com base em qual sugestão.
Preciso de IA para conciliar?
Não para o casamento exato, que é regra pura. A IA ajuda no que sobra: casar com pequenas diferenças de data, ler históricos abreviados e sugerir contas. É um complemento, não um substituto da lógica determinística.
Como integrar com o meu ERP?
O caminho mais universal é por arquivo: o agente gera um CSV ou um layout de importação e uma pessoa importa. Integração direta só quando o fornecedor documenta uma API, e webhooks apenas quando o recurso existe na documentação oficial.
Isso serve para faturas de cartão de crédito?
Sim. O mesmo desenho vale para cruzar a fatura do cartão com os lançamentos do ERP e com o extrato que paga a fatura. A diferença está nos campos disponíveis, que variam conforme o que o banco e o ERP exportam.
