일본 청구서 완벽 가이드
AP 및 세금 처리를 위한 데이터 추출

일본식 청구서가 다른 점 — 그리고 추출에 중요한 이유

일본식 청구서는 서양 추출 도구가 분석하도록 훈련되지 않은 필드 구조를 가지고 있습니다. 미국 또는 EU 청구서는 헤더에서 라인 항목을 거쳐 합계와 납기일로 이어지며, 일반적으로 4~6개의 추출 열이 지급 계정 워크플로를 처리합니다. 일본식 청구서는 합계 아래에 두 번째 전체 섹션인 지급 지시 블록을 추가합니다. 이는 구매자에게 어느 은행으로 자금을 보낼지, 어떤 결제일 관행이 자금 만기를 결정하는지, 그리고 자금 중 일부를 세무서를 위해 원천징수해야 하는지 여부를 알려줍니다. 문서를 위에서 아래로 읽으며 "청구서 번호"와 "합계"만 찾는 일반 추출 엔진은 이 전체 섹션을 건너뛰거나, 더 나쁜 경우 네 개의 개별 은행 필드를 하나의 뒤섞인 텍스트 문자열로 연결합니다.

2023년 10월부터 이 문제는 구조적 차원 외에 규정 준수 차원도 추가되었습니다. 인보이스 제도(インボイス制度, 공식 명칭 適格請求書等保存方式)는 소비세법 제57조의2에 따라 매입 세액 공제 청구를 뒷받침하는 모든 청구서에 6개의 필수 필드를 요구합니다. 이 중 세 가지(등록 번호, 세율별 세액 합계, 세율 구분 내역)는 제도 시행 전에는 필수 필드가 아니었습니다. 2025년 3월 기준, 국세청은 약 461만 명의 적격 청구서 발행 사업자가 등록되었다고 보고했습니다. 이들 모두는 모든 청구서에 T+13자리 등록 번호를 포함해야 합니다. 해당 번호가 누락되면 구매자의 매입 세액 공제가 감소하며, 이는 80% 공제 가능에서 0%로 단계적으로 전환되는 경과 일정에 따릅니다.

따라서 추출 작업은 단순히 일본어 텍스트를 읽는 것이 아닙니다. AP(지급 계정) 및 세금에 중요한 열인 문서의 필드 스키마가 추출 도구가 예상하도록 구축된 스키마와 다르다는 점을 인식하는 것입니다. 해결책은 맞춤 열 추출입니다. AP 스프레드시트와 일본 비즈니스 로직에 맞는 열 이름으로 출력 스키마를 직접 정의한 다음, AI가 각 필드의 의미를 이해하여 위치를 찾도록 하는 것입니다. 특정 공급업체의 청구서 템플릿에서 어디에 있는지가 아니라요. 동일한 열 스키마는 대형 무역 회사의 ERP 생성 PDF, 지역 서비스 제공업체의 Word 템플릿을 인쇄하여 스캔한 문서, 또는 손으로 작성한 양식의 모바일 사진 등 모든 청구서에 적용됩니다. 각 열 정의가 무엇이어야 하는지, 그리고 일본 관행을 포착하는 추론 로직을 작성하는 방법을 알아보려면 단계별 일본식 청구서 추출 튜토리얼을 참조하십시오. 이 튜토리얼에서는 25개의 열을 한 번 정의하고 모든 공급업체에 걸쳐 재사용하는 방법을 설명합니다.

이 가이드의 나머지 부분에서는 각 열이 추출해야 하는 내용과 일본식 청구서 고유의 필드(후리코미사키 은행 세부 정보, 시메비 결제 관행, 겐센 초슈 원천징수, 이중 세율 소비세)가 열 정의부터 지급 배치 출력, 소비세 신고 제출에 이르기까지 전체 추출 워크플로를 어떻게 형성하는지 다룹니다.

세이큐쇼(일본식 청구서)의 필드 구조

일본 청구서는 네 가지 논리 영역으로 구성됩니다. 처음 두 영역인 헤더와 라인 항목은 전 세계 청구서에 공통적으로 존재합니다. 마지막 두 영역인 세금 및 규정 준수, 지급 및 은행 정보는 서양식 추출 엔진이 예상하는 필드 스키마와 차이가 나는 부분입니다. 다음은 다양한 공급업체로부터 세이큐쇼를 처리할 때 AP 팀이 접하게 되는 모든 필드를 영역별로 정리한 것입니다.

