공급업체 청구서 30장을
지급 준비 완료된 AP 스프레드시트 하나로

단일 파일 추출이 놓치는 것

허브 문서인 일본 청구서 데이터를 Excel로 추출하기에서는 전체 필드 구조(은행 송금 정보, 지급 조건, 소비세, 원천징수를 단일 청구서에서 캡처하는 방법)를 다룹니다. 하지만 단일 파일 워크플로우는 문서별 추출 문제를 해결할 뿐입니다. 일괄 지급 문제는 해결하지 못하며, 이는 다른 출력이 필요한 별개의 문제입니다.

30장의 청구서를 수동으로 처리하는 AP 담당자의 작업 순서는 다음과 같습니다. 청구서 PDF를 열고, 은행 송금 정보 블록을 찾고, 인터넷 뱅킹 화면에 네 가지 은행 필드를 입력하고, 지급 조건을 분석하여 납기일을 확인하고, 원천징수 여부를 확인하고, 소비세 내역을 검증하고, 공급업체 마스터와 청구서 등록 번호를 대조합니다. 이 순서를 30번 반복합니다. 청구서에서 데이터를 읽어내는 '추출' 작업과, 해당 데이터를 은행 송금 가능 형식으로 조합하는 '지급 준비' 작업이 하나의 반복적인 작업으로 결합되어 있습니다. 단일 파일 추출 도구는 이 둘을 분리합니다. 데이터는 스프레드시트 행으로 추출됩니다. 하지만 지급 준비(30개 행을 지급 배치 파일, 지급 일정, 원천징수 예치 일정, 세무 신고용 소비세 요약으로 조합하는 작업)는 여전히 수동으로 해야 합니다. 추출이 '읽기' 문제는 해결했지만, '조합' 문제는 해결하지 못한 것입니다.

일괄 처리는 두 문제를 동시에 해결합니다. 30장의 청구서를 하나의 작업 단위로 취급하여, 모든 문서에서 데이터를 한 번에 추출하고, 사람이 보기 위한 것이 아니라 다운스트림 시스템에 바로 사용할 수 있도록 구조화된 출력을 생성하기 때문입니다.

일괄 워크플로우: 한 번 정의하고 매달 처리

일본 청구서 일괄 처리를 위한 열 스키마는 한 번만 정의합니다. 동일한 20개 이상의 열 이름(청구서 번호, 발행일, 발행자, 적격 청구서 등록 번호, 품명, 수량, 단가, 금액, 소계, 10% 과세 대상 금액, 10% 소비세, 8% 과세 대상 금액, 8% 소비세, 합계 금액, 원천징수 구분, 은행명, 지점명, 계좌 유형, 계좌 번호, 예금주, 지급 조건, 마감일, 송금 수수료 부담)을 한 번 입력합니다. 이후 매달 AP 팀은 월말 청구서 PDF 더미를 업로드에 넣기만 하면, 일괄 처리가 모든 문서를 동시에 분석하고, 30개 행이 모두 채워진 출력 스프레드시트가 생성됩니다. 열 이름은 변경되지 않습니다. 공급업체의 청구서 형식은 변경될 수 있지만(한 공급업체의 새 ERP 시스템 도입, 다른 업체의 청구 플랫폼 마이그레이션), AI는 각 필드의 의미를 이해하여 문서를 읽기 때문에 각 공급업체가 은행 정보를 페이지의 어디에 배치하는지 기억할 필요가 없습니다.

이 스키마는 맞춤 열 추출을 캡처합니다. 출력에 원하는 열 이름을 입력하면, AI가 각 문서에서 일치하는 데이터를 필드의 의미를 이해하여 찾습니다. 공급업체 청구서 레이아웃에 따라 달라지는 고정된 위치에 의존하지 않습니다. 계산 열은 추출 중에 추가 값을 도출할 수 있습니다. 예를 들어 순 지급액 (원천징수 적용 시: 합계 × 0.8979, 미적용 시: 합계)와 같은 열은 실제 송금 금액을 직접 계산합니다. 추론 열은 간결한 지급 조건 텍스트를 구조화된 값으로 변환할 수 있습니다. 마감일 (지급 조건에서: "20일 마감"이면 20) 및 지급 지연 개월 수 ("다음 달 말 지급"이면 1) — "20일 마감 다음 달 말 지급"이라는 텍스트 문자열을 지급 일정 공식이 직접 읽을 수 있는 두 개의 계산 가능한 숫자로 분할합니다.

출력 1: 계좌 정보 → 지급 일괄 파일

