종이 통장 문제
일본 중소기업이 모르는 비용

통장 패러독스: 2024년 회계 워크플로우 속 1970년대 문서

일본은 선진국 중 유일하게 물리적 은행 통장이 대중적인 금융 수단으로 남아 있는 국가입니다. MUFG나 SMBC 지점에 가면 ATM이 최신 거래 내역을 바로 제본된 통장에 출력해 줍니다 — 도트 매트릭스 프린트 헤드로 다섯 개의 열(날짜(月日), 거래 코드(摘要), 출금액(お支払金額), 입금액(お預り金額), 잔액(差引残高))이 인쇄됩니다. 이 형식은 은행 창구 직원이 수동으로 잔액을 확인하고 CSV 내보내기 개념이 존재하지 않던 시대에 설계되었습니다. 그 이후로 실질적인 변화는 없었습니다.

그러나 일본 중소기업이 사용하는 회계 소프트웨어 — Yayoi Accounting (弥生会計)(70만 개 이상 기업 사용), freee(클라우드 회계 시장 선두주자, 45만 유료 고객), MoneyForward Cloud(44만 2천 유료 기업) — 는 근본적으로 다른 가정 위에서 작동합니다. 거래 데이터가 디지털로 도착한다고 가정합니다. CSV 가져오기, 은행 API 피드, 자동화된 복식부기 규칙 등입니다. 통장은 이러한 모든 가정을 동시에 위반합니다.

이것은 "디지털 리터러시" 문제나 "일본이 뒤처졌다"는 진부한 표현이 아닙니다. 이는 문서 형식의 불일치입니다: 금융 활동을 기록하는 인프라와 이를 장부에 반영하는 인프라는 50년의 차이를 두고, 서로 소통할 필요가 없었던 다른 산업에 의해 구축되었으며, 그 간극을 사람이 읽고 다시 입력함으로써 메워야 합니다.

일본우체국은행만 약 1억 2천만 개의 계좌를 보유하고 있습니다 — 시민 한 명당 거의 하나꼴입니다. MUFG, SMBC, 미즈호는 합쳐서 수천만 개 이상을 보유하고 있습니다. 대부분의 계좌는 여전히 기본적으로 종이 통장을 발행합니다. 인터넷 뱅킹을 활성화한 고객조차도 일상 확인용 디지털 인터페이스와 확정 기록용 통장을 모두 보유하는 경우가 많습니다. 청색 신고(青色申告)를 제출하는 개인 사업자(個人事業主)의 경우 — 소득세법 제143조에 따라 적절한 복식부기를 조건으로 65만 엔의 특별 공제를 받음 — 모든 통장 페이지의 모든 거래는 분개장 항목으로 추적 가능해야 합니다. 통장은 선택 사항이 아닙니다. 그것이 감사 추적입니다.

구조적 문제를 간단히 말하면: 인간 창구 직원이 눈으로 잔액을 확인하기 위해 설계된 문서가, 기계가 읽을 수 있는 거래 피드를 위해 설계된 소프트웨어의 주요 데이터 소스로 사용되고 있습니다. 불일치는 절대적이며, 그 비용은 전적으로 키보드 앞에 있는 사람이 부담합니다.

실제 작업은 타이핑이 아닙니다 — 번역입니다

통장 데이터 입력 문제의 일반적인 프레임은 "타이핑에 너무 오래 걸린다"는 것입니다. 이 프레임은 틀렸고, 실제 노력이 어디에 들어가는지 숨기는 방식으로 틀렸습니다. 타이핑 속도는 병목이 아닙니다. 병목은 통장의 모든 줄이 키를 한 번 누르기 전에 일련의 인지적 번역을 필요로 한다는 점입니다.

통장 한 줄을 소리 내어 읽으면서 결정 사항을 세어보세요:

다섯 개 필드를 입력하는 데는 몇 초가 걸립니다. 위의 네 가지 결정이 실제 시간을 소모하며, 타이핑 속도와 관계없이 모든 줄에서 동일한 네 가지 결정이 요구됩니다. 통장 데이터 입력을 하는 사람은 데이터 입력 사무원이 아닙니다. 그들은 은행 코드 약어, 연호 수학, 회계 항목 논리의 실시간 해석자입니다 — 이러한 번역 계층이 존재하기 전에 설계된 기계로 인쇄된 문서를 작업하면서 말이죠.

동일한 구조적 격차 — 문서 형식과 대상 시스템이 서로 다른 언어를 사용하여 사람이 직접 번역해야 하는 문제 — 는 국경을 넘어 나타납니다. 영국 프리랜서는 은행 명세서와 송장을 SA100 양식으로 변환할 때 거의 동일한 불일치에 직면하며, 호주 급여 팀은 PAYG 요약이 어떤 급여 소프트웨어도 기본적으로 읽지 못하는 형식으로 도착할 때 이를 경험합니다. 일본 통장은 동일한 구조적 마찰을 일본 고유의 요소, 즉 은행마다 다른 적요 코드 체계로 배가시킵니다.

