ERP 없이 3-Way 매칭 구현하기:
발주서부터 승인까지 구글 시트 파이프라인

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

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

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

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

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

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

해당 그룹에 속한다면 — 스프레드시트로 조달을 운영하거나, ERP의 송장 캡처 기능이 공급업체별 템플릿 설정을 요구하지만 이를 유지할 여력이 없거나, 소규모 공급업체가 많아 PDF만 받을 수 있는 경우 — ERP의 매칭 모듈은 실제 문제보다 하류에 있는 문제를 해결하고 있는 셈입니다. 더 나은 매칭 알고리즘이 필요하지 않습니다. PO 데이터, 수령 데이터, 송장 데이터를 하나의 구조화된 뷰로 통합할 방법이 필요하며, 이미 조달 추적에 사용 중인 도구는 대개 스프레드시트입니다. 문제는 그 스프레드시트를 파이프라인으로 전환하는 방법입니다.

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

파이프라인은 3계층으로 구성됩니다 — 3방향 매칭의 각 문서에 하나씩 — 그리고 그 위에 매칭 대시보드라는 네 번째 계층이 있습니다. 처음 세 계층은 비정형 문서에서 구조화된 데이터를 추출합니다. 네 번째 계층은 이를 비교합니다. 처음 세 계층 중 하나라도 일관되지 않거나 불완전한 데이터를 생성하면 매칭 계층은 제 역할을 할 수 없습니다. 아키텍처는 가장 약한 추출 계층만큼만 강력합니다.

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

레이어 1과 3에서 비정형 데이터를 정형 데이터로 변환하는 도구는 사용자 정의 열 추출입니다: 각 문서의 필드 주위에 상자를 그리거나 공급업체 형식별로 템플릿을 만드는 대신, 원하는 열 이름("PO 번호", "공급업체명", "라인 항목", "수량", "단가", "라인 합계")을 입력하면 AI가 문서를 읽고 해당 값이 페이지에서 어디에 있는지가 아니라 무엇을 의미하는지 이해하여 찾아냅니다. SAP의 PDF 출력에서 나온 정형화된 PO와 지역 공급업체의 수기 PO는 전혀 다르게 보입니다. 하지만 둘 다 PO 번호, 공급업체명, 수량, 가격을 포함하고 있습니다. 열 이름 추출은 모든 레이아웃에서 해당 필드의 의미를 검색하여, 수십 가지의 다양한 공급업체 문서 형식을 처리하는 조달 팀에게 템플릿 기반 OCR을 비실용적으로 만드는 공급업체별, 형식별 템플릿 유지 관리를 없앱니다.

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

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

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

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

위 데모는 구매 주문서 프리셋을 사용합니다. 이는 PO 문서용으로 미리 구성된 추출 열 세트입니다. 구매 주문서를 업로드하면 입력 없이 필드가 자동으로 채워집니다. PO에 프리셋이 포함하지 않은 필드(예: 상품 할증료 항목, 운임 조건 섹션, 내부 원가 센터 코드)가 있다면 사용자 정의 열로 추가하세요. 추출 엔진은 동일하게 처리합니다. 프리셋은 시작점을 제공하며, 사용자 정의 열이 이를 확장하여 대시보드 요구 사항에 맞춥니다.

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

입고 확인서는 구조화된 시스템에서 가장 누락되기 쉬운 문서이며, 3자 매칭을 가능하게 하는 핵심 문서입니다. 입고 확인 없이는 2자 매칭(구매발주서 대 인보이스)만 수행하게 되어, 실제로 배송되었는지 확인할 수 없는 상품에 대해 비용을 지불하게 됩니다. ACFE는 특히 입고 확인서를 청구 사기(배송되지 않은 상품에 대한 지불)를 방지하는 통제 수단으로 지목합니다. 이를 생략하는 것은 단순한 지름길이 아닙니다. 통제 프레임워크에 구멍을 내는 것입니다.

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

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

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

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

계층 3 — 공급업체 송장 추출: 통제할 수 없는 형식 문제

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

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