이 구조는 추측이 아닙니다. 내각부의 적격 청구서 제도 공식 개요에는 6가지 필수 항목이 나열되어 있습니다. 그러나 추출 작업은 필수 항목을 넘어섭니다. 가장 많은 수동 AP 시간을 소모하는 필드(계좌 정보, 지급 조건 분석, 원천징수)는 법적 요구사항이 아닌 관행에 의해 포함됩니다. 이것이 일본 청구서 처리를 서양식과 구조적으로 다르게 만드는 요소이며, 일반적인 추출이 가장 먼저 실패하는 지점입니다. 추출 작업을 수동으로 수행할 때의 비용을 이해하려면 일본 중소기업의 수동 세이큐쇼 처리 비용 분석에서 월말 마감 주기별 인건비를 엔화로 분석합니다.

핵심 추출 인사이트: 일본식 청구서는 일본어 텍스트가 포함된 영어 청구서가 아닙니다. 필드 스키마가 다른 문서이며, 추출 열 정의는 해당 스키마를 반영해야 합니다. 그렇지 않으면 AP 팀이 여전히 다시 입력해야 하는 데이터 테이블이 출력됩니다.

후리코미사키(계좌 정보): 하나의 텍스트 블록이 아닌 네 개의 개별 은행 필드가 필요한 이유

은행 송금 정보 블록은 일본 AP에서 가장 반복적인 데이터 입력 작업입니다. 공급업체의 청구서에는 은행명, 지점명, 계좌 유형, 계좌 번호의 네 가지 레이블 필드가 있으며, AP 담당자는 인터넷 뱅킹 화면을 열어 매 청구서마다 하나씩 입력합니다. 동일한 네 값이 이미 회계 소프트웨어의 공급업체 마스터에 존재합니다. 월말에 30장의 청구서가 도착하면 AP 팀은 해당 네 필드를 30번 다시 입력합니다. 즉, 한 화면에서 다른 화면으로 기존 마스터 데이터만 복제하는 120개의 개별 항목으로, 새로운 정보는 전혀 추가되지 않습니다.

대부분의 일반 추출 도구는 "지급 방법"이 "송금" 또는 "ACH"라는 단일 필드이고, 청구서에 라우팅 은행 정보가 구조화된 필드 세트로 존재한다는 개념이 없는 미국 및 EU 청구서 데이터 세트로 학습되었습니다. 이러한 도구에 세이큐쇼를 넣으면 은행 정보 블록이 건너뛰어지거나 하나의 비정형 텍스트 필드로 연결됩니다. AP 팀은 여전히 PDF를 열어 각 필드를 복사하여 붙여넣어야 합니다.

추출 접근 방식은 후리코미사키 블록을 각 필드를 독립적으로 캡처하는 네 개의 전용 열로 분리하고, 유초 은행(ゆうちょ銀行) 변환을 처리하기 위해 추론 열을 사용합니다. 유초 은행 계좌 시스템은 일반 은행 후리코미 시스템에 필요한 7자리 송금 계좌 번호와 다른 기호-번호(記号-番号) 쌍을 사용합니다. 추론 열 — AI가 페이지에 인쇄된 값을 찾는 대신 문서 컨텍스트를 기반으로 값을 계산하는 열 — 은 추출 중에 변환을 처리합니다: 송금 계좌 번호(은행명에 ゆうちょ가 포함된 경우, 유초 은행 변환 규칙에 따라 기호-번호 쌍을 7자리 형식으로 변환, 그렇지 않으면 계좌 번호 출력). 열 정의는 한 번 실행되며 모든 배치에 적용됩니다.

