PO 데이터를 재고 시스템에 연결하세요
개발자 없이도 가능합니다

추출된 PO 데이터와 재고 시스템 간의 실제 격차는 기술이 아니라 형식 변환입니다

조달 관리자에게 AI 도구가 PO 필드를 스프레드시트로 추출한 후 어떤 일이 일어나는지 물어보면, 업계를 막론하고 같은 답이 돌아옵니다: "파일을 열고, 재고 시스템이 요구하는 대로 열 이름의 절반을 바꾸고, 날짜 형식을 고치고, 공급업체 내부 ID를 찾아보고, 시스템이 요구하면 데이터를 헤더와 라인 항목으로 나눈 다음 CSV로 다시 저장합니다." 그것은 통합이 아닙니다. 그것은 재포맷이며, 가져올 때마다 15~30분을 소모합니다.

이 단계가 존재하는 이유는 PO 데이터가 공급업체의 언어로 도착하기 때문입니다 — "Order Date," "Vendor," "Part #" — 그리고 재고 시스템은 고유한 언어를 사용합니다: "TranDate," "VendorName," "PartNumber." 둘 사이를 변환하는 작업은 업로드를 담당하는 사람의 몫입니다. 대부분의 팀은 이를 불가피한 것으로 여깁니다. 하지만 그렇지 않습니다.

문제는 형식 다양성으로 인해 더욱 복잡해집니다. 30개 공급업체에서 조달하는 제조업체는 30가지 레이아웃의 PO를 받습니다. AI 기반 PO 필드 추출 같은 도구를 사용해 데이터를 깔끔한 스프레드시트로 추출한 후에도, 사람이 읽기에 적합한 구조(공급업체별로 그룹화되고 설명적인 열 헤더 포함)는 재고 시스템의 가져오기 엔진이 수용하는 구조와 일치하는 경우가 드뭅니다. 해결책은 단순히 보기 좋은 것이 아니라 대상 시스템이 실제로 기대하는 바를 이해하는 데 있습니다.

다운스트림 워크플로는 변하지 않습니다 — 그것이 핵심입니다

팀이 새로운 데이터 입력 방식을 도입하는 것을 꺼릴 때, 그 이유가 데이터 입력을 좋아해서인 경우는 거의 없습니다. 그보다는 그 주변에 취약하지만 작동하는 파이프라인을 구축했기 때문이며, 어떤 변화든 "이러면 입고가 깨지지 않을까? 적치(putaway)는 계속 작동할까? 사이클 카운트는 어떻게 되지?"라고 묻게 만듭니다. 제대로 설정된 추출-재고 흐름에서의 답은: 그 어떤 것도 변하지 않는다는 것입니다.

워크플로에서 정확히 동일하게 유지되는 부분은 다음과 같습니다:

• 입고 — 창고 직원은 지금까지 그래왔듯이 재고 시스템에서 PO와 대조하여 입고되는 상품을 확인합니다. 선적이 도착할 때 PO는 이미 시스템에 있습니다.
• 적치 — 빈 위치, 통로 지정, 스캔 워크플로는 영향을 받지 않습니다. 재고 기록은 수동 입력과 마찬가지로 가져오기를 통해 생성되었습니다.
• 사이클 카운트 및 실물 재고 — 이는 실물 재고를 시스템 기록과 비교합니다. 기록의 출처(수동 입력 또는 가져오기)는 카운팅 프로세스에 전혀 영향을 미치지 않습니다.
• 공급업체 정산 — AP 팀은 시스템에서 송장을 PO와 계속 대조합니다. PO 데이터는 거기에 있습니다. 대조 로직은 데이터가 어떻게 입력되었는지 신경 쓰지 않습니다.
• 재주문 트리거 — 최소 재고 수준, 리드 타임, 재주문 시점은 모두 출처와 관계없이 시스템 데이터를 기반으로 작동합니다.

