운송 및 화물 문서 추출
완벽 가이드

선적 문서 생태계 — 다섯 가지 문서, 하나의 선적

데이터 추출을 시작하기 전에, 물류 팀은 추출 대상 문서와 문서 간의 관계를 파악해야 합니다. 일반적인 FCL(만재 컨테이너) 해상 선적에서는 다음과 같은 5가지 핵심 문서가 생성됩니다.

공통 필드 문제는 즉시 드러납니다. 컨테이너 번호는 BOL, 적하목록, 패킹 리스트, 운임 송장에 모두 나타납니다. BOL 번호는 적하목록, 상업 송장, 운임 송장을 연결합니다. 총중량은 BOL, 적하목록, 패킹 리스트에 명시되지만, 단위가 다른 경우가 많습니다(BOL은 kg, 패킹 리스트는 lb, 적하목록은 미터톤을 사용할 수 있음). 각 문서를 개별적으로 읽는 추출 방식은 서로 일치하지 않는 다섯 개의 데이터 세트를 생성합니다. 반면, 선적 서류 묶음 전체를 고려하여 설계된 추출 방식은 문서들을 함께 읽고 불일치 사항을 식별합니다.

의미론적 AI 추출이 이러한 문서를 기존 OCR과 어떻게 다르게 처리하는지 자세히 알아보려면 물류용 OCR 가이드와 AI OCR의 기본 개념을 참조하십시오.

선하증권 — 핵심 문서

선하증권은 선적 서류 중 법적으로 가장 복잡한 문서입니다. 화물 영수증, 운송 계약, 그리고 양도 가능한 형태의 경우 권리 증서의 역할을 동시에 수행합니다. 필드 수만 봐도 추출이 간단하지 않음을 알 수 있습니다. 일반 해상 BOL은 3-5페이지에 걸쳐 30-40개의 데이터 필드를 포함하며, 여러 국제 표준의 적용을 받습니다.

BOL 유형(직항 vs 해상 vs 복합운송, 마스터 vs 하우스), 추출 파이프라인, 검증을 심층적으로 다룬 BOL 데이터 추출 전용 종합 가이드를 게시했습니다. 여기서는 문서 간 패킷에서 중요한 부분, 즉 다른 모든 선적 문서가 참조하는 필드에 초점을 맞춥니다.

SCAC 코드는 물류에서 가장 흔히 잘못 추출되는 필드이므로 자세히 살펴볼 가치가 있습니다. BOL에는 선사명이 "Maersk Line"으로 인쇄되어 있지만 TMS는 MAEU를 기대할 수 있습니다. 다른 선사는 참조 번호처럼 보이는 SCAC와 함께 이름을 나열할 수도 있습니다. 의미론적 AI 추출은 표준 코드 패턴(영문 대문자 2-4자리, 종종 선사명 또는 SCAC 레이블 근처에 위치)을 인식하여 전체 선사명과 별도의 필드로 추출함으로써 이를 처리합니다. 그러나 모든 추출 도구가 SCAC 코드를 찾도록 설계된 것은 아닙니다. 많은 도구가 선사 필드를 자유 텍스트로 처리하여 시스템에 MAEU가 필요할 때 "Maersk Line"을 출력합니다.

선적 라벨 및 데이터 포인트에 대한 필드 수준 정확도 분석은 관련 기사 AI가 선적 라벨 및 매니페스트 데이터를 추출할 수 있을까?를 참조하십시오.

화물 적하목록 — 선적 단위 재고 목록

화물 적하목록은 선박, 트럭, 항공기 또는 기차에 적재된 모든 선적 화물의 전체 목록입니다. 단일 선적 계약인 BOL과 달리, 적하목록은 다중 선적 재고 목록으로 주로 세관 당국, 항만 운영자 및 터미널 핸들러가 사용합니다.

해상 적하목록은 일반적으로 선박 내 각 BOL당 한 행으로 구성되며, 주요 항목은 다음과 같습니다:

• 마스터 BOL 번호 — 통합 선적을 포괄하는 운송사 발행 BOL
• 하우스 BOL 번호 — 해당되는 경우 각 하주에 대한 포워더 발행 BOL
• 컨테이너 번호 — 각 BOL과 연계된 모든 컨테이너
• 품목 설명 — 종종 약칭 또는 그룹화됨 (예: 통합 컨테이너의 경우 "일반 백화점 상품")
• HS 코드 — 세관용 6~10자리 분류 코드
• 총 중량 및 부피 — BOL별 합계
• 적재항 및 양륙항 — UN/LOCODE 형식
• 송하인 및 수하인 — 이름 및 주소
• 선박명 및 항차 번호 — 해상 적하목록용

적하목록의 형식 문제는 근본적으로 다른 두 가지 구조로 제공된다는 점입니다. 미국행 선적을 위한 CBP 준수 ACE 적하목록은 CBP 1301(입항 화물 적하목록) 또는 CBP 1302(출항) 형식을 따르며, ISF 신고에 필요한 특정 필드가 있습니다. 포워더가 내부적으로 사용하는 상업 적하목록은 완전히 다른 레이아웃을 사용하여 BOL별이 아닌 컨테이너별로 필드를 그룹화할 수 있습니다. 항공 화물 적하목록(AWB 적하목록)은 해상 적하목록과 다른 헤더 구조(선박명 대신 항공편 번호, MBL/HBL 대신 MAWB/HAWB)를 사용합니다.

추출의 과제는 적하목록 데이터가 컨테이너 수준에서 BOL 데이터와 일치해야 한다는 점입니다. 적하목록에 컨테이너 MSCU 234781 6에 500개의 카톤이 있다고 표시되고 BOL에는 480개라고 표시되면, 그 20개 차이는 적하목록 입력 오류이거나 BOL 오류이며 세관이나 수하인에게 지적됩니다. 두 문서를 모두 읽고 처리 중 공유 필드를 비교하는 의미론적 추출은 이러한 불일치가 세관 보류로 이어지기 전에 포착합니다.

패킹 리스트 — 품목별 상세 내역

패킹 리스트는 선적 서류 중 가장 세분화된 문서입니다. BOL이 총 중량과 총 개수만 표시하는 반면, 패킹 리스트는 각 패키지 안에 무엇이 들어 있는지 — 카톤별, 팔레트별로 상세히 기재합니다. LCL(컨테이너 미만 적재) 선적의 경우, 패킹 리스트는 포워더가 여러 화주의 화물을 통합하는 방법을 알려주는 문서입니다.

표준 패킹 리스트 항목은 다음과 같습니다:

패킹 리스트가 품목 수준의 진실 문서로서의 역할은 선적에서 가장 중요한 교차 문서 검증 중 하나인 수량 조정의 기준이 됨을 의미합니다. 상업 인보이스에는 개당 $12.50에 2,000개라고 명시되어 있습니다. 패킹 리스트에는 50개씩 40카톤에 2,000개라고 명시되어 있습니다. BOL에는 40카톤이라고 명시되어 있습니다. 이 숫자 중 하나라도 일치하지 않으면 세관 중개인은 어떤 문서를 신뢰할지 결정해야 하며 — 세 문서를 모두 읽는 추출 도구는 단일 조정 열에서 불일치를 플래그할 수 있습니다.

패킹 리스트 형식은 놀라울 정도로 다양합니다. 제조업체의 패킹 리스트는 컨테이너당 50개 라인 항목이 있는 여러 페이지의 Excel 내보내기 파일일 수 있습니다. 포워더의 하우스 패킹 리스트는 동일한 정보를 상품당 한 행으로 압축할 수 있습니다. 통합 컨테이너 패킹 리스트는 여러 구매 주문을 단일 컨테이너에 매핑해야 합니다 — 이는 라인 항목 경계가 PO 경계를 넘나들기 때문에 기존 OCR 도구가 어려워하는 형식입니다.

상업송장 — 관세 평가 서류

상업송장은 관세 당국이 관세와 세금을 산정하는 데 사용하는 서류입니다. 포장명세서(물리적 화물 중심)나 선하증권(운송 중심)과 달리, 상업송장은 가치에 관한 것입니다: 무엇이 얼마에, 어떤 무역 조건으로, 어디서 원산지인지가 기록됩니다.

서식 구조는 일반 판매 송장과 유사하지만, 국제 무역에 특화된 항목이 추가됩니다:

• 매도인과 매수인 — 이름과 주소(제3자 물류 업체가 개입된 경우 선하증권의 송하인/수하인과 다를 수 있음)
• 송장 번호 및 발행일 — 수출업체의 참조 번호로, 포장명세서와 상호 참조되는 경우가 많음
• 선적 참조 — 구매 주문 번호, 선하증권 번호, 컨테이너 번호, 예약 번호
• 품목 — 설명, HS 코드, 수량, 단가, 품목별 총 가치
• 인코텀즈 — 운임, 보험, 관세를 누가 부담하는지 결정하는 무역 조건(FOB 상하이, CIF 로테르담, EXW 공장, DDP 매수인 창고)
• 원산지 — 상품이 제조되거나 실질적으로 변형된 국가
• 총 신고 가액 — 관세 계산의 기준
• 통화 및 결제 조건 — USD, EUR, JPY; Net 30, T/T, L/C

상업송장의 HS 코드 추출은 특히 주의해야 합니다. 이 필드가 잘못되면 통관 지연이 발생할 가능성이 가장 높기 때문입니다. 6자리 HS 코드(HS 협약상 최소 단위)는 제품을 특정 장, 류, 소호로 분류합니다. HS 코드가 잘못되면 잘못된 관세율이 적용되거나, 코드가 설명과 일치하지 않아 상품이 검사 대상으로 지정될 수 있습니다. HS 코드를 단순한 영숫자 필드로 처리하는 추출 도구는 이를 WCO 분류의 첫 6자리와 대조하여 검증할 기회를 놓칩니다. HS 코드 패턴(XXXX.XX 또는 XXXXXX.XX)을 인식하고 이를 상품 설명과 교차 검증하는 의미론적 추출 설정은 세관 중개인이 보기 전에 이러한 오류를 잡아냅니다.

상업송장에는 가장 중요한 문서 간 참조 필드인 인코텀즈도 포함됩니다. 인코텀즈는 선하증권에서 운임이 선불인지 후불인지, 누가 보험을 준비하는지, 위험이 매도인에서 매수인으로 언제 이전되는지를 결정합니다. 상업송장에서 "FOB 상하이"를 읽고 선하증권에서 "운임 후불"을 읽으면서도 불일치(대부분의 운송사 해석에서 FOB는 후불)를 표시하지 않는 추출은 통관 시간을 낭비하는 조정 작업을 놓치게 됩니다.

화물 송장 및 배송 라벨

선적 서류 꾸러미를 완성하는 두 가지 추가 문서입니다.

화물 송장은 운송업체가 발행하는 운송 서비스 청구서입니다. BOL 번호와 컨테이너 번호를 참조하며, 운임 기본 요금, 유류 할증료, 섀시 임대료, 체화료, 지체료, 픽업 및 배송비, 추가 서비스 요금 등이 항목별로 기재됩니다. 화물 송장 데이터 추출의 어려움은 요금 자체를 읽는 것이 아니라, 각 요금을 올바른 BOL에 매칭하고 계약상 합의된 사항인지 확인하는 데 있습니다. 운송업체가 요청하지 않은 리프트게이트 서비스에 대해 250달러를 청구할 수도 있습니다. 화물 송장 데이터 추출은 AP팀이 운임 확인서나 예약 내역과 대조할 수 있도록 충분한 참조 데이터(BOL 번호, 컨테이너 번호, 날짜)를 보존해야 합니다. 추출 설정에서 계산된 열을 추가하여 운임 기본 요금을 알려진 계약 요율과 비교하고 5% 이상의 차이에 플래그를 지정하면, 수동적인 추출 결과물을 능동적인 감사 도구로 전환할 수 있습니다.

배송 라벨은 최종 배송 지점에서 사용됩니다. 운송업체가 인쇄한 라벨에는 추적 번호, 바코드, 발신자 및 수신자 주소, 서비스 등급, 패키지 중량, 참조 필드가 포함됩니다. 당사의 배송 라벨 및 화물 명세서 데이터 추출 관련 기사에서는 감열지 라벨, 잉크젯 라벨, 수기 수정본별 필드별 정확도를 분석합니다. 선적 서류 꾸러미 추출의 핵심은 배송 라벨의 추적 번호가 BOL 번호 또는 화물 명세서의 상호 참조와 일치해야 한다는 점입니다. 그렇지 않으면 해당 화물의 최종 배송 추적이 중단됩니다.