네 개의 구조화된 은행 열은 단순한 조직적 편의가 아닙니다. 이는 지급 배치 파일의 입력 데이터이며, 여기서 젠긴 포맷(全銀フォーマット)이 워크플로에 진입합니다. 배치 처리 가이드는 전체 체인을 다룹니다: 한 배치에서 처리된 30장의 청구서 → 별도 열의 후리코미 은행 정보 → 은행이 수락 가능한 지급 배치 파일로 형식화된 출력. 추출은 단순히 입력을 줄이는 것이 아니라, 추출로 입력된 동일한 은행 필드가 은행 업로드 화면에서 수집되는 동일한 은행 필드인 데이터 파이프라인을 생성합니다.

시메비(마감일): 회계 기간을 결정하는 결제일

일본의 지급 조건은 AP팀이 한눈에 읽을 수 있지만 일반 추출 시스템은 불투명한 텍스트로 읽는 간결한 구문입니다. "20일 시메비 익월말 지급"은 청구 기간이 매월 20일에 마감되고 다음 달 말까지 지급이 이루어져야 함을 의미합니다. 이 문자열은 결제일(20)과 지급 지연 기간(1개월)이라는 두 가지 계산 가능한 값을 인코딩합니다. "월말 시메비 익익월말 지급"은 건설 및 제조업에서 흔히 볼 수 있으며, 월말 마감, 다음 다음 달 말까지 지급(지연: 2개월)을 의미합니다.

시메비(마감일)는 단순한 형식이 아니라 운영상 중요한 요소입니다. 20일 시메비 조건에서 3월 18일자 청구서는 3월 청구 기간에 속합니다. 즉, 4월 말까지 지급해야 하며, 장부가 3월 31일에 마감되면 비용은 당해 회계연도에 속합니다. 동일한 조건에서 3월 22일자 청구서는 4월 청구 기간에 속합니다. 즉, 5월 말까지 지급해야 하며, 비용은 다음 회계연도에 속합니다. 회계연도 분류를 결정하는 것은 청구서 날짜나 달력 월 경계가 아니라 시메비(마감일)입니다. 시메비 지급 기한 분석에서는 30개 공급업체가 각각 다른 시메비 날짜를 사용할 때 시메비 관행이 현금 흐름 예측에 어떻게 연쇄적으로 영향을 미치는지에 대한 전체적인 운영 영향을 다룹니다.

계산 열은 AI가 정의된 수식을 사용하여 추출 중에 값을 계산하는 열로, 지급 조건을 구조화된 필드로 분할합니다: 시메비(마감일) (지급 조건에서 추출: "20일 시메비" → 20, "월말 시메비" → 31, "10일 시메비" → 10) 및 지급 지연 개월 수 (지급 조건에서 추출: "익월말 지급" → 1, "익익월말 지급" → 2). 이 두 열은 스프레드시트 수식에서 사용되어 실제 지급 만기일을 계산합니다. 출력 스프레드시트의 만기일 열은 입력되거나 자유 텍스트 필드에서 추출된 것이 아니라 청구서 날짜에 구문 분석된 조건을 더하여 파생됩니다. 이 날짜 열은 현금 흐름 예측과 지급 배치 일정에 사용되며, 둘 다 이를 인코딩하는 텍스트 문자열이 아닌 실제 달력 날짜가 필요합니다.

겐센 초슈 쿠분(원천징수 구분): 지급자가 송금 전에 원천징수해야 하는 경우

일본의 원천징수 제도는 수취인이 적격 전문 서비스 제공자일 때 지급자에게 원천징수 의무를 부과합니다. 세무사(税理士), 공인회계사(公認会計士), 변호사(弁護士), 사법서사(司法書士), 디자이너(デザイナー), 작가(著作家) 및 소득세법(所得税法) 제204조에 정의된 기타 여러 직종은 지급액의 10.21%를 원천징수 대상으로 합니다. 지급자는 원천징수액을 공제하여 세무서에 납부하고, 공급자에게 나머지 89.79%를 지급합니다.

적격 전문가의 세이큐쇼(일본식 청구서)에는 일반적으로 원천징수 표시가 있습니다. 공제액이 기재된 "源泉徴収額" 항목이 있거나 "源泉徴収あり"와 같은 분류 표시가 있습니다. 원천징수가 포함된 청구서는 AP 지급 계산을 변경합니다. 순 지급액은 청구서 총액에서 원천징수액을 뺀 금액이며, 세금 예치금에 대한 별도의 부채 항목을 계상해야 합니다. 추출 과정에서 원천징수가 포착되지 않으면 AP 팀은 적격 청구서 각각을 개별적으로 재검토하고, 공제액을 수동으로 계산한 후 지급액을 조정해야 합니다. 청구서 60건에 걸친 이 청구서별 산술 단계는 상당한 AP 시간을 소모합니다.

