Google Sheets에서의 3방향 매칭:
ERP 없이 발주서, 송장, 입고증 조정하기
레딧의 한 조달 관리자는 월간 조정 작업을 이렇게 설명했습니다. 시스템에서 CSV로 발주 데이터를 내보내고, 공유 드라이브에 있는 창고의 수기 입고 기록을 열고, 40개 PDF 송장의 라인 항목을 수동으로 스프레드시트에 입력합니다. 모든 주문 번호에 세 가지 버전, 세 가지 형식, 그리고 매달 차이를 찾는 데 오후 내내 시간을 쏟습니다. 매칭 로직 자체는 문제가 아닙니다. 문제는 서로 다른 세 가지 형식으로 존재하는 세 문서를 실제로 비교할 수 있는 단일 구조로 만드는 것입니다.
핵심 요약
- 3방향 매칭에 ERP가 필요하다고 모두가 생각하지만, Google Sheets의 매칭 수식은 1990년대부터 사용되어 왔습니다.
- 수동으로 입력된 송장 라인의 39%는 데이터 입력 오류를 포함하며, 수정에 평균 53달러가 소요됩니다. 월말 조정 작업은 실제 차이보다 자신의 오타를 찾는 데 시간을 낭비하게 됩니다.
- ImageToTable.ai는 한 번의 추출 단계로 구매 주문서, 입고증, 공급업체 송장을 원본 형식에 관계없이 동일한 열 구조로 변환하며, 매칭 대시보드는 이미 사용 중인 수식으로 몇 초 만에 비교를 실행합니다.
진짜 병목은 매칭이 아니다. 그 전 단계다.
Ardent Partners의 2025년 AP 벤치마크에 따르면 평균 1차 불일치율은 22%입니다. 제조업에서 이 수치가 더 높은 이유 — 포괄 발주, 부분 납품, 하역장과 청구서 간 단위 차이 — 를 분석했습니다. 하지만 ERP가 없는 팀에게 더 중요한 숫자는 조용한 39%입니다. 수동 송장 중 최소 한 건의 데이터 입력 오류가 포함된 비율이며, ACFE의 AP 재작업 비용 벤치마크에 따르면 수정에 평균 53달러가 소요됩니다.
이것은 매칭 실패가 아닙니다. 데이터 추출 실패입니다. PDF, 수기 입고 기록, 발주서 내보내기 파일의 데이터가 같은 공간에 모이지 않았기 때문입니다. 마침내 모였을 때, 불일치는 실제 차이가 아닌 누군가의 오타입니다.
아무도 말하지 않는 3개 문서 형식의 현실
3방향 매칭은 개념적으로 간단합니다. 구매 발주서(요청한 것), 입고 확인서(도착한 것), 공급업체 송장(청구된 금액)을 비교합니다. 수량, 단가, 품목 설명이 모두 일치하면 지급하고, 그렇지 않으면 조사합니다.
하지만 조달, 입고, AP를 하나의 데이터 모델로 통합하는 ERP가 없는 조직에서는 이 세 문서가 서로 다른 부서에만 있는 것이 아닙니다. 서로 다른 형식으로 존재합니다:
- 발주서는 QuickBooks, 조달 모듈, 또는 누군가 작성한 템플릿 등 생성된 시스템의 구조화된 데이터로 존재합니다. CSV나 Sheets로 내보내면 깔끔한 열(발주 번호, 라인 항목, 수량, 단가, 공급업체)을 얻을 수 있습니다.
- 입고 확인서는 종종 가장 취약한 고리입니다. 하역 직원에게 전달된 종이 포장 명세서로 도착하며, 펜으로 메모("2박스 부족")를 적고 사진을 찍어 공유 폴더에 업로드됩니다. 또는 창고 관리자가 수첩에 기록한 수기 로그입니다. 데이터는 있지만 구조는 없습니다.
- 공급업체 송장은 공급업체로부터 PDF(또는 인쇄된 PDF의 스캔 이미지)로 도착합니다. 라인 항목, 수량, 가격, 발주 참조 번호가 있지만, 해당 공급업체 청구 시스템이 생성하는 형식으로 배열됩니다. 두 공급업체의 송장 형식이 동일한 경우는 없습니다.
이것이 대부분의 3방향 매칭 조언이 현실과 동떨어진 이유입니다. 세 문서가 이미 비교 가능한 행으로 존재한다고 가정하지만, 실제로는 그렇지 않습니다. "문서를 보유했다"와 "비교할 수 있다" 사이의 격차가 전체 운영 과제입니다.
AP 워크플로우에서 추출 기능의 위치 (기존 체계를 유지하면서)
대부분의 팀이 저지르는 워크플로우 통합 실수는 AI 추출을 기존 프로세스의 대체재로 간주하는 것입니다. 그렇지 않습니다. 이는 문서 수신과 데이터 비교 사이에 위치하는 계층으로, 기존 워크플로우에 하나의 단계만 추가됩니다.
ERP 없이 일반적인 AP 흐름에서 삽입 지점은 다음과 같습니다:
현재 워크플로우:
PO 생성 → 입고 (수기 기록) → 송장 수신 (PDF) → 스프레드시트에 라인 항목 수동 입력 → 비교 → 지불
추출 계층 삽입 시:
PO 생성 → 입고 (수기 기록) → 송장 수신 (PDF) → 세 문서 모두 Sheets로 추출 → 비교 → 지불
승인 라우팅, 지불 일정, 공급업체 커뮤니케이션 등 나머지 워크플로우는 변경되지 않습니다. 회계 시스템도 변경할 필요가 없습니다. 변경되는 것은 비교를 수행하는 사람이 수동으로 입력한 데이터가 아닌 추출된 데이터를 본다는 점입니다.
이것이 구매 주문서용 AI 문서 추출이 워크플로우 경제성을 바꾸는 지점입니다. 한 시스템에서 PO를 내보내고 다른 시스템에서 송장을 수동으로 입력하는 대신, 세 문서 모두 동일한 추출 단계를 거칩니다. 출력은 원본 문서의 형식과 관계없이 동일한 열 구조(PO 번호, 품목 설명, 수량, 단가, 라인 합계)를 가진 세 개의 시트입니다.
여기서 작동하는 개념은 사용자 정의 열 추출입니다: "PO 번호", "품목 설명", "수량", "단가" 등 원하는 열을 정의하면 AI가 각 문서를 읽어 해당 값을 찾습니다. 값이 페이지의 어디에 위치하는지가 아니라 무엇을 의미하는지 이해합니다. 공급업체 A가 단가를 1페이지 오른쪽 정렬 열에 넣고 공급업체 B가 3페이지 각주에 숨겨도 문제되지 않습니다. 추출 결과는 균일하며, 균일한 데이터는 비교 가능한 데이터입니다.
파일은 안전하게 처리되며 저장되지 않습니다.
추출부터 매칭까지: 4개 시트, 하나의 비교
세 가지 문서 유형이 모두 구조화된 데이터로 추출되면, Google Sheets의 매칭 아키텍처는 다음 네 개의 탭으로 구성됩니다:
데이터 출처: 구매 시스템에서 내보내거나 발주 문서에서 추출. 열: 발주 번호, 공급업체, 품목 설명, 주문 수량, 단가, 라인 합계, 날짜.
데이터 출처: 촬영된 납품서에서 추출하거나 입고 담당자가 수동 입력. 열: 발주 번호, 입고 품목, 입고 수량, 입고일, 운송사, 상태 메모.
데이터 출처: 공급업체 청구서 PDF에서 추출. 열: 청구서 번호, 발주 번호, 공급업체, 품목 설명, 청구 수량, 단가, 라인 합계, 청구일, 납기일.
비교 계층. VLOOKUP/QUERY를 사용해 세 등록부에서 데이터를 가져오고, 차이 로직을 적용하여 라인 항목별로 일치/불일치 플래그를 출력합니다. 여기서 실제 조정이 이루어집니다.
월별로 동일 공급업체의 여러 청구서를 처리하는 팀의 경우, 공급업체 청구서를 일괄 처리하여 단일 추출 실행으로 문서별 설정 단계를 없앨 수 있습니다. 한 번 추출하고 여러 번 비교하세요. 스프레드시트에서 발주 데이터를 여전히 수동으로 재생성하는 팀의 경우, 원본 문서에서 발주 라인 항목을 직접 추출하면 모든 문서 유형이 동일한 구조화된 파이프라인을 통해 매칭 대시보드로 들어오는 순환이 완성됩니다.
대시보드 자체의 매칭 공식은 복잡하지 않습니다. Google Sheets의 QUERY 또는 FILTER 함수로 발주 번호와 라인 항목을 기준으로 세 데이터 세트를 조인할 수 있습니다. 항상 복잡했고, 추출 계층이 이제 해결하는 것은 이러한 공식이 작동할 수 있는 상태로 데이터를 만드는 일입니다.
매칭 수식 패턴
매칭 대시보드 탭에서 비교 열은 다음과 같이 작동합니다(세 레지스터 모두 A열에 PO 번호, B열에 품목이 있다고 가정):
| 확인 항목 | 수식 로직 | 녹색 조건 |
|---|---|---|
| 수량 일치 | =AND(G2=H2, H2=I2) | PO 수량 = 입고 수량 = 청구 수량 |
| 단가 일치 | =ABS(J2-K2)/J2<=0.05 | 단가 차이 ≤ 5% |
| 라인 합계 일치 | =ABS(L2-M2)<=0.01 | 라인 합계 $0.01 이내 |
| 전체 매칭 플래그 | =IF(AND(Qty_OK, Price_OK, Line_OK), "MATCH", "REVIEW") | 세 가지 확인 항목 모두 통과 |
허용 오차 비율과 금액 임계값을 회사의 중요성 정책에 맞게 조정하세요.
자동 매칭 영역: 스프레드시트가 사람 개입 없이 플래그할 수 있는 항목
모든 라인 항목에 사람의 검토가 필요한 것은 아닙니다. 깨끗하게 추출된 데이터와 허용 오차 규칙을 사용하면 잘 구성된 매칭 대시보드가 대부분의 송장을 자동 승인할 수 있습니다. 최고 수준의 AP 팀이 직통 처리율(STP)이라고 부르는 방식입니다. ERP가 없는 조직의 목표는 70-80% 자동 매칭이며, 진정한 예외 사항만 검토 대상으로 남깁니다.
자동 매칭 조건은 간단합니다:
- 세 문서 모두에서 정확한 수량 일치. 100개 주문, 100개 입고, 100개 청구 — 녹색. 입고와 송장이 일치하는 부분 배송도 유효합니다(100개 주문, 50개 입고, 50개 청구 — 입고 수량 기준 매칭).
- 정의된 허용 오차 내 단가 차이. 대부분의 조직은 비계약 품목에 대해 2-5%, 계약 가격 품목에 대해 0%로 설정합니다. PO의 단가 $10.00 대비 송장의 $10.20는 2% 차이로 — 많은 팀에서 허용 범위 내에 있지만, 동일 공급업체에서 반복되면 패턴으로 추적할 가치가 있습니다.
- 세 문서 모두 동일한 PO 번호와 동일한 라인 번호를 참조. 공급업체의 송장이 단일 PO 라인을 두 개의 송장 라인으로 분할하는 경우, 이는 구조적 불일치입니다. 합계가 일치하더라도 라인 수가 맞지 않아 자동으로 플래그됩니다.
허용 오차 구성은 모든 상황에 적용되는 단일 기준이 아닙니다. 자연적인 중량 변동이 있는 대량 원자재(곡물, 고철, 목재)를 취급하는 작업은 개별 단위(포장 전자제품, 라벨 부착 의류)를 선적하는 작업보다 더 넓은 수량 허용 오차가 필요합니다. 보수적으로 시작하세요 — 가격 ±2%, 계약 품목 ±0% — 그리고 2~3회 지급 주기에 걸쳐 실제 예외 패턴에 따라 범위를 넓히세요. 실제 초과 지급을 허용하지 않으면서 허위 양성의 80%를 제거하는 허용 오차가 이상적입니다.
휴먼 판단 영역: "Steel Rod 12mm"와 "Round Bar Ø12 ST37"이 동일한 경우
스프레드시트 수식은 텍스트 문자열을 일치시킵니다. 공급업체 카탈로그에는 "Round Bar Ø12 ST37 Grade"로, 구매 주문서에는 "Steel Rod 12mm"로 기재된 품목이 동일하다는 것을 이해하지 못합니다. 둘 다 직경 12mm의 연강 환봉을 설명하지만, 수식은 공통된 문자가 하나도 없다고 판단합니다.
이것은 잘 구축된 스프레드시트 파이프라인으로도 자동화할 수 없는 일치 오류입니다. 또한 조사에 가장 많은 시간이 소요되는 오류이기도 합니다. 수량과 가격은 완벽하게 일치할 수 있지만, 품목 설명 열은 문자열이 일치하지 않아 차이로 표시되기 때문입니다.
실무에서 휴먼 판단 계층은 수식이 해결할 수 없는 세 가지 유형의 불일치를 처리합니다.
1. 이름은 다르지만 동일한 품목. 가장 흔하고 노동 집약적인 경우입니다. 공급업체는 자체 SKU 명명법, 약식 설명 또는 내부 품목 마스터와 일치하지 않는 상품명을 사용합니다. 포장 명세서에는 "BRG 6205-2RS"라고 적혀 있지만 구매 주문서에는 "Ball Bearing 25x52x15 Sealed"라고 적혀 있을 수 있습니다. 사람은 즉시 일치를 인식하지만 VLOOKUP은 #N/A를 반환합니다.
해결 방법은 수식이 아닌 운영에 있습니다. 공급업체 품목 코드를 내부 품목 설명에 매핑하는 별도의 시트인 크로스 레퍼런스 테이블을 유지 관리하고 점진적으로 채웁니다. 불일치가 처음 발생하면 사람이 해결하고 매핑을 추가합니다. 이후 수식은 일치시킬 대상을 갖게 됩니다. 6개월이 지나면 크로스 레퍼런스는 활성 SKU의 90%를涵盖하고 수동 판단 범주는 신규 품목으로만 축소됩니다.
2. 조사 비용이 가치가 없는 소액 불일치. 송장 총액이 $2,145.00이고 구매 주문서 금액이 $2,144.86인 경우 $0.14의 차이가 발생합니다. 이는 세금 계산의 반올림 차이, 단가 확장의 페니 차이 또는 공급업체가 항목별로 명시하지 않고 적용한 운임 할증료일 가능성이 높습니다. 조사 비용이 불일치 금액보다 더 많이 듭니다. 대부분의 조직은 달러 기준(보통 $10 또는 $25)을 설정하여 그 미만이고 비율이 0.5% 미만인 차이는 자동 승인합니다.
3. 라인 순서는 일치하지 않지만 합계는 일치합니다. 구매 주문서는 주문한 순서대로 품목을 나열합니다. 공급업체의 송장은 창고 피킹 순서, SKU 알파벳순 또는 세금 범주별로 그룹화하여 재정렬할 수 있습니다. 라인별 VLOOKUP은 구매 주문서의 라인 3이 송장의 라인 7에 해당하기 때문에 실패합니다. 이러한 경우 사람은 품목 설명을 스캔하여 모든 구매 주문서 품목이 송장에 있는지 확인한 다음 송장 총액을 구매 주문서 총액과 대조합니다. 라인별 비교는 건너뛰고 헤더 수준 일치를 우선시합니다.
목표는 3방향 매칭에서 휴먼 판단을 없애는 것이 아닙니다. 판단이 실제로 가치를 더하는 경우(모호한 품목 설명, 중요성 결정, 구조적 불일치)로 휴먼 판단 영역을 축소하고 수량, 가격 및 설명이 깔끔하게 일치하는 80%의 라인 품목은 스프레드시트가 처리하도록 하는 것입니다.
월 1회 소방훈련에서 주간 점검으로: 업무 리듬의 변화
수동 3방향 매칭은 예측 가능한 리듬을 가집니다. 모든 업무가 월말까지 쌓이고, AP팀이 지급 실행 전 사흘 동안 조정 작업을 하는 식입니다. 추출 및 매칭 워크플로는 이 템포를 수동 배치 처리에서 지속적 검토로 바꿉니다.
추출에 페이지당 5~10초가 걸리면(수동 입력 평균 3분 대비), 처리 시점의 경제성이 달라집니다. 더 이상 송장을 한 달 치씩 모아서 처리할 필요가 없습니다. 도착하는 대로 처리할 수 있으며, 그 결과는 다음과 같습니다:
- 불일치가 몇 주가 아닌 며칠 내에 드러납니다. 5일에 발견된 수량 차이는 지급 실행 전까지 2주의 해결 시간이 있습니다. 28일에 발견되면, 공급업체에 급히 전화를 걸거나 지급이 지연됩니다.
- 공급업체 커뮤니케이션이 수동에서 능동으로 전환됩니다. 패턴이 포착되면(예: X 공급업체가 PO 가격보다 2% 높게 청구), 6개월 치 송장에 걸쳐 누적되기 전에 대처합니다.
- 월말 마감이 데이터 입력 마라톤에서 검토 세션으로 바뀝니다. 매칭 대시보드는 이미 채워져 있습니다. 마감 작업은 플래그된 예외를 확인하고 지급 배치를 승인하는 것이지, 처음부터 구축하는 것이 아닙니다.
Reddit r/procurement의 한 조달 전문가는 이 변화를 이렇게 설명했습니다. PO 내보내기와 추출된 송장 데이터를 병합하는 Power Query 파이프라인을 설정한 후, "월말 3일 프로젝트에서 매주 금요일 20분만 확인하는 일로 바뀌었습니다." 추출 계층은 단순히 시간을 절약하는 것을 넘어, 언제 시간을 투자할 수 있는지를 바꿉니다.
감사에도 견디는 실용적인 허용 오차 프레임워크
허용 오차 규칙은 3방향 매칭을 단순한 조정 작업이 아닌 내부 통제로 만듭니다. PCAOB 감사 기준 2201(SOX 섹션 404 평가를 관장)에 따라, 3방향 매칭은 사후 탐지가 아닌 지급 전 오류를 차단하는 예방 통제로 분류됩니다. 감사관은 허용 오차가 문서화되고, 일관되게 적용되며, 조직을 실질적으로 보호하는 수준으로 설정되었는지 검토하여 예방 통제를 테스트합니다.
방어 가능한 허용 오차 프레임워크는 세 가지 계층으로 구성됩니다:
| 허용 오차 계층 | 일반 범위 | 적용 대상 |
|---|---|---|
| 가격 변동률 (%) | 비계약: ±2%; 계약: ±0% | PO와 송장 간 단가 차이 |
| 수량 변동률 (%) | 벌크 상품: ±5%; 개별 단위: ±0% | 입고 수량과 송장 수량 간 차이 |
| 절대 금액 임계값 | 라인 항목당 $25–$100 | 이 미만이고 변동률이 0.5% 미만이면 자동 승인 |
| 송장 수준 임계값 | 송장당 $500–$5,000 | 이 미만이면 매칭을 2-Way(PO+송장)로 간소화 |
각 임계값에 대한 근거를 문서화하세요. 감사관이 가격 허용 오차가 1%가 아닌 2%인 이유를 물을 때, "그냥 합리적으로 보여서"가 아니라 공급업체 계약 구조, 과거 변동 데이터, 중요성 임계값을 참조한 답변이 필요합니다. 문서화된 근거는 통제입니다. 문서화되지 않은 숫자는 추측일 뿐입니다.
FAQ
Google Sheets로 월 100개 이상의 송장에 대해 3-Way 매칭을 실제로 처리할 수 있나요?
네, 단 한 가지 전제 조건이 있습니다. 매칭 로직 자체는 무한히 확장 가능합니다. VLOOKUP 및 QUERY 함수는 수천 개의 행도 성능 저하 없이 처리합니다. 병목 현상은 데이터 입력입니다. 송장 등록 탭에 100개의 송장을 수동으로 입력하고 있다면, 제약은 스프레드시트가 아니라 바로 여러분입니다. 데이터 추출 단계가 '기술적으로 가능'과 '실질적으로 지속 가능'을 가르는 핵심입니다. 추출이 데이터 입력을 처리하면, 스프레드시트 비교는 볼륨에 관계없이 몇 초 만에 실행됩니다.
수신 부서에서 여전히 수기 로그를 사용하는 경우 어떻게 해야 하나요?
손으로 작성된 수신 로그 사진도 추출이 가능합니다. 추출 도구에서 "PO 번호", "수령 품목", "수량", "날짜"와 같은 열을 정의하고 사진을 업로드하면 AI가 필기체를 읽어 구조화된 열로 변환합니다. 명확한 필기체의 경우 정확도가 높지만, 번지거나 약어가 많이 사용된 항목은 점검(spot-checking)이 필요할 수 있습니다. 대안인 수동 입력(manual transcription)도 동일한 정확도 위험이 있지만 훨씬 더 오래 걸립니다.
단가 매칭에 대한 허용 오차(tolerance)는 어떻게 설정해야 하나요?
고정 계약 가격이 없는 품목은 ±2%부터 시작하고, 계약 가격이 있는 품목은 ±0%로 시작하십시오. 두 번의 지불 주기 후에 예외 사항을 검토하십시오. 가격 플래그가 지정된 항목의 90%가 $1 미만의 차이이며 반올림에 해당하는 경우 허용 오차를 ±3%로 확대하십시오. 가격 불일치가 특정 공급업체에 집중되어 있다면, 문제는 허용 오차가 아니라 해당 공급업체의 청구 관행(billing practice)입니다.
이 접근 방식은 부분 선적(partial shipments)에도 적용되나요?
네, 하지만 첫 번째 부분 선적이 도착하기 전에 정책 결정이 필요합니다. 한 가지 접근 방식: 수령 수량과 청구 수량이 서로 일치하는 경우(둘 다 PO 100개에 대해 40개로 표시됨) 부분 일치로 플래그를 지정하고 나머지 수량을 위해 PO를 열어 둡니다. 두 번째 접근 방식: 첫 번째 수령 및 청구서를 매칭한 후 PO 라인을 마감하고 잔액에 대한 새 라인을 생성합니다. 첫 번째 접근 방식은 PO와 최종 지불 간의 감사 추적(audit trail)을 유지합니다. 두 번째 접근 방식은 스프레드시트에서 추적하기 더 간단합니다. 하나를 선택하여 일관되게 적용하십시오.
여러 PO를 포함하는 청구서는 어떻게 처리해야 하나요?
추출 결과를 매칭 대시보드에 입력하기 전에 PO 번호별로 분할하십시오. 단일 청구서 PDF가 세 개의 PO 번호를 참조하는 경우, 추출된 데이터는 각각 다른 PO 번호를 가진 세 개의 행을 생성해야 합니다. 매칭 대시보드는 PO 번호를 기준으로 조인(join)하므로, 다중 PO 청구서는 세 번의 개별 매칭 작업이 됩니다. 이는 세 개의 단일 PO 청구서와 동일합니다.
SOX를 준수하나요?
스프레드시트 기반 3방향 매칭 프로세스는 세 가지 조건을 충족하면 SOX 섹션 404 요구 사항을 만족할 수 있습니다. (1) 허용 오차 임계값이 근거와 함께 문서화되어야 하며, (2) 매칭 대시보드에는 각 예외를 검토한 사람과 검토 시간을 추적하는 감사 추적이 포함되어야 하고, (3) 승인 후 매칭 결과를 변경할 수 없도록 스프레드시트에 대한 접근이 통제되어야 합니다. 매칭 대시보드에 "검토자" 및 "검토일" 열을 추가하고, 승인 후 시트를 보호하면 테스트 가능한 예방 통제의 핵심 요소를 갖추게 됩니다.
ERP 없는 3방향 매칭의 핵심은 한 가지 질문으로 귀결됩니다. 세 문서를 모두 동일한 구조화된 형식으로 충분히 빠르게 변환하여 비교가 수식 작업이 되고, 세 부서의 조사가 필요 없게 할 수 있습니까? 답이 '예'라면 — 월 50~500장의 송장을 처리하는 대부분의 AP 팀에게 그렇습니다 — 스프레드시트가 나머지를 처리합니다.