Conferir antes de importar
Ver quantos lançamentos existem, qual o período e quanto dá o líquido, antes de o movimento entrar no sistema contábil. Depois de importado, corrigir custa muito mais.
Envie o OFX que o banco gerou e receba uma planilha .xlsx ou um CSV com um lançamento por linha: Data, Histórico, Documento, Valor e Tipo. É para quando você tem o arquivo certo para importar, mas precisa olhar o movimento antes — conferir, filtrar, somar — fora do sistema contábil.
Converter e conferir são gratuitos. O crédito só é debitado quando você baixa o arquivo.
Sem cadastro para testar. O arquivo é processado na memória e descartado — não guardamos o seu extrato.
o formato
Esta é a explicação que quase ninguém dá, e é a razão de o arquivo ser tão difícil de abrir com ferramenta genérica. O OFX é descrito como formato baseado em tags, o que leva muita gente a tratá-lo como XML e a tentar renomeá-lo para .xml. Não funciona.
Na versão 1.x, as tags de valor não são fechadas. Uma linha de valor é assim:
<STMTTRN>
<TRNTYPE>DEBIT
<DTPOSTED>20260301120000[-3:BRT]
<TRNAMT>-89.90
<MEMO>PIX ENVIADO
</STMTTRN> Não existe </TRNAMT>: o valor termina na quebra de linha. Isso é SGML válido e OFX 1.x perfeitamente correto — e é XML inválido. Um analisador de XML não recupera desse erro: ele rejeita o arquivo inteiro, não a linha. Só o OFX 2.x é XML de verdade, com todas as tags fechadas e prólogo declarado.
Como os bancos brasileiros exportam quase sempre a versão 1.0.2, a leitura aqui é feita por varredura de tags, que funciona nas duas versões. É menos elegante que usar uma biblioteca de XML pronta. É também a única forma de ler o arquivo que o seu banco realmente emite.
a leitura
Cada lançamento do OFX é um bloco <STMTTRN>. Destes campos sai a planilha:
Do cabeçalho do arquivo vêm ainda o código e o nome da instituição, a agência, a conta, o período declarado e o saldo — usados para identificar o extrato, não para preencher a planilha.
as armadilhas
O padrão OFX é de meados dos anos 1990 e cada banco o implementou do seu jeito. Estas são as divergências que aparecem em arquivo de banco brasileiro e que quebram a leitura ingênua:
quando usar
Quem chega aqui não tem problema de importação — tem o arquivo certo. O problema é que o OFX é escrito para o software, não para o leitor. Estes são os casos:
Ver quantos lançamentos existem, qual o período e quanto dá o líquido, antes de o movimento entrar no sistema contábil. Depois de importado, corrigir custa muito mais.
Quando a importação falha sem dizer o motivo, olhar o conteúdo do arquivo é o primeiro passo — datas fora do período, lançamentos do dia corrente, histórico vazio.
Conciliar com o contas a pagar, mandar o movimento para um cliente que não tem sistema contábil, ou simplesmente filtrar e somar. Nada disso se faz em OFX.
a planilha
Cinco colunas, uma linha por lançamento: Data em DD/MM/AAAA, Histórico, Documento, Valor e Tipo. O valor sai como número, com o sinal do lançamento — débito negativo — para que somar a coluna devolva o líquido do período direto.
No .xlsx a coluna de valor já vem com formato numérico brasileiro e as larguras ajustadas. No CSV, o separador é ponto e vírgula e o arquivo leva BOM UTF-8, que é o que faz o Excel em português abrir sem corromper a acentuação do histórico. O detalhe de cada um está na página sobre converter PDF para Excel.
outros caminhos
perguntas
Porque o OFX não é um formato de planilha. E, na versão que os bancos brasileiros usam, ele também não é XML: é SGML, uma estrutura de tags em que as tags de valor não são fechadas. Renomear o arquivo para .xml não resolve — qualquer leitor de XML rejeita o arquivo inteiro na primeira tag sem fechamento.
Depende da versão. O OFX 2.x é XML de verdade, com prólogo e todas as tags fechadas. O OFX 1.x é SGML: uma linha como <TRNAMT>-89.90 termina na quebra de linha, sem </TRNAMT>. Os bancos brasileiros exportam quase sempre a versão 1.0.2, que é 1.x — por isso a ferramenta genérica de XML falha na prática, mesmo que o padrão OFX apareça descrito como XML.
Quase sempre a 1.0.2. É a mesma versão que o Convertou gera quando o caminho é o inverso, porque é a que os sistemas contábeis brasileiros esperam na importação. A leitura aqui é feita por varredura de tags, que funciona nas duas versões — 1.x e 2.x — em vez de depender de um analisador de XML.
Sim. O OFX 1.x declara a codificação no cabeçalho, e os bancos brasileiros gravam mesmo em Windows-1252. Ler o arquivo como UTF-8 corrompe todo acento do histórico. O leitor inspeciona o cabeçalho antes de decidir como decodificar, e trata o caso do OFX 2.x, que declara a codificação no prólogo XML.
É aceito. O padrão OFX manda ponto decimal, mas há bancos brasileiros que gravam vírgula — o Bradesco é o caso conhecido. Recusar um arquivo que o próprio banco emitiu não ajudaria ninguém, então as duas formas são lidas.
O sinal do valor manda. Há bancos que gravam CREDIT em lançamento com valor negativo; o valor negativo é inequívoco e o tipo declarado não é. O tipo declarado só decide quando o valor é exatamente zero.
Ele não some em silêncio. Um lançamento sem data ou sem valor legível é registrado como aviso, com o trecho do arquivo, para você ver o que ficou de fora. Um arquivo sem nenhum lançamento reconhecível é recusado com essa mensagem, em vez de gerar uma planilha vazia.
Não. O OFX é processado na memória e descartado ao fim da conversão. Não é gravado em disco, não vai para banco de dados e não vai para armazenamento em nuvem.