모든 은행이 각자의 언어를 사용하는 이유: 아무도 이야기하지 않는 적요 코드 문제

일본 통장의 적요(摘要)란은 페이지에서 가장 정보 밀도가 높은 필드이면서 동시에 가장 난해합니다. 사람이 읽을 수 있는 거래 설명이 아닌, 은행별 약어 코드로, 한자, 가타카나, 반각 가타카나, 영숫자가 혼합된 형태로 ATM 도트 매트릭스 프린터의 좁은 열에 맞춰 약 12~16자로 잘려 인쇄됩니다.

MUFG 은행만 해도 참고 문서에 200개 이상의 고유 적요 코드를 게시하고 있으며, 이는 가장 흔한 것들만 나열한 것입니다. 동일한 거래 유형이 주요 통장 발행 기관에서 어떻게 다르게 표시되는지 샘플을 보여드립니다:

이는 단순한 사소한 불편이 아닙니다. 일상 운영용 MUFG, 세금 적립용 일본우체국은행(ゆうちょ銀行), 급여용 지역 신용금고(信用金庫) 등 세 개의 통장을 관리하는 소상공인은 세 가지 다른 적요 코드 어휘에 직면합니다. 동일한 경제적 사건이 각 통장에서 다른 이름으로 나타나며, 이를 통합 해독하는 도구는 존재하지 않습니다. 사업주는 무보수 부업으로 암호 해독가가 됩니다.

日本の最大のQ&Aフォーラム「Yahoo 知恵袋」で、現役の経理担当者が直接質問を投げかけました。「取引先の通帳の取引履歴をすべて手入力でExcelに打ち込んでいる。手入力に膨大な時間がかかる。MoneyForwardやfreeeのような会計ソフトを使わずに、通帳の取引履歴をExcelに変換する方法はないか？」 最も支持された回答は現実的で、「取引先にネットバンキングを契約してもらい、データをダウンロードしてもらう」というものでした。2番目の回答は、より現実を直視したものでした。「OCRは存在するが、読み取りエラーのチェックが必要。そのチェックだけでかなりの時間がかかる。」

合計記帳: あなたの問題を生み出す銀行の解決策

日本の通帳システムには、記帳の遅れを構造的なペナルティに変えてしまう機能が組み込まれています。それが合計記帳と呼ばれるもので、勤勉な者には報い、忙しい者には機械的な無関心で罰します。

三菱UFJ銀行での仕組みは次の通りです（他のほとんどの日本の銀行も同様の仕組みを採用しています）。ATMで通帳を更新していないため、取引が通帳に印字されずに口座に蓄積されると、銀行は最終的にそれらを統合します。年に2回、5月と11月の第3土曜日に、三菱UFJ銀行は全口座をスキャンします。3月末または9月末時点で、未印字の取引が一定数を超えている口座は、それらの取引が1行にまとめられます：合計記帳。取引総数とその合計純額を示す1行です。個々の取引の日付、金額、摘要コードはすべて、通帳から永久に失われます。

通帳を主要な記録として頼りにしている人にとっての結果は次の通りです。

• 失われた取引は通帳から復元できません。 個々の明細は紙に印字されたことは一度もありません。それらは印字されていない電子記録としてのみ存在し、統合処理によって上書きされました。
• 3月と9月は、まさに中小企業が四半期または半期の決算書を作成する月です。 統合のトリガーは、事業主が最も詳細なデータを必要とするまさにその瞬間と一致します。
• 特定の取引に異議を唱えることが不可能になります。 20万円が6回の取引で引き出され、それが統合された場合、どの引き出しがどれで、それぞれがいつ発生し、摘要コードが何であったかを特定できません。税務調査において、これは記録の欠落です。

三菱UFJ銀行自身のウェブサイトでは、このシステムについて「合計記帳を避けるため、定期的に通帳を記帳してください」という脚注に埋もれる形で、ほとんどおまけのように触れられています。そのトーンは、毎週銀行に通って最新の取引を印字する退職者を想定しています。レストラン、工房、コンサルタント業を営み、せいぜい月に1回しか銀行に行けない中小企業の経営者にとって、合計記帳は時間に対する税金であり、記帳を怠ればデータを永久に失い、銀行から取引履歴の印刷物を請求する以外に埋められない帳簿の空白に直面することになります。しかも、その印刷物が届くまでには約1週間かかり、普通郵便で届きます。

