추출된 BOL 데이터를
수작업 재입력 없이 TMS에 공급하는 방법

진짜 문제는 추출이 아니라 — 추출과 TMS 사이의 간극입니다

BOL에서 데이터를 얻는 것은 방정식의 해결된 절반입니다. 현대 AI 추출은 모든 운송사 형식(Maersk, MSC, Hapag-Lloyd 또는 지역 NVOCC 하우스 빌)에서 화주 이름, 수하인 세부 정보, 컨테이너 번호, 중량 및 항구 정보를 몇 초 만에 추출할 수 있습니다. 더 어려운 절반은 그 다음에 일어나는 일입니다: 추출된 데이터는 스프레드시트에 남아 있고, TMS는 사람이 입력하기를 기다립니다.

"데이터 추출"과 "TMS에 데이터 입력" 사이의 이 간극은 포워더가 매일 몇 시간씩 잃는 지점입니다. 한 포워더가 Reddit에 말했듯이: "제가 이야기한 대부분의 포워더는 수동 데이터 입력에 빠져 있으며, 그 시간을 화물 예약이나 고객 관리에 쓰고 싶어 합니다." (출처)

문제는 운송사 다양성으로 인해 더욱 복잡해집니다. Hapag-Lloyd BOL은 선박 이름을 오른쪽 상단 헤더 블록에 배치하고, MSC BOL은 로고 아래 표 셀에 넣으며, 지역 NVOCC의 하우스 빌은 본문 텍스트에 묻어 둘 수 있습니다. 이러한 문서를 읽는 운영자는 모든 문서에서 각 필드를 시각적으로 찾은 다음 일치하는 TMS 필드에 다시 입력해야 합니다 — 반복해서 말입니다. 하루에 30개의 BOL을 처리하는 중간 규모 포워더는 운영 작업이 시작되기 전에 순수한 전사 작업에 5~7시간을 소비합니다 (출처). 선적당 수동 BOL 입력 비용은 단순한 생산성 항목이 아니라 — 여러분의 책상을 통과하는 모든 컨테이너에 부과되는 숨은 세금입니다.

하지만 해결책은 TMS를 교체하거나, 청구 파이프라인을 재구축하거나, 팀을 재교육할 필요가 없습니다. 여러분에게 필요한 것은 TMS가 이미 가지고 있는 가져오기 도어의 형태에 맞는 브리지입니다 — 그리고 모든 TMS에는 하나가 있습니다.

모든 TMS에는 가져오기 기능이 있습니다 — 여기에서 확인하세요

추출 도구를 평가하기 전에 TMS의 가져오기 경로를 알아두세요. 포워더가 사용하는 모든 주요 시스템은 구조화된 데이터 가져오기를 지원합니다 — 일반적으로 CSV 또는 Excel을 통해 — 하지만 경로와 필드 요구 사항은 플랫폼마다 다릅니다.

CargoWise One. 대량 업로드 엔진은 사전 형식화된 Excel 또는 CSV 템플릿을 허용하며, 최종 제출 전에 데이터 정확성, 형식 및 중복을 확인하는 내장 검증 기능이 있습니다. 직접 프로그래밍 방식 통합의 경우 CargoWise는 XML을 허용하는 eHub 및 Universal Gateway API를 제공합니다 — 그러나 CargoWise 버전이 업데이트됨에 따라 개발자 참여와 지속적인 유지 관리가 필요합니다 (출처). CSV 가져오기 경로는 IT 지원 없이 모든 사용자가 사용할 수 있습니다.

Descartes Forwarder TMS. SaaS 기반 플랫폼은 웹 기반 아키텍처를 통해 구조화된 데이터 업로드를 허용하며, 일반적으로 CSV 매핑을 통해 이루어집니다. Descartes는 또한 통신 및 통관 신고를 위한 EDI를 지원합니다 — 그러나 내부 BOL 데이터 입력의 경우 CSV 가져오기가 대부분의 포워딩 팀에게 가장 진입 장벽이 낮은 방법입니다.

