선하증권 데이터 추출
완벽 가이드
선하증권은 단일 문서가 아닙니다. 기명식 선하증권, 해상 선하증권, 복합운송 선하증권, 마스터 및 하우스 선하증권 등 법적으로 구별되는 여러 문서 유형의 집합이며, 각각 다른 필드, 다른 발행 기관, 다른 데이터 목적지를 갖습니다. 하루에 100건의 B/L을 처리하는 포워더는 점심 전에 5개 운송사의 8가지 서로 다른 문서 레이아웃을 접할 수 있습니다. 한 가지 B/L 유형에서는 작동하지만 다음 유형에서는 실패하는 추출은 추출이 아니라 수동 대체가 필요한 부분 솔루션입니다. 이 가이드는 모든 유형, 모든 운송사, 그리고 TMS가 기대하는 모든 표준 코드에 걸쳐 B/L 데이터를 안정적으로 추출하기 위해 실제로 알아야 할 사항을 다룹니다.

핵심 요점
- 선하증권용 템플릿 기반 추출은 50개 운송사에 걸쳐 750개의 좌표 사각형을 유지 관리해야 함을 의미합니다. Maersk가 컨테이너 번호를 오른쪽 상단 영역에서 페이지 중간으로 옮기면, 누군가 템플릿을 편집할 때까지 해당 운송사가 보내는 모든 B/L에서 빈 필드가 생성됩니다.
- 부조리함은 단순히 유지 관리 부담만이 아닙니다. 템플릿 변경 때마다 잘못 읽은 컨테이너 ID가 TMS, 고객 추적 포털 또는 세관 신고에 도달할 새로운 기회가 생기며, 컨테이너가 3일 동안 사라진 것을 아무도 알아차리기 전에 발생합니다.
- 단일 의미론적 열 정의가 750개 템플릿 전체를 대체하고 추출 중에 ISO 6346 체크 디지트를 기준으로 컨테이너 번호를 검증합니다. 체선료 시계가 돌기 시작한 후가 아니라 추출 레이어를 떠나기 전에 잘못 입력된 숫자를 잡아냅니다.
BOL 추출이 다른 문서 추출과 다른 점

