Google Sheets에서 3-way 매칭 워크플로우 구축 방법:PO부터 인보이스 승인까지 단계별

우리는 제조업에서 3-way 매칭이 실패하는 이유를 분석했으며, 병목이 매칭 알고리즘이 아니라 그 앞 단계인 데이터 추출 단계에 있음을 확인했습니다. Ardent Partners의 2025 AP 벤치마크에 따르면 평균 1차 불일치율은 22%이며, 제조업에서는 블랭킷 PO, 부분 선적, 선적장과 인보이스 간 측정 단위 불일치로 인해 그 수치는 더 높아집니다. 진단은 분명합니다. 두 문서가 여전히 비정형 PDF에 갇혀 있다면 세 문서를 매칭할 수 없습니다. 이 기사가 답하는 질문은: 실제로 무엇을 구축해야 문제를 해결할 수 있으며, ERP 없이도 구축할 수 있는가입니다. 기반은 매칭 공식이 실행되기 전에 각 문서를 깨끗한 행으로 변환하는 반복 가능한 PDF를 Google Sheets로 추출 단계입니다.

이것은 구축 가이드입니다. Google Sheets 파이프라인의 네 가지 추출 및 매칭 레이어를 단계별로 안내합니다 — 정의할 열, 작성할 수식, 그리고 공급업체가 수집 링크를 통해 문서를 직접 제출하는 방법. 대신 조정 프레임워크를 찾고 있다면 — 허용 오차 규칙, 자동 매칭 영역, 검토 중 모호한 품목명 처리 방법 — ERP 없이 Google Sheets에서 3-way 매칭에 대한 동반 가이드를 참조하세요.

문서 데이터를 Google Sheets로 바로 가져오기
사이드바에서 AI 추출 — 데이터가 스프레드시트에 입력됩니다
Sheets에 추가 →
기사 제목과 세 가지 플랫 아이콘이 포함된 블로그 히어로 이미지: 모든 인보이스 형식을 읽기 위한 돋보기가 있는 문서, PO 번호에 대한 VLOOKUP 키, 그리고 차이를 표시하는 호박색 플래그가 있는 테이블 행

핵심 요약

  1. 22%의 1차 불일치율은 알고리즘 문제처럼 보이지만, 데이터 추출 단계에서 시작됩니다.
  2. AP 팀의 66%는 여전히 인보이스 데이터를 ERP에 수동으로 입력하므로, 누군가 입력을 마치는 동안 매칭 모듈은 유휴 상태입니다.
  3. ImageToTable.ai의 열 이름 추출은 사전 구성된 템플릿 없이 모든 공급업체의 형식을 읽어, 세 부서가 조사하던 일을 VLOOKUP과 초록색 셀로 바꿔줍니다.

3방 매칭이 실제로 요구하는 것 — 허용 오차 한도 그 이상

3방 매칭은 구매 주문서, 입고 확인서, 공급업체 청구서를 지불 승인 전에 비교하여 주문한 품목이 실제로 입고되고 청구된 것과 일치하는지 확인하는 프로세스입니다. ISO 9001:2015 8.4항에 따라 인증된 제조업체는 구매한 제품이 지정된 요구사항을 충족하는지 확인해야 하며, 대부분의 기업은 3방 매칭을 통해 이를 이행합니다. ACFE 2024 국가 보고서는 조직이 연간 수익의 5%를 업무상 사기로 손실한다고 추정하며, 3방 매칭을 청구 사기 방지 핵심 통제 수단으로 지목합니다. 규제 논리는 타당합니다. 그러나 그 이면의 데이터 문제가 실제로 시스템을 무너뜨립니다.

3방 매칭 개선에 관한 대부분의 조언은 매칭 계층에 초점을 맞춥니다: 허용 오차 한도 강화, 승인 워크플로 추가, ERP에서 자동 매칭 규칙 구성. 그러나 이 중 어느 것도 세 문서가 서로 다른 세 시스템에서 각기 다른 형식으로 도착하며, 그중 두 개는 비정형이라는 근본 문제를 해결하지 못합니다. 구매 주문서는 조달 시스템에 있습니다. 입고 확인서는 종이 포장 명세서에서 입력되었을 수도 있고 아닐 수도 있습니다. 공급업체 청구서는 PDF로 도착합니다. 매칭 로직이 이 문서들을 비교하려면, 먼저 정형화되지 않은 두 문서에서 데이터를 추출하여 비교 가능한 형식으로 입력하고, 단위와 라인 항목이 일치하기를 기대해야 합니다. 매칭 계층(VLOOKUP, IF문, 조건부 서식)은 쉬운 부분입니다. 데이터 추출 계층이 파이프라인의 성패를 좌우합니다.

작동하는 3방 매칭 파이프라인은 더 나은 매칭 규칙에서 시작하지 않습니다. 세 문서를 모두 동일한 스프레드시트의 동일한 정형 형식으로 만드는 것에서 시작합니다. 일단 그렇게 되면 매칭은 수식 문제일 뿐입니다. 어려운 부분은 그 상태로 만드는 과정입니다.

ERP 조언이 스프레드시트 워크플로우에 맞지 않는 이유

SAP의 MM 모듈, Oracle E-Business Suite, Microsoft Dynamics 365 — 모두 구성 가능한 허용 오차를 갖춘 3자 매칭 모듈을 포함합니다. 예를 들어 SAP는 GR/IR 정산 계정을 통해 매칭을 처리합니다: 자재 수령(트랜잭션 MIGO)은 차변을 게시하고, 송장 수령(MIRO)은 대변을 게시하며, 시스템은 일치하는 라인 항목을 자동으로 정산합니다. 이 로직은 성숙하고 잘 문서화되어 있습니다.