원천징수 분류(청구서에 겐센 초슈(원천징수) 표시가 있는지 확인; 공급자가 적격 전문가이고 원천징수가 표시된 경우 "해당", 그렇지 않으면 "해당 없음" 출력)으로 정의된 열은 원천징수가 필요한 청구서를 식별합니다. 계산 열(Computed Columns) — 순 지급액(원천징수 해당 시: 총액 × 0.8979; 그 외: 총액) — 은 실제 후리코미사키(계좌 정보) 송금액을 직접 계산합니다. 이제 지급 배치 파일에는 AP 팀이 적격 청구서 각각에 대해 별도의 계산 단계를 실행하지 않아도 청구서 총액이 아닌 올바른 송금액이 포함됩니다.

인보이스 번호: T+13 등록 번호와 그 존재 이유

적격 청구서 등록 번호(인보이스 등록 번호)는 "T"가 접두사로 붙은 13자리 숫자입니다(예: T1234567890123). 모든 적격 청구서 발행 사업자(QII)는 등록 시 국세청으로부터 이 번호를 부여받으며, 구매자가 소비세 공제를 위해 사용할 모든 청구서에 이 번호를 인쇄해야 합니다. 국세청은 적격 청구서 발행 사업자 공개 등록부를 운영하여 AP팀이 등록 번호를 확인할 수 있도록 합니다.

등록 번호는 2023년 10월 이전에는 존재하지 않았던 새로운 청구서별 확인 단계를 만들었습니다. 청구서를 수신한 AP 담당자는 T-번호를 찾아야 합니다. 이 번호는 헤더, 바닥글, 여백, 회사 직인 옆의 작은 글씨, 또는 은행 송금 정보 근처 텍스트 블록에 포함되어 있을 수 있으며, 공급업체의 것임을 확인해야 합니다. 번호가 없거나 국세청 등록부와 일치하지 않는 경우, 해당 거래에 대한 구매자의 매입세액 공제는 80% 공제 가능(2026년 9월까지)에서 50%(2029년 9월까지), 이후 0%로 단계적으로 축소되는 경과 일정에 따라 감소됩니다. 일본 적격 청구서 추출 완벽 가이드에서는 6가지 필수 항목, 경과 공제 일정, 단일 열 조회로 추출된 T-번호를 국세청 등록부와 확인하는 방법을 포함하여 규정 준수 청구서 환경을 심층적으로 다룹니다.

추출 워크플로우에서 등록 번호 열은 정의하기 간단합니다. AI가 문서를 읽고 페이지 내 어디에서든 T+13 패턴을 식별하여 열을 채웁니다. 문제는 추출 자체가 아니라 배치의 가변성입니다. 모든 공급업체가 T-번호를 다른 위치에 배치합니다. 등록 번호가 고정 영역에 있을 것으로 예상하는 템플릿 기반 도구는 공급업체가 바닥글에 번호를 배치한 청구서에서는 이를 놓칠 것입니다. 의미론적 추출은 필드가 어디에 있는지가 아니라 무엇인지 이해하여 위치에 관계없이 필드를 찾아냅니다. 동일한 원칙이 청구서의 모든 필드에 적용되며, 이것이 단일 열 스키마가 서로 다른 30가지 레이아웃을 가진 30개 공급업체에서 작동하는 이유입니다.

소비세: 세금 신고를 위한 이중 세율 추출

일본의 소비세 제도는 10% 표준 세율(대부분의 재화 및 용역 대상)과 8% 경감 세율(식품, 비알코올 음료, 주 2회 이상 발행되는 구독 신문 대상)의 두 가지 세율을 사용합니다. 적격 청구서에는 각 세율 구분별로 과세 표준과 세액을 별도로 명시해야 하며, 분수는 원 단위로 절사합니다. 두 세율을 혼합한 단일 총액은 적격 청구서 제도(인보이스 제도)에 부합하지 않습니다.

