Por que o Odoo Brasil precisava de uma integração bancária nativa

Se você usa Odoo no Brasil, provavelmente já fez essa pergunta: “por que ainda preciso baixar CNAB de Retorno todo dia, ou usar um plugin de terceiro para falar com o meu banco?”. A resposta é uma mistura de boas razões históricas, um trabalho coletivo enorme da comunidade OCA, e um gap real que existia — e que é exatamente onde uma PME em 2026 perde dinheiro.

Este post é honesto sobre o estado da arte. Explica o que a localização brasileira do Odoo cobre, o que não cobria, por que essa lacuna existia, e como a integração da KMEE fecha esse gap hoje.

O que a localização Odoo Brasil já faz muito bem

A localização brasileira do Odoo é mantida principalmente pela OCA (Odoo Community Association) no repositório OCA/l10n-brazil, com versões ativas para Odoo 14, 16, 17 e 18. Foi construída ao longo de mais de uma década pela comunidade open-source brasileira, com a KMEE entre as mantenedoras principais.

O que ela entrega bem hoje, na parte financeira:

• l10n_br_base: CPF/CNPJ, IE, municípios e o modelo res_partner_pix (chaves Pix dos contatos).
• l10n_br_account_payment_order: a peça central. Estende o módulo account_payment_order da OCA para gerar arquivos CNAB 240 e 400, com modos de pagamento, ordens de pagamento (débito e crédito), códigos de instrução/retorno por banco.
• l10n_br_account_payment_brcobranca: gera boletos e arquivos CNAB usando a biblioteca BRCobranca (em Ruby), via micro-serviço REST. Suporta BB, Itaú, Bradesco, Santander, Sicoob, Sicredi, Caixa, Banrisul.
• payment_bacen_pix: módulo experimental para receber pagamentos via QR Code Pix EMV (estático e dinâmico).
• Importação de extratos: usando OCA/bank-statement-import para OFX, CAMT e CSV.

Ou seja, o Odoo Brasil não é um deserto em integração bancária. Ele cobre o caminho clássico: gerar boleto → enviar CNAB Remessa → receber CNAB Retorno → conciliar.

Onde está o gap

O problema é que esse caminho clássico ficou velho. Em 2026, os bancos brasileiros oferecem (em sua maioria) APIs REST modernas, com OAuth2 + mTLS, que permitem:

• Registrar e cancelar boletos em tempo real, com retorno imediato (sem esperar arquivo).
• Emitir QR Code Pix Cobrança (/cob e /cobv) com txid único.
• Receber webhooks quando o cliente paga — em segundos.
• Consultar saldo e extrato sob demanda, sem aguardar batch.
• Iniciar pagamentos em lote (Pix, TED, boletos, tributos) com aprovação no app.
• Emitir cobranças recorrentes via Pix Automático.

E é aqui que a localização Odoo Brasil ainda tem um buraco: não há, hoje, módulo OCA estável que fale OAuth2 + mTLS com cada banco brasileiro de forma nativa. Existem módulos comerciais isolados (TrusteCode, Oitech e outros), normalmente fechados, por banco e pagos por integração.

A consequência prática para PMEs:

• Conciliação demora 1 dia em vez de 1 minuto.
• Boletos emitidos em horário comercial só (CNAB Remessa do dia seguinte).
• Webhooks de Pix recebido não chegam ao Odoo — você descobre olhando o app do banco.
• Cobrança recorrente continua presa ao cartão de crédito (com taxas de 3–5%).
• Uma empresa com 4 bancos precisa de 4 integrações de terceiros, sem padrão entre elas.

Por que esse gap existe (não é por preguiça)

Existem três razões legítimas para a comunidade OCA não ter avançado nisso ainda:

1. As APIs dos bancos brasileiros são muito heterogêneas. Embora todos sigam o Manual API Pix do BCB para a parte Pix, a parte de boleto, extrato e pagamentos é específica de cada banco. Cada um tem onboarding próprio, formato próprio de credencial, fluxo próprio de webhook. Itaú exige certificado ICP-Brasil e gerente; Inter é totalmente self-service; Sicredi exige abrir chamado. Manter 8–10 adapters atualizados é trabalho contínuo, não pontual.

2. A regulação está mudando rápido. Entre 2024 e 2026 saíram a Resolução BCB nº 400/2024 (governança), as Resoluções nº 406 e 407/2024 (Jornada Sem Redirecionamento), a IN BCB nº 615/2025 (Manual de APIs v7.0), a IN BCB nº 706/2026 (Manual de Monitoramento v3.0). Cada nova versão exige ajuste técnico. Comunidade voluntária tem dificuldade de manter ritmo regulatório de banco central.