ゆうちょ銀行はこの処理を異なる方法で行います。固定日付での集計ではなく、通帳のページ制限に基づいています。標準的な通帳1冊には、銀行にもよりますが、約50～100行の取引明細が印字されます。ページがなくなると、ATMが自動的に新しい通帳を発行します。古い通帳の最終印字行と新しい通帳の最初の印字行の間の取引は、新しい通帳の最初のページにまとめて記帳されます。その間の個々の取引は？紙の上からは消えます。新しい通帳は、繰り越された残高と履歴なしで新たに始まります。

通帳は、人々が毎週銀行に足を運び、新しい行を一つ一つ手作業で確認する世界のために設計されました。その世界では、合計記帳は合理的なスペースの最適化です。しかし、通帳がデジタル会計ワークフローのソース文書となる世界では、それはデータ破壊の仕組みです。そして、ページ上にもう存在しないデータを自動化でどうにかすることはできません。

アプリだけではギャップを埋められない理由

日本の個人向け・会計アプリ — MoneyForward ME（1,780万人ユーザー）、Zaim、Moneytree、そして業務向けのfreeeややよい — はすべて、API経由での銀行口座連携を提供しています。インターネットバンキングが有効な口座の場合、新しい取引は自動的にアプリに取り込まれます。毎月の支出を追跡する個人にとっては、これで今後の問題はほぼ解決します。

しかし、確定申告を準備する小規模事業主にとっては、全く不十分です。理由は3つあります。

앱들은 최근 내역을 보여주고 분류를 돕는 일은 잘합니다. 하지만 1970년대 인쇄 문서와 구조화된 데이터를 기대하는 회계 시스템 사이의 다리가 되도록 설계되지는 않았습니다. 그 다리는 여전히 사람입니다. 그리고 앱들은 편리함을 제공했지만, 오히려 사람이 다리 양쪽 끝이 얼마나 멀리 떨어져 있는지 더 절감하게 만들었을 뿐입니다.

오류가 증폭되는 지점: 잔액 연쇄 전파

소상공인이 처리하는 모든 문서(인보이스, 영수증, 구매 주문서, 납품서) 중에서 통장은 한 가지 중요한 차원에서 독특합니다. 데이터 행이 서로 독립적이지 않다는 점입니다. 모든 행의 잔액(差引残高)은 이전 모든 행이 정확해야만 올바르게 계산됩니다. 200줄짜리 통장의 47번째 줄에 숫자 하나가 잘못 입력되면, 47번째 줄에만 영향을 주는 것이 아닙니다. 48번째 줄부터 200번째 줄까지 모두 오염됩니다. 오류 이후에 인쇄된 모든 잔액은 실제와 일치하지 않게 됩니다.

이는 다른 문서 유형에서는 발생하지 않는 검증 부담을 만듭니다. 인보이스 더미는 각각 독립적으로 처리할 수 있습니다. 23번 인보이스의 오류가 24번 인보이스에 영향을 주지 않습니다. 하지만 통장의 경우, 모든 행의 잔액을 하나하나 검증(이전 잔액 + 입금 – 출금 = 현재 잔액 확인)하거나, 배치 내 오류가 조용히 앞으로 전파되는 것을 감수해야 합니다. 대부분의 소상공인은 가게 문을 닫고 늦은 밤에 일하면서, 그 위험을 인지하지 못한 채 두 번째 선택지를 택합니다.

이는 가상의 이야기가 아닙니다. Yahoo 知恵袋에서 한 사용자는 자신의 작업 방식을 설명했습니다. 통장 데이터를 수동으로 Excel에 입력하고 합계를 은행 명세서와 대조 확인하는 방식이었습니다. 응답자들은 CSV 다운로드부터 OCR까지 다양한 해결책을 제시했지만, 단 하나의 실수가 최종 합계가 일치하지 않을 때까지 감지되지 않고 전파된다는 근본적인 문제는 해당 형식에 내재된 것으로 인정되었습니다. 한 응답자는 OCR을 사용하더라도 "읽기 오류를 여전히 확인해야 하며, 확인 작업만으로도 상당한 시간이 소요된다"고 지적했습니다. 통장의 경우 "확인"은 몇몇 행을 표본 점검하는 것을 의미하지 않습니다. 모든 줄의 잔액 연쇄를 검증하는 것을 의미합니다.

和暦の問題：天皇が変わるたびに年号が変わる

日本では2つの暦が併用されています。世界標準のグレゴリオ暦と、在位する天皇にちなんで年を命名する元号（和暦）です。通帳には元号形式で日付が印字されます：令和6年3月15日。会計ソフト（弥生、freee、MoneyForward）はどちらの形式も受け付けますが、各日付がどの元号に属するかを指定しないと、相互に変換できません。そして元号が変わると、年号は1にリセットされます。

実務上の困難は、二重システムの存在そのものではありません。問題は境界年——元号が年中に変わり、新旧両方の元号が同じグレゴリオ暦年を指す年——です。

