일본 청구서(請求書) 데이터를 Excel로 추출하여
지급 및 세무 신고에 활용하는 방법

일본 청구서에 포함된 항목 — 항목별 설명

일본 청구서는 법적 체계에 따라 운영되므로, 일반적인 서양 청구서보다 필드 구조가 더 표준화되어 있고 상세합니다. 2023년 10월부터 적격 청구서 제도에 따라 매입세액 공제를 위해 사용되는 모든 청구서에는 'T'로 시작하는 13자리 적격 청구서 등록 번호가 포함되어야 하며, 세율 구분별로 소비세액을 별도로 명시해야 합니다. 법적 요구 사항 외에도 수십 년간의 국내 비즈니스 관행으로 인해 지급 조건 구문과 은행 송금 경로가 추가되어, 국제 추출 도구가 이를 분석하도록 학습되지 않았습니다.

다음은 AP 부서가 세이큐쇼를 처리할 때 실제로 다루는 전체 필드 구조입니다:

필드 구조는 추측이 아닙니다 — 내각부의 적격 청구서 제도 공식 개요에는 모든 청구서(インボイス)가 반드시 포함해야 하는 6가지 필수 항목이 명시되어 있습니다. 그러나 추출 작업은 6가지 필수 항목을 넘어섭니다. 수동 AP 처리 시간을 가장 많이 소모하는 필드는 법적으로 청구서에 요구되지 않습니다. 이들은 관례상 포함되며, 일본 청구서 처리 워크플로우를 미국이나 유럽식과 다르게 만드는 필드입니다.

일반 추출 도구가 일본 청구서에서 실패하는 이유

대부분의 AI 청구서 추출 도구는 영어권 청구서 데이터 세트로 학습되었으며, 필드는 "청구서 번호", "마감일", "합계 금액", "공급자"입니다. 이러한 도구에 일본 청구서를 넣으면 세 가지 문제가 발생합니다.

첫째, 공급자의 계좌 이체 정보(振込先)가 무시되거나 잘못 읽힙니다. 일본 청구서에는 은행명, 지점명, 계좌 종류(普通), 계좌 번호가 별도의 라벨 필드로 나열되지만, 일반 추출 엔진은 페이지 하단의 네 개의 텍스트 문자열을 보고 "계좌 이체 정보"에 대한 열 정의가 없으므로 이를 건너뛰거나 하나의 깨진 필드로 연결합니다. AP 팀은 여전히 각 PDF를 열어 지급 시스템에 은행 정보를 직접 입력해야 합니다.

둘째, 지급 조건(支払条件)은 두 개의 계산 가능한 값을 포함하는데도 불투명한 텍스트 문자열로 읽힙니다. "20일締翌月末払い"는 장식용 텍스트가 아닙니다. 이는 AP 팀에게 청구 기간이 20일에 마감됨을 알려줍니다 — 해당 날짜 이전의 거래는 이번 달 채무이고, 이후의 거래는 다음 달에 속합니다 — 그리고 지급은 다음 달 말까지 완료되어야 합니다. 일반 추출기는 이 문자열을 그대로 출력합니다. 일본 지급 관행을 이해하는 추출 도구는 이를 마감일: 20일 및 지급 지연: 1개월로 분리합니다 — 지급 일정 공식이 사용할 수 있는 두 개의 구조화된 값입니다.

셋째, 소비세액 구분과 원천징수 구분은 서양식 추출 스키마에 해당 항목이 없습니다. 미국 청구서의 세금 필드는 단일 판매세 항목입니다. 일본 청구서에는 잠재적으로 세 가지 세금 관련 필드가 있습니다: 10% 소비세액 소계, 8% 경감세율 소비세액 소계, 그리고 공급자가 적격 사업자인 경우 원천징수 금액 또는 구분 표시입니다. 모든 세금 필드를 하나의 숫자로 평탄화하는 일반 추출 도구는 AP 팀이 검증 중에 평탄화를 되돌려야 하게 만듭니다.

청구서 데이터를 Excel로 추출하는 방법 — 단계별 안내

수동 청구서-AP 스프레드시트 입력 작업을 대체하는 워크플로는 구매 주문서에 사용되는 방식과 유사하지만, 청구서 고유 필드라는 다른 열 스키마와 PO 매칭 프로세스가 아닌 은행 지급 프로세스로 이어지는 다른 다운스트림 파이프라인을 사용합니다. 이 3단계 워크플로는 한 번만 정의하면 모든 공급업체, 모든 청구서 형식, 그리고 이후 모든 월말 일괄 처리에 적용됩니다.

