선적 및 화물 문서 추출
완전 가이드

선적 문서 생태계 — 한 건의 화물, 다섯 종류의 문서

추출 작업을 시작하기 전에, 물류 팀은 무엇을 추출할지 그리고 문서들이 서로 어떻게 연관되는지에 대한 지도를 파악해야 합니다. 일반적인 FCL (Full Container Load) 해상 운송은 다음 다섯 가지 핵심 문서를 생성합니다:

공유 필드 문제는 즉시 확인할 수 있습니다: 컨테이너 번호는 B/L, manifest, packing list, freight invoice에 모두 나타납니다. B/L 번호는 manifest, commercial invoice, freight invoice를 연결합니다. 총 중량은 B/L, manifest, packing list에 모두 기재되지만 — 단위가 같은 경우는 드뭅니다. 각 문서를 개별적으로 읽는 추출 프로세스는 서로 일치하지 않는 다섯 개의 데이터셋을 생성합니다. 선적 서류 묶음에 맞게 설계된 추출 프로세스는 이들을 함께 읽고 불일치 사항을 표시합니다.

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

선하증권 — 핵심 문서

선하증권(Bill of Lading, BOL)은 운송 서류 중 법적으로 가장 복잡한 문서입니다. 화물 수령증, 운송 계약서, 그리고 양도 가능한 형태에서는 화물 소유권 증서의 역할을 동시에 수행합니다. 필드 수만 봐도 추출이 쉽지 않은 이유를 알 수 있습니다. 일반적인 해상 B/L에는 3~5페이지에 걸쳐 30~40개의 데이터 필드가 있으며, 여러 국제 표준의 적용을 받습니다.

저희는 BOL 데이터 추출에 대한 전용 종합 가이드를 게시하여 BOL 유형, 추출 파이프라인, 검증을 심도 있게 다루고 있으며, BOL 데이터를 Excel로 추출하는 단계별 가이드도 제공합니다. 여기서는 문서 간 교차 검증에 중요한 부분, 즉 다른 모든 운송 문서가 참조하는 필드에 초점을 맞춥니다.

SCAC 코드는 물류에서 가장 흔히 잘못 추출되는 필드이므로 자세히 살펴볼 가치가 있습니다. B/L에 선사 이름이 "Maersk Line"으로 인쇄되어 있어도 TMS는 MAEU를 기대할 수 있습니다. 다른 선사는 참조 번호처럼 보이는 SCAC 옆에 이름을 나열할 수도 있습니다. 의미론적 AI 추출은 표준 코드 패턴을 인식하여 전체 선사 이름과 별도의 필드로 추출함으로써 이를 처리합니다. 그러나 모든 추출 도구가 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별이 아닌 컨테이너별로 필드를 그룹화할 수 있습니다. 항공 화물 적하목록은 해상 적하목록과 다른 헤더 구조를 사용합니다.

추출의 과제는 적하목록 데이터가 컨테이너 수준에서 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 도구가 어려워하는 형식입니다.

상업송장 — 관세 평가 서류

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

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

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

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

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

운송장 및 배송 라벨

운송 서류 묶음을 완성하는 두 가지 추가 문서가 있습니다.

운송장(Freight Invoice)은 운송 서비스에 대한 운송업체의 청구서입니다. B/L 번호와 컨테이너 번호를 참조하며 운임, 유류할증료, 섀시 임대료, 체화료, 지체료, 픽업·배송비, 부대비용 등 항목별 요금을 명시합니다. 운송장 추출의 과제는 요금을 읽는 것이 아니라 각 요금을 올바른 B/L에 대응시키고 계약상 합의된 금액인지 확인하는 것입니다. 운송업체가 요청하지 않은 리프트게이트 서비스에 대해 250달러를 청구할 수도 있습니다. 운송장 추출은 AP 팀이 운임 확약서나 예약 내역과 대조할 수 있도록 충분한 참조 데이터를 보존해야 합니다. 추출 설정의 계산 열(Computed Columns)에서 운송 요금을 알려진 계약 운임과 비교하고 5% 이상의 차이를 플래그로 표시하면, 수동적인 추출 결과물이 능동적인 감사 도구로 바뀝니다.

배송 라벨은 최종 배송 접점입니다. 운송업체가 인쇄한 라벨에는 추적 번호, 바코드, 발송인·수취인 주소, 서비스 등급, 패키지 중량, 참조 필드가 포함됩니다. 당사의 배송 라벨 및 화물목록 추출 문서에서 열전사 라벨, 잉크젯 라벨, 수기 수정 사항별 필드별 정확도를 분석합니다. 패킷 추출의 핵심은 배송 라벨의 추적 번호가 B/L 번호 또는 화물목록의 상호 참조로 연결되어야 한다는 것입니다. 그렇지 않으면 해당 화물의 최종 배송 추적이 끊어집니다.

전체 운송 서류 묶음 일괄 처리

단일 B/L 또는 포장 명세서를 읽는 것은 기본입니다. 효율성 향상은 한 번의 작업으로 전체 운송 문서 묶음을 일괄 처리하고, 문서 간 필드를 동일한 출력 열에 매핑할 때 발생합니다.

일반적인 운송 패킷 일괄 처리 작업 흐름은 다음과 같습니다:

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

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

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

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

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

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

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

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

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

품목별 행. 패킹 리스트 또는 상업 송장의 각 품목에 대해 하나의 행이 생성되며, 선적 수준 필드가 모든 행에 반복됩니다. 이는 품목 수준 세부 정보가 필요한 재고 관리 시스템 및 관세 계산 엔진을 위한 형식입니다.

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

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

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

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

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

중량 정규화를 건너뛰는 것. B/L에는 15,420 KGS로 표시될 수 있습니다. 매니페스트에는 34,000 LBS로 표시됩니다. 패킹 리스트에는 340 CWT로 표시됩니다. 이들은 다른 단위로 표현된 동일한 중량이지만, 원시 텍스트 추출은 이를 세 가지 다른 숫자로 출력합니다. 모든 중량을 단일 단위로 정규화하고 단위 변환 후 실제 불일치를 표시하는 계산 열은 중량 관련 세관 보류 및 운송업체 인보이스 분쟁을 방지합니다.

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

자주 묻는 질문

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

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

B/L을 읽고 멈추는 도구 — 적하 목록 전에, 포장 명세서 전에, 문서 간 대사 전에 — 는 한 문서를 읽은 것에 불과합니다. 선적을 처리한 것이 아닙니다. 완전한 추출은 문서 묶음을 포착하고, 공유 필드를 검증하며, 불일치가 이미 표시되고 코드가 이미 표준화된 데이터셋을 출력합니다. 이것이 문서 판독 도구와 선적 문서 워크플로의 차이입니다.