운송장 및 적하목록 데이터를 추출하여
화물 추적용 Excel로 변환하는 방법

어떤 도구를 사용하기 전에, 한 가지 차이가 스프레드시트를 만드는 방식을 결정합니다. 운송장과 패키지 적하목록은 동일한 발송물을 설명하더라도 구조적으로 다른 문서입니다. 운송장은 패키지별 문서로, 상자 하나당 한 장씩 있으며 해당 상자의 운송장 번호, 주소, 중량, 서비스 등급이 포함됩니다. 패키지 적하목록은 일괄 요약본으로, 한 번의 인도에서 접수된 모든 물품을 나열하는 한 페이지이며, USPS 및 화물 운송업체가 각 라벨을 개별적으로 스캔하는 대신 전체 트레일러나 우편 봉투를 한 번에 접수하는 데 사용합니다. 둘 다 추적 테이블에 포함되어야 합니다. 단지 동일한 운영의 서로 다른 측면에서 오는 것뿐입니다.

다음은 두 경우 모두에 대한 전체 워크플로입니다: 추적 스프레드시트에 실제로 필요한 열, 라벨과 적하목록을 해당 열에 매핑하는 방법, 타이핑을 건너뛰는 추출 단계, 그리고 출력을 검증하는 데 사용해야 하는 운송업체 규칙 형식입니다.

화물 추적 스프레드시트에 실제로 필요한 것

추적 스프레드시트는 한눈에 세 가지 질문에 답하기 위해 존재합니다: 무엇이 운송 중인지, 어떤 운송업체가 처리하는지, 언제 도착해야 하는지. 이는 업계와 관계없이 거의 모든 팀이 사용하게 되는 소수의 열로 범위를 좁힙니다:

운송장 번호는 잘못 입력하면 안 되는 유일한 열입니다. 22자리 USPS 번호에서 한 자리만 틀려도 해당 소포는 영구히 "위치 확인 불가" 상태가 됩니다. 다른 항목은 라벨을 다시 보면 수정할 수 있지만, 잘못된 운송장 번호는 조회조차 할 수 없습니다. 바로 이 제약 때문에 운송장 번호 수동 입력은 전체 스프레드시트에서 가장 취약한 고리이며, 문서에서 직접 추출해야 하는 가장 강력한 이유이기도 합니다.

라벨 vs 적하목록: 두 문서, 하나의 스프레드시트

표준 운송업체 라벨(FedEx Ground, UPS, USPS Priority)은 4″ × 6″ 열전사 라벨에 8~12개 필드를 담습니다: 운송장 번호, 주소 블록 2개, 서비스 등급, 중량, 발송일, 참조 필드. 필드 배치는 운송업체마다 다르며, 운송장 번호는 항상 바코드 근처에 있습니다. 스캐너와 사람이 동일한 코드를 읽기 때문입니다.

반면 적하목록은 테이블입니다. USPS Manifest Mailing System은 두 가지 형식을 정의합니다: 항목별 처리는 각 품목을 고유 ID, 중량, 우편 요금으로 개별 나열하고, 일괄 처리는 연속된 ID 범위를 수량과 총 우편 요금으로 그룹화합니다. 두 방식 모두 스프레드시트에서는 동일한 결과, 즉 행으로 귀결됩니다. 품목당 적하목록 행 하나, 운송장 ID, 중량, 우편 요금 열은 운송업체가 미리 정렬해 둡니다.

실질적인 차이: 라벨은 일주일치 배송에 분산되어 도착하거나, 적하목록은 단일 드롭오프에서 접수된 모든 물품을 담은 1~2개의 다중 페이지 PDF로 도착합니다. 일괄 추출은 두 경우 모두 동일하게 처리합니다 — 모든 파일을 한 번에, 모든 행을 동일한 출력 테이블로 병합 — 하지만 적하목록 시나리오에서 일괄 처리가 진가를 발휘합니다. 단일 문서에서 수백 개 행이 생성되어, 수동 입력이라면 오후 내내 걸렸을 작업을 대체하기 때문입니다. 이 정확도가 유지되는 부분과 그렇지 않은 부분에 대한 필드별 분석은 AI가 운송 라벨과 적하목록에서 추출할 수 있는 것과 없는 것에 대한 가이드를 참조하세요.

