일본의 PO-청구서 매칭이 대부분의 조달팀이
예산으로 감당하는 것보다 더 자주 실패하는 이유

세 가지 문서, 하나의 거래 — 그러나 공유 데이터 모델은 없음

삼자 대사(三点照合, santen totsugō)는 조달 분야의 보편적인 안전장치입니다. 지불을 승인하기 전에 주문한 내용, 공급업체가 납품한 내용, 청구한 내용이 모두 동일한 거래를 설명하는지 확인하는 것입니다. 일본 공정거래위원회의 하도급법(下請代金支払遅延等防止法)은 2026년 중소기업 공정거래법에 의해 강화되어, 하도급업체에 발행되는 모든 구매 주문서에 납입 장소(納入場所, nōnyū basho), 지급 조건 및 마감일(支払条件・締日, shiharai jōken / shimebi), 검수 완료일 등 특정 항목을 포함하도록 의무화하여 구매 주문서를 거래의 법적 기준점으로 삼고 있습니다. 이론적으로 대사 작업 흐름은 선형적입니다: 구매 주문서 → 납품서 → 청구서 → 지불. 그러나 실제로는 형식, 일정, 명명 규칙이 충돌하는 삼자 대결입니다.

핵심 문제는 대사 작업이 지루하다는 것이 아닙니다. 세 문서 각각이 서로 다른 시스템, 다른 시점, 다른 대상을 위해 생성되었으며, 동일한 식별자를 사용하는 경우가 전혀 없다는 점입니다. 조달 관리자는 회사의 ERP에서 내부 공급업체 마스터에 연결된 구조화된 필드로 구매 주문서를 작성합니다. 공급업체는 자체 내부 제품 코드를 사용하고 수량을 손으로 기재한 종이 납품서와 함께 상품을 발송합니다. 2주 후, 공급업체의 청구 부서는 또 다른 시스템에서 구매 주문서나 납품서의 내용과 정확히 일치하지 않는 라인 설명이 포함된 청구서를 발행합니다. 세 가지 문서. 하나의 거래. 세 가지 호환되지 않는 데이터 표현.

일본 CFO 협회 보고서에 따르면 회계 부서 업무 시간의 약 30%가 문서 확인 및 대사 작업에 소요됩니다. 월 200건의 공급업체 주문을 처리하는 조달 팀의 경우, 이는 매월 약 60시간에 해당하며, 더 나은 조건 협상이나 공급업체 관계 관리가 아닌 세 장의 종이에 적힌 세 개의 숫자가 동일한 내용을 주장하는지 확인하는 기계적인 작업에 소비됩니다.

매칭이 실제로 깨지는 지점 — 네 가지 실패 유형

3자 대사는 단일 검증이 아닙니다. 개별 비교의 연속이며, 각각은 사람의 실수와 무관한 이유로 독립적으로 실패할 수 있습니다. 그 이유를 이해하는 것이 증상을 다루는 것과 구조를 다루는 것의 차이를 만듭니다.

1. 수량 불일치: 주문과 일치하지 않는 납품

공급업체가 M10 육각 볼트 200개에 대한 구매 주문서를 확인합니다. 첫 번째 납품에서 140개를 보내고 2주 후에 60개를 보냅니다. 첫 번째 납품서에는 140개, 두 번째에는 60개로 기재되어 있습니다. 두 번째 납품 이후 발행된 청구서에는 200개로 표시됩니다. 청구서를 기준으로 작업하는 지급 담당 팀은 200개를 확인하고 구매 주문서의 200개와 매칭합니다. 매칭은 깨끗해 보입니다. 그러나 그중 80개는 프로젝트 마감일 이후에 도착했고, 사용되지 않은 채로 남아 있었으며, 가격 조정으로 협상되었어야 했습니다.

分納은 일본 조달에서 매칭 오류의 가장 흔한 원인입니다, 그리고 납품서가 포장 상자 안에 종이로 도착할 때 더욱 악화됩니다 — 회계가 아닌 창고에서 추적되기 때문입니다. 청구서가 지급 담당 부서에 도착할 때쯤, 두 건의 납품서는 서로 다른 서류 더미에 있거나, 다른 해상도로 스캔되었거나, 단순히 분실되었을 수 있습니다. 매칭이 실패하는 이유는 데이터가 잘못되었기 때문이 아니라 두 개의 물리적 문서에 분산되어 있어 어떤 시스템도 연결하지 못하기 때문입니다.

