일본 통장 3년치
연간 지출 원장 한 권으로

일괄 처리에서 장부로의 간극: 단일 페이지 추출이 3년 문제를 해결하지 못하는 이유

통장 한 페이지를 추출하는 것은 문제의 절반을 해결한 부분입니다. 일본 통장 추출 워크플로 — 다섯 개 열을 정의하고, 페이지를 업로드하고, 거래당 스프레드시트 행 하나를 얻는 방식 — 은 한 페이지를 안정적으로 처리합니다. 해결되지 않은 나머지 절반은 추출이 끝난 후 36개의 개별 스프레드시트가 데스크톱에 남아 있고, 각각 8~10개의 거래를 포함하며, 각각 다른 은행의 다른 통장에서 나온 다른 페이지라는 상황입니다.

수동 병합이 단일 페이지 추출의 효율성을 무너뜨리는 지점입니다. 통장 3권 × 각 12페이지 = 36개의 개별 Excel 파일입니다. 각 파일의 거래를 하나의 마스터 시트에 추가하고, 세 가지 다른 연호 헤더(MUFG 페이지의 令和5年, Japan Post Bank 페이지의 R6, 디지털 내보내기의 2024)에 걸쳐 날짜순으로 정렬하며, 서로 다른 날짜에 동일한 은행 내 이체를 기록한 통장 간 잔액 열을 교차 검증해야 합니다.

월별 지출을 추적하는 가계도 비슷한 계산을 경험합니다. 3년 동안 매월 업데이트되는 개인 통장 2권(36회 업데이트, 각각 50~100페이지짜리 통장 2권에 걸쳐 있을 수 있음)에서 약 250건의 거래가 발생하며, 이를 단일 연간 지출 장부(家計簿)로 병합해야 합니다. MoneyForward ME와 Zaim은 은행 API에서 매일 새로운 거래를 가져오지만, API 등록 이전의 연도까지는 소급하지 않습니다. 바로 그 부분이 통장 서랍에 쌓여 있는 페이지들입니다. 이 앱들은 일별 가시성을 해결합니다. 3년 치 종이가 하나의 스프레드시트가 되어야 하는 연간 한 번의 순간은 해결하지 못합니다.

일괄 처리가 일본 통장에 실제로 가져오는 변화

일괄 처리를 은행 통장에 적용할 때는, 인보이스나 영수증 더미를 일괄 처리하는 것과는 다릅니다. 인보이스 배치는 각각 독립된 문서의 집합입니다. 각 인보이스의 데이터는 자체적으로 완결되며, 47번 인보이스의 판독 오류는 47번 인보이스에만 영향을 미칩니다. 반면 통장 배치는 상호 의존적인 페이지들의 집합입니다. 각 페이지는 이전 페이지의 내용을 이어받고, 차인 잔액은 앞으로 누적되며, 연호 헤더를 포함한 날짜 컨텍스트는 페이지 경계를 넘어 전달됩니다. 12페이지 분량 배치의 3페이지에서 단 한 번의 판독 오류가 발생하면, 이후 모든 페이지의 잔액 검증이 조용히 망가집니다.

통장 일괄 처리를 단일 페이지 추출과 구분 짓는 세 가지 차원이 있습니다:

단일 페이지 추출 도구는 각 페이지를 독립된 섬처럼 처리합니다. 일괄 도구는 이를 연속된 시퀀스로 처리합니다. 그리고 연속성을 기반으로 정의된 문서 유형의 경우, 이 차이가 출력물을 즉시 사용할 수 있게 만들지, 아니면 수동 재조립에 몇 시간을 소비하게 할지를 결정합니다.

和暦 문제, 일괄 처리로 인해 배가되다

통장 한 페이지의 일본 연호(和暦) 날짜 변환은 수동으로 처리 가능한 수준입니다. 상단의 연호 헤더를 읽고, 연호 오프셋을 알고, 각 날짜를 머릿속으로 변환하면 됩니다. 그러나 세 개의 통장에서 총 36페이지에 걸쳐 — ATM 출력물의 매달 첫 페이지에만 연호 헤더가 나타나고 이후 5~7페이지의 연속 페이지에서는 사라지는 경우 — 수동 변환 작업량은 '처리 가능'에서 '회계 소프트웨어에서 거부되는 오류의 근원'으로 바뀝니다.

데이터 경로를 생각해 보세요. MUFG ATM에서 출력된 통장은 2024년 7월 15일을 R6.7.15 형식으로 사용합니다. 같은 거래가 Japan Post Bank의 ATM에서 출력되면 전체 연호명인 令和6年7月15日을 사용할 수 있습니다. 사용자가 인터넷 뱅킹에서 일부 월을 CSV로 내보내면 해당 날짜는 2024-07-15로 도착합니다. 하나의 일괄 처리 내에서 동일한 날짜가 세 가지 방식으로 표현됩니다.