SAP Transportation Management. SAP TM은 NWBC 인터페이스를 통해 화물 주문 생성을 처리하며, 프로그래밍 방식 통합을 위해 서비스 인터페이스(SOAP/XML)를 통해 데이터를 수락합니다. 전담 SAP TM 개발자가 없는 팀의 경우 SAP의 데이터 마이그레이션 도구를 통한 구조화된 파일 업로드가 사용자 지정 코드 없이 실용적인 대안을 제공합니다.

BluJay / E2open TMS. 이 플랫폼은 가져오기 파이프라인을 통해 가격 책정, 입찰 및 자동화된 화물 할당을 지원하며, CSV와 EDI가 일반적인 데이터 입력 형식입니다.

이 모든 시스템의 패턴은 동일합니다: TMS는 이미 구조화된 데이터를 수집하는 방법을 알고 있습니다. 병목 현상은 TMS가 아니라 — 모든 필드를 수동으로 입력하지 않고 BOL 데이터를 구조화된 형식으로 만드는 것입니다. 그 격차를 해소하면 나머지 워크플로우는 그대로 유지됩니다.

추출 결과를 TMS 가져오기 템플릿에 맞게 구성하기

대부분의 자동화 시도를 무산시키는 핵심 문제는 미묘합니다. 추출이 끝난 뒤에도 누군가는 TMS 가져오기 형식에 맞게 출력을 다시 정리해야 한다는 점입니다. CargoWise 대량 업로드 템플릿이 B열에 "Ref No"를 요구하는데 추출 결과가 D열에 "PRO Number"를 넣는다면, 수작업 단계를 다른 수작업 단계로 바꾼 것에 불과합니다. 그래서 자동화를 시도한 팀에서도 수작업 BOL 입력이 계속되는 이유가 바로 이것입니다. 재구성 단계가 절약한 시간을 다시 잡아먹기 때문입니다.

해결책은 처음부터 추출 열 이름을 TMS 가져오기 템플릿에 맞추는 것입니다. 이 방식, 즉 열 이름 기반 추출은 기존 OCR과 다르게 작동합니다. 페이지의 모든 텍스트를 스캔해서 나중에 파싱해야 할 파일로 덤프하는 대신, TMS가 요구하는 정확한 필드 이름("SHIPPER_NAME", "CONTAINER_NO", "VESSEL_VOYAGE")을 지정합니다. 추출 엔진은 데이터가 레이아웃의 어디에 있는지가 아니라 무엇을 의미하는지를 이해하여 각 BOL 페이지 어디에서든 해당 값을 찾아냅니다. Maersk BOL, MSC BOL, 지역 NVOCC 하우스 빌 — 동일한 열 구성으로 세 가지를 모두 읽습니다. 운송사별 템플릿 설정 없이 모든 운송사의 BOL 데이터를 구조화된 열로 추출할 수 있습니다.

CargoWise 가져오기 템플릿이 "SHIPPER", "CONSIGNEE", "CONTAINER", "WEIGHT_KG", "VOYAGE"를 요구한다면, 그 정확한 이름을 추출 열로 설정하세요. 추출된 출력은 처음부터 매핑된 상태로 도착합니다. 열 헤더가 TMS 가져오기 템플릿과 일대일로 일치합니다. CSV로 내보내고 바로 가져오면 됩니다. 재구성도, 열 재정렬도, 수동 변환 테이블도 필요 없습니다. 한 번만 설정하면 이후의 모든 BOL이 동일한 경로를 따릅니다.

동일한 원리는 모든 TMS에 적용됩니다. Descartes 가져오기 매핑, SAP TM 데이터 마이그레이션, BluJay CSV 수집 — 모두 구조화된 필드 이름을 받아들입니다. 유일한 변수는 TMS 가져오기 템플릿이 요구하는 특정 필드 이름이며, 그것도 한 번만 설정하면 됩니다.

일괄 처리는 이를 더욱 확장합니다. 8개 운송사의 BOL 20장을 한 번에 업로드하고, TMS 매핑 열 헤더가 적용된 단일 CSV로 함께 추출한 다음, 전체 배치를 TMS 대량 업로드 한 번으로 가져올 수 있습니다. BOL당 처리 시간이 분 단위에서 초 단위로 줄어듭니다.