AP 팀의 66%가 여전히 ERP에 송장 데이터를 수동으로 입력한다는 66%를 보여주는 사각형 숫자 카드와, 그 격차가 매칭 이전 단계에 있다는 호박색 경고 배지

이 로직은 또한 상당수의 조달 운영에서 사실이 아닌 것을 가정합니다: 매칭 로직이 실행되기 전에 세 문서 모두 ERP 내부에 구조화되고 비교 가능한 데이터로 존재한다는 것입니다. 2025 IFOL AP 자동화 동향 조사에 따르면 AP 팀의 66%가 여전히 ERP에 송장 데이터를 수동으로 입력합니다. 50~200개 공급업체와 공급업체 관계를 관리하는 조달 팀 — 그중 다수는 이메일로 PDF를 보내는 소규모 기계 공장, 지역 유통업체, 전문 공급업체입니다 — 매칭이 시작되기 전에 모든 송장이 수동 데이터 입력 이벤트입니다.

그 그룹에 속한다면 — 회사가 스프레드시트로 조달을 운영하거나, ERP의 송장 캡처에 유지 관리할 대역폭이 없는 공급업체별 템플릿 구성이 필요하거나, 공급업체 기반에 PDF만 보내는 소규모 공급업체가 충분히 포함되어 있기 때문이든 — ERP의 매칭 모듈은 실제로 가지고 있는 문제의 하류에 있는 문제를 해결하고 있습니다. 더 나은 매칭 알고리즘이 필요하지 않습니다. PO 데이터, 수령 데이터, 송장 데이터를 하나의 구조화된 보기로 가져올 방법이 필요합니다 — 그리고 조달 추적에 이미 사용하는 도구는 스프레드시트일 가능성이 높습니다. 문제는 그 스프레드시트를 파이프라인으로 전환하는 방법입니다.

문서 데이터를 Google Sheets로 바로 가져오기
사이드바에서 AI 추출 — 데이터가 스프레드시트에 입력됩니다
Sheets에 추가 →

3계층 파이프라인 아키텍처

PO 레지스터, 수령 데이터, 인보이스 추출, 그리고 행이 주황색으로 표시된 매칭 대시보드를 화살표로 연결한 4단계 플로우 다이어그램

파이프라인은 3-way 매칭의 각 문서에 해당하는 3개 레이어와, 그 위에 위치하는 4번째 레이어인 매칭 대시보드로 구성됩니다. 처음 3개 레이어는 비정형 문서에서 정형 데이터를 추출하고, 4번째 레이어는 이를 비교합니다. 처음 3개 레이어 중 하나라도 일관되지 않거나 불완전한 데이터를 생성하면 매칭 레이어는 제 역할을 할 수 없습니다.

1
PO 추출 — 구매 주문 데이터(PO 번호, 공급업체, 라인 항목, 수량, 단가, 납기일)를 정형화된 PO 레지스터 탭으로 추출합니다. 이는 기준 레이어로, 모든 매칭이 이 데이터를 기준으로 참조합니다.
2
수령 데이터 — 포장 명세서와 수령 로그의 상품 수령 정보: 수령 수량, 수령 날짜, 운송업체 정보, 상태 메모. 수동 입력 또는 스캔 문서에서 추출합니다.
3
인보이스 추출 — AI로 추출한 공급업체 인보이스 데이터: 인보이스 번호, PO 참조, 라인 항목 수량, 단가, 라인 합계, 추가 요금, 운임, 인보이스 총액. 공급업체 형식과 관계없이 동일한 열 구조를 사용합니다.
4
매칭 대시보드 — PO 데이터, 수령 데이터, 인보이스 데이터를 하나의 뷰로 통합하는 탭. PO 번호 기준 VLOOKUP. 수량 및 가격 차이에 대한 IF 문. 불일치를 표시하는 조건부 서식. 부서 간 조사가 필요 없습니다.

각 레이어는 구매-결제 체인에서 특정 공백을 메웁니다. PO 레이어는 기준선(무엇을, 어떤 가격에, 누구에게서 주문했는지)을 설정합니다. 수령 레이어는 실제로 도착한 물품을 확인합니다. 인보이스 레이어는 공급업체가 청구한 금액을 포착합니다. 매칭 대시보드는 세 가지가 모두 수렴되는 지점이며, 스프레드시트가 문제 분석에서 전통적 매칭 워크플로의 구조적 약점으로 지목된 3개 부서 간 조사를 대체하는 곳입니다.

레이어 1과 3에서 비정형 데이터를 정형 데이터로 변환하는 핵심 기능은 맞춤 열 추출입니다. 각 문서의 필드 주변에 박스를 그리거나 공급업체 형식별로 템플릿을 만들 필요 없이, "PO 번호", "공급업체 이름", "품목", "수량", "단가", "라인 합계" 등 원하는 열 이름을 입력하면 AI가 문서를 읽고 해당 값이 페이지에서 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 찾아냅니다. SAP PDF 출력물의 정형화된 PO와 지역 공급업체의 수기 PO는 전혀 다르게 보입니다. 하지만 둘 다 PO 번호, 공급업체 이름, 수량, 가격을 포함합니다. 열 이름 추출은 모든 레이아웃에서 해당 필드의 의미를 검색하므로, 다양한 공급업체 문서 형식을 처리해야 하는 조달 팀에게 템플릿 기반 OCR을 비현실적으로 만드는 공급업체별·형식별 템플릿 유지보수를 제거합니다.

레이어 1 — 구매 주문 추출: 기준 기준선

