벤더 견적서 5개를 일괄 변환하는 방법
Google Sheets 비교 테이블 하나로

공급업체 5곳의 RFQ: 동일한 데이터, 서로 다른 5가지 형식

조달 모범 사례는 일관된 숫자로 수렴합니다. RFQ당 자격을 갖춘 공급업체 3~5곳을 초청하는 것입니다. 3곳 미만이면 경쟁 압박이 생기지 않습니다. 5곳을 초과하면 평가 복잡성이 한계 가격 이점보다 커집니다. Institute for Supply Management와 애리조나 주립대학교의 W. P. Carey School of Business가 공동 후원하는 CAPS Research는 20개 산업 분야에 걸쳐 조달 프로세스를 벤치마킹하며, 3~5곳 범위가 모든 분야의 구조적 기본값입니다(APQC 조달 벤치마킹).

자격을 갖춘 공급업체 5곳은 견적 응답 5건을 의미합니다. 그리고 응답 5건은 서로 다른 5가지 형식을 의미합니다. 공급업체 A는 ERP에서 내보냅니다. 품목 코드, 설명, 단가, 리드 타임이 일관된 테이블로 정리된 깔끔한 PDF입니다. 공급업체 B는 이메일 본문에 견적서를 작성하고 인쇄된 양식을 스캔한 PDF를 첨부합니다. 공급업체 C는 한 번도 본 적 없는 열 라벨이 있는 자체 견적 템플릿을 사용합니다. "Ref." 대신 "Item Code", "Rate" 대신 "Unit Price", "Lead Time" 대신 "Delivery (working days)" 같은 식입니다. 공급업체 D는 행별로 항목을 나열하지만 합계는 3페이지에 넣습니다. 공급업체 E의 PDF는 소규모 지역 유통업체의 수기 견적 양식을 스캔한 것입니다. 가장 비용 경쟁력이 높은 옵션이면서 동시에 디지털화에 가장 노동 집약적인 옵션입니다.

Google Sheets 비교 템플릿은 이러한 다양성에 관심이 없습니다. 깔끔한 열이 있습니다: 공급업체 이름, 품목 설명, 수량, 단가, 품목 합계, 리드 타임, 지급 조건, 납품 조건. 형식 격차 — "지저분한 PDF 5개"와 "깔끔한 스프레드시트 1개" 사이에 있는 것 — 은 바로 당신입니다. 견적 라운드당 60~90분 동안 데이터를 형식 간에 수동으로 옮기는 일입니다.

엔터프라이즈 소프트웨어가 해결합니다 — 엔터프라이즈 가격으로

SAP Ariba와 Coupa는 Source-to-Pay 시장을 장악하고 있으며, 둘 다 2025년과 2026년 가트너 매직 쿼드런트 Source-to-Pay 스위트 부문에서 리더로 선정되었습니다. 이들의 e-소싱 모듈은 정확히 이 문제를 해결합니다: 공급업체에 구조화된 RFQ를 보내고, 표준화된 응답을 받고, 자동 비교 테이블을 생성합니다. PDF를 스프레드시트로 변환할 필요가 없습니다 — 플랫폼이 처음부터 구조를 강제하기 때문입니다.

가격표는 이 작업의 대부분을 수행하는 중소 규모 조달 팀에게 이 도구들을 무의미하게 만듭니다. SAP Ariba는 공급업체 500곳과 사용자 5명을 포함한 중간 규모 배포의 Supplier Lifecycle & Performance 모듈 기준으로 연간 약 $25,000부터 시작합니다. Coupa의 시작 가격은 월 약 $2,500이며, 일반적인 중간 시장 배포는 연간 $200,000~$800,000에 구현 비용 $100,000~$400,000가 추가됩니다. 소기업을 위한 전용 RFQ 도구인 AuraVMS는 월 $5부터 시작하지만 — 공급업체가 자사 플랫폼을 통해 제출해야 하므로, 이미 받은 편지함에 있는 PDF를 처리할 수 없습니다.