운송사 PDF에서 TMS 레코드까지: 종단 간 경로

다음은 CargoWise One을 사용하는 포워더를 위한 구체적인 워크스루입니다. 하지만 이 패턴은 CSV 가져오기 기능이 있는 모든 TMS에 적용됩니다.

BOL 3건의 총 소요 시간: 2분 미만, 대부분이 검토 단계입니다. 동일한 BOL 3건을 수동으로 입력하면 30~45분이 걸리며, 컨테이너 번호와 중량의 수동 전사 오류율이 높아 대부분의 팀이 어차피 두 번째 검토 주기를 구축합니다. 검토 단계를 추가하는 것이 아니라 30분의 타이핑을 30초의 확인으로 대체하는 것입니다.

변하지 않는 것: 다운스트림 워크플로우는 그대로 유지됩니다

이 부분은 기존에 작동하던 파이프라인을 망가뜨 솔루션으로 인해 피해를 본 모든 분에게 가장 중요한 섹션입니다. CSV 가져오기를 통해 TMS로 들어오는 데이터는 TMS 인터페이스를 통해 수동으로 입력된 데이터와 구조적으로 동일합니다 — 시스템은 그 차이를 인식하지 못합니다. 송장 발행 모듈은 동일한 필드에서 데이터를 가져옵니다. 통관 신고는 동일한 레코드를 참조합니다. 고객 포털에는 동일한 배송 상태가 표시됩니다.

송장 발행. TMS가 배송 레코드에서 송장을 자동 생성하든, 청구 팀이 수동으로 생성하든, 송장이 참조하는 송하인 및 수하인 정보, 중량, 컨테이너 정보는 동일한 데이터 구조에서 채워집니다. 송장 템플릿은 변경되지 않습니다. 청구 워크플로우를 재설계할 필요도 없습니다. 미수금 팀은 불일치하는 참조 번호에 대한 문의가 줄어든 것 외에는 아무런 차이도 느끼지 못합니다.

통관 신고. CargoWise의 자동 통관 항목은 기존 배송 레코드에서 송하인, 수입자, 선하증권 데이터를 가져옵니다. 통관 모듈은 항상 그랬던 것처럼 동일한 위치에서 데이터를 읽습니다. 통관 신고서의 컨테이너 번호 전사 오류는 검사 지연을 초래할 수 있습니다 — 그리고 추출 엔진은 교대 근무가 끝나갈 무렵의 지친 작업자와 달리 숫자를 전치하지 않습니다.

고객 커뮤니케이션. 추적 포털, 이정표 알림, 배송 상태 이메일은 모두 TMS 배송 데이터에서 데이터를 가져옵니다. 시스템 관점에서 데이터 소스는 변경되지 않았습니다 — 데이터가 시스템에 입력되는 방식만 변경되었을 뿐입니다. 다운스트림은 동일한 레코드에서 동일한 필드를 읽습니다.

이것이 워크플로우 통합 논쟁의 핵심입니다: 추출 레이어는 이미 작동하는 모든 것의 업스트림에 위치합니다. 입력 방식을 변경할 뿐, 시스템 자체를 변경하지는 않습니다. 적재장에 컨베이어 벨트를 추가하는 것과 같다고 생각하세요 — 창고, 재고 시스템, 트럭은 변하지 않습니다.

CSV 브리지가 직접 API 통합보다 더 적합한 경우

두 경로 모두 작동합니다. 선택은 볼륨, 기술 리소스, 그리고 실시간 데이터 흐름이 얼마나 긴밀하게 필요한지에 따라 달라집니다.

직접 API 통합 — CargoWise eHub, SAP TM 서비스 인터페이스, Descartes EDI 커넥터 — 은 중간 CSV 단계 없이 추출된 데이터를 TMS 레코드로 직접 푸시합니다. 배포는 일반적으로 4~8주가 소요되며, 발견, 구축, 테스트, 그리고 라이브 오픈을 포함합니다(출처). 장점: 추출과 TMS 입력 사이에 수동 단계가 전혀 없습니다. 비용: XML 스키마 매핑을 위한 개발자 노력, TMS API가 발전함에 따른 지속적인 유지보수, 그리고 다른 TMS로 이전되지 않는 공급업체별 구현이 필요합니다. EDI 및 직접 API 접근 방식은 나름의 가치가 있지만, 구현에 드는 노력은 실질적입니다.