모든 3자 매칭은 구매 주문에서 시작됩니다. PO는 어떤 공급업체, 어떤 품목, 어떤 수량, 어떤 가격, 언제 배송인지 등 조건을 설정합니다. ERP 통합 환경에서는 이 데이터가 이미 정형화된 라인 항목으로 존재합니다. PO가 시스템에서 생성되었기 때문입니다. 그러나 스프레드시트 기반 조달 워크플로에서는 PO가 여러 형태로 도착합니다. 구매자 자체 시스템에서 생성된 PDF, 주문을 확인하는 공급업체의 이메일 PO, 또는 종이로 운영하는 소규모 공급업체의 스캔 문서 등입니다. PO 데이터를 정형 형식으로 만드는 것이 첫 단계이며, 스프레드시트 기반 팀에게는 이후 파이프라인이 가능한지 여부를 결정하는 단계입니다.

PO의 추출 열은 매칭 프로세스가 참조해야 하는 항목에 따라 달라집니다. 최소한 다음이 필요합니다:

열캡처 내용매칭에 중요한 이유
PO 번호고유 PO 식별자핵심 필드 — 모든 입고 보고서와 송장이 매칭을 위해 이를 참조해야 함
공급업체 이름PO에 표시된 공급업체 이름송장의 공급업체와 교차 참조 — 동일 공급업체인지 확인
품목품목 설명, SKU 또는 부품 번호입고 및 송장 라인 항목과 매칭하여 품목별 비교
수량라인별 주문 수량입고 수량 및 송장 수량과 비교
단가라인별 합의된 단가가격 차이 확인 — 가장 흔한 감사 플래그
라인 합계라인별 수량 × 단가송장 라인 합계와 비교 — 확장 오류 포착
배송 날짜예상 배송 날짜입고 날짜 확인 및 지연 배송 플래그 지정에 사용
PO 합계모든 라인 합계의 총합설명 없이 송장이 초과해서는 안 되는 총액

내부적으로 일관된 형식으로 생성된 구매 주문서(자사 PO 템플릿)의 경우 추출이 간단합니다. AI가 매번 동일한 일반 레이아웃에서 동일한 필드를 읽습니다. 공급업체 확인 PO가 공급업체 형식으로 도착하는 경우 추출이 적응합니다. 열 이름은 동일하게 유지되고 AI는 레이아웃과 관계없이 값을 찾습니다. 단일 추출 실행으로 PO 레지스터 탭에 구조화된 데이터가 채워집니다. 매칭을 위해 헤더 수준 또는 라인 항목 수준 세분화 중 원하는 방식에 따라 PO당 한 행 또는 라인 항목당 한 행으로 표시됩니다. Google Sheets 애드온을 사용한 단일 PO 추출 가이드에서는 열 설정과 첫 번째 추출 워크플로우를 안내합니다. 한 번에 수십 개의 PO를 처리하는 대규모 팀의 경우 일괄 PO 처리 대시보드가 단일 세션에서 여러 PO에 동일한 추출 엔진을 적용합니다.

JPG/PNG/PDF AI 추출

파일은 안전하게 처리되며 저장되지 않습니다.

위 데모는 PO 문서용으로 사전 구성된 추출 열 세트인 구매 주문 프리셋을 사용합니다. 구매 주문서를 업로드하면 입력 없이 필드가 채워지는 것을 확인할 수 있습니다. PO에 프리셋이 다루지 않는 필드(상품 할증 라인, 운임 조건 섹션, 내부 원가 센터 코드)가 포함된 경우 맞춤 열로 추가하면 추출 엔진이 동일한 방식으로 처리합니다. 프리셋은 시작점을 제공합니다. 맞춤 열은 매칭 대시보드의 요구 사항에 맞게 확장합니다.

레이어 2 — 수령 보고 데이터 수신: 까다로운 중간 문서

입고 확인서는 구조화된 시스템에서 가장 누락되기 쉬운 문서이며, 3자 매칭을 3자 프로세스로 만드는 문서입니다. 수령 확인이 없으면 2자 매칭(구매 주문서 대비 송장)만 수행하게 되며, 배송이 확인되지 않은 상품에 대해 비용을 지불하게 됩니다. ACFE는 구매 주문서와 송장 매칭에서 입고 확인서를 청구 사기(배송되지 않은 상품에 대한 지불)를 방지하는 통제 수단으로 명시합니다. 이를 건너뛰는 것은 지름길이 아닙니다. 통제 프레임워크의 공백입니다.

수령 데이터는 생성 방식 때문에 PO 데이터보다 구조화하기 어렵습니다. 데이터는 부두에서, 종종 종이로, 트럭 하역이 우선순위인 직원에 의해 생성되며, 데이터 입력은 그 다음입니다. 포장 명세서는 일반적으로 다중 부분 카본지 양식 또는 운송업체의 감열 인쇄 문서입니다. 수령 담당자가 서명하고, 수령 수량(PO와 다른 단위로 기록되는 경우도 있음)을 기록한 후 물리적 사본을 보관합니다. 이 데이터가 디지털 시스템에 입력되는지 여부는 사후에 누군가 입력하는지에 달려 있으며, 이 단계는 바쁜 수령일에는 가장 먼저 건너뛰는 단계입니다.

파이프라인의 경우 수령 데이터에는 두 가지 실행 가능한 입력 경로가 있습니다. 첫 번째는 직접 수동 입력입니다. 수령 담당자 또는 지정된 데이터 입력 담당자가 수령 워크플로우의 일부로 핵심 필드를 Google 시트에 입력합니다. 열은 PO 열을 반영합니다: PO 번호(연결용), 수령 품목, 수령 수량, 수령 날짜, 운송업체, 상태. 이 경로는 수령 물량이 적당하고(일일 30건 미만) 부두에서 시트가 열린 기기에 접근할 수 있을 때 작동합니다. 장점은 통제입니다. 수령 데이터는 입력 시점부터 구조화되어 다운스트림 변환이 필요 없습니다.