2. 소비세율 변경 — 청구서의 세율이 구매 주문서의 세율과 다른 경우

일본의 소비세(消費税, shōhizei)는 2019년 10월 인상 이후 시행된 2단계 체계로, 표준 세율 10%와 식품·음료에 대한 경감 세율 8%로 구성됩니다. 적용되는 세율은 구매 주문서 작성일이 아닌 납품일을 기준으로 결정됩니다. 8% 세율로 9월에 발주되었으나 세율이 10%로 변경된 10월에 상품이 납품된 경우, 청구서에는 법적으로 10% 세율이 반영되어야 합니다. 구매 주문서에는 여전히 8%로 표시되어 있습니다. 두 문서의 합계는 결코 일치하지 않으며 — 그 차이는 오류가 아니라 세법입니다.

세율 변경 시점이 아니더라도, 서로 다른 세율이 적용되는 품목이 혼재된 경우 — 사무용품(10%)과 포장 식품(8%)의 혼합 납품 — 청구서 합계를 구매 주문서 합계와 기계적으로 비교하려면 두 문서를 품목별로 분해해야 합니다. 수동 AP 팀은 이러한 분해를 생략하고 합계만 확인하는 경우가 많으며, 그 결과 소비세 오분류는 세무 조사에서 적발되기 전까지 감지되지 않은 채 통과됩니다.

3. 구매 주문서와 청구서 간 상이한 지급 조건

일본의 B2B 지급 조건은 정밀하면서도 오독하기 쉬운 관례를 따릅니다: 결제일(締日, shimebi)과 지급 기간의 조합입니다. 대표적인 조건은 20일締め翌月末払い — "매월 20일까지의 거래분을 익월 말까지 지급"입니다. 구매 주문서에는 하도급법에 따라 이 조건이 명시적으로 기재됩니다. 그러나 공급업체의 청구 시스템이 기본값으로 10일締め翌々月末払い — 다른 결제일과 다른 지급 기간을 사용할 수 있습니다. 공급업체의 청구서에 기재된 지급 기한이 구매 주문서의 조건과 일치하지 않는 경우, 해당 청구서는 기술적으로 부적합하며, 공급업체가 명시한 조건대로 지급할 경우 계약상 요구되는 것보다 한 달 일찍 현금을 지출하게 될 수 있습니다.

지급 조건에 대한 매칭 확인은 AP 담당자가 두 문서의 짧은 텍스트 필드를 읽고 비교해야 하는 작업으로, 조건이 숫자가 아니기 때문에 VLOOKUP으로 자동화할 수 없습니다. 실제로 대부분의 수동 매칭 워크플로우는 수량과 합계에 집중하고 이 확인을 완전히 생략합니다. 지급 조건 검증을 생략하면 중견 제조업체는 월 지급액의 약 2-3%를 불필요한 조기 현금 유출로 손실합니다 — 일본 중소기업을 대상으로 하는 조달 컨설턴트에 따르면, 이 자금은 구매자가 아닌 공급업체 계좌에 한 달간 머물며 모든 거래에 걸쳐 배가됩니다.

4. 누락된 문서 — 3개 중 하나가 존재하지 않는 경우

모든 공급업체 거래가 깔끔한 3개 문서 흔적을 생성하는 것은 아닙니다. 전화 주문, 기존 거래처에 보내는 LINE 메시지, 부서장이 구두로 승인한 긴급 구매 — 이러한 거래는 구매 주문서가 누군가의 기억 속에만 존재하는 상황을 만듭니다. 일본의 중소기업에서는 발주서 문화가 실제 운영보다는 이상에 가깝습니다. 중소기업청(中小企業庁)의 2023년 조사에 따르면 10만 엔 미만의 중소기업 거래 중 40% 이상이 공식 구매 주문서 없이 이루어졌습니다. 이러한 거래의 매칭 프로세스는 구매 주문 번호가 없는 납품서와 주문 날짜가 참조되거나 참조되지 않을 수 있는 청구서에서 시작됩니다.