변경되는 유일한 단계는 PO 데이터가 시스템에 입력되는 방식입니다. 누군가 PDF를 읽고 재고 UI에 필드를 입력하는(또는 스프레드시트에 복사한 다음 가져오는) 대신, 데이터는 추출 → 구조화된 출력 → 가져오기로 흐릅니다. 한 단계가 수동 입력을 대체합니다. 그 이후의 모든 것은 그대로 유지됩니다.

새로운 단계(AI 추출 → 구조화된 출력)가 수동 데이터 입력을 대체합니다. 가져오기 이후의 모든 과정은 동일합니다.

추출 열 이름은 원본 문서가 아닌 대상 시스템에 맞춰 지정하세요

이것은 재구성 단계를 완전히 없애는 통합 기법입니다. 공급업체 문서의 열 머리글("Order Ref", "Supplier", "Item Code")에 맞춰 PO 데이터를 추출한 다음 수동으로 이름을 바꾸는 대신, 추출 열 이름을 가져올 때 재고 시스템이 기대하는 형식과 정확히 일치하도록 지정하는 것입니다.

이를 가능하게 하는 메커니즘은 열 이름 추출입니다. "PONum", "VendorName", "PartNumber"와 같이 캡처하려는 데이터 필드를 지정하면, AI가 각 필드의 의미를 이해하여 문서 어디에서든 해당 값을 찾아냅니다. 공급업체가 해당 필드를 어떻게 부르는지는 중요하지 않습니다. "Order Reference", "PO #", "Document No." — 모두 "PONum"으로 매핑됩니다. AI는 라벨이 아닌 의미를 읽기 때문입니다.

이것은 기존 워크플로우를 뒤집습니다. 일반적으로는 먼저 데이터를 추출하고(자연스러운 열 이름 사용), 스프레드시트로 내보낸 후, 재고 시스템의 가져오기 템플릿과 비교하고, 열 이름을 바꾸고, 날짜 형식을 수정한 다음 가져옵니다. 열 이름 정렬 방식은 추출과 형식 지정을 한 번의 과정으로 통합합니다. 출력 파일은 이미 대상 시스템에 맞게 구조화되어 있습니다.

필드가 누락된 PO가 도착하는 경우 — 공급업체가 라인 항목별 배송 날짜를 포함하지 않지만 재고 시스템에 필요한 경우 — 추출 중에 계산 열을 사용하여 그 공백을 채울 수 있습니다. 배송 날짜가 PO 헤더에만 있는 경우, 계산 열이 모든 라인 항목 행에 대해 이를 파생할 수 있습니다. 단가가 누락되었지만 라인 합계와 수량이 있는 경우, 간단한 합계 ÷ 수량 계산으로 채울 수 있습니다. 추출 엔진은 존재하는 데이터를 찾는 것과 암시된 데이터를 파생하는 것 모두를 처리합니다.

여러 PO를 한 번에 처리하는 경우 — 서로 다른 공급업체의 PDF 50개 묶음이라면 — 일괄 추출은 모든 파일에 동일한 열 이름 매핑을 한 번에 적용합니다. 배치에 서로 다른 공급업체 형식이 몇 개 포함되어 있든, 출력 결과는 가져오기 준비가 된 단일 구조화 파일입니다.

다섯 가지 재고 시스템이 PO 데이터를 실제로 받는 방식 — 추출 출력이 맞춰야 할 조건

각 재고 시스템에는 특정 가져오기 형식이 있습니다. 차이는 작지만 결과에 영향을 미칩니다 — 한 가지 세부 사항이 틀리면 전체 가져오기가 실패합니다. 공식 문서를 기준으로 각 시스템이 기대하는 형식과, 이를 충족하도록 추출 출력을 구성하는 방법은 다음과 같습니다.

Fishbowl Inventory

Fishbowl은 북미 제조 및 도매 유통 분야에서 널리 사용됩니다. 구매 주문용 CSV 가져오기는 2가지 행 유형 플래그 시스템을 사용합니다:

• 행 유형 1 — PO 헤더: 첫 번째 열에 "PO" 텍스트가 포함됩니다. 필드에는 PONum, Status(숫자: 10=Bid Request, 15=Pending Approval, 20=Issued, 95=Historical), VendorName(대소문자 구분 없음, 없으면 자동 생성), RemitToName, ShipToName, CarrierName 및 날짜 필드가 포함됩니다.
• 행 유형 2 — 품목 라인: 첫 번째 열에 "Item" 텍스트가 포함됩니다. 필드에는 POItemTypeID(숫자: 10=Purchase, 20=Credit Return, 30=Out Sourced, 40=Shipping), PartNumber(기존 Fishbowl 부품과 일치해야 함), VendorPartNumber, PartQuantity 및 UnitCost가 포함됩니다.

Flag,PONum,Status,VendorName,RemitToName,...
PO,PO-2026-0423,20,Acme Industrial,Acme Industrial,...
Item,10,PART-8842,VP8842-A,250,14.75,...
Item,10,PART-7721,VP7721-B,100,22.30,...

Zoho Inventory

Zoho Inventory는 필드 매핑이 포함된 표준 CSV 가져오기를 제공합니다. Fishbowl의 플래그 시스템과 달리 Zoho는 각 행이 라인 항목을 나타내는 평면 구조를 사용하며, 헤더 수준 필드는 여러 행에 걸쳐 반복됩니다:

• Zoho의 가져오기 페이지에서 샘플 가져오기 템플릿을 다운로드하세요 — 예상되는 정확한 열 헤더와 순서가 포함되어 있습니다.
• 가져오기 중에 CSV 열을 Zoho 필드에 대화식으로 매핑할 수 있습니다. 즉, 열 이름이 Zoho의 필드 이름과 완벽하게 일치할 필요 없이 업로드 단계에서 정렬할 수 있습니다.
• 필수 필드에는 공급업체 이름, 품목 이름, 수량 및 단가가 포함됩니다. 공급업체와 품목 이름은 가져오기 전에 Zoho에 존재해야 합니다.

Vendor Name,Item Name,Quantity,Rate,PONumber,Delivery Date
Acme Industrial,PART-8842,250,14.75,PO-2026-0423,2026-05-15
Acme Industrial,PART-7721,100,22.30,PO-2026-0423,2026-05-15

Cin7 Core

Cin7 Core(이전 DEAR Inventory)는 대부분보다 더 복잡한 RecordType 기반 CSV 구조를 사용합니다. 각 행의 첫 번째 열은 공식 가져오기 문서에 따라 해당 행이 포함하는 데이터 유형을 결정합니다:

• RecordType 값: header, invoice_lines, stock_received, additional_costs, payments, credit_notes, refunds, unstock.
• 헤더 행(열 이름)은 필수입니다 — Cin7은 헤더 줄을 확인하여 CSV 유형을 검증합니다.
• 하나의 파일에 여러 구매 작업을 포함할 수 있습니다(가져오기당 최대 100개 작업).
• 중요한 제한 사항: CSV를 통해 기존 구매 라인을 편집할 수 없습니다 — 가져오기는 새 작업 생성 전용입니다. 기존 라인은 API를 통해 관리해야 합니다.

RecordType,Supplier,OrderNumber,OrderDate,...
header,Acme Industrial,PO-2026-0423,2026-05-10,...
invoice_lines,ITEM-8842,250,14.75,...
invoice_lines,ITEM-7721,100,22.30,...

Katana MRP

Katana는 위의 CSV 중심 시스템들과 다른 접근 방식을 취합니다. 주요 통합 방법은 CSV 가져오기가 아닌 REST API입니다. 이는 더 강력하면서도 비기술 사용자에게는 처음에 더 부담스러울 수 있습니다:

• QuickBooks Online, Xero, Shopify, HubSpot, BigCommerce, WooCommerce와의 기본 통합을 제공합니다.
• API는 제품/변형, 고객/공급업체, 판매 주문, 구매 주문, 재고 조정 및 재고 이전 생성을 지원합니다.
• 웹훅은 주문 수명 주기 변경(생성, 업데이트, 삭제)을 외부 시스템에 알립니다.
• Katana의 파트너 디렉토리에는 맞춤 워크플로우를 구축할 수 있는 통합 파트너가 나열되어 있습니다.

API 개발 리소스가 없는 팀을 위한 실용적인 방법은 다음과 같습니다: PO 데이터를 스프레드시트로 추출한 다음 Katana의 제품 가져오기(CSV 지원)를 사용하여 새 자재를 만들고, 수동 PO 생성 또는 사전 구축된 QuickBooks/Xero 동기화를 진행합니다. Katana가 QuickBooks Online에 연결되어 있으면 QuickBooks에서 생성된 PO가 자동으로 Katana로 흘러 들어갑니다.

NetSuite

NetSuite의 구매 주문 CSV 가져오기는 여기서 다루는 다섯 시스템 중 구조적으로 가장 까다롭습니다. 주요 요구 사항:

• 두 개의 별도 파일 — 하나는 PO 헤더용, 다른 하나는 라인 항목용입니다. 두 파일 모두에 나타나고 정확히 일치해야 하는 외부 ID 필드로 연결됩니다.
• 공급업체 참조는 내부 ID 또는 외부 ID를 사용해야 합니다. 공급업체 이름 문자열은 검증에 실패합니다. 가져오기 파일을 만들기 전에 NetSuite의 공급업체 마스터에서 숫자 공급업체 ID를 조회해야 합니다.
• 날짜 형식: 앞에 0이 없는 M/D/YYYY (03/05/2026이 아닌 3/5/2026).
• 단일 파일 형식에서는 동일한 PO 번호가 헤더와 모든 항목 행에 반복됩니다. 이중 파일 형식에서는 외부 ID가 연결합니다.
• 드롭십 PO는 다른 사용자 정의 양식으로 별도의 가져오기 작업이 필요합니다.

External ID,Order #,Vendor,Vendor Internal ID,Tran Date
EXT-0423-001,PO-2026-0423,Acme Industrial,8842,3/5/2026

External ID,Item,Item Internal ID,Quantity,Rate,Amount
EXT-0423-001,PART-8842,4421,250,14.75,3687.50
EXT-0423-001,PART-7721,3398,100,22.30,2230.00

Google Sheets를 브리지로 — CSV 파일을 완전히 피하고 싶은 팀을 위한 방법

모든 팀이 CSV 파일을 관리하고 싶어 하는 것은 아닙니다. 특히 여러 사람이 처리된 항목과 대기 중인 항목을 확인해야 하는 경우에는 더욱 그렇습니다. 소규모 조달 팀(주당 20-50건의 PO 처리)의 경우, Google Sheets와 노코드 통합 플랫폼을 결합하면 CSV 가져오기 단계를 자동화된 파이프라인으로 대체할 수 있습니다.

이 구성은 세 가지 계층으로 작동합니다:

1. Google Sheets로 추출. 추출된 데이터를 CSV로 다운로드하는 대신 Google Sheet로 직접 전송합니다. ImageToTable.ai는 Google Sheets 애드온을 제공합니다 — Sheets 내 사이드바에서 PDF나 이미지를 업로드하고, 추출할 열 이름을 지정하면 구조화된 데이터가 스프레드시트에 직접 추가됩니다. 파일 다운로드도, 단계 간 형식 변환도 필요 없습니다.
2. 형식 지정 계층. 동일한 Sheet의 전용 탭에 참조 조회 테이블(공급업체 내부 ID, 품목 번호 매핑, 상태 코드 변환)이 보관됩니다. 간단한 VLOOKUP 또는 INDEX/MATCH 수식으로 시스템별 값을 추출 출력에 가져옵니다. 추출 결과 공급업체 열에 "Acme Industrial"이 생성되면, 다음 열의 수식은 NetSuite 공급업체 ID "8842"를 반환합니다. 이 조회 탭은 가져오기마다가 아니라 한 번만 유지 관리하면 됩니다.
3. 재고 시스템으로 푸시. Zapier 및 Make 같은 플랫폼은 Google Sheets를 재고 시스템에 연결합니다. Zap이 새 행을 모니터링하고, 필요 시 데이터를 변환한 다음, 재고 시스템에 해당 PO 레코드를 생성합니다. 직접 커넥터가 없는 시스템의 경우 Skyvia가 Google Sheets-to-inventory CSV 가져오기를 예약 작업으로 처리합니다.