전체 선적 서류 꾸러미 일괄 처리

단일 BOL이나 포장 명세서를 읽는 것은 기본에 불과합니다. 효율성 향상은 전체 선적 문서 꾸러미(5개 이상의 문서)를 한 번의 작업으로 일괄 처리하고, 문서 간 필드를 동일한 출력 열에 매핑함으로써 얻을 수 있습니다.

일반적인 선적 서류 꾸러미 일괄 처리 워크플로우는 다음과 같습니다:

이 워크플로우는 일괄 우선 처리를 위해 설계된 방식입니다. 혼합 형식의 문서 5~15개를 업로드하고, 열 스키마를 한 번만 정의하면 검증 및 교차 참조된 단일 출력 테이블을 얻을 수 있습니다. 운송사별 템플릿 설정이나 문서 유형별 재구성이 필요하지 않습니다.

필드 검증 — 원시 텍스트에서 TMS 준비 데이터로

유용한 추출 결과와 단순 텍스트 덤프의 차이는 검증 계층에 있습니다. 선적 문서는 내장된 검증 규칙이 있는 코드 시스템을 사용합니다. 이러한 규칙을 적용하는 추출 도구는 TMS나 통관 신고에 도달하기 전에 오류를 잡아냅니다.

추출 중 이러한 규칙을 적용하는 검증 파이프라인은 단순히 오류를 잡는 것 이상의 역할을 합니다. 수동 정리 과정 없이 다운스트림 시스템에서 바로 사용할 수 있는 데이터셋을 구축합니다. ISO 6346 검증 숫자 검사를 통과한 컨테이너 번호는 운송사 추적 API로 직접 전송할 수 있습니다. UNECE 조회를 통과한 UN/LOCODE는 TMS 라우팅 테이블에 로드할 수 있습니다. 상품 설명과 일치하는 HS 코드는 세관에 자신 있게 제출할 수 있습니다.

검증 없이 추출하면 겉보기에는 정확해 보이는 원시 텍스트 스프레드시트가 생성됩니다. 하지만 7번째와 11번째 숫자가 바뀌어 운송사 추적 API가 "컨테이너를 찾을 수 없음"을 반환할 때까지는 말이죠. 하루 100~500달러의 체선료가 발생하는 이러한 지연은, 비용을 절감하는 추출과 또 다른 종류의 비용을 창출하는 추출의 차이를 만듭니다.

내보내기 전략 — 최종 스프레드시트에 포함되는 내용

선적 문서 추출은 데이터를 사용 가능한 형식으로 만들기 전까지 완료되지 않습니다. 출력 전략은 누가 사용하고 어떤 시스템에 공급되는지에 따라 달라집니다.

문서별 행. 패킷의 각 문서는 하나의 출력 행을 생성합니다. BOL 행에는 모든 BOL 필드가 포함됩니다. 패킹 리스트 행에는 모든 패킹 리스트 필드가 포함됩니다. 이는 각 문서의 전체 세부 정보를 보존하지만, 행 간에 수동으로 상호 참조해야 합니다. 각 문서를 개별적으로 감사해야 하는 팀에 가장 적합합니다.

선적별 통합 행. 선적당 하나의 행이며, 열은 원본 문서별로 그룹화됩니다: BOL_Container_Number, Manifest_Container_Number, PL_Container_Number, 그 뒤에 조정 열이 옵니다. 이는 AP 팀과 관세사가 선호하는 형식입니다. 선적의 모든 데이터가 한 곳에 있으며, 불일치 사항을 한눈에 확인할 수 있습니다.

라인 항목별 행. 패킹 리스트나 상업 송장의 각 라인 항목당 하나의 행이며, 선적 수준 필드(컨테이너 번호, BOL 번호, 항구 코드)가 모든 행에 반복됩니다. 이는 항목 수준 세부 정보가 필요한 재고 관리 시스템 및 관세 계산 엔진을 위한 형식입니다.

ImageToTable.ai는 배치 처리 파이프라인을 통해 세 가지 출력 형식을 모두 지원합니다. 내보내기 토큰 시스템을 사용하면 필요에 따라 Excel 파일을 생성하고 계정이 없는 팀원과 공유할 수 있습니다. 수신자는 링크를 열고 출력물을 다운로드합니다. 이는 각 클라이언트에게 도구 자체에 대한 액세스 권한을 부여하지 않고 선적 데이터를 공유해야 하는 포워더에게 특히 유용합니다.

