종이 통장의 문제
일본 중소기업이 인지하지 못하는 비용

통장 역설: 2024년 회계 워크플로우 속 1970년대 문서

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

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

이것은 "디지털 리터러시" 문제도, "일본이 뒤처졌다"는 식의 진부한 표현도 아닙니다. 문서 형식의 불일치입니다: 금융 활동을 기록하는 인프라와 이를 기장하는 인프라는 서로 대화할 필요가 없었던 서로 다른 업계에서 50년 간격으로 만들어졌으며 — 그 간극을 읽고 다시 입력하는 방식으로 메워야 하는 사람만 남겨졌습니다.

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

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

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

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

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

다섯 개 필드를 입력하는 데는 몇 초밖에 걸리지 않습니다. 위의 네 가지 판단이 실제로 시간이 걸리는 부분이며, 입력 속도와 관계없이 모든 행마다 동일한 네 가지 판단이 요구됩니다. 통장 데이터를 입력하는 사람은 단순 데이터 입력 담당자가 아닙니다. 은행 코드 약어, 연호 계산, 회계 분류 논리를 실시간으로 해석하는 사람입니다. 그들이 다루는 문서는 이러한 변환 계층이 존재하기 전에 설계된 기계가 인쇄한 것입니다.

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

모든 은행이 제각각의 언어를 쓰는 이유: 아무도 말하지 않는 적요 코드 문제

일본 통장의 적요(摘要)란은 페이지에서 가장 정보 밀도가 높은 필드이면서 동시에 가장 난해한 필드이기도 합니다. 거래에 대한 사람이 읽을 수 있는 설명이 아니라 은행별 약어 코드로, 한자, 가타카나, 반각 가타카나, 영숫자 문자가 조밀하게 섞여 ATM 도트매트릭스 프린트 헤드가 찍는 좁은 칸에 맞게 잘려 인쇄됩니다.

MUFG 은행만 해도 참고 문서에 200개가 넘는 적요 코드를 게시하고 있습니다. 그나마도 가장 흔한 것들만 추린 것입니다. 주요 통장 발행 기관에서 동일한 거래 유형이 어떻게 다르게 표시되는지 샘플을 보면 다음과 같습니다.

이것은 단순한 불편함이 아니다. 일상 업무용 MUFG, 세금 적립용 일본우편은행(ゆうちょ銀行), 급여 지급용 지역 신용금고(信用金庫) — 이렇게 세 개의 통장을 관리하는 소상공인은 세 가지 서로 다른 적요 코드 체계를 마주하게 된다. 동일한 경제적 사건이 통장마다 다른 이름으로 표시되며, 이를 통합 해독해 줄 도구는 없다. 사업주는 무급 부업으로 암호 해독가가 되어 버린다.

일본 최대 Q&A 포럼인 Yahoo 지식袋(知恵袋)에서 한 현직 회계사가 직접 질문을 던졌다: "고객사 통장 거래 내역을 모두 Excel에 수동 입력해야 합니다. 수동 입력에 엄청난 시간이 걸립니다. MoneyForward나 freee 같은 회계 소프트웨어를 사용하지 않고 통장 거래 내역을 Excel로 변환할 방법이 있나요?" 가장 많은 추천을 받은 답변은 실용적이었다: 고객에게 인터넷 뱅킹에 가입하고 데이터를 내려받도록 요청하라는 것. 두 번째 답변은 현실을 더 솔직하게 말했다: "OCR이 있긴 하지만 여전히 판독 오류를 확인해야 합니다. 확인 작업만으로도 상당한 시간이 걸립니다."

합계기장(合計記帳): 문제를 만드는 은행의 해결책

일본 통장 시스템에는 기록을 미루는 사람에게 구조적 불이익을 주는 기능이 내장되어 있다. 그것은 합계기장(合計記帳, gōkei kichō)이라고 불리며, 성실한 사람에게는 보상을, 바쁜 사람에게는 처벌을 동일한 기계적 무관심으로 적용한다.

MUFG에서의 작동 방식은 다음과 같다. 대부분의 다른 일본 은행도 유사한 메커니즘을 운영한다. ATM을 방문해 통장을 갱신하지 않아 계좌에 거래가 누적되면, 은행은 결국 이를 통합한다. MUFG는 연 2회, 5월과 11월의 세 번째 토요일에 모든 계좌를 스캔한다. 3월 말 또는 9월 말 기준으로 미출력 거래가 임계 건수를 초과하는 계좌는 해당 거래들이 단일 항목으로 압축된다: 合計記帳. 거래 건수와 순액 합계만 표시된 한 줄. 개별 거래의 모든 세부 정보 — 날짜, 금액, 적요 코드 — 는 통장에서 영구히 사라진다.

통장을 주요 기록으로 의존하는 사람에게 미치는 영향:

• 통장에서 누락된 거래 내역은 복원할 수 없습니다. 개별 거래 내역은 종이에 기록된 적이 없습니다. 이는 인쇄되지 않은 전자 기록으로만 존재했으며, 합산 처리 과정에서 덮어쓰여졌습니다.
• 3월과 9월은 정확히 소규모 사업자가 분기별 또는 반기별 재무제표를 준비하는 시기입니다. 합산 트리거는 사업주가 개별 데이터를 가장 필요로 하는 바로 그 순간에 발생합니다.
• 특정 거래에 이의를 제기하는 것이 불가능해집니다. 200,000엔이 계좌에서 6건의 거래로 출금되었는데 합산되었다면, 어떤 출금이 어떤 것인지, 각각 언제 발생했는지, 적요 코드가 무엇이었는지 알 수 없습니다. 세무 조사에서 이는 문서 공백입니다.

MUFG 자체 웹사이트에서도 이 시스템을 거의 부수적인 언급으로만 다룹니다 — "합산 기록을 피하려면 통장을 정기적으로 업데이트하십시오"라는 각주에 묻혀 있습니다. 그 어조는 매주 은행을 방문해 최신 내역을 인쇄하는 은퇴자를 전제로 합니다. 식당, 공방, 컨설팅 업체를 운영하며 한 달에 많아야 한 번 은행에 가는 소규모 사업주에게 합계기장은 복리로 쌓이는 시간 세금입니다: 방문을 놓치면 데이터가 영구히 사라지고, 은행에 거래 내역 출력을 요청하지 않고는 메울 수 없는 장부 공백에 직면합니다 — 물론 그 출력물은 도착하는 데 약 일주일이 걸리고 일반 우편으로 배송됩니다.

일본우편은행은 이 문제를 다르게 처리합니다 — 동일한 고정일 합산 방식이 아니라 통장 페이지 한도를 통해 처리합니다. 표준 통장 장부에는 은행에 따라 약 50~100줄의 인쇄된 거래 내역이 들어갑니다. 페이지가 모두 차면 ATM이 자동으로 새 통장을 발급합니다. 이전 통장의 마지막 인쇄 줄과 새 통장의 첫 인쇄 줄 사이의 거래는 새 통장의 첫 페이지에 요약됩니다. 그 사이의 개별 거래는? 종이에서 사라집니다. 새 통장은 이월 잔액과 기록 없이 새로 시작됩니다.

통장은 사람들이 매주 은행을 방문해 새 내역을 하나씩 수동으로 확인하던 세상을 위해 설계되었습니다. 그 세상에서 합계기장은 합리적인 공간 최적화입니다. 통장이 디지털 회계 워크플로우의 원본 문서인 세상에서는 데이터 파괴 메커니즘입니다 — 그리고 페이지에 더 이상 존재하지 않는 데이터를 자동화로 해결할 수는 없습니다.

앱만으로는 격차를 메울 수 없는 이유

일본의 개인 금융·회계 앱 — MoneyForward ME, Zaim, Moneytree, 그리고 업무용 freee와 Yayoi — 은 모두 API를 통한 은행 계좌 연동을 제공합니다. 인터넷 뱅킹이 활성화된 계좌의 경우 새 거래 내역이 자동으로 앱에 유입됩니다. 월간 지출을 관리하는 가계라면 이 정도면 향후 문제는 대부분 해결됩니다.

하지만 세금 신고를 준비하는 소상공인에게는 턱없이 부족합니다. 그 이유는 세 가지입니다:

앱은 맡은 일을 잘 해냅니다: 최근에 일어난 일을 보여주고 분류를 도와줍니다. 하지만 1970년대식 인쇄 문서와 구조화된 데이터를 기대하는 회계 시스템 사이의 다리가 되도록 설계된 것은 아닙니다. 그 다리는 여전히 사람입니다 — 그리고 앱은 아무리 편리해도, 다리 양쪽 끝이 얼마나 멀리 떨어져 있는지를 사람이 더 잘 깨닫게 해줄 뿐입니다.

오류가 누적되는 지점: 잔액 연쇄 검증

소규모 사업주가 다루는 모든 문서 — 청구서, 영수증, 구매 주문서, 배송장 — 중에서 통장은 한 가지 중요한 측면에서 독특합니다. 데이터 행이 서로 독립적이지 않다는 점입니다. 모든 행의 차인잔고는 이전의 모든 행이 정확해야만 올바릅니다. 200줄짜리 통장의 47번째 줄에 숫자 하나가 잘못되면 47번째 줄만 틀리는 것이 아닙니다. 48번째 줄부터 200번째 줄까지 모두 오염됩니다. 오류 이후에 인쇄된 모든 잔액은 실제와 어긋나게 됩니다.

이로 인해 다른 문서 유형에서는 발생하지 않는 검증 부담이 생깁니다. 청구서 더미라면 각각을 독립적으로 처리할 수 있습니다 — 23번째 청구서의 오류는 24번째 청구서에 영향을 미치지 않습니다. 그러나 통장의 경우 모든 행의 잔액을 검증하거나, 아니면 배치 내의 오류가 조용히 앞으로 전파되는 것을 감수해야 합니다. 대부분의 소규모 사업주는 가게 문을 닫은 뒤 늦은 밤에 일하면서, 그 위험을 인지하지 못한 채 두 번째 선택지를 택합니다.

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