대부분의 문서 추출 관련 글은 선하증권을 배가 그려진 송장처럼 취급합니다. 이런 가정에서 만들어진 도구는 데모에서는 잘 작동하지만 실제 운영에서는 실패합니다. BOL이 다른 어떤 문서보다 구조적으로 다른 이유는 다음과 같습니다.
법적으로 구별되는 다섯 가지 문서 유형, 하나의 추출 파이프라인. 기명식 선하증권은 특정 수하인을 지정하며 양도할 수 없습니다. LTL 트럭 운송에서 흔히 볼 수 있는 가장 단순한 형태입니다. 해상 선하증권은 양도가 가능하며 헤이그-비스비 규칙에 따라 선하증권의 권리증서 역할을 합니다. 원본을 보유한 사람이 누구든 화물을 청구할 수 있습니다. 복합운송 선하증권은 복합운송서류에 관한 UNCTAD/ICC 규칙에 따라 해상, 철도, 트럭 구간을 단일 문서로涵盖합니다. 그리고 모든 포워더가 매일 처리하는 분할이 있습니다. 운송인이 포워더에게 발행하는 마스터 선하증권(MBL)과 포워더가 화주에게 발행하는 하우스 선하증권(HBL)입니다. 동일한 화물에 대한 두 문서로, 컨테이너 번호와 항구 같은 필드를 공유하지만 발행인 이름, 참조 번호, 운임 지불 조건은 다릅니다.
각 유형은 필드를 다르게 배치합니다. 머스크 해상 선하증권은 컨테이너 번호를 선박 이름 옆 오른쪽 상단 사분면에 배치합니다. MSC 선하증권은 화물 설명 그리드 위 페이지 중간에 배치합니다. 하우스 선하증권은 마스터 선하증권을 상호 참조하는 HBL 참조 번호를 추가합니다. 기명식 선하증권에는 전혀 없는 필드입니다. 다섯 가지 유형을 유형별 구성 없이 처리할 수 없는 추출 도구는 팀이 화물을 운송하는 대신 템플릿을 유지 관리하게 만듭니다.
데이터는 단순히 읽히기만 하면 안 됩니다. 변환되어야 합니다. BOL에는 선적항이 "CNSHA", "Shanghai" 또는 "Port of Shanghai, CN"으로 표시될 수 있습니다. TMS는 1981년부터 유엔 유럽 경제 위원회(UNECE)가 관리하는 249개국 100,000개 이상의 위치를涵盖하는 5자리 UN/LOCODE인 CN SHA를 기대합니다. BOL에는 운송인 이름이 "Maersk Line"으로 인쇄될 수 있지만 TMS는 NMFTA가 관리하는 SCAC 코드 MAEU를 요구합니다. 품목에는 세계관세기구가 관리하고 200개 이상의 국가에서 사용하는 조화 시스템인 HS 코드가 필요하며, "woven polypropylene bulk bags"와 같은 자연어 화물 설명을 6305.33에 매핑해야 합니다. 일반 텍스트를 출력하는 BOL 추출 도구는 완성된 것이 아닙니다. 표준화된 코드를 출력하는 도구가 완성된 것입니다.
이것이 BOL 추출을 송장 추출이나 영수증 추출과 다른 문제로 만드는 핵심 과제입니다. BOL 데이터 추출의 전체 정의와 TMS 데이터 입력과 같은 인접 개념과의 차이점은 BOL 데이터 추출이란 무엇인가 가이드를 참조하세요.
전통적인 OCR과 템플릿 기반 방식이 BOL에서 실패하는 이유
템플릿 기반 OCR은 레이아웃이 통제된 문서를 위해 설계되었습니다. 선하증권(BOL)은 모든 수준에서 그 가정을 깨뜨립니다.
다중 운송사 형식의 폭발적 증가. 하루에 100건의 BOL을 처리하는 화물 중개인은 자사 화주가 어떤 운송사를 이용했는지 통제할 수 없습니다. 해당 BOL은 머스크(MAEU), MSC(MSCU), CMA CGM(CMDU), 하팍로이드(HLCU), COSCO(COSU), ONE(ONEY), 에버그린(EMCU) 및 수십 개의 지역 트럭킹 회사 각각의 고유한 형식으로 도착합니다. 템플릿 기반 OCR은 운송사 형식별로 각 필드 주변에 경계 상자를 그려야 합니다. 50개 운송사와 BOL당 15개 필드의 경우, 정의하고 유지 관리해야 할 좌표 사각형이 750개입니다. 어떤 운송사가 양식을 업데이트하면 해당 템플릿은 조용히 깨져서, 누군가 세관의 B/L 수정 수수료 패턴을 알아차릴 때까지 올바른 열에 잘못된 데이터를 생성합니다.
손글씨, 도장, 카본 카피는 예외 사항이 아닙니다. 적재장에서 작성된 BOL은 깨끗한 디지털 PDF가 아닙니다. 수하인 이름은 펜으로 휘갈겨 썼습니다. 개수는 빨간색 잉크로 도장이 찍혔습니다. 운임 조건("PREPAID")은 마커로 동그라미 쳤습니다. 스캔본은 3세대 카본 카피로, 원본의 텍스트가 화물 설명 필드로 번져 보입니다. 전통적인 OCR은 도장을 노이즈로, 카본 번짐을 추가 문자로, 90 DPI 미만의 손글씨를 읽을 수 없는 것으로 처리합니다. 그러나 BOL에서 이러한 "노이즈" 요소는 운송사 송장 분쟁을 가장 자주 유발하는 세 가지 데이터 포인트를 전달합니다.
NMFC 화물 등급은 의미론적 이해를 필요로 합니다. 전미 자동차 화물 분류(NMFC) 시스템은 밀도, 적재 용이성, 취급 및 책임에 따라 18개의 화물 등급(50~500)을 정의합니다. BOL에는 상품 설명 "목재 가구, KD" 옆에 "Class 70"이 나열되거나, 등급 없이 상품만 나열되어 운송사가 적용하도록 할 수 있습니다. 템플릿 OCR은 둘 다 동일한 상자의 텍스트 문자열로 읽습니다. 의미론적 추출은 "Class 70"이 "목재 가구"를 수식하며 화물 등급 열에 속하고 상품 설명 열에 속하지 않음을 이해합니다. 이 구분은 운임 청구서의 정확성 여부를 결정하며, 3주 후에 300달러의 재분류 수수료가 발생하는지를 결정합니다.
이 세 가지 실패 모드는 복합적으로 작용합니다. 운송사별 템플릿이 필요하고, 손글씨를 읽을 수 없으며, 화물 등급과 상품 설명을 구분하지 못하는 도구는 인건비를 절감하는 것이 아니라 원래 데이터 입력 작업만큼 큰 검토 대기열을 생성하는 것입니다.
최신 AI 추출이 선하증권을 읽는 방식
수동 B/L 데이터 입력을 대체하는 파이프라인은 입력부터 시각적 이해, 필드 매핑, 표준화, 출력까지 이어집니다. 비전 AI 모델이 B/L 페이지를 읽고 위치가 아닌 의미로 필드를 매핑하는 단계별 메커니즘에 대한 전체 내용은 B/L 데이터 추출 가이드를 참조하세요. 여기서 더 자세히 다룰 부분은 실제 B/L 추출 도구와 일반 문서 판독기를 구분 짓는 단계인 표준화와 코드 검증입니다.
주요 B/L 필드와 이를 검증하는 표준
모든 B/L 추출 프로젝트는 어떤 필드가 중요한지 정의하는 것에서 시작합니다. 아래 표는 모든 물류 운영에 필요한 5개 그룹, 각 그룹의 세부 필드, 그리고 추출된 값이 단순히 존재하는 것뿐 아니라 올바른지 판단하는 검증 표준을 다룹니다.
| 필드 그룹 | 추출 필드 | 검증 표준 | 중요한 이유 |
|---|---|---|---|
| 당사자 | 송하인 이름 및 주소, 수하인, 통지처, 운송사/SCAC 코드 | SCAC (NMFTA): 2~4자리 운송사 코드; EU 세관용 EORI 번호 | 잘못된 배송은 일당 $100~500의 체선료를 유발하며, 잘못된 통지처는 선적 도착을 놓치게 합니다 |
| 운송 경로 | 선적항, 양하항, 수령지, 인도지, 선박/항차, 컨테이너 번호, 봉인 번호 | UN/LOCODE (UNECE): 5자리 코드; ISO 6346: 컨테이너 검증 숫자 | ISF 신고는 선적 24시간 전에 정확한 항구 코드를 요구하며, 컨테이너 ID 불일치는 세관 보류를 초래합니다 |
| 화물 | 품목 설명, 포장 개수 및 포장 유형, 총중량 (kg/lbs), 순중량, 부피/치수, 화물 등급, NMFC 코드, HS 코드 | NMFC: 18개 화물 등급 (50~500); HS: 6자리 국제 코드 + 국가별 확장 코드; SOLAS VGM: 2016년 7월부터 컨테이너 검증 총중량 필수 | 화물 등급 재분류는 건당 $150~300의 비용이 들며, HS 코드 오류는 부족분의 최대 10배에 달하는 세관 벌금을 초래합니다 |
| 운임 및 조건 | 운임 지불 조건, 해상 운임, 벙커 할증료, 터미널 처리비, 추가 요금 | 인코텀즈 2020: 비용/위험 이전 시점 정의 | 잘못된 운임 지불 조건은 이미 포워더에게 지불한 고객에게 비용을 청구하는 등 잘못된 당사자에게 청구하게 됩니다 |
| 참조 정보 | B/L 번호, HBL/MBL 상호 참조, 예약 번호, PO/상업 송장 참조, 픽업 날짜, 배송 날짜/ETA | 운송사별 형식 상이, 두 문서를 모두 처리하는 포워더의 HBL과 MBL 간 상호 참조 검증 | B/L 번호가 TMS에 없으면 운송 추적이 불가능하며, 배송 기간을 놓치면 서비스 수준 약속이 훼손됩니다 |
컨테이너 번호 체크 숫자는 특히 유용한 검증 게이트입니다. ISO 6346에 따라 각 컨테이너 식별자는 3자리 소유자 코드, 1자리 장비 유형 식별자, 6자리 일련 번호, 그리고 앞의 문자들로 계산된 체크 숫자로 구성됩니다. 추출 결과가 MSKU 907082 3인데 실제 컨테이너가 MSKU 907082 8이라면, 체크 숫자 불일치가 즉시 오류를 표시합니다 — 그 컨테이너 번호가 TMS, 고객 추적 포털 또는 세관 신고에 도달하기 전에 말입니다. 추출 중 이 검증을 수행하는 도구는 컨테이너가 터미널에서 분실될 때까지 살아남는 오류를 잡아냅니다.
화물 그룹은 모든 B/L에서 데이터 밀도가 가장 높은 섹션이며 오류 발생 가능성도 가장 높습니다. 또한 운송사별로 가장 크게 달라지는 섹션이기도 합니다. 어떤 B/L은 개별 중량과 통합 화물 등급으로 5개의 품목 라인을 나열하고, 다른 B/L은 모든 것을 "FAK" 한 줄로 통합합니다. 또 다른 B/L은 화주가 손으로 적은 HS 코드를 여백에 추가합니다. B/L 추출 도구는 운송사별 레이아웃을 알 필요가 없습니다. 각 데이터 유형이 운송사와 화주가 표현하는 모든 방식에서 어떤 형태인지 알아야 합니다.
배치 처리: 다중 운송사 B/L, 하나의 스프레드시트로