문서 하나가 누락된 경우, AP 팀은 두 가지 선택에 직면합니다. 문서 흔적을 재구성하는 동안 지급을 지연하거나, 2자 대사에 따라 승인하고 위험을 수용하는 것입니다. 대부분은 후자를 선택합니다 — 태만 때문이 아니라, 대안이 이미 생산 라인에 있는 공급업체에 대한 지급을 보류하는 것을 의미하기 때문입니다. 그 결과 회사의 내부 통제 프레임워크 — 3자 대사의 바로 그 목적 — 는 3개 문서가 모두 우연히 존재하는 거래 하위 집합에만 적용됩니다.

스프레드시트 함정 — Excel이 문제를 더 작게 만들지 않고 더 조용하게 만드는 이유

매칭 혼란에 대한 표준 대응은 스프레드시트입니다. ERP에서 구매 주문서 데이터를 내보냅니다. 납품서 데이터를 두 번째 시트에 수동으로 입력합니다. 공급업체 PDF에서 청구서 데이터를 가져옵니다. 구매 주문 번호에 VLOOKUP을 작성합니다. 불일치 항목을 표시합니다. 일치 항목을 승인합니다. 다음으로 넘어갑니다.

이 워크플로는 작동합니다 — 결국 지급할 거래 목록을 생성한다는 의미에서 말입니다. 그러나 스프레드시트가 복잡성을 해결하지 않고 흡수한다는 점에서 실패합니다. 구매 주문 번호에 대한 VLOOKUP은 구매 주문 번호가 3개 문서 모두에 동일하게 나타나는 경우에만 작동합니다. 실제로 구매 주문 번호 필드는 가장 신뢰할 수 있는 식별자입니다 — 그럼에도 공급업체의 청구 시스템이 구매 주문 번호를 잘라내거나, 부서 코드 접두사를 추가하거나, 납품서가 다른 시스템에서 포장 명세서를 인쇄했기 때문에 구매 주문 번호를 포함하지 않는 경우에는 실패합니다.

하지만 구매 주문 번호는 쉬운 필드입니다. 실제 스프레드시트 함정은 품목 수준 매칭입니다. 구매 주문서에 "SUS304 M8×30 六角ボルト"로 설명된 볼트가 납품서에는 "ステンレスボルト M8×30"으로, 청구서에는 "部品コード BT-0842 六角穴付ボルト M8 L=30"으로 나타납니다. 3개 모두 동일한 물리적 품목을 설명합니다. 그러나 텍스트로는 일치하지 않습니다. VLOOKUP은 #N/A를 반환하고 AP 담당자는 3개 문서를 열어 동일한 볼트인지 육안으로 확인해야 합니다 — 품목당 90초가 소요되며, 월간 청구서에는 400개의 품목이 있습니다.

스프레드시트는 실패하지 않습니다. 오히려 팀이 대사가 완료되었다고 믿게 만듭니다. 실제로는 모든 #N/A 뒤에 조사가 필요한 실제 불일치 또는 명명 불일치로 인한 거짓 불일치가 숨어 있습니다. 시간이 지나면서 팀은 대사 기준을 낮추는 방식으로 적응합니다. 발주 번호와 총액만 대사하고 품목별 확인은 건너뛰며 큰 불일치만 표시하는 방식입니다. 이러한 적응은 합리적입니다. 대안은 처리되지 않은 청구서의 무한 대기열이기 때문입니다. 그러나 이는 3자 대사가 실제로는 1.5자 대사로 격하되었음을 의미하며, ACFE 추정에 따르면 조직은 연간 수익의 약 5%를 사기로 인해 손실하며, 그 상당 부분이 취약한 청구서 통제를 통과합니다.

PO 데이터를 스프레드시트에 넣는 방법에 대한 자세한 안내는 일본 구매 주문서 데이터를 Excel로 추출 가이드를 참조하십시오. 이 허브 문서는 発注書의 필드별 구조와 각 필드를 구조화된 행으로 변환하는 방법을 다룹니다. 일괄 처리 측면에서는 50개 공급업체 PO를 단일 조달 대시보드로 일괄 처리에서 월간 업무를 구조적 병목으로 바꾸는 확장 차원을 다룹니다. 데이터가 스프레드시트에 들어간 후의 전체 Excel 대사 워크플로우는 제조업에서 공급업체 청구서를 PO에 대사하는 가이드를 참조하십시오.