조달 소프트웨어 시장은 2024년에 66억 달러로 평가되었습니다. $250,000 이상 배포용으로 만들어진 도구와 월 $5 RFQ 자동화용으로 만들어진 도구는 공통된 가정을 공유합니다: 공급업체가 도구의 제출 형식을 사용할 것이라는 가정입니다. 소규모 조달 팀의 현실은 견적서가 이메일 첨부 파일 — PDF, 스캔된 양식, 가끔은 Excel 파일 — 로 도착하고, 비교는 플랫폼이 요구하는 형식이 아니라 가진 자료로 이루어져야 한다는 것입니다.

시트 중심 시스템의 현실 — 그리고 부족한 것

소규모 기업이나 중견기업의 조달 팀이 수억 원대 Source-to-Pay 스위트를 도입할 수 없을 때, 기본 도구 구성은 단순합니다: Google Sheets로 비교 + Gmail로 PDF 수신 + 수동 데이터 입력으로 연결. 이는 조달 전문성의 부족이 아닙니다. 사용 가능한 도구에 대한 합리적 적응입니다 — Sheets는 실시간 협업, 공유 링크, 수식 기반 점수를 IT 조달이나 벤더 온보딩 없이 제공합니다.

이 구성에서 부족한 것은 분석 계층이 아닙니다. Google Sheets는 조건부 서식, 가중 점수, 피벗 테이블 요약을 어떤 조달 플랫폼만큼 잘 처리합니다. 부족한 것은 수집 계층입니다 — 다섯 개의 PDF 첨부 파일을 사람의 수작업 입력 없이 다섯 개의 구조화된 데이터 행으로 변환하는 메커니즘입니다.

단일 견적서 추출 — 공급업체 견적서 PDF 하나에서 스프레드시트로 데이터를 가져오는 작업 — 의 경우 단계별 가이드에서 부가기능을 통한 열 이름 추출의 기본을 다룹니다. 일괄 처리는 동일한 사이드바 인터페이스를 기반으로 하지만 단일 파일 규모에서는 존재하지 않는 과제를 도입합니다: 서로 다른 용어를 사용하는 공급업체 간 일관된 열 매핑, 일부 견적서에만 나타나는 필드 처리, 그리고 소스 형식과 관계없이 모든 행이 동일한 열 구조에 정렬되는 비교 준비 완료 테이블 생성.

열 이름 추출이 다섯 가지 다른 견적서 형식을 통합하는 방법

일관되지 않은 형식에서 일괄 처리를 가능하게 하는 엔진은 열 이름 추출입니다: 각 공급업체 PDF에서 데이터를 찾을 위치를 도구에 알려주는 대신 — 필드 주위에 박스를 그리고 공급업체별 템플릿을 만드는 대신 — 추출하려는 내용을 알려줍니다. 비교 열을 한 번 정의합니다: "공급업체 이름 / 품목 설명 / 단가 / MOQ / 리드 타임(일) / 지급 조건." AI는 페이지에서의 위치가 아니라 의미적으로 이해하여 각 문서에서 각 값을 찾습니다.

이것이 공급업체 간 용어 문제를 해결하는 메커니즘입니다. 공급업체 A의 PDF는 필드를 "Rate"로 표시합니다. 공급업체 B는 "Unit Price"로 표시합니다. 공급업체 C는 "Price Per Each"로 표시합니다. 템플릿 기반 도구는 세 가지 다른 필드 이름을 보고 세 가지 별도 구성을 요구합니다. 열 이름 추출은 세 가지 모두 동일한 조달 개념 — 단가 — 을 가리킨다는 것을 인식하고 자동으로 동일한 출력 열에 매핑합니다. 이것이 추출과 이해의 차이입니다: 전통적인 OCR은 위치에 따라 텍스트 문자열을 추출하고, 열 이름 추출은 의미적 역할에 따라 데이터 포인트를 추출합니다.

실제 RFQ 라운드의 형식 다양성 — ERP 생성 PDF 하나, 이메일 본문 텍스트 하나, 스캔된 수기 양식 하나 — 에 대해 추출 접근 방식은 세 가지 모두 동일합니다. 공급업체별로 열 정의를 변경하지 않습니다. 형식별로 템플릿을 훈련하지 않습니다. 한 번 정의한 열 이름은 배치의 모든 문서에서 동일한 테이블에 행을 생성합니다.

배치 워크플로: 5개 파일을 한 번에 업로드하고 하나의 테이블로