3つの通帳を管理し、青色申告を行う事業者にとって、元号問題は摘要コード問題と重なります。単に令和6年を2024年に変換するだけではありません。三菱UFJ銀行の通帳にある「振込TB1」が、ゆうちょ銀行の通帳にある「振込」と同じ入金かどうかを——片方の通帳が通帳繰越の直前、もう片方が直後に印字されたため、月の途中で元号ラベルが異なる可能性がある期間に——解読しながら変換しなければならないのです。

元号はなくなりません。政府の書式、税務書類、銀行取引明細はすべて元号を使用しています。中小企業が利用しなければならない会計ソフトはどちらの形式も受け付けます。しかし、それらの間の変換は依然として人間の手作業であり——変換のたびに年号の不一致が発生し、誤った課税年度に取引が計上されるリスクがあります。

通帳から会計ソフトへの手動変換をなくす——それが近道だ

構造的な問題が通帳ページと会計ソフトの間の手動変換レイヤーにあるなら、解決策は「もっと速く打ち込む」や「もっと良いアプリを使う」ではありません。変換ステップを迂回して通帳データを抽出する方法——つまり、通帳の5列フォーマットを読み取り、銀行固有の摘要略語を解読したり、元号を変換したり、残高を手動で検証したりする必要なく、構造化データを直接生成する方法——でなければなりません。

この問題に適したアプローチはセマンティック抽出です。「日付」「摘要」「お引出し」「お預入れ」「残高」といった意味で列を指定すると、固定テンプレートに一致させるのではなく、ドキュメントのレイアウトを理解して各値を検出します。日本の通帳フォーマットは銀行間で標準化されているため（5列、同じ順序、同じ一般的なレイアウト）、セマンティックモデルは三菱UFJ銀行、ゆうちょ銀行、地方信用金庫のページを同じ列定義で読み取ることができます。銀行ごとに変わるのは摘要コードだけで、これらは後で分類するためにそのまま抽出されるテキストです。

これが맞춤 열 추출の核となるアイデアです。フィールドの周りにボックスを描いたり、銀行ごとに解析ルールを作成したりする代わりに、必要な列名を入力して通帳ページをアップロードします。AIが各ページを読み取り、表形式のレイアウトを理解して5列を特定し、トランザクションごとにスプレッドシートの行を生成します。계산 열（例：「残高チェック（前残高＋お預入れ－お引出し）」）を追加すると、残高が合わない行がすべてフラグ付けされるため、データが会計ソフトに入力される前にエラーが発生した場所を正確に把握できます。

最初の通帳ページのアップロードからフォーマット済みスプレッドシートの取得までの完全なステップバイステップの抽出ワークフローは、日本の通帳抽出ガイドに記載されています。また、複数年にわたる複数の通帳を処理する場合は、일괄 우선 처리アプローチにより、異なる銀行のページを1つの支出元帳に統合し、すべての元号日付を変換し、すべての残高を1回のパスで検証します。これは、3冊の通帳×3年で280件の取引、1,400のデータポイントとなり、1ページずつの抽出では手動での統合作業が残ってしまう場合に重要です。

이 모든 것이 통장을 사라지게 하지는 않습니다. 일본의 은행 인프라는 앞으로도 수년간 통장을 계속 인쇄할 것입니다. 바뀌는 것은 ATM 반대편에 있는 사람이 매달 은행 코드를 해석하고 누적 잔액을 감사해야 하는 번역가가 되어야 하는지, 아니면 추출이 몇 초 만에 이루어지고 인간의 작업이 실제로 인간의 판단이 필요한 부분(거래 분류 및 신고서 제출)으로 이동하는지입니다.

자주 묻는 질문

다음에 월간 통장 더미가 책상 위에 놓일 때 — 세 권의 통장, 그 사이에 약 60개의 새로운 줄, 각 줄에는 5개의 필드와 4개의 결정이 있습니다 — 실제로 무슨 일이 일어나고 있는지 이름을 붙일 가치가 있습니다. "데이터 입력"도 아니고 "회계"도 아닌, 쇼와 시대부터 변하지 않은 문서 형식과 근본적으로 다른 논리로 작동하는 회계 소프트웨어 간의 실시간 번역 작업입니다. 타이핑은 작업 중 가장 작은 부분입니다. 의미 해독 — 이 코드는 무엇을 의미하는지, 올해는 몇 년도인지, 이 은행의 약어 체계는 무엇인지 — 이곳에 시간이 소요되고 오류가 발생합니다. 추출이 몇 초 만에 이루어지고 남은 유일한 결정이 숫자로 무엇을 할지일 때, 자신의 통장 페이지가 어떻게 보이는지 확인해 보세요.