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

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

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

이 단계가 존재하는 이유는 PO 데이터가 공급업체의 언어("주문일", "공급업체", "부품 번호")로 도착하는 반면, 재고 시스템은 고유한 언어("TranDate", "VendorName", "PartNumber")를 사용하기 때문입니다. 이 둘 사이를 변환하는 작업은 업로드를 담당하는 사람에게 떨어집니다. 대부분의 팀은 이를 불가피한 것으로 여기지만, 그렇지 않습니다.

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

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

팀이 새로운 데이터 입력 방식을 채택하는 것을 거부할 때, 그 이유는 데이터 입력 자체를 좋아해서가 아닙니다. 취약하지만 기능적인 파이프라인을 구축했고, 변경이 발생하면 "입고가 중단되지는 않을까? 적치는 여전히 작동할까? 사이클 카운트는 어떻게 될까?"라고 묻게 되기 때문입니다. 제대로 설정된 추출-재고 흐름에서 이에 대한 답변은 다음과 같습니다: 그 어떤 것도 변경되지 않습니다.

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

• 입고 — 창고 직원은 이전과 동일하게 재고 시스템에서 PO를 기준으로 입고 상품을 확인합니다. 선적 도착 시 PO는 이미 시스템에 등록되어 있습니다.
• 적치 — 위치, 통로 할당 및 스캔 워크플로우는 영향을 받지 않습니다. 수동 입력과 마찬가지로 가져오기를 통해 재고 기록이 생성됩니다.
• 사이클 카운트 및 실사 — 실제 재고와 시스템 기록을 비교합니다. 기록의 출처(수동 입력 또는 가져오기)는 카운팅 프로세스에 전혀 영향을 미치지 않습니다.
• 공급업체 정산 — AP 팀은 시스템에서 PO와 송장을 매칭합니다. PO 데이터는 이미 존재하며, 매칭 로직은 데이터 입력 방식을 고려하지 않습니다.
• 재주문 트리거 — 최소 재고 수준, 리드 타임 및 재주문 포인트는 출처와 관계없이 시스템 데이터를 기반으로 작동합니다.

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

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

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

이 통합 기법은 재구성 단계를 완전히 없앱니다. 공급업체 문서의 열 머리글("주문 참조", "공급업체", "품목 코드")을 그대로 추출한 후 수동으로 이름을 바꾸는 대신, 추출 열 이름을 재고 시스템이 가져오기 시에 정확히 기대하는 형식으로 지정하는 것입니다.

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

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

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

여러 개의 구매 주문서(예: 다른 공급업체의 PDF 50개)를 한 번에 처리하는 경우 일괄 추출을 사용하면 모든 파일에 동일한 열 이름 매핑이 한 번에 적용됩니다. 배치에 공급업체 형식이 몇 개이든 관계없이 가져올 준비가 된 단일 구조화된 파일이 출력됩니다.

다섯 가지 재고 시스템이 실제로 PO 데이터를 수신하는 방식 — 추출 출력이 일치해야 하는 조건

각 재고 시스템에는 특정 가져오기 형식이 있습니다. 차이는 작지만 결과에 영향을 미칩니다. 한 가지 세부 사항이 잘못되면 전체 가져오기가 실패합니다. 다음은 공식 문서를 기반으로 각 시스템이 요구하는 사항과 이에 맞게 추출 출력을 구성하는 방법입니다.

Fishbowl Inventory

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

• 행 유형 1 — PO 헤더: 첫 번째 열에 "PO" 텍스트가 포함됩니다. 필드에는 PONum, 상태(숫자: 10=견적 요청, 15=승인 대기, 20=발행, 95=기록), 공급업체 이름(대소문자 구분 안 함, 없으면 자동 생성), 수취인 이름, 배송처 이름, 운송업체 이름 및 날짜 필드가 포함됩니다.
• 행 유형 2 — 품목 라인: 첫 번째 열에 "Item" 텍스트가 포함됩니다. 필드에는 POItemTypeID(숫자: 10=구매, 20=반품, 30=외주, 40=배송), 부품 번호(기존 Fishbowl 부품과 일치해야 함), 공급업체 부품 번호, 부품 수량 및 단가가 포함됩니다.

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 개발 리소스가 없는 팀을 위한 실용적인 방법은 다음과 같습니다. 구매 발주 데이터를 스프레드시트로 추출한 후, Katana의 제품 가져오기(CSV 지원)를 사용해 새 자재를 생성하고, 수동으로 구매 발주를 작성하거나 사전 구축된 QuickBooks/Xero 동기화를 활용하는 것입니다. Katana가 QuickBooks Online에 연결되어 있으면 QuickBooks에서 생성된 구매 발주가 자동으로 Katana로 유입됩니다.

NetSuite

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

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

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-재고 CSV 가져오기를 처리합니다.

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

실제 트레이드오프가 있습니다. Google Sheets 방식은 의존성(Zap이 계속 활성화되어야 하고 수식이 정확해야 함)을 추가하는 대신 가시성(팀원 누구나 시트에서 처리 현황을 확인 가능)을 얻습니다. 조달을 한 사람이 처리하는 팀이라면 직접 CSV 가져오기가 더 간단합니다. 여러 사람이 구매 주문 데이터를 다루는 팀이라면 Google Sheets 브리지의 공유 가시성이 추가 구성 요소를 정당화합니다.

60초 사전 가져오기 체크리스트

직접 CSV 가져오기든 Google Sheets 브리지든, 네 가지 사항이 잘못되면 가져오기가 조용히 실패합니다. 업로드 전에 항상 확인하세요:

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

자주 묻는 질문

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

아닙니다. 열 이름 추출은 형식과 관계없이 필드의 의미를 읽습니다. 이것이 공급업체 측의 변경이 필요 없는 메커니즘입니다. 공급업체가 PDF, 이메일 첨부파일, 포털 스크린샷 또는 스캔 이미지를 보내더라도 AI는 사용자가 지정한 데이터를 찾습니다. 공급업체가 표준 템플릿, 포털 또는 새로운 방식을 도입할 필요가 없습니다. 이것이 형식 변화에 취약한 템플릿 기반 추출과 그렇지 않은 의미 기반 추출의 핵심적인 구조적 차이입니다.

내 재고 시스템이 여기에 나열된 5개 중 하나가 아니라면 어떻게 하나요?

열 이름 정렬 원리는 CSV 가져오기를 지원하는 모든 시스템에서 작동합니다. 시스템의 가져오기 문서에서 "[시스템 이름] CSV 가져오기" 또는 "[시스템 이름] 구매 발주 가져오기"를 검색하여 예상하는 정확한 열 헤더를 확인한 후, 이를 추출 열 이름으로 사용하세요. 매핑 단계는 동일하며, 특정 필드 이름만 다릅니다. 시스템이 Katana와 같은 API 기반 가져오기를 사용하고 개발자 액세스 권한이 있는 경우, API 문서에 JSON 필드 이름이 나열됩니다. CSV 헤더 대신 이를 추출 열 이름으로 사용하세요.

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

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

30개 공급업체의 30가지 다른 형식의 PO를 처리하는 경우에도 작동하나요?

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

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

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

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

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

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