完全な案件ファイルは
資金実行可能な案件ではない

資金提供者は案件ファイルを開き、書類が一致しているかを確認します。

自動車金融の資金実行デスクは、署名済み契約が承認された与信内容どおりであること、計算と開示が正しいこと、付帯商品がプログラムに適合していること、すべての条件がクリアされていること、そして案件を資金実行・保留・与信差し戻しのいずれにできるかを確認します。完全性は書類一式をキューに入れるための基準です。一致しているかどうかを判断するのは資金提供者です。

3つの役割が同じ事実に異なるタイミングで関わり、それぞれが書類一式の一部しか見ていません。

案件ファイルとは、異なる当事者がそれぞれの言葉で作成した書類の束です。不動産クロージングパッケージも同じ形をしており、それをまとめた経験がある人ならこの照合の問題は身近なものです。

車両の識別情報は3か所に存在します。注文書、割賦販売契約、そして保険証明書ページです。所有権申請書は4つ目の転記であり、通常は同じDMS（ディーラー管理システム）の記録から生成されます。買い手の名前はクレジット申込書と契約に記載され、保険証券が一致すべき名前でもあります。金額は注文書と契約に現れますが、この2つの書類は同じ数字を記載していません。

VINチェックの結果は3通りあり、そのうち1つはページを見ただけでは解決できません。

3つの結果とは、すべての書類で同じ17文字である、いずれか1つで異なる17文字である、またはすべての書類で同じ17文字だが納車された車とは別の車のものである、のいずれかです。最初の2つは比較できます。3つ目はできません。すべての書類が一致しているからです。

49 CFR 565.13によると、VINは17文字です。1～3桁目は製造者、4～8桁目は車両、9桁目はチェックディジット、10桁目はモデルイヤー、11桁目は工場、12～17桁目はシリアル番号を示します。使用可能な文字セットからは、1や0と混同しやすいI、O、Qが除外されています。

形式チェックでは、文字列が17文字で使用可能な文字のみで構成されていることを確認します。そこで止まるVIN検証が確認するのは文字列の形であり、車の同一性ではありません。転置によって異なる2つのVINを見てみましょう。

最初の15文字は一致しています。違いは最後の2文字にあり、製造者とモデルイヤーが一致した後に確認者が流し読みする部分です。1文字ずつ比較すれば発見できます。ちらりと見ただけではできません。

9桁目はチェックディジットで、他の16文字に対するチェックサムです。転記ミスを検出するために存在しますが、誰かが計算した場合に限られます。目視レビューでは計算しません。混在したPDFからシリアル番号を抽出するときにも同じ問題が生じます。きれいに見える文字列は、検証済みの文字列とは同じではありません。

より難しいのは3つ目の結果です。ある購入者は、同一の2台を試乗し、在庫期間が長く1,500ドルの割引が付いていた2台目を選んだところ、後に書類が1台目で作成されていたことに気づきました。すべての書類に同じVINが記載されていました。書類間の比較ではその案件ファイルは合格していたでしょう。比較するものが何もなかったからです。車両の同一性を証明できる唯一の根拠は、車両または所有権証書のVINであり、書類の束ではありません。

融資金額は定義された数値であり、注文書には通常それとは異なる金額が表示されます。

契約書の融資金額は注文書の総販売価格ではなく、その差額は多くの場合正当です。レギュレーションZ、12 CFR 1026.18(b)では、現金価格から頭金を引き、債権者が融資したその他の金額を加え、前払金融費用を差し引いたものと定義されています。同規則の1026.18(j)では別途総販売価格が定義され、これには金融費用が加算されます。注文書には総販売価格、残高、または融資金額の行が表示されることがあり、これらは3つの異なる数値です。

契約書の金額が高くなる最も一般的な理由は追加商品です。CFPBの2024年秋の自動車金融監督報告書によると、消費者は通常、GAP、サービス契約などの商品を組成時に融資を受け、保険料は前払いで融資金額に含まれます。1026.18(c)(1)(iii)では、明細にこれらの任意商品の受取人を特定する必要があります。下取り不足額ももう一つの正当な差額です。CFPBの2024年の下取り不足額報告書では、調査した取引の12%で下取り不足額が見られ、新車では平均$5,073、中古車では$3,284でした。

以下は差額を埋める橋渡しの形です。注文書には販売価格$28,900、頭金$3,000、税金と手数料$2,150が表示され、残高は$28,050です。契約書には融資金額$30,640が表示されています。$2,590の差額は$1,895の車両サービス契約と$695のGAP保険です。注文書に両商品が記載されていれば、橋渡しは成立し例外はありません。記載がなければ、$2,590が例外となります。

