O que é o formato OFX e por que ele importa na conciliação bancária

O que significa OFX

OFX é a sigla de Open Financial Exchange: um formato aberto para representar dados financeiros — contas, períodos e lançamentos — de um jeito que qualquer software leia sem saber nada sobre o banco que o emitiu.

Na prática, é um documento de texto puro com marcações parecidas com HTML: dá para abrir um OFX no Bloco de Notas e entender o que está lá dentro. Não é binário, não é proprietário e não exige o programa do banco para ser aberto.

A promessa do formato é a padronização: um sistema contábil lê o extrato do Itaú, do Nubank ou do Sicoob da mesma maneira, porque os três descrevem uma transação com as mesmas etiquetas, na mesma hierarquia. O trabalho de entender o layout de cada banco acontece antes; depois do OFX, é tudo igual.

De onde veio o OFX: a guerra de formatos dos anos 1990

O OFX nasceu em 1997, de um acordo entre três empresas que disputavam o mesmo espaço: a Microsoft, dona do Money; a Intuit, dona do Quicken; e a CheckFree, que processava pagamentos eletrônicos para boa parte dos bancos americanos.

Antes disso, cada uma empurrava o seu dialeto: a Microsoft tinha o OFC (Open Financial Connectivity), a Intuit tinha o seu Open Exchange, e o Quicken importava dados via QIF — um formato de linhas soltas, sem identificador de transação, sem dados da conta e com datas ambíguas. Para o banco, era o pior dos mundos: manter duas ou três integrações para entregar a mesma informação, e escolher um lado numa briga que não era dele.

A fusão desses dialetos num padrão único e publicado é o que fez o OFX pegar. "Aberto", aqui, significa algo concreto: a especificação está escrita e disponível, então quem quer implementar um leitor não depende de licença nem de engenharia reversa. Foi o que permitiu ao formato sobreviver aos produtos que o criaram — o Microsoft Money foi descontinuado há anos e o OFX continuou de pé; hoje a especificação é mantida pela FDX (Financial Data Exchange).

A lição explica o resto deste guia: o OFX não venceu por ser tecnicamente superior, e sim por ser o único que todo mundo podia implementar sem pedir permissão.

A anatomia de um arquivo OFX

Um OFX tem duas partes distintas: um cabeçalho de linhas chave:valor, sem etiqueta nenhuma, e — depois de uma linha em branco — o documento marcado.

O cabeçalho é um bloco de texto simples, e cada linha tem função:

• OFXHEADER:100 — a versão do próprio cabeçalho.
• DATA:OFXSGML — anuncia que o corpo é SGML, e não XML.
• VERSION:102 — a versão da especificação (1.0.2).
• ENCODING e CHARSET — a codificação do texto. O CHARSET:1252 que se vê por aí é a página de código do Windows, herança da época em que acentuação era um problema em aberto.
• SECURITY, COMPRESSION, OLDFILEUID, NEWFILEUID — campos do tempo em que o OFX trafegava por conexão discada; hoje quase sempre NONE.

É esse bloco que muitos ERPs leem primeiro para decidir se aceitam o arquivo. Um OFX sem cabeçalho, ou com uma versão que o sistema não conhece, é recusado antes de a primeira transação ser lida — o que chega ao usuário como um "arquivo inválido" sem mais explicação.

Depois vem o envelope <OFX>, e aqui está a chave do formato: o OFX não foi desenhado para ser um arquivo. Foi desenhado para ser um protocolo — o software ligava para o banco, enviava uma requisição e recebia uma resposta. O arquivo que você baixa hoje é essa resposta congelada em disco. Por isso a hierarquia tem camadas que, num arquivo estático, parecem não servir para nada:

• <OFX> — o envelope de tudo.
  • <SIGNONMSGSRSV1> — o bloco de login. O RS no meio do nome é de Response Set, conjunto de respostas. Dentro dele, <SONRS> (Sign-On Response) traz um <STATUS> com <CODE>0</CODE> — "deu certo", a resposta de uma sessão que, num arquivo baixado, nunca existiu —, além de <DTSERVER>, a hora do servidor, e <LANGUAGE>, que num extrato brasileiro vem como POR.
  • <BANKMSGSRSV1> — o conjunto de respostas bancárias, onde o extrato mora.
    • <STMTTRNRS> — a resposta a um pedido de extrato, com o seu <TRNUID> (o número da requisição original) e outro <STATUS>.
    • <STMTRS> — o extrato em si: a moeda, o bloco <BANKACCTFROM> que identifica a conta e a <BANKTRANLIST>, a lista de lançamentos delimitada por uma data inicial e uma final.

Só no fim dessa descida aparecem os blocos <STMTTRN>, um por transação. Em uma frase: uma resposta de login bem-sucedido, seguida da resposta a um pedido de extrato de uma conta, contendo os lançamentos de um período. Nenhuma camada é decorativa — cada uma existia para um pedaço da conversa entre o programa e o banco.

Isso muda o jeito de depurar um arquivo: quando um ERP diz que "não encontrou transações", a pergunta útil deixa de ser "cadê os lançamentos?" e passa a ser "em que altura da hierarquia isso quebrou?". Para inspecionar ou corrigir campo a campo, o editor de OFX lista o que cada etiqueta significa.

OFX 1.0 (SGML) e OFX 2.0 (XML): por que o Brasil ficou no 1.0

Existem duas gerações do formato, e a diferença está na sintaxe do corpo.

O OFX 1.0 é SGML. A regra que mais espanta quem abre o arquivo pela primeira vez é que as etiquetas de valor não são fechadas: escreve-se <TRNAMT>-150.00 e pula-se a linha — a quebra de linha encerra o campo. Só os blocos que contêm outros blocos, como <STMTTRN>, levam etiqueta de fechamento. Para um validador de XML, isso é um documento malformado da primeira linha à última.

O OFX 2.0, do início dos anos 2000, corrigiu isso adotando XML puro: tudo fechado, declaração no topo, validação por schema. É tecnicamente melhor sob qualquer critério. Ainda assim, o Brasil ficou no 1.0.

O motivo é menos técnico do que parece: quem manda é o lado que importa o arquivo. Os importadores dos ERPs nacionais foram escritos há muitos anos contra o dialeto SGML, e vários nem são parsers de verdade — são leitores de linha, que varrem o texto atrás de <TRNAMT> e pegam o que vier até o fim da linha. Um leitor assim engole o SGML sem reclamar e quebra no XML bem formado, porque o </TRNAMT> final entra junto no valor. O arquivo mais correto é o que falha.

Daí a assimetria que congelou o formato: migrar para o 2.0 não dependia dos bancos, dependia de reescrever o importador de cada sistema contábil em operação — sem ganho nenhum visível para o usuário final. Ninguém reescreve. O 1.0 virou o denominador comum, e quem gera arquivo passou a mirar nele por segurança. É por isso que o nosso conversor emite exatamente OFXHEADER:100, DATA:OFXSGML e VERSION:102: não é apego ao passado, é o dialeto que Conta Azul, Bling, Omie, QuickBooks e a maioria dos ERPs nacionais aceitam sem discussão.

Entre esses dois marcos existem outras versões, cada uma com o seu número no cabeçalho: a referência das versões do OFX lista todas, com data de publicação e link para a especificação oficial.

Por que um formato de protocolo virou o padrão da conciliação

O OFX é reconhecidamente ruim de ler a olho nu, e ninguém abre um para conferir o mês. Mesmo assim ele venceu a conciliação — e a origem como protocolo explica por quê.

Um relatório é escrito para uma pessoa: ele pode abreviar, presumir contexto e confiar em quem lê para entender que aquela coluna é o valor. Uma resposta de máquina, não. Do outro lado da linha havia um programa que precisava agir sozinho, sem ninguém para interpretar nada — e por isso a especificação teve que fixar tudo que um relatório deixa em aberto: como se escreve uma data, onde termina o período, de que conta é aquilo, como reconhecer uma transação já vista antes.