엔드투엔드 추출 워크플로우

ImageToTable.ai는 맞춤 열 추출을 사용합니다. 템플릿을 학습하거나 필드 주위에 경계 상자를 그리는 대신, 원하는 열 이름을 입력하면 AI가 각 필드의 의미를 이해하여 문서 어디에서든 일치하는 값을 찾아냅니다. FedEx Ground 운송장, UPS Air 운송장, USPS 적하목록 표 모두 운송업체별 설정 없이 동일한 열 목록에 매핑됩니다. 물류 코디네이터가 실제로 실행하는 워크플로우는 다음과 같습니다.

추출이 타이핑을 대체하지만, 텍스트 형식 단계는 필수입니다 — 이는 스프레드시트가 제대로 보이는 것과 운송업체 포털에서 실제로 작동하는 것의 차이입니다. ShipWorks의 운송장 번호를 Excel로 가져오는 지원 문서도 정확히 이 내용을 다룹니다: 번호가 재해석되기 전에 가져오는 동안 열 형식을 텍스트로 설정하세요.

운송업체별 운송장 번호 읽기

번호가 스프레드시트에 들어간 후에는 정확해야만 유용합니다. 가장 빠른 정확성 확인 방법은 비용이 들지 않습니다. 운송업체 운송장 번호는 인식 가능한 운송업체별 형식을 따릅니다. 운송장 번호는 임의의 문자열이 아닙니다. 접두사가 운송업체를, 경우에 따라 서비스 등급을 나타냅니다.

이러한 패턴은 독립적으로 문서화되어 있습니다. UPS 1Z 번호의 구조는 Wikipedia의 운송장 번호 문서에 자세히 설명되어 있습니다. 추출 후 검증 단계로 이를 사용하면 중요한 오류를 잡아낼 수 있습니다. 21자리 "USPS" 번호, FedEx 문자열 내부의 문자, 다른 숫자로 시작하는 1Z 번호 등이 그것입니다. 여러 운송업체의 라벨 배치를 한 번에 처리할 때 이 교차 확인은 형식 지식이 빛을 발하는 부분입니다. 친숙한 라벨에서 직원이 본능적으로 수행하던 동일한 검증을 이제 모든 행에 균일하게 적용하는 것입니다.

수입 화물의 경우에도 동일한 원칙이 선하증권 번호에 적용되며, 운송업체와 운송 모드별로 각자의 규칙을 따릅니다. 추적 테이블이 LTL과 소포를 함께 다루는 경우, 여러 운송업체의 선하증권을 하나의 스프레드시트로 일괄 처리하는 방법을 참조하세요. 동일한 열 정의 접근 방식이 BOL에 적용되며, PRO 번호와 BOL 참조가 소포 운송장 번호를 대체합니다. 월간 BOL이 몇 건에 불과한 더 간단한 워크플로우라면, 선하증권을 Excel로 직접 변환하는 방법으로 배치 오버헤드 없이 처리할 수 있습니다.

추출된 행에서 실시간 추적 보기까지

운송장 번호로 가득 찬 스프레드시트는 운송 기록입니다. 상태 열을 추가하고 이를 의사 결정에 활용하기 시작하면 추적 기록이 됩니다. 행이 준비되면 세 가지 스프레드시트 작업으로 마무리할 수 있습니다.