金額チェックは等しいことではありません。差額のすべての金額に名前があるかどうかです。

契約書内の計算は別のチェックです。注文書との橋渡しが成立しても、契約書が内部的に誤っていることがあります。これは掛け算が合わない明細行と同じ失敗パターンの一段上のものです。個々の数値は正しく見えても、それらの関係が正しくないのです。

保険証明書ページに正しいVINが記載されていても、資金提供者のチェックに通らないことがあります。

保険証明書ページは保険契約の概要であり、記名被保険者、対象車両とそのVIN、補償内容と免責金額、そしてリーエンホルダーまたはロスペイが記載されています。VINは資金実行で重要な項目の一つにすぎません。

実際の信用組合の公開要件を見ると、その形が分かります。資金提供者がリーエンホルダーまたはロスペイとして記載されていること、保険契約上の担保がローン書類上の担保と一致すること、補償限度額がローン額を下回らないこと。これらは三つの独立した確認事項であり、VINの一致は二つ目を満たすにすぎません。

記名被保険者は、最も頻繁に誤って見える項目であり、時に正しいこともあります。配偶者の名前、法人名、旧姓での保険契約は、その人物または法人が契約上の買主または共同買主であれば正当です。確認すべきは、記名被保険者が契約上の買主と一致するかどうかであり、1ページ目の最初の名前と一致するかどうかではありません。契約にまったく記載のない人物名義の保険契約が問題となります。

ロスペイは省略されやすい項目です。保険会社が保険金を支払う際に使用するのは、資金提供者の正確な法人名と住所です。資金提供者を追加被保険者として記載していてもロスペイとして記載していない保険契約は、証明書が完全に見えても、誤った欄にチェックが入っていることになります。異なるVINで作成された保険契約は別の車を対象としているため、保険契約上の担保はローン上の担保とは一致しません。

VINの一致は、そのVINに対して保険契約が作成されたことを証明するものです。保険料が支払われたこと、事故日時点で保険契約が有効であること、補償限度額が資金提供者のプログラムを満たすことは証明しません。これらは別々の確認事項であり、保険証明書ページは保険契約の証拠であって、その現在のステータスの証拠ではありません。

署名漏れを検出するレビューは、項目が不一致の場合には適切なレビューではない。

資金実行チェックリストは完全性を確認するツールです。各ドキュメントがルール（存在する、署名済み、日付入り、正しい様式）に適合するかを確認します。項目の不一致は2つのドキュメント間の関係であり、1つのドキュメントずつ見るルールでは検出できません。

• 存在は同一性ではない。 チェックリストは契約書にVINがあると示しますが、契約書のVINが注文書のVINと等しいとは示しません。
• 用語が異なる。 総価格、残高、融資金額、総販売価格は4つの異なる数値です。これらを1つの数値として扱うレビュアーは、正当な差異を指摘するか、その項目の確認をやめてしまいます。
• DMSは1つの値をすべての書式にコピーする。 通常、システムは1つのフィールドからVINを注文書、契約書、所有権申請書、保険依頼書に印刷します。1つの誤字が内部整合性となり、これが最も見つけにくい種類です。
• 目は接頭辞に引き寄せられる。 メーカーと年式が一致するため、レビュアーはシリアルも一致すると仮定します。最後の6文字こそ、1文字ずつ読まれる可能性が最も低い部分です。

チェックリストはVINが存在することを示せますが、他の2つのドキュメントが持つVINと同じであることは示せません。

キューがこれを悪化させます。資金担当者は案件ファイルのリストを処理しており、パケットを最初から最後まで読んでいるわけではありません。不備リストにない不一致は、所有権担当者、保険会社、または顧客が見つけるまで残ります。

2つのドキュメントが不一致の場合、どの項目かによってどちらが優先されるかが決まり、その答えは項目ごとに異なります。

ルールは項目ごとに異なり、比較する前に書き留めておくことで、定義の違いが例外になるのを防げます。これがなければ、すべての違いがエラーに見え、レビュアーは値を解決するのではなく平均し始めます。

抽出単位はドキュメントです。案件ファイルは複数のドキュメントの集合だからです。

案件ファイルごとに1行では、探そうとしている不一致が隠れてしまいます。同じフィールドをすべてのドキュメントから1つのテーブルに抽出し、1ドキュメントにつき1行（ドキュメントにテーブルがある場合は明細行ごと）にして、抽出後に比較します。