일반적인 청구서 추출이 실패하는 필드 — 그리고 이를 처리하는 방법

일본 청구서의 네 가지 데이터 항목은 다른 항목보다 자동 추출에 더 큰 저항을 보입니다. OCR이 문자를 읽지 못해서가 아니라, 각 필드에 비즈니스 로직이 내장되어 있어 텍스트 문자열로 평탄화하는 대신 구조화된 데이터로 보존해야 하기 때문입니다.

계좌 이체 정보(振込先) — 지급 배치 파일이 되는 네 개의 필드

계좌 이체 정보 블록은 일본 AP 업무에서 가장 반복적인 데이터 입력 작업입니다. AP 담당자는 청구서를 받아 인터넷 뱅킹 화면을 열고 은행명, 지점명, 계좌 종류, 계좌 번호라는 네 가지 값을 입력합니다. 이는 회계 소프트웨어의 공급자 마스터에 이미 기록된 동일한 네 가지 값입니다. 월말에 청구서 60장이 도착하면 청구서당 네 개 필드를 60번 다시 입력해야 하며, 이는 총 240건의 개별 데이터 입력으로, 새로운 정보를 추가하지 않고 한 시스템에서 다른 시스템으로 정보를 복제할 뿐입니다.

추출 방식은 네 개의 필드를 각각 별도의 열로 캡처합니다: 은행명(振込先銀行名), 지점명(支店名), 계좌 종류, 계좌 번호(口座番号). 계좌 참조가 상업 은행 시스템에서 요구하는 7자리 이체 계좌 번호와 다른 記号-番号 형식을 사용하는 ゆうちょ銀行 이체의 경우, 추론 열이 추출 중에 일본 우체국 형식을 변환할 수 있습니다: 이체 계좌 번호과 같은 열을 정의합니다. AI는 추출 중에 변환을 적용하여 AP 팀이 이체 가능한 형식의 계좌 번호를 받을 수 있도록 합니다.

은행 정보가 구조화된 열에 있으면 다음 단계인 은행용 지급 배치 파일 생성은 재입력 작업이 아닌 스프레드시트 작업이 됩니다. 추출 결과의 은행명, 지점명, 계좌 종류, 계좌 번호, 계좌 명의 열은 은행의 인터넷 뱅킹 시스템이 업로드로 수락하는 CSV 형식의 일괄 지급 파일 입력을 구성합니다.

지급 조건(支払条件) — 복합 문구에서 마감일과 지급 지연까지

일본의 지급 조건은 AP 팀이 한눈에 읽을 수 있지만 공식화된 추출에는 저항하는 간결한 구문입니다. "20일 마감 다음 달 말 지급"은 두 가지 결정을 인코딩합니다. 청구 기간이 매월 20일에 마감되고 지급이 다음 달 말까지 이루어져야 한다는 것입니다. 계산 열 — 추출 중 AI가 계산하는 열 — 이를 두 개의 구조화된 필드로 분할합니다: 마감일 및 지급 지연 개월 수.

마감일은 장식이 아니라 운영상 중요합니다. 20일 마감 조건에서 3월 18일자 청구서는 3월 청구 기간에 속합니다 — 지급은 4월 말까지 이루어져야 하며, 회사가 3월 31일에 결산하면 해당 비용은 현재 회계 연도에 속합니다. 동일한 20일 마감 조건에서 3월 22일자 청구서는 4월 청구 기간에 속합니다 — 지급은 5월 말까지 이루어져야 하며, 해당 비용은 다음 회계 연도에 속합니다. 마감일은 청구서 날짜나 달력 월 경계가 아니라 회계 연도 분류를 결정합니다. 동일한 지급 조건 로직은 일본 구매 주문서 데이터 추출 가이드에 자세히 설명되어 있으며, 조달 측면에서 동일한 지급 조건 필드를 전달합니다.

소비세(消費税) — 세금 신고서가 구조화된 입력으로 필요로 하는 이중 세율 분할