Yayoi Accounting(弥生会計)은 CSV 가져오기 시 날짜가 yyyy-mm-dd 형식일 것으로 예상합니다. "R6.7.15"라는 날짜 문자열을 보내면 가져오기가 자동으로 실패합니다. 해당 거래 행은 건너뛰어지고, 실패는 몇 시간 후 시산표가 통장과 일치하지 않을 때야 드러납니다.

일괄 추출은 출력 계층에서 연호 변환을 처리합니다. 각 통장 페이지에 날짜가 어떻게 표시되든 — 약식 연호 + 월.일, 전체 연호명 + 年月日, 또는 이미 서력인 경우 — 통합 스프레드시트의 모든 날짜는 yyyy-mm-dd로 도착합니다. 3년과 2개의 연호(2019년은 平成31년 1~4월과 令和元年 5~12월에 걸쳐 있음)에 걸친 일괄 처리의 경우, 추출 엔진은 사용자의 수동 주석이 아닌 각 페이지에서 감지된 연호 컨텍스트를 기반으로 거래별로 올바른 오프셋을 적용합니다.

연호 변환 로직은 결정적입니다. 레이와 n년 = 서력 (n + 2018)년, 헤이세이 n년 = (n + 1988)년, 쇼와 n년 = (n + 1925)년입니다. 문제는 산술이 아닙니다. 연호 헤더가 몇 페이지마다 한 번씩 나타나고 연호 자체가 일괄 처리 중간에 바뀔 수 있을 때, 어떤 연호가 어떤 페이지의 어떤 줄에 적용되는지 감지하는 것입니다. 템플릿 기반 OCR은 격리된 셀만 읽기 때문에 이 판단을 내릴 수 없습니다. 일괄 컨텍스트를 사용한 의미론적 추출은 페이지 헤더와 해당 콘텐츠 행 간의 관계를 읽기 때문에 가능합니다.

통장 일괄 처리 워크플로우 구축: 3단계

3년 치 통장 페이지를 연간 지출 원장 하나로 일괄 처리하는 워크플로우는 통장 3권을 처리하든 30권을 처리하든 동일합니다. 설정 단계(출력 열 정의)는 한 번만 수행하면 모든 배치, 모든 은행, 모든 과세 연도에 걸쳐 재사용됩니다. 이미 단일 통장 추출을 위해 열을 설정했다면, 여기서도 동일한 열 스키마를 재사용하면 됩니다.

적요 코드와 연간 지출 원장

통장의 적요(摘要) 열은 일본인이 보면 즉시 분류할 수 있는 간결한 코드를 사용합니다. 給与는 급여, 振込는 은행 송금, 引落은 자동 이체, 手数料는 은행 수수료, 利息는 이자, カード는 카드 거래를 의미합니다. 이러한 코드(振込, 振込, 引落, 給与, 振込)를 충실히 재현하는 원시 추출 결과는 거래 목록을 생성합니다. 반면, 처리 중에 이를 분류하는 일괄 추출은 연간 지출 원장을 생성합니다.

이 차이가 중요한 이유는 대상 회계 소프트웨어(Yayoi, freee, MoneyForward Cloud Accounting)가 원시 적요 코드가 아닌 계정 과목(勘定科目)이 포함된 분개장 항목을 필요로 하기 때문입니다. 단일 페이지 추출 후 수동 워크플로우는 스프레드시트를 열고 '카테고리' 열을 추가한 다음 280개 행을 살펴보며 급여 입금에는 売上(매출)을, 자동 이체에는 水道光熱費(공과금)을 할당하는 것입니다. 3년 치 배치의 경우, 이는 약 45분의 반복적인 분류 작업입니다. 振込 같은 코드를 하위 분류(고객 지급 vs. 친구의 저녁 식비 상환)해야 한다면 더 오래 걸립니다.

추출 중에 적요 코드를 지출 카테고리로 매핑하는 계산 열(Computed Column)을 사용하면 — 給与는 "Salary Income", 東京電力으로의 引落은 "Utilities", 手数料는 "Bank Fee", 利息는 "Interest Income" — 출력 결과가 거래 목록에서 사전 분류된 원장으로 바뀝니다. 매핑 규칙은 열 스키마에 한 번 정의되며 280개 행 모두에 자동으로 적용됩니다.

동일한 계산된 분류 로직은 설명 필드만으로는 파악할 수 없는 맥락이 필요한 코드도 처리합니다. 입금처 필드에 알려진 거래처 회사명이 있는 ¥500,000의 振込은 사업 수입입니다. 개인으로부터의 ¥15,000 振込은 개인 송금일 가능성이 높습니다. 계산 열은 설명 코드와 입금액을 결합하여 다음과 같이 분류할 수 있습니다: if Description="振込" and Amount > 100000 then "사업 수입"; if Description="振込" and Amount <= 100000 then "개인 송금". 추출 엔진은 처리 중에 이 로직을 평가하며, 출력 시 분류 결정이 완료된 상태로 제공됩니다. 사용자는 모든 결정을 처음부터 내리는 대신 승인하거나 재정의하면 됩니다.