두 번째 경로는 포장 명세서 자체에서 문서 추출입니다. 서명된 포장 명세서의 사진이나 스캔을 찍어 PO 및 송장에 사용된 것과 동일한 추출 엔진으로 처리합니다. 이 경로는 수동 입력이 불가능한 경우(대량 수령 부두, 원격 수령 위치, 또는 포장 명세서가 유일한 수령 기록인 운영)에 작동합니다. 추출 열은 동일합니다: PO 번호, 품목 설명, 수령 수량, 수령 날짜, 운송업체. 사이드바 애드온을 통해 처리된 포장 명세서의 휴대폰 사진은 수동 입력 데이터와 동일한 구조화된 형식으로 수령 탭을 채웁니다. 주요 제한 사항: 포장 명세서의 손글씨는 인쇄된 PO 및 송장에 비해 추출 정확도를 떨어뜨립니다. 중요 화물에 대해서는 표본 검사가 권장됩니다. 문서 품질별 정확도 분석에 대한 자세한 내용은 손글씨 문서 추출 정확도 가이드를 참조하세요. 동일한 원칙이 포장 명세서 및 수령 보고서에 적용됩니다.

어떤 경로를 사용하든 결과는 동일합니다. 모든 수령을 해당 구매 주문서에 연결하는 핵심 필드로 PO 번호가 있는 수령 등록 탭이 생성됩니다. 이 연결이 없으면 매칭 대시보드가 제 역할을 할 수 없습니다.

레이어 3 — 공급업체 인보이스 추출: 통제할 수 없는 형식 문제

공급업체 인보이스는 형식 다양성 문제가 가장 극심해지는 영역입니다. 단일 조달 운영에서도 대형 MRO 유통업체의 구조화된 SAP 생성 PDF, 지역 금속 공급업체의 자체 제작 Excel-to-PDF 형식, 지역 기계 공장의 촬영된 수기 문서, 날짜 형식·통화 규칙·세금 항목 구조가 다른 해외 공급업체의 인보이스를 받을 수 있습니다. 공급업체별 레이아웃에 필드 매핑 템플릿을 만들고 레이아웃이 바뀔 때마다 업데이트해야 하는 템플릿 기반 OCR은 이러한 다양성 앞에서 무너지거나, 유지보수 시간이 너무 많이 소요되어 추출 작업이 대체하려던 수작업 입력과 맞먹게 됩니다.

맞춤 열 추출은 추출 로직을 특정 레이아웃에서 분리하여 이 문제를 해결합니다. 열 이름은 한 번만 정의하면 됩니다. AI는 형식과 관계없이 각 인보이스를 읽고 해당 열 정의와 일치하는 값을 찾습니다. 3자 매칭을 위한 인보이스 열 구성에는 일반적으로 다음이 포함됩니다:

열출처매칭 역할
인보이스 번호인보이스에서 추출고유 식별자 — 중복 지불 방지
PO 번호인보이스에서 추출핵심 연결 필드 — 매칭이 작동하려면 PO 등록 탭의 PO와 일치해야 함
공급업체 이름인보이스에서 추출PO 공급업체와 교차 확인 — 잘못된 PO 참조 오류 포착
인보이스 날짜인보이스에서 추출지불 조건 계산, 노후화 분석
납기일인보이스에서 추출조기 지불 할인 기간 추적
품목 설명인보이스에서 추출PO 품목과 매칭 — 주문한 상품과 동일한 상품이 청구되었는지 확인
수량인보이스에서 추출PO 수량 및 수령 수량과의 차이 검증
단가인보이스에서 추출PO 단가와의 차이 검증 — 가격 인상 감지
품목 합계인보이스에서 추출확장 검증 — 인보이스 자체에서 수량 × 단가 = 품목 합계 확인
인보이스 합계인보이스에서 추출허용 오차 범위 내 PO 합계와의 총액 매칭, 지불 승인 트리거

또한 추론 열을 추가할 수 있습니다. 추론 열은 인보이스에 명시적으로 인쇄되지는 않았지만 문맥에서 파생할 수 있는 데이터를 캡처하는 열입니다. 예를 들어, Match Status (options: Ready to Match/Needs PO Reference/Missing Line Items)로 정의된 열은 AI가 PO 번호를 찾았는지, 라인 항목을 추출할 수 있었는지에 따라 추출 중 각 인보이스를 분류할 수 있게 합니다. 문서에 PO 번호를 포함하지 않는 공급업체로부터 도착한 인보이스는 즉시 플래그가 지정되어 "Needs PO Reference" 상태로 매칭 대시보드에 들어가며, AP 담당자는 PO 번호가 추가될 때까지 매칭을 시도하지 않아야 함을 알게 됩니다. 이는 추출로서의 분류입니다. 분류 결정은 데이터를 채우는 동일한 패스에서 이루어지며, 별도의 검토 단계에서 이루어지지 않습니다.

계산 열은 추출 후 스프레드시트 수식이 필요했을 수학을 처리합니다. 열을 Extension Check (Line Total - Quantity * Unit Price)로 정의하면 AI가 추출 중 계산을 수행하여 인보이스의 라인 합계가 수량 곱하기 단가와 일치하지 않는 모든 라인에 플래그를 지정합니다. 출력은 분산 값입니다. 0이면 확장이 올바르다는 뜻이고, 0이 아닌 값은 공급업체 인보이스의 산술 오류를 식별합니다. 이는 매칭 대시보드의 역할을 "오류 찾기"에서 "플래그가 지정된 행 검토"로 전환합니다. AI가 감지를 수행하고 사람이 처분을 수행하는 워크플로우입니다. 계산 열 구문과 기능에 대한 전체 설명은 문서 추출의 계산 열 가이드를 참조하세요.