일본의 소비세 제도는 10% 표준 및 8% 인하라는 두 가지 세율을 사용하며, 적격 청구서는 각 세율 범주에 대해 과세 표준과 세액을 별도로 명시해야 합니다. 지급 전에 청구서를 검증하는 AP 팀은 청구서의 세율 그룹 합계가 회계 시스템이 기대하는 것과 일치하는지 확인해야 합니다. 소비세 신고서를 제출하는 세무 팀은 신고 계산을 위한 입력 데이터로 10% 및 8% 합계가 필요합니다.

추론 열은 추출 중 분류를 처리합니다: 세율. AI는 각 라인 품목 설명을 읽고 일본의 이중 세율 규칙을 적용하여 세율 열을 채웁니다. 출력 스프레드시트는 모든 라인이 사전 분류된 상태로 도착합니다 — 10% 표준 소계 및 8% 인하 소계는 별도의 분류 패스를 요구하지 않고 추출된 데이터에서 계산할 수 있습니다. 혼합 품목 청구서 — 사무용품(10%)이 포장 음료(8%)와 함께 배송되는 경우 — 라인별 분류는 각 청구서 PDF를 다시 열지 않고 청구서의 세율 그룹 합계가 올바른지 확인하는 유일한 방법입니다.

원천징수 (源泉徴収) — 지급자가 송금 전에 공제해야 하는 경우

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

원천징수 구분이 포함된 청구서 — 흔히 源泉徴収あり로 표시되거나 별도의 「源泉徴収額」 라인으로 표시됨 — 는 지급 계산을 변경합니다. AP 팀은 청구서 합계에서 원천징수를 차감하고 순액을 공급자에게 지급하며 징수된 금액을 별도의 세금 예치 부채로 계상해야 합니다. 추출 중에 원천징수가 포착되지 않으면 AP 팀은 각 적격 청구서를 다시 검토하고 원천징수를 수동으로 계산한 후 지급을 조정해야 합니다 — 청구서당 산술 단계로, 60장의 청구서에 걸쳐 상당한 AP 시간을 소비합니다.

원천징수 구분으로 정의된 열은 공제가 필요한 청구서를 식별합니다. 순 지급액과 같은 계산 열은 실제 이체 금액을 직접 계산합니다.

추출된 청구서 데이터를 일본 회계 소프트웨어로 가져오기

추출 작업의 출력은 구조화된 스프레드시트입니다. 대상은 구매 분개가 기록되는 회계 소프트웨어와 지급이 실행되는 은행 시스템입니다. 일본의 모든 주요 회계 플랫폼은 구조화된 데이터 가져오기를 지원합니다 — 병목 현상은 항상 가져오기 이전 단계, 즉 공급자 PDF에서 청구서 데이터를 추출하여 구조화된 형태로 만드는 단계였습니다.

Yayoi (弥生会計) — 일본 중소기업 회계 시장의 선두주자 — CSV를 통해 구매 원장 데이터를 가져옵니다. 추출된 청구서 열은 직접 매핑됩니다: 청구서 번호 → 伝票番号, 공급자 → 仕入先, 날짜 → 日付, 합계 → 金額. 세율 범주별 소비세액은 Yayoi의 세금 신고 모듈로 전달됩니다. Yayoi Sales (弥生販売) — 동반 구매 모듈 — 도 사용하는 기업의 경우 청구서 데이터는 해당 구매 주문서 기록에 연결되어 삼자 일치(三点照合)에 필요한 문서 체인을 생성합니다.

freee — 70,000개 이상의 중소기업이 사용하는 클라우드 회계 플랫폼 — CSV 가져오기에서 자동 분개 생성(自動仕訳)을 지원합니다. 각 청구서 라인과 함께 추출된 적격 청구서 등록 번호는 freee의 청구서 규정 준수 확인으로 흐르고, 세율별 소비세액은 freee가 자동으로 생성하는 소비세 신고 계산에 반영됩니다. 계좌 이체 정보 — 추출에서 이미 별도 열로 제공됨 — 는 은행 일괄 파일 생성을 위해 freee의 지급 모듈로 전달됩니다.

MoneyForward Cloud Accounting (マネーフォワード クラウド会計) — 일본에서 가장 많은 금융 기관 API 연결 보유 — 구매 청구서 데이터를 구매 관리 모듈로 가져옵니다. 플랫폼의 자동 은행 잔액 조정은 지급 기록을 은행 피드와 대조하고, 소비세 내역이 포함된 추출된 청구서 데이터는 MoneyForward의 이중 세율 세금 신고를 지원합니다.