이 접근 방식은 설정 시간(수식과 Zap 구성)이 더 들지만, 파일을 다운로드하고, 열고, 확인하고, 업로드하는 반복적인 수작업을 없애줍니다. 주당 30건의 PO를 처리하는 팀의 경우, 월간 약 5-7시간의 파일 처리 시간을 절약할 수 있습니다 — 초기 설정 2시간의 비용으로 말이죠.

트레이드오프는 분명합니다. Google Sheets 경로는 가시성(모든 팀원이 시트를 확인해 처리 상태를 파악할 수 있음)을 얻는 대신 의존성(Zap이 활성 상태여야 하고 수식이 정확해야 함)이 추가됩니다. 구매를 한 명이 담당하는 팀이라면 직접 CSV 가져오기가 더 간단합니다. 여러 명이 PO 데이터를 다루는 팀이라면 Google Sheets 브리지의 공유 가시성이 추가 복잡성을 정당화합니다.

가져오기 전 60초 점검 목록

직접 CSV 가져오기든 Google Sheets 브리지든 어떤 경로를 선택하든, 네 가지 항목이 잘못되면 조용히 가져오기가 실패합니다. 매 업로드 전에 다음을 확인하세요:

알아두면 좋은 또 하나의 조용한 실패: 인코딩 손상. 특수 문자가 포함된 공급업체 이름(부품 설명의 ™ 기호, 유럽 공급업체 이름의 악센트 모음)은 추출 중에는 그대로 유지되지만 CSV 저장 시 인코딩이 UTF-8에서 ASCII로 변경되면 손상될 수 있습니다. 손상된 문자가 스프레드시트 미리보기에서는 정상으로 보이지만 가져오기 엔진의 문자열 비교에서 실패하기 때문에 발견하기 어렵습니다. 해결책은 간단합니다. 항상 UTF-8 CSV로 저장하고, 도구에 인코딩 옵션이 있다면 다른 옵션을 선택하지 마세요.

자주 묻는 질문

이 기능을 사용하려면 공급업체가 PO를 보내는 방식을 변경해야 하나요?

아니요. 열 이름 추출은 형식과 관계없이 필드의 의미를 읽어내므로 공급업체 측 변경이 필요 없습니다. 공급업체가 PDF, 이메일 첨부 파일, 포털 스크린샷, 스캔 이미지 중 어떤 방식으로 보내든 AI가 지정한 데이터를 찾아냅니다. 공급업체가 표준 템플릿, 포털, 또는 새로운 방식을 도입할 필요가 없습니다. 이것이 형식 변화에 취약한 템플릿 기반 추출과 그렇지 않은 의미 기반 추출의 핵심 아키텍처 차이입니다.

제 재고 시스템이 여기 나열된 다섯 가지 중 하나가 아니라면 어떻게 하나요?

열 이름 정렬 원리는 CSV 가져오기를 지원하는 모든 시스템에서 작동합니다. 시스템의 가져오기 문서에서 "[시스템 이름] CSV import" 또는 "[시스템 이름] import purchase orders"를 검색하여 시스템이 기대하는 정확한 열 헤더를 확인한 후, 이를 추출 열 이름으로 사용하세요. 매핑 단계는 동일하며 특정 필드 이름만 다를 뿐입니다. 시스템이 API 기반 가져오기(예: Katana)를 사용하고 개발자 액세스 권한이 있다면 API 문서에 JSON 필드 이름이 나열되어 있으니 CSV 헤더 대신 이를 추출 열 이름으로 사용하세요.