형식 차이는 수식이 실행되기 전에 잘못된 분산을 유발합니다. 한 공급업체는 인보이스 날짜를 05/06/2026으로 기재하고, 다른 공급업체는 06/05/2026으로 기재하며, 동일한 부품 번호가 한 문서에서는 앞에 0이 있고 다음 문서에서는 없을 수 있습니다. 추출 레이어는 각 행을 작성할 때 날짜와 식별자에 일관된 출력 형식을 적용하므로 대시보드에서 플래그가 지정된 불일치는 형식 문제가 아닌 실제 불일치를 반영합니다.

3자 매칭 파이프라인을 구동하는 동일한 인보이스 추출 레이어는 더 광범위한 공급업체-AP 인보이스 파이프라인의 엔진입니다. 열 구조는 다르지만 추출 메커니즘은 동일합니다. 매칭을 위해 구축된 동일한 파이프라인은 AP 보고, 발생액 계산 및 감사 문서화에도 사용됩니다.

매칭 대시보드: VLOOKUP, IF 및 조건부 서식

세 레이어(구매 주문 등록부, 수령 등록부, 송장 등록부)가 모두 채워지면 매칭 대시보드에서 이들이 수렴됩니다. 이는 조회 함수를 사용하여 세 소스 탭 모두에서 데이터를 가져오고 비교 논리를 적용하여 일치 항목, 차이 및 누락된 데이터를 플래그하는 단일 탭입니다. 매칭 논리 자체는 복잡하지 않습니다. 스프레드시트로 처리할 수 있습니다. 항상 복잡했던 것 — 그리고 파이프라인이 해결하는 것 — 은 스프레드시트가 처리할 수 있는 상태로 데이터를 만드는 것입니다. 이 파이프라인의 조정 중심 대응 — 허용 오차 규칙, 자동 매칭 영역 및 모호한 품목 설명에 대한 인간 판단 계층 — 은 ERP 없이 Google Sheets에서 3자 매칭에 대한 가이드를 참조하세요.

Google Sheets로 구축된 매칭 대시보드 구조:

열출처수식 / 로직
A: PO 번호송장 등록부에서 가져옴기본 키 — 이후 모든 열이 이를 참조
B: 송장 번호송장 등록부에서직접 참조: ='Invoice Register'!A2
C: 공급업체송장 등록부에서직접 참조
D: PO 공급업체PO 등록부에서 VLOOKUP=VLOOKUP(A2, 'PO Register'!A:H, 2, FALSE)
E: PO 수량PO 등록부에서 VLOOKUPPO의 라인 항목 수량과 일치
F: 수령 수량수령 등록부에서 VLOOKUP=VLOOKUP(A2, 'Receiving'!A:G, 3, FALSE)
G: 송장 수량송장 등록부에서직접 참조
H: PO 단가PO 등록부에서 VLOOKUP차이 검증을 위한 가격 기준
I: 송장 단가송장 등록부에서직접 참조
J: 수량 차이계산됨=G2-E2 — 양수는 주문보다 많이 청구되었음을 의미
K: 가격 차이계산됨=I2-H2 — 양수는 PO 대비 단가 인상을 의미
L: 라인 합계 차이계산됨=(G2*I2)-(E2*H2) — 수량 + 가격 효과 결합
M: 수령 vs. 송장계산됨=G2-F2 — 청구 수량 vs. 실제 도착 수량
N: 일치 상태계산됨=IF(AND(J2=0,K2=0,M2=0),"MATCHED",IF(F2="","NO RECEIPT","VARIANCE"))
O: 메모수동차이에 대한 설명: "공급업체 할증료가 PO에 없음," "부분 선적 — 잔액은 다음 달 청구"
일치 대시보드 결과의 3열 비교: 지불 가능을 나타내는 녹색 체크, 확인 필요를 나타내는 주황색 느낌표, 유효한 PO나 수령 내역이 없을 때 공백을 메워야 함을 나타내는 빨간색 X.

조건부 서식은 이 표를 대시보드로 바꿔 줍니다: N열을 "MATCHED"는 녹색, "NO RECEIPT"는 호박색, "VARIANCE"는 빨간색으로 강조 표시합니다. J열(수량 차이)이 구성 가능한 임계값(벌크 자재의 경우 5%, 고가 엔지니어링 부품의 경우 2%)을 초과하는 모든 행에 빨간색 테두리를 적용합니다. 맨 위 행에 요약 행을 추가합니다: =COUNTIF(N:N,"MATCHED") — 일치하는 인보이스 수 계산, =COUNTIF(N:N,"VARIANCE") — 예외 수 계산, =SUMIF(N:N,"VARIANCE",L:L) — 차이의 총 달러 가치 계산.

핵심 아키텍처 결정은 PO 번호를 보편적 키로 사용하는 것입니다. 매칭 대시보드의 모든 VLOOKUP은 PO 번호 열을 참조합니다. 공급업체 인보이스에 PO 번호가 포함되지 않은 경우(그리고 매칭 문제 분석 결과 이것이 매칭 실패의 가장 흔한 근본 원인임을 확인했습니다), 해당 행은 모든 VLOOKUP 열에서 #N/A 오류로 채워지며 대시보드에서 즉시 확인됩니다. 해결책은 간단합니다: 인보이스 등록부 행에 PO 번호를 추가하면 수식이 다시 계산됩니다. 그러나 가시성이 핵심입니다. 대시보드가 없으면 PO 번호가 없는 인보이스는 누군가 알아차릴 때까지 대기열에 남아 있습니다. 대시보드가 있으면 행이 채워지는 즉시 표시됩니다.