반면 CSV 브리지는 구조화된 파일 가져오기를 허용하는 모든 TMS(사실상 모든 TMS)와 호환되며, 초기 열 구성 이후에는 IT 개입이 전혀 필요 없고, 몇 주가 아닌 1시간 미만으로 설정할 수 있습니다. 절충점: 추출과 가져오기 사이에 30초의 검토 단계가 있습니다.

월 50~500건의 BOL을 처리하는 포워더의 경우, CSV 브리지가 거의 항상 올바른 시작점입니다. 구현 노력의 일부만으로 시간 절약 효과의 대부분을 제공합니다. BOL 처리를 100건에서 1,000건으로 확장하는 것은 첫날 API 통합을 요구하지 않습니다. CSV 브리지를 작동하게 만드는 열 매핑 규율이 필요하며, 이는 나중에 직접 API에 투자할 때 스키마 사양이 됩니다.

볼륨이 증가하여 그 30초 검토 간격이 매주 몇 시간으로 누적되는 시점이 되면, API 경로가 투자 가치가 생깁니다 — 그리고 이미 확립된 열 매핑은 개발자에게 전달할 정확한 사양이 됩니다.

자주 묻는 질문

BOL이 스캔된 PDF나 운전자가 찍은 휴대폰 사진으로 도착하면 어떻게 하나요?

최신 AI 추출은 스캔된 페이지, 휴대폰 사진, 네이티브 PDF를 모두 읽을 수 있으며 PDF에 텍스트 레이어가 필요하지 않습니다. 운전자가 창고 게이트에서 찍은 종이 BOL 사진도 디지털로 생성된 Maersk PDF와 동일한 추출 결과를 제공합니다. 여백에 손으로 적은 수하인 메모나 수정 사항도 인쇄된 필드와 함께 읽힙니다.

매주 다른 운송사에서 BOL을 처리해도 되나요?

네 — 바로 이 점이 이 방식의 가장 큰 장점입니다. 템플릿 기반 도구는 각 운송사 형식에 맞는 레이아웃을 학습시켜야 합니다. 열 이름 추출은 데이터의 의미("이 페이지에서 선박 이름은 무엇인가?")를 찾기 때문에 위치("선박 이름은 x=300, y=450 좌표에 있다")가 아닌 어떤 운송사의 BOL이든 읽을 수 있습니다. 동일한 열 구성으로 Maersk BOL, MSC BOL, 지역 NVOCC 하우스 빌을 운송사별 설정 없이 처리할 수 있습니다. 다중 운송사 BOL Excel 추출은 재구성 없이 모든 형식에서 작동합니다.

BOL에서 추출해야 할 TMS 필드는 무엇인가요?

대부분의 포워딩 워크플로우를 포괄하는 최소 필드: 송하인 이름 및 주소, 수하인 이름 및 주소, 통지 당사자, 선박 이름, 항차 번호, 적재항, 양하항, 컨테이너 번호, 봉인 번호, 화물 설명, 총중량 및 순중량, 개수, MBL 번호, HBL 번호. LTL 화물에는 PRO 번호를 추가하세요. 사용하는 열 이름은 TMS 가져오기 템플릿이 기대하는 것과 정확히 일치해야 합니다 — 기억이 아닌 템플릿에서 복사하세요.

단일 문서에 여러 컨테이너가 나열된 BOL은 어떻게 처리하나요?

CONTAINER_NO와 SEAL_NO를 별도 열로 설정하세요. 추출 엔진은 다중 컨테이너 BOL을 컨테이너별 행으로 분할합니다 — 각 행에는 자체 컨테이너 번호, 봉인 번호, 관련 중량이 포함되므로 TMS는 컨테이너당 하나의 행을 받습니다. 이는 대부분의 TMS 플랫폼이 화물 기록을 기본적으로 구성하는 방식과 일치합니다.