B/L 추출은 한 번에 하나의 문서가 아니라 수십 또는 수백 건을 단일 실행으로 처리하는 배치 작업에서 진정한 가치를 발휘합니다. 바로 여기서 일괄 우선 처리 설계 원칙이 중요해집니다.
아침 이메일에서 받은 B/L 80건을 처리하는 포워더를 생각해 보세요. 이 80개 문서는 12개 운송사에서 왔을 수 있고, 4가지 B/L 유형에 걸쳐 있으며, 깨끗한 디지털 PDF와 지역 트럭킹 업체의 스캔한 카본 사본이 섞여 있을 수 있습니다. 이러한 규모를 처리하는 워크플로우는 다음과 같습니다:
1. 모든 B/L을 한 번에 업로드합니다. 운송사별 분류나 B/L 유형별 사전 분류가 필요 없습니다. 배치는 PDF, JPG, PNG, 다중 페이지 문서를 구분 없이 수용합니다.
2. 열을 한 번 정의합니다. 동일한 15~20개 열 이름이 배치의 모든 B/L에 적용됩니다. AI가 매핑을 처리합니다: 기명식 선하증권을 만나면 해당 열을 비워 둡니다. 다중 라인 화물 그리드가 있는 해상 선하증권을 만나면 품목 라인별로 별도의 행으로 확장합니다. 문서별 구성이 필요 없습니다.
3. 예외 사항만 검토합니다. AI가 높은 신뢰도로 추출한 필드는 자동으로 통과됩니다. 신뢰도가 낮은 필드는 사람의 검토를 위해 플래그가 지정됩니다. 물류 담당자는 문서 80건당 5~10개의 플래그 필드를 확인하는 대신 1,200개 필드를 수동으로 입력하지 않습니다. 이것이 데이터 입력 작업을 대체하는 것과 단순히 "데이터 검토"로 이름을 바꾸는 것의 차이입니다.
4. 출력 파일 하나. 결과는 단일 Excel 스프레드시트입니다 — B/L당 한 행이며, 정의한 필드와 일치하는 열로 구성됩니다. 이 출력은 스프레드시트 네이티브입니다: Excel 또는 Google Sheets에 바로 들어가 TMS 가져오기에 바로 사용할 수 있습니다. Google Sheets를 사용하는 팀은 B/L-to-TMS 워크플로우를 통해 사이드바 애드온으로 스프레드시트 내부에서 추출을 실행하여 파일 전달 단계를 완전히 제거할 수 있습니다. 통합 오버헤드 없이 배치 처리를 확장하는 방법에 대한 자세한 내용은 다중 운송사 배치 B/L 추출을 참조하세요.
내보내기 옵션: 추출된 데이터를 필요한 곳으로 보내기