ImageToTable.aiのカスタム列抽出がこれを実用的にします。VIN、融資金額、総販売価格または残高、記名被保険者、ロスペイなど、必要な列名を入力すると、AIがページ上の位置ではなくフィールドの意味を理解して各値を特定します。列名は出力テーブルのヘッダーになります。資金提供者ごとのテンプレートも、ディーラーが書式を変更した際に描き直すゾーンもありません。

各行が1ドキュメントであれば、VIN列は1つで十分です。Document Type列がどのドキュメントが各値を提供したかを示すため、注文書のVIN、契約書のVIN、保険証券のVINを3つの別々の列なしで区別できます。

バッチ処理が量をこなします。案件ファイルのバッチを1回のアップロードで投入し、1つのExcelテーブルとして受け取れるため、作業単位が受付単位と一致します。出力はXLSX、CSV、JSONに対応します。

案件ファイルが1つのマルチページPDFとして届く場合は、Document Type (options: Purchase Order / Retail Installment Contract / Insurance Declaration / Title Application / Other)のような推論列を追加します。AIが各ページをその内容から分類するため、ページインデックスをドキュメントグループにフィルタリングできます。案件ファイルではマルチページマージをオンにしないでください。この設定は1つの論理ドキュメントのページ用であり、案件ファイルは異なるドキュメントの集合です。

計算列は1つのドキュメント内の計算をチェックできます。たとえば、Contract Math Check (output OK if Amount Financed equals the itemized total, otherwise the difference)は同じ契約書上にある2つの値を比較します。契約書の融資金額と注文書の残高を比較することはできません。これらの値は別々の行にあるためです。その比較はシート上の数式で行います。

行をエクスポートした後は、比較は通常の表計算作業です。ピボットまたは3つのルックアップで、案件番号とドキュメント種別ごとにテーブルを整形し、3つのVINを横に並べ、B2、C2、D2に3つのVINが入っているとして=IF(AND(EXACT(B2,C2),EXACT(C2,D2)),"match","check")を使用します。金額については、契約書の金額から注文書の残高と記名された追加項目を差し引き、残りがゼロかどうかを確認します。VINチェックが失敗した行、またはブリッジが一致しない行のみにフラグを立てます。

3行の抽出結果がその形を示します:

このテーブルは1つではなく3つの疑問を生みます。2つのVINが一致し、契約書が外れ値であるため、契約書が最初に確認すべきドキュメントです。記名被保険者が買主と異なるため、契約書には共同買主が必要か、保険証券に修正が必要です。注文書の残高と契約書の融資金額は$2,590異なるため、次にどの製品がその差額を説明するのかが問題になります。

バウンディングボックス(bbox)付きのレビューモードは、VIN行のチェックです。フラグが立ったセルにカーソルを合わせるかクリックすると、その元の領域が元の画像上でハイライトされます。画像上の領域をクリックすると、対応するセルが選択されます。バッチが大きい場合は処理後にAuto-annotateをオンにすると、ファイルを開いたときにボックスが用意されています。F&Iフォームの密集した手書き文字には、より強力なビジョンモデルを選択するアカウント設定である上位のモデル階層を使用してください。標準階層は印刷されたテーブル向けに作られています。

資金実行前の4ステップチェックで、資金提供者に指摘される前に不一致を捕捉できます。

このチェックは一度きりの監査ではなく、1週間分の案件ファイルに繰り返し適用できるものでなければなりません。4つの判断を一度決めてすべてのバッチに適用すれば十分です。

これを省略したコストは日数で測られます。Dealertrackの2020年の輸送中契約データでは、従来の紙の書類一式は平均5日間輸送中であり、紙の契約の4件に1件は、署名漏れ、条件の欠落、資金提供者の要件を満たさない契約などのエラーを含んでいました。VINの誤記で差し戻された案件ファイルは、その行列の最初からやり直しになります。

この方法には明確な限界があります。すべての書類が同じ誤りを繰り返している場合は検出できません。

抽出は根拠のある値を提供しますが、判定を下すものではありません。この境界が重要なのは、あいまいにしてしまうツールが新たな種類の不良記録、つまり権威があるように見えて説明できない記録を生み出すからです。