Google Sheets 부가기능은 스프레드시트 안에서 열리는 사이드바 패널로, 비교 시트와 같은 창과 탭의 확장 프로그램 메뉴에서 접근할 수 있습니다. 웹사이트에서 견적서를 처리하고 파일을 내보낸 뒤 Sheets로 가져오는 별도의 도구가 아닙니다. 스프레드시트 안에서 실행되는 추출 인터페이스 자체이며, 활성 시트가 직접적인 출력 대상이 됩니다.

배치 벤더 견적 비교에서 이 구조가 중요한 이유는 한 가지입니다. 사이드바가 5개의 견적 PDF를 받아 동일한 열 정의를 사용해 모두에서 데이터를 추출하고, 모든 결과를 연속된 행으로 현재 보고 있는 시트에 바로 기록합니다. 다운로드 버튼도, "CSV를 Sheets로 가져오기" 단계도, 중간 대시보드도 없습니다. 지원되는 필드 유형, 형식, 플랜 세부 정보 등 전체 기능에 대한 자세한 내용은 Google Sheets 추출 기능 페이지를 참조하세요.

배치 워크플로는 세 단계로 이루어집니다:

누락 필드 문제: 공급업체 A는 지급 조건을 명시하지만 공급업체 B는 명시하지 않는 경우

단일 견적서 워크플로에서 누락된 필드는 사소한 불편일 뿐입니다. "N/A"를 입력하거나 셀을 비워 두고 넘어가면 됩니다. 그러나 동일한 비교 테이블에 입력되는 5개 견적서 배치에서는 누락된 필드가 구조적 문제를 만듭니다. 공급업체 A가 지급 조건에 "Net 30"을 명시했지만 공급업체 B의 견적서에 지급 조건이 전혀 언급되지 않았다면 비교 열에 공백이 생깁니다. 지급 조건을 포함한 가중 기준으로 공급업체를 평가하는 경우, 공급업체 B의 누락 데이터는 조건이 더 나쁘기 때문이 아니라 명시하지 않았기 때문에 점수를 낮춥니다.

부가기능은 일관된 전략으로 누락된 필드를 처리합니다: 정의한 열이 공급업체 문서에 나타나지 않으면 해당 공급업체의 해당 열 출력 셀은 비워 둡니다. 오류 없음, 자리 표시자 텍스트 없음. 빈 셀 — 필드를 찾을 수 없어 데이터를 수동으로 입력할 때 만들었을 바로 그 상태입니다.

이것은 비교 테이블에 적합한 동작입니다. 조건부 서식으로 누락된 셀을 강조할 수 있습니다. 점수 공식은 빈 셀을 0이 아닌 "제공되지 않음"으로 처리할 수 있습니다. 한 공급업체가 필드를 누락해도 출력 구조는 깨지지 않습니다. 모든 행은 동일한 순서로 동일한 열을 가지며, 원본 문서에 데이터가 없었던 위치는 공백으로 남습니다.

실제로 다중 공급업체 견적서 비교에서 누락된 필드는 예외가 아니라 표준입니다. r/procurement의 조달 전문가는 9단계 수동 프로세스로 구성된 표준 RFQ 절차를 설명하면서 5단계 — "공급업체가 제공한 항목과 요청한 항목 간 포함/제외 비교" — 가 가장 시간이 많이 걸리는 단계라고 언급했습니다. 일부 공급업체는 구조화된 응답 대신 브로셔를 보냅니다. 일부는 품목별로 항목을 나열하지만 필요한 요약 필드는 건너뜁니다. 일부 PDF에는 모든 데이터가 있지만 4페이지에 걸쳐 분산되어 있고 합계는 4페이지에 묻혀 있습니다. 추출 방식은 이 모든 경우를 처리합니다. 데이터가 문서 어디에든 있으면 AI가 의미론적 의미로 찾아 올바른 열에 매핑합니다. 데이터가 없으면 셀은 공백입니다. 템플릿이 깨지지 않고, 행 정렬이 어긋나지 않으며, 수동 조정이 필요 없습니다.

속도 배수: 한 번의 세션에서 5개 견적서 처리 vs. 5번의 개별 세션