일본 AP에서 가장 반복적인 데이터 입력 작업은 청구서의 계좌 정보를 인터넷 뱅킹 시스템에 다시 입력하는 것입니다. 각 청구서에는 振込先 블록이 있으며, 여기에는 은행명(銀行名), 지점명(支店名), 계좌 유형(口座種別 — 보통 예금은 普通, 당좌 예금은 当座), 계좌 번호(口座番号)의 네 가지 필드가 포함됩니다. AP 담당자는 청구서에서 이 네 가지 필드를 읽고, 은행의 인터넷 뱅킹 화면으로 전환하여 입력합니다. 이는 이미 회계 시스템의 공급처 마스터에 저장된 동일한 네 가지 필드로, 매월 모든 청구서에 대해 다시 입력됩니다. 월말에 30장의 청구서가 있다면, 120개의 개별 은행 필드 항목이 이미 기록된 데이터를 중복 입력하게 됩니다.

일괄 출력에 은행명, 지점명, 계좌 유형, 계좌 번호의 네 가지 은행 필드가 각각의 열로 포함되어 있으면, 해당 열은 지급 일괄 파일의 입력값이 됩니다. 일본 은행은 전은 포맷(全銀フォーマット, Zengin format)의 일괄 이체 파일을 허용합니다. 이는 전국은행자금결제네트워크(全国銀行資金決済ネットワーク)가 표준화한 고정 길이 형식으로, 기업이 인터넷 뱅킹 화면에서 하나씩 입력하는 대신 단일 업로드로 여러 건의 송금 이체를 제출할 수 있게 해줍니다. 이 형식에는 각 이체 건에 대해 송금 은행 지점 코드, 송금 계좌 번호, 수취 은행 코드, 수취 지점 코드, 수취 계좌 번호, 수취인 이름, 이체 금액이 모두 정확한 문자 위치에 필요합니다.

각 행에 은행명, 지점명, 계좌 유형, 계좌 번호, 예금주, 순 지급액이 별도 열로 포함된 30행의 스프레드시트는 간단한 템플릿을 통해 전은 포맷으로 매핑할 수 있습니다. 데이터는 이미 구조화되어 있습니다. 매핑은 일회성 스프레드시트-고정 길이 내보내기일 뿐, 30번의 은행 코드 재입력이 아닙니다. 동일한 접근 방식은 종합 이체(総合振込, consolidated transfer)에도 적용됩니다. 종합 이체는 단일 회사 계좌에서 여러 지급을 하나의 이체 지시로 처리하는 방식으로, 동일한 결제일에 여러 공급처 청구서를 지급하는 일본 기업에게 가장 일반적인 방법입니다. 추출된 계좌 정보를 결제일별로 그룹화하면 종합 이체 일괄 파일의 입력값이 됩니다. 20일 마감이고 월말 지급인 모든 청구서는 하나의 이체 지시로, 월말 마감이고 다음 달 지급인 모든 청구서는 다른 이체 지시로 묶입니다.

출력 2: 지급 조건이 결제일 달력으로 변환됩니다

일본 청구서의 지급 조건 필드는 AP팀이 쉽게 읽지만 공식적인 처리가 어려운 간결한 텍스트 문자열입니다. "20일 마감 다음 달 말일 지급" — 청구 마감은 20일, 지급 기한은 다음 달 말일입니다. "말일 마감 다다음 달 10일 지급" — 청구 마감은 말일, 지급 기한은 다다음 달 10일입니다. "15일 마감 다음 달 말일 지급" — 청구 마감은 15일, 지급 기한은 다음 달 말일입니다. 각 문자열은 마감일(締日)과 지급 지연이라는 두 가지 값을 인코딩합니다. 단일 파일 워크플로에서는 사람이 각 청구서의 문자열을 읽고, 지급 예정일을 머릿속으로 계산한 후 달력에 입력합니다. 일괄 워크플로에서는 계산 열이 이러한 문자열을 마감일과 지급 지연 개월 수라는 구조화된 숫자로 구문 분석하고, 스프레드시트가 마감일별로 지급을 자동으로 그룹화합니다.