É essa a inversão que importa: as garantias do OFX não foram um recurso pensado para contadores. Elas são subproduto de ele ser a fala de um banco para um computador, e não um documento para gente. O formato serve à conciliação exatamente porque nunca tentou servir ao leitor humano — e é por isso que o extrato conciliável nasceu do protocolo, não do relatório.

Para ver essas garantias medidas contra as alternativas, o guia sobre as diferenças entre OFX, CSV e XLSX compara os três critério a critério.

O OFX no Brasil: onipresente e não-oficial

Por aqui o formato ocupa uma posição curiosa: é exigido por todo mundo e não é norma de ninguém. O OFX não é um padrão da Febraban — o que a Febraban padroniza são os layouts CNAB (240 e 400 posições), e eles servem a cobrança, remessa e retorno de pagamentos, não ao extrato que você concilia no fim do mês. Para o extrato bancário nunca houve norma nacional: o OFX venceu por adoção, porque os softwares de gestão passaram a exigi-lo e os bancos foram atrás.

O ponto em que o padrão americano encontra a realidade brasileira é a identificação do banco: o campo que diz de qual instituição é o extrato espera o código COMPE — os três dígitos do Banco Central, como 341, 237 ou 001 — e não o nome. É a peça mais local de um formato desenhado em Redmond, e também uma das que mais causam importação recusada; os códigos estão listados na página do editor de OFX.

Na prática, os bancos se dividem em dois grupos. Os que exportam OFX nativo direto no internet banking — o caminho fácil, e vale procurar essa opção antes de qualquer outra coisa. E os que só entregam o PDF, ou escondem a exportação atrás de um canal específico: a conta PJ exporta e a PF não; o aplicativo só dá PDF enquanto o internet banking dá OFX; a conta vinculada, de investimento ou de adquirência não exporta nada. Nesse segundo grupo, transformar o PDF em OFX é o único caminho sem digitação — é o que o conversor de extrato para OFX faz para o Banco do Brasil, Bradesco, Caixa e mais de 40 outras instituições.

O que o OFX não resolve

As fraquezas do formato são todas do mesmo tipo: o OFX transporta o fato, não o significado do fato.

• Não existe categoria. O arquivo diz que saíram R$ 340,00 e que o histórico é "PAGAMENTO FORNECEDOR"; não diz que isso é matéria-prima, e nem tenta. A classificação contábil é sempre trabalho do seu lado — nenhum extrato, em formato nenhum, adivinha o seu plano de contas.
• O histórico é texto livre. Não há gramática alguma no campo de descrição: cada banco escreve como quer, com as próprias abreviações, e o mesmo evento vira "PIX ENVIADO" num banco e "PIX-ENV" noutro, às vezes truncado no meio. É o que mais frustra quem automatiza regras de categorização — e a razão de essas regras precisarem de ajuste banco a banco.
• Saldo por linha não existe. A especificação prevê o saldo do período, mas aquela coluna "Saldo" que corre ao lado de cada lançamento no PDF não faz parte do formato — e o que cada banco de fato preenche varia. Quem concilia conferindo o saldo corrido precisa somar os lançamentos, o que fica fácil abrindo o OFX em Excel.
• Não há documento anexo. Comprovante, nota fiscal, chave do Pix: nada disso viaja no arquivo. O OFX é o esqueleto da movimentação, não o dossiê dela.

Nada disso tira dele o posto de melhor formato para levar um extrato para dentro de um sistema. Só delimita o que esperar: transporte e identidade resolvidos com precisão, interpretação por sua conta. Quando a importação dá errado, o problema quase nunca está nessas limitações — está em detalhes de preenchimento, e o guia de erros comuns ao importar OFX cobre os mais frequentes. Se o que você tem em mãos ainda é o PDF do banco, o passo a passo da conversão mostra o caminho.