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

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

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

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

フィールド構造は推測に基づくものではありません。内閣府が公開する適格請求書制度の公式概要には、すべてのインボイスに必須とされる6項目が明記されています。しかし、抽出作業はこの6項目にとどまりません。買掛金処理で最も手作業を要するフィールド（銀行振込情報、支払条件の解析、源泉徴収）は、法律上インボイスに必須ではありません。これらは慣行として記載されるものであり、日本の請求書処理ワークフローを米国や欧州のものと異なるものにしているフィールドです。

汎用的な請求書抽出が日本の請求書で機能しない理由

ほとんどのAI請求書抽出ツールは、英語の請求書データセット（米国やEUの形式で、「請求書番号」「支払期日」「合計金額」「販売元」といったフィールドがあるもの）で学習されています。このようなツールに日本の請求書を投入すると、3つの問題が発生します。

第一に、仕入先の銀行振込先情報（振込先）が無視されるか誤読されます。日本の請求書には、銀行名（例：三菱UFJ銀行）、支店名（例：新宿支店）、口座種別（普通）、口座番号がそれぞれ別のラベル付きフィールドとして記載されています。しかし、汎用的な抽出エンジンはページ下部の4つのテキスト文字列を認識しても、「振込先情報」という列定義を持たないため、これらをスキップするか、1つの判読不能なフィールドに連結してしまいます。その結果、買掛金チームは各PDFを開いて銀行情報を支払システムに手入力しなければなりません。

第二に、支払条件（支払条件）は、2つの計算可能な値を含んでいるにもかかわらず、不透明なテキスト文字列として読み取られます。「20日締翌月末払い」は装飾的なテキストではありません。これは買掛金チームに対して、請求期間が20日に締め切られること（その日以前の取引は今月の債務、以降の取引は翌月の債務となる）、および支払いが翌月末までに行われることを示しています。汎用的な抽出ツールはこの文字列をそのまま出力します。日本の支払慣行を理解する抽出ツールは、これを「締日：20日」「支払猶予：1ヶ月」という2つの構造化された値に分割し、支払カレンダーの計算式で利用できるようにします。

第三に、消費税の内訳と源泉徴収区分には、欧米の抽出スキーマに相当するものがありません。米国の請求書における税フィールドは単一の売上税行です。日本の請求書には、最大3つの税関連フィールドが存在する可能性があります。すなわち、10%消費税の小計、8%軽減税率消費税の小計（複数品目の請求書の場合）、そして仕入先が適格事業者である場合の源泉徴収額または区分マークです。すべての税フィールドを1つの数値にフラット化する汎用的な抽出では、買掛金チームが検証時にそのフラット化を元に戻す作業を強いられます。

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

수동으로 청구서를 AP 스프레드시트에 옮기던 작업을 대체하는 이 워크플로우는 구매 주문서에 사용된 접근 방식과 유사하지만, 열 스키마(청구서 고유 필드)가 다르고, PO 매칭 프로세스가 아닌 은행 지급 프로세스로 이어지는 다운스트림 파이프라인이 다릅니다. 3단계 워크플로우는 한 번 정의되며 모든 공급자, 모든 청구서 형식, 그리고 이후 모든 월말 일괄 처리에 적용됩니다.

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

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

계좌 이체 정보 (振込先) — 지급 배치를 생성하는 4개 필드

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

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

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

지급 조건 (支払条件) — 복합 텍스트에서 결제일과 지급 지연 기간으로

일본의 지급 조건은 AP 팀이 한눈에 읽을 수 있지만 공식 기반 추출이 어려운 간결한 구문입니다. "20日締翌月末払い"는 두 가지 결정을 포함합니다: 청구 기간이 매월 20일에 마감되고, 지급은 다음 달 말까지 이루어져야 합니다. 계산 열 — AI가 추출 중에 값을 계산하는 열 — 을 사용하여 이를 두 개의 구조화된 필드로 분할합니다: 결제일 (지급 조건에서: "20日締"이면 20, "月末締"이면 31, "10日締"이면 10) 및 지급 지연 개월 수 (지급 조건에서: "翌月末払い"이면 1, "翌々月末払い"이면 2).