이 그룹화는 현금 유출을 통제하기 때문에 중요합니다. 20일에 마감되고 다음 달 말일에 지급되는 청구서는 모두 같은 날 현금이 유출됩니다. 말일에 마감되고 다음 달 말일에 지급되는 청구서는 2~3주 후 다른 날짜에 현금이 유출됩니다. 일괄 그룹화가 없으면 AP팀은 30개의 개별 납기일을 보게 됩니다. 일괄 그룹화를 사용하면 AP팀은 총액이 표시된 2~3개의 현금 유출일을 보게 됩니다. 이는 재무 부서가 운전 자본을 관리하는 데 실제로 필요한 정보입니다. 마감일은 청구서 날짜나 달력 월이 아니라 비용이 속한 회계 기간을 결정합니다. 20일 마감 조건에서 3월 18일자 청구서는 3월 비용입니다. 4월에 지급되지만 3월 31일에 종료되는 회계 연도에 발생합니다. 동일한 20일 마감 조건에서 3월 22일자 청구서는 4월 비용입니다. 5월에 지급되며 다음 회계 연도에 발생합니다. 마감일이 회계 기간의 경계이며, 계산 열이 이를 숫자로 추출했기 때문에 일괄 출력은 해당 경계별로 자동으로 그룹화됩니다.

출력 3: 소비세 합계가 세무 신고서에 직접 입력됩니다

일본의 소비세 제도는 10% 표준 세율과 8% 경감 세율이라는 두 가지 세율을 적용하며, 적격 청구서 제도는 각 청구서에 세율 범주별로 과세 기준과 세액을 별도로 명시하도록 요구합니다. 소비세 신고를 위해 적산 계산 방식을 사용하는 회사의 경우, 세무 신고서에는 청구서별 세금 데이터가 필요합니다. 단순한 집계 소계가 아니라 각 적격 청구서의 개별 세액을 문서 수준에서 보존해야 합니다.

일괄 출력은 각 청구서에서 10% 과세 금액, 10% 소비세, 8% 과세 금액, 8% 소비세를 별도의 열로 캡처합니다. 스프레드시트는 각 청구서에 인쇄된 세금 내역과 대조하여 확인할 수 있는 세율별 그룹 합계를 제공합니다. 이는 AP팀이 각 청구서에서 수동으로 수행해야 하는 동일한 확인 작업이지만, 30개 청구서 전체에 대해 단일 출력에서 자동으로 수행됩니다. 청구서에서 추출된 8% 소비세 합계가 문서에 인쇄된 합계와 다른 경우, 그 차이가 스프레드시트에 플래그되어 검토 대상이 됩니다. 30개의 청구서 더미는 30개의 개별 확인 작업이 아닌 하나의 확인 체크리스트가 되며, 세율별 그룹 합계는 별도의 수동 집계 과정 없이 분기별 소비세 신고서의 입력 자료가 됩니다.

출력 4: 원천징수 후 순지급액 산출

일본의 원천징수 제도(源泉徴収制度)는 소득세법(所得税法) 제204조에 따라 세무사(税理士), 공인회계사(公認会計士), 변호사(弁護士), 사법서사(司法書士), 디자이너(デザイナー), 작가(著作家) 등 특정 전문 서비스 제공자에게 지급할 때 원천징수하도록 규정하고 있습니다. 원천징수율은 지급액 100만 엔 이하의 경우 10.21%, 100만 엔 초과분의 경우 20.42%이며, 이는 국세청 원천징수 안내에서 확인할 수 있습니다. 지급자는 원천징수액을 세무서에 납부하고, 공급자에게는 나머지 잔액을 지급합니다.

원천징수 대상 공급자의 청구서에는 일반적으로 '源泉徴収あり'로 표시되거나 별도의 '源泉徴収額' 항목이 있어 지급 계산이 달라집니다. AP팀은 원천징수가 필요한 청구서를 식별하고, 청구서별 공제액을 계산한 후 지급액에서 차감하고, 원천징수액을 별도의 세금 예치금 부채로 계상해야 합니다. 단일 파일 워크플로에서는 대상 청구서마다 수동 계산이 필요합니다. 일괄 워크플로에서는 두 개의 열로 처리합니다:

• 원천징수 구분 — 청구서에 源泉徴収가 명시되어 있는지, 공급자가 대상 전문직인지 확인하는 추론 열입니다. 출력값: "해당" 또는 "해당 없음".
• 순지급액 — 계산 열입니다. 원천징수가 적용되고 총액이 100만 엔 미만인 경우 총액 × 0.8979를 출력합니다. 각 청구서의 실제 이체 금액을 출력합니다.

스프레드시트에는 대상 청구서당 세 개의 열(총액(청구서 합계), 원천징수액(공제액), 순지급액(이체 금액))이 있습니다. 지급 일괄 파일은 순지급액을 사용합니다. 세금 예치금 일정은 원천징수액을 사용합니다. 둘 다 동일한 원천 데이터(한 번 추출, 한 번 계산)를 사용하여 지급과 규정 준수 모두에 활용됩니다. 일본 구매 주문서에 대한 동일한 일괄 처리 방식은 조달 측면에서 동일한 지급 조건과 원천징수 필드를 캡처하여 주문된 내용과 청구되는 내용 간의 일치 파이프라인을 생성합니다.