• 상태 열을 추가하고 최신 상태로 유지합니다. 소량의 경우, 배송되지 않은 소수의 패키지를 운송업체 포털에서 하루에 한 번 확인하고 셀을 업데이트합니다. 대량의 경우 운송업체의 일괄 추적 기능이나 가져오기 기반 상태 도구를 사용한 후 결과를 다시 붙여넣습니다. 핵심은 상태가 추출된 데이터 옆, 같은 행에 위치하여 필터가 전체 테이블에 적용되도록 하는 것입니다.
• 운송업체 및 서비스 등급별 피벗 테이블을 만듭니다. 행: 운송업체. 열: 상태. 값: 개수. 이 하나의 피벗으로 "이번 주에 실적이 저조한 운송업체"와 "아직 배송 중인 패키지 수"를 행을 스크롤하지 않고도 파악할 수 있습니다.
• 조건부 서식을 사용하여 예외 사항을 표시합니다. 예상 배송 기간보다 오래된 항목, 즉 도착했어야 하는데 아직 도착하지 않은 패키지의 행을 강조 표시합니다. 이러한 항목은 누군가 먼저 발견하지 않으면 고객 지원 사례로 이어질 수 있습니다.

이것은 또한 배송 소프트웨어가 등장하는 지점이기도 합니다. ShipStation, ShipBob(3PL 풀필먼트), 그리고 화물 중심 시스템인 FreightPOP, Freightview 또는 기업용 Descartes 제품과 같은 플랫폼은 모두 자체 추적 보기를 생성합니다. 그러나 이러한 보기는 동일한 기본 데이터에서 생성되며, 많은 팀은 여전히 소프트웨어가 다루지 않는 소스의 데이터를 병합하는 스프레드시트와 대조하여 이를 조정합니다. 추출은 이러한 하이브리드 워크플로우의 스프레드시트 측면을 채웁니다. 행이 완전하게 도착하고 소프트웨어 자체의 내보내기는 유일한 기록이 아닌 교차 확인 수단이 됩니다.

주문 관리 규모가 아닌 운송 기록 규모로 운영하는 팀에게 스프레드시트는 여전히 가장 간단한 대상이며, 동일한 일괄 접근 방식은 추적에서 화물 인보이스 처리까지 확장되어 추출된 중량과 참조 번호가 운송업체 청구와 대조됩니다.

적하목록 규모: 라벨 몇 장이 아닐 때

위의 워크플로는 수동 입력이 한계에 부딪히는 지점까지 확장됩니다. USPS 드롭십 적하목록이나 화물 운송업체의 적하목록은 몇 페이지에 수백 건의 품목을 나열할 수 있습니다. 운송업체가 자체 시스템에서 생성했기 때문에 필드가 균일하고 표 형식으로 되어 있어 추출에 가장 쉬운 문서 유형입니다. 하나의 적하목록을 단일 파일로 처리하면 하루 전체의 운송장 추적 행이 한 번에 생성됩니다.

화물 적하목록에는 소포 라벨에 없는 필드가 추가됩니다: 해상 화물의 컨테이너 및 실 ID, 총 중량, 상품 코드, 패키지 유형 등이 있습니다. 이러한 필드는 적하목록이 세관과 수령 팀이 대조하는 문서이기 때문에 존재합니다. 적하목록의 중량과 품목 수는 포장 목록 및 선하증권과 일치해야 하며, 일치하지 않을 경우 누군가는 차이점을 찾기 위해 적하목록 데이터를 비교 가능한 형식으로 필요로 합니다. 이 대조 워크플로는 대량 BOL 수령 및 PO 대조 가이드에서 자세히 다룹니다.

USPS의 적하목록 규정은 공개적이고 정확합니다: Domestic Mail Manual 및 Publication 401은 품목별 및 일괄 적하목록 형식, 개별 ID 및 중량 요구 사항, 문서를 마감하는 우편 요금 명세서를 정의합니다. 권위 있는 참조 자료는 USPS Manifest Mailing Systems 개요입니다. 스프레드시트에 대한 실용적인 요점은 적하목록이 매우 표준화되어 있어 추출이 깔끔하게 이루어진다는 것입니다. 운송업체가 이미 데이터를 구조화했으며 추출 단계는 이를 행으로 읽어들일 뿐입니다.

전용 추출 워크플로를 구축할 가치가 있는지 아직 평가 중이라면, 2026년 테스트된 물류 문서 추출 도구 요약에서 템플릿 기반, AI 기반, 하이브리드 방식을 이 문서에서 다루는 정확한 문서 유형에 대해 나란히 비교합니다.