일괄 처리의 효율성 향상은 단순 합산이 아니라 구조적인 차이입니다. 사이드바에서 견적서 하나를 처리하는 데는 약 15~30초가 걸립니다. PDF를 업로드하면 AI가 정의된 필드를 찾아내고 데이터가 시트에 표시됩니다. 견적서 5개를 하나씩 처리하는 경우(업로드 5회, 개별 추출 5회) 총 약 2~3분이 소요되며, 각 파일을 열고 업로드를 확인하는 시간이 추가됩니다. 이는 이미 수동 데이터 입력보다 10~20배 빠른 속도입니다. 수동 입력은 견적서당 읽기, 각 필드 찾기, 입력에 약 3분이 걸립니다.

일괄 처리는 이를 더욱 압축합니다: 견적서 파일 5개를 한 번에 선택하여 업로드하고, 추출 세션을 한 번 시작하면 5개 행이 모두 시트에 표시됩니다. 5건의 추출은 순차적으로 실행됩니다(각 파일을 읽고, 각 값 세트를 찾고, 각 행을 추가) — 하지만 일괄 처리는 한 번만 시작하면 됩니다. 공급업체 5곳의 RFQ 라운드의 경우, 파일 선택부터 Sheets에 비교 가능한 행이 생성될 때까지 전체 데이터 추출 단계는 2분 미만으로 완료됩니다.

월간 누적 효과에서 구조적 차이가 분명하게 드러납니다. 주 1회 RFQ 라운드를 진행한다면(월 4회, 각각 공급업체 5곳 비교), 수동 데이터 입력만으로 월 4~6시간이 소요됩니다. 사이드바를 통한 일괄 추출은 이를 8분 미만으로 줄입니다. 이는 2배 개선도, 5배 개선도 아닙니다. 약 45배의 절감 효과입니다 — "반나절이 반복되는 작업"에서 "커피를 마시는 동안 끝나는 작업"으로 바뀌는 것입니다.

여러 카테고리에 걸쳐 견적서를 처리하는 조달 팀의 경우 — 원자재는 한 공급업체 그룹에서, 포장재는 다른 그룹에서, 물류 서비스는 또 다른 그룹에서 — 주간 RFQ 작업량은 3~4개의 별도 견적 라운드에 달할 수 있습니다. 각 라운드당 60~90분이 소요되면 수동 비교는 조달 전문가의 한 주에서 가장 큰 비중을 차지하는 활동이 됩니다. 이는 조달 전문가가 소싱 작업에 하루 평균 2시간 45분을 소비하며, 그중 상당 부분이 전략적 평가가 아닌 데이터 통합에 쓰인다는 데이터와 일치합니다.

벤더 견적서를 넘어: 문서 유형별 일괄 처리

부가기능 사이드바의 일괄 처리 메커니즘은 문서 유형에 관계없이 동일하게 작동합니다 — 열은 달라지지만 워크플로는 동일합니다. 조달 업무를 수행하면서 동일한 Google Sheets 추적 시스템을 통해 공급업체 인보이스도 처리한다면, 인보이스 일괄 처리 워크플로우도 동일한 패턴을 따릅니다: 인보이스 열을 정의하고, 모든 공급업체 인보이스를 한 번에 업로드하고, 하나의 원장 테이블을 얻습니다. 조달 역할이 비용 정산까지 확장된다면, 지출 보고서 일괄 처리도 동일하게 작동합니다 — 팀의 월간 제출분을 업로드하면 하나의 환급 테이블을 얻습니다. 그리고 조직에서 벤더 견적서와 함께 세금 목적의 영수증을 추적한다면, 영수증 일괄 처리 가이드에서 영수증 볼륨에 대한 동일한 사이드바 패턴을 다룹니다.

Sheets 사이드바 대신 웹 인터페이스를 통해 작업하는 경우 — ImageToTable.ai 웹사이트에 업로드하고 Excel로 내보내는 경우 — 일반 벤더 견적 일괄 비교 가이드에서 동일한 열 이름 추출 메커니즘을 사용하는 웹 기반 워크플로우를 다룹니다. 추출 엔진은 동일하며, 전달 방식만 다릅니다.