의미 기반 추출이 매칭 방정식을 바꾸는 이유

스프레드시트 접근 방식은 데이터가 이미 구조화되어 있다고 가정합니다. 즉, "발주 번호", "품목명", "단가"가 데이터베이스에 깔끔한 필드로 존재한다고 전제합니다. 실제 출발점은 각각 다른 레이아웃과 용어를 가진 세 개의 PDF이며, 경우에 따라 종이 납품서의 스캔본 하나가 포함될 수 있습니다. 매칭이 이루어지기 전에 누군가는 그 PDF들을 행과 열로 변환해야 합니다. 바로 그 변환 단계가 실제 병목이 발생하는 지점입니다.

기존 OCR 도구는 페이지에서 각 필드의 위치를 식별하여 변환을 시도합니다. "발주 번호는 위에서 3cm, 왼쪽에서 4cm 지점에 있다"는 방식으로, 공급업체 형식별로 정의해야 하는 영역 템플릿이나 레이아웃이 바뀌면 작동이 중단되는 규칙 기반 파서를 사용합니다. 이 접근 방식은 구조적인 이유로 매칭 문제에서 실패합니다. 세 문서의 레이아웃이 완전히 다르기 때문입니다. 발주 번호는 발주서 PDF의 헤더 박스에 있고, 납품서에는 아예 나타나지 않을 수 있으며, 청구서에서는 참조 번호 필드에 있습니다. 발주서 레이아웃에 맞춰 작성된 위치 기반 추출 규칙은 청구서 레이아웃에는 무용지물입니다.

의미 기반 추출 — 맞춤 열 추출이 가능하게 하는 접근 방식 — 은 논리를 뒤집습니다. 각 문서에서 각 필드가 어디에 있는지 정의하는 대신, 원하는 것이 무엇인지 정의합니다. "발주 번호"라는 열, "품목명"이라는 열, "수량"이라는 열을 정의하는 것입니다. AI는 각 문서를 읽고 값이 페이지의 어디에 나타나든, 어떻게 표시되든 그 의미를 이해하여 값을 찾습니다. 박스형 헤더에 발주 번호가 있는 팩스로 받은 구매 주문서와 동일한 번호가 "ご注文番号" 필드에 있는 PDF 청구서는 모두 동일한 열을 반환합니다. AI가 좌표가 아닌 의미를 기준으로 매칭하기 때문입니다.

이로써 매칭 워크플로우는 "세 문서를 서로 다른 세 개의 스프레드시트로 변환한 후 대사한다"에서 "세 문서를 모두 동일한 열 구조로 추출한 후 비교한다"로 전환됩니다. 비교 단계는 진정한 스프레드시트 작업이 됩니다. 발주 번호 열에서 조회하면 실제로 일치 항목이 반환되는데, 그 열이 각 문서의 의미를 이해한 AI에 의해 채워졌기 때문이지, 각 문서의 내용을 필사한 사람에 의해 채워졌기 때문이 아닙니다.

이와 동일한 구조적 문제 — 동일한 재무 현실을 설명하지만 호환되지 않는 형식으로 작성된 문서 간의 수동 대사 — 는 일본 외의 다른 맥락에서도 나타납니다. 호주 BAS 신고 수동 대사 문제에 대한 분석에서는 분기별 GST 데이터를 은행 거래 내역, 청구서, ATO 양식 간에 대사해야 할 때 중소기업이 유사한 과제에 직면하는 방식을 살펴봅니다. 이는 또한 전 세계 제조업 AP에서 3자 매칭 실패율을 높이는 동일한 원인입니다. 3자 매칭이 제조업 AP에 팀이 인정하는 것보다 더 큰 타격을 주는 이유를 참조하십시오.

FAQ

3자 대사(三点照合)란 무엇이며, 일본 조달에서 왜 필요한가요?