결제일은 단순한 형식이 아니라 운영상 중요한 의미를 갖습니다. 20日締 조건에서 3월 18일자 청구서는 3월 청구 기간에 속하며, 지급은 4월 말까지 이루어져야 하고, 회사가 3월 31일에 결산을 마감하는 경우 해당 비용은 당기 회계연도에 속합니다. 동일한 20日締 조건에서 3월 22일자 청구서는 4월 청구 기간에 속하며, 지급은 5월 말까지 이루어져야 하고, 해당 비용은 다음 회계연도에 속합니다. 청구서 발행일이나 달력상 월 경계가 아닌 결제일이 회계연도 분류를 결정합니다. 동일한 지급 조건 로직은 일본 구매 주문서 데이터 추출 가이드에서 자세히 다루며, 조달 측면에서 동일한 지급 조건 필드를 제공합니다.

소비세 — 세무 신고에 필요한 이중 세율 분할 구조화 입력

일본의 소비세 제도는 10%(표준)와 8%(경감)의 두 가지 세율을 사용하며, 적격 청구서에는 각 세율 구분별로 과세 기준과 세액을 별도로 명시해야 합니다. 지급 전 청구서를 검증하는 AP팀은 청구서에 기재된 세율별 합계가 회계 시스템의 예상치와 일치하는지 확인해야 합니다. 소비세 신고를 담당하는 세무팀은 신고 계산을 위한 입력 데이터로 10% 및 8% 합계가 필요합니다.

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

원천징수 — 지급자가 송금 전에 공제해야 하는 경우

일본의 원천징수 제도는 특정 전문 서비스 제공자(세리사, 공인회계사, 변호사, 사법서사, 디자이너, 저작가 및 소득세법 제204조에 정의된 기타 여러 범주)에게 지급할 때 지급자가 원천에서 소득세를 공제하도록 요구합니다. 원천징수율은 일반적으로 지급액의 10.21%입니다. 지급자는 원천징수액을 세무서에 납부하고 공급자에게 나머지 89.79%를 지급합니다.

원천징수 분류가 있는 청구서(종종 '원천징수あり'로 표시되거나 별도의 '원천징수액' 라인이 표시됨)는 지급 계산을 변경합니다. AP팀은 청구서 합계에서 원천징수를 차감하고 순액을 공급자에게 지급한 후, 원천징수액을 별도의 세금 예치금 부채로 계상해야 합니다. 추출 중에 원천징수가 포착되지 않으면 AP팀은 각 적격 청구서를 재검토하고 수동으로 원천징수를 계산하여 지급액을 조정해야 하며, 이는 청구서당 산술 단계로, 60건의 청구서에 걸쳐 상당한 AP 시간을 소모합니다.

원천징수 분류 (청구서에 원천징수 언급 여부 확인; 공급자가 적격 전문가이고 원천징수가 표시된 경우 "해당", 그렇지 않으면 "해당 없음" 출력)으로 정의된 열은 공제가 필요한 청구서를 식별합니다. 순 지급액 (원천징수 해당 시: 합계 × 0.8979; 그 외: 합계)와 같은 계산 열은 실제 이체 금액을 직접 계산합니다.

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

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

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

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

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

Kanjo Bugyo (勘定奉行) — OBC의 중견 기업(연간 매출 5억~50억 엔)용 제품군 — 은 부문별 원가 관리(部門別原価管理) 기능과 함께 구매 청구서 데이터의 일괄 CSV 가져오기를 지원합니다. 청구서에 부서 코드나 원가 센터 참조가 포함된 경우, 해당 필드는 Kanjo Bugyo의 세분화된 손익 보고서로 자동 전달됩니다.

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

FAQ

소규모 공급자의 수기 청구서도 읽을 수 있나요?

네. 일본의 많은 소규모 공급자(지역 서비스 제공업자, 개인 사업자, 지방 제조업체)는 여전히 인쇄된 용지에 볼펜으로 금액을 기재하고 회사 인감을 날인한 수기 청구서(手書き請求書)를 발행합니다. AI 모델은 수기 한자와 숫자를 읽을 수 있으며, 수기 청구서에서 흔히 사용되는 약식 표기(㈱는 株式会社, 〒는 우편 기호 접두사, No.는 번호)도 인식합니다. 품질이 낮은 스캔본이나 팩스 사본의 경우 300dpi 이상으로 스캔할 것을 권장합니다. 수기 문서의 경우, 특히 한 자리 오독으로 이체가 실패할 수 있는 수기 은행 계좌 번호와 같은 어려운 문자는 점검하는 것이 바람직합니다.

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