송장 번호 체인: PDF에서 지불 확인까지

송장 번호(請求書番号)는 AP 조회 및 지불 추적의 기본 키입니다. 은행에서 지불 확인이 도착하면 — 미쓰비시 UFJ 은행 신주쿠 지점, 계좌 1234567로 847,200엔의 후리코미 거래 기록 — AP 팀은 이를 원본 송장과 대조하여 올바른 금액이 올바른 계좌로 올바른 송장에 대해 지불되었는지 확인해야 합니다. 송장 번호가 없으면 은행 거래를 공급업체 송장과 일치시키는 것은 규모가 커질수록 복잡해지는 조정 문제가 됩니다: 월 30건의 공급업체 지불, 연간 12개월, 360건의 잠재적 불일치.

일괄 출력물은 전용 열에 송장 번호를 포함합니다. 은행의 모든 지불 확인은 금액이 아닌 송장 번호로 일괄 스프레드시트와 대조될 수 있으며(두 송장이 동일한 총액을 가질 경우 모호할 수 있음), 원본 송장 PDF에서 추출 스프레드시트를 거쳐 은행 지불 기록까지 이어지는 감사 추적을 생성합니다. 송장 번호와 함께 추출된 적격 청구서 등록 번호(インボイス登録番号)는 두 번째 확인 지점을 제공합니다: 추출된 데이터의 T-번호는 공급업체 마스터의 T-번호와 일치해야 합니다. 불일치가 발생하면 등록 상태가 변경되었을 수 있는 공급업체가 플래그 지정됩니다 — 수동 작업에서는 소비세 신고가 감사 문의를 촉발할 때까지 감지되지 않을 데이터 포인트입니다.

이 체인 — 송장 번호 → 은행 송금 → 지불 확인 — 은 30건의 개별 후리코미 송금을 단일 조정 작업으로 전환합니다. 일괄 처리는 단순히 데이터를 더 빠르게 추출하는 것이 아닙니다. 30건의 지불을 30건의 개별 조사가 아닌 하나의 그룹으로 조정 가능하게 만드는 연결 구조를 생성합니다. 조달 측면의 동일한 연결 원칙은 발주-납품-송장 매칭 워크플로와 호주 BAS 분기별 일괄 접근 방식을 추진합니다 — 추출 결과물은 최종 지점이 아니라 구매 주문서로 시작하여 세금 신고서로 끝나는 문서 체인의 중간 지점입니다.

자주 묻는 질문

공급업체마다 청구서 형식이 다른 경우에도 일괄 처리가 가능한가요?

네, 가능합니다. 열 스키마는 한 번 정의하면 레이아웃에 관계없이 배치 내 모든 청구서에 적용됩니다. 어떤 공급업체는 ERP 시스템에서 생성한 PDF를 사용하여 페이지 하단의 테두리 상자에 계좌 정보를 표시할 수 있습니다. 다른 공급업체는 스캔한 수기 청구서를 보내면서 계좌 정보가 비고란에 나타날 수도 있습니다. AI는 각 문서를 읽을 때 각 필드가 의미하는 바를 이해합니다. 즉, 은행명이 어디에 나타나든 은행명은 은행명입니다. 공급업체별로 고정된 레이아웃을 기대하지 않습니다. 서른 개의 청구서가 서로 다른 서른 개의 청구 시스템에서 서로 다른 서른 가지 형식으로 와도 출력은 하나의 일관된 스프레드시트입니다.

일괄 처리는 유초 은행 계좌 번호 형식을 어떻게 처리하나요?

유초 은행은 이체에 사용되는 일반 은행의 7자리 계좌 번호와 다른 기호-번호 형식을 사용합니다. 배치 출력이 은행명으로 유초 은행을 감지하면, 추론 열이 기호-번호 쌍을 금융 시스템에 필요한 7자리 이체 계좌 번호로 변환할 수 있습니다. 유초 은행은 웹사이트에 변환 규칙을 공개하고 있습니다. 열 로직은 기호 숫자와 번호 숫자를 구문 분석하여 원래 형식과 함께 이체 가능한 계좌 번호를 출력하여 확인할 수 있도록 합니다.

일부 청구서는 세금 포함(税込)이고 다른 청구서는 세금 별도(税抜)인 경우는 어떻게 하나요?