추론 열을 추가할 수도 있습니다. 추론 열은 송장에 명시적으로 인쇄되지는 않았지만 맥락에서 유추할 수 있는 데이터를 캡처하는 열입니다. 예를 들어, 매칭 상태 (옵션: 매칭 준비 완료/구매처 참조 필요/라인 항목 누락)로 정의된 열을 사용하면 AI가 각 송장을 추출할 때 구매처 번호가 있는지, 라인 항목을 추출할 수 있는지에 따라 분류합니다. 구매처 번호를 문서에 포함하지 않는 공급업체로부터 도착한 송장은 즉시 플래그가 지정되어 "구매처 참조 필요" 상태로 매칭 대시보드에 들어가며, AP 담당자는 구매처 번호가 추가될 때까지 매칭을 시도하지 않아야 함을 알게 됩니다. 이는 추출로서의 분류입니다. 분류 결정은 데이터를 채우는 동일한 과정에서 이루어지며, 별도의 검토 단계에서 이루어지지 않습니다.

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

동일한 인보이스 추출 레이어가 3방향 매칭 파이프라인을 구동하며, 더 넓은 공급업체→AP 인보이스 파이프라인의 엔진 역할을 합니다. 열 구조는 다르지만 추출 메커니즘은 동일합니다. 매칭을 위해 구축된 이 파이프라인은 AP 보고, 발생액 계산, 감사 문서에도 동일하게 사용됩니다.

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

PO 등록부, 입고 등록부, 인보이스 등록부의 세 레이어가 모두 채워지면 매칭 대시보드에서 이들이 통합됩니다. 이는 조회 함수를 사용해 세 소스 탭에서 데이터를 가져오고 비교 로직을 적용하여 일치, 차이, 누락 데이터를 표시하는 단일 탭입니다. 매칭 로직 자체는 복잡하지 않습니다. 스프레드시트로도 가능합니다. 항상 복잡했던 점(파이프라인이 해결하는 부분)은 스프레드시트가 이를 수행할 수 있는 상태로 데이터를 만드는 것입니다.

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

조건부 서식은 이 표를 대시보드로 전환합니다: N열을 녹색("일치"), 호박색("미입고"), 빨간색("차이")으로 강조합니다. J열(수량 차이)이 구성 가능한 임계값(벌크 자재 5%, 고가 엔지니어링 부품 2%)을 초과하는 행에 빨간색 테두리를 적용합니다. 상단 요약 행 추가: =COUNTIF(N:N,"일치")로 일치 인보이스 개수, =COUNTIF(N:N,"차이")로 예외 개수, =SUMIF(N:N,"차이",L:L)로 차이의 총 금액을 계산합니다.

핵심 아키텍처 결정은 PO 번호를 범용 키로 사용하는 것입니다. 매칭 대시보드의 모든 VLOOKUP은 PO 번호 열을 참조합니다. 공급업체 송장에 PO 번호가 없으면 — 매칭 문제 분석 결과 이것이 매칭 실패의 가장 흔한 단일 근본 원인으로 확인되었습니다 — 해당 행의 모든 VLOOKUP 열에 #N/A 오류가 표시되어 대시보드에서 즉시 확인됩니다. 해결책은 간단합니다. 송장 등록 행에 PO 번호를 추가하면 수식이 다시 계산됩니다. 그러나 가시성이 핵심입니다. 대시보드가 없으면 PO 번호가 누락된 송장은 누군가가 알아차릴 때까지 대기열에 머뭅니다. 대시보드가 있으면 행이 채워지는 즉시 플래그가 지정됩니다.

부분 납품(하나의 발주서가 여러 선적을 포함하는 제조 조달의 가장 일반적인 복잡성)의 경우, 수령 등록부와 송장 등록부 모두에 "납품 번호" 열을 추가하십시오. VLOOKUP은 두 개의 키 조회(발주서 번호와 납품 번호 일치)가 됩니다. 각 부분 납품은 자체 일치 행을 가지며, 누적 수령 계산(=SUMIFS(F:F, A:A, A2, [납품], "<="&[@납품]))은 전체 발주 수량 중 모든 부분 선적에 걸쳐 납품된 양을 추적합니다. 동일한 로직이 월별 롤링 릴리스가 있는 포괄 발주서에도 적용됩니다. 대시보드는 총 발주 승인 금액 대비 누적 수량을 추적합니다.

수집 링크 — 공급업체가 직접 문서를 제출하도록 하기

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

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