매칭 수식은 어려운 부분이 아닙니다. VLOOKUP에 익숙한 모든 AP 담당자는 Excel에서 이 버전을 만들어 본 적이 있습니다. 달라지는 것은 데이터가 어디서 오는가입니다: PO 라인 항목, 수령 수량, 인보이스 세부 정보가 동일한 구조화된 형식으로 도착하며, 수작업으로 입력하는 대신 원본 문서에서 몇 초 만에 추출됩니다.

부분 배송의 경우 — 제조 조달에서 가장 흔한 복잡성으로 하나의 PO가 여러 배송을 포함하는 경우 — 수령 등록부와 인보이스 등록부 모두에 "Delivery Number" 열을 추가합니다. VLOOKUP은 두 키 조회가 됩니다: PO 번호와 Delivery Number를 모두 매칭합니다. 각 부분 배송은 자체 매칭 행을 가지며, 누적 수령 계산(=SUMIFS(F:F, A:A, A2, [Delivery], "<="&[@Delivery]))은 전체 PO 수량 중 모든 부분 배송에 걸쳐 얼마나 많이 수령되었는지 추적합니다. 동일한 로직이 롤링 월별 릴리스가 있는 블랭킷 PO에도 적용됩니다 — 대시보드는 전체 PO 승인 금액 대비 누적 수량을 추적합니다.

3자 매칭 파이프라인의 지속적인 비효율성 중 하나는 공급업체에서 귀하의 팀으로 문서를 전달하는 과정입니다. 공급업체가 이메일로 송장을 보내면, AP 담당자가 첨부 파일을 다운로드하여 공유 드라이브나 로컬 폴더에 저장한 다음, 추출 도구에 업로드합니다. 이 다운로드-재업로드 주기는 병목 현상은 아니지만, 한 달에 50개 공급업체에서 100장 이상의 송장을 처리할 때 마찰을 누적시키는 추가 단계입니다.

수집 링크는 그 중간 단계를 제거합니다. 공급업체에 보내는 공유 가능한 URL(형식: /c/xxxx)로, 생성하여 공급업체에 보내면 됩니다. 공급업체는 링크를 열고, 페이지에 표시된 짧은 확인 코드를 입력한 후, 송장을 직접 업로드합니다 — 계정 생성, 로그인, 소프트웨어 설치가 필요 없습니다. 파일은 사용한 링크로 식별된 공급업체와 함께 귀하의 계정 처리 대기열에 자동으로 도착합니다. 공급업체별로(또는 공급업체 그룹별로) 별도의 수집 링크를 만들 수 있으므로, 추출이 시작되기 전에 수신 파일이 출처별로 미리 분류됩니다.

3자 매칭 파이프라인에 적용하면, 수집 링크는 문서 흐름을 "공급업체가 송장을 이메일로 보냄 → 다운로드 → 업로드 → 추출"에서 "공급업체가 직접 업로드 → 파일이 대기열에 표시됨 → 추출"로 바꿉니다. 다운로드-재업로드 단계를 완전히 제거합니다. 동일한 선적에 대해 패킹 슬립과 송장 등 여러 문서를 보내는 공급업체의 경우, 단일 수집 링크로 두 파일을 모두 수집하며, 추출 엔진은 시트의 열 정의에 따라 각각을 처리합니다. 자세한 설정과 워크플로는 문서 수집 및 추출 가이드를 참조하세요.

수집 링크는 공급업체 관계를 포털로 대체하지 않습니다. 이메일 첨부 파일 다운로드 루프를 직접 업로드 경로로 대체합니다. 공급업체는 교육, 자격 증명, 소프트웨어가 필요 없습니다. 링크와 확인 코드만 있으면 됩니다. 나머지는 동일한 추출 파이프라인입니다 — "공급업체가 보냄"과 "데이터가 시트에 있음" 사이의 단계가 하나 줄었을 뿐입니다.

대체하는 것과 대체하지 않는 것

파이프라인은 "이 단계들의 순서가 이 결과를 만든다"는 구체적인 주장입니다. 여기서 설명하는 파이프라인이 무엇을 대체하고, 무엇을 보완하며, 무엇을 위해 설계되지 않았는지 정확히 아는 것이 중요합니다.

대체하는 것:

  • 구매주문서와 송장에서 스프레드시트로의 수동 데이터 입력. 추출 계층이 비정형 문서를 정형화된 행으로 변환합니다. 구매주문 라인 항목과 송장 필드를 추적 시트에 입력하는 단계가 사라집니다.
  • 공급업체별 OCR 템플릿 유지보수. 열 이름 추출은 사전 구성된 템플릿 없이 모든 문서 레이아웃을 읽습니다. 신규 공급업체는 수집 링크를 보내는 것만으로 온보딩되며, 템플릿 구축이 필요하지 않습니다.
  • 3개 부서 조사 루프. 구매주문 데이터, 입고 데이터, 송장 데이터가 모두 하나의 구조화된 대시보드에 있을 때, "송장이 구매주문과 일치하는가?"라는 질문은 조건부 서식 셀을 보면 답이 나오며, 조달 부서와 입고 창고에 전화할 필요가 없습니다.
  • 문서 누수 사각지대. 대시보드의 VLOOKUP 구조는 즉시 공백을 드러냅니다. 구매주문 VLOOKUP에서 #N/A는 송장이 유효한 구매주문을 참조하지 않음을 의미합니다. 입고 수량이 비어 있으면 입고가 입력되지 않은 것입니다. 이는 월간 감사 결과가 아니라 모든 행에서 실시간으로 확인됩니다.