추출의 과제는 분류입니다. 혼합 세율의 품목(10% 대상 사무용품과 8% 대상 포장 음료)이 포함된 청구서는 각 품목을 올바른 세율 구분에 할당하여 세율별 소계가 공급자가 명시한 총액과 일치하는지 확인할 수 있도록 해야 합니다. 공급자가 실수로 10% 품목을 8% 열에 포함시킨 경우, 구매자의 소비세 신고에서 매입 세액 공제를 과다 청구하게 되며, 국세청의 데이터 매칭 엔진은 의도적인 허위 신고와 공급자의 오류에 의존한 경우를 구분하지 않습니다.

추론 열은 추출 중 세율 분류를 처리합니다: 세율 (품목 설명 기준: 알코올 및 외식을 제외한 식품/음료 품목 → 8% 경감 세율; 일반 재화/용역 → 10% 표준 세율; 명시적으로 수출 관련 → 면세). AI가 각 품목 설명을 읽고 일본의 이중 세율 규칙을 적용하여 세율 열을 채웁니다. 그런 다음 두 개의 계산 열이 세율별 소계를 계산합니다 — 10% 소계 (세율 = 10%인 품목 금액의 합계) 및 8% 소계 (세율 = 8%인 품목 금액의 합계) — 이를 청구서에 명시된 각 세율 구분별 소계와 직접 비교할 수 있습니다.

소비세 데이터는 추출된 스프레드시트에서 소비세 신고(消費税申告)로 입력 데이터(10% 과세 총액, 10% 세액, 8% 과세 총액, 8% 세액)로 흘러갑니다. 추출 결과가 각 품목을 원천에서 분류하면, 세무 담당자는 분류를 처음부터 수행하는 대신 검증만 하면 됩니다. 일반적인 소비세 데이터 입력 오류 가이드에서는 세율 분류를 추출 단계가 아닌 수동으로 수행할 때 세금 불일치를 유발하는 특정 실수들을 다룹니다.

추출 워크플로우: PDF에서 지급 준비 완료 스프레드시트까지

수동으로 청구서를 스프레드시트에 옮겨 적는 작업을 대체하는 이 워크플로우는 한 번만 정의하면 모든 공급업체, 모든 청구서 형식, 그리고 이후 모든 월말 일괄 처리에 적용됩니다. 공급업체별로 설정하는 과정이 아닙니다. 열 스키마는 발신자가 누구든 관계없이 AP 팀이 세이큐쇼(일본식 청구서)에서 필요로 하는 것을 포착합니다. AI가 각 문서를 읽고 스키마를 채우며, 출력은 매번 동일한 열에 저장됩니다.

월말 AP를 위한 일괄 처리

30~50개의 국내 공급업체로부터 구매하는 일본 기업의 월말 AP는 세 가지 채널을 통해 공급업체 청구서를 수신합니다: 청구 소프트웨어를 사용하는 회사로부터의 이메일 PDF, 대규모 무역 회사 및 제조업체의 공급업체 포털에서 다운로드한 PDF, 그리고 우편으로 수신되어 PDF로 스캔되거나 사진 촬영된 종이 청구서입니다. 세 채널 모두 매월 같은 주에 동일한 담당자에게 집중되며, 모두 동일한 AP 처리 주기에 투입됩니다.

일괄 처리는 이러한 모든 청구서를 출처 채널, 공급업체 또는 레이아웃에 관계없이 단일 작업으로 처리함을 의미합니다. 열 스키마는 배치 내 모든 문서에 적용됩니다. 출력은 각 행이 하나의 청구서이고 각 열이 하나의 추출 필드인 하나의 스프레드시트입니다. 세 채널과 20~30개의 서로 다른 청구 시스템을 통해 도착한 30~50개의 청구서는 이제 통일된 구조의 단일 파일로 존재합니다.

일괄 처리가 변경하는 세 가지 운영상의 결정:

AP 팀은 재입력에서 검증으로 전환합니다. 추출이 스프레드시트를 채웁니다. AP 담당자의 업무는 이제 플래그가 지정된 항목(도구가 낮은 신뢰도로 표시한 T-번호, 이상하게 읽히는 은행 지점명, 잘못된 것으로 보이는 계산된 지급 지연일)에 대해 열을 스캔하는 것이지, 데이터를 처음부터 생성하는 것이 아닙니다. 검증은 배치당 몇 분이 소요됩니다. 생성은 각 PDF를 열고, 올바른 필드를 찾고, 다른 화면에 입력하는 데 몇 시간이 걸립니다.

스프레드시트는 세 가지 다운스트림 시스템을 위한 단일 진실 공급원이 됩니다. 회계 소프트웨어는 구매 분개 데이터를 가져옵니다. 은행 시스템은 지급 배치 데이터를 가져옵니다. 세금 신고는 소비세 입력 데이터를 가져옵니다. 세 시스템이 세 번의 개별 수동 입력 작업이 아닌 동일한 추출 데이터에 의존할 때, 한 시스템의 불일치는 추출 출력으로 추적되며, 연결되지 않은 세 개의 데이터 입력 작업 중 하나의 오타로 인한 것이 아닙니다.

동일한 열 스키마가 다음 달에도 그대로 적용됩니다. 공급업체가 청구서 레이아웃을 변경할 수 있고, 새로운 공급업체가 추가될 수도 있습니다. 각 필드의 의미(위치가 아님)로 정의되는 스키마는 업데이트할 필요가 없습니다. 일괄 처리 가이드에서는 후리코미사키(계좌 정보) 세부 사항, 원천징수 계산, 결제일별로 그룹화된 지급 일정이 포함된 30건의 청구서 예제를 설명합니다.

전체 포맷: 스프레드시트 열에서 은행 수용 가능 지급 일괄 파일로

젠긴 포맷(全銀フォーマット)은 일본 은행 자금 결제 네트워크(全国銀行資金決済ネットワーク)에서 표준화한 고정 너비 파일 형식으로, 기업이 인터넷 뱅킹 화면에서 하나씩 입력하는 대신 단일 업로드로 여러 건의 후리코미 은행 송금을 제출할 수 있게 해줍니다. 모든 주요 일본 은행은 기업 뱅킹(FB) 서비스를 통해 일괄 송금에 이 형식을 허용합니다.

이 형식은 줄당 120바이트, Shift-JIS 인코딩이며, 4가지 레코드 유형이 있습니다:

추출에서 젠긴 포맷으로의 연결은 파일 변환이 아닌 데이터 파이프라인입니다. 추출 출력에는 은행명, 지점명, 계좌 유형, 계좌 번호, 예금주명, 순 지급액이 각각 별도 열에 포함됩니다. 이러한 열은 젠긴 파일의 각 데이터 레코드를 채우는 정확한 필드입니다. 청구서의 텍스트 이름과 다른 젠긴 포맷에서 사용되는 숫자 식별자인 은행 코드(4자리)와 지점 코드(3자리)는 AP 팀이 한 번 유지 관리하는 조회 테이블(공급업체 은행명 및 지점명을 해당 젠긴 은행 코드 및 지점 코드에 매핑)을 통해 확인할 수 있습니다.

계산 열은 추출 중에 이 조회를 수행할 수 있습니다: 젠긴 은행 코드 (은행명 매핑 테이블에서 조회). 열 출력에는 청구서에 표시된 은행명이 아닌, 젠긴 데이터 레코드에 사용할 숫자 은행 코드가 포함됩니다. 스프레드시트에서 추출 출력 열을 고정 너비 120바이트 형식으로 변환하는 작업(스프레드시트-투-젠긴 변환)은 스프레드시트 수식이나 간단한 스크립트로 수행할 수 있습니다. 추출은 설계된 대로 수행됩니다: 열에 구조화된 데이터를 생성합니다. 지급 배치 생성은 해당 열을 입력으로 사용합니다.

일본 은행 자금 결제 네트워크는 공식 젠긴 시스템 사양을 발행합니다 (PDF). 개별 은행은 자체 FB 업로드 형식 사양을 발행하며, 여기에는 특정 문자 인코딩(JIS 또는 Shift-JIS), 필드 패딩 규칙(숫자 필드는 오른쪽 정렬 제로 필, 이름 필드는 왼쪽 정렬 스페이스 필), 및 공백으로 남길 수 있는 필드가 포함됩니다. 추출 출력은 형식에 구애받지 않습니다 — 열을 생성합니다. AP 팀이나 스크립트는 해당 열을 회사가 사용하는 은행의 젠긴 사양에 맞게 포맷합니다.