열 정의는 원하는 출력 정규화를 지정해야 합니다. 일부 공급업체 청구서의 단가가 세금 포함이고 다른 청구서는 세금 별도인 경우, 계산 열이 추출 중에 이를 정규화합니다: 라인 금액(세금 별도) (청구서 표기가 税込인 경우, 10% 품목은 단가를 1.1로 나누고 8% 품목은 1.08로 나눕니다. 그렇지 않으면 그대로 사용합니다). AI는 税込 또는 税抜 표기를 포함한 문서 컨텍스트를 읽어 과세 처리를 결정하고 모든 라인 금액을 일관된 기준으로 출력합니다. 스프레드시트는 모든 행이 정규화된 상태로 제공되므로, 서른 개 청구서 전체의 소비세 합계는 일관된 기준에서 계산됩니다.

원천징수(源泉徴収) 열은 소비세 계산과 어떻게 연동되나요?

국세청 지침에 따르면, 청구서에 보수와 소비세가 명확히 구분되어 기재된 경우 원천징수는 보수 금액에 대해서만 계산되며, 소비세 부분은 원천징수 대상에서 제외됩니다. 구분되지 않은 경우에는 일반적으로 세금 포함 금액을 기준으로 원천징수액을 계산합니다. 열 정의에는 계산 규칙을 명시해야 합니다: 원천징수 기준 (청구서에 報酬와 消費税가 명확히 구분된 경우 報酬 사용, 그렇지 않으면 합계 사용) 및 원천징수액 (원천징수 기준 × 0.1021, 단 100만 엔 이하 부분에 대해서는 원천징수 기준 × 0.1021을 한도로 함). 일괄 처리는 30장의 청구서 전체에 동일한 규칙을 적용하므로, 원천징수 계산이 일관되고 감사 가능합니다.

일괄 처리 결과물을 일본 회계 소프트웨어에 직접 가져올 수 있나요?

네. 일본의 주요 회계 플랫폼 — 야요이(Yayoi), freee, 머니포워드 클라우드(MoneyForward Cloud), 간조 부교(Kanjo Bugyo) — 모두 구매 원장 데이터의 CSV 가져오기를 지원합니다. 일괄 처리 결과물은 다음과 같이 직접 매핑됩니다: 청구서 번호 → 전표 번호, 공급업체 → 거래처명(仕入先), 발행일 → 거래일자(日付), 합계 → 금액(金額). 세율별 소비세 열은 세금 신고 모듈로 전달됩니다. 적격 청구서 등록 번호(インボイス登録番号)는 freee와 같은 플랫폼이 자동으로 수행하는 적격 청구서 확인 검증으로 전달됩니다. 은행 송금 정보는 별도 열로 제공되어, 회계 소프트웨어 가져오기와는 별개로 은행의 일괄 지급 파일 입력을 구성합니다.

30장의 PDF에서 지급 준비 완료된 원장까지

일본 기업의 월말 청구서 더미는 단순히 지급해야 할 30장의 청구서가 아닙니다. 이는 30개의 지급 지시서이며, 각각 은행 시스템에 다시 입력해야 하는 은행 송금 정보를 담고 있습니다. 또한 30개의 세금 문서로, 분기별 신고에 사용될 세율별 소비세 금액을 포함합니다. 그리고 30개의 규정 준수 기록으로, 일부는 별도 세금 납부가 필요한 원천징수 의무를 수반합니다. 마지막으로 30개의 대사 증빙으로, 구매 주문서, 납품 확인서, 은행 지급 기록과 일치해야 하는 청구서 번호가 포함됩니다.

30장의 청구서를 하나의 작업 단위로 처리하는 일괄 추출 워크플로우는 30개의 개별 스프레드시트 행이 아닌, 네 가지 즉시 사용 가능한 결과물을 생성합니다: 송금 준비가 완료된 열에 은행 정보가 담긴 지급 일괄 파일, 결제일별로 그룹화된 지급 일정표, 세금 신고를 위한 세율별 소비세 요약, 그리고 순 지급액이 이미 계산된 원천징수 일정표입니다. 미지급금(AP) 팀의 월말 업무는 데이터 입력에서 데이터 검증으로 전환됩니다. 즉, 동일한 네 가지 은행 필드를 30번 입력하는 대신, 추출된 30개의 행이 원본 문서와 일치하는지 확인하는 것입니다. 스프레드시트는 결과물입니다. 동시에 스프레드시트는 은행 지급 시스템, 회계 소프트웨어, 세금 신고의 입력물이기도 합니다. 일괄 처리는 각 하위 시스템이 기대하는 구조로 데이터를 생성함으로써 이들을 연결하며, 각 인계 전에 사람이 데이터를 재구성해야 하는 방식이 아닙니다.