勘定奉行 — OBC의 중견기업용 제품군 — 구매 청구서 데이터의 일괄 CSV 가져오기를 지원하며, 부문별 원가 관리(部門別原価管理) 기능을 제공합니다. 청구서에 부서 코드나 원가 센터 참조가 포함된 경우, 해당 필드는 자동으로勘定奉行의 세그먼트별 손익 보고서에 반영됩니다.

공통점: 청구서 데이터가 구조화된 열로 정리되면, 이러한 플랫폼 중 어느 곳으로든 가져오기는 파일 업로드에 불과합니다. 현재 몇 시간이 걸리는 단계 — 은행 정보, 세액, 지급 조건을 60장의 청구서에서 회계 시스템에 입력하는 작업 — 은 검증 작업으로 바뀝니다: 추출된 데이터를 확인하고, 이상치를 검토한 후 가져오면 됩니다. 매칭 워크플로우의 조달 측면에 동일한 추출 방식을 적용하는 방법은 일본 구매 주문서 데이터를 Excel로 추출하는 단계별 가이드를 참조하십시오. 청구서 지급과 함께 나타나는 거래 내역을 추출하는 은행 측면의 경우, 일본 은행 통장 추출 가이드에서 통장에서 스프레드시트로의 전체 워크플로우를 다룹니다.

FAQ

소규모 공급업체의 손으로 쓴 청구서도 추출할 수 있나요?

네. 많은 소규모 일본 공급업체 — 지역 서비스 제공업체, 개인 계약자, 지방 제조업체 — 는 여전히 인쇄된 용지에 볼펜으로 금액을 기재하고 회사 도장을 찍은 손으로 쓴 청구서(手書き請求書)를 발행합니다. AI 모델은 손으로 쓴 한자와 숫자를 읽을 수 있으며, 수기 청구서에서 흔히 사용되는 약식 표기도 인식합니다. 스캔 품질이 낮거나 팩스 사본인 경우 300dpi 이상으로 스캔하는 것이 좋습니다. 특히 손으로 쓴 은행 계좌 번호는 숫자를 잘못 읽으면 송금이 실패할 수 있으므로, 손으로 쓴 문서의 경우 어려운 문자를 교차 확인하는 것이 바람직합니다.

추출 기능은 ゆうちょ銀行 계좌 번호 형식을 어떻게 처리하나요?

일본우정은행(ゆうちょ銀行)은 일반 은행의 7자리 계좌 번호와 다른 記号-番号 형식을 사용합니다. 일반 은행에서 일본우정 계좌로 송금할 때는 記号-番号를 7자리 송금용 계좌 번호로 변환해야 합니다. 추론 열을 사용하면 추출 중에 이 변환을 수행할 수 있습니다: 열 로직을 정의하여 은행 이름이 ゆうちょ銀行인지 감지하고, 記号-番号 필드를 파싱한 후 변환된 7자리 번호를 출력합니다. 일본우정은행 웹사이트에 변환 규칙이 게시되어 있습니다 — 기본적으로 記号 숫자는 송금용 계좌 번호의 첫 부분에 매핑되고, 番号 숫자는 나머지 부분에 매핑됩니다.

적격 청구서 등록 번호(インボイス登録番号)가 없는 경우 어떻게 되나요?

공급자가 적격 청구서 발행 사업자(適格請求書発行事業者)로 등록되지 않은 경우, 해당 청구서에는 등록 번호가 기재되지 않습니다. 이 경우 구매자는 구매에 대한 전체 매입세액 공제를 받을 수 없지만, 경과 조치에 따라 일부 공제가 허용됩니다. 2023년 10월부터 2026년 9월까지는 매입세액의 80%가 공제 가능합니다. 2026년 10월부터 2029년 9월까지는 50%가 공제 가능합니다. 2029년 9월 이후 또는 2031년 이후에는 0%입니다. 경과 기간 동안 AP 팀은 적격 청구서와 다른 기준으로 공제액을 계산해야 하므로, 비적격 청구서를 별도로 표시해야 합니다. 등록 번호를 추출하거나 그 부재를 기록하는 추출 열은 각 청구서를 올바른 세무 처리로 분류하는 데 필요한 데이터를 제공합니다.