선적 문서 추출의 일반적인 함정

올바른 접근 방식을 사용하더라도, 선적 문서 추출에는 자동화 처리를 처음 접하는 물류 팀을 잡는 함정이 있습니다.

모든 BOL을 동일한 문서로 취급. 직선 BOL, 해상 BOL, 복합운송 BOL, 하우스 BOL, 마스터 BOL은 이름은 같지만 필드 구조와 법적 효력이 다릅니다. 직선 BOL(단일 송하인, 단일 수하인, 단순 경로)에서 작동하는 추출 설정은 하우스 BOL의 HBL 참조 번호와 복합운송 BOL의 추가 운송 조건을 놓칩니다. 해결책은 접하는 가장 복잡한 문서 유형에 맞게 열 스키마를 설계하고, 더 간단한 문서는 더 적은 필드를 채우도록 하는 것입니다.

통합 계층 무시. 포워더가 5명의 송하인으로부터의 선적을 하나의 컨테이너로 통합할 때, 패킹 리스트는 단일 문서가 아니라 송하인 수준의 패킹 리스트 모음과 통합 매니페스트입니다. 추출 설정은 컨테이너 MSCU 234781 6에 5개 수출업체의 15개 개별 구매 주문이 포함될 수 있으며, 각각 고유한 PO 번호, HS 코드, 원산지 국가가 있음을 이해해야 합니다. 컨테이너당 한 행을 출력하는 도구는 세관이 요구하는 모든 항목 수준 세부 정보를 놓칩니다.

중량 정규화 생략. BOL에는 15,420 KGS로 표시될 수 있습니다. 매니페스트에는 34,000 LBS로 표시됩니다. 패킹 리스트에는 340 CWT(헌드레드웨이트)로 표시됩니다. 이들은 다른 단위로 표시된 동일한 중량이지만, 원시 텍스트 추출은 세 개의 다른 숫자로 출력합니다. 모든 중량을 단일 단위(킬로그램)로 정규화하고 (단위 변환 후) 실제 불일치 사항을 플래그 지정하는 계산된 열은 중량 관련 세관 보류 및 운송사 송장 분쟁을 방지합니다.

추출 시점에 코드를 검증하지 않는 행위. 유효하지 않은 컨테이너 체크디지트, 존재하지 않는 UN/LOCODE, 또는 불일치하는 HS 코드가 추출 시점에 발견되면 수정 비용이 들지 않습니다. 동일한 오류가 48시간 후 — ISF 신고가 제출되고 화물이 적재된 후 — 적발되면 미국 CBP 규정(19 CFR 149.3)에 따라 5,000달러의 수정 벌금이 부과됩니다. 실시간 검증 없는 추출은 추출이 아닌, 빠른 속도로 타이핑하는 것에 불과합니다.

자주 묻는 질문

반복 가능한 선적 문서 워크플로우 구축

선적 문서 추출은 일회성 디지털화 프로젝트가 아닙니다. 이는 반복 가능한 운영 프로세스입니다: 매일, 선적분의 BOL, 선하증권, 적하목록, 포장명세서, 상업송장, 운임송장이 PDF와 이미지로 도착하고, 매일 그 데이터는 수동 타이핑 과정 없이 TMS, 세관 중개인, AP 시스템에 도달해야 합니다. 작동하는 추출과 새로운 작업을 만들어내는 추출의 차이는, 도구가 전체 패킷을 함께 처리하는지 — 문서 간 필드 매핑, 코드 검증, 배치 내보내기 포함 — 아니면 각 문서 유형을 별도로 추출한 후 결과를 수동으로 연결하도록 강제하는지에 달려 있습니다.

BOL을 읽고 멈추는 도구 — 선하증권 전, 적하목록 전, 포장명세서 전, 문서 간 조정 전 — 는 하나의 문서를 읽었을 뿐입니다. 선적을 처리한 것이 아닙니다. 완전한 추출은 패킷을 캡처하고, 공유 필드를 검증하며, 불일치가 이미 표시되고 코드가 이미 표준화된 데이터셋을 출력합니다. 이것이 문서 읽기 도구와 선적 문서 워크플로우의 차이입니다.