잔액 오류 전파: 일괄 처리에서 한 번의 오독이 이후 모든 행을 망가뜨리는 이유

통장의 차인 잔액(差引残高)은 회계 검증에 있어 가장 큰 장점이자, 일괄 처리에서 가장 위험한 오류 모드입니다. 은행 명세서는 월별 요약본입니다. 14행의 오독은 14행에만 영향을 미칩니다. 반면 통장은 원장입니다. 15행의 잔액은 14행의 잔액에 15행의 입금액을 더하고 15행의 출금액을 뺀 값과 같습니다. 14행의 오독, 즉 쉼표 하나가 빠져 ¥30,000이 ¥3,000으로 읽히면 14행의 잔액이 틀어지고, 이는 15행의 잔액 확인을 망가뜨리며, 16행으로, 그리고 통장의 모든 후속 행으로 오류가 연쇄적으로 전파됩니다.

10건의 거래가 있는 단일 페이지 추출에서는 오류 연쇄가 페이지 경계에서 멈춥니다. 다음 페이지는 자체 잔액 연속성으로 새로 시작하기 때문입니다. 36페이지에서 병합된 280건의 거래 일괄 처리에서는 잔액이 N페이지의 마지막 행에서 N+1페이지의 첫 행으로 이어지기 때문에 오류 연쇄가 페이지 경계를 넘어갑니다. 3페이지 7행의 쉼표 하나 오독으로 인해 253개의 잘못된 잔액 확인 결과가 생성됩니다. 해당 지점 이후의 모든 행이 잔액 확인에 실패하여, 한 행씩 거슬러 올라가지 않고는 어떤 행이 문제를 일으켰는지 식별하는 것이 불가능해집니다.

계산 열 접근 방식(잔액 확인 (이전 잔액 + 입금 − 출금 = 현재 잔액? 'OK' : '검토'))은 실패 지점에서 문제를 포착합니다. 3-7행은 '검토'로 표시됩니다. 3-7행의 잔액에 의존하는 3-8행도 '검토'로 표시되지만, 사용자는 3-7행을 먼저 수정해야 한다는 것을 알 수 있습니다. 그러면 3-8행부터 일괄 처리 끝까지 올바르게 재계산됩니다. 수많은 'OK' 행 사이에 하나의 '검토' 행은 정확히 지목된 수정 사항입니다. 연속된 200개의 '검토' 행은 첫 번째 플래그가 지정된 행에 단일 근본 원인이 있음을 의미합니다.

이 검증 로직은 문서 간 연속성이 동일한 연쇄 위험을 생성하는 다른 일괄 추출 시나리오에도 직접 적용됩니다. 80개의 SA100 자진 신고서를 하나의 스프레드시트로 통합하는 영국 세무 회계 법인은 각 신고서의 데이터가 독립적이므로 독립 문서를 처리합니다. 300개의 PAYG 지급 요약서를 일괄 처리하는 호주 급여 팀도 동일한 독립성에 직면합니다. 통장 일괄 처리는 문서 자체가 연속성을 생성하기 때문에 다릅니다. 그리고 일괄 처리를 인식하는 추출이 이 연속성을 존중할 때, 이는 숨겨진 시한폭탄이 아닌 내장된 감사 추적 장치가 됩니다.

자주 묻는 질문

서랍 속에서 기다리는 통장

3년 치 통장 페이지가 서랍에 보관되어 있는 이유는 데이터에 접근할 수 없어서가 아닙니다. 모든 거래가 깨끗이 인쇄되어 있고, 행당 5개 열, 모든 줄에 차인 잔액이 표시되어 있습니다. 문제는 그 양이 수동 입력이 지루함을 넘어 시간 낭비로 느껴지는 임계점을 넘었기 때문입니다. 청색신고자가 280건의 거래를 행당 2분씩 수동으로 입력한다면(날짜 읽기, 적요 코드 해독, 금액 입력, 잔액 확인) 데이터 입력만으로 약 9시간이 소요됩니다. 연간 65만 엔 공제는 장부 정리를 위한 보상이지, 은행 데이터를 다시 입력하는 대가가 아닙니다.

일괄 추출은 이러한 계산을 바꿉니다. 9시간의 입력 작업이 통장 페이지 18분 스캔과 계산 열 플래그 확인 2분으로 단축됩니다. 280건 중 REVIEW로 표시된 1~2건의 행에서 잔액 확인이 잠재적 오독을 알리는 경우입니다. 나머지 278건은 추출 중 자동 검증을 통과했으며 추가 검토 없이 회계 소프트웨어로 가져올 준비가 되었습니다. 다음 해의 일괄 작업은 다른 페이지로 동일한 열 스키마를 사용합니다. 그 다음 해에도 다시 사용합니다. 전국은행협회가 규정하고 은행 ATM이 인쇄하며, 전국 모든 금융 기관에서 표준화된 통장 형식은 변하지 않을 것입니다.