和暦 문제: 연호가 바뀔 때마다 연도가 바뀌는 문제

일본에는 두 가지 병행 달력 체계가 있습니다. 세계 나머지 국가들이 사용하는 그레고리력과, 재위 중인 천황의 이름을 따서 연도를 표기하는 일본 연호(和暦, wareki)입니다. 통장에는 연호 형식으로 날짜가 인쇄됩니다: 令和6年3月15日. 회계 소프트웨어 — Yayoi, freee, MoneyForward — 는 두 형식을 모두 받아들일 수 있지만, 각 날짜가 어느 연호에 속하는지 알려주지 않으면 두 형식 간 변환이 불가능합니다. 그리고 연호가 바뀌면 연도 숫자는 1로 초기화됩니다.

실질적인 어려움은 이중 체계의 존재 자체가 아닙니다. 문제는 경계 연도 — 연호가 연중에 바뀌어 옛 연호와 새 연호가 같은 그레고리력 연도를 가리키는 해입니다:

통장 3개를 관리하고 청색신고를 제출하는 사업자의 경우, 연호 문제는 적요 코드 문제와 겹쳐집니다. 단순히 레이와 6년을 2024년으로 변환하는 것만이 아닙니다. MUFG 통장의 "振込TB1"이 일본우편은행 통장의 "振込"과 동일한 입금인지 해독하면서 동시에 변환해야 합니다 — 한 통장은 갱신 직전, 다른 통장은 갱신 직후에 인쇄되어 연호 라벨이 서로 다를 수 있는 달 동안 말입니다.

연호 달력은 사라지지 않을 것입니다. 정부 서식, 세금 문서, 은행 거래명세서 모두 연호를 사용합니다. 소규모 사업자가 입력해야 하는 회계 소프트웨어는 두 형식을 모두 받아들입니다. 그러나 두 형식 간의 변환은 여전히 사람의 수작업으로 남아 있으며 — 변환할 때마다 연도가 어긋나 잘못된 과세 연도에 거래가 표시될 위험이 있습니다.

더 빠른 입력이 해답이 아니다 — 변환 계층을 제거하는 것이 해답이다

구조적 문제가 통장 페이지와 회계 소프트웨어 사이의 수동 변환 계층이라면, 해결책은 "더 빨리 입력하기"나 "더 나은 앱 구하기"가 될 수 없습니다. 변환 단계를 거치지 않고 통장 데이터를 추출하는 방법 — 통장의 5열 형식을 읽고 구조화된 데이터를 직접 생성하여, 사용자가 은행별 적요 약어를 해독하거나 연호를 변환하거나 잔액을 수동으로 검증할 필요가 없는 방식이어야 합니다.

이 문제에 맞는 접근 방식은 의미 기반 추출입니다. 도구에 열의 의미를 지정합니다 — "날짜", "적요", "출금액", "입금액", "잔액" — 그러면 도구가 통장 페이지를 읽고 고정 템플릿을 매칭하는 대신 문서 레이아웃을 이해하여 각 값을 찾습니다. 일본 통장 형식은 은행 간에 표준화되어 있으므로, 의미 기반 모델은 MUFG, 일본우편은행, 지역 신용금고의 페이지를 동일한 열 정의로 읽을 수 있습니다. 은행별로 달라지는 것은 적요 코드뿐이며, 이는 도구가 그대로 추출하여 나중에 분류할 수 있게 해주는 텍스트일 뿐입니다.

이것이 맞춤 열 추출의 핵심 아이디어입니다. 필드 주위에 상자를 그리거나 은행별 파싱 규칙을 만드는 대신, 원하는 열 이름을 입력하고 통장 페이지를 업로드하면 됩니다. AI가 각 페이지를 읽고 표 형식 레이아웃을 이해하여 5개 열을 찾은 다음, 거래마다 스프레드시트 행을 채웁니다. 계산 열을 추가하면 — 예를 들어 "잔액 검증" — 도구가 잔액이 맞지 않는 모든 행에 플래그를 표시하므로, 데이터가 회계 소프트웨어에 들어가기 전에 오류가 발생한 위치를 정확히 알 수 있습니다.

첫 페이지 업로드부터 서식이 갖춰진 스프레드시트 생성까지의 전체 단계별 추출 워크플로는 일본 통장 추출 가이드에 문서화되어 있습니다. 여러 해에 걸친 여러 통장을 처리할 때는 일괄 처리 방식이 서로 다른 은행의 페이지를 단일 지출 원장으로 병합하고, 모든 연대 날짜를 변환하고 모든 잔액을 한 번에 검증합니다. 이는 통장 3권 × 3년이 280건의 거래, 1,400개의 데이터 포인트, 그리고 단일 페이지 추출이 여러분의 책상에 남겨 두는 수동 병합 단계를 의미할 때 중요합니다.

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

자주 묻는 질문

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