3자 대사(三点照合)는 구매 주문서(発注書, hatchūsho), 납품서(納品書, nōhinsho), 청구서(請求書, seikyūsho)를 상호 대조하여 주문, 납품, 청구된 내역이 모두 동일한 거래를 설명하는지 확인합니다. 일본 공정거래위원회(JFTC)의 하도급법(下請代金支払遅延等防止法)은 하청업체에 발행되는 모든 구매 주문서에 특정 항목을 요구하며, 이 대사 과정은 초과 지급, 중복 지급, 미납품 대금 지급을 방지하는 핵심 내부 통제 수단입니다.

데이터가 정확한데도 구매 주문서-청구서 대사가 실패하는 이유는 무엇인가요?

문서마다 동일한 품목에 대해 서로 다른 식별자를 사용하기 때문입니다. 예를 들어, 동일한 스테인리스 볼트가 구매 주문서에는 "SUS304 M8×30", 납품서에는 "ステンレスボルト M8", 청구서에는 "BT-0842"로 표시될 수 있습니다. 데이터 자체는 모두 동일한 물리적 품목을 설명하므로 정확하지만, VLOOKUP과 같은 텍스트 기반 대사 도구는 문자열이 다르기 때문에 불일치를 반환합니다. 분할 납품(分納), 소비세율 차이(消費税), 지급 조건 불일치가 이 문제를 더욱 악화시킵니다.

공급업체의 문서 형식을 변경하지 않고 3자 대사를 자동화할 수 있나요?

가능합니다. 핵심은 위치 기반이 아닌 의미론적으로 데이터를 추출하는 것입니다. 추출 엔진이 "구매 주문서 번호를 가져와" 및 "품목명을 가져와"를 열 정의로 읽으면, 레이아웃이나 레이블링과 관계없이 각 문서에서 해당 질문에 답하는 값을 검색합니다. 공급업체는 기존 형식을 계속 사용하며, 추출 단계에서 출력을 일관된 열 구조로 정규화하고, 대사는 이 정규화된 데이터를 기반으로 수행됩니다.

세 문서 중 하나가 누락되면 어떻게 되나요?

이는 실제 업무에서 가장 흔한 시나리오입니다. 전화 주문, LINE 메시지, 구두 승인은 공식 구매 주문서 없이 거래를 생성합니다. 문서가 누락된 경우, 많은 미지급금(AP) 팀은 기본적으로 2자 대사를 수행합니다. 이는 더 빠르지만 검증 단계 하나를 제거합니다. 가장 좋은 완화 방법은 문서 생성을 최대한 간편하게 만드는 것입니다. 조달 관리자가 수기 주문 메모를 스캔하여 공식 구매 주문서와 동일한 구조화된 형식으로 추출할 수 있다면, 공식 절차가 없었더라도 문서 흔적이 남게 됩니다.

소비세(消費税)만이 세금 관련 매칭 문제인가요?

소비세는 세율이 10%와 8%로 이원화되어 있어 단일 청구서에 서로 다른 세율이 적용된 항목이 포함될 수 있기 때문에 세금 불일치의 가장 흔한 원인입니다. 하지만 이것만이 유일한 문제는 아닙니다. 수입 물품과 관련된 거래에는 선적 서류에는 나타나지만 구매 주문서에는 없는 관세(関税)가 발생합니다. 일본 기업의 글로벌 공급망 내에서 이루어지는 국경 간 거래에는 이전 가격 조정이 수반되어 원래 구매 주문서에 해당 항목이 없음에도 청구서 총액에 영향을 미칠 수 있습니다.

이는 기업용 ERP 시스템이 이미 처리하는 방식과 어떻게 다른가요?

SAP Japan이나 OBIC7과 같은 기업용 ERP는 3자 대사 모듈을 제공하지만, 대사가 이루어지기 전에 데이터가 시스템 내에 있어야 합니다. 문제는 데이터 입력 단계에 있습니다. SAP의 대사 엔진은 이메일 받은 편지함에 PDF로 저장된 청구서를 대사할 수 없습니다. ERP는 비교를 자동화할 뿐, 비정형 문서에서 데이터를 추출하는 작업은 자동화하지 않습니다. 이미 ERP를 보유한 기업의 경우, 병목 현상은 대사 모듈보다 상류인 납품서와 청구서 데이터를 ERP에 입력하는 단계에서 발생합니다.