3방향 매칭 파이프라인에 적용된 컬렉션 링크는 문서 흐름을 "공급업체가 이메일로 송장 발송 → 다운로드 → 업로드 → 추출"에서 "공급업체가 직접 업로드 → 파일이 대기열에 표시 → 추출"로 변경합니다. 다운로드 후 재업로드 단계를 완전히 제거합니다. 동일한 선적에 대해 포장 명세서와 송장 등 여러 문서를 보내는 공급업체의 경우, 단일 컬렉션 링크로 두 파일을 모두 캡처하며, 추출 엔진은 시트의 열 정의에 따라 각각을 처리합니다. 자세한 설정 및 워크플로는 추출 기능을 포함한 문서 수집 가이드를 참조하세요.

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

파이프라인은 "이 단계 순서가 이 출력을 생성한다"는 구체적인 주장입니다. 여기서 설명하는 파이프라인이 무엇을 대체하고, 무엇을 보완하며, 무엇을 위해 설계되지 않았는지 정확히 파악하는 것이 중요합니다.

대체하는 것:

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

대체하지 않는 것:

• ERP는 필요할 때 도입하는 시스템입니다. 월 2,000~3,000건의 송장을 처리하는 시점에서 스프레드시트 기반 대사 대시보드는 한계에 부딪힙니다. 예외 건수가 너무 많아 수동 검토가 어려워집니다. 이 규모에서는 자동 대사, 통합 감사 추적, 직무 분리 강제 등 ERP의 가치가 선택이 아닌 필수가 됩니다. 파이프라인은 ERP에 정형 데이터를 공급할 뿐, 통제 환경으로서 ERP를 대체하지 않습니다.
• 예외 처리에는 사람의 판단이 필요합니다. 대시보드는 차이를 표시할 뿐 해결하지 않습니다. 송장과 발주서의 단가가 47.50달러 차이 나는 경우, 조달팀이 협의했지만 AP팀에 전달되지 않은 정당한 추가 요금일 수도 있고 오류일 수도 있습니다. AI는 이를 알 수 없으며, 판단을 요구받아서도 안 됩니다. 플래그는 사람의 검토를 유발하고, 검토에는 AI가 알 수 없는 업무 맥락이 필요합니다.
• 입고 프로세스 자체가 중요합니다. 입고가 생성되지 않는다면, 즉 창고에서 도착한 물품을 기록하지 않는다면 파이프라인은 입고 탭에서 그 공백을 드러낼 뿐 데이터를 만들어낼 수 없습니다. 입고 단계에는 프로세스 규율이 필요합니다. 누군가가 인도된 물품을 확인하고 기록해야 합니다. 파이프라인은 그 데이터를 구조화할 뿐, 무에서 창조하지 않습니다.
• 공급업체의 송장 내 발주서 번호 기재 준수. 파이프라인은 발주서 번호 누락을 보여줄 뿐, 공급업체가 번호를 기재하도록 강제하지 않습니다. 이를 위해서는 기술적 해결책이 아닌 조달 정책과 그 집행이 필요합니다.

FAQ

이 파이프라인은 월 몇 건의 송장까지 처리할 수 있나요?

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

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

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

손으로 작성한 패킹 리스트와 수령 문서에서도 추출이 작동하나요?

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

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

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

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

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

발주와 공급업체 송장 간 통화 차이는 어떻게 처리하나요?

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

결론

此处所述的三方匹配流程并非替代企业所需ERP的系统，而是为那些仍通过电子表格管理采购的团队设计的方案——因为他们的ERP发票捕获功能需要无法持续维护的模板，因为供应商格式多样导致匹配模块无法处理，或因为交易量处于“手动匹配过于复杂”与“升级ERP成本过高”之间的尴尬区间。对这些团队而言，问题不在于“是否应自动化匹配”，而在于“能否将三份文档快速转化为统一结构化格式，使匹配从跨部门调查变为公式运算”。

该流程通过三个提取层与一个仪表盘解决此问题：采购订单层提供基准参考，收货层确认到货情况，发票层记录账单信息。匹配仪表盘通过VLOOKUP、IF语句和条件格式进行比对，并标记所有需人工处理的条目。提取引擎由按语义而非位置读取文档的AI驱动，可应对多供应商采购中模板方案无法持续的格式多样性。Collection Link则消除了文档接收流程中的邮件附件下载环节。

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

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