인보이스 제도(적격 청구서 제도) 준수를 위한 구조화된 추출

적격 청구서 제도는 모든 AP 팀이 모든 공급업체 청구서에 대해 수행해야 하는 세 가지 새로운 준수 확인 단계를 만들었습니다:

1. 등록 번호 확인 — 청구서에 있는 T+13 번호가 공급업체에 속하고, 국세청 공개 등록부와 일치하며, 만료되거나 취소되지 않았는지 확인합니다.
2. 세율 구분 — 청구서가 8% 경감세율 항목과 10% 표준세율 항목을 올바르게 분리하고, 세율별 소계 및 세액이 산술적으로 정확한지(과세 기준 × 세율, 소수점 이하 버림) 확인합니다.
3. 경과적 세액 공제 계산 — 미등록 공급업체의 청구서에 대해 경과 일정에 따라 경감된 매입세액 공제를 계산합니다(2026년 9월까지 80% 공제, 2029년 9월까지 50% 공제, 이후 0%).

시스템 도입 전에는 AP 담당자가 두 가지만 확인했습니다: 청구서 총액이 맞는지, 공급업체가 마스터 파일에 있는지. 이제 담당자는 청구서당 세 가지 추가 준수 차원을 확인해야 합니다. 월말에 30~50장의 청구서를 처리한다면, 2023년 10월 이전에는 존재하지 않았던 90~150개의 추가 확인 작업이 발생합니다. 2023년 청구서 개혁이 재무 처리를 더 어렵게 만든 방법 분석에서는 개혁 전과 후의 확인 체크리스트 변경 사항을 자세히 설명합니다.

구조화된 추출은 이러한 확인의 기계적 부분을 흡수합니다. 등록 번호 열은 단일 열 조회로 국세청 등록부와 대조 검색할 수 있게 합니다. 세율별 소계를 위한 계산 열은 공급업체가 명시한 수치와 직접 비교할 수 있게 합니다. 공급업체의 청구서 시스템 등록 상태 열은 경과적 세액 공제 계산이 적용되는지 여부를 표시합니다. AP 팀은 여전히 확인을 수행합니다 — 하지만 확인은 스프레드시트에서 추출된 데이터를 원본 데이터와 비교하는 것을 의미하며, 각 청구서의 세금 섹션을 읽고 계산기로 세율별 산술을 수행하는 것이 아닙니다. 일본 적격 청구서 추출 완벽 가이드에서는 등록 번호 교차 확인, 세율 구간 산술, 경과적 세액 공제 계산 등 확인 워크플로를 자세히 다룹니다.

이 문서들의 관계: 일본 청구서 클러스터

이 가이드는 일본 청구서(세이큐쇼) 추출의 모든 측면(방법, 일괄 처리, 문제 분석, 비용, 일반적인 실수, 그리고 이 완전 참조)을 다루는 6개 문서로 구성된 클러스터의 허브 문서입니다. 각 문서는 독립적으로 활용 가능하지만, 클러스터 내에서 더 큰 맥락을 얻습니다. 각 문서의 관계는 다음과 같습니다.

일본 청구서 클러스터 외에도 세이큐쇼와 추출 로직을 공유하는 인접 문서 유형을 다루는 두 개의 관련 문서가 있습니다.

자주 묻는 질문

AI 추출이 스마트폰 사진으로 촬영한 일본 청구서 데이터를 읽을 수 있나요?

네, 기본 비전 언어 모델은 텍스트 우선 OCR이 아닌 시각적 입력으로 이미지를 처리합니다. 사무실 조명 아래에서 약간의 원근 왜곡이 있는 종이 청구서의 모바일 사진도 유효한 입력입니다. AI는 완벽한 평판 스캔 문서를 요구하지 않고 필드의 모양과 의미를 이해하여 필드를 읽습니다. 공급업체의 ERP 생성 PDF에서 작동하는 동일한 열 스키마가 소규모 서비스 제공업체의 수기 청구서 사진에서도 작동합니다. 추출이 필드 위치가 아닌 필드 ID를 읽기 때문입니다.

