O Problema da Caderneta de Papel
Custa às PMEs Japonesas Mais do que Imaginam
Em 2024, 42,8% dos pagamentos de consumo no Japão foram sem dinheiro — um recorde impulsionado por PayPay, Suica e reembolsos do governo. Entre em qualquer banco japonês, no entanto, e o caixa eletrónico ainda emite um livrete de papel. A caderneta bancária (通帳, tsūchō) — um registo impresso atualizado linha por linha em máquinas que datam dos anos 1970 — continua a ser o principal registo de atividade financeira para cerca de 120 milhões de contas do Japan Post Bank e dezenas de milhões mais em megabancos como MUFG e SMBC. Para o pequeno empresário que apresenta uma declaração de imposto azul (青色申告) que exige contabilidade por partidas dobradas em Yayoi Accounting (弥生会計) ou freee, cada uma dessas linhas impressas deve tornar-se uma entrada de diário digital. A ponte entre os dois é um ser humano num teclado, olhando a uma columna de 5 cm × 7 cm de códigos japoneses abreviados e tentando decidir o que cada um significa.
Principais Conclusões
- Cada linha da caderneta exige que primeiro decodifique um ano de era e um código de abreviatura específico do banco antes de poder digitar um único dígito — a digitação nunca foi o gargalo, o trabalho de tradução oculto era.
- Se falte a uma visita regular ao caixa, 合計記帳 elimina permanentemente as transações individuais da sua caderneta — uma optimização de espaço que destrói os seus dados exatamente quando os estados financeiros trimestrales dependem deles.
- Um dígito mal lido em qualquer linha da caderneta corrompe silenciosamente todos os saldos que se seguem em todas as páginas subsequentes — e o erro permanece oculto até que o seu software de contabilidade se recuse a conciliar.
O Paradoxo da Caderneta: Um Documento dos Anos 1970 em um Fluxo de Trabalho Contábil de 2024
O Japão é a única economia desenvolvida onde cadernetas bancárias físicas continuam sendo um instrumento financeiro de massa. Entre em uma agência do MUFG ou SMBC e o caixa eletrônico imprimirá suas transações mais recentes diretamente em um livreto encadernado — cinco colunas em uma cabeça de impressão matricial: data (月日), código de descrição (摘要), valor de saque (お支払金額), valor de depósito (お預り金額) e saldo corrente (差引残高). O formato foi projetado em uma era em que caixas bancários verificavam saldos manualmente e o conceito de exportação em CSV não existia. Ele não mudou significativamente desde então.
No entanto, o software de contabilidade que as pequenas empresas japonesas usam — Yayoi Accounting (弥生会計), usado por mais de 700.000 empresas; freee, o líder de contabilidade em nuvem com 450.000 clientes pagantes; e MoneyForward Cloud, com 442.000 empresas pagantes — opera com uma premissa fundamentalmente diferente. Ele pressupõe que os dados de transações chegam digitalmente. Importação de CSV, feed de API bancária ou regras automatizadas de escrituração. A caderneta viola todas essas premissas ao mesmo tempo.
Isso não é um problema de "letramento digital" nem um clichê de "Japão atrasado". É um descompasso de formato de documento: a infraestrutura que registra a atividade financeira e a infraestrutura que a contabiliza foram construídas com 50 anos de diferença por indústrias diferentes que nunca precisaram conversar entre si — e sobra para uma pessoa fazer a ponte lendo e redigitando.
Somente o Japan Post Bank (ゆうちょ銀行) detém aproximadamente 120 milhões de contas — quase uma por cidadão. MUFG, SMBC e Mizuho detêm coletivamente dezenas de milhões a mais. A maioria dessas contas ainda emite uma caderneta de papel por padrão. Mesmo clientes que ativaram o internet banking costumam ter ambos: a interface digital para consultas diárias, a caderneta como registro definitivo. Para o profissional autônomo (個人事業主) que declara a declaração azul (青色申告) — que concede uma dedução especial de ¥650.000 nos termos do Artigo 143 da Lei do Imposto de Renda em troca de escrituração contábil adequada em partidas dobradas — cada transação em cada página da caderneta deve ser rastreável até um lançamento contábil. A caderneta não é opcional. Ela é a trilha de auditoria.
O problema estrutural, dito claramente: um documento projetado para um caixa humano verificar um saldo a olho nu está sendo usado como fonte primária de dados para um software projetado para feeds de transações legíveis por máquina. O descompasso é absoluto, e o custo recai inteiramente sobre a pessoa diante do teclado.
O Trabalho Real Não É Digitar — É Traduzir
A forma padrão de enquadrar o problema de lançamento de dados de caderneta é "demora muito para digitar". Esse enquadramento está errado, e está errado de uma forma que esconde onde o esforço realmente vai. A velocidade de digitação não é o gargalo. O gargalo é que cada linha de uma caderneta exige uma série de traduções cognitivas antes que uma única tecla possa ser pressionada.
Leia uma única linha da caderneta em voz alta para si mesmo e conte as decisões:
Decodifique o ano da era. A caderneta imprime "R6.3.15" — Reiwa 6, 15 de março. Reiwa 6 é 2024 no calendário gregoriano. Mas Reiwa começou em 1º de maio de 2019, então Reiwa 1 tem apenas 8 meses. E Heisei 31 (que durou de janeiro a abril de 2019) também é 2019. Nenhum aplicativo de calculadora faz essa conversão; você faz de cabeça.
Decodifique o código de descrição. A coluna 摘要 lê "振込IB1". Essa é a abreviação interna do MUFG para uma transferência de internet banking para esta conta. Mas no Japan Post Bank (ゆうちょ銀行), um depósito de salário aparece como "振込" — ou às vezes apenas "給与" se o empregador o enviou via uma mensagem eletrônica específica de folha de pagamento. O mesmo evento econômico aparece sob rótulos diferentes dependendo de qual banco o imprimiu.
Decida a categoria contábil. "カード" (cartão) em uma linha de caderneta pode significar um saque em caixa eletrônico com cartão de débito, uma dedução de pagamento de cartão de crédito ou uma compra com cartão de débito — três tratamentos contábeis diferentes. A caderneta não informa qual é. Você precisa lembrar ou cruzar com um recibo.
Verifique o saldo corrente. O 差引残高 da caderneta deve ser igual ao saldo anterior menos o saque desta linha mais o depósito desta linha. Um dígito lido errado — um saque de ¥8.000 confundido com ¥80.000 — e todos os saldos subsequentes em todas as páginas seguintes estarão matematicamente errados. Essa verificação precisa acontecer em cada linha.
Digitar os cinco campos leva segundos. As quatro decisões acima é que consomem o tempo de verdade, e são as mesmas quatro decisões que cada linha exige, independentemente da sua velocidade de digitação. Quem faz a entrada de dados da caderneta não é um digitador. É um intérprete em tempo real de abreviações de códigos bancários, matemática de eras e lógica de categorias contábeis — trabalhando a partir de um documento impresso por uma máquina projetada antes de qualquer uma dessas camadas de tradução existir.
A mesma lacuna estrutural — em que um formato de documento e um sistema de destino falam idiomas diferentes, deixando uma pessoa para traduzir — aparece em vários países. Freelancers do Reino Unido enfrentam um descompasso quase idêntico quando traduzem extratos bancários e faturas para os campos do formulário SA100, e equipes de folha de pagamento australianas enfrentam isso quando resumos PAYG chegam em formatos que nenhum software de folha lê nativamente. A caderneta japonesa apenas pega a mesma fricção estrutural e a multiplica por um fator exclusivo do Japão: um sistema de códigos de descrição que muda conforme o banco.
Por Que Cada Banco Fala Seu Próprio Idioma: O Problema do Código 摘要 Que Ninguém Menciona
A coluna de descrição de uma caderneta japonesa é o campo com maior densidade de informação da página — e também o mais opaco. Não é uma descrição legível da transação. É um código de abreviação específico do banco, impresso em uma mistura densa de kanji, katakana, katakana de meia largura e caracteres alfanuméricos, muitas vezes truncado para caber em cerca de 12 a 16 posições de caractere em uma coluna estreita impressa por uma cabeça de matriz de pontos de caixa eletrônico.
Só o MUFG Bank publica um documento de referência listando mais de 200 códigos 摘要 distintos — e esses são apenas os mais comuns. Uma amostra de como o mesmo tipo de transação aparece nas principais instituições que emitem cadernetas:
| Tipo de Transação | 摘要 na Caderneta MUFG | 摘要 no Japan Post Bank | O Que Realmente Significa |
|---|---|---|---|
| Depósito de salário | 給料 | 振込 | Transferência de folha de pagamento do empregador — mas os caixas eletrônicos do Japan Post Bank não conseguem exibir o rótulo "salário" porque não processam o formato de mensagem eletrônica específico de folha que o sistema do MUFG processa |
| Transferência de internet banking (entrada) | 振込IB1 | 振込 | Mesmo evento econômico, abreviação completamente diferente — o MUFG codifica o canal (IB = internet banking), o Japan Post Bank não |
| Saque em dinheiro no caixa eletrônico | カード | 現金 | O MUFG usa o método (cartão), o Japan Post Bank usa o resultado (dinheiro) — o usuário da caderneta precisa saber qual convenção cada banco segue |
| Pagamento automático de conta de serviço | 口座振替 | 自動支払 | Mesma função, termos diferentes — ambos significam "débito automático em conta", mas usam palavras japonesas diferentes |
| Registro agregado (合計記帳) | 合計記帳 | (varia) | Múltiplas transações não impressas condensadas em uma única linha — os detalhes individuais das transações são permanentemente perdidos da caderneta |
Isto não é apenas um pequeno inconveniente. Um pequeno empresário que mantiene três cadernetas — MUFG para operações diárias, Japan Post Bank (ゆうちょ銀行) para reservas fiscais e uma cooperativa de crédito regional (信用金庫) para nómina — enfrenta três vocabulários diferentes de códigos de descrição. O mesmo evento econômico aparece com nomes diferentes em cada caderneta, e não existe um decodificador unificado. O empresário se torna criptógrafo como trabalho secundário não remunerado.
No Yahoo 知恵袋, o maior fórum de Q&A do Japão, um contador em atividade fez a pregunta diretamente: "Tenho que inserir manualmente todo o histórico de transações das cadernetas dos nossos clientes no Excel. A inserção manual leva uma quantidade enorme de tempo. Existe algum método para converter o histórico de transações de cadernetas para Excel sem usar software de contabilidade como MoneyForward ou freee?" A resposta mais votada foi pragmática: pedir ao cliente que se registre no banco online e baixe os dados. A segunda resposta foi mais honesta sobre a realidade: "OCR existe, mas ainda é necessário verificar erros de leitura. Só a verificação leva um tempo considerável."
Registro Agregado (合計記帳): A Solução do Banco Que Crea Seu Problema
Existe uma função integrada no sistema de cadernetas japonês que transforma um inconveniente em uma penalidade estrutural para qualquer pessoa que se atrase no registro. Se chama registro agregado (合計記帳, gōkei kichō), e recompensa os diligentes e castiga os ocupados com a mesma indiferência mecánica.
Así funciona no MUFG, e a maioria dos outros bancos japoneses opera um mecanismo similar. Se transações se acumulan em sua conta sem ser impressas na caderneta — porque você não visitou um ATM para atualizarla — o banco eventualmente as consolida. Duas vezes por ano, no terceiro sábado de maio e novembro, MUFG examina todas as contas. Qualquer conta com transações não impressas que excedan um limite de quantidade ao final de março ou setembro faz que essas transações sejam colapsadas em uma única linha: 合計記帳. Uma linha mostrando o número total de transações e seu montante neto combinado. Cada transação individual — as datas, os montantes, os códigos de descrição — se perde permanentemente da caderneta.
As consequências para alguien que depende da caderneta como seu registro principal:
- As transações perdidas não podem ser reconstruídas a partir da caderneta. As linhas individuais nunca existiram em papel. Elas existiam apenas como registros eletrônicos não impressos que foram sobrescritos pelo processo de agregação.
- Março e setembro são exatamente os meses em que pequenas empresas preparam demonstrações financeiras trimestrais ou semestrais. O gatilho de agregação coincide com o momento exato em que o dono de uma empresa mais precisa de dados desagregados.
- Contestar uma transação específica torna-se impossível. Se ¥200.000 foram retirados da conta em seis transações que foram agregadas, você não consegue dizer qual retirada foi qual, nem quando cada uma ocorreu, nem quais eram os códigos de descrição. Em uma auditoria fiscal, isso é uma lacuna documental.
O próprio site do MUFG menciona esse sistema quase como uma nota de rodapé — enterrado em uma nota que diz "atualize sua caderneta regularmente para evitar registro agregado". O tom pressupõe um aposentado que visita o banco toda semana para imprimir as linhas mais recentes. Para o dono de uma pequena empresa que administra um restaurante, uma oficina ou uma consultoria e vai ao banco no máximo uma vez por mês, 合計記帳 é um imposto sobre o tempo que se acumula: perca uma visita, perca dados permanentemente e enfrente uma lacuna nos livros que não pode ser fechada sem solicitar um extrato de histórico de transações ao banco — que, convenientemente, leva cerca de uma semana e chega pelo correio comum.
O Japan Post Bank processa isso de forma diferente — não pela mesma agregação em data fixa, mas pelos limites de páginas da caderneta. Uma caderneta padrão comporta aproximadamente 50 a 100 linhas de transações impressas, dependendo do banco. Quando as páginas acabam, o caixa eletrônico emite automaticamente uma nova caderneta. As transações entre a última linha impressa na caderneta antiga e a primeira linha impressa na nova são resumidas na página inicial da nova caderneta. As transações individuais no meio? Desaparecidas do papel. A nova caderneta começa do zero com um saldo transportado e sem histórico.
A caderneta foi projetada para um mundo em que as pessoas visitavam o banco semanalmente e verificavam manualmente cada nova linha. Nesse mundo, 合計記帳 é uma otimização razoável de espaço. No mundo em que a caderneta é o documento-fonte para um fluxo de trabalho contábil digital, é um mecanismo de destruição de dados — e você não pode automatizar seu caminho em torno de dados que não existem mais na página.
Por que apenas aplicativos não conseguem preencher a lacuna
Os aplicativos japoneses de finanças pessoais e contabilidade — MoneyForward ME (17,8 milhões de usuários), Zaim, Moneytree e os de nível empresarial freee e Yayoi — todos oferecem vinculação de contas bancárias via API. Para contas com internet banking ativado, novas transações entram no aplicativo automaticamente. Para uma família que acompanha gastos mensais, isso resolve em grande parte o problema de agora em diante.
Para o pequeno empresário que prepara uma declaração de imposto, não chega nem perto. Três razões:
A lacuna do pré-cadastro
Aplicativos vinculados por API puxam transações a partir do dia do cadastro em diante. Eles não — e não conseguem — alcançar anos de histórico de transações que existem apenas em páginas impressas de cadernetas antes da ativação do internet banking. Um empresário que ativou o internet banking do MUFJ em 2024 ainda tem 2022 e 2023 em uma caderneta física na gaveta. Esses anos ainda precisam ser inseridos manualmente para uma declaração azul, e os aplicativos não oferecem nenhuma ajuda para isso.
O problema do ecossistema fechado
Mesmo para transações que entram nos aplicativos, extrair os dados em um formato que outra ferramenta possa usar não é simples. O MoneyForward exporta dados CSV, mas os mapeamentos de campos e atribuições de categorias são específicos do MoneyForward. Migrar do MoneyForward para o freee significa recategorizar cada transação. Migrar de um aplicativo pessoal como o Zaim para uma plataforma de contabilidade como o Yayoi significa começar do zero. Os aplicativos adicionam conveniência, mas também adicionam uma nova camada de dependência de formato.
O ponto cego das anotações manuscritas
Cadernetas no Japão frequentemente contêm adições manuscritas — uma anotação a lápis ao lado de uma linha misteriosa de "振込" identificando-a como pagamento de um cliente específico, ou uma correção escrita quando o saldo não bate. Aplicativos de digitalização como o OCR de recibos do MoneyForward não são projetados para ler escrita manual sobreposta a entradas impressas por máquina, especialmente quando a caligrafia cruza as colunas estreitas.
Os aplicativos são bons no que fazem: mostrar o que aconteceu recentemente e ajudar a categorizar. Eles não foram projetados para ser a ponte entre um documento impresso da década de 1970 e um sistema contábil que espera dados estruturados. Essa ponte ainda é uma pessoa — e os aplicativos, apesar de toda a conveniência, só fizeram a pessoa perceber o quão distantes estão as duas pontes.
Onde os Erros se Acumulam: A Cascada do Saldo Corrente
Entre todos os documentos que um pequeno empresário manusea — faturas, recibos, ordens de compra, notas de entrega — o passbook é único em uma dimensão crítica: suas linhas de dados não são independentes. O saldo corrente (差引残高) de cada linha depende de que todas as linhas anteriores estejam corretas. Um dígito errado na linha 47 de um passbook de 200 linhas não afeta apenas a linha 47. Corrompe as linhas 48 a 200. Cada saldo impresso após o erro discordará da realidade.
Isto cria uma carga de verificação que outros tipos de documentos não impõem. Com uma pilha de faturas, você pode processar cada uma independentemente — um erro na fatura 23 não afeta a fatura 24. Com um passbook, ou você verifica o saldo em cada linha (verificando que Saldo Anterior + Depósito – Saque = Saldo Corrente) ou aceita que qualquer erro no lote se propague silenciosamente. A maioria dos pequenos empresários, trabalhando até tarde da noite depois que a loja fecha, escolhe a segunda opção sem perceber o risco.
Isto não é hipotético. No Yahoo 知恵袋, um usuário descreveu seu fluxo de trabalho: digitar manualmente dados do passbook no Excel e cruzar totais com extratos bancários. Os respondentes ofereceram soluções que variam de downloads CSV a OCR, mas o problema subjacente — que um único erro se propaga indetectablemente até que o total final não coincida — foi reconhecido como inerente ao formato. Um respondente notou que mesmo com OCR, "você ainda precisa verificar erros de leitura, e só a verificação leva um tempo considerável." Para um passbook, "verificar" não significa verificar aleatoriamente algumas linhas. Significa verificar a cascada de saldo em cada linha.
O Problema do 和暦: Quando o Ano Muda Toda Vez que o Imperador Muda
O Japão usa dois sistemas de calendário em paralelo. O calendário gregoriano, que o resto do mundo usa, e o calendário de era japonês (和暦, wareki), que nomeia os anos de acordo com o imperador reinante. Uma caderneta imprime as datas no formato do calendário de era: 令和6年3月15日 (Reiwa 6, 15 de março). O software de contabilidade — Yayoi, freee, MoneyForward — aceita qualquer um dos formatos, mas não consegue converter entre eles sem que lhe digam a qual era cada data pertence. E quando a era muda, os números dos anos voltam a 1.
A dificuldade prática não é a existência do sistema duplo. São os anos de fronteira — os anos em que uma era mudou no meio do ano e tanto o rótulo da era antiga quanto o da nova se referem ao mesmo ano gregoriano:
| Ano Gregoriano | Ano de Era na Caderneta | Desafio de Conversão |
|---|---|---|
| 1989 | 昭和64年 (1–7 de jan.) / 平成元年 (8 de jan.–31 de dez.) | Showa 64 durou exatamente 7 dias; Heisei 1 começou em 8 de janeiro. Uma linha da caderneta datada de 昭和64.1.5 = 1989. Uma linha datada de 平成1.12.20 = também 1989. Mesmo ano calendário, dois rótulos de era diferentes. |
| 2019 | 平成31年 (1 de jan.–30 de abr.) / 令和元年 (1 de mai.–31 de dez.) | A transição atual. Uma página da caderneta impressa em abril de 2019 diz 平成31年. Uma página impressa em maio de 2019 diz 令和元年. Ambas são 2019. Ordenar as transações cronologicamente através da fronteira de era significa que a pessoa que insere os dados precisa mapear mentalmente 平成31.4.30 → 令和1.5.1 como datas consecutivas. |
| 2026 (ano atual) | 令和8年 | Mais simples agora, mas a próxima transição — quando vier — criará o mesmo problema de fronteira. Uma caderneta que abranja a transição terá dois rótulos de era diferentes para o mesmo ano fiscal. |
Para uma empresa que mantém três cadernetas e apresenta uma declaração azul, o problema da era se soma ao problema do código de descrição. Você não está apenas convertendo Reiwa 6 para 2024. Você está fazendo isso enquanto também decodifica se "振込TB1" na caderneta do MUFG é o mesmo depósito que "振込" na caderneta do Japan Post Bank — durante um mês em que o rótulo de era em uma caderneta pode diferir do da outra se uma foi impressa logo antes e a outra logo depois de uma renovação de caderneta.
O calendário de era não vai a lugar nenhum. Formulários do governo, documentos fiscais e extratos bancários todos o usam. O software de contabilidade que uma pequena empresa precisa alimentar aceita qualquer um dos formatos. Mas a conversão entre eles continua sendo uma etapa humana — e cada conversão é uma chance de um ano ficar desalinhado, criando transações que aparecem no ano fiscal errado.
O Caminio Não É Digitar Mais Rápido — É Eliminar a Etapa de Tradução
Se o problema estrutural é uma etapa de tradução manual entre as páginas do passbook e o software de contabilidade, a solução não pode ser "digitar mais rápido" ou "conseguir um app melhor". Tem que ser uma forma de extrair dados do passbook que contorne essa etapa de tradução — que lea o formato de cinco colunas do passbook e produza dados estruturados diretamente, sem exigir que a pessoa decodifique abreviações de descrição específicas do banco, converta anos de era ou verifique manualmente os saldos correntes.
A abordagem que se ajusta a este problema é a extração semântica: você diz a uma ferramenta o que as colunas significam — "Data", "Descrição", "Retiro", "Depósito", "Saldo" — e ela lee a página do passbook e encontra cada valor entendendo o layout do documento, não combinando um modelo fixo. Como os formatos de passbook japoneses são padronizados entre bancos (cinco colunas, mesma ordem, mesmo layout geral), um modelo semântico pode ler páginas de MUFG, Japan Post Bank e uma cooperativa de crédito regional com a mesma definição de colunas — a única coisa que muda por banco são os códigos de descrição, e esses são apenas texto que a ferramenta extrae tal qual para que você categorize depois.
Essa é a ideia central por trás da Extraction de Colunas Personalizadas. Em vez de desenhar caixas ao redor de campos ou criar regras de parsing por banco, você digita os nomes das colunas que deseja e faz upload das páginas do passbook. A IA lee cada página, localiza as cinco colunas entendendo o layout tabular e preenche uma linha de planilha por transação. Adicione uma coluna calculada — por exemplo, "Verificação de Saldo (Saldo Anterior + Depósito – Retiro)" — e a ferramenta marca cada linha onde o saldo corrente não bate, para que você saiba exatamente onde ocorreu um erro antes que os dados entrem no seu software de contabilidade.
Os arquivos são processados de forma segura e não são armazenados.
O fluxo de trabalho completo de extração passo a passo — desde o upload da primeira página do passbook até a obtenção de uma planilha formatada — está documentado no guia de extração de passbook japonês. E para lidar com múltiplos passbooks ao longo de vários anos, a abordagem de processamento em lote mescla páginas de diferentes bancos em um único livro de despesas, com todas as datas de eras convertidas e todos os saldos verificados em uma única passada — o que importa quando três passbooks × três anos significam 280 transações, 1.400 pontos de dados e uma etapa de mesclagem manual que a extração de página única deixa na sua mesa.
Nada disso faz o passbook desaparecer. A infraestrutura bancária do Japão continuará imprimindo-os por muitos anos. O que muda é se a pessoa do outro lado do caixa eletrônico precisa se tornar uma tradutora de códigos bancários e auditora de saldos em cascata todo mês — ou se a extração acontece em segundos e o trabalho humano passa para a parte que realmente exige julgamento humano: categorizar as transações e preencher a declaração.
Perguntas Frequentes
Por que os bancos japoneses não simplesmente param de emitir cadernetas de papel?
Vários megabancos agora oferecem alternativas somente digitais — o Eco通帳 do MUFG (caderneta pela internet), por exemplo, substitui o livreto de papel por uma interface de navegador ou aplicativo e isenta certas tarifas de caixa eletrônico como incentivo. Mas mudar para ele desativa permanentemente a caderneta de papel, o que muitos clientes — especialmente correntistas mais velhos e pequenos empresários que usam a caderneta como registro definitivo — relutam em fazer. O status legal da caderneta como registro de transações está profundamente enraizado na prática bancária japonesa, e mudar isso exige mudanças regulatórias e culturais que não acontecem na velocidade de um lançamento de software.
Posso simplesmente fotografar minha caderneta com o celular e fazer um aplicativo lê-la?
Sim, com ressalvas. Alguns serviços de OCR com IA (como SmartOCR e Shuttle Smile, projetados especificamente para cadernetas japonesas) conseguem ler páginas fotografadas com alta precisão para caracteres impressos — a SmartOCR afirma 99,8% para texto impresso por máquina. No entanto, páginas fotografadas trazem desafios que as digitalizações não trazem: distorção de perspectiva (a caderneta fotografada em ângulo faz as colunas parecerem trapezoidais), iluminação irregular na lombada da caderneta e legibilidade reduzida dos caracteres katakana de meia largura, que já são comprimidos em colunas estreitas. Anotações manuscritas nas páginas da caderneta reduzem ainda mais a precisão. A tecnologia existe e funciona, mas exige boa qualidade de entrada e — para fins contábeis — verificação humana do resultado.
O que acontece com os dados da minha caderneta se eu mudar para o Eco通帳 (caderneta pela internet)?
O Eco通帳 do MUFG mantém até 10 anos de histórico de transações em formato digital, acessível pelo internet banking. Transações passadas que já foram agregadas (合計記帳) na sua caderneta de papel antiga podem ser recuperadas por meio de uma solicitação separada de extrato de histórico de transações — mas somente se você solicitá-la. O detalhe: depois que você muda para o Eco通帳, sua caderneta de papel é desativada permanentemente. Você não pode voltar atrás. Se depois precisar de um registro em papel para uma auditoria fiscal ou pedido de empréstimo, você precisará baixar e imprimir pela interface digital.
Usar um software de contabilidade como freee ou Yayoi elimina a necessidade de extrair dados da caderneta?
Para transações que ocorrem depois de você vincular sua conta bancária via API, os aplicativos puxam os dados das transações automaticamente. Para tudo o que aconteceu antes da vinculação — que, para a maioria das pequenas empresas, são anos de histórico — os dados ainda vivem nas páginas da caderneta. Os aplicativos não conseguem preencher o histórico retroativamente. E mesmo para contas vinculadas, a categorização automática não é perfeita: um depósito "振込" de um cliente parece idêntico a uma transferência "振込" da sua própria outra conta, e o aplicativo não consegue distingui-los sem regras manuais ou correções. Os aplicativos reduzem a entrada contínua de dados, mas não eliminam a necessidade de extração de dados da caderneta para registros históricos e verificação de precisão.
A mesma configuração de extração pode funcionar em diferentes cadernetas bancárias — MUFG, Japan Post Bank, bancos regionais?
Sim. Apesar das diferenças nos códigos de descrição entre os bancos, o layout de cinco colunas da caderneta (data, descrição, saque, depósito, saldo) é padronizado em praticamente todas as instituições financeiras japonesas. A extração semântica lê o layout compreendendo-o como uma tabela — ela não precisa de modelos por banco, pois identifica as colunas pelo conteúdo e posição, em vez de usar um conjunto fixo de regras. Defina as colunas uma vez, e a mesma definição funciona em cadernetas do MUFG, Japan Post Bank, SMBC e cooperativas de crédito regionais. Os códigos de descrição serão diferentes (conforme documentado acima), mas são extraídos como texto — você os categoriza após a extração, não durante ela.
Na próxima vez que a pilha mensal de passbooks cair na mesa — três cadernetas, talvez 60 novas linhas entre elas, cada linha com cinco campos e quatro decisões — vale a pena nomear o que está realmente acontecendo. Não é "digitação de dados", não é "contabilidade", mas um exercício de tradução em tempo real entre um formato de documento inalterado desde a era Showa e um software de contabilidade que opera com uma lógica fundamentalmente diferente. Digitar é a menor parte do trabalho. A decodificação de significados — o que este código diz, que ano é este, de qual banco é este sistema de abreviações — é onde as horas se vão e onde os erros moram. Veja como ficam as suas próprias páginas de passbook quando a extração acontece em segundos e a única decisão restante é o que fazer com os números.