일본우편은행(ゆうちょ銀行)은 일반 은행의 7자리 계좌 번호와 다른 記号-番号 형식(예: 記号12345 番号6789012)을 사용합니다. 일반 은행에서 일본우편 계좌로 이체할 때는 記号-番号를 7자리 이체용 계좌 번호로 변환해야 합니다. 추론 열을 사용하여 추출 중에 이 변환을 수행할 수 있습니다. 열 로직을 정의하여 은행명이 ゆうちょ銀行인지 감지하고, 記号-番号 필드를 구문 분석한 후 변환된 7자리 번호를 출력합니다. 일본우편은행 웹사이트에는 변환 규칙이 게시되어 있습니다. 기본적으로 記号 숫자는 이체 계좌 번호의 첫 부분에 매핑되고, 番号 숫자(8자리 번호의 경우 최종 검증 숫자 제외)는 나머지 부분에 매핑됩니다.

적격 청구서 등록 번호(インボイス登録番号)가 누락되면 어떻게 되나요?

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

동일한 추출 방식으로 세금 포함(税込) 청구서와 세금 별도(税抜) 청구서를 모두 처리할 수 있습니까?

가능합니다. 단, 열 정의에서 원하는 출력 형식을 지정해야 합니다. 일부 공급자가 세금 포함(内税) 청구서를 발행하고 다른 공급자가 세금 별도(外税) 청구서를 발행하는 경우, 계산 열을 추가하면 추출 중 정규화 문제가 해결됩니다. 예: 세금 별도 라인 금액(단가가 세금 포함인 경우 10% 항목은 1.1로, 8% 항목은 1.08로 나누고, 그렇지 않으면 그대로 사용). AI는 청구서에 기재된 税込 또는 税抜 표기를 포함한 문서 맥락을 읽어 세금 처리를 판단하고 출력을 정규화합니다. 스프레드시트의 모든 라인 금액은 일관된 세금 별도 기준으로 도착하며, 구매 주문서와 비교할 준비가 됩니다.

원천징수(源泉徴収) 열은 지급 금액 계산과 어떻게 상호 작용합니까?

원천징수는 지급자가 공급자에게 송금하기 전에 공제하는 금액입니다. 청구서 합계는 총 청구 금액이며, 공급자가 수령하는 금액은 합계에서 원천징수를 뺀 금액입니다. 순 지급액(원천징수 구분 = "해당"인 경우: 합계 × 0.8979, 그렇지 않은 경우: 합계)로 구성된 계산 열은 각 청구서의 실제 이체 금액을 출력합니다. 원천징수된 금액(합계와 순 지급액의 차이)은 별도 예치금으로 세무서(税務署)에 납부해야 합니다. 미지급금 원장에는 원천징수 대상 청구서당 세 개의 열(총액(청구서 합계), 원천징수액(세금 공제액), 순 지급액(이체 금액))이 있어야 합니다. 추출은 이 세 가지를 모두 생성하므로, 지급 배치 파일과 세금 예치 일정이 동일한 원천 데이터에서 구축됩니다.

동일 문서에 소비세율이 혼합된 청구서에도 작동합니까?

가능합니다. 단일 일본 청구서에는 10% 표준 세율, 8% 경감 세율 및 면세 항목이 함께 포함될 수 있습니다. 적격 청구서 제도는 청구서에 세율 범주별로 과세 기준과 세액을 별도로 명시하도록 요구합니다. 추출 중에 추론 열은 품목 설명에 따라 각 라인 항목을 세율별로 분류합니다(식음료 항목은 8%, 일반 상품 및 서비스는 10%, 명시적으로 면제된 항목은 면세). 출력 스프레드시트는 항목을 세율별로 그룹화하며, 세율별 그룹 합계는 청구서에 명시된 세금 내역과 대조하여 검증할 수 있습니다. 두 값이 일치하지 않는 경우(예: 추출에서 계산된 8% 합계가 청구서에 명시된 8% 합계와 다른 경우) 불일치 사항이 검토 플래그로 표시됩니다. 이는 미지급금 팀이 수동으로 수행하는 것과 동일한 확인 작업이지만, 60개의 청구서에 대해 동시에 자동으로 수행됩니다.

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

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

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