청구서의 지급 조건 문자열이 비정상적인 형식인 경우 어떻게 처리되나요?

구문 분석 논리를 정의하는 계산 열(“20日締” → 결제일 20일, “月末締” → 결제일 31일)이 표준 패턴을 처리합니다. 비표준 조건(“15日締翌々月20日払い” 또는 완전히 다른 방식으로 표현된 조건)의 경우, 추출 기능은 지급 조건 열에 원본 텍스트를 출력하고 계산 열은 수동 검토를 위해 플래그를 지정합니다. AP 팀은 30개 중 1~2개인 플래그가 지정된 행을 검토하며, 모든 청구서의 지급 조건을 수동으로 분석하지 않습니다. 시간이 지남에 따라 계산 열 로직이 새로운 패턴을 처리하도록 확장되면 플래그가 지정된 행 수가 감소합니다.

추출 기능이 유초 은행(ゆうちょ銀行) 계좌 번호를 올바르게 처리하나요?

네, 유초 은행을 은행명으로 감지하고 추출 중에 유초 은행 기호-번호에서 7자리 이체 계좌 번호 변환 규칙을 적용하는 추론 열을 통해 처리합니다. 출력에는 원본 계좌 참조(청구서와 대조 확인용)와 변환된 이체 계좌 번호(지급 배치 생성용)가 모두 포함됩니다. 유초 은행은 웹사이트에 변환 규칙을 게시하고 있습니다.

10%와 8% 소비세 항목이 혼합된 청구서는 추출 기능이 어떻게 처리하나요?

추론 열이 각 라인 항목 설명을 읽고 일본의 소비세 범주(외식 제외 식품 및 비알코올 음료 → 8%, 기타 대부분의 상품 및 서비스 → 10%)에 따라 8% 경감 또는 10% 표준으로 분류합니다. 그런 다음 계산 열이 각 세율 범주를 소계로 합산합니다. AP 팀은 공급업체가 명시한 소계와 분류를 대조 확인합니다. 이는 분류 단계가 아닌 비교 단계입니다. 공급업체가 경감 세율 항목을 표시하지 않은 청구서의 경우, 추론된 분류는 각 청구서 PDF를 다시 열지 않고 공급업체의 합계 총액이 올바른지 확인하는 유일한 방법입니다.

이 가이드와 적격 청구서 추출 가이드의 차이점은 무엇인가요?

적격 청구서 추출 가이드는 인보이스 제도(적격 청구서 제도)에 따른 적격 청구서(適格請求書)의 6가지 필수 항목, 경과적 매입세액 공제 일정, 국세청 등록부 확인 절차, 수기 및 세로 형식 청구서의 특정 문제점에 중점을 둡니다. 이 가이드는 더 광범위한 세이큐쇼(일본식 청구서) 추출 환경, 즉 AP 팀이 접하는 모든 필드, 추출부터 지급 및 세무까지의 전체 파이프라인, 그리고 적격 청구서 가이드에서 다루지 않는 젠긴 포맷 통합을 다룹니다. 규정 준수 관련 심층 내용은 적격 청구서 가이드를 참조하십시오. 종단 간 프로세스는 이 가이드를 참조하십시오.

일본 청구서에서 헤더 합계뿐만 아니라 라인 항목도 추출할 수 있나요?

네, 가능합니다. 이 가이드에서 설명하는 열 스키마에는 헤더 및 푸터 필드와 함께 라인 항목 수준의 열(品名, 数量, 単位, 単価, 金額)이 포함됩니다. 각 라인 항목은 출력 스프레드시트에서 하나의 행이 되며, 헤더 필드(청구서 번호, 공급업체, 발행일)가 각 행에 반복되어 모든 라인 항목을 원본 청구서로 추적할 수 있습니다. 이 구조는 청구서 총액뿐만 아니라 개별 라인 항목을 비교해야 하는 삼자 매칭(구매 발주서 → 입고 전표 → 청구서)을 지원합니다.