3. Segurança não é trivial. Armazenar certificados ICP-Brasil A1, gerenciar tokens, garantir mTLS, lidar com rotação de credenciais e LGPD — tudo isso exige arquitetura cuidadosa. Não é um commit num módulo OCA; é um subsistema.

O que entregamos

A nossa aposta foi simples: um módulo Odoo modular que fala OAuth2 + mTLS com os principais bancos brasileiros, mantido com qualidade comercial e contribuído de volta à comunidade onde faz sentido. Hoje ele está pronto, em produção, e instalável no seu Odoo.

A arquitetura, em linhas gerais:

• Um hub central (bank_api_hub) com cliente HTTP genérico que cuida de OAuth2, refresh de token, mTLS, retry com backoff, logging estruturado.
• Adapters por banco (Itaú, Inter, BTG, BB, Sicoob, Bradesco, Santander, Sicredi) que herdam do hub e implementam só os endpoints específicos.
• Receivers de webhook com idempotência por txid e endToEndId — para que cada Pix recebido baixe a fatura instantaneamente.
• Vault de credenciais externo (HashiCorp Vault, AWS Secrets Manager ou módulo keychain da OCA) — sem certificado em texto puro no banco.
• Multi-tenant: para grupos de empresas e consultorias contábeis, credenciais isoladas por (company_id, bank_id, environment).
• Integração com l10n_br_account_payment_order: aproveita tudo o que já existe na OCA. Você continua usando os modos de pagamento, ordens, códigos de instrução. Só que agora o “envio” é uma chamada de API, não um arquivo CNAB.

E onde o banco não tem boa API ou o cliente tem 5+ contas em bancos secundários, plugamos um agregador autorizado pelo BCB (como Pluggy, Belvo ou Celcoin), que entrega Open Finance regulado em uma só conexão. Você paga uma assinatura SaaS em vez de virar instituição regulada — explicamos as duas rotas em Open Finance regulado vs APIs proprietárias.

O que isso muda para a sua empresa

A diferença prática, do ponto de vista de quem opera o financeiro de uma PME, é grande:

• Conciliação cai de 1 dia para minutos — explicamos em Conciliação bancária em tempo real: webhooks vs CNAB.
• Cobrança Pix automatizada, com webhook, tira o “ficar olhando o app do banco” da rotina.
• Pagamentos em lote (folha, fornecedores) viram aprovação dentro do Odoo, com trilha de auditoria.
• Boleto-híbrido (boleto + QR Code Pix no mesmo papel) sai direto do Odoo — veja como funciona.
• Cobrança recorrente via Pix Automático substitui o cartão e elimina chargeback — veja o caso do SaaS.
• Multi-banco: a sua holding com 4 empresas e 6 bancos vê tudo num só painel — explicamos a arquitetura multi-tenant.

E se eu já uso Omie / ContaAzul / Bling / TOTVS?

Esses ERPs ofereciam essa integração há mais tempo — e era por isso mesmo que o Odoo, apesar de muito mais flexível e aberto, perdia clientes de PME para eles em alguns casos. Esse era exatamente o gap que fechamos. E, no caso da TOTVS Protheus especificamente, há um movimento adicional: a TOTVS está descontinuando sua API bancária nativa em 31/03/2026, abrindo uma janela enorme para uma alternativa neutra como o Odoo. Detalhamos em TOTVS está descontinuando sua API bancária — Odoo é a alternativa neutra.

Conclusão

A localização Odoo Brasil é boa. Não era completa. O fato de a comunidade não ter coberto APIs bancárias REST até pouco tempo era um gap real, não uma escolha — e tinha custo concreto para quem operava no Odoo. A boa notícia é que ele foi fechado: OAuth2, mTLS, webhooks dos 10 principais bancos brasileiros, integração com agregadores Open Finance — tudo no mesmo módulo, mantido pela KMEE.

Está rodando Odoo no Brasil e quer entender como integrar com seus bancos a partir de hoje? Conheça nossa oferta de Integração Bancária para Odoo ou marque uma conversa. Em 30 minutos a gente mapeia seu cenário (quais bancos, qual volume, quais ERPs adjacentes) e sai com um plano realista de implantação.

---

Repositório oficial da localização: github.com/OCA/l10n-brazil. Especificações de API Pix do BCB: bacen/pix-api.