추출된 B/L 데이터의 목적은 하나입니다: 다른 시스템에 입력되는 것입니다. 어떤 시스템이냐는 운영 방식에 따라 다릅니다. 선택하는 내보내기 경로는 추출과 워크플로우 사이에 남는 수동 작업의 양을 결정합니다.
Excel / CSV 내보내기
대상: 파일 업로드로 TMS에 가져오는 팀
추출된 B/L 데이터를 XLSX 또는 CSV로 다운로드하세요. 열을 TMS 가져오기 템플릿에 매핑하세요 — CargoWise, Descartes, McLeod 등은 CSV 가져오기를 지원합니다. 파일 하나, 가져오기 한 번, 타이핑 없음.
Google Sheets 추가 기능
대상: 스프레드시트로 운영하는 팀
Google Sheets 사이드바 추가 기능을 사용하면 추적 스프레드시트를 벗어나지 않고 B/L을 업로드하고, 추출 열을 정의하고, 구조화된 데이터를 현재 시트에 직접 추가할 수 있습니다. 추출은 팀이 이미 사용하는 도구 안에서 이루어집니다.
API 통합
대상: 자체 시스템을 갖춘 대량 운영
REST API가 B/L 파일을 받아 필드별 신뢰도 점수가 포함된 JSON 또는 CSV 형식의 구조화된 데이터를 프로그래밍 방식으로 반환합니다. 시스템은 낮은 신뢰도의 추출 결과를 자동으로 사람 검토로 보내고 높은 신뢰도의 결과를 TMS로 바로 전송할 수 있습니다.
올바른 내보내기 경로는 운영 규모와 기술 리소스에 따라 달라집니다. 하루 50건의 B/L이라면 Excel 내보내기 + TMS 가져오기로 충분합니다. 하루 500건이라면 수동 파일 전달이 새로운 병목이 됩니다. 대부분의 팀은 Excel 내보내기로 시작하고, 규모가 개발 작업을 정당화할 때 API 통합으로 전환합니다. 추출 엔진은 두 경로를 모두 지원해야 하므로 내보내기 방식을 바꿔도 도구를 바꿀 필요가 없습니다.
BOL 추출 도구 선택 방법
다섯 가지 기준이 실제 업무용 BOL 볼륨을 처리하는 도구와 깨끗한 디지털 문서를 가끔 사용하는 도구를 구분합니다.
1. 운송사별 설정 없이 다중 운송사 처리. 핵심 테스트: Maersk 해상 BOL, MSC 해상 BOL, Old Dominion 직송 BOL, 지역 LTL 운송사의 스캔된 카본 사본을 동일한 배치, 동일한 열 정의로 처리하고 단일 템플릿도 생성하지 않아야 합니다. 도구가 운송사별로 필드 위치를 정의하도록 요구한다면, 추출 도구가 아닌 템플릿 유지보수 작업을 구매하는 것입니다.
2. 표준 코드 검증 및 정규화. 도구는 컨테이너 번호를 ISO 6346 체크 디지트 규칙에 따라 검증하고, 항구 이름을 표준 형식으로 정규화하며, "Maersk", "MAERSK LINE", "MAEU"가 동일한 운송사를 의미함을 인식해야 합니다. 이 계층이 없으면 수동 입력을 수동 데이터 정리로 대체하는 것일 뿐, 동일한 노동력에 다른 단계일 뿐입니다.
3. 다중 페이지 및 라인 항목 수준 추출. 컨테이너 화물이 포함된 해상 BOL은 종종 3~5페이지에 달합니다. 상품 설명, 컨테이너 번호, 봉인 번호, 패키지 수량이 계속 페이지에 걸쳐 분산됩니다. 첫 페이지만 읽는 도구는 데이터의 절반을 추출하지 못합니다. 각 상품 행이 별도의 데이터 행이 되는 라인 항목 지원은 통관 분류 및 재고 조정에 필수적입니다.
4. 필드 수준 신뢰도 점수. 실제 물류 운영에서 받는 다양한 문서 품질에 대해 100% 완전 자동 처리를 달성하는 추출 도구는 없습니다. 중요한 것은 도구가 어떤 필드를 확신하지 못하는지 알려준다는 점입니다. 추출된 각 필드별 신뢰도 표시기를 통해 팀은 불확실한 추출만 검토하고 나머지는 하위 시스템으로 직접 흐르도록 신뢰할 수 있습니다.
5. 일괄 처리 우선 설계 및 통합 출력. 하루 5건의 선적에서는 BOL을 하나씩 처리해도 괜찮습니다. 50건에서는 배치 업로드, 배치 처리, 단일 통합 출력이 필요합니다. 도구는 처음부터 배치 워크플로우를 위해 설계되어야 하며, 다중 선택 대화상자 뒤에서 문서를 순차적으로 처리하는 "배치 모드"를 나중에 추가한 것이 아니어야 합니다.
실제로 받는 BOL, 실제로 거래하는 운송사의 문서로 이 기준을 테스트하십시오. 단일 운송사의 깨끗한 디지털 BOL 데모는 화요일 아침 15개 운송사에서 온 40개의 BOL 배치를 도구가 어떻게 처리하는지에 대해 아무것도 증명하지 않습니다.
자주 묻는 질문
AI 추출이 처리할 수 있는 BOL 유형은 무엇인가요?
템플릿 없는 AI 추출 도구는 동일한 설정으로 모든 주요 BOL 유형(직선 BOL, 해상 BOL, 복합/복합운송 BOL, 마스터 BOL(MBL), 하우스 BOL(HBL))을 처리합니다. AI는 템플릿 위치가 아닌 의미를 기준으로 필드를 식별하므로, 트럭 운송 회사의 직선 BOL과 머스크의 해상 BOL이 동일한 열 정의를 통해 처리됩니다. BOL 유형별 필드가 있는 문서의 경우, 모든 문서 유형에 필요한 필드의 합집합을 정의하면 도구가 특정 문서에 없는 필드는 비워둡니다.
BOL 추출 시 ISO 6346에 따라 컨테이너 번호를 검증할 수 있나요?
일부 도구는 가능하지만, 모든 도구가 그렇지는 않습니다. ISO 6346 컨테이너 번호 검증은 추출 후 검증 계층으로, 전사 오류가 TMS에 도달하기 전에 포착합니다. 컨테이너 검증이 워크플로에 중요하다면, 공급업체에 추출 파이프라인에 이 단계가 포함되어 있는지 확인하세요. 추출된 체크 디지트와 계산된 체크 디지트가 일치하지 않으면 해당 필드에 사람의 검토가 필요함을 표시해야 합니다.
BOL 추출이 필기 입력과 독(dock) 수준 BOL을 처리할 수 있나요?
네, 한계는 있습니다. 최신 비전 AI 모델은 판독 가능한 필기에서 BOL 필드를 높은 정확도로 읽을 수 있습니다. 그러나 심하게 바랜 카본지, 필기 위에 겹쳐진 스탬프, 또는 스캔 가능한 표시를 생성하기에는 펜 압력이 너무 약한 문서에서는 정확도가 떨어집니다. 이러한 경우, 잘 설계된 추출 도구는 추측을 출력하는 대신 낮은 신뢰도 점수로 필드를 표시하여 사람이 검토하도록 합니다.
추출 시스템은 화물 세부 정보가 계속 페이지에 있는 다중 페이지 BOL을 어떻게 처리하나요?
최신 추출 시스템은 다중 페이지 BOL의 모든 페이지를 단일 문서로 수집하고 추출된 필드를 하나의 출력 레코드로 병합합니다. 당사자 정보는 일반적으로 1페이지에 있습니다. 화물 세부 정보, 컨테이너 번호, 봉인 번호 및 패키지 수는 종종 계속 페이지에 나타납니다. 도구는 이들이 동일한 선적에 속한다는 것을 인식하고 결합합니다. 여러 줄의 화물 설명의 경우 각 상품 라인은 헤더 필드가 반복된 별도의 출력 행이 됩니다. 이는 TMS가 라인 항목 수준 데이터에 대해 기대하는 형식입니다.
AI가 하우스 BOL과 마스터 BOL을 구분할 수 있나요?
네. 하우스 BOL과 마스터 BOL은 발행자 정보가 구조적으로 다릅니다. HBL은 포워더가 발행하고, MBL은 선사가 발행합니다. AI는 이러한 구조적 차이를 인식하고 동일한 배치에서 두 유형을 모두 추출하여 공통 필드를 동일한 열에 매핑하면서 HBL 참조 번호나 선사 예약 번호와 같은 유형별 필드는 별도로 처리합니다.
선사가 동일한 BOL 필드에 다른 이름을 사용하면 어떻게 되나요?
이것이 바로 의미론적 추출이 템플릿 기반 접근 방식보다 확실히 우세한 부분입니다. 선사 A가 필드를 "Shipper"로, 선사 B가 "Shipper/Exporter"로, 선사 C가 "Consignor"로 표시할 때 AI는 이 세 가지 모두 동일한 주체, 즉 운송을 위해 화물을 제공하는 당사자를 의미한다는 것을 이해합니다. 출력 열을 "송하인 이름"으로 한 번 정의하면 AI가 각 선사의 변형을 해당 열에 자동으로 매핑합니다. 선사별 필드 매핑, 변환 테이블 또는 "선사가 Maersk이면 A열, 선사가 MSC이면 B열"과 같은 로직이 필요하지 않습니다.
추출된 BOL 데이터를 TMS에 직접 입력할 수 있나요?
대부분의 추출 도구는 Excel 또는 CSV로 내보내며, 이를 플랫폼의 표준 가져오기 기능을 통해 TMS로 가져올 수 있습니다. CargoWise, Descartes, Turvo, McLeod와 같은 플랫폼은 구조화된 파일 가져오기를 지원합니다. 추출 결과를 내보내고 열을 TMS 가져오기 템플릿에 매핑한 후 업로드하면 됩니다. 파일 전달 없이 직접 푸시하려면 REST API가 있는 도구를 프로그래밍 방식으로 통합할 수 있습니다. 팀이 Google Sheets를 통해 운영을 실행하는 경우 사이드바 애드온 접근 방식을 사용하면 TMS 가져오기에 사용되는 스프레드시트에 BOL 데이터를 직접 추출할 수 있습니다. 파일 다운로드 및 업로드 주기가 필요 없습니다.
다른 운송사에서 발행한 B/L에서 기대할 수 있는 정확도는 어느 정도인가요?
최신 AI 추출 기술은 주요 운송사(Maersk, MSC, CMA CGM, Hapag-Lloyd, COSCO, ONE, Evergreen)가 발행한 깨끗한 디지털 B/L에서 필드 수준 정확도 95~99%를 달성합니다. 저해상도 스캔, 심한 카본지 훼손, 또는 손으로 작성된 독(Dock) B/L의 경우 정확도가 떨어지지만, 동일한 문서에 대한 템플릿 OCR보다는 여전히 훨씬 높습니다. 중요한 지표는 단순 정확도가 아닙니다. 바로 신뢰할 수 있는 처리량입니다. 즉, 수동 개입 없이 처리되는 B/L의 수입니다. 신뢰도 점수와 함께 필드 수준 정확도 95%를 달성하면 약 5%의 필드만 검토하면 됩니다. 20개 필드 추출 기준으로 B/L당 약 1개 필드입니다. 이는 80개 문서 배치에서 80개 필드를 검토하는 것과 1,600개 필드를 수동으로 입력하는 것의 차이입니다.
B/L 추출이 관세사를 대체할 수 있나요?
아닙니다. B/L 추출은 데이터 입력 단계, 즉 B/L에서 필드를 읽어 구조화된 형식으로 변환하는 작업을 자동화합니다. 면허를 보유한 관세사가 제공하는 규제 판단을 대체하지는 않습니다. 추출은 타이핑 작업을 없애 관세사가 전문성이 필요한 분류 및 규정 준수 결정에 시간을 투자할 수 있게 합니다. 추출이 더 넓은 물류 문서 환경에 어떻게 적용되는지에 대한 전체 설명은 B/L 추출이란 무엇인가에 대한 가이드를 참조하시고, B/L이 전체 선적 서류와 어떻게 조정되는지에 대해서는 선적 및 화물 문서 추출 가이드를 참조하세요.
선적 데이터를 얻는 데 있어 B/L 추출과 EDI의 차이점은 무엇인가요?
EDI는 추출 없이 운송사로부터 직접 구조화된 선적 데이터를 제공합니다. 그러나 EDI는 운송사별 설정, 테스트, 지속적인 유지보수가 필요하며, 많은 중소 운송사와 포워더는 이를 지원하지 않습니다. 실제로 대부분의 물류 운영은 혼합된 형태로 데이터를 받습니다. 주요 운송사에서 정규 노선에 대해 EDI를 사용하고, 나머지 업체에서는 PDF B/L을 받습니다. B/L 추출은 PDF 측면을 처리합니다. 두 접근 방식은 경쟁 관계가 아니라 상호 보완적입니다. 전체 비교는 EDI와 AI B/L 추출을 참조하세요.
B/L 추출은 느린 데이터 입력 프로세스를 더 빠르게 만드는 것이 아닙니다. 그 단계 자체를 없애는 것입니다. 즉, 운영자가 자신이 만들지 않은 문서에서 필드를 옮겨 적고, 외워야 했던 운송사 약어를 사용하고, 오타를 감지할 수 없는 TMS에 입력하는 단계를 제거합니다. B/L이 수신함과 TMS 사이에 머무는 모든 시간은 고객이 선적을 추적할 수 없고, 세관 신고가 시작되지 않았으며, 운송사 송장을 실제 수령 화물과 대조할 수 없는 시간입니다. 추출은 이 격차를 몇 초로 줄입니다. 되찾은 시간을 어떻게 활용할지는 여러분의 몫입니다.