재고 시스템에 필요한 모든 필드가 없는 PO는 어떻게 처리하나요?

세 가지 방법이 있으며, 노력이 적은 순서대로 나열합니다. 첫째: 추출 중 계산 열을 사용하세요. 시스템이 품목별 납기일을 요구하지만 PO 헤더에만 표시된 경우, 계산 열로 헤더 값을 모든 품목에 할당할 수 있습니다. 단가가 없지만 품목 합계와 수량이 있다면 합계 ÷ 수량으로 채울 수 있습니다. 둘째: PO별로 변하지 않는 값(결제 조건, 배송 방법, 기본 창고 위치)에 대한 소규모 조회 테이블을 유지하고 추출 후 출력에 병합하세요. 셋째: 특정 필드에 기본값을 허용하도록 재고 시스템의 가져오기를 구성하세요(NetSuite의 Import Assistant는 필드 매핑 페이지에서 이를 지원합니다).

30개 공급업체가 30가지 형식으로 PO를 보내도 작동하나요?

네, 작동합니다. 바로 이 지점에서 열 이름 정렬 방식이 템플릿 기반 방식보다 훨씬 큰 시간 절감 효과를 제공합니다. 템플릿 기반 가져오기에서는 공급업체 형식 30개에 대해 가져오기 템플릿 30개가 필요하며, 공급업체의 형식 변경이 발생할 때마다 템플릿을 업데이트해야 합니다. 의미 기반 추출에서는 열 이름을 한 번만 정의하면 되고(재고 시스템의 예상 필드와 일치), AI가 공급업체 측의 형식 변동을 처리합니다. 일괄 처리를 사용하면 30개 PO를 한 번에 처리할 수 있습니다. 추출은 각 파일에 대해 독립적으로 실행되며 동일한 열 이름 매핑을 적용하고, 결과를 재고 시스템 가져오기에 맞게 구성된 단일 출력 파일로 병합합니다.

추출 과정에서 필드를 잘못 가져오면 어떻게 되나요?

가져오기가 실패합니다. 그리고 이는 잘못된 데이터를 조용히 가져오는 것보다 오히려 나은 결과입니다. 대부분의 재고 시스템은 파일을 수락하기 전에 참조 키를 검증합니다. 공급업체 이름이나 부품 번호가 기존 레코드와 일치하지 않으면 가져오기에서 해당 행을 거부하고 오류를 생성합니다. 이렇게 하면 데이터가 시스템에 입력되기 전에 추출 결과를 수정할 기회가 생깁니다. 어떤 재고 시스템도 참조 데이터에 대해 "최선의 추정" 매칭을 수행하지 않습니다. 키가 정확히 일치하거나 행이 거부되거나 둘 중 하나입니다. 일반적인 추출 오류 패턴과 가져오기 전에 이를 잡는 방법은 ERP 가져오기 실패의 여섯 가지 범주와 원인 해결 방법을 참조하십시오.

추출과 재고 시스템 사이의 단 한 단계

"PO 데이터가 추출되었다"와 "재고 시스템에 입력되었다" 사이의 간극은 IT 프로젝트가 필요한 기술 문제가 아닙니다. 열 이름 매핑이 필요한 형식 일치 문제입니다. 재고 시스템이 요구하는 사항(정확한 필드 이름, 참조 키 유형, 날짜 형식)을 알게 되면 추출 결과가 해당 구조로 직접 출력되도록 구성할 수 있습니다. 수동 재포맷 단계는 사라집니다.

PO를 Excel로 처리한 다음 재고 시스템에 다시 입력하는 방식이라면, 열 이름 정렬 방식은 두 단계를 한 번의 패스로 대체합니다. 시스템의 가져오기 형식으로 직접 추출한 다음 업로드하면 됩니다.