대체하지 않는 것:

  • ERP가 필요한 조직을 위한 ERP. 월 2,000~3,000건의 송장에서 스프레드시트 기반 매칭 대시보드는 실질적 한계에 도달합니다. 예외 건수가 수동 검토를 압도합니다. 이 규모에서는 ERP의 가치(자동 매칭, 통합 감사 추적, 직무 분리 강제)가 필수적이 됩니다. 파이프라인은 ERP에 정형화된 데이터를 공급할 뿐, 통제 환경으로서의 ERP를 대체하지 않습니다.
  • 예외에 대한 인간의 판단. 대시보드는 차이를 표시합니다. 해결하지는 않습니다. 송장과 구매주문 단가 간 47.50달러 차이는 조달팀이 협상했지만 AP에 전달되지 않은 정당한 추가 요금일 수도 있고, 오류일 수도 있습니다. AI는 이를 알 수 없으며, 결정하도록 요청받아서도 안 됩니다. 플래그는 인간의 검토를 촉발합니다. 검토에는 AI가 없는 비즈니스 맥락이 필요합니다.
  • 입고 프로세스 자체. 입고가 생성되지 않는다면(창고에서 도착한 물품을 기록하지 않는다면), 파이프라인은 입고 탭에서 공백을 드러내지만 데이터를 만들어낼 수는 없습니다. 입고 계층에는 프로세스 규율이 필요합니다. 누군가가 배송된 것을 확인하고 기록해야 합니다. 파이프라인은 그 데이터를 구조화할 뿐, 무에서 창조하지 않습니다.
  • 송장 내 구매주문번호 기재에 대한 공급업체 준수. 파이프라인은 구매주문번호 부재를 보이게 만듭니다. 공급업체가 번호를 포함하도록 강제하지는 않습니다. 이를 위해서는 기술적 해결책이 아닌 조달 정책과 그 집행이 필요합니다.

자주 묻는 질문

이 파이프라인은 한 달에 몇 개의 인보이스를 처리할 수 있나요?

구조적 한계는 추출 엔진이 아니라 매칭 대시보드의 수동 검토 용량에 있습니다. 한 명의 AP 담당자가 변동 사항을 검토하고 처리할 때, 잘 구성된 매칭 대시보드를 사용하면 22% 예외율(66~110건 조사)을 가정할 때 월 300~500개 인보이스를 무리 없이 처리할 수 있습니다. 월 1,000개를 초과하면 예외 볼륨이 너무 커져 여러 명의 AP 담당자가 필요하거나 자동 매칭 규칙이 있는 ERP로 전환해야 합니다. 높은 볼륨에서 이 파이프라인의 가치는 '주 매칭 도구'에서 'ERP에 정형 데이터를 공급하는 데이터 수집 엔진'으로 전환됩니다. 추출 계층은 계속 작동하고, 대시보드는 최종 매칭 환경이 아닌 ERP 사전 검증 단계가 됩니다.

PO가 매월 변동되는 포괄 가격을 사용하는 경우, 파이프라인이 변동 가격을 처리할 수 있나요?

가능합니다. 단, PO 레지스트리를 일회성 추출이 아닌 살아있는 문서로 유지해야 합니다. 원자재 시장 가격에 연동된 월별 가격 조정이 있는 포괄 PO의 경우, 해당 공급업체의 PO 레지스트리 행을 매월 현재 유효 가격으로 업데이트해야 합니다. 매칭 대시보드의 VLOOKUP은 업데이트된 가격을 반영합니다. 감사 추적을 보존하는 대안은 PO 레지스트리에 '발효일' 열을 추가하고 날짜 범위 매칭 VLOOKUP을 사용하는 것입니다. 현재 가격이 아닌 인보이스 날짜에 발효된 PO 가격을 가져옵니다. 설정은 더 복잡하지만 선적 당시 합의된 가격을 정확히 반영하며, 이것이 3자 매칭이 검증해야 하는 사항입니다.

수기로 작성된 포장 명세서와 수령 문서에서도 추출이 작동하나요?

네, AI는 부두에서 서명된 포장 명세서에 일반적인 숫자와 표기를 포함한 필기 텍스트를 읽습니다. 그러나 수기 문서의 정확도는 인쇄된 문서보다 낮으며, 심하게 손상된 문서(희미한 감열지 인쇄물, 글자가 희미한 카본지, 구겨졌다가 다시 편 포장 명세서)는 더 많은 추출 오류를 발생시킵니다. 수령 데이터의 경우 다음을 권장합니다. (a) 가능하다면 수령 담당자가 부두에서 Google 시트에 주요 필드(PO 번호, 품목, 수량, 날짜)를 직접 입력합니다. 수령 시점의 수동 입력이 나중에 손상된 문서에서 추출하는 것보다 빠르고 정확합니다. (b) 포장 명세서 추출이 유일한 방법이라면, 특히 고가 선적의 경우 원본 문서와 샘플 행을 대조 확인합니다. (c) 포장 명세서 사진을 수령 행과 함께 첨부 파일로 저장합니다. 추출에서 숫자를 놓치더라도 원본 문서를 한 번의 클릭으로 확인할 수 있습니다.

Google Sheets 애드온 없이 웹 앱만으로 이 파이프라인을 사용할 수 있나요?

네. Sheets 안의 사이드바 애드온을 통해서든 ImageToTable.ai 웹 애플리케이션을 통해서든 추출 엔진은 동일합니다. 애드온의 장점은 추출 결과가 활성 시트에 직접 기록된다는 점입니다 — 다운로드 후 다시 업로드하는 과정이 없습니다. 웹 앱에서는 브라우저에서 문서를 업로드하고, 추출된 Excel 파일을 다운로드한 다음, 해당 행을 원하는 대시보드에 붙여넣거나 가져옵니다. 열 정의는 동일합니다. 추출 품질도 동일합니다. 애드온은 한 단계(다운로드-가져오기)를 없애주며, 웹 앱은 Google Sheets뿐 아니라 모든 스프레드시트 도구에서 작동합니다. 이 한 단계가 작업량에 영향을 주는지에 따라 선택하세요.