추출된 데이터에 오류가 있으면 어떻게 하나요?

추출과 가져오기 사이의 검토 단계가 안전망 역할을 합니다. 이 단계는 자동화로 대체되지 않으며, 이는 의도적인 설계입니다. 추출된 스프레드시트를 열고 컨테이너 번호와 중량을 원본 PDF와 대조하여 확인한 후, 가져오기 전에 잘못된 필드를 수정하세요. 이 30초 검토는 완전 자동화 시스템이 완벽히 처리하지 못하는 예외 상황(번짐이 있는 PDF 스캔, BOL 여백의 수기 수정, 비표준 단위로 기재된 중량)을 잡아냅니다. 절충점은 명확합니다. 수동 입력 10~15분이 목표 검증 30초로 줄어듭니다.

이 방식은 세관 및 규제 요건을 준수하나요?

데이터 정확도가 향상됩니다. 추출 엔진은 모든 운송사 형식에 일관된 해석을 적용하여, 특히 긴 컨테이너 번호와 단위 변환에서 수동 입력 시 발생하는 전사 오류를 제거합니다. 세관 신고에서 데이터 정확도는 선택 사항이 아닙니다. 신고서의 컨테이너 번호 오류는 검사 지연을 초래할 수 있습니다. 가져오기 전 검토 단계가 규정 준수 체크포인트 역할을 합니다. 다양한 운송사의 BOL 필드에 걸친 데이터 정확도는 본질적으로 어려운 문제이며, 어떤 시스템도 모든 것을 완벽히 잡아내지는 못하지만, 추출과 목표 검토의 조합은 피로한 작업자의 수동 전사보다 확실히 더 신뢰할 수 있습니다.

Excel 대신 Google Sheets에서도 사용할 수 있나요?

네. 추출 결과물은 Google Sheets로 직접 내보낼 수 있습니다. 팀이 TMS에 데이터를 입력하기 전 운영 추적을 위해 Sheets를 사용한다면, 흐름은 다음과 같습니다: BOL 데이터를 Sheets로 추출 → 검토 및 확인 → Sheets에서 CSV로 내보내기 → TMS에 가져오기. ImageToTable.ai의 Google Sheets 사이드바 애드온을 사용하면 스프레드시트 작업 공간을 벗어나지 않고 BOL 데이터를 시트에 직접 추출한 다음, 검토된 CSV를 TMS 업로드용으로 내보낼 수 있습니다.

데이터 입력 직원을 더 고용하는 것과 어떻게 다른가요?

데이터 입력 직원은 BOL 1건당 10~15분이 소요되고, 운송사 형식 차이에 대한 교육이 필요하며, 물량이 늘수록 오류도 함께 증가합니다. 인력 추가는 운송 물량에 비례하여 비용이 선형적으로 증가합니다. CSV 브리지는 한계 비용이 거의 0에 가깝게 확장됩니다. BOL 100건을 처리하는 데 드는 문서당 시간은 10건을 처리할 때와 거의 동일합니다. 작업자의 역할은 데이터 입력에서 예외 처리(플래그가 지정된 필드 검토 및 예외 사례 해결)로 전환되며, 이는 더 높은 가치의 업무입니다.

CSV 브리지는 제품이 아니라 방법론입니다. 구조화된 열을 출력하는 모든 추출 도구와 CSV 가져오기를 지원하는 모든 TMS에서 작동합니다. 핵심은 첫날부터 추출 열 이름을 TMS 가져오기 템플릿에 맞추는 것으로, 대부분의 자동화 시도를 실패하게 만드는 재구성 단계를 제거합니다. 받은 편지함에서 BOL PDF를 꺼내 가져오기 템플릿 열을 한 번 매핑하고, 문서당 10분이 30초로 줄어드는지 확인해 보세요. 자체 BOL로 테스트해 보세요 — 오늘 구축하는 브리지는 내일 개발자에게 넘겨줄 API 스키마가 됩니다.