FAQ

운송장 사진에서도 데이터를 추출할 수 있나요, 아니면 PDF만 가능한가요?

둘 다 가능합니다. 창고 도크에서 촬영한 휴대폰 사진의 라벨도 PDF 라벨과 동일한 열 정의로 추출됩니다. 운송장 번호나 주소 같은 인쇄된 필드가 가장 정확하며, 손으로 적은 중량 메모는 정확도가 가장 낮으므로 손으로 작성된 라벨은 해당 값을 확인하세요.

한 배치에서 여러 운송업체를 처리할 수 있나요?

네. 추출이 템플릿 기반이 아닌 의미 기반으로 이루어지기 때문에 FedEx Ground 라벨, UPS Air 라벨, USPS 적하목록을 하나의 공유 열 목록으로 한 배치에서 처리할 수 있습니다. 각 행은 운송업체가 문서를 어떻게 배치했는지와 관계없이 열과 일치하는 값으로 태그가 지정됩니다.

Excel에서 운송장 번호가 과학적 표기법으로 표시되는 이유는 무엇인가요?

Excel은 셀 형식이 '일반'일 때 긴 숫자 문자열을 과학적 표기법으로 변환합니다. 붙여넣기나 가져오기 전에 운송장 번호 열을 선택하고 형식을 '텍스트'로 설정하세요. 추출된 스프레드시트의 경우 내보내기 직후에 수행하세요. 추출된 값은 정확한 문자열이며 텍스트 형식이 이를 보존합니다.

운송장과 적하목록의 차이점은 무엇인가요?

운송장은 한 박스의 운송장 번호, 주소, 중량을 담는 개별 패키지 문서입니다. 적하목록은 단일 인도 시 제출된 모든 물품을 목록화한 배치 문서로, 물품 ID, 중량, 우편 요금이 표 형식으로 포함됩니다. 둘 다 동일한 추적 스프레드시트에 입력됩니다. 운송장은 파일당 한 행씩, 적하목록은 파일당 여러 행이 추가됩니다.

스프레드시트가 추적 상태를 자동으로 업데이트할 수 있나요?

추출만으로는 불가능합니다. 추출은 문서를 읽는 것이고, 운송업체 상태는 운송업체 시스템에 있습니다. 표준 워크플로는 운송장 번호를 추출한 다음 운송업체의 대량 상태 조회를 사용하여 상태 열을 갱신하는 것입니다. 추출의 역할은 스프레드시트의 번호가 처음부터 정확하도록 보장하는 것입니다.

열전사 라벨에서 추출 정확도는 어느 정도인가요?

품질이 좋은 열전사 라벨에 인쇄된 운송장 번호는 높은 정확도로 추출되며, 주소 블록과 서비스 등급도 마찬가지입니다. 그러나 색이 바래거나 번진 열전사 라벨이나 손글씨의 경우 정확도가 떨어집니다. 운송장 번호는 나중에 수정할 수 없는 필드이므로, 각 배치 후 샘플을 몇 개씩 대조 확인하세요. 위의 운송업체 형식 규칙 덕분에 이 확인 작업은 빠르게 진행됩니다.

스프레드시트가 목적지이며, 추출은 빠진 단계일 뿐입니다

작업 흐름을 바꾸는 핵심은 간단합니다. 운송 추적 스프레드시트를 수작업으로 만들 필요가 없다는 것입니다. 필요한 모든 필드는 이미 라벨이나 적하목록에 존재하기 때문입니다. 항상 빠져 있던 단계는 전송이었고, 바로 그 전송이 수동 입력이 지루해지고 신뢰할 수 없게 되는 규모에서 일괄 추출이 수행하는 작업입니다.

직접 문서로 시도해 보세요. 일주일치 라벨과 적하목록을 업로드하고 위의 열을 정의한 다음, 한 시간 동안 타이핑한 후가 아니라 완성된 상태로 도착하는 추적 테이블을 확인해 보세요.