동일한 추출로 세금 포함(税込) 및 세금 별도(税抜) 청구서를 모두 처리할 수 있나요?

가능하지만, 열 정의에서 원하는 출력 형식을 지정해야 합니다. 일부 공급자가 세금 포함 청구서(内税)를 발행하고 다른 공급자가 세금 별도 청구서(外税)를 발행하는 경우, 계산 열을 추가하여 추출 중 정규화를 해결할 수 있습니다. 예: 세금 별도 라인 금액. AI는 청구서의 税込 또는 税抜 표기 등 문서 맥락을 읽어 세무 처리를 판단하고 출력을 정규화합니다. 스프레드시트의 모든 라인 금액은 일관된 세금 별도 기준으로 도착하여 구매 주문서와 비교할 준비가 됩니다.

원천징수(源泉徴収) 열은 지급 금액 계산과 어떻게 연동되나요?

원천징수는 지급자가 공급자에게 송금하기 전에 공제하는 금액입니다. 청구서 합계는 총 청구 금액이며, 공급자가 수령하는 금액은 합계에서 원천징수를 뺀 금액입니다. 순 지급액로 구성된 계산 열은 각 청구서의 실제 이체 금액을 출력합니다. 원천징수 금액은 별도 예치금으로 세무서(税務署)에 납부해야 합니다. AP 원장에는 원천징수 대상 청구서별로 총 금액, 원천징수 금액, 순 지급액의 세 가지 열이 있어야 합니다. 추출은 세 가지를 모두 생성하므로 지급 일괄 파일과 세금 예치 일정이 동일한 원본 데이터에서 작성됩니다.

혼합 소비세율이 적용된 청구서도 처리할 수 있나요?

네, 가능합니다. 일본 청구서 한 장에 표준세율 10%, 경감세율 8%, 면세 항목이 함께 포함될 수 있습니다. 적격 청구서 제도는 세율 구분별 과세 표준과 세액을 별도로 기재하도록 요구합니다. 추출 과정에서 추론 열이 품명을 기준으로 각 라인 항목을 세율별로 분류합니다 — 8%는 식품·음료, 10%는 일반 상품·서비스, 면세 대상은 면세로 구분합니다. 출력 스프레드시트는 세율별로 항목을 그룹화하며, 세율별 합계는 청구서에 기재된 세액 내역과 대조하여 검증할 수 있습니다. 두 값이 일치하지 않을 경우 — 추출 결과의 8% 합계가 청구서에 기재된 8% 합계와 다를 경우 — 불일치 항목은 검토 대상으로 표시됩니다. 이는 AP 팀이 수동으로 수행하던 검증과 동일한 절차를 60장의 청구서에 대해 동시에 자동으로 수행하는 것입니다.

PDF 60장에서 지급 준비 완료 스프레드시트로

일본 청구서는 단순한 청구서가 아닙니다. 지급 지시서입니다 — 은행 정보는 AP 팀에 자금을 보낼 곳을 알려줍니다. 세금 문서입니다 — 소비세 내역은 국세 신고에 반영되며, 적격 청구서 등록 번호는 매입세액 공제의 전제 조건입니다. 컴플라이언스 기록입니다 — 원천징수 구분은 구매자 측의 별도 세금 납부 의무를 발생시킵니다. 그리고 대사 대상 문서입니다 — 청구서 번호, 라인 항목, 금액은 지급 승인 전에 해당 구매 주문서 및 납품서와 대조 검증되어야 합니다.

합계 금액과 날짜뿐만 아니라 이러한 모든 필드를 포착하는 추출 워크플로우는 월말 청구서 더미를 데이터 입력 대기열에서 검증 체크리스트로 전환합니다. 계좌 이체 정보는 열로 정리되어 지급 배치 파일로 바로 사용할 수 있습니다. 소비세는 세율별로 구분되어 세금 신고에 바로 반영할 수 있습니다. 원천징수 구분이 표시되어 적격 청구서가 실수로 총액으로 지급되는 일이 없습니다. 지급 조건은 결제일과 지연 일수로 파싱되어 지급 일정이 자동으로 채워집니다. 스프레드시트는 구조화된 상태로 도착하며, AP 팀의 시간은 입력에서 검증으로 — 데이터 입력에서 재무 관리로 전환됩니다.