공통점은 Google Sheets가 이미 기록 시스템이라는 것입니다 — 벤더 비교, 인보이스 추적, 비용 정산 모두에서. 부가기능은 스프레드시트를 대체하지 않습니다. 스프레드시트에 입력되는 데이터 입력 작업을 대체합니다. 서로 다른 용어를 사용하는 5개의 벤더 견적서를 처리하는 동일한 열 이름 추출은 서로 다른 레이아웃의 30개 공급업체 인보이스와 서로 다른 POS 시스템의 100개 영수증도 처리합니다. 사이드바는 Sheets 기반 시스템 아키텍처에서 항상 빠져 있던 수집 계층입니다.

이미 Google Sheets에서 벤더 견적서를 수동으로 비교하는 팀 — 하지만 가중 점수, 조건부 서식, 그리고 스프레드시트가 복잡해질 때 발생하는 문제를 포함한 전체 비교 프레임워크도 원하는 팀 — 을 위해 일반적인 벤더 견적 비교 실수 문서에서 일괄 추출이 해결하지 못하는 스프레드시트 측 함정을 다룹니다. 그리고 수동 견적 비교가 여전히 의미가 있는지에 대한 더 넓은 질문에 대해서는 수동 vs. AI 비교 워크플로우에서 추출이 선택 사항이 아닌 필수가 되는 손익분기점을 살펴봅니다.

자주 묻는 질문

이 부가기능은 공급업체별로 여러 품목이 포함된 견적서를 처리할 수 있나요?

네. 공급업체의 견적서에 여러 품목이 포함된 경우, 반복되는 구조를 포착하도록 열을 정의하면 됩니다: "품목 설명 / 수량 / 단가 / 품목 합계." AI는 이 필드들이 각 품목마다 반복된다는 것을 인식하여 품목별로 별도의 행을 생성합니다. 따라서 공급업체 A에 5개의 품목이 있으면 동일한 공급업체 이름에 서로 다른 품목 데이터가 있는 5개의 행이 생성됩니다. 비교 목적으로 피벗 테이블이나 QUERY 함수를 사용하여 시트에서 공급업체별로 그룹화할 수 있습니다.

한 공급업체가 다른 통화로 견적을 제시하면 어떻게 하나요?

부가기능은 문서에 표시된 그대로 값을 추출합니다. 공급업체 A가 USD로, 공급업체 B가 EUR로 견적을 제시하면 추출된 숫자는 원래 통화를 반영합니다. 통화 간 비교를 위해 "통화" 열을 추가하고 인접 열에 GOOGLEFINANCE 수식을 사용하여 변환하세요. 예: =GOOGLEFINANCE("CURRENCY:EURUSD") — 각 행에 한 번씩 적용합니다. 추출 자체는 통화를 변환하지 않으며, 페이지에 있는 그대로를 포착합니다.

공급업체마다 다른 열 이름을 설정해야 하나요?

아니요. 한 번 설정한 열 정의("단가", "MOQ", "리드 타임" 등)는 각 공급업체가 사용하는 용어와 관계없이 모든 공급업체에 적용됩니다. 이것이 열 이름 추출의 핵심 메커니즘입니다. AI는 "Rate", "Price Per Each", "Unit Price"가 모두 동일한 조달 개념을 가리킨다는 것을 인식합니다. 공급업체별로 매핑을 구성할 필요가 없습니다.

이 부가기능은 스캔된 손글씨 견적서에도 작동하나요?

네. AI 엔진은 스캔된 문서와 손글씨 텍스트를 디지털 PDF와 동일한 방식으로 처리합니다. 손글씨 인식 정확도는 가독성에 따라 달라집니다 — 명확한 블록체는 인쇄된 텍스트만큼 안정적으로 추출되지만, 매우 양식화된 필기체나 빽빽한 손글씨는 정확도가 낮을 수 있습니다. 엔진은 시각적 언어 모델을 통해 인쇄된 텍스트와 손글씨를 모두 식별하며, 인쇄된 데이터의 경우 최대 99%의 인식 정확도를 제공합니다. 손글씨 견적서의 경우 구매 결정의 기초로 사용하기 전에 출력 결과를 검토해야 합니다.

5개 이상의 공급업체를 비교해야 하면 어떻게 되나요?

사이드바의 일괄 업로드는 한 세션에서 5개, 10개, 20개 등 파일 수에 관계없이 처리합니다. 유일한 제한은 동일한 브라우저 세션에서 파일을 업로드해야 한다는 점입니다. 배치당 파일 제한은 없습니다.