전체 파이프라인(구매 주문 등록부, 입고 등록부, 송장 등록부, 매칭 대시보드)의 설정 시간은 얼마나 걸리나요?

Google Sheets에서 VLOOKUP과 조건부 서식을 다룰 수 있는 분 기준으로, 4개 탭으로 구성된 전체 파이프라인 구축에는 약 2시간이 걸립니다: 위에서 설명한 열 구조로 4개 탭을 설계하고 만드는 데 30분, 매칭 대시보드에서 VLOOKUP 및 IF 수식을 작성하고 테스트하는 데 45분, 조건부 서식과 요약 지표를 설정하는 데 30분, 애드온 사이드바에서 추출 열 세트를 정의하는 데 15분입니다. 열 정의는 시트에 저장되어 세션 간 유지됩니다 — 한 번 정의해 두면 사이드바를 열고 해당 시트를 선택할 때마다 사용할 수 있습니다. 초기 설정 후 월간 작업 흐름은 다음과 같습니다: (1) 새 구매 주문을 구매 주문 등록부에 추출하고, (2) 입고 데이터를 입력하거나 추출하며, (3) 공급업체 송장을 추출하고, (4) 매칭 대시보드를 열어 플래그가 지정된 행을 검토합니다. 첫 달은 설정과 데이터 입력 때문에 가장 오래 걸립니다. 세 번째 달부터는 일상적인 작업이 됩니다. 지원되는 필드 유형, 형식, 플랜 세부 정보 등 전체 기능에 대한 자세한 내용은 Google Sheets 문서 추출 애드온을 참조하세요.

PO와 공급업체 청구서 간 통화 차이는 어떻게 처리하나요?

추출 엔진은 문서에 표시된 대로 숫자 값과 통화 기호를 캡처합니다. 통화 변환은 수행하지 않습니다. PO가 USD이고 공급업체 청구서가 EUR인 경우, 변환된 값이 정확하더라도 금액이 일치하지 않으므로 대시보드에 차이가 표시됩니다. 해결 방법은 PO 등록부와 청구서 등록부 양쪽에 "통화" 열을 추가하고, 수동으로 유지 관리하거나 수식으로 공급되는 환율을 참조하는 "환율" 열을 추가하는 것입니다. 그런 다음 가격 비교는 원시 추출 금액 대신 변환된 금액을 사용합니다. 파이프라인의 역할은 추출입니다. 통화 변환은 스프레드시트 계층의 작업입니다.

결론

여기서 설명하는 3자 대사 파이프라인은 ERP가 필요한 조직에서 ERP를 대체하는 솔루션이 아닙니다. 이미 스프레드시트로 구매를 관리하는 팀을 위한 시스템입니다. ERP의 청구서 캡처가 유지할 수 없는 템플릿 관리를 요구하거나, 공급업체 기반이 매칭 모듈이 처리할 수 없는 형식에 걸쳐 있거나, 거래량이 "수동 매칭에는 너무 복잡"하고 "ERP 업그레이드를 정당화할 만큼 크지 않은" 사이에 있는 경우입니다. 이러한 팀에게 질문은 "매칭을 자동화해야 하는가"가 아닙니다. "세 문서를 모두 동일한 구조화된 형식으로 충분히 빨리 가져와서 매칭이 3개 부서의 조사가 아닌 수식 작업이 될 수 있는가"입니다.

파이프라인은 세 가지 추출 계층과 하나의 대시보드로 이 질문에 답합니다. PO 계층은 기준선을 제공합니다. 수령 계층은 도착한 것을 확인합니다. 청구서 계층은 청구된 것을 캡처합니다. 매칭 대시보드는 VLOOKUP, IF 문 및 조건부 서식을 사용하여 이를 비교하고 사람의 주의가 필요한 모든 행에 플래그를 지정합니다. 위치가 아닌 의미로 문서를 읽는 AI로 구동되는 추출 엔진은 다중 공급업체 구매 운영에서 템플릿 기반 접근 방식을 지속 불가능하게 만드는 형식 다양성을 처리합니다. 수집 링크는 문서 수집 프로세스에서 이메일 첨부 파일 다운로드 루프를 제거합니다.

우리의 문제 분석에서 확인한 구조적 격차(세 부서, 세 시스템, 데이터 파이프라인의 단일 소유자 없음)는 사라지지 않습니다. 그러나 세 문서 유형이 모두 동일한 스프레드시트에서 동일한 구조화된 형식으로 도착하고 동일한 PO 번호가 범용 키로 사용되면 매칭 단계는 더 이상 부서 간 조사가 필요하지 않습니다. 조직적 격차는 남아 있습니다. 데이터는 더 이상 세 가지 다른 입력 채널의 누적된 드리프트를 전달하지 않습니다. 이것이 매칭을 인력 문제가 아닌 스프레드시트 작업으로 만드는 이유입니다.

PO 추출 계층부터 시작하세요. 아래 데모에서 구매 주문서를 업로드하세요. 매칭 워크플로에 중요한 필드(PO 번호, 공급업체, 라인 항목, 수량, 가격)가 분 단위가 아닌 초 단위로 구조화되어 반환되는지 확인하세요. 첫 번째 계층이 작동하면 나머지 파이프라인은 동일한 엔진으로 구축됩니다.

📮 contact email: [email protected]