고객 50명의 세금 신고서,
신고 시즌별 고객 요약 한눈에
가쿠테이 신코쿠 시즌에 개인 고객 80명을 처리하는 중간 규모의 세무사 사무소는 서류상으로는 사라졌다가 실제 업무에서 다시 나타나는 워크플로 문제를 안고 있습니다. 서류상으로는 고객이 freee, Yayoi(弥生), 또는 국세청 작성 코너에서 생성된 세금 신고서 PDF를 건네면 세무사가 검토합니다. 실제로는 세무사가 자신의 분석 템플릿(고객별 한 행과 B양식의 모든 항목에 대한 열이 있는 스프레드시트)을 열고 모든 숫자를 다시 입력합니다. 첫 번째 표에서 수입 합계. 7개 항목 공제란에서 공제액. 계산 섹션에서 과세 소득. 원천징수 섹션에서 선납 세액 공제. 최종 납부 세액 또는 환급액. 이 작업을 고객 80명에게 반복합니다. 계산은 간단합니다. 신고서당 50개 이상의 필드, 고객 80명, 필드당 약 15초의 재입력 시간은 16시간 이상의 데이터 입력 작업이며, 이는 모든 시간이 이미 할당된 4주 기간에 집중됩니다. 80개의 신고서를 한 번에 업로드하여 읽고 고객당 한 행씩, 모든 필드가 해당 열에 있는 결과를 출력하는 일괄 처리 워크플로는 이 16시간을 서류 더미를 스캔하는 시간으로 단축시킵니다.
핵심 요약
- 고객 세금 신고서당 50개 필드를 각 15초씩 재입력하면, 고객 80명을 기준으로 4,000회 이상의 필드 전사 작업이 발생합니다. 이는 3월 15일 마감일이 오차를 허용하지 않는 2월에 집중된 16시간의 데이터 입력입니다.
- 병목 현상은 타자 속도가 아니라 인지 매핑, 즉 PDF의 시각적 레이아웃에 인쇄된 값을 스프레드시트 셀에 일치시키는 작업을 시즌 동안 4,000번 반복하면서 피로로 인해 오류율이 누적되는 데 있습니다.
- 출력 열을 한 번 정의하고 80개의 신고서를 한 번에 업로드하면 AI가 각 필드의 의미를 읽습니다. 사회보험료 공제는 신고서가 freee, Yayoi, 또는 2022년 수기 작성 양식 중 어디에서 왔든 동일한 열에 유지되므로, 2월에는 인쇄된 숫자를 다시 입력하는 대신 공제 누락 항목을 찾는 데 집중할 수 있습니다.
개인 신고 처리가 50건에서 멈추는 이유
세무사가 한 고객의 신고서를 검토할 때 PDF를 열고, 숫자를 읽고, 스프레드시트에 입력한 후 다음으로 넘어갑니다. 신고서당 5분(50개 필드에 걸쳐 필드당 30초)이면 한 건은 효율적입니다. 10건은 오전 내내 걸립니다. 50건은 키 입력에 소모되는 청구 가능 시간 1주일입니다. 그리고 그 주는 2월, 일 년 중 가장 짧은 달에 찾아옵니다. 소득세법 제120조에 따른 신고 마감일 3월 15일을 앞두고, 작년 신고서를 다시 입력하는 데 보내는 모든 하루는 올해 고객과의 세금 전략 검토에 쓰지 못하는 하루입니다.
구조적 문제는 세무 신고서가 문서로서 세무서에 최적화되어 있고, 세무사에게는 그렇지 않다는 점입니다. B양식의 필드는 중간 소계가 있는 7개의 독립적인 계산 블록으로 구성됩니다. 1면의 공제 블록은 세로 목록입니다. 2면의 소득 내역은 다열 가로 표입니다. 수지내역서(収支内訳書) 또는 청색 신고 결산서(青色申告決算書)는 두 곳 모두에 입력됩니다. 세 문서를 모두 읽고 이를 스프레드시트의 단일 행으로 통합하는 것은 인지적 매핑 작업입니다. 세무사의 뇌는 고객당 3개의 PDF에 걸쳐 조인 연산을 수행하는 것입니다. 80건의 경우 240개의 PDF 평가가 필요하며, 피로로 인해 오류율이 증가합니다.
진정한 병목 현상은 입력 속도가 아닙니다. 컨텍스트 전환입니다. PDF에서 50개 필드를 다시 입력하는 세무사는 뇌가 설계되지 않은 작업, 즉 시각적 레이아웃의 인쇄된 값을 스프레드시트 그리드의 셀에 일치시키는 작업을 수행하고 있습니다. 이러한 시각적 매핑의 인지적 부하가 4,000회(50개 필드 × 80건) 반복되면 오후 검토가 이틀 분량의 데이터 입력 작업으로 변합니다. 일괄 추출은 매핑 단계를 완전히 제거합니다. 세무사는 출력 열을 한 번 정의하고 모든 신고서를 업로드하면 각 고객의 모든 필드가 이미 해당 열에 있는 하나의 행을 받게 됩니다.
일괄 가쿠테이 신코쿠 워크플로우의 실제 모습
80건의 고객 신고를 처리하는 세무사의 일괄 처리 워크플로우는 세 단계로 구성되며, 첫 번째 단계인 열 정의는 일회성 투자로 이후 매 신고 시즌마다 그 가치를 발휘합니다.
고객 요약 컬럼 스키마를 한 번 정의하세요
세무사 고객 요약의 표준 컬럼 세트는 네 그룹으로 구성됩니다. 수입 항목: 사업소득(収入金額), 부동산소득, 급여소득, 잡소득. 경비 항목: 필요경비, 소득 종류별 순소득. 공제 항목: 사회보험료공제, 소규모기업공제 등 공제, 생명보험료공제, 지진보험료공제, 의료비공제, 배우자공제, 부양공제, 기초공제. 세액 항목: 과세소득금액, 산출세액, 배당공제, 외국세액공제, 예정납세액, 원천징수세액, 납부세액 또는 환급세액. 고객 메타데이터: 고객명, 과세 연도, 청색 신고 또는 백색 신고 여부, 사용 회계 소프트웨어. 이 컬럼들은 영구적인 출력 스키마가 됩니다. 매년 모든 고객의 신고서가 어떤 소프트웨어로 생성되었는지, 또는 고객이 연중 freee에서 Yayoi로 전환했는지와 관계없이 동일한 컬럼에 매핑됩니다.
80건의 신고서를 한 번에 업로드하세요
PDF를 스캔하거나 수집하세요. 각 고객의 신고서는 일반적으로 4~6페이지입니다. 제1표 2페이지, 제2표 1페이지, 그리고 수입원 수에 따라 수지내역서 또는 청색신고결산서 1~3페이지로 구성됩니다. 모든 신고서를 단일 배치로 업로드하세요. AI는 각 고객의 페이지를 독립적으로 처리합니다. 동일 고객의 페이지가 하나의 신고서를 구성함을 인식하고, 컬럼 스키마에 정의된 모든 필드를 추출하여 고객당 한 행을 출력합니다. 신고서가 5페이지인 고객의 경우, 행이 조합되기 전에 모든 5페이지가 읽히므로, 제1표의 총 공제액이 제2표의 개별 공제 항목과 대조되는 등 시트 간 값이 한 번에 캡처됩니다. 처리는 혼합 형식을 지원합니다. freee로 생성된 신고서(산세리프 글꼴, 오른쪽 정렬 합계), Yayoi 인쇄물(세리프 글꼴, 다른 행 간격), 2022년에 손으로 작성된 스캔 종이 신고서 등 모든 형식이 동일한 배치에서 처리됩니다. 의미론적 추출은 템플릿 좌표가 아닌 필드 의미를 기준으로 읽기 때문입니다.
고객 요약 스프레드시트를 내보내고 검토를 시작합니다
출력 결과는 각 고객이 한 행, 각 필드가 한 열에 배치된 하나의 Excel 파일입니다. 이제 세무사는 80개의 개별 PDF 대신 구조화된 데이터 세트를 갖게 됩니다. 과세 소득별로 정렬하여 소득 구간 임계값에 근접한 고객을 식별합니다. 공제 총액별로 정렬하여 사용 가능한 공제를 충분히 활용하지 못하는 고객을 찾아냅니다. 예를 들어, 작년에 병원을 방문한 사실을 알고 있는 고객의 의료비 공제(医療費控除) 열에 ¥0이 표시되면 검토 전화를 유발합니다. 선납 세액(予定納税額)으로 필터링하여 큰 환급이 예상되는 고객을 식별합니다. 이는 3월 15일 마감일 전에 일정을 조정해야 하는 우선순위입니다. 더 중요한 것은, 자동 검증을 위해 계산 열을 추가하는 것입니다. 개별 공제 필드의 합계가 Sheet 1에 인쇄된 총 공제액과 일치하는지 교차 확인하고, 불일치가 있는 경우 "CHECK" 레이블로 표시합니다. OK 값 열에서 하나의 CHECK는 정확히 어느 행을 다시 확인해야 하는지 알려주며, 모든 행을 수동으로 감사할 필요가 없습니다.
파일은 안전하게 처리되며 저장되지 않습니다.
고객 간 공제 비교: 이상치 발견
열 형식의 고객 요약 스프레드시트는 개별 PDF 더미로는 불가능한 것을 가능하게 합니다: 고객 간 공제 패턴 분석입니다. "의료비 공제(医療費控除)" 열을 내림차순으로 정렬하면 상위 5개 행이 작년에 상당한 의료비를 지출한 고객을 보여줍니다. 이 정보는 세무사가 해당 고객에게 조세특별조치법 제4조의5(租税特別措置法第4条の5)에 따라 도입된 대체 의료비 공제 제도인 셀프메디케이션 세제(セルフメディケーション税制)를 고려했는지 질문하도록 유도합니다. 이 제도는 12,000엔을 초과하는 일반의약품 구매에 대해 별도의 공제 경로를 제공합니다.
"생명보험료 공제(生命保険料控除)"로 정렬하면 일반 생명보험, 개인연금, 간병보험의 세 가지 하위 항목(각각 최대 40,000엔)에 걸친 법정 최대 한도인 120,000엔을 보여주는 행이 해당 공제를 최대한 활용하는 고객을 알려줍니다. 해당 고객의 프로필에 적용되어야 하는 공제 항목에서 0엔이 표시되는 행(예: iDeCo(イデコ)가 널리 이용 가능함에도 소규모기업공제 등(小規模企業共済等掛金控除) 공제가 없는 자영업자 고객)은 신고 마감일 전에 5분 통화로 해결할 수 있는 계획상의 공백을 알려줍니다.
가장 중요한 패턴: 공제 미활용. 연중 국민연금(国民年金)과 국민건강보험(国民健康保険) 보험료를 납부하는 고객은 사회보험료 공제(社会保険料控除)에 납부한 전액이 표시되어야 합니다. 해당 열에 null 또는 0 값이 나타나고, 고객이 자영업자이며 두 가지를 모두 납부하고 있음을 알고 있다면, 이는 추출 과정에서 항목이 누락되었거나 고객이 증명서를 제출하지 않았음을 의미합니다. 어느 쪽이든, 열 기반 정렬을 통해 신고서 제출 전에 이를 발견할 수 있지만, PDF 더미에서는 5페이지 분량 문서의 2페이지에 묻혀 있을 뿐입니다.
선납세 추적: 누가 납부해야 하고, 누가 환급받을까
일본의 선납세 제도(予定納税, 요테이 노제이)는 전년도 납세액이 15만 엔을 초과한 납세자에게 2회에 걸쳐 선납을 요구합니다 — 각각 전년도 세액의 약 1/3씩, 7월 31일과 11월 30일까지 납부합니다. 선납액은 해당 연도의 B양식에 기재되어 최종 세액 계산 시 공제됩니다. 80명의 고객을 관리하는 세무사에게 선납세는 두 가지 업무 우선순위를 만듭니다.
첫째, 선납세(予定納税額)와 원천징수세(源泉徴収税額)의 합계가 계산된 세액(算出税額)을 초과하는 고객은 환급 대상입니다 — 신고가 빠를수록 환급도 빨리 처리됩니다. 순 차액(계산 세액 − 선납세 − 원천징수세, 음수 = 환급)을 기준으로 열 정렬을 하면 환급 대상 고객이 신고 대기열 상단에 표시됩니다.
둘째, 선납세가 비정상적으로 높은 소득 연도(예: 일회성 프로젝트로 2024년 소득이 급증한 경우)를 기준으로 계산된 고객은 수십만 엔을 초과 납부했을 수 있습니다. 선납액은 소득세법 제107조(所得税法第107条)에 따라 전년도 신고서에서 자동 계산되지만, 세무서는 소득 감소에 따라 이를 하향 조정하지 않습니다. 2025년 소득이 400만 엔이지만 2024년 소득이 700만 엔이어서 더 높은 금액을 기준으로 선납 분할납부가 발생한 고객은 필요액보다 30만 엔 이상을 더 납부했을 수 있습니다. 표 형식 요약에서 "선납세" 값이 "계산 세액"보다 현저히 큰 행은 즉시 눈에 띕니다. PDF 더미에서는 5페이지 분량 문서의 1페이지에 있는 한 필드의 숫자에 불과하며, 세무사가 모든 고객에 대해 이 두 필드를 구체적으로 비교하지 않으면 보이지 않습니다.
| 고객 시나리오 | 선납세 (予定納税) | 계산 세액 (算出税額) | 순 포지션 | 우선순위 |
|---|---|---|---|---|
| 소득이 700만 엔에서 400만 엔으로 감소 | ¥420,000 | ¥110,000 | −¥310,000 (환급) | 즉시 신고 |
| 안정적 소득, 표준 원천징수 | ¥180,000 | ¥210,000 | +¥30,000 (미납) | 기한 내 신고 |
| 첫해 프리랜서, 선납세 없음 | ¥0 | ¥85,000 | +¥85,000 (미납) | 기한 내 신고 |
| 급여 + 부업, 원천징수로 충당 | ¥0 | ¥12,000 | −¥138,000 (원천징수로 환급) | 환급 신고 |
세무사 소프트웨어 연동: Yayoi, TKC, MJS
일본 세무사 소프트웨어 생태계는 세 가지 플랫폼이 주도하고 있으며, 추출된 고객 요약 스프레드시트는 이들 모두에 직접 매핑됩니다. 그 이유는 세 플랫폼 모두 공통 요구사항, 즉 소프트웨어가 데이터를 처리하려면 먼저 고객 데이터가 열(column) 형태로 정리되어야 하기 때문입니다.
Yayoi Tax (弥生シリーズ). 중소 규모 세무사 사무소에서 시장 점유율 1위입니다. Yayoi Tax Suite는 "외부 데이터 가져오기(外部データ取込)" 기능을 통해 CSV 가져오기로 고객 데이터를 이전할 수 있습니다. 추출된 열 — "사업 소득(事業所得)", "사회보험료 공제(社会保険料控除)" — 은 Yayoi의 내부 계정 필드에 직접 매핑됩니다. 시즌당 80건의 신고를 처리하는 사무소의 경우, CSV 가져오기는 고객 배치당 한 번의 가져오기 작업으로 약 16시간의 수동 데이터 입력을 대체합니다. 절약된 시간은 고객 파일당 검토 시간을 늘리는 데 직접 사용되며, 이는 세무사 수수료를 정당화하는 핵심 업무입니다.
TKC (FX2/MX 시리즈). 중대형 세무사 법인에서 지배적인 플랫폼입니다. TKC의 데이터 이전 유틸리티는 열 헤더가 포함된 형식화된 CSV를 허용합니다. 추출 결과는 TKC의 표준 순서로 열 스키마가 정의될 때 TKC의 예상 필드 순서와 일치합니다. 시즌당 200건 이상의 고객 신고를 처리하는 TKC 사무소의 경우, 일괄 추출은 데이터 입력 단계를 여러 주에 걸친 직원 배정에서 단일 오후의 스캔 및 업로드 작업으로 단축합니다. 추출의 계산 열(Computed Column) 검증 — 시트 1 합계와 개별 공제 필드를 교차 확인 — 은 데이터가 TKC의 검토 파이프라인에 들어가기 전에 산술 오류를 포착하여, 회사의 품질 관리 워크플로를 지연시키는 수동 재정의 플래그 발생을 줄입니다.
MJS Accounting (会計大将). 기업 내 회계 부서와 독립 세무사 사무소 모두에서 널리 사용됩니다. "타 시스템 데이터 가져오기(他システムデータ取込)" 기능을 통해 가져오며, 추출된 Excel 출력은 중간 형식 변환 없이 직접 가져올 수 있습니다. MJS의 내장 감사 기능 — 공제 총액 확인, 필수 필드 누락 감지 — 은 가져온 열 데이터를 기반으로 작동하여, 추출 자체의 계산 열 교차 검증 이후 두 번째 검증 계층을 제공합니다. 동일한 데이터 세트에 대한 두 번의 독립적인 검증 패스는 각 계층만으로는 놓칠 수 있는 오류를 포착합니다.
연동 경로는 플랫폼에 관계없이 일관됩니다. 추출 도구에서 열을 한 번 정의하고, 시즌 신고서를 단일 배치로 업로드하고, 스프레드시트를 내보낸 후 세무 소프트웨어로 가져옵니다. 열 스키마는 과세 연도에 걸쳐 유지됩니다. NTA가 매년 1월 공식 신고 안내서인 '가쿠테이 신코쿠의 안내(確定申告の手引き)'에 게시하는 B양식의 연례 개정은 일반적으로 줄 번호와 안내 문구를 조정하지만 필드 구조는 유지합니다. "의료비 공제(Medical Expense Deduction)"라는 열은 2025년, 2026년, 2027년에도 동일한 개념에 매핑됩니다. 추출은 양식상의 위치가 아닌 의미를 기준으로 필드를 읽습니다.
다년도 추적: 과거 데이터셋 구축
2026년에 80건의 신고서를 처리하고 2027년에도 동일한 열 스키마를 사용하는 세무사는, 이전에는 수년간의 수동 재입력을 통해서만 가능했던 데이터셋, 즉 모든 필드가 동일한 열 위치에 정렬된 다년도 고객 이력을 구축하게 됩니다. 2027년 스프레드시트를 열고 고객 ID를 기준으로 2026년 데이터와 병합하면, 각 고객은 연도별로 하나씩 총 두 개의 행을 가지게 되며 모든 필드는 동일한 열에 위치합니다. "사업 소득"으로 정렬하여 모든 고객의 2026년 대비 2027년 데이터를 몇 초 만에 비교할 수 있습니다. 2026년에 "생명보험 공제"가 ¥120,000이었던 고객이 2027년에 ¥0으로 감소했는지 확인하고 그 이유를 물어보십시오. "의료비"와 "사업 소득"의 비율이 상승 추세인지 추적하세요. 이는 고객이 개인 비용을 잘못 분류하고 있다는 신호일 수 있습니다.
올해 구축하는 데이터셋이 내년의 검토 우위입니다. 2026년의 컬럼 데이터를 옆에 두고 고객의 2027년 신고서를 검토하는 세무사는 PDF만으로는 따라올 수 없는 정보 밀도로 작업하고 있습니다. 컬럼식 이력은 모든 전년 대비 비교를 즉각적으로 가능하게 하며, 이상 징후를 드러내는 비교는 각 연도의 신고서가 별도의 PDF 폴더에 보관되어 있다면 세무사가 수행할 시간이 없었을 것입니다.
동일한 일괄 처리 로직은 유사한 신고 구조를 가진 다른 세무 관할권에도 적용됩니다. 80건의 SA100 종합소득세 신고서를 하나의 요약 스프레드시트로 처리하는 영국 세무사는 동일한 워크플로우를 따릅니다: 신고서 필드에 대한 열을 정의하고, 모든 신고서를 한 번에 업로드하며, 고객당 하나의 행을 받습니다. 양식의 언어와 공제 명칭은 "의료비 공제"에서 "맹인 수당"으로 변경되지만, 일괄 처리 원칙과 신고서당 수동 입력 대비 효율성 향상은 변하지 않습니다.
마찬가지로, 일괄 방법론은 세무 신고에 입력되는 증빙 서류로까지 확장됩니다. 50건의 일본 구매 주문서(発注書)를 하나의 조달 대시보드로 일괄 처리하는 조달 부서는 동일한 '열 한 번 정의, 모두 일괄 업로드' 패턴을 사용하며, 출력 스프레드시트는 50개 행의 단순 목록으로는 답할 수 없는 공급업체별 지출, 세율별 소비세, 결제일별 지불액 등의 질문에 답변합니다. 일괄 원칙은 문서 유형에 구애받지 않습니다: 스키마를 한 번 정의하고, 모든 것을 업로드하고, 문서당 하나의 행을 얻습니다. 변경되는 것은 열 이름과 검토 질문일 뿐, 워크플로우는 아닙니다.
자주 묻는 질문
일괄 처리에서 백색 신고와 청색 신고 고객을 동시에 업로드할 수 있나요?
네, 가능합니다. B양식 자체는 백색 신고와 청색 신고 모두 동일하며, 차이는 첨부 서류에 있습니다. 백색 신고 고객은 간소화된 수지내역서를 첨부하고, 청색 신고 고객은 대차대조표, 손익계산서, 비용 내역이 포함된 상세한 청색 신고 결산서를 첨부합니다. 두 서류 모두 신고서와 함께 동일한 배치에 업로드할 수 있습니다. 추출은 각 문서를 독립적으로 읽습니다. 청색 신고 고객의 경우 추가 열(자산, 부채, 순자산 등)이 채워지고, 백색 신고 행은 해당 열이 비어 있습니다. 열 스키마는 두 경우를 모두 수용합니다. 가능한 모든 열을 정의하면, 해당 데이터가 없는 고객의 행은 빈 셀로 표시됩니다.
고객이 작년에는 freee, 올해는 Yayoi로 회계 소프트웨어를 변경했다면 어떻게 하나요?
이것이 바로 의미 기반 추출을 통한 일괄 처리가 중요한 이유입니다. freee로 생성된 신고서와 Yayoi로 생성된 신고서는 동일한 B양식을 출력하지만, 글꼴, 행 간격, 섹션 순서가 다릅니다. freee 출력에 맞춰진 템플릿 기반 추출 도구는 Yayoi 출력에서 모든 필드를 잘못 정렬합니다. 의미 기반 추출은 '사회보험료 공제'와 같은 필드 레이블을 읽기 때문에 글꼴, 행 위치, 간격은 중요하지 않습니다. 두 연도의 신고서를 동일한 배치에 업로드하면, '사회보험료 공제' 열에는 어떤 소프트웨어로 생성되었든 관계없이 각 연도 신고서의 올바른 값이 포함됩니다. 고객이 소프트웨어를 변경해도 가장 중요한 다년도 비교(이 공제액이 변경되었는지)가 깨지지 않습니다.
한 배치에서 80건의 신고서를 처리하는 데 얼마나 걸리나요?
일반적인 세금 신고서는 4~6페이지 분량입니다. 80건의 고객이라면 약 320~480페이지가 됩니다. 시간이 가장 많이 걸리는 단계는 PDF를 스캔하거나 수집하는 것이지만, 이는 시즌당 한 번만 수행하면 되며, 대부분의 회계사는 이미 회계 소프트웨어를 사용하는 고객으로부터 PDF를 받고 있습니다. 업로드되면 AI가 각 신고서를 독립적으로 처리합니다. 총 처리 시간은 페이지 수와 서버 부하에 따라 다르지만, 80건 배치는 일반적으로 30분 이내에 완료됩니다. 16시간 이상의 수동 재입력(거의 이틀 근무일)과 비교하면, 이 워크플로우 전환은 고객이 실제로 비용을 지불하는 검토 및 자문 업무에 사용할 수 있는 시간을 확보해 줍니다.
추출 기능을 통해 고객의 손익계산서 합계가 B양식으로 이월된 금액과 일치하는지 확인할 수 있나요?
네, 계산 열을 통해 가능합니다. 검증 열을 정의하세요. 예: "수지내역서 vs. 제1표 수입금액 대조 — 일치? 'OK' : 'CHECK'" — 이 열은 손익계산서의 수입 합계를 제1표의 해당 수입 필드와 비교합니다. 추출 기능은 동일한 고객 배치에서 두 문서를 모두 읽고 비교 열을 자동으로 채웁니다. 이 열에 'CHECK'가 표시되면 손익계산서와 신고서가 일치하지 않는다는 의미이며, 이는 정확히 세무조사 요청을 유발하는 유형의 불일치입니다. 신고서 제출 전에 회계사 사무실에서 이를 발견하면, 제출 후 수정의 가장 일반적인 원인을 제거할 수 있습니다.
과거에 종이로 신고했고 스캔본만 있는 고객의 경우에도 일괄 추출이 작동하나요?
네, 가능합니다. 2023년과 2024년에 종이로 신고하다가 2025년에 freee로 전환한 고객의 경우, 해당 2년치 신고서는 파일 폴더에 인쇄된 형태로만 존재합니다. 해당 서류를 스캔하거나 스마트폰으로 균일한 조명 아래에서 촬영한 후, 2025년 PDF와 함께 업로드하면 됩니다. 추출 기능은 스캔된 종이 신고서를 소프트웨어 생성 PDF와 동일하게 처리합니다. 즉, 형식이 아닌 필드 의미를 기준으로 읽습니다. 출력 결과의 세 행(2023, 2024, 2025)은 동일한 열 구조를 가지므로, 수동으로 2년치 종이 신고서를 다시 입력하지 않고도 전년 대비 비교가 가능해집니다. 이는 대출 신청, 비자 갱신, 또는 여러 해의 소득 증빙이 필요한 세무 조사(税務調査)에서 특히 유용합니다.
2월을 데이터 입력이 아닌 검토의 달로 만들기
일본 개인 소득세 신고 기간(2월 16일~3월 15일)은 법정 기간으로 고정되어 있습니다. 이 기간 동안 세무사 사무소의 수익성은 2월을 데이터 입력에 얼마나 할애하느냐, 아니면 데이터 분석에 얼마나 할애하느냐에 따라 크게 결정됩니다. 여기서 설명하는 일괄 처리 워크플로우는 그 비율을 바꿉니다. 스캔 및 열 정의에 소요되는 오후 한나절이 재입력에 필요한 이틀을 대체하며, 추출된 고객 요약(고객당 한 행, 각 필드는 해당 열에, 공제 합계는 Sheet 1과 대조 확인됨)이 검토의 시작점이 되는 작업 문서가 됩니다.
한 번 정의된 열 스키마는 이후 매 시즌마다 사용됩니다. 비교 분석(공제 미활용, 선납세액 초과 납부, 손익계산서 조정)은 데이터가 이미 열로 정리되어 있기 때문에 몇 초 만에 이루어집니다. 그리고 여러 신고 시즌에 걸쳐 구축된 데이터셋은 매년 가치가 증가하는 자산이 됩니다. 즉, 단일 연도 PDF에서는 볼 수 없는 추세를 드러내는 다년간의 고객 이력입니다. 매년 2월마다 변하는 것은 신고서 구조가 아닙니다. 변하는 것은, 세무사가 이미 인쇄되어 있는 숫자를 입력하는 데 얼마나 많은 시간을 보내고, 자신의 수수료를 정당화하는 패턴을 찾는 데 얼마나 많은 시간을 보내느냐입니다.