• VINのデコードや車両履歴の照会は行いません。 ツールはページ上の17文字を読み取るだけです。NMVTIS、メーカーのデータベース、所有権履歴、盗難車リストを照会することはなく、そのVINがその車のものであることを証明するものでもありません。
• チェックディジットの検証は行いません。 9文字目はシート外で計算できます。抽出は文字列を返すだけで、検証結果を返すものではありません。
• 書類をまたぐ判断は行いません。 比較はスプレッドシート上の数式です。ツールは値を抽出するだけで、2つの行が一致しないと判断したり、その不一致が何を意味するかを決めたりするものではありません。
• 資金実行の判断は行いません。 与信を承認したり、条件を解釈したり、資金を実行したり、案件が資金実行可能かを判断したりするものではありません。
• 署名の認証は行いません。 署名が存在するかどうかは分かりますが、本人が署名したか、電子署名の監査証跡が完全か、後から署名されていないかを検証するものではありません。
• 保険の証明は行いません。 保険証明書ページは保険契約の内容を示すもので、保険料が支払われたことや、事故日時点で保険が有効であることを証明するものではありません。
• 所有権のブランド確認は行いません。 サルベージ、再構築、水没などのブランドは案件ファイルではなく所有権記録に存在します。
• キーがなければ結合できません。 書類間で案件番号やVINが共通していなければ、行を自動で照合できず、担当者が日付、購入者、車両で照合する必要があります。

すべての書類が一致するケースが重要です。同じ誤ったVINがすべての書式に印刷されていると、書類一式は内部的に整合し、比較は通ってしまいます。それを確定できるのは車両、所有権、または在庫番号だけです。書類チェックは転記のチェックであり、車両のチェックではありません。

FAQ

注文書、契約書、保険記録にまたがるVINを自動で照合できますか？

各ドキュメントからVINを抽出してテーブルに自動でまとめることはできます。照合自体はスプレッドシートの数式で行います。3つの値が3つの行にあるためです。案件番号とドキュメント種別でテーブルを整形し、3つのVINを完全一致の文字列比較で確認してください。ツールがドキュメント間の判断を代行するわけではありません。

VINが有効か、盗難届が出ていないかをツールが確認しますか？

いいえ。印刷されているとおりにVINを読み取るだけです。車両のデコード、チェックディジットの検証、NMVTIS・メーカーデータベース・盗難車リストへの照会は行いません。これらは別のデータソースに対する別の手順であり、ページ上のVINが正しくてもこれらの確認で不合格になることはあります。

融資金額が注文書の合計と異なるのはなぜですか？

別の数値だからです。融資金額はレギュレーションZにより、現金価格から頭金を引き、その他の融資対象額を加え、前払金融費用を差し引いたものと定義されています。注文書には総販売価格、残高、総販売価格が表示されることがあります。GAPやサービス契約などの追加商品は融資対象となり融資金額に含まれ、下取りによる下取り不足額も同様に加算されます。その差額のすべてを項目として説明できるなら、その差は正当です。

VINが一致していれば資金実行に十分ですか？

いいえ。VINの一致は車両識別の確認を満たすだけです。資金提供者はほかにも、記名被保険者が契約上の買主または共同買主であること、資金提供者が正式な法人名でロスペイとして記載されていること、補償限度額がプログラムの要件を満たしていること、必要な署名が揃っていること、すべての条件がクリアされていることを確認します。

スキャンまたは撮影した案件ファイルも読み取れますか？

はい。PDF、JPG、PNG、WebP、AVIFに対応しており、スキャンやスマートフォンでの撮影も含まれます。手書き、筆記体、チェックボックスにも対応しています。F&I書類の密集した手書き文字は上位の処理ティア向けのケースです。標準ティアは印刷された表を対象としています。

案件ファイル全体が20ページのPDF1つだった場合は？

推論列としてドキュメントタイプ列を追加し、出力をページ索引として扱ってから、ページを注文書、契約書、保険、所有権のグループに絞り込みます。この用途ではMulti-Page Mergeを使用しないでください。この設定は1つの論理ドキュメントのページを1行にまとめるためのものであり、案件ファイルは異なるドキュメントの集合だからです。PDFをドキュメントごとに分割できる場合は、分割した方が1ドキュメント1行の表になり、より整理されます。

電子署名を検証しますか？

いいえ、署名の有無を超える検証は行いません。契約書や追加契約書に署名が表示されているかどうかは報告できます。署名者の本人確認、電子署名の監査証跡の完全性、資金実行前に署名されたかどうかは検証しません。これらの確認は電子署名プラットフォームと資金提供者自身のプロセスに属します。

書類一式は互いに一致すべき主張の集まりであり、最も重要な主張こそ、完全性チェックが決して読まないものです。案件ファイルを1つ通し、3つのVINと金額のつながりを比較して、資金提供者より先にどのドキュメントが矛盾しているかを見つけましょう。 案件ファイルで試す。