送金前に確認する書類
5タブのサプライヤー支払パッケージを構築し、所有者、鮮度ルール、例外承認を身元、契約、請求書、銀行証拠に割り当てます。
仕入先関係は、送金が保留されている間にメールスレッドから再構築する必要はありません。 1リリースパッケージを受け取り、誰に支払うか、なぜその金額が必要か、それを裏付ける書類、各事実を確認した担当者、まだ開いている例外が表示されるはずです。
決定を1カバーシートに配置する
パッケージのカバーは6支援文書ではありません。それはレビューアーが1添付ファイルを一度に比較し、それらの間の関係を忘れないようにするための照合ページです。
支払参照およびベンダーID
中国語での正式名称およびUSCC
契約当事者/請求書発行者/銀行受取人
発注書または契約/請求書/マイルストーンの参照
金額、通貨、支払期日、銀行所在国、および支払目的
既存または変更された銀行情報
作成者、商業承認者、財務承認者、および例外所有者
3の異なるエンティティを1「仕入先名」フィールドに強制的に入力しないでください。契約上の売主、請求書発行者、または受取人が異なる場合は、それぞれを別行に表示し、関係性を説明する文書を指し示してください。空白のフィールドは可視ですが、隠れた想定は可視ではありません。
タブ1:身元証明証拠
正確な中国語の法人名、統一社会信用コード(USCC)、ステータス、および情報源を含む、日付付きの会社登記結果を含めてください。現在の営業許可証はファイルを補完できますが、唯一の最新チェックであってはなりません。2025の会社登記措置は、以下を通じて利用可能です。 重慶市市場監督管理局、会社許可証に記載されている項目の中に名称と統一社会信用コード(USCC)を列挙しています。これらは、許可証が銀行口座またはこの請求書の証拠であることを意味するものではありません。
APは算術および文書の一致を所有しています。 国家市場監督管理総局(SAMR)登録サービスページ は、公開登録システムを通じて利用可能な全国の会社情報を説明しています。調達またはベンダーオンボーディングがこのタブを所有し、買掛金担当者は、法人名と統一社会信用コード(USCC)が表紙で使用されている値と同じであることを確認します。最新の照会が必要な場合は、 ChinaValidate会社検索ガイド を使用してください。
タブ 2:商業的義務
署名済みの契約書または承認された発注書、関連する改正条項、およびこの金額の支払いを確定させる条項または別添書類を含める。審査担当者は、受信箱を検索せずに、商品またはサービス、数量、価格、通貨、支払段階、および契約当事者を特定できる必要がある。
支払いがマイルストーンに依存する場合は、その観察を行った者が保有する証拠(サンプル承認、生産完了サインオフ、検査結果、船積書類、またはサービス受領証)を追加する。財務部門は証拠が存在し承認されていることを確認するが、PDFからの製品品質を保証するものではない。契約事実の所有権は調達部門にあり、マイルストーンの所有権は運用、エンジニアリング、または品質部門にある。
タブ 3:取引リクエスト
サプライヤーのプロformaインボイスまたは商業請求書、または取引に対する合意された支払リクエストを含める。発行者、購入者、商品またはサービス、POまたは契約参照番号、金額、通貨、支払条件、および文書日付を特定する必要がある。中国本土のVATインボイスは異なる税務文書であり、事前出荷リクエストがfapiao(中国の正規領収書)でないからといって、海外送金パケットを不完全としてマークしてはならない。
APはリクエストと契約およびマイルストーンを比較し、重複する請求書番号をチェックし、クレジット、割引、前払い入金、または部分支払いのいずれかを記録します。発行者が契約販売者でない場合は、「同じグループ」とコメントに記入するのではなく、差額をタブ5に移動してください。 インボイス発行者用語集 この役割を受取人と分離する。
タブ 4:銀行指示および独立した確認
受取人名義、口座番号、銀行名および国、SWIFTまたはルーティングデータ、支払参照番号、および指示の源泉を一緒に保持する。これらの詳細を承認済みベンダーマスタおよび以前の成功した支払い(1が存在する場合)と比較する。インボイスは支払請求であるため、変更された口座の認証に使用される唯一の情報源であってはならない。
新規口座または一切の変更に対して、コールバック記録を追加する:日時、対応した担当者、使用された電話番号またはチャネル、その連絡先がすでにどのように知られていたか、旧詳細の確認、新詳細の確認、およびチェックを実行した従業員。英国政府 支払横取りガイダンス 信頼できる連絡先および承認手続きを推奨しているが、その インボイス詐欺ガイダンス 銀行変更メッセージに含まれる連絡先情報を使用してはならないと述べている。
財務部門は最終的な支払フィールドおよび実行を所有する。購入者は通常の制裁、輸出管理、または銀行コンプライアンスレビューも必要とする場合がある;このパケットはこれらの統制を置き換えるものではない。エンティティから口座への推論には、 受取人チェックワークフローを使用する。
タブ 5:1 明示的な例外、所有者、および有効期限
検証済みサプライヤー、契約当事者、インボイス発行者、または受取人が一致しない場合、必要な文書が利用できない場合、またはポリシーの有効性が期限切れになった場合には、例外ページが必要である。正確な差異、商業的説明、独立した証拠、残存リスク、補完的統制、承認者、および有効期限を記載する必要がある。
「承認済みサプライヤー」は例外理由ではない。新しい銀行詳細と同じメールで送信された関係証明書も例外理由ではない。より強力な証拠の例としては、署名済みの三者間支払条項、現在の社内関係記録、受取人を明記した契約改正条項、および制御された連絡先を通じた独立した確認がある。差異に応じて、法務、コンプライアンス、税務、または財務部門が決定を所有する必要があるかもしれない。
イベント駆動型の有効性を使用し、1 の任意の年齢に基づかないこと
- 会社の証拠: リスクベースのポリシーウィンドウを設定し、その後、法人名、ステータス、住所、所有権、連絡先、または紛争の変更後に早期に更新する。「昨年チェック済み」は現在のルールではない。
- 契約およびマイルストーン: この支払いに対するバージョンおよびイベントを使用する。改正がない限り、以前のPOは新しい金額を支えることはできない。
- インボイスまたはリクエスト: この金額に関連付け、既に支払われているか代替されていないことを確認する。
- 銀行指示: 以前から長年正常に使用されていたアカウントであっても、変更は新たな認証イベントとして扱う。
- 例外: 取引、金額、日付、または明示された条件によって期限切れとする。1時間の承認が恒久的なベンダーマスタルールのようにならないようにする。
ポリシーでは、異なる会社のチェックに対して30、90、または180日を選択できるが、これらの数字は内部リスク設定であり、中国の法的有効期間ではない。後続の監査で判断を再現できるように、使用されたポリシーバージョンを記録する。
2日にわたってパケットを構築する
- T-2営業日: 調達部門が支払参照を開き、ベンダーIDをロックし、身元および契約証拠を添付する。
- T-1: マイルストーン所有者がイベントに署名し、AP(未払金)がリクエスト、金額、通貨、発行者を照合し、相違点には所有者を割り当てる。
- T-0: 財務部門が銀行詳細を管理された記録と照合し、独立したコールバックを完了し、2人の承認を確認する。
- リリース後: 銀行確認書、価値日、最終承認者、および拒否または返送メッセージを同じパケットに保存する。
この順序により、支払いを入力した人物が、パケットの作成、変更、承認、実行を行う唯一の人物になることを防ぐ。運用上の最終段階でのチェックは 中国サプライヤーへの電信送金チェックに提出される証拠を定義している。
パケットのリリース、保留、または拒否
リリース 債務が期日にあり、金額と通貨が整合し、エンティティチェーンが理解され、銀行指示が認証され、必要な承認が存在する場合。 保留 証拠が不足しているが、指定された所有者が期限前にそれを埋められる場合。 拒否またはエスカレーション アカウント変更が認証できない場合、文書が改ざんされているように見える場合、支払いに契約上の根拠がない場合、または権限を持つ者が例外を受け入れない場合。
架空のサプライヤーが請求書を送信した場合を想定する HX-2048 これは16:40のよく知られたメールスレッドからのもので、当日払いを要求し、新しい香港の受益者を導入している。タブ1から5月3日はまだ完全である必要がある。タブ4は失敗する。新しい口座には独立して入手可能な確認書がなく、タブ5には承認された受取関係がない。正しい結果は 保留であり、「95%完了」ではない。パケットには、調達部門と財務部門が取得しなければならないものが正確に表示される。
他のレビューアーが必要とするファイルを保持する
元のメッセージ、ネイティブ添付ファイル、利用可能な場合は関連ヘッダー、以前のおよび新しい銀行指示、コールバックノート、承認イベント、例外証拠、および最終的な送金確認書を保存する。機密性の高い銀行データは、必要なスタッフのみがアクセスできるように制限する。英国政府 国際貿易詐欺ガイダンス また、取引詐欺防止の一環として、パートナーの審査および設立時の証拠を扱う。
このパッケージは、口述歴史に頼らず4の質問に答えるべきである:どの金額が誰に、どの法的関係に基づき、どの認証済み口座に対して、そして残りの差額を誰が受け入れたか。より長いサプライヤーの履歴を サプライヤー承認ファイルに保管し、このリリースパッケージをコンパクトで取引固有のものとし、必要なタブが静かに空のままになっている間は承認不可能なものとする。