일본 은행 통장(通帳) 데이터 추출:
회계 및 세금 신고를 위한 완전 가이드
일본의 은행 통장 제도는 선진국 중에서도 독특합니다. ATM이 도트 매트릭스 또는 감열식 프린트 헤드로 실시간 인쇄하는 물리적 장부로, 모든 거래를 잔액이 함께 표시되는 5열 원장으로 기록합니다. 그리고 이를 주요 재무 기록으로 사용하는 460만 명의 개인 사업자와 소규모 사업체에게는 세금 신고의 결정적 원천 문서이기도 합니다. 2024년, 일본 전국은행협회(全国銀行協会)는 주요 은행 ATM이 디지털 뱅킹 이용이 늘어나는 상황에서도 연간 3억 건 이상의 통장 업데이트를 처리한다고 보고했습니다. 추출 문제의 관점에서 이 수치는 특정한 의미를 갖습니다. 통장은 사라져 가는 구식 형식이 아닙니다. 회계 워크플로우가 수용해야 하는 형식이며, 그 구조를 이해하는 것이 매년 세금 신고 기간마다 수 시간의 수작업 입력을 소모하는 데이터 입력 작업을 자동화하기 위한 전제 조건입니다.
핵심 요점
- 일본 통장은 은행 거래 내역서가 아닙니다. 47번째 줄의 숫자 하나를 잘못 읽으면 이후 153개 줄의 모든 잔액이 오염되는 연속 원장입니다.
- 2027년 세제 개편으로 서면 제출 청색신고 공제액이 ¥550,000에서 ¥100,000으로 축소됩니다. 이는 지금까지 해오던 수작업 통장 필사 방식을 계속할 경우 ¥450,000의 불이익을 의미합니다.
- 동일한 5열 추출 스키마로 MUFG, Japan Post Bank, 지역 신용조합의 통장을 한 번의 배치로 읽을 수 있습니다. AI가 값이 페이지의 어디에 있는지가 아니라 각 값의 의미를 읽기 때문입니다.
일본 통장이 독특한 추출 대상인 이유
대부분의 국가에서 은행 거래 내역서는 월간 요약본입니다. 특정 기간을 다루는 PDF 또는 종이 보고서로, 기초 잔액, 기말 잔액, 그 사이의 거래 내역이 포함됩니다. 각 내역서는 독립적입니다. 3월 내역서의 오독은 4월 내역서에 영향을 미치지 않습니다.
일본의 은행 통장(通帳, tsūchō)은 내역서가 아닙니다. ATM이 인쇄하는 연속 원장으로, 통장을 기계에 넣어 도트 매트릭스 또는 열전사 프린트 헤드로 새 거래 내역을 페이지에 직접 인쇄하는 방식으로 유지되는 연속적인 물리적 기록입니다. 각 행에는 다섯 개의 필드가 있습니다: 날짜(月日), 적요(摘要, tekiyō), 출금액(お支払金額), 입금액(お預り金額), 그리고 잔액(差引残高). 새 줄이 추가될 때마다 체인이 이어집니다. 47번째 줄의 잔액은 1번부터 46번까지의 모든 줄이 정확해야만 올바릅니다. 한 번의 오독은 이후의 모든 잔액을 오염시킵니다. 이는 잔액 오류(残高ずれ)라고 불리는 실패 모드로, 내역서 기반 은행 업무에는 없는 문제입니다.
이 인쇄 메커니즘은 대부분의 범용 OCR 도구가 처리하도록 설계되지 않은 2차 추출 문제를 만듭니다. 통장 페이지는 일관된 잉크 농도와 정렬을 가진 조판 문서가 아닙니다. 프린터 출력물이며, 인쇄 품질은 ATM 모델, 잉크 리본 수명, 프린트 헤드 청결 상태에 따라 달라집니다. 같은 은행의 두 통장이라도 6개월 간격으로 다른 ATM에서 갱신했다면 문자 농도, 정렬, 가독성이 눈에 띄게 다를 수 있습니다. 교체 주기가 끝나가는 도트 매트릭스 프린트 헤드는 더 가는 문자와 더 많은 점 간격을 만들어냅니다. 깨끗한 ATM이 선명하고 연속적인 획으로 인쇄하는 동일한 振込 코드가, 마모된 헤드에서는 분리된 점들의 집합체가 됩니다.
통장 형식은 전국은행협회(全国銀行協会)가 관리하며, 은행 간 데이터 교환, ATM 상호 운용성, 그리고 계좌 정보를 저장하는 뒷표지의 자기 띠(磁気ストライプ)에 대한 표준을 정합니다. ATM은 이 띠를 읽어 계좌를 식별한 후 거래 내역을 인쇄합니다. 즉, 여러분이 가진 통장은 설계된 문서가 아닌 프린터 출력물입니다. 형식은 일본의 모든 은행에서 5열 레이아웃이 일관되게 유지될 만큼 표준화되어 있습니다. 그러나 인쇄 품질은 그렇지 않습니다. 표준 형식과 가변적 실행 사이의 이 긴장 관계가 추출 과제를 정의합니다.
추출에 중요한 구조적 차이: 영국의 SA100 자진 신고 세금 신고서 또는 호주 BAS 명세서는 스냅샷입니다. 한 번 추출하고 외부 출처와 대조하면 끝입니다. 일본 통장은 체인입니다. 추출은 각 행의 정확성이 이전의 모든 행에 의존하는 연속성 작업입니다. 이를 내역서 기반 문서처럼 취급하고 페이지를 독립적으로 처리하는 것은 일본 회계 워크플로우에서 추출 실패의 가장 흔한 원인입니다.
일본의 은행 환경과 통장 추출에 미치는 영향
일본에는 물리적 통장을 발행하는 은행이 100개 이상 있으며, 5열 레이아웃이 표준이지만 글꼴 크기, 줄 간격, 지점 열(取抜店)의 유무, 단일 거래가 한 줄에 표시되는지 두 줄로 줄바꿈되는지 등의 세부 형식은 기관마다 다릅니다. 어떤 은행이 통장을 발행했는지 이해하는 것은 학문적인 문제가 아닙니다. 어떤 추출 과제가 발생할지 결정합니다.
| 은행 | 통장 스타일 | 추출 고려 사항 | 시장 역할 |
|---|---|---|---|
| MUFG Bank (三菱UFJ銀行) | 단일 행 입력, 날짜는 왼쪽, 지점 코드(取扱店) 열 포함. 깔끔한 현대적 레이아웃. | 추출이 가장 쉬움 — 일관된 도트매트릭스 정렬, 연호 연도 헤더가 페이지 상단에 명확히 인쇄됨. 지점 코드 열은 회계 요구에 따라 추출하거나 무시할 수 있는 추가 데이터 포인트. | 일본 최대 은행 — 기업 주거래은행 비중 7.93% |
| SMBC (三井住友銀行) | MUFG와 유사한 단일 행 형식. 연호 연도를 축약 표기할 수 있음 (R6 vs 令和6年). | 축약된 연호는 날짜 변환 시 축약 매핑에 대한 인지가 필요함. 그 외에는 MUFG와 난이도가 비슷함. | 주거래은행 비중 6.34%. 탄탄한 기업 고객 기반. |
| Mizuho Bank (みずほ銀行) | MUFG/SMBC와 유사. 전통적인 인쇄 형식; 연호 연도는 종종 전각 문자로 표기됨. | 전각 연호 문자는 문자 단위 OCR에서 개별 문자로 읽힐 수 있음. AI 기반 의미 추출은 날짜 필드를 전체로 읽어 이러한 문제를 방지함. | 주거래은행 비중 5.04%. 3대 메가뱅크 중 가장 전통적인 은행. |
| Japan Post Bank (ゆうちょ銀行) | 거래당 2행 형식 — 적요 필드가 두 번째 행으로 줄바꿈됨. 조밀한 인쇄. 지점 코드는 숫자로만 표시. | 가장 까다로운 표준 형식 — 2행 줄바꿈으로 인해 단일 행 형식으로 학습된 템플릿 기반 OCR은 적요 세부 정보를 놓칠 수 있음. 의미 추출은 두 행을 하나의 의미 단위로 읽어 처리함. 또한 Yucho Direct+ 계좌 보유자를 위한 '디지털 통장'도 제공. | 전국 네트워크 — ATM 24,000대 이상. 많은 개인 계좌의 기본 은행. |
| Resona Bank (りそな銀行) | 단일 행 형식. 중소기업 및 개인 고객에 강점; 통장에는 거래 행 뒤에 은행 부가 서비스 안내 문구가 포함되는 경우가 많음. | 거래 배치 사이에 인쇄된 부가 서비스 안내 문구는 거래 행과 정보성 텍스트를 구분하지 못하는 도구에서 데이터 행으로 오인될 수 있음. | Resona Group 소속 — 강력한 중소기업 기반. 지역 중심 은행 업무. |
| 지방은행 및 신용금고 (地方銀行・信用金庫) | 다양함 — 대부분 표준 5열 레이아웃을 따르지만 지역화된 인쇄 관례, 구형 ATM 하드웨어, 구식 연호 형식을 사용합니다. | 구형 ATM 하드웨어는 인쇄 품질의 편차가 더 큽니다. 1980년대에 개설된 통장에는 쇼와 연호(昭和) 날짜가 포함될 수 있으며, 쇼와 + 1925 변환이 필요합니다. 이러한 큰 편차는 의미 기반 추출이 필요한 가장 강력한 이유입니다 — 100개 이상의 지역 인쇄 관례를 템플릿으로 처리할 수 없습니다. | 합산하면 3대 메가뱅크를 합친 것보다 더 많은 중소기업 고객을 대상으로 서비스를 제공합니다. |
추출에 대한 실질적인 의미는 날짜, 적요, 출금, 입금, 잔액의 단일 열 스키마가 모든 은행에서 작동한다는 것입니다. AI는 템플릿의 픽셀 좌표를 일치시키는 것이 아니라 의미를 읽어 각 값을 찾습니다. 깔끔한 단일 줄 인쇄의 MUFG 통장과 두 줄 줄바꿈이 있는 유초 통장은 추출 엔진이 필드 위치가 아닌 필드 의미를 읽기 때문에 동일한 배치에서 동일한 5열 스프레드시트를 생성합니다. 이 열 기반 접근 방식에 대한 자세한 설명은 일본 통장 추출 단계별 가이드를 참조하십시오.
통장의 5열 구조 — 그리고 일반 OCR이 각 열에서 실패하는 이유
통장의 5열 레이아웃은 표면적으로는 우아하게 단순하지만 깊이 들어가면 기존 OCR에 구조적으로 적대적입니다. 각 열은 뚜렷한 실패 모드를 제시합니다:
月日 — 일본 연호 문제
통장의 날짜는 일본 연호를 사용합니다: 令和, 平成(헤이세이, 1989–2019), 昭和(쇼와, 1926–1989). R6.7.15로 표기된 날짜는 2024년 7월 15일입니다. H30.3.31은 2018년 3월 31일입니다. 연호 연도 헤더는 페이지 상단에 한 번만 인쇄되며, 같은 페이지의 이후 줄과 계속 페이지에는 월과 일만 표시됩니다. "7.15"만 단독으로 읽는 일반 OCR 도구는 연도가 없는 날짜를 얻게 되며, 세 페이지 앞의 연도 헤더는 인식하지 못합니다. 변환 공식은 결정적입니다 — 레이와 n = n + 2018, 헤이세이 n = n + 1988, 쇼와 n = n + 1925 — 그러나 어떤 줄에 어떤 공식을 적용할지 식별하려면 페이지 헤더와 내용 행 간의 관계를 읽어야 하며, 개별 셀만 읽어서는 안 됩니다.
摘要 — 코드 분류 격차
적요 열은 일본인이 즉시 분류할 수 있는 간결한 코드를 사용합니다: 振込, ATM(ATM 거래), 給与(급여 입금), 引落(자동이체), 手数料(은행 수수료, 일반적으로 ¥110–¥550), 利息(이자), カード(카드 거래). 이러한 코드를 충실히 재현하는 원시 추출은 거래 내역 목록을 생성합니다. 처리 중에 이를 분류하는 추출은 사전 분류된 원장을 생성합니다. 분류 로직은 계산 열로 한 번 정의할 수 있습니다: 적요에 "給与"가 포함되면 "급여 수입"; "引落"이 포함되면 "자동이체"; "手数料"가 포함되면 "은행 수수료"; "利息"가 포함되면 "이자 수입". 가장 모호한 코드는 振込입니다 — 알려진 고객 회사로부터의 ¥500,000 송금은 사업 수입이고, 개인으로부터의 ¥15,000 송금은 개인 거래일 가능성이 높습니다. 계산 열은 적요와 금액을 결합하여 모호성을 해소할 수 있습니다: 적요="振込"이고 금액 > 100000이면 "사업 수입"; 그 외에는 "개인 송금".
お支払金額 / お預り金額 — 상호 배타성 함정
주어진 거래는 출금 열 또는 입금 열 중 하나에만 기록되며, 둘 다에 기록되는 경우는 없습니다. 이러한 상호 배타성은 잔액 검증의 구조적 기반이지만, 일반적인 OCR 오류를 유발하기도 합니다: 정렬 오류로 인해 ¥30,000 입금이 출금 열에 배치되는 경우입니다. 해당 행에서 잔액 계산이 실패하고, 이후의 모든 행도 실패합니다. 이전 잔액 + 0 − ¥30,000(잘못된 열)은 인쇄된 현재 잔액과 같을 수 없기 때문입니다. 이는 무작위 오류가 아니라 상호 배타적 논리를 가진 열 기반 형식의 특징적인 구조적 오류이며, 위치별로 셀을 읽는 템플릿 기반 OCR이 특히 취약합니다.
差引残高 (Running Balance) — 자체 검증 엔진
잔액(差引残高)은 통장 추출에 있어 가장 큰 장점이자 가장 위험한 오류 지점입니다. 장점인 이유는 잔액 열이 자체 검증 기능을 내포하고 있기 때문입니다. 이전 잔액 + 입금 − 출금 = 현재 잔액이 성립해야 합니다. 추출 중 모든 행에서 이를 확인하는 계산 열(Computed Column)을 정의하면 — Balance Check (previous Balance + Deposit − Withdrawal = current Balance? 'OK' : 'REVIEW') — 데이터가 회계 소프트웨어에 들어가기 전에 검토가 필요한 행을 알 수 있습니다. 위험한 이유는 단 한 번의 오독 — 쉼표 하나가 빠져 ¥30,000이 ¥3,000으로 바뀌는 경우 — 이 해당 행의 잔액을 오염시키고, 다음 행의 검증을 오염시키며, 이후 모든 행에도 영향을 미치기 때문입니다. 거래 280건 중 47번째 행에서 한 번 오독이 발생하면 REVIEW 플래그가 233개 생성됩니다 — 그러나 근본 원인은 첫 번째 플래그 행입니다. 47번째 행을 수정하면 48~280번째 행은 올바르게 재계산됩니다. 이러한 연쇄 효과는 통장 데이터 입력 시 흔한 실수 가이드에서 다루며, 잔액 오류 방지에 대해 심도 있게 설명합니다.
자기 띠 (磁気ストライプ) — 하드웨어 의존성
뒷표지의 자기 띠에는 계좌번호, 지점 코드, 계좌 유형이 저장되어 있습니다. 통장을 ATM에 삽입하면 기계가 띠를 읽고 계좌를 식별한 후, 미출력 거래 내역을 불러와 인쇄합니다. 자기 띠는 기계 판독용 구성 요소입니다 — 여기에 포함된 계좌 정보는 통장 페이지에 텍스트로 인쇄되지 않습니다. 추출 목적상 계좌번호와 지점 정보는 현금카드(キャッシュカード), 앞표지 정보, 또는 수동 입력 중 하나에서 가져와야 하는 데이터 포인트입니다 — 통장 페이지 자체에는 이 데이터가 기계 판독 가능한 인쇄 형태로 포함되어 있지 않습니다. 오래된 통장의 자기 띠가 손상되면 ATM이 인쇄 업데이트를 위해 이를 읽을 수 없지만, 기존 인쇄 페이지 추출을 방해하지는 않습니다 — 인쇄된 거래 데이터는 자기 띠와 독립적입니다.
추출 워크플로우: 종이 통장에서 회계 준비 완료 스프레드시트까지
일본 통장 데이터 추출은 통장 한 권을 처리하든 열 권을 처리하든, 1년치든 5년치든 동일한 3단계 구조를 따릅니다. 설정 단계는 한 번 수행하면 이후 계속 재사용됩니다. 처리 단계에서는 추출 엔진이 작업을 수행합니다. 검증 단계에서는 출력 결과가 올바른지 확인합니다 — 통장의 자체 검증 잔액 열 덕분에 이 단계는 수동 조정보다 훨씬 빠릅니다.
출력 스키마 정의. 날짜, 적요(摘要), 출금액(お支払金額), 입금액(お預り金額), 잔액(差引残高) 등 다섯 개의 열 이름을 지정하고, 선택적으로 사전 분류 및 검증을 위한 계산 열을 추가할 수 있습니다. 이것이 맞춤 열 추출입니다: 출력을 정의하면 AI가 각 통장의 인쇄된 필드를 읽고 의미를 파악하여 해당 열에 매핑합니다. 동일한 열 스키마는 MUFG Bank, SMBC, Mizuho Bank, Japan Post Bank, 지역 신용조합 등 모든 은행에서 작동합니다. AI가 픽셀 좌표가 아닌 필드 의미를 읽기 때문입니다. MUFG의 단일 라인 레이아웃에 맞게 구성된 템플릿은 Japan Post Bank의 2줄 래핑에서는 실패할 수 있습니다. 그러나 의미 기반 스키마는 각 필드의 위치가 아닌 의미를 읽기 때문에 동일한 배치에서 두 형식을 모두 처리할 수 있습니다.
업로드 및 처리. 통장 페이지를 스캔하거나 촬영합니다 — 계좌 소유자 이름이 표시된 앞표지, 참고용 뒷표지, 모든 거래 페이지를 포함 — 모든 이미지를 단일 배치로 업로드합니다. 각 페이지는 동일한 열 스키마로 독립적으로 처리됩니다. 일본 연호 날짜는 출력 레이어에서 페이지별 올바른 연호 맥락을 적용하여 그레고리력(yyyy-mm-dd)으로 변환됩니다. 적요 코드는 원본 그대로 캡처되며 선택적으로 계산 열을 통해 지출 카테고리로 분류됩니다. 모든 행의 누적 잔액은 추출 중 이전 행의 잔액과 대조 검증되어 불일치가 표시됩니다.
내보내기 및 검증. 출력은 거래당 한 행, 각 필드가 자체 열에 있는 단일 Excel 파일입니다. 잔액 검증 열은 계산이 일치하는 모든 행에 OK를 표시하고, 불일치가 있는 행에는 REVIEW를 표시합니다. 약 280건의 거래가 있는 3년치 통장은 일반적으로 한두 개의 REVIEW 플래그를 생성합니다 — 잘못 읽은 쉼표, 오래된 페이지의 번짐된 숫자, 또는 인쇄 판독기를 혼란스럽게 한 수기 수정 등입니다. 해당 행을 수정하면 나머지 278건이 검증됩니다. 스프레드시트는 CSV 거래 데이터를 수용하는 모든 일본 회계 소프트웨어로 직접 가져올 수 있습니다.
파일은 안전하게 처리되며 저장되지 않습니다.
이 워크플로우를 직접 체험해 보려면 — 열 설정, 페이지 스캔 전략, 일반적인 오류 처리 등 — 단일 통장 추출 가이드에서 각 단계를 자세히 다룹니다. 여러 통장을 여러 연도에 걸쳐 처리하는 배치 전략은 배치 처리 가이드에서 다중 통장 병합, 페이지 간 연호 날짜 이월, 배치 규모의 잔액 검증을 다룹니다. 디지털 도구가 있음에도 수동 입력이 여전히 보편적인 이유를 분석한 내용은 일본 통장 수동 입력 문제 심층 분석을 참조하세요.
배치 처리: 통장 하나가 10년치 데이터가 될 때
통장 한 권에는 페이지당 약 8~10건의 거래가 있고 총 50~100페이지로, 계좌 활동에 따라 일반적으로 1~3년간 사용합니다. 청색신고를 하는 개인 사업자가 일상 운영(MUFG Bank), 세금 적립(Japan Post Bank), 급여용으로 각각 별도의 통장을 유지한다면 추출할 통장이 3권입니다 — 약 36페이지의 인쇄 거래, 280개 행, 세 가지 인쇄 방식에 걸쳐 있습니다.
배치 추출은 이를 단일 작업으로 처리합니다. 세 통장은 동일한 5열 스키마로 한 번의 업로드에 포함됩니다. 연호 날짜는 올바른 연호 맥락으로 페이지별로 변환됩니다 — MUFG Bank 통장은 약식 연호 연도(R6), Japan Post Bank 통장은 전체 연호 이름(令和6年), 신용조합 통장은 1980년대에 개설된 계좌의 쇼와 후기 거래를 포함 — 모두 출력에서 그레고리력 날짜로 변환됩니다. 동일한 배치에서 손으로 쓴 여백 메모를 보조 Notes 열로 처리하고, 계산 열이 거래를 지출 범주로 사전 분류하고 잔액 불일치를 표시합니다.
대안 — 단일 페이지 추출 후 수동 병합 — 은 사용자가 36개의 개별 스프레드시트 파일을 통합하고, 연도 헤더가 1페이지에 나타났다가 다음 7개의 연속 페이지에서 사라지는 페이지 간 연호 날짜를 교차 참조하고, 통장 경계를 넘어 잔액 연속성을 수동으로 검증해야 합니다. 3개 은행의 3년치 데이터를 수동 병합하는 단계만 약 2~3시간이 걸립니다. 배치 방식은 이를 완전히 제거합니다 — 업로드 한 번, 스프레드시트 하나, 검증 한 번. 전체 배치 워크플로우 아키텍처는 통장 페이지를 연간 지출 원장으로 배치 처리하는 가이드를 참조하세요. 수동 데이터 입력이 일본 중소기업 소유주에게 실제로 얼마나 많은 비용을 초래하는지 정량적으로 분석한 비용 분석은 시간과 오류율을 구체적인 수치로 제시합니다.
통장 배치 처리와 다른 시장 배치 시나리오의 차이: 영국에서 80건의 SA100 자진 신고서를 배치 처리하는 업무는 독립적인 문서를 다룹니다. 각 신고서는 독립적인 데이터 세트이므로 47번 신고서의 오독은 47번 신고서에만 영향을 미칩니다. 그러나 통장 배치는 상호 의존적인 페이지를 처리합니다. 잔액이 페이지 경계를 넘어 누적되므로 3페이지의 오독은 이후 모든 페이지의 검증을 조용히 손상시킵니다. 배치는 각 페이지를 독립적으로 처리하는 것이 아니라 문서 유형의 연속성 구조를 인식해야 합니다. 이것이 추출 시점에 Computed Column 검증을 수행하는 이유입니다. 사후 검증이 아니라, 검증된 출력을 생성하는 배치와 회계 소프트웨어 내에서 전체 재검증이 필요한 데이터를 생성하는 배치 사이의 엔지니어링 차이는 바로 여기에 있습니다.
일본 회계 생태계로: Yayoi, freee, MoneyForward 그리고 그 너머
추출된 스프레드시트는 다리와 같습니다. 목적지는 일본 회계 소프트웨어입니다. 개인 사업자와 소기업 시장을 지배하는 세 플랫폼 — Yayoi Accounting(弥生会計), freee Accounting(freee会計), MoneyForward Cloud Accounting(マネーフォワード クラウド会計) — 은 청색 신고 납세자의 대부분을 포괄합니다. 각 플랫폼은 서로 다른 가져오기 경로를 가지며, 추출 출력은 대상 플랫폼의 기대에 부합해야 합니다.
Yayoi Accounting(弥生会計). 특히 세무사(税理士) 사이에서 시장 선두주자입니다. 가져오기는 스마트 거래 가져오기(スマート取引取込) 기능을 통한 CSV 기반입니다. Yayoi는 날짜를 yyyy-mm-dd 형식으로 요구하므로 추출 단계의 연호-그레고리력 변환이 내보내기 전에 완료되어야 합니다. Yayoi는 CSV에 독자적인 "Yayoi 가져오기 형식"(弥生インポート形式)을 사용하므로 추출 출력은 Yayoi 필드 스키마(날짜, 차변 계정(借方勘定科目), 차변 금액, 대변 계정(貸方勘定科目), 대변 금액, 적요(摘要))에 매핑되어야 합니다.
freee Accounting(freee会計). 270개 이상의 API 엔드포인트와 MCP(Model Context Protocol) 지원을 갖춘 클라우드 네이티브 플랫폼으로, 세 플랫폼 중 API가 가장 풍부합니다. freee의 가져오기 템플릿 형식을 사용한 수동 CSV 업로드(取引 CSV インポート) 또는 자동 수집을 위한 freee API를 통한 가져오기가 가능합니다. freee의 자동 등록 규칙(自動登録ルール)은 통장 적요 코드를 인식하고 계정 과목(勘定科目)을 지정하도록 구성할 수 있습니다. 즉, 추출 단계는 정확한 코드 캡처에 집중하고 분류 로직은 회계 소프트웨어의 규칙 엔진에 맡길 수 있습니다.
MoneyForward Cloud Accounting(マネーフォワード クラウド会計). 데이터 마이그레이션 기능(他社ソフトデータの移行)을 통해 가져오며, 중간 CSV 형식으로 Yayoi 호환 형식을 선택합니다. MoneyForward의 강점은 통장 데이터, 신용카드 명세서, 영수증 스캔을 하나의 완전한 재무 현황으로 통합하는 대시보드입니다. 추출 출력이 Yayoi 호환 날짜 및 열 형식을 사용하면 동일한 열 매핑으로 MoneyForward에 가져올 수 있습니다.
동일한 CSV 가져오기를 지원하는 기타 플랫폼으로는 MJS Accounting(会計大将), TKC(FX2/MX 시리즈), OBC Kanjo Bugyo(勘定奉行), Sorimachi Accounting King(会計王), EPSON Financial Support(財務応援R4), PCA Accounting(PCA会計)이 있습니다. 통장의 5열 형식은 모든 일본 은행에서 표준화되어 있으므로 동일한 추출 출력이 CSV 거래 데이터를 가져오는 모든 회계 플랫폼에서 작동합니다. 날짜 형식, 금액 열, 적요 필드는 수신 소프트웨어와 관계없이 동일합니다.
추출 계획을 위한 세 가지 주요 플랫폼의 핵심 차이점: Yayoi는 CSV 전용이며 추출 결과가 Yayoi 가져오기 형식 호환 파일을 생성해야 합니다. freee는 CSV와 API를 모두 지원하며, API 경로를 통해 수동 파일 전송 없이 통장에서 회계로 이어지는 자동화 파이프라인을 구축할 수 있습니다. MoneyForward는 Yayoi 형식 CSV를 중간 형식으로 사용하므로 Yayoi 형식으로 출력된 추출 결과는 두 플랫폼 모두에서 작동합니다. API 연동을 설정하지 않은 대부분의 소규모 사업체의 경우, Yayoi 가져오기 형식을 추출 출력 표준으로 삼는 것이 가장 폭넓은 호환성을 제공합니다.
청색신고와의 연관성: 2027년 세제 개혁으로 통장 추출이 중요해지는 이유
2025년 12월 19일 여당이 발표한 일본 세제 개혁 대강(令和8年度税制改正の大綱)은 청색신고 특별공제(青色申告特別控除)를 재편합니다. 이 제도는 도입 이후 개인사업자가 복식부기로 장부를 작성할 가치를 만들어 온 세제 혜택입니다. 이 변경은 2027년 과세 연도부터 적용되며 통장 디지털화의 경제적 가치를 직접적으로 바꿉니다.
현행 제도에서 복식부기 장부를 작성하고 전자 신고를 하는 청색신고 신고자는 과세 소득에서 ¥650,000을 공제받습니다. 복식부기 장부를 작성하고 서면으로 신고하는 경우 ¥550,000을 공제받습니다. 2027년 개혁은 서면 신고 공제액을 ¥100,000으로 대폭 축소하고, e-Tax 전자 신고를 사용하면서 우수한 전자장부(優良な電子帳簿)를 유지하거나 자동 데이터 연동 기능을 갖춘 지정 전자 계산 시스템을 사용하는 신고자에게 ¥750,000의 최상위 공제액을 신설합니다. 3단계 구조는 다음과 같습니다:
| 신고 방법 | 장부 작성 | 공제액 (2026) | 공제액 | 변경 사항 |
|---|---|---|---|---|
| e-Tax + 우수한 전자장부 또는 자동 연동 | 복식부기 | — | ¥750,000 | 신설 |
| e-Tax 전자 신고 | 복식부기 | ¥650,000 | ¥650,000 | 변경 없음 |
| 서면 신고 | 복식부기 | ¥550,000 | ¥100,000 | −¥450,000 |
| 간이장부 | 단식부기 | ¥100,000 | ¥100,000 ¥0 (수입 > ¥10M) | 수입 제한 추가 |
통장 추출과의 연관성은 직접적입니다. 2026년에 복식부기와 수동 통장 필사로 서면 신고를 한 개인사업자는 ¥550,000을 받았습니다. 동일한 신고자가 2027년에도 동일한 수동 방식을 계속 사용하면 ¥100,000을 받게 됩니다 — 공제액이 ¥450,000 감소하며, 한계세율에 따라 약 ¥90,000–¥180,000의 추가 세금이 발생합니다. 이번 개혁으로 ¥650,000 등급을 받으려면 e-Tax 전자 신고가 의무화됩니다. 즉, 통장 데이터 입력부터 최종 신고 제출까지 전체 회계 파이프라인이 디지털화되어야 합니다. 통장 추출은 편의 기능이 아닙니다. 이는 이제 세금 공제 등급을 결정하는 체인의 첫 번째 고리입니다.
전자장부보존법에 따라, 금융 문서의 스캔본은 해상도(200 dpi) 및 컬러 요건을 충족하면 법적으로 유효한 기록으로 인정될 수 있습니다. 2024년 개정으로 타임스탬프 요건이 완화되었습니다 — 수정·삭제 이력이 있는 시스템에 저장된 스캔 문서는 별도의 타임스탬프가 더 이상 필요하지 않습니다. 통장 추출의 경우, 추출 입력으로 사용된 스캔 통장 페이지가 스캔 해상도가 200 dpi 컬러 요건을 충족하고 스캔 파일이 적합한 시스템에 저장되어 있다면 법적 기록 사본으로도 사용될 수 있습니다. 실물 통장은 법정 보존 기간인 7년 동안 계속 보관해야 합니다 — 추출은 수동 데이터 입력 단계를 대체할 뿐, 법적 기록을 대체하지 않습니다.
예외 사례 및 문제 해결
대부분의 통장 추출은 깨끗한 결과물과 함께 한두 개의 플래그가 지정된 행을 생성합니다. 아래의 예외 사례는 추출 결과에 사람의 검토가 필요한 시나리오를 다룹니다 — 문제가 발생하기 전에 어떤 모습인지 파악해 두면 답답한 문제 해결 과정이 2분 만에 해결되는 작업으로 바뀝니다.
수기 수정 (手書き通帳修正)
통장 사용자는 때때로 인쇄된 항목을 손으로 수정합니다 — 은행 직원이 잘못 인쇄된 금액 옆에 수정 사항을 적거나, 계좌 보유자가 적요란에 家賃 또는 仕入 같은 메모를 추가합니다. 이러한 메모는 법적으로 기록의 일부이며 회계상 중요한 정보를 담고 있습니다. 비전 모델 기반 추출은 인쇄된 텍스트와 함께 수기 메모를 읽을 수 있지만, 필기 품질은 다양합니다 — 선명한 볼펜 한자 메모는 일반적으로 읽을 수 있지만, 인쇄된 격자선을 가로지르는 각도로 적힌 흐릿한 연필 메모는 신뢰도가 낮습니다. 수기 메모가 거래 분류의 유일한 기록인 통장의 경우, 필기가 모호했던 행에 대해서는 실물 통장을 펼쳐 놓고 추출된 스프레드시트를 검토해야 합니다. AI가 읽을 수 있는 대다수를 처리하며, 검토는 예외 처리일 뿐 행별 일일이 확인이 아닙니다.
적요 코드 모호성 (摘要あいまい性)
알려진 거래처 회사명에서 온 ¥500,000의 振込은 사업 소득입니다. 개인에게서 온 ¥15,000의 振込은 개인 소득일 가능성이 높습니다. 통장의 적요 코드만으로는 이 둘을 구분할 수 없습니다 — 구분을 하는 것은 회계 소프트웨어의 분류 기능입니다. 추출은 코드를 충실히 캡처해야 하며, 분류 로직은 다운스트림에서 처리됩니다 — 회계 소프트웨어의 자동 분류 규칙 또는 적요 코드와 금액 임계값을 결합한 계산 열에서 말입니다. 일반적인 오류 패턴은 분류 규칙을 너무 공격적으로 작성하는 것입니다 — 모든 ¥100,000 이상의 振込을 "사업 소득"으로 분류하는 규칙은 일회성 가족 선물 ¥200,000을 잘못 분류할 수 있습니다. 규칙은 보수적으로 작성하여 명백한 사례만 분류하고 모호한 사례는 수동 검토로 남겨 두어야 합니다.
손상되거나 훼손된 통장 페이지
5년 이상 된 통장은 인쇄가 흐릿하거나, 물에 젖었거나, 잉크가 번졌거나, 거래 영역을 가로지르는 접힘 자국이 있는 페이지가 있을 수 있습니다. 흐린 인쇄의 경우 추출 전에 더 높은 해상도로 스캔하고 대비를 조정하면 판독성이 향상됩니다. 도트 매트릭스 문자를 왜곡하는 접힘 자국의 경우, 자연광 아래에서 각도를 주어 페이지를 촬영하면 접힘 그림자를 줄일 수 있습니다. 손상으로 거래 행을 읽을 수 없는 페이지의 경우 — 일반적으로 280행 중 1~2행 — 실물 통장을 기준으로 해당 행을 수동 입력으로 표시합니다. 추출은 나머지 278행을 처리합니다. 손상된 행의 실패는 검증 열에서 확인할 수 있습니다: 잔액 계산이 맞지 않는 행의 REVIEW 플래그로, 흔히 부분적으로 읽을 수 없는 금액 숫자로 인해 발생합니다.
디지털 통장(デジタル通帳)과 실물 통장 비교
일부 은행 — 특히 Japan Post Bank의 Yucho Direct+ 서비스 — 은 실물 통장을 대체하는 디지털 통장을 제공하며, 웹 기반 거래 조회와 CSV 내보내기 기능을 지원합니다. 그러나 내보내기 형식, 기간, 제공되는 열은 은행마다 다르며 회계 소프트웨어가 기대하는 형식과 일치하지 않는 경우가 많습니다. Japan Post Bank의 디지털 통장 CSV는 양력 날짜로 내보낼 수 있는 반면, ATM에서 출력한 동일 계좌의 실물 통장은 일본 연호 날짜를 사용하며, CSV는 최근 12개월만 포함하지만 실물 통장에는 전체 거래 내역이 있습니다. 회계 소프트웨어가 특정 CSV 형식을 요구하는 청색신고 신고자의 경우, 추출 경로 — 실물 통장 스캔 또는 디지털 통장 화면 캡처 — 를 통해 입력 형식과 관계없이 출력 단계에서 일본 연호에서 양력으로의 변환이 처리되는 일관된 형식의 결과물을 얻을 수 있습니다.
연호를 넘나드는 통장과 연도 헤더 누락
2018년에 개설되어 2024년에 갱신된 통장에는 平成과 令和 두 시대에 걸친 거래가 포함되어 있습니다. 연호 경계 — 平成31年에서 令和元年으로 전환 — 은 통장 중간에 위치합니다. 추출 과정에서는 연도 헤더가 平成에서 令和로 바뀌는 페이지에서 연호 변경을 감지하고 거래별로 올바른 오프셋을 적용해야 합니다. 마찬가지로, 같은 통장 내에서 연도 헤더를 다시 인쇄하지 않는 계속 페이지는 가장 최근에 헤더가 있는 페이지의 컨텍스트를 이어받습니다. 5페이지에 令和6年이 인쇄되고 6~8페이지에 월과 일만 인쇄된 경우, 추출은 5~8페이지의 모든 거래에 令和6年 컨텍스트를 적용하며, 1월 1일 경계 이후 9페이지에 令和7年이 인쇄되면 컨텍스트가 업데이트됩니다. 컨텍스트 전달이 누락되면 연도가 없는 거래("7.15")가 생성되어 타임라인에 배치할 수 없고 회계 소프트웨어 가져오기가 실패합니다.
자주 묻는 질문
통장 추출이 같은 배치에서 모든 일본 은행을 처리할 수 있나요?
네 — 단일 행 입력 방식의 MUFG Bank 통장, 거래당 두 줄 형식의 Japan Post Bank(ゆうちょ銀行) 통장, 간결 인쇄 방식의 지역 신용금고(信用金庫) 통장을 모두 같은 배치에 업로드하여 일관된 열로 구성된 통합 스프레드시트를 생성할 수 있습니다. 의미 기반 추출은 각 값의 의미를 읽어냅니다 — 날짜는 한 통장에서 R6.7.15로 인쇄되든 다른 통장에서 令和6年7月15日로 인쇄되든 날짜입니다. 동일한 5열 스키마가 모든 형식에 적용됩니다. 일본 연호에서 서기로의 변환은 각 페이지에서 감지된 연호 헤더를 기준으로 페이지별로 적용되므로, MUFG Bank 통장의 平成, Japan Post Bank 통장의 令和, 오래된 신용금고 통장의 昭和 등 서로 다른 연호의 통장이 포함된 배치도 모든 날짜를 출력에서 yyyy-mm-dd 형식으로 변환합니다.
추출 기능은 서로 다른 연호에 걸친 일본 연호(和暦) 날짜를 어떻게 처리하나요?
추출 기능은 각 페이지의 연호 연도 헤더를 읽고 올바른 변환 공식을 적용합니다: 레이와 n = n + 2018, 헤이세이 n = n + 1988, 쇼와 n = n + 1925. 연도 헤더가 없는 연속 페이지의 경우, 가장 최근에 헤더가 있는 페이지의 연호 맥락이 이어집니다. 통장 중간에 연호 경계가 발생하는 경우 — 예: 2019년 5월 1일 헤이세이 31년에서 레이와 1년으로 전환 — 엔진은 헤더가 바뀌는 페이지에서 연호 변경을 감지합니다. 경계 연도의 경우, 平成 헤더가 있는 페이지의 거래는 헤이세이 오프셋을, 令和 헤더가 있는 페이지의 거래는 레이와 오프셋을 적용합니다. 출력의 모든 날짜는 Yayoi, freee, MoneyForward와 직접 호환되는 서기(yyyy-mm-dd) 형식입니다.
잔액 검증이 여러 행에서 실패하면 어떻게 되나요?
연속된 여러 REVIEW 플래그는 거의 항상 단일 근본 원인 — 첫 번째 플래그가 지정된 행 — 에서 비롯됩니다. 쉼표 오독(¥30,000 → ¥3,000)이 47행에서 발생하면 47행의 잔액이 손상되고, 이로 인해 48행의 검증이 손상되며, 통장 끝까지 모든 후속 행이 영향을 받습니다. 47행을 수정 — 오독된 금액을 바로잡으면 — 48행부터 280행까지 올바르게 재계산됩니다. 계산 열 접근 방식은 실패 지점에서 문제를 포착합니다. 사용자가 첫 번째 플래그 행을 수정하면 나머지가 해결됩니다. 이 검증 단계가 없으면 오류는 시산표가 은행 명세서와 일치하지 않을 때 회계 소프트웨어 내부에서 표면화됩니다 — 이는 연쇄를 시작한 단일 오독을 찾기 위해 모든 행을 역추적해야 하는 대사 작업입니다. 추출 시점의 플래그는 2분의 수정입니다. 회계 시점의 플래그는 1시간의 법의학적 장부 정리입니다. 이 및 기타 일반적인 통장 데이터 입력 오류 모드에 대한 전체 설명은 일반적인 실수 가이드를 참조하십시오.
통장 페이지의 손글씨 메모는 추출 시 어떻게 처리되나요?
출력 스키마에 "Notes"라는 열을 정의하세요. 거래 내역 줄 옆에 있는 읽을 수 있는 손글씨 메모 — 家賃, 仕入(매입) 같은 메모나 振込 입금 항목 옆에 적힌 고객 이름 — 는 추출 과정에서 추가 컨텍스트로 포착됩니다. 손글씨 품질은 편차가 큽니다: 표준 한자로 또렷하게 볼펜으로 적힌 메모는 일반적으로 판독 가능하지만, 연필로 흐리게 적고 인쇄된 격자선을 가로질러 기울어진 메모는 신뢰도가 낮습니다. 손글씨 메모가 거래 분류의 유일한 기록인 통장의 경우, 손글씨 판독이 불확실했던 행에 대해서는 실제 통장을 펼쳐 놓고 추출된 스프레드시트를 검토해야 합니다. AI가 판독 가능한 대부분을 처리하므로, 검토 범위가 모든 행에서 메모 품질이 부족했던 일부 행으로 줄어듭니다.
추출된 통장 데이터를 Yayoi Accounting에 직접 넣어 청색신고를 할 수 있나요?
네 — 추출 결과물은 yyyy-mm-dd 형식의 날짜가 포함된 Excel 스프레드시트로, Yayoi Accounting(弥生会計)의 스마트 거래 불러오기(スマート取引取込) 기능을 통해 불러올 수 있습니다. 추출 열을 Yayoi의 필드 스키마에 매핑하세요: 날짜, 차변 계정(借方勘定科目), 차변 금액, 대변 계정(貸方勘定科目), 대변 금액, 적요(摘要). 계산 열을 사용해 거래를 사전 분류하는 경우 — 給与를 "Salary Income"으로, 引落를 "Utilities"로 매핑 — 계정 과목 필드가 가져오기 전에 이미 채워집니다. 회계 소프트웨어가 분류를 처리하도록 하려면 원본 적요 코드를 추출하고 Yayoi 또는 freee의 자동 분류 규칙을 구성하여 올바른 계정 과목에 매핑하세요. freee의 270개 이상의 API 엔드포인트는 수동 파일 전송 없이 자동화된 추출-회계 파이프라인을 가능하게 합니다. Yayoi와 MoneyForward는 CSV 가져오기를 사용하며, Yayoi 호환 형식이 공통 중간 형식으로 사용됩니다. 추가 지원 플랫폼에는 MJS Accounting, TKC, OBC Kanjo Bugyo, Sorimachi, EPSON, PCA가 포함되며, 모두 동일한 CSV 거래 형식을 수용합니다.
추출 후에도 실제 통장이 필요한가요?
전자장부보존법(電子帳簿保存法)에 따라 금융 문서의 스캔본은 200dpi 컬러 스캔 요건과 보관 준수 규칙을 충족하면 법적으로 인정되는 기록으로 사용될 수 있습니다. 그러나 실제 통장은 여전히 원본 문서로 남습니다. 국세청(国税庁)은 세무 조사 중 원본을 요청할 수 있습니다. 모범 사례: 회계 워크플로우를 위해 통장을 스프레드시트로 추출하고, 스캔한 페이지를 전자 기록 사본으로 보관하며, 법정 7년 문서 보존 기간 동안 실제 통장을 보관하세요. 추출은 수동 데이터 입력 단계를 대체할 뿐 — 법적 기록을 대체하지는 않습니다.
전체 그림: 일본 회계 워크플로에서 통장 추출의 위치
일본 개인사업자의 세무 신고 워크플로는 역사적으로 서로 연결되지 않은 두 부분으로 나뉘어 있었습니다. 전반부인 통장 데이터 입력은 수작업입니다. 책상 위에 펼쳐진 페이지, 머릿속으로 변환하는 일본 연호 날짜, 스프레드시트나 회계 소프트웨어에 한 줄씩 입력되는 금액. 후반부인 회계 및 신고는 Yayoi, freee 또는 MoneyForward 안에서 이루어지며, 데이터가 조정되고 분류되어 청색신고결산서(青色申告決算書)로 정리됩니다. 두 부분은 수동 전사로 연결되며, 그 연결의 품질에 따라 세금 신고가 첫 번째에 맞춰지는지 다섯 번째에 맞춰지는지가 결정됩니다.
통장 추출은 전사 연결을 자동화된 연결로 대체합니다. 통장 페이지가 이미지가 되고, 이미지는 검증된 날짜, 분류된 거래, 표시된 불일치 항목이 포함된 스프레드시트가 되며, 스프레드시트는 회계 소프트웨어로 가져와져 나머지 워크플로는 변경되지 않습니다. 추출 단계는 회계 소프트웨어, 세무 신고 절차, 청색신고 공제 구조를 변경하지 않습니다. 추출 단계는 그들을 지원하는 데이터 파이프라인을 변경할 뿐입니다.
2027년 세제 개혁에 따라 이 파이프라인에는 공제 가치가 부여됩니다. 종이로 유지하는 신고자는 ¥100,000을 받습니다. 파이프라인을 디지털화하는 신고자는 ¥650,000, 적격 전자장부보존법을 갖춘 경우 ¥750,000을 받습니다. ¥450,000–¥650,000의 격차는 추출 소프트웨어 사용에 대한 세액 공제가 아닙니다. 이는 수동 통장 데이터 입력의 현상 유지에 실제 비용을 매기는 세금 제도이며, 공제 폭이 좁아지기 전에 디지털 전환을 장려하는 것입니다.
단일 통장 추출 방법 가이드는 5열 구성과 첫 추출을 다룹니다. 배치 처리 가이드는 다년간, 다중 은행 통합을 처리합니다. 문제 분석은 도구가 있음에도 수동 현상 유지가 지속되는 이유를 설명합니다. 비용 분석은 지속적인 수동 입력으로 인한 재정적 손실을 정량화합니다. 일반적인 실수 가이드는 잔액 오차와 검증 전략을 다룹니다. 이 문서는 통장 추출이 왜 존재하는지, 어떻게 작동하는지, 회계 스택에서 어디에 위치하는지, 그리고 2027년 세제 개혁이 왜 청색신고를 제출하는 모든 일본 개인사업자에게 이를 기본 경로로 만드는지를 하나의 그림으로 연결합니다.