完全ガイド:
運送状データ抽出
運送状は単一の書類ではありません。直送運送状、海上運送状、複合一貫運送状、マスター運送状、ハウス運送状など、法的に異なる書類群であり、それぞれに異なる項目、発行者、データの送信先があります。1日に100通の運送状を処理するフォワーダーは、昼までに5つの運送会社から8種類の異なる書式に触れることもあります。ある運送状では機能しても、次の形式で破綻する抽出は、抽出ではなく、手作業によるフォールバックを伴う部分的な解決策に過ぎません。本ガイドでは、あらゆる種類、運送会社、そしてTMSが求めるすべての標準コードにわたって、運送状データを確実に抽出するために実際に知っておくべきことを解説します。
重要ポイント
- 運送状のテンプレートベース抽出では、50の運送会社に対して750の座標矩形を維持する必要があります。マースクがコンテナ番号を右上からページ中央に移動した場合、誰かがテンプレートを編集するまで、同社発行の全運送状で該当フィールドが空白になります。
- 問題はメンテナンス負担だけではありません。テンプレート変更のたびに、誤読されたコンテナIDがTMS、顧客の追跡ポータル、税関申告に到達し、誰もコンテナが3日間行方不明になっていることに気づかないリスクが生じます。
- 1つのセマンティック列定義で750のテンプレートすべてを代替し、抽出中にISO 6346チェックデジットでコンテナ番号を検証します。これにより、誤入力が抽出レイヤーを離れる前、つまりデマレージの時計が動き出す前に捕捉できます。
船荷証券(BOL)のデータ抽出が他と違う理由
ほとんどの文書抽出に関する記事は、船荷証券を「船の絵がついた請求書」のように扱います。この前提から作られたツールはデモでは動いても、本番では失敗します。ここでは、BOLが他のどの文書とも構造的に異なる理由を説明します。
法的に異なる5種類の文書を、1つの抽出パイプラインで処理。 straight bill of lading(非流通性)は特定の荷受人を指定し、譲渡不可。LTLトラック輸送で一般的な最も単純な形式です。ocean bill of lading(海上BOL)は流通性があり、ヘーグ・ヴィスビー規則に基づく権原証券として機能します。原本を所持する者が貨物を請求できます。multimodal BOL(複合一貫BOL、combined transport BOLとも呼ばれる)は、UNCTAD/ICC複合運送書類規則に基づき、海上、鉄道、トラックの各輸送区間を1枚の書類でカバーします。そして、フォワーダーが日常的に扱う分割があります。運送会社がフォワーダーに発行するmaster bill of lading(MBL、親BOL)と、フォワーダーが荷主に発行するhouse bill of lading(HBL、子BOL)です。これらは同一貨物に対する2つの書類で、コンテナ番号や港などのフィールドを共有しますが、発行者名、参照番号、運賃支払条件が異なります。
各タイプでフィールドの配置が異なります。マースクの海上BOLではコンテナ番号が右上、船名の隣にあります。MSCのBOLではページ中央、貨物明細グリッドの上にあります。ハウスBOLには、マスターBOLと相互参照するHBL参照番号というフィールドが追加されますが、ストレートBOLにはこのフィールドはありません。これら5種類すべてを、タイプごとの設定なしに処理できない抽出ツールは、貨物を動かす代わりにテンプレートのメンテナンスにチームの時間を費やさせることになります。
データは読み取るだけでなく、変換する必要があります。 BOLには、荷積港が「CNSHA」「Shanghai」「Port of Shanghai, CN」などと記載される場合があります。TMSが期待するのは、国連欧州経済委員会(UNECE)が1981年から維持する5文字のUN/LOCODE「CN SHA」です。このシステムは249カ国、10万以上の地点をカバーします。BOLに運送会社名が「Maersk Line」と印刷されていても、TMSが要求するのはNMFTAが管理するSCACコード(Standard Carrier Alpha Code)「MAEU」かもしれません。商品にはHSコードが必要です。これは世界税関機構(WCO)が維持し、200カ国以上で使用される Harmonized Systemに基づくコードで、「woven polypropylene bulk bags」のような自然言語の貨物説明から「6305.33」にマッピングされます。プレーンテキストを出力するだけのBOL抽出ツールは完成ではありません。標準化されたコードを出力するツールこそが完成形です。
これが、BOL抽出が請求書抽出やレシート抽出とは異なる問題である核心的な理由です。BOLデータ抽出の完全な定義と、TMSデータ入力などの関連概念との違いについては、BOLデータ抽出とはのガイドをご覧ください。
従来のOCRやテンプレート方式がBOLで通用しない理由
テンプレートベースのOCRは、レイアウトが固定された書類(自社の請求書、発注書、自社で設計したフォーム)向けに設計されています。船荷証券(BOL)は、その前提をあらゆるレベルで覆します。
マルチキャリアによるフォーマットの爆発的増加。 1日に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」はマーカーで丸で囲まれています。スキャンは三代目のカーボンコピーで、元の文字が貨物記述フィールドに透けて見えます。従来のOCRは、スタンプをノイズ、カーボンの透けを余分な文字、90 DPI未満の手書きを判読不能として扱います。しかしBOLでは、これらの「ノイズ」要素こそが、キャリアの請求書紛争を引き起こす可能性が最も高い3つのデータポイント、すなわち手書きの個数、スタンプされた重量、マークされた運賃条件を保持しています。
NMFC貨物クラスには意味理解が必要。 全米自動車貨物分類システムは、密度、積載性、取扱性、責任に基づいて18の貨物クラス(50~500)を定義しています。BOLには、商品説明「木製家具、KD」の横に「クラス70」と記載されている場合もあれば、クラスを記載せずに商品のみを記載し、キャリアがクラスを適用することを期待する場合もあります。テンプレートOCRは、両方を同じボックス内のテキスト文字列として読み取ります。意味抽出は、「クラス70」が「木製家具」を修飾し、商品説明列ではなく貨物クラス列に属することを理解します。この区別が、運送状が正確であるか、3週間後に300ドルの再分類手数料を引き起こすかを決定します。
これらの3つの障害は複合的に作用します。キャリアごとのテンプレートが必要で、手書きが読めず、貨物クラスと商品説明を区別できないツールは、労力を節約するどころか、元のデータ入力タスクと同じくらい大きな確認待ちキューを生み出しているにすぎません。
最新のAI抽出が船荷証券を読み取る仕組み
手作業によるBOLデータ入力を代替するパイプラインは、5つの段階で構成されています。これを理解することで、テンプレートOCRでは不可能だった、複数運送業者のBOLに対するセマンティック抽出の処理方法が明確になります。
このパイプラインと従来のアプローチの根本的な違いは、位置ベースからセマンティックベースの抽出への移行にあります。テンプレートOCRは「データはどこにあるか」を問い、位置が変わると機能しなくなります。一方、セマンティック抽出は「このデータは何か」を問い、レイアウトが変わっても適応します。頻繁に運送業者が変わるBOLを扱う物流チームにとって、これは自動化パイプラインとテンプレート保守作業の違いを意味します。
主要なBOLフィールドとそれを検証する基準
BOL抽出プロジェクトは、どのフィールドが重要かを定義することから始まります。以下の表は、あらゆる物流業務に必要な5つのグループ、各グループ内の具体的なフィールド、そして抽出された値が単に存在するだけでなく正しいかどうかを判断する検証基準を示しています。
| フィールドグループ | 抽出するフィールド | 検証基準 | 重要性 |
|---|---|---|---|
| 当事者 | 荷主の名称・住所、荷受人、通知先、運送業者/SCACコード | SCAC (NMFTA): 2~4文字の運送業者コード; EU税関向けEORI番号 | 配送先の誤りは1日100~500ドルのデマレージを発生; 通知先の誤りは出荷の未通知につながる |
| ルーティング | 積港、揚港、受取地、配送地、船名/航海番号、コンテナ番号、シール番号 | UN/LOCODE (UNECE): 5文字コード (例: CN SHA, NL RTM); ISO 6346: コンテナチェックデジット | ISF申告には積込み24時間前の正しい港コードが必要; コンテナID不一致は税関保留の原因に |
| 貨物 | 商品説明、個数・梱包タイプ、総重量 (kg/lbs)、正味重量、容積/寸法、運送等級、NMFCコード、HSコード | NMFC: 18の運送等級 (50~500); HS: 6桁の国際コード+各国固有の拡張; SOLAS VGM: 2016年7月以降コンテナの検証総重量が必須 | 運送等級の再分類は1回150~300ドルのコスト; HSコードの誤りは不足関税の最大10倍の税関罰金を招く |
| 料金・条件 | 運賃条件 (前払い/着払い)、海上運賃、バンカーサーチャージ、ターミナルハンドリング、付帯費用 | インコタームズ2020: コスト/リスク移転ポイントを定義 | 運賃支払条件の誤りは、誤った当事者への請求や、既にフォワーダーに支払い済みの顧客からのコスト回収につながる |
| 参照情報 | BOL番号、HBL/MBL相互参照、ブッキング番号、PO/商業送り状参照、ピックアップ日、配送日/ETA | 形式は運送業者により異なる; 両方を扱うフォワーダー向けHBLとMBL間の相互参照検証 | BOL番号なしではTMSで出荷追跡不可; 配送期限の遅れはサービスレベル契約を損なう |
コンテナ番号のチェックデジットは、特に有用な検証手段です。ISO 6346では、各コンテナ識別子は3文字のオーナーコード(例:マースクはMSK)、1文字の機器カテゴリ識別子(Uは貨物コンテナ)、6桁のシリアル番号、およびそれらの文字から計算されるチェックデジットで構成されます。抽出結果がMSKU 907082 3なのに実際のコンテナがMSKU 907082 8だった場合、チェックデジットの不一致で即座にエラーが判明します。そのコンテナ番号がTMS、顧客の追跡ポータル、税関申告に届く前にです。抽出時にこの検証を行うツールは、コンテナがターミナルで行方不明になるまで気づかれないエラーを防ぎます。
貨物グループ(商品説明、重量、運送クラス、HSコード)は、BOLの中で最もデータ密度が高く、最もエラーが発生しやすい部分です。また、運送会社によって最も大きく異なる部分でもあります。あるBOLでは5つの商品明細を個別重量と一括運送クラスで記載し、別のBOLではすべてを「FAK」(混載貨物)として1行にまとめます。さらに別のBOLでは、荷主が手書きで余白にHSコードを追加します。BOL抽出ツールに必要なのは、運送会社ごとのレイアウトを知ることではありません。必要なのは、運送会社や荷主が表現するあらゆる方法において、各データタイプがどのように見えるかを理解することです。
バッチ処理:複数運送会社のBOLを1つのスプレッドシートに
BOL抽出の真価は、バッチ処理(1回の実行で数十から数百の文書を処理)において発揮されます。ここで重要なのはバッチファースト処理という設計思想です。
あるフォワーダーが午前中のメールから80件のBOLを処理する場合を考えます。これら80件の文書は12社の異なる運送会社から届き、4種類のBOL(船荷証券、ハウスBOL、マスターBOL、ストレートBOL)にまたがり、鮮明なデジタルPDFから地域のトラック運送会社のスキャンしたカーボンコピーまで混在しています。これをスケールさせるワークフローは次の通りです。
1. すべてのBOLを一度にアップロード。運送会社ごとの仕分けやBOLタイプの事前分類は不要です。バッチはPDF、JPG、PNG、複数ページの文書を区別なく受け付けます。
2. 列を一度だけ定義。同じ15~20の列名がバッチ内のすべてのBOLに適用されます。AIがマッピングを処理します。ストレートBOL(HBL/MBLの相互参照なし)の場合は該当列を空白にし、複数行の貨物グリッドがある船荷証券の場合は商品明細ごとに別の行に展開します。文書ごとの設定は不要です。
3. 例外のみを確認。AIが高い信頼度で抽出したフィールドは自動的に通過します。信頼度が低いフィールド(かすれたカーボンコピーの重量、にじんだシール番号など)は人間の確認用にフラグが立てられます。物流担当者は80件のバッチあたり5~10件のフラグ付きフィールドを確認するだけで、手動で1,200件のフィールドを入力する必要はありません。これがデータ入力作業を置き換えることと、単に「データ確認」と名前を変えることの違いです。
4. 1つの出力ファイル。結果は1つのExcelスプレッドシートです。BOLごと(または複数明細の出荷の場合は商品明細ごと)に1行で、定義したフィールドに一致する列が含まれます。この出力はスプレッドシートネイティブです。ExcelやGoogleスプレッドシートに直接読み込まれ、TMSへのインポート準備が整います。Googleスプレッドシートを使用するチームは、BOLからTMSへのワークフローでサイドバーアドオンを介してスプレッドシート内で抽出を実行できるため、ファイルの受け渡し手順が完全に不要になります。統合のオーバーヘッドなしでバッチ処理を拡張する方法の詳細は、複数運送会社のバッチBOL抽出をご覧ください。
エクスポートオプション:抽出データを必要な場所へ
抽出されたBOLデータの目的は、別のシステムに入力することです。どのシステムを使うかは、お客様の業務によります。選択するエクスポート方法によって、抽出からワークフローまでの手作業の量が決まります。
Excel / CSV エクスポート
対象: ファイルアップロードでTMSにインポートするチーム
抽出したBOLデータをXLSXまたはCSVでダウンロード。CargoWise、Descartes、McLeodなど、CSVインポートに対応するTMSのインポートテンプレートに列をマッピングします。1ファイル、1インポート、手入力は不要です。
Google スプレッドシート アドオン
対象: スプレッドシートで業務を管理するチーム
Googleスプレッドシートのサイドバーアドオンで、BOLをアップロードし、抽出列を定義し、構造化データを現在のシートに直接追加できます。追跡用スプレッドシートから離れる必要はありません。チームが既に使っているツール内で抽出が完了します。
API 連携
対象: 社内システムで大量処理を行う業務
REST APIがBOLファイルを受信し、プログラムで構造化データ(JSONまたはCSV、フィールドごとの信頼度スコア付き)を返します。信頼度の低い抽出はシステムが自動的に人間のレビューに回し、信頼度の高い結果は直接TMSにプッシュできます。
適切なエクスポート方法は、処理量と技術リソースによって異なります。1日50件のBOLであれば、Excelエクスポート+TMSインポートで十分です。1日500件になると、手動ファイルの受け渡しが新たなボトルネックになります。多くのチームはExcelエクスポートから始め、処理量が開発作業を正当化する規模になった時点でAPI連携に移行します。抽出エンジンは両方の方法をサポートしているため、エクスポート方法を変更してもツールを切り替える必要はありません。
BOL抽出ツールの選び方
本番レベルのBOLを処理できるツールと、クリーンなデジタル文書をたまに使うだけのツールを分ける5つの基準。
1. キャリアごとの設定不要で複数キャリアに対応。 試金石:マースクの海上BOL、MSCの海上BOL、オールドドミニオンのストレートBOL、地域LTLキャリアのスキャンカーボンコピーを、同じバッチ、同じ列定義で、テンプレートを1つも作らずに処理できるか。キャリアごとにフィールド位置の定義が必要なら、それは抽出ツールではなく、テンプレート保守作業を買っていることになる。
2. 標準コードの検証と正規化。 コンテナ番号をISO 6346チェックデジットルールで検証し、港名を標準形式(理想的にはUN/LOCODE)に正規化し、「Maersk」「MAERSK LINE」「MAEU」が同一キャリアを指すと認識できること。この層がなければ、手入力が手作業のデータクレンジングに変わるだけ——同じ労力、違う工程。
3. 複数ページと明細レベルの抽出。 コンテナ化貨物の海上BOLは3~5ページになることが多い。商品説明、コンテナ番号、シール番号、パッケージ数は継続ページに分散している。1ページ目しか読めないツールではデータの半分が未抽出のまま。各商品行が個別のデータ行になる明細対応は、税関分類や在庫照合に不可欠。
4. フィールドレベルの信頼度スコアリング。 実際の物流業務で受け取る文書品質の混在に対し、100%のストレートスルー処理を達成する抽出ツールは存在しない。重要なのは、ツールがどのフィールドに確信がないかを教えてくれること。抽出フィールドごとの信頼度インジケーター(高/中/低)があれば、チームは不確実な抽出(通常フィールドの5~10%)だけを確認し、残りはそのまま下流システムに流せる。
5. バッチファースト設計と統合出力。 1日5件の出荷なら1件ずつ処理でも問題ない。50件なら、バッチアップロード、バッチ処理、単一の統合出力——1つのスプレッドシート、BOLごとに1行、1回のエクスポート——が必要。ツールはバッチワークフロー用にゼロから設計されているべきで、複数選択ダイアログの裏で文書を順次処理する「バッチモード」を後付けしたものでは不十分。
これらの基準を、実際に受け取るBOL、実際に取引のあるキャリアの書類でテストすること。単一キャリアのクリーンなデジタルBOLのデモでは、火曜の朝に15キャリアから届く40件のBOLバッチをツールがどう処理するかは何も証明できない。
よくある質問
AI抽出はどのようなBOLタイプに対応できますか?
テンプレート不要のAI抽出ツールは、ストレートBOL、海上BOL、複合一貫輸送BOL、マスターBOL(MBL)、ハウスBOL(HBL)など、主要なBOLタイプすべてを同じ設定で処理できます。AIはテンプレート上の位置ではなく、意味に基づいてフィールドを識別するため、運送会社のストレートBOLとマースクの海上BOLが同じ列定義で処理されます。HBLのマスターBOL参照番号のようにBOLタイプ固有のフィールドがある場合は、全ドキュメントタイプにわたって必要なフィールドの和集合を定義し、該当ドキュメントに存在しないフィールドは空白のまま出力されます。
BOL抽出でISO 6346に基づくコンテナ番号の検証は可能ですか?
可能なツールもありますが、すべてではありません。ISO 6346コンテナ番号検証(所有者コードとシリアル番号からチェックデジットを計算し、抽出された数字と比較する処理)は、抽出後の検証レイヤーであり、転記ミスがTMSに到達する前に検出します。コンテナ検証がワークフロー上重要である場合(海上貨物を扱うなら重要です)、ベンダーに抽出パイプラインにこのステップが含まれているか確認してください。抽出されたチェックデジットと計算されたチェックデジットが一致しない場合は、そのフィールドを人間による確認対象としてフラグ付けする必要があります。
BOL抽出は手書き入力やドックレベルのBOLに対応していますか?
はい、ただし限定的です。最新のビジョンAIモデルは、判読可能な手書き(活字体のブロック体、ほとんどの筆記体、運転手が通常明確に記入するBOL番号や個数などの標準化されたフィールド)に対して、高い精度でBOLフィールドを読み取ることができます。ただし、薄くなったカーボンコピー、手書きに重なったスタンプ、ペン圧が弱すぎてスキャン可能な跡が残っていない文書では精度が低下します。このような場合、適切に設計された抽出ツールは推測値を出力するのではなく、低い信頼度スコアでフィールドをフラグ付けし、人間による確認を促します。
複数ページにわたるBOLで、貨物詳細が継続ページにある場合の抽出方法は?
最新の抽出システムは、複数ページのBOLを1つのドキュメントとして取り込み、抽出したフィールドを1つの出力レコードに統合します。荷主情報(荷送人、荷受人、通知先)は通常1ページ目にあります。貨物詳細、コンテナ番号、シール番号、梱包数は継続ページに記載されることが多く、ツールはこれらを同一貨物と認識して結合します。複数行の貨物明細の場合、各商品行はヘッダーフィールド(BOL番号、荷送人、港)を繰り返した個別の出力行になります。これは、明細レベルデータを期待する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データを直接抽出できます。ファイルのダウンロードとアップロードのサイクルは不要です。
各キャリアのBOLでどの程度の精度が期待できますか?
最新のAI抽出技術により、主要キャリア(Maersk、MSC、CMA CGM、Hapag-Lloyd、COSCO、ONE、Evergreen)の鮮明なデジタルBOLでは、フィールドレベルで95~99%の精度を達成しています。低解像度のスキャン、カーボンコピーの劣化が激しい場合、または手書きのドックBOLでは精度は低下しますが、それでも同じ文書に対するテンプレートOCRの精度を大幅に上回ります。重要なのは単なる精度ではありません。重要なのは信頼できるスループット、つまり手作業を介さずに処理できるBOLの数です。信頼度スコアリングによる95%のフィールドレベル精度では、約5%のフィールドを確認するだけで済みます。これは20フィールドの抽出であれば、1件のBOLあたり約1フィールドの確認です。つまり、80件のバッチで80フィールドを確認するのと、1,600フィールドを手入力するのとの違いです。
BOL抽出は税関ブローカーの代わりになりますか?
いいえ。BOL抽出はデータ入力のステップ、つまりBOLからフィールドを読み取り、構造化された形式に変換する作業を自動化します。ライセンスを持つ税関ブローカーが提供する規制上の判断(HSコードの分類決定、税関評価、自由貿易協定の適格性判断、輸入申告戦略)を代替するものではありません。抽出によってタイピング作業がなくなるため、ブローカーは専門知識を要する分類やコンプライアンスの判断に時間を割くことができます。抽出が物流書類全体の中でどのように位置づけられるかの詳細については、BOL抽出とは何かに関するガイドをご覧ください。
出荷データを取得するためのBOL抽出とEDIの違いは何ですか?
EDI(電子データ交換)は、キャリアから直接構造化された出荷データを提供するため、抽出は不要です。ただし、EDIはキャリアごとの設定、テスト、継続的なメンテナンスが必要であり、多くの中小キャリアやフォワーダーはEDIに対応していません。実際には、ほとんどの物流業務では、主要キャリアからの定期航路にはEDI、それ以外からのPDF BOLという混合で受け取っています。BOL抽出はPDF側を処理します。この2つのアプローチは補完的であり、競合するものではありません。完全な比較については、EDI vs AI BOL抽出をご覧ください。
船荷証券の抽出とは、遅いデータ入力を速くすることではありません。それは、そのステップ自体をなくすことです。つまり、人間のオペレーターが、自分が作成したわけでもない書類から、覚えなければならないキャリアの略語を使ってフィールドを書き写し、タイプミスがあっても気づかないTMSに入力するというステップです。BOLが受信箱とTMSの間で滞留する1時間ごとに、顧客は荷物を追跡できず、税関申告は開始されず、実際に受け取った貨物に対して運送会社の請求書を照合することもできません。抽出はそのギャップを数秒に縮めます。取り戻した時間をどう使うかは、あなた次第です。