(57)【要約】  販売者支援自動支払と例外管理のためのシステムおよび方法を提供する。販売者は、販売者の請求書とマッチングしない購入者からの支払を受領し、この結果、調整が必要となる。調整文書生成器が、購入者から支払データを受領し、且つ、販売者から購入者に固有の注文データを取得して、調整文書を作成する。必要な実際の調整に応じて、様々な調整文書を生成することができる。次いで、調整文書を調整の承認のために１つまたは複数の購入者に固有の審査担当者の組に自動的に回付することができる。好ましくは、自動支払および調整処理システムは、販売者の金融機関と一体化することができる。
2007507800.tif 000002
【特許請求の範囲】
【請求項１】
調整文書を自動的に生成する方法において、
購入者から支払情報を受領する段階と、
販売者から請求書情報を受領する段階と、
前記支払情報と前記請求書情報とを比較する段階と、
前記支払情報が前記請求書情報と異なっている場合に、調整文書を自動的に生成する段階と、を含む方法。
【請求項２】
前記調整文書は、複数の利用可能な調整文書の中の１つである請求項１に記載の方法。
【請求項３】
前記支払情報に関する送金情報を受領する段階を更に有し、前記調整文書は、前記送金情報に少なくとも部分的に基づいて自動的に生成される請求項２に記載の方法。
【請求項４】
前記請求書情報と前記支払情報間の差は通貨の金額であり、前記調整文書は、前記通貨の金額の大きさに少なくとも部分的に基づいて自動生成される請求項２に記載の方法。
【請求項５】
前記調整文書を承認のために審査担当者に回付する段階を更に含む請求項１に記載の方法。
【請求項６】
前記請求書情報と前記支払情報間の差は、通貨の金額であり、前記回付段階は、前記通貨の金額の大きさに少なくとも部分的に基づいている請求項５に記載の方法。
【請求項７】
前記回付段階は、既定の販売者の設定に基づいている請求項５に記載の方法。
【請求項８】
前記回付段階は、前記購入者の特定情報に少なくとも部分的に基づいている請求項５に記載の方法。
【請求項９】
前記調整文書を承認のためにさらなる審査担当者に回付する段階を更に含む請求項５に記載の方法。
【請求項１０】
調整文書を審査担当者に自動的に回付する方法において、
ワークフロー承認プロセッサにおいて電子的な調整文書を受領する段階であって、前記調整文書は、購入者から受領した支払に基づいている段階と、
前記調整文書用の回付ワークフローを判定する段階であって、前記回付ワークフローは、前記調整文書内の情報に応じて可変である段階と、
前記回付ワークフローに基づいて、前記ワークフロー承認プロセッサから複数の審査担当者の中の少なくとも１人に対して前記調整文書を自動的に回付する段階と、を含む方法。
【請求項１１】
前記回付段階は、前記購入者の特定情報に基づいている請求項１０に記載の方法。
【請求項１２】
調整文書は、紛争となっている通貨の金額を含んでおり、前記回付段階は、前記通貨の金額の大きさに少なくとも部分的に基づいている請求項１０に記載の方法。
【請求項１３】
前記回付段階は、既定の販売者の設定に基づいている請求項１０に記載の方法。
【請求項１４】
前記回付段階は、前記購入者の特定情報に少なくとも部分的に基づいている請求項１０に記載の方法。
【請求項１５】
前記調整文書を承認のためにさらなる審査担当者に回付する段階を更に含む請求項１０に記載の方法。
【請求項１６】
調整文書を審査担当者に自動的に回付する方法において、
ワークフロー承認プロセッサにおいて電子的な調整文書を受領する段階であって、前記調整文書は、購入者から受領した支払に基づいている段階と、
前記調整文書用の回付ワークフローを判定する段階であって、前記回付ワークフローは、前記調整文書内の情報に応じて可変である段階と、
前記回付ワークフローに基づいて、前記ワークフロー承認プロセッサから複数の審査担当者の中の少なくとも１人に前記調整文書を自動的に回付する段階と、
を含み、
前記回付段階は、ＡＳＰ（Application Service Provider）によって実行される方法。
【請求項１７】
複数の審査担当者の中の少なくとも１人から承認を受領する段階と、
前記調整文書を使用して前記購入者から受領した前記支払を処理する段階と、
前記購入者から受領した前記支払を登録する段階と、を更に含む請求項１０に記載の方法。
【請求項１８】
前記複数の審査担当者の中の少なくとも１つから拒絶を受領する段階と、
前記調整文書を集金部門に回す段階と、を更に含む請求項１０に記載の方法。
【請求項１９】
調整文書を自動的に生成するシステムにおいて、
購入者から支払情報を受領し、販売者から請求書情報を受領する支払処理および例外管理アプリケーションと、
前記支払情報と前記請求書情報を比較するビジネスデータフィルタと、
前記支払情報が前記請求書情報と異なっている場合に、調整文書を自動的に生成する調整文書生成器と、を含むシステム。
【請求項２０】
前記調整文書生成器は、複数の利用可能な調整文書を含んでいる請求項１９に記載のシステム。
【請求項２１】
前記調整文書生成器は、前記購入者の特定情報に少なくとも部分的に基づいて前記調整文書を自動的に生成する請求項２０に記載のシステム。
【請求項２２】
前記請求書情報と前記支払情報間の差は、通貨の金額であり、前記調整文書生成器は、前記通貨の金額の大きさに少なくとも基づいて前記調整文書を自動的に生成する請求項２０に記載のシステム。
【請求項２３】
前記調整文書を承認のために審査担当者に対して回付するワークフロー承認プロセッサを更に含む請求項２０に記載のシステム。
【請求項２４】
前記ワークフロー承認プロセッサは、前記購入者の特定情報に基づいて前記調整文書を回付する請求項２３に記載のシステム。
【請求項２５】
前記請求書情報と前記支払情報間の差は、通貨の金額であり、前記ワークフロー承認プロセッサは、前記通貨の金額の大きさに少なくとも基づいて前記調整文書を回付する請求項２３に記載のシステム。
【請求項２６】
前記ワークフロー承認プロセッサは、既定の販売者の設定に基づいて前記調整文書を回付する請求項２３に記載のシステム。
【請求項２７】
前記ワークフロー承認プロセッサは、前記調整文書を承認のためにさらなる審査担当者に回付する請求項２３に記載のシステム。
【請求項２８】
前記ワークフロー承認プロセッサは、ＡＳＰ（Application Service Provider）として実装される請求項１９に記載のシステム。
【請求項２９】
前記ワークフロー承認プロセッサは、金融機関において実装される請求項１９に記載のシステム。
【請求項３０】
前記ワークフロー承認プロセッサは、サードパーティにアウトソーシングされる請求項１９に記載のシステム。
【請求項３１】
調整文書を審査担当者に自動的に回付するシステムにおいて、
電子的な調整文書を受領するワークフロー承認プロセッサであって、前記調整文書は、購入者から受領した支払に基づいており、前記ワークフロー承認プロセッサは、前記調整文書用の回付ワークフローを判定し、前記回付ワークフローは、前記調整文書内の情報に応じて可変である、ワークフロー承認プロセッサと、
複数の審査担当者であって、前記ワークフロー承認プロセッサは、前記回付ワークフローに基づいて、前記複数の審査担当者の中の少なくとも１人に前記調整文書を自動的に回付する、複数の審査担当者と、を含むシステム。
【請求項３２】
前記ワークフロー承認プロセッサは、前記購入者の特定情報に基づいて、前記調整文書を回付する請求項３１に記載のシステム。
【請求項３３】
前記調整文書は、紛争となっている通貨の金額を含んでおり、前記ワークフロー承認プロセッサは、前記通貨の金額の大きさに少なくとも部分的に基づいて前記調整文書を回付する請求項３１に記載のシステム。
【請求項３４】
前記ワークフロー承認プロセッサは、前記調整文書を承認のためにさらなる審査担当者に回付する請求項３１に記載のシステム。
【請求項３５】
前記ワークフロー承認プロセッサは、ＡＳＰ（Application Service Provider）として実装される請求項３１に記載のシステム。
【請求項３６】
前記ワークフロー承認プロセッサは、金融機関において実装される請求項３１に記載のシステム。
【請求項３７】
前記ワークフロー承認プロセッサは、サードパーティにアウトソーシングされる請求項３１に記載のシステム。
【請求項３８】
前記ワークフロー承認プロセッサは、前記複数の審査担当者の中の少なくとも１人から承認を受領し、前記調整文書を使用して前記購入者から受領した前記支払を処理し、前記購入者から受領した前記支払を登録する請求項３１に記載のシステム。
【請求項３９】
前記ワークフロー承認プロセッサは、前記複数の審査担当者の中の少なくとも１つから拒絶を受領し、前記調整文書を集金部門に回す請求項３１に記載のシステム。
【請求項４０】
調整文書を自動的に生成する方法において、
購入者から支払情報を受領する段階と、
販売者から請求書情報を受領する段階と、
前記支払情報と前記請求書情報を比較する段階と、
前記支払情報が前記請求書情報と異なっている場合に、調整文書を自動的に生成する段階と、を含み、
前記比較段階は、ＡＳＰ（Application Service Provider）によって実行される方法。
【請求項４１】
調整文書を自動的に生成する方法において、
購入者から支払情報を受領する段階と、
販売者から請求書情報を受領する段階と、
前記支払情報と前記請求書情報を比較する段階と、
前記支払情報が前記請求書情報と異なっている場合に、調整文書を自動的に生成する段階と、を含み、
前記比較段階は、金融機関にインストールされたソフトウェアパッケージによって実行される方法。
【請求項４２】
調整文書を審査担当者に自動的に回付する方法において、
ワークフロー承認プロセッサにおいて電子的な調整文書を受領する段階であって、前記調整文書は、購入者から受領した支払に基づいている段階と、
前記調整文書用の回付ワークフローを判定する段階であって、前記回付ワークフローは、前記調整文書内の情報に応じて可変である段階と、
前記回付ワークフローに基づいて、前記ワークフロー承認プロセッサから複数の審査担当者の中の少なくとも１つに前記調整文書を自動的に回付する段階と、を含み、
前記回付段階は、金融機関にインストールされたソフトウェアパッケージによって実行される方法。
【請求項４３】
調整文書を審査担当者に自動的に回付する方法において、
ワークフロー承認プロセッサにおいて電子的な調整文書を受信する段階であって、前記調整文書は、購入者から受領した支払に基づいている段階と、
前記調整文書用の回付ワークフローを判定する段階であって、前記回付ワークフローは、前記調整文書内の情報に応じて可変である段階と、
前記回付ワークフローに基づいて、前記ワークフロー承認プロセッサから複数の審査担当者の中の少なくとも１人に前記調整文書を自動的に回付する段階と、を含み、
前記回付段階は、サードパーティにアウトソーシングされたソフトウェアパッケージによって実行される方法。
【請求項４４】
購入者からの支払を処理する方法において、
販売者から請求書情報を受領する段階であって、前記請求書情報は、前記販売者から前記購入者に請求された少なくとも１つの未払いの請求書を表している段階と、
前記購入者から支払情報を受領する段階と、
前記支払情報を前記請求書情報と電子的に比較し、前記支払情報が前記未払いの請求書の中の少なくとも１つとマッチングできるか否かに関する自動的な判定を実行する段階と、
前記自動的な判定によって前記支払情報を前記未払いの請求書の中の少なくとも１つにマッチングできない場合に、前記支払情報を前記販売者の審査担当者に伝送する段階と、を含む方法。
【請求項４５】
前記ユーザーの前記審査担当者が前記支払情報を前記未払いの請求書の中の少なくとも１つとマッチングさせることができるようにする段階を更に有する請求項４４に記載の方法。
【請求項４６】
前記支払情報の前記支払金額が、前記少なくとも１つの未払いの請求書の中の１つに含まれている支払金額とマッチングしないため、前記自動的な判定によって前記支払情報を前記未払いの請求書の中の少なくとも１つにマッチングさせることができない請求項４５に記載の方法。
【請求項４７】
前記支払情報の前記支払金額は、データ入力の誤りに起因し、前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【請求項４８】
前記支払情報が前記未払いの請求書の中の複数のものの支払金額を含んでおり、且つ、前記複数の未払いの請求書の中のいずれが含まれているのかを前記支払情報が示していないため、前記支払情報の前記支払金額が前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【請求項４９】
前記支払情報の前記支払金額が、まだ存在していない請求書の前払いを表しているため、前記支払情報の前記支払金額が前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【請求項５０】
前記支払情報の前記支払金額が、既に支払われている請求書の支払を表しているため、前記支払情報の前記支払金額が前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【請求項５１】
前記請求書に控除または調整が適用されるため、前記支払情報の前記支払金額が前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【請求項５２】
前記販売者は、第１の販売者であり、前記支払情報の前記支払金額が、前記第１の販売者とは異なる第２の販売者に対する支払を表しているため、前記支払情報の前記支払金額が前記少なくとも１つの未払いの請求書の中の１つの前記支払金額とマッチングしない請求項４６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般に、販売者から送付された請求書に関連して、購入者が要求する調整などの例外を管理するシステムおよび方法に関するものである。更に詳しくは、本出願は、購入者が要求する控除や購入者に対する与信などの例外を処理し、販売者側のトランザクションを処理し、トランザクションを完結させ、且つ、販売者の会計システムを更新する販売者支援自動システムおよび方法を提供する。
【背景技術】
【０００２】
図１は、従来技術による商品購入の代表的なトランザクション１００を示している。図１に示されているように、このトランザクションには、購入者１１０、販売者１３０、および金融機関１２０が関与している。通常、購入者１１０は、購入要求書１０２または購入注文書を販売者に対して送付する。購買要求書１０２は、購入者１１０が所望する商品を特定している。販売者１３０は、購入者の購入注文書を受領した後、その商品を購入者１１０に対して出荷する。
【０００３】
商品と共に（または、これとは別途に）、販売者１３０は、明細書または請求書１０５を送付できる。請求書１０５は、通常、出荷された商品を記載しており、価格、数量、販売者コードまたはＳＫＵ番号等の特定情報などの情報、及び/又はその他の注文情報を包含できる。あるいは、この代わりに、同一の購入者に対して複数の出荷が行われる場合には、１つの出荷用の１枚の請求書の代わりに、複数の出荷を反映した明細書を利用することもできる。
【０００４】
販売者の商品と請求書１０５とを受領すると、購入者１１０は、この時点、またはこの時点の後で、商品に対する支払を行わなければならない。現在、多くの場合に、購入者は、現金、小切手、クレジットカード、自動決済機関（ACH：Automated Clearing House）、またはその他の電子／電信送金を含む様々な方法のいずれかを使用して、商品に対する支払を実行している。支払の方法とは無関係に、購入者の支払及び/又は情報が、送金情報１１５として金融機関１２０に送付される。場合によっては、支払及び/又は情報は、まず、販売者１３０に送付され、次いで、販売者が、これを金融機関１２０に伝達する場合もある。
【０００５】
金融機関１２０は、購入者の支払および送金情報１１５を受領し、金融機関１２０の販売者の口座内に資金を預金する。次いで、金融機関１２０は、支払データ１２５を販売者１３０に送付することにより、支払を受領したことを販売者１３０に対して通知する。
【０００６】
支払データ１２５は、月次、週次、あるいは、通常は、日次の口座取引要約書の形態であってよい。最も好ましい設定においては、口座取引要約書は、毎日、数回更新される。また、支払データは、販売者１３０に対して電子的に送付することも可能であり、あるいは、金融機関の記録に販売者が電子的にアクセスできるようにすることで販売者１３０に情報提供することも可能であり、あるいは、写しを販売者１３０にメイルすることも可能である。
【０００７】
又、前述のように、購入者の支払は、様々な方法のいずれかによって受領できる。但し、受領する支払のタイプとは無関係に、支払は、通常、金融機関によって電子的表現に変換される。例えば、金融機関が受領した紙の小切手は、読み取りまたは画像化可能であり、金融機関１２０のデータ入力要員が、小切手の表面上の支払データを電子的表現に変換することもできる。自動決済機関（以降、ＡＣＨと略記）または電信送金は、すでに電子的な形態になっているので、そのトランザクションの金融機関のレコードに、例えば、ＡＣＨのオリジネータやＡＣＨの日付を反映させることもできる。通常、支払データ１２５として、銀行の電子データの大部分が販売者１３０に対して送信される。
【０００８】
支払データ１２５を受領すると、販売者１３０は、それぞれの受領した支払を対応する請求書にマッチングさせるという困難な作業を開始しなければならない。即ち、購入者１１０が、出荷された商品に対する支払を行ったことを確認するべく、販売者１３０は、金融機関１２０から受領した支払データ１２５を、購入者１１０に送付した請求書１０５のデータとマッチングさせる。そして、この販売者１３０による請求書１０５のデータと支払データ１２５のマッチング作業が完了し、請求書１０５のデータが支払データと正確にマッチングした場合に、トランザクションが完結したと言える。多数の請求書を有する販売者の場合には、このプロセスに長時間を要することになる。
【０００９】
又、支払データ１２５が請求書１０５のデータと正しくマッチングする時点まで、すなわちトランザクションが完結する時点まで、販売者１３０は、購入者１１０から正しく支払を受領しているか否かを判断することができない。購入者１１０は、例えば、支払超過状態または支払不足状態となっている可能性がある。従って、トランザクションが完結する時点まで、販売者１３０は、金融機関１２０の販売者の口座に反映されている通貨の残高が利用可能な現金を表しているのか否か、あるいは、例えば、支払超過のために、いくらかの金額を購入者１１０に返金する必要があるのか否かについて確信することができない。
【００１０】
予測されるように、請求書情報に対する支払データのマッチング作業には、特に、販売者１３０が多数の購入者１１０に対して商品を出荷している場合には、極めて長時間を要することになる。また、受領した支払データ１２５が請求書１０５のデータとマッチングしないことがあるため、請求書情報に対する支払データのマッチング作業は更に複雑化する可能性がある。
【００１１】
即ち、購入者が請求された金額とは異なる支払を実行する可能性がある。購入者によって実行された支払が、請求された金額を下回っている（または、上回っている）場合がある。例えば、購入者によって実行される支払は、例えば、商品のいくつかが受領されていなかったり、損傷している場合など、購入者の支払が商品のすべてに対するものでない場合は、請求金額を下回っている場合がある。又、購入者の支払は、商品の価格または品質、あるいは、購入者が受領した割引に対する意見の相違に起因し、請求金額を下回っている場合もある。これとは逆に、購入者が実行する支払は、印刷の誤りや請求作業の矛盾などの購入者の誤りに起因し（あるいは、購入者が前払いや過払いを行った場合に）、請求金額を上回る可能性がある。
【００１２】
購入者から受領した支払が販売者の請求書とマッチングしない場合には、通常、請求書に対する調整（adjustment）が行われる。調整の結果、請求金額が低減される場合には、調整を控除（deduction）として言及される（これは、チャージバックまたは紛争（dispute）として知られている）。通常、調整を要求するのは顧客である。この調整の要求は、一般に、調整要求と呼ばれている。控除は、必ずしも、販売者の特定の請求書に言及する必要はないが、調整要求は、通常、請求書金額の控除という形態を取っている。例えば、損傷した商品を顧客が受領した場合には、各顧客は、商品の損傷を反映した請求書金額の低減を要求し、従って、請求書金額の控除という形態の調整要求を請求する。また、販売者の請求書が最初から誤っていた場合にも、購入者の支払が販売者の請求書とマッチングしないことになる。あるいは、この代わりに、例えば、購入者に固有の割引などの調整が購入者の請求書に対して適用される場合もある。
【００１３】
調整要求は、様々な形態があり得る。例えば、調整要求は、調整を要求する購入者から販売者に対する電話による通話であってもよい。あるいは、調整要求は、顧客から販売者に対する手紙や電子メールであってもよい。更には、調整要求は、調整の理由を概説する借方伝票を伴った請求書金額（または、合意した値引）を下回る支払であってもよい。あるいは、この代わりに、調整要求は、ウェブサイトからの電子データなどの電子的な通信の形態であってもよい。
【００１４】
販売者が調整要求を受領すると、調整要求は、通常、審査のために担当者に伝達される。審査担当者とは、調整要求を承認または拒絶するべく、調整要求および関係文書を審査する人物である。特定の顧客による調整の実行を許容するために、複数の審査担当者の同意が必要であってよい。すべての審査担当者がその調整要求を審査し、すべての関係文書を審査し終わった段階で、調整要求は承認または拒絶される。
【００１５】
調整要求を承認した場合には、販売者は、顧客に対してクレジットを発行する。購入者に対する再請求作業は、通常、顧客に対するクレジットの発行と同一の効果を販売者の会計システムに対して具備している。逆にいえば、顧客が請求書金額の控除という形態の調整を要求し、販売者がこの調整要求を承認した場合には、販売者は、貸方伝票により請求書金額を低減し、当初請求書金額より低い購入者の支払を受け入れる。
【００１６】
前述のように、調整要求を受領した場合には、販売者は、その調整要求を監視し解決しなければならない。通常、販売者は、調整要求および関係文書を手作業によって収集する。関係文書には、通常、請求書、支払情報、および配送情報が含まれる。支払情報とは、商品に対する支払を確認するなんらかの文書である。例えば、支払情報には、顧客からの小切手、顧客から販売者に対する電子的な資金の送金、あるいは、貸方勘定に対する貸し登録の文書が含まれる。配送情報とは、商品の配送を確認するなんらかの文書である。例えば、配送情報は、配送証明書であってよい。
【００１７】
調整要求およびすべての関係文書の収集を完了すると、販売者は、調整要求と関係する文書を１人または複数の審査担当者に送付する。実際には、調整要求の収集と正しい審査担当者に対する調整要求の回付は、困難であって時間を所要する。古いシステムを使用している販売者の場合には、通常、調整要求を支援する文書を、調整パッケージとして手作業で収集しなければならない。又、調整パッケージは、審査担当者間を移動する際に、１つに纏まっていなければならない。この結果、調整パッケージの回付が遅延することになり、且つ、関係文書の一部またはすべてが消失してしまう可能性を有している。
【００１８】
最近のシステムの場合には、通常、少なくとも一部が電子的な形態になっている調整パッケージの文書を伴っている。例えば、審査担当者は、自分のデスクにおいて、電子在庫システムから運送証券を取得することができる。しかしながら、文書の大部分は、通常、依然として紙の形態になっている。又、１つまたは複数の文書アイテムが電子的な形態になっている場合にも、これらの文書アイテムは、通常、相互通信状態にはない異なるシステム上に存在している。
【００１９】
また、調整パッケージ内の文書アイテムが電子的な形態で入手可能な場合であっても、現在の商習慣は、通常、特に複数の審査担当者を必要としている場合は、重複した作業になっている。例えば、第１の審査担当者は、調整パッケージの紙の部分を受領し、第１アプリケーションにログインして文書の第１の電子アイテムを取得し、第２アプリケーションにログインして文書の第２の電子アイテムを取得する等の作業により、最終的に調整を承認することになる。次いで、この調整パッケージが、第２の審査担当者に送付され、第２の審査担当者は、通常、第１の審査担当者が実行したプロセスをそのまま重複実行するか、あるいは、第１の審査担当者によって作成された調整文書の写しを審査することになるのである。
【００２０】
図２は、商品を販売するトランザクションを処理する代表的なワークフロー２００を示している。まず、段階２１０において、販売側２０１が購入側２０２に対して請求書を送付する。次に、段階２２０において、購入者は、まず請求書を審査する。段階２３０において、例えば、調整を実行することにより、紛争（dispute）を処理する。尚、段階２３０においては、紛争ないし調整は審査され、購入者によって承認される。後述するように、かつ、図２に示されているように、紛争および調整プロセスは、販売者にとって極めて時間と労働力を必要とすることになる。最後に、段階２４０において、支払が購入者から販売者に実行される。
【００２１】
段階２４０において、購入者から受領した支払は、しばしば、販売者において、手作業で請求書に対してマッチングされるが、これには、極めて時間を要することに留意されたい。いくつかのデータが電子的に提供されている場合でも、購入者の支払システムは、通常、相当量の人間とのやり取りを伴うこと無しに、受領したデータを処理するようにはなっていない。又、段階２３０における調整または紛争プロセスは、購入者と販売者の両方にとって労働集約的であり、且つ、長期間にわたるものである。
【００２２】
従って、調整を解決する現在のシステムは、いくつかの理由から、費用がかかり過ぎている。第１に、監視対象の情報が多数存在している。この情報には、顧客情報、請求書情報、調整要求の原因（即ち、控除または支払超過による返金が要求されているか否か）、顧客の過去の請求書、顧客からの過去の調整要求、および販売者におけるその顧客の与信限度が含まれており、且つ、その他の情報を含むこともある。
【００２３】
第２に、大規模な事業体においては、しばしば、販売者内の関係するすべての部門（例えば、会計部門、出荷部門、および与信部門など）が、調整要求を審査、編集、および承認または拒絶することを実行することを保証するのは不可能である。販売者内の関係するすべての部門が、調整要求を審査することを保証できないという事実は、前述のように、調整要求と関係文書とを結びつける作業が手作業であることに起因している。例えば、調整要求の適切な審査のために必要な文書のすべてを審査担当者が受領できなければ、誤りが頻発することは明らかである。
【００２４】
関係する第３の問題点として、特に複数の部門が関与している場合に、販売者内のすべての関係している部門に各々の審査をタイムリーに実行させることが非常に困難である。例えば、第１の審査担当者が調整要求の審査に必要なすべての文書を受領するところで遅延した場合には、更なる遅延が後続の審査担当者に発生することになる。このようにして、別の審査担当者が、第１の審査担当者による調整文書および関係文書の審査の完了を待つケースにおいては、調整要求の処理が継続して遅延することになる。この遅延は、販売者が複数レベルの審査を必要としている場合（即ち、第１の審査担当者による調整要求の解決を待った後に、別の審査担当者が審査することを要する場合）には、更に大きな問題となる。例えば、販売者が、審査担当者の管理者に対して、調整要求のすべての初期審査を行うことを要求している場合、１人または複数の審査担当者への情報の回付（または、担当者からの決断結果の受領）が遅延することにより、更なる遅延が発生することになる。
【００２５】
最後に、すべての関係部門による調整要求の審査が遅延すると、顧客に対する売掛の回収の実行または顧客に対する返金が更に遅延することになる。この結果、長期間にわたる回収の遅延に起因するビジネス上の損失と顧客の信用の損失が発生する可能性がある。また、現在のシステムおよび方法は、調整管理システムおよび方法と販売者の銀行間における一体化を提供していない。
【発明の開示】
【発明が解決しようとする課題】
【００２６】
従って、現在のシステムに関連する問題点の多くを除去または極小化する販売調整管理ソリューションに対するニーズが、従来から存在している。例えば、関係するすべての文書を確実に収集して審査担当者に供給することにより、高度な調整管理の自動化を提供するシステムに対するニーズが特に存在している。また、関係する審査担当者に対する未解決の調整の回付を簡略化し、良好な回付と調整プロセスの文書化を提供し、且つ、販売者の金融機関と直接一体化されているシステムに対するニーズが長期間にわたって存在している。また、販売者の金融機関とのより高度な一体化を提供する調整管理システムに対するニーズも長期間にわたって存在している。
【課題を解決するための手段】
【００２７】
本発明の実施例は、購入者から受領した支払に対する調整の処理を自動化するシステムおよび方法を提供する。即ち、購入者が販売者に対して支払を行うが、この購入者による支払が販売者の請求書とマッチングしていない。この結果、購入者の支払に対する調整が必要となる。支払処理および例外管理アプリケーションは、購入者の支払情報を受領し、販売者が入手できるデータから、購入者に関する固有の注文データを取得する。支払処理および例外管理アプリケーションは、支払データおよび注文データに基づいて調整文書を自動的に生成する調整文書生成器を含んでいる。調整文書は、異なる調整に使用可能ないくつかの利用可能な調整文書の中の１つであってよい。次いで、調整文書は、ワークフロー承認プロセッサに伝達される。次いで、ワークフロー承認プロセッサは、調整文書を１人または複数の審査担当者に回付する。この審査担当者の組は、購入者に固有のものであってよく、あるいは、購入者から受領した支払データ内の情報、または、購入者から受領した支払データと購入者の未解決の請求書などの購入者に固有の注文データ内の情報との比較に基づいて判定することもできる。又、支払および調整管理アプリケーションは、好ましくは、販売者の金融機関と一体化される。
【発明を実施するための最良の形態】
【００２８】
図３は、本発明の一実施例による自動支払処理および例外管理システム３００を示している。支払処理および例外管理システム３００は、購入者３１０、金融機関３２０、販売者３３０、調整処理アプリケーション３４０、および支払および調整管理アプリケーション３５０を含んでいる。支払および調整管理アプリケーション３５０は、金融機関３２０と調整処理アプリケーション３４０を含んでいる。
【００２９】
更に後述するように、購買要求書３０２は、購入者３１０から販売者３３０に送付される。請求書情報３０５は、販売者３３０から購入者３１０に送付される。請求書情報３０５は、販売者３３０から提供される商品及び/又はサービスとは別個に送付可能であり、あるいは、商品及び/又はサービスと一緒に送付することもできる。支払情報３１５は、購入者３１０から販売者の金融機関３２０に対して送付される。支払および送金データ３２５は、金融機関３２０から調整処理アプリケーション３４０に送付される。注文データ３３５は、販売者から調整処理アプリケーション３４０に送付される。注文データ３３５は、基礎となっている商品について購入者に対して請求する際に、調整処理アプリケーション３４０に送付することができ、あるいは、その後の時点において調整処理アプリケーション３４０に送付することもできる。登録データ３４５は、調整処理アプリケーション３４０から販売者３３０に対して送付される。
【００３０】
支払処理および例外管理システム３００は、動作の際には、おおむね、次のように動作する。まず、購入者３１０が、例えば、販売者３３０からの商品の購入を決定する。通常、次いで、購入者３１０は、購買要求書３０２を販売者３３０に送付することにより、購入者３１０が購入を希望していることを販売者３３０に通知する。この結果、販売者３３０は、購入者の購買要求書３０２を受領する。次いで、販売者３３０は、所望の商品を購入者３１０に対して出荷し、請求書情報３０５を購入者３１０に送付する。
【００３１】
請求書情報３０５は、好ましくは、販売者３３０から購入者３１０に出荷された商品に関係する情報を含んでいる。例えば、請求書情報３０５は、好ましくは、出荷された商品を特定する販売者のコード、価格、数量、及び/又はその他の注文情報を含んでいる。
【００３２】
前述のように、購入者３１０は、請求書情報３０５および商品を受領する。次いで、購入者３１０は、受領した商品を審査する。次いで、購入者３１０は、好ましくは、受領した商品に対する支払を実行する。しかしながら、様々な理由から、購入者の支払金額は、販売者３３０が請求した支払金額とは異なることになる。
【００３３】
例えば、受領した商品が請求書情報３０５内に特定されている商品とマッチングしない場合には、購入者の支払は、請求書と異なることになる。また、例えば、商品の中のいくつかが、損傷または破壊されていることもある。あるいは、この代わりに、受領した実際の商品について合意した価格または数量が、請求書情報内に記載されている商品の価格または数量とマッチングしていないこともある。更には、購入者が所望している商品とは異なる商品を販売者が出荷している場合もある。尚、これらは、請求書情報３０５からの逸脱を結果的にもたらすことになる商品の出荷の際に遭遇し得る多数の問題点の中のいくつかの例に過ぎない。
【００３４】
図３を再度参照すれば、商品を受領すると、購入者３１０は、支払情報３１５を金融機関３２０に伝送することにより、商品に対する支払を実行する。即ち、購入者３１０は、支払を含む支払情報３１５を販売者の金融機関３２０に対して提出する。尚、いくつかのケースにおいては、購入者３１０は、販売者３００に対して支払を直接実行することも可能であり、この場合には、販売者が支払を金融機関３２０に対して提出する。但し、本実施例は、図３に示されているように、金融機関３２０と調整処理アプリケーション３４０とを一体化することにより、金融機関３２０を支払および調整管理アプリケーション３５０に変換するべく機能している。
【００３５】
即ち、購入者３１０は、商品を受領すると（または、添付された請求書の条件に従って）、商品に対する支払を実行する。しかしながら、商品に伴う前述の問題点の中の１つまたは複数のものが発生すると、購入者が支払として提出する金額が、請求書情報３０５内に含まれている金額とは異なることになる。購入者３１０が提出した支払金額が請求書情報３０５内に含まれている支払金額と異なっており、且つ、下回っている場合には、この支払金額の差を控除（deduction）と呼ぶ。
【００３６】
前述の背景技術のところで述べたように、購入者３１０が通常の方式で控除を取得する場合は、控除の取得に販売者の大量の作業が必要となる。通常、販売者は、購入者から受領した支払金額を購入者に送付した商品および請求書情報とマッチングさせなければならず、これは、複雑で時間を要するプロセスとなる。
【００３７】
前述のシステムの中のいくつかにおいては、請求書情報とのマッチングに所要する時間量を低減し、購入者が控除を取得できるように、販売者は、購入者に手作業またはウェブサイトを通じて借方伝票を提出することを要求できる。このような方法を使用して控除を管理することにより、内部の会計処理において販売者を支援することはできるが、販売者による承認と購入者に対する支払または与信のさらなる遅延が必然的に伴うことになる。この結果、多くの場合に、購入者および販売者は、このようなシステムを面倒なものと見ている。その他の従来のシステムにおいては、購入者は、請求書が正確でない限り（即ち、すべての調整を示す最終的な修正済みの請求書を購入者が受領済みであるか、誤った請求書を相殺するべく貸方伝票が発行済みであるか、あるいは、控除が支払の前に認可されていない限り）、その請求書の支払を拒否できる。しかしながら、このようなシステムは、通常、支払のさらなる遅延を伴うため、通常、販売者は、望ましいものではないと見なしている。
【００３８】
逆に、図３に示されているように、購入者３１０は、支払を含む支払情報３１５を販売者の金融機関３２０に対して提出する。しかしながら、図３に示されているように、本実施例は、金融機関３２０を調整処理アプリケーション３４０と一体化することにより、金融機関３２０を支払および調整管理アプリケーション３５０に変換するべく動作する。
【００３９】
即ち、購入者の送金および支払情報３１５は、金融機関３２０に対して送付されている。支払情報３１５は、例えば、現金や小切手からＥＤＩ（Electronic Data Interchange）などの電子的な資金の送金にいたる様々な形態のいずれかであってよい。金融機関３２０は、送金および支払情報３１５を受領し、支払および送金データ３２５を生成する。支払および送金データ３２５は、好ましくは、支払および送金情報のすべてを含んでおり、受領した小切手、受領した送金通知書、及び/又は借方伝票の読み取り画像などのさらなる送金データを含むこともできる。次いで、支払および送金データ３２５は、調整処理アプリケーション３４０に送信される。
【００４０】
調整処理アプリケーション３４０は、支払および送金データ３２５に加え、販売者３３０からの注文データ３３５をも受領する。注文データ３３５は、好ましくは、請求書に関係する情報、購入者に関係する情報、および販売者に関係する情報という３つのタイプの情報を含んでおり、さらなる情報を含むこともできる。
【００４１】
請求書に関係する情報に関連し、注文データ３３５は、好ましくは、購入者３１０に送付された請求書情報３０５内に含まれているすべての情報を含んでおり、運送証券または請求書情報３０５の電子画像などの商品の運搬に関係する情報を含むこともできる。
【００４２】
即ち、支払および送金データ３２５の中の１つの要素は、好ましくは、支払を行う購入者を特定している。好ましくは、未解決の請求書は、例えば、請求書を元々購入者に送付した時点で調整処理アプリケーション３４０に対して事前送付または事前配送されている。調整処理アプリケーション３４０が、特定の販売者の特定の請求書を検出できない場合には、調整処理アプリケーション３４０は、後述するように、標準的な控除様式を既定のものとして使用することができる。あるいは、この代わりに、調整処理アプリケーション３４０は、販売者３３０に問い合わせることにより、注文データ３３５として通知された購入者のすべての未解決の請求書のリストを受領することもできる。支払データ３２５内に購入者が示されていない場合には、調整処理アプリケーション３４０は、好ましくは、すべての購入者のすべての未解決の請求書を検索することができる。即ち、支払および送金データ３２５が、好ましくは、購入者を特定している。次いで、調整処理アプリケーション３４０は、購入者に関する任意の情報について販売者３３０に問い合わせることができる。又、調整処理アプリケーション３４０は、様々な方法の中の任意のものによって販売者３３０からデータを取得することができる。例えば、調整処理アプリケーション３４０は、１人の購入者の１枚の請求書の情報とは対照的に、１人または複数の購入者の複数枚の請求書を表す情報を、一括処理用（以降、一括処理をバッチと表記）として、注文データ３３５を受領することができる。また、購入者３１０から受領する支払情報３１５は、１枚の請求書の代わりに、複数枚の請求書からなるバッチ用で表すこともできる。
【００４３】
購入者に関係する情報と関連し、注文データ３３５は、好ましくは、後述するように、例えば、この購入者による以前の注文の数、交渉の結果その購入者に適用された割引、またはその他のインセンティブなどの購入者自身に関係する情報をも含んでいる。
【００４４】
販売者に関係する情報に関連し、注文データ３３５は、後述するように、例えば、その注文を受注した販売員や調整承認用の内部回付情報などの販売者に関する情報を包含できる。
【００４５】
調整処理アプリケーション３４０は、支払および送金データ３２５と注文データ３３５を受領すると、受領した支払および送金データ３２５を、注文データ３３５から受領した未解決の請求書の中の１つまたは複数のものにマッチングする試みを実行する。
【００４６】
図６に関連して後述するように、支払データ３２５が１つまたは複数の請求書に即座にマッチングできる場合には、調整処理アプリケーション３４０は、マッチング成功の通知を登録データ３４５として販売者３３０に送付する。登録データ３４５は、好ましくは、支払データによって支払われている１つまたは複数の請求書を示している。販売者３３０は、登録データ３４５を受領し、次いで、そのトランザクションを完結させるべく、１つまたは複数の請求書が支払われたことを反映するように販売者３３０の会計システムのレコードを更新する。尚、この説明においては、請求書ごとの調整処理アプリケーション３４０の動作に焦点を合わせているが、調整処理アプリケーションは、バッチベースで動作することもできる。例えば、請求書のバッチを一度に処理できる。後述するように、すべての請求書がマッチングされると共に／または、請求書に対するすべての例外が処理された後に、一括して請求書のバッチを一度に販売者に送信できる。例えば、調整処理アプリケーション３４０は、請求書のバッチを処理し、マッチングできる請求書をマッチングし、次いで、後述するように、請求書のバッチ全体を販売者に通過させる前に、残りの請求書内の例外の分類に集中することもできる。次いで、販売者の審査担当者が、例外を更に審査、変更、及び/又は承認／拒絶できる。
【００４７】
支払データ３２５が、１つまたは複数の請求書と即座にマッチングしない場合には、販売者が調整を要求しているか、または誤りが発生している可能性があり、この場合には、調整処理アプリケーション３４０は、図６に関連して後述するように、さらなる処理のために支払データに対してフラグを付加することができる。
【００４８】
次いで、調整処理アプリケーション３４０は、後述するように、調整を自動的に解決および処理するべく試みるために、販売者による設定が可能なビジネス規則の組を支払データに対して適用するべく試行することができる。例えば、特定の閾値を下回るまたは請求書金額の特定の割合を下回る調整が自動的に許可されるように、各々の購入者用規則のセットを用いて調整処理アプリケーション３４０を設定できる。
【００４９】
処理アプリケーション３４０は、調整を自動的に解決できない場合には、調整様式を生成できる。次いで、図４〜図２０に関連して後述するように、販売者によって設定された理由コードを使用して調整様式を分類した後に、解決のために関係する要員に対して回付できる。調整様式は、好ましくは、調整を解決（承認または反証）するために必要なすべてのデータを含んでいる。
【００５０】
初期の請求書および支払マッチング動作については、ｘｘｘｘ付けで出願された「System And Method For Automated Incoming Payment and Invoice Reconciliation」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に更に記述されており、この内容は、本引用により、そのすべてが本明細書に包含される。又、自動調整処理動作については、ＸＸＸＸ付けで出願された「System And method For Automated Payment And Adjustment Processing」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に更に記述されており、この内容は、本引用により、そのすべてが本明細書に包含される。
【００５１】
調整処理アプリケーション３４０が支払および送金データ３２５および注文データ３３５を処理して購入者の調整が解決されたら、調整処理アプリケーション３４０は、登録データ３４５を販売者３３０に対して送信する。後述するように、登録データ３４５は、貸方伝票を生成するための指示、在庫に対する調整、または控除を集金部門に回すための指示などのいくつかの形態の中のいずれかであってよい。
【００５２】
前述のように、請求書情報３０５は、いくつかの形態のいずれかを取ることができる。例えば、請求書情報３０５は、紙の文書であるか、あるいは、電子メール、ウェブ対応様式、またはその他のＥＤＩ情報交換などの電子的な文書であってもよい。
【００５３】
尚、以上においては、購入者による商品の注文に関連し、本実施例について説明しているが、この代わりに、購入者がサービスの入手に関心を持つこともできる。調整管理に関連し、サービスを入手するという環境においても同様に考えることができる。この説明においては、商品に合焦しているが、本支払処理および例外管理システムは、同様にサービスに対しても適用され、商品に限定されるものではない。
【００５４】
前述のように、請求書情報は、後述するように大量の情報を包含できる。しかしながら、以下に一覧表示する情報アイテムのすべてが請求書情報内に存在している必要はない。請求書情報の一部として包含するアイテムは、販売者が設定できる。例えば、請求書情報は、販売者３３０から購入者３１０に販売された商品及び/又はサービスの数量および価格に関する情報を包含できる。請求書情報３０５は、出荷日、購入者３１０の名前および住所、販売者３１０の名前および住所、購入者３１０から販売者３３０に対する支払期限を超過した貨幣の金額、または販売者３３０において購入者３１０が具備している利用可能な与信などの情報を包含することもできる。更には、請求書情報３０５は、特定および追跡のために販売者３３０が使用する請求書番号を含むこともできる。例えば、請求書情報３０５は、購入者３１０に配送または提供された商品及び/又はサービスを販売者３３０が追跡できるように請求書番号を包含できる。更には、請求書情報３０５は、運送証券、並びに／あるいは、運賃請求書、配送証明書、及び/又は価格見積などのその他の文書を含むこともできる。
【００５５】
前述の請求書情報と同様に、支払情報は、多数の形態の中から購入者が選択したいずれかの形態を取ることができる。従って、例えば、支払情報３１５は、小切手、金融機関の為替手形、銀行小切手、送金為替、与信限度に借方登録する命令、約束手形、または受領した商品及び/又はサービスに対する支払を示すその他の文書を含むことができる。また、支払情報３１５は、支払の形態の電子画像を含むこともできる。例えば、支払情報３１５は、商品及び/又はサービスに対する支払に使用される小切手の電子画像を包含できる。
【００５６】
前述の説明に加え、好ましくは、支払データ及び/又は送金情報が電子的な形態で購入者から提供されていない場合には、金融機関３２０が支払および送金データを作成する。即ち、金融機関３２０は、例えば、小切手などの到来した支払情報を審査し、次いで、小切手に関係するデータの組を生成できる。例えば、金融機関３２０は、受領日、金額、支払人、被支払人、および任意の口座、ＭＩＣＲ、または請求書番号を小切手の上に電子的に書き留めることができる。金融機関は、受領した小切手、送金情報、および借方伝票を電子的に画像化することもできる。次いで、金融機関３２０によって施されたこの記録を支払および送金データ３２５の一部として調整管理アプリケーションに伝達できる。
【００５７】
あるいは、この代わりに、支払情報が金融機関３２０に対して電子的に配送されている場合には、支払情報は、様々な形態のいずれかを取ることができる。金融機関３２０は、通常、受領した支払情報を処理し、金融機関の内部的な処理基準に合致したものになるように、支払情報を再表現または再フォーマットする。次いで、この再処理済みの電子的に受領した支払情報を支払および送金データの一部として調整処理アプリケーション３４０に対して伝達できる。
【００５８】
支払および送金データ自体は、金融機関３２０が選択する様々な形態のいずれかを取ることができる。例えば、支払および送金データ３２５は、この代わりに、ＸＭＬ文書、ＥＤＩ文書、インターネットベースの金融サービスからの情報、あるいは、商品またはサービスの支払に関係する電子的データのその他の形態から構成できる。
【００５９】
注文データ３３５および登録データ３４５も、例えば、電子メール、ＸＭＬ文書、ＨＴＭＬ文書、またはＥＤＩなどの様々な形態のいずれかを取ることができる。
【００６０】
また、調整処理アプリケーション３４０は、例えば、パッケージソフトウェアアプリケーションとして実装可能であり、あるいは、ＡＳＰ（Application Service Provider）として金融機関またはその他のサードパーティにインストールすることもできる。ＡＳＰとしては、調整処理アプリケーション３４０を金融機関３２０、販売者３３０、またはサードパーティによって直接ホスティングできる。調整処理アプリケーション３４０が、金融機関３２０および販売者３３０と通信状態に維持されている限り、その実際の物理的な場所は関係ない。例えば、調整処理アプリケーション３４０は、金融機関においてホスティングまたはインストールされるか、サードパーティにインストールされるか、または、その他の方法でアウトソーシングすることもできる。
【００６１】
図４は、図３の調整処理アプリケーション３４０の一実施例を詳細に示している。図４に示されているように、調整処理アプリケーション３４０は、ビジネスデータフィルタ４１０、調整文書生成器４２０、およびワークフロー承認プロセッサ４３０を含んでいる。図３に関連して前述したように、調整処理アプリケーション３４０は、金融機関３２０から支払および送金データ３２５を、そして、販売者３３０から注文データ３３５を受領する。次いで、支払および送金データ３２５および注文データ３３５は、調整処理アプリケーション３４０のビジネスデータフィルタ４１０に引き継がれる。
【００６２】
ビジネスデータフィルタ４１０は、注文データ３３５と支払および送金データ３２５とを受領し、動作の際には、支払および送金データ３２５と注文データ内に含まれている１つまたは複数の請求書とをマッチングさせるべく試みる。ビジネスデータフィルタ４１０が、支払および送金データ３２５を注文データ３３５内の１つまたは複数の請求書にマッチングさせることができた場合には、ビジネスデータフィルタは、前述のように、登録データ３４５を販売者３３０に送付してトランザクションを完結させる。ビジネスデータフィルタ４１０が、支払および送金データ３２５を注文データ３３５内の１つまたは複数の請求書にマッチングさせることができない場合には、支払および送金データ３２５は、図６と関連して後述するように、ビジネスデータフィルタによって更に処理されることになる。
【００６３】
次いで、ビジネスデータフィルタ４１０は、図６と関連して後述するように、注文データ３３５と支払および送金データ３２５をマッチングさせるように試みるべく、一連のビジネス規則を適用する。ビジネス規則の適用後に、ビジネスデータフィルタ４１０がマッチングを検出できた場合には、ビジネスデータフィルタ４１０は、登録データ３４５を販売者３３０に送信する。ビジネスデータフィルタによって適用されるビジネス規則は、好ましくは、後述するように、購入者に固有のものとなるように設定できる。
【００６４】
しかしながら、購入者に固有のビジネス規則の適用後にも、ビジネスデータフィルタ４１０が、依然として、支払データを１つまたは複数の請求書とマッチングさせることができない場合には、ビジネスデータフィルタ４１０は、支払および送金データ３２５を調整文書生成器に対して送付する。この結果、調整文書生成器４２０において、調整文書４２５が生成される。又、調整文書生成器４２０は、支払が実行されており、調整文書が生成されていることを販売者の会計システムに対して通知するべく、登録データ３４５を販売者３３０に送付する。
【００６５】
生成された調整文書４２５は、ワークフロー承認プロセッサ４３０に送付される。ワークフロー承認プロセッサ４３０は、審査及び/又は承認のために、調整文書４２５を販売者３３０の既定のカスタマイズ可能な審査担当者の組に回付する。調整承認様式の構造と承認様式の回付については、図８〜図２０と関連して後述する。調整文書が審査担当者の組によって承認された場合には、ワークフロー承認プロセッサは、さらなる登録データを販売者３３０に送付する。一方、調整文書が審査担当者の組によって承認されなかった場合には、販売者３３０は、この代わりに、さらなるアクションのために、調整文書を集金に回すことができる。
【００６６】
図７と関連して後述するように、調整文書４２５は、好ましくは、支払データ並びに購入者に関係するすべての関連データを含んでいる。購入者と関係する関連データは、好ましくは、信用の格付けを含む購入者の以前の購入および支払活動、並びに、購入者を担当している販売者の担当窓口または購入者に付与された以前の割引などの購入者に関係する販売者側の情報を含んでいる。
【００６７】
ビジネスデータフィルタ４１０は、購入者の情報がトランザクションから消失している場合に、支払データを検証するように要求することもできる。例えば、支払データが購入者の標識を含んでいない場合には、ビジネスデータフィルタ４１０は、全購入者の未解決のすべての請求書に対して、支払金額またはその他の利用可能な情報にマッチングさせるべく、試行することができる。マッチングが検出された場合には、ビジネスデータフィルタ４１０は、例えば、請求書以外の特定のフィールドなどの二次的な基準により、試行したマッチングを確認できるように、ユーザーに対して自動的に要求することができる。
【００６８】
好ましくは、ビジネス規則によって提供されるトランザクションの検証は、トランザクションの下記の面からの検証を含む
（１）購入者３１０の顧客情報に関する検証
（２）購入者に運搬された商品の配送情報、好ましくは、例えば、積み荷の請求書及び／又は運送証券を含む配送情報、さらにドル金額を含む配送情報に関する検証
（３）購入者の支払が既に受領した支払の重複であるか否か、または、合計金額で既定の閾値の許容値より下回る金額で、購入者から送金されてきた金額が請求金額と異なっているか否か、あるいは、合計請求書金額が既定の金額を下回っているか否かのような判定をするための購入者の支払に関する検証
【００６９】
図５は、支払データ３２５内に包含可能な情報源のタイプのいくつかの例を示している。前述のように、支払データ３２５は、ＸＭＬ文書５１０、ＥＤＩ文書５２０、電子データ５４０、及び/又はウェブサービスからのデータ５３０から導出されたデータを包含できる。電子データ５４０は、図３に示されているように、支払情報３１５の電子画像やその他の情報を含むことができる。支払データ及び送金データ３２５は、調整処理アプリケーション３４０により解析が可能である金融機関が所望する内部フォーマットに設定できる。
【００７０】
従って、本実施例は、支払データと請求書データとを自動的にマッチングさせるべく機能する。前述のように、支払データと請求書データとをマッチングさせるための従来技術による方法は、大量の手作業を伴っており、極めて低速である。本実施例によれば、到来する大部分の支払を自動的にマッチングおよび処理できる。従って、作業量と費用が低減され、利用可能な現金を相対的に正確に査定できる。又、支払データを請求書データとマッチングさせる従来技術による方法においては、マッチングを販売者の金融機関と自動的に一体化してはいない。
【００７１】
図６は、調整管理アプリケーションの動作のフローチャート６００を更に詳しく示している。まず、段階６０１〜６０２において、支払データおよび注文データを受領する。次に、段階６０５において、金融機関が支払データを受信し、顧客ごとに集計する。即ち、金融機関は、１つの預金内にいくつかの支払を蓄積し、バッチを形成できる。次いで、販売者の要員が、金融機関のレコードにアクセスし、支払のバッチを全体として処理できる。あるいは、この代わりに、バッチではなく、支払を個別に処理することもできる。
【００７２】
段階６１０において、支払のバッチ内のそれぞれの支払を評価する。好ましくは、支払データ６０１は、購入者によって実行された支払を販売者から購入者に送付された特定の請求書番号とリンクさせる請求書情報を含んでいる。好ましくは、注文データ６０２の一部として、請求書番号のリストが販売者から検索される。段階６１５において、注文データによって提供された請求書番号とマッチングする請求書番号を支払が含んでいるか否かを判定する。マッチングする請求書番号が検出された場合には、処理は、段階６３０に進み、請求書を支払にマッチングさせる。請求書番号のマッチングが検出されない場合には、処理は、段階６２０に進む。
【００７３】
販売者が支払データを購入者の未解決の請求書の中の１つまたは複数のものに適用できるようにするべく、段階６２０において、いくつかの選択肢を販売者に対して提示する。尚、フローチャート６００においては、上部が傾斜したボックス内に配置されている処理段階は、システム内において自動的に実行されるアクションとは対照的に、販売者が実行するアクションを示している。段階６２０において、販売者は、支払データが請求書番号とマッチングしなかった理由に対応するいくつかのアクションの中の１つを実行できる。まず、支払データは、請求書番号の誤りなどの誤りを含んでいるために、請求書とマッチングしなかった可能性がある。この場合には、段階６２５において、データを訂正することにより、支払データ内の請求書番号を未解決の請求書番号の中の１つとマッチングさせることができる。次いで、プロセスは、段階６３０に進むことができる。あるいは、この代わりに、段階６２６において、支払データを複数の請求書間において分割することも可能であり、次いで、プロセスは、段階６３０に進むことができる。あるいは、この代わりに、段階６２７において、購入者から受領した支払が前払いであると販売者が判定した場合には、プロセスは段階６６０に進むことになる。
【００７４】
段階６３０においては、受領した支払は、特定の請求書に対するマッチングが完了する。次に、段階６３２において、請求書内に含まれている請求している支払金額と受領している支払とを比較する。受領している支払が請求している支払とマッチングした場合には、プロセスは段階６３５に進む。段階６３５において、販売者の会計システムに登録のために、支払をマーキングする。
【００７５】
逆に、受領した支払が請求されている支払とマッチングしない場合には、プロセスは、段階６４０に進む。段階６４０においては、支払金額が請求している金額と正確にマッチングしない場合でも、支払が請求書と「マッチング」していると認めるビジネス規則を提供している。例えば、受領した支払が請求されている支払金額と異なっている場合でも、その差が十分に小さい場合には、請求書と支払がマッチングしていると見なすように、本システムに対してグローバルな閾値を設定できる。例えば、グローバルな閾値として、受領した支払が１％未満または１００ドル未満だけ請求書金額と異なっている場合には、請求書と支払をマッチングしているものと見なすことができる。グローバルな閾値は、好ましくは、販売者によって設定される。
【００７６】
すべての購入者に対して適用可能なグローバルなビジネス規則以外に、購入者に固有のビジネス規則を適用することもできる。受領した支払と請求書がマッチングできるようにするべく、グローバルな閾値の代わりに、例えば、グローバルな閾値よりも寛容な購入者に固有の閾値を利用できる。例えば、販売者は、２％または５００ドルの購入者に固有の閾値を設定可能であり、この結果、受領した支払が、購入者に固有の閾値を上回るだけ、請求済みの金額から異なっていない限り、支払は、請求書とマッチングしていると見なされることになる。又、割引支払条件やその他のインセンティブなどのその他の購入者に固有の基準を適用することもできる。
【００７７】
グローバルおよび購入者に固有の閾値を含むビジネス規則は、段階６０２において、注文データの一部として販売者から取得できる。あるいは、この代わりに、ビジネス規則は、プロセスが段階６４０に進む際に、販売者から取得することもできる。別の代替例として、ビジネス規則は、調整管理アプリケーション内に保存することも可能であり、定期的な更新のために販売者に提供できる。ビジネス規則は、いずれも、好ましくは、販売者によって設定できる。
【００７８】
次に、段階６４２を参照すれば、ビジネス規則の適用後に、支払金額が請求された金額とマッチングしている場合には、プロセスは、段階６５０に進む。段階６５０において、請求書の支払と受領した支払間の差を貸方登録するべく、Ｇ／Ｌ（総勘定元帳）調整レコードを生成する。次いで、本プロセスは、段階６３５に進み、登録のために支払をマーキングする。登録のための支払のマーキングが完了したら、段階６９０において、登録データを販売者に送信する。
【００７９】
一方、段階６４２におけるビジネス規則の適用後に、支払金額が請求済みの金額とマッチングしない場合には、本プロセスは、段階６４３に進む。段階６４３において、支払金額をチェックし、受領した支払が部分的な支払を表しているか否かを判定する。受領した支払が部分的な支払を表している場合には、本プロセスは、段階６５５に進み、Ａ／Ｒに対する調整を実行する。次いで、本プロセスは、段階６３５に進み、登録のために支払をマーキングする。
【００８０】
逆に、受領した支払が部分的な支払を表していない場合には、本プロセスは、段階６６０に進み、控除様式などの調整様式を生成する。調整様式の生成および処理については、図２２において更に説明する。次いで、本プロセスは、段階６５５に進み、Ａ／Ｒに対する調整を実行する。次いで、本プロセスは、段階６３５に進み、前述のように、登録のために支払をマーキングする。
【００８１】
図２２は、調整様式を処理するための手順の一実施例のフローチャート２２００を示している。図６と同様に、フローチャート２２００においては、上部が傾斜したボックス内に配置されたプロセス段階は、本システム内において自動的に実行されるアクションとは対照的に、販売者が実行するアクションを示している。まず、段階２２０１において、控除様式などの調整様式を生成する。調整様式のいくつかの例が、後続の図９〜図１９に示されている。後述するように、購入者が所望する特定の調整に基づいて、いくつかの異なるタイプの調整様式が提供される。調整様式を生成する際には、調整様式には、好ましくは、調整と関係し得るすべての利用可能なデータが入力される。例えば、調整様式は、好ましくは、受領した支払に関係している支払データ、並びに、特定の購入者に関係している注文データおよび請求書を含んでいる。
【００８２】
段階２２０１を再度参照すれば、調整または控除様式を生成したら、販売者が設定したワークフロー２２０５に従って、控除様式を回付する。例えば、特定の調整は、販売者の審査担当者の１つの組に回付可能であり、別の調整は、販売者の別の審査担当者の組に回付できる。例えば、調整は、調整の大きさ、調整を取得する購入者、及び/又は特定の購入者の未解決の合計調整金額、並びに、図２０と関連して後述するその他の要因に基づいて回付できる。
【００８３】
調整様式は、段階２２１０において、審査担当者によって受領並びに評価される。次いで、本プロセスは、段階２２１５に進む。段階２２１５において、審査担当者は、注釈または説明書を控除様式に付加できる。次いで、段階２２２０において、審査担当者は、さらなる関係文書が必要であるか否かを判定できる。さらなる関係文書が必要である場合には、本プロセスは、段階２２２５に進み、関係文書を付加する。関係文書を付加した後に（または、文書が不要な場合には）、本プロセスは段階２２３０に進む。
【００８４】
段階２２０３において、さらなる審査が必要であるか否かを判定する。さらなる審査が必要であるか否かの判定は、自動化することも可能であり、あるいは、審査担当者が進めることもできる。例えば、審査担当者は、さらなる審査の必要性を判定し、審査のために控除文書を別の審査担当者に回付するべく選択できる。この場合には、本プロセスは、段階２２０５に戻り、控除様式が新しい審査担当者に回付されることになる。
【００８５】
又、本プロセスは、さらなる審査担当者が必要であるか否かを自動的に判定することもできる。例えば、特定の控除文書の承認用のワークフローは、その控除文書が複数の審査担当者を通過しなければならないことを通知できる。この場合には、第１の審査担当者がその審査を完了した後に、控除文書は、審査のために次の審査担当者に自動的に回付され、本プロセスは、段階２２０５に戻る。調整様式は、図２０と関連して後述するように、逐次的にまたは並行的に回付できる。
【００８６】
審査担当者は、控除様式に関連して３つの選択肢の中の１つを選択できる。即ち、控除様式は、完全承認、部分的承認、および承認拒否ができる。まず、段階２２４０において、本プロセスは、控除が部分的に承認されたか否かを判定する。控除が部分的に承認されている場合には、段階２２５０において、承認された控除金額について、調整レコードを生成する。次いで、段階２２６０において、控除が部分的に承認されていることおよび承認の金額について通知するデータを販売者に伝送する。又、段階２２５０においては、控除様式の承認されていない部分を集金部門に回す。
【００８７】
控除が部分的に承認されていない場合には、本プロセスは、段階２２４５に進む。段階２２４５において、本プロセスは、控除が完全に承認されているか、または完全に拒絶されているかを判定する。控除が拒絶されている場合には、本プロセスは、段階２２５０に進み、控除は、さらなるアクションのために集金部門に回される。控除が完全に承認されている場合には、本プロセスは、前述のように、段階２２５０に進み、控除のために調整文書が生成され、段階２２６０において、販売者に送付される。
【００８８】
図７は、購入者固有の情報の一例を示している。この情報は、調整文書生成器によって、調整文書を生成および回付できるようにするべく、調整文書生成器が受領することができる。調整文書生成器４２０は、好ましくは、調整文書４２５を生成するべく、顧客情報７１０、ワークフロー参加者リスト７２０、適用可能な販売情報７３０、および調整情報７４０を受領する。
【００８９】
図示のように、調整文書生成器４２０は、様々な情報源７１０〜７４０からいくつかの情報アイテムを収集、編成、および再フォーマットすることによって調整文書４２５を生成する。例えば、顧客情報７１０は、購入者３１０の名前、ビジネス、およびコンタクト情報を含む購入者３１０に関する情報を包含できる。調整情報７４０は、販売者３３０または金融機関３２０が購入者３１０の名前で保有可能な借金や貸金に関するデータまたは情報を含んでいる。
【００９０】
ワークフロー参加者リスト７２０は、後述するように、調整文書４２５の審査を必要とし得る様々な審査担当者のリストである。ワークフロー参加者リスト７２０は、好ましくは、調整文書のワークフローを販売者の内部ビジネス／買掛勘定構造にマッチングさせるべく販売者３３０によって高度にカスタマイズされている。
【００９１】
この結果、販売者３３０は、適切な審査担当者が確実に調整文書４２５を審査するように、ワークフロー参加者リスト７２０をカスタマイズできる。例えば、与信限度において購入者に商品を販売した販売者３３０は、与信分析者が調整文書４２５を審査することを所望する可能性が高い。更に複雑な例においては、販売者３３０は、与信部門、会計部門、業務部門、担当窓口、ＣＦＯ（Chief Financial Officer）、販売部門、及び/又は輸送部門を含むいくつかの審査担当者が調整文書４２５を審査することを所望する可能性がある。従って、販売者３３０は、ワークフロー参加者リスト７２０をカスタマイズすることにより、これらの審査担当者のすべてが確実に調整文書４２５を受領するようにすることができる。ワークフロー設定のさらなる例には、顧客ごと、理由コードごと、およびドル金額ごとのものが含まれる。
【００９２】
又、調整文書４２５は、審査担当者に対して同時にまたは逐次的に送付できる。即ち、一実施例においては、調整文書４２５は、一度に１人の審査担当者の手に渡り、一度に１人の審査担当者のみが販売文書を検討する。調整文書は、以前の審査担当者が文書の処理を完了した際にのみ、次の審査担当者の手に渡ることになる。例えば、調整文書は、電子メールにより、審査担当者間を逐次的に移動できる。
【００９３】
別の実施例においては、指定された審査担当者全員が、同時に調整文書４２５に対してアクセス可能である。例えば、ウェブページなどの中央の集中箇所において、調整文書４２５をアクセスできる。それぞれの審査担当者が文書を審査する際には、審査担当者は、ウェブサイト上において施した変更やアクションを通知することができる。
【００９４】
次に、適用可能な販売情報リポジトリ７３０から調整文書生成器４２０に供給される情報を参照すれば、適用可能な販売情報７３０は、好ましくは、図８に関連して後述するように、請求書、販売注文、運送証券、購入注文書、購入者３１０の小切手を含む支払データ３２５からのすべての適用可能な情報を含んでいる。しかしながら、調整文書４２５のタイプに応じて、適用可能な販売情報７３０は、更に多くの、または、少ない情報から構成することもできる。例えば、商品が販売者３３０から購入者３１０に配送されなかった場合には、適用可能な販売情報７３０内に含まれる運送証券が存在している可能性は低い。従って、適用可能な販売情報７３０（並びに、相応して、調整文書４２５）は運送証券を含んでいないであろう。
【００９５】
従って、調整文書生成器は、好ましくは、後述するように、実行される実際の調整に応じて、調整文書のいくつかの異なるタイプを生成する。生成対象の特定のタイプの調整文書に応じて、様々なデータベースから異なるタイプおよび量の情報が調整文書内に収容される。
【００９６】
図８は、調整文書４２５内に収容できる様々な模範的な文書およびその他のアイテムを示している。図８に示されているように、調整文書４２５は、運賃請求書８１０、小切手８２０、請求書８３０、種々の関係文書８４０、配送証明書８５０、顧客見積８６０、および運送証券８７０からの情報、または、スキャニングによるこれらの複写を含むことができる。運賃請求書８１０は、購入者３１０が購入した商品の配送に使用した運賃請求書の電子画像であってよい。小切手８２０は、商品に対する購入者３１０の支払いの電子画像であってよい。小切手８２０は、小切手、金融機関の為替手形、銀行小切手、為替、与信限度に貸し登録する命令、手形、または受領した商品及び/又はサービスに対する支払を示すその他の文書の電子画像を含む支払の任意の証拠であってよい。請求書８３０は、購入者３１０に対する商品の販売において使用された請求書の電子画像であってよい。その他の関係文書８４０は、販売者３３０から購入者３１０に対する商品の販売および運送に使用された任意の文書の電子データまたは画像を包含できる。これには、販売者３３０または購入者３１０のいずれかからの書簡が含まれる。配送証明書８５０は、商品が購入者３１０に配送されたことを証明する任意の文書の電子画像であってよい。顧客見積８６０は、購入者３１０に対する商品及び/又はサービスの販売ための販売者３３０による見積を含む任意の文書の電子画像またはその他の電子表現であってよい。運送証券８７０は、購入者３１０に対する商品の配送の際に使用された運送証券の電子画像であってよい。
【００９７】
様々な情報アイテムは、いずれも、文書の電子的なコピー対するリンク、文書の読み取られた写しに対するリンク、または任意のその他のタイプの文書アウトソーシングを含む様々な方法のいずれかにおいて提供できる。
【００９８】
前述のように、図８は、調整文書内に収容可能な文書の模範的なものに過ぎない。さらなる文書または示されている全文書の一部を利用することもできる。
【００９９】
図７を再度参照すれば、前述のように、調整文書生成器は、好ましくは、発生する実際の調整に応じて、いくつかの異なるタイプの調整文書を生成する。図９〜図１９は、いくつかの異なる状況において利用可能ないくつかの模範的な調整文書を示している。前述のように、図９〜図１９の模範的な調整文書のそれぞれに含まれている情報は、販売者が設定可能であり、文書自体も販売者が設定可能であってよい。
【０１００】
又、調整文書生成器は、１人または複数の審査担当者が使用する初期調整文書を判定できるが、審査担当者は、調整文書生成器の選択内容を無効にし、異なる調整様式を使用するべく選択することもできる。初期判定は、ベンダ順守マニュアルに含まれている控除コードまたは理由コードなどの購入者から供給されるデータに基づいたものであってよく、あるいは、単に販売者によって設定された既定の設定内容であってもよい。すべての情報及び/又は読み取られた画像は、調整文書のそれぞれから、その他の調整文書のいずれのものにも直接転送できる。
【０１０１】
前述のように、本システムは、好ましくは、様々な選択肢を使用して販売者から提供される理由コードを評価することにより、調整のタイプを認識する。又、例えば、販売者が既定のコードを指定することにより、既定の調整を通知の問題とすることもできる。あるいは、この代わりに、調整様式の生成時点において販売者がすべての調整を個別にコーディングする必要があるように、本システムを構成することもできる。
【０１０２】
図９は、調整文書４２５の模範的な顧客順守様式９００タイプを示している。顧客順守様式９００は、タイトル９１０、作成者情報９１５、審査担当者情報９２０、顧客情報９２５、販売員情報および与信分析者情報９３０、トランザクション情報９３５、調整チャート９４０、Ｇ／Ｌコード９４５、影響が及ぶ在庫レコードインジケータ９５０、ＣＭ支払条件９５５、不順守理由インジケータ９６０、さらなる添付品に対するハイパーリンク９６５、調整ノート９７０、調整ノートの履歴９７５、およびワークフロープロセッサの監査証跡として利用可能なそれぞれの審査担当者の状態インジケータ９８０を含んでいる。
【０１０３】
タイトル９１０は、購入者３１０の名前、調整様式のタイプインジケータ、理由コード、状態インジケータ、調整番号、紛争フラグ、および最新アクションの日付などの情報を含んでいる。状態インジケータとは、例えば、「未解決（unresolved）」、「解決済み（resolved）」、「集金済み（collected）」、または「未集金（not collected）」の標識である。状態インジケータを使用し、調整要求の現在の状態を示している。この結果、調整要求がまだ解決されていない場合には、調整文書４２５は、「未解決」という状態インジケータを具備できる。逆に、調整が解決されている場合には、調整文書４２５は、「解決済み」という状態インジケータを具備できる。又、購入者３１０が販売者３３０に対して支払義務を負っている資金の回収が完了している場合には、調整文書４２５は、「集金済み」という状態インジケータを具備できる。逆に、購入者３１０が販売者３３０に対して支払義務を負っている資金がまだ回収されていない場合には、調整文書４２５は、「未集金」という状態インジケータを具備できる。さらなる状態インジケータには、審査担当者が控除を部分的に承認している場合の「部分承認済み（partially approved）」と、控除様式は生成済みであるが、控除がまだ解決されていない場合の「保留中（opened）」と、が含まれる。
【０１０４】
調整文書４２５の顧客順守様式例９００のタイトルの調整番号は、調整文書４２５を識別するために使用する番号である。例えば、購入者３１０は、販売者３３０との間で現在未解決のいくつかの調整要求を具備できる。販売者３３０が未解決の調整要求のすべてを十分に監視できるように、未解決の調整要求は、いずれもが、別個の調整文書４２５内に記載され、別個の調整番号によって特定される。あるいは、この代わりに、複数の調整要求を単一の調整文書４２５内に収容することもできる。
【０１０５】
調整文書４２５の顧客順守様式例９００のタイトルの理由コードは、調整要求の原因のインジケータである。この結果、１つの文字または番号、あるいは、いくつかの番号及び/又は文字の組み合わせを使用し、調整要求の原因を迅速に特定できる。例えば、販売者３３０は、次の理由コードを具備できる。
【０１０６】
【表１】
2007507800.tif 000003
【０１０７】
又、調整文書が解決されているか否かに関する標識として紛争フラグを使用できる。紛争フラグが「オン」状態にあれば、調整に関する決定がまだ下されていないことを意味している。紛争フラグが「オフ」状態にあれば、決定が既に下されていることを意味している（決定とは、その調整の承認または拒絶を意味している）。
【０１０８】
調整文書４２５の顧客順守様式例９００のタイトルの最新アクションの日付は、その調整要求に最後に手を加えた日付である。例えば、調整要求に対して施された最後のアクションが、審査担当者が４月１５日に調整文書４２５を再分類することであった場合には、最新アクションの日付として、施された最新のアクション（即ち、調整文書４２５の再分類）と日付（即ち、４月１５日）を表示できる。
【０１０９】
調整文書４２５の顧客順守様式例９００の作成者情報は、調整要求を作成した関係者に関連する情報である。例えば、与信分析者が調整要求を作成した場合には、与信分析者に関する情報を作成者情報として記載できる。
【０１１０】
調整文書４２５の顧客順守様式例９００の審査担当者情報は、調整文書４２５を審査した審査担当者に関係する情報である。例えば、与信分析者が調整文書４２５を審査した場合には、与信分析者に関する情報を審査担当者情報として記載できる。
【０１１１】
調整文書４２５の顧客順守様式例９００の顧客情報は、購入者３１０に関係する情報である。調整文書４２５の顧客順守様式例９００の販売員情報は、商品及び/又はサービスを購入者３１０に対して販売した販売員に関係する情報である。調整文書４２５の顧客順守様式例９００の与信分析者情報は、ワークフローに応じて、調整文書４２５を既に審査したまたはまだ審査していない与信分析者に関係する情報である。
【０１１２】
トランザクション情報９３５は、参照番号（図中、Reference #）、請求書番号（図中、Invoice #）、注文番号（図中、Order）、借方日付（図中、Debit Date）、小切手特定情報（図中、Check ID）、請求書合計（図中、Invoice Total）、控除または支払金額（図中、Ded/Payment）、合計割合金額（図中、Total %）、および電子画像に対するいくつかのハイパーリンクを含んでいる。後続の図面における販売調整様式のいくつかの実施例においては、トランザクション情報の様々な構成が利用されている。又、トランザクション情報セクションは、動的に拡張可能なものになるように構成することもできる。例えば、審査担当者は、調整要求を次の審査担当者に伝達する前に、トランザクション情報セクションに対してさらなる情報を追加することを所望することができる。従って、トランザクション情報９３５を拡張し、例えば、生産、価格、または数量などの単位品目請求書情報やその他の所望の情報を収容することができる。
【０１１３】
調整文書４２５の顧客順守様式例９００の参照番号は、調整要求を特定するのに使用する番号である。この結果、１人の購入者３１０がいくつかの未解決の調整要求を具備している場合にも、それぞれの調整要求を容易に特定し監視することができる。例えば、購入者３１０は、販売者３３０との間に現在未解決のいくつかの調整要求を具備できる。あるいは、この代わりに、それぞれの独立した調整要求に対して異なる参照番号を割り当てることにより、調整要求を容易に特定することもできる。
【０１１４】
調整文書４２５の顧客順守様式例９００の請求書番号は、図３において前述した請求書情報３０５を識別するのに使用する番号である。
【０１１５】
調整文書４２５の顧客順守様式例９００の注文番号は、商品及び/又はサービスの注文を特定するべく使用する番号である。例えば、販売者３３０は、注文番号によって購入者３１０に対する販売を追跡できる。この結果、販売者３３０は、顧客順守様式例９００内の注文番号により、この注文を参照できる。又、好ましくは、それぞれの請求書番号は、単一の注文番号と付随しており、請求書番号が特定されることにより、このフィールドが必然的に入力されることになる。
【０１１６】
調整文書４２５の顧客順守様式例９００の借方日付とは、販売者３３０から購入者３１０に販売された商品及び/又はサービスについて借方登録された日付である。
【０１１７】
文書４２５の顧客順守様式例９００の小切手特定情報は、販売者３３０から商品及び/又はサービスを購入する際に購入者３１０が使用した小切手または電子支払番号を特定するのに使用する番号である。即ち、小切手特定情報は、通常、金融機関の参照符号である。
【０１１８】
調整文書４２５の顧客順守様式例９００の請求書合計とは、請求書情報３０５内に記載されている購入者３１０が支払わなければならない金額である。例えば、購入者３１０が請求書内に記載されている商品に対して５００ドルを支払う義務があると請求書情報３０５に示されている場合には、請求書合計は、５００ドルである。
【０１１９】
調整文書４２５の顧客順守様式例９００の控除または支払金額は、購入者３１０が調整を要求している金額である。従って、購入者３１０が、請求書金額を控除すべきであると主張している金額、あるいは、購入者３１０が、自分で過払いしたと主張している金額が、控除または支払金額である。
【０１２０】
調整文書４２５の顧客順守様式例９００の合計割合金額は、控除または支払金額の請求書合計に対する割合である。例えば、控除または支払金額が１００ドルであり、請求書合計が５００ドルである場合には、合計割合金額は２０％である。
【０１２１】
調整文書４２５の顧客順守様式例９００の電子画像に対するいくつかのハイパーリンクとは、様々な関係文書の画像に対する電子的なハイパーリンクである。例えば、電子画像に対するいくつかのハイパーリンクは、購入者３１０の小切手の電子画像に対する電子的なリンクを包含できる。又、電子画像に対するいくつかのハイパーリンクは、請求書の電子画像または送金情報に関する購入者のウェブサイトに対する電子的なリンクを含むこともできる。
【０１２２】
調整文書４２５の顧客順守様式例９００の調整チャートは、合計調整、承認済みの調整、拒絶済みの調整、小切手番号、バッチ番号、および借方伝票番号を含むチャートである。合計調整とは、調整要求において要求されている調整の合計金額である。例えば、購入者３１０が、請求書金額における３００ドルの控除を要求している場合には、合計調整は３００ドルである。承認済みの調整とは、控除管理アプリケーション３４０内において審査担当者が承認した調整の金額である。拒絶済みの調整とは、控除管理アプリケーション３４０内において審査担当者が拒絶した調整の金額である。小切手番号とは、調整が行われる購入者３１０の小切手の番号である。バッチ番号とは、支払受領日を特定するために販売者３３０が使用する番号である。
【０１２３】
借方伝票番号は、その特定の控除または調整に割り当てられている番号である。即ち、販売者が、借方伝票の写しについて購入者にコンタクトする際には、販売者は、この借方伝票の番号を参照することによって写しを要求することになる。
【０１２４】
調整文書４２５の顧客順守様式例９００のＧＬアルファコード（図中、G/L Alpha Code）は、総勘定元帳コードである。総勘定元帳コードは、販売者３３０によってカスタマイズされたコードである。Ｇ／Ｌコードは、貸方伝票（未解決の承認）を生成するための資金がどこから到来するかを表している。Ｇ／Ｌコードは、増数額である。Ｇ／Ｌコードは、アルファと指定する必要はない。又、Ｇ／Ｌコードは、アルファベット特定情報、数字特定情報、またはアルファベットおよび数字特定情報の組み合わせであってよい。
【０１２５】
調整文書４２５の顧客順守様式例９００の影響が及ぶ在庫レコード（Inventory Records Affected）インジケータは、調整要求が販売者３３０の在庫に対して及ぼし得る影響の標識である。従って、調整要求により、販売者３３０の在庫が１０００単位だけ増大する場合には、影響が及ぶ在庫レコードインジケータは、１０００単位の値を具備できる。又、調整要求が販売者３３０の在庫に対してなんの影響をも及ぼさない場合には、影響が及ぶ在庫レコードインジケータは、販売者３３０の在庫にはなんの変化もないことを示す「非在庫（Non Inventory）」という値を具備できる。
【０１２６】
調整文書４２５の顧客順守様式例９００のＣＭ支払条件は、請求書金額の完全な支払が購入者３１０から行われることを要する時点までの時間の総計である。例えば、ＣＭ支払条件が６０日であれば、購入者３１０は、６０日以内に請求書金額の完全な支払を実行しなければならない。あるいは、この代わりに、調整様式の生成が完了しているため、請求書の完全な支払の条件が、もはや適切なものではない場合もあろう。
【０１２７】
調整文書４２５の顧客順守様式例９００の不順守理由インジケータは、購入者３１０が調整要求を要求している理由の標識である。このインジケータは、好ましくは、顧客によって設定可能であり、審査担当者が急いで調整できるように動的なものであってもよい。例えば、商品が遅れために、購入者３１０がトランザクションの調整を要求している場合には、販売者３３０は、「出荷遅延」という不順守理由インジケータを生成できる。不順守とは、好ましくは、販売者が、例えば、出荷、バーコーディング、包装、またはその他の要件などの購入者の要件を満足しなかった状況を意味している。あるいは、この代わりに、不順守理由インジケータは、調整要求の様々な原因を示すべく、可変の英数字コードとして表すこともできる。
【０１２８】
調整文書４２５の顧客順守様式例９００のさらなる添付品に対するハイパーリンクとは、関係文書の任意の電子画像に対する電子的なハイパーリンクである。例えば、電子画像に対するいくつかのハイパーリンクが、購入者３１０の小切手、請求書、および運送証券の電子画像に対するハイパーリンクを含んでいるが、顧客見積の電子画像に対するハイパーリンクを含んでいない場合には、このさらなる添付品に対するハイパーリンクが、顧客見積の電子的画像に対するハイパーリンクを包含できる。あるいは、この代わりに、このさらなる添付品を使用することにより、ハイパーリンクを介しては提供不可能な読み取られた文書を付加することもできる。又、このフィールドによれば、その他のシステムからデータを複写し、ここに貼り付けることもできる。これらのハイパーリンクは、ユーザーを任意の所望のタイプの情報に導くように設定できる。
【０１２９】
調整文書４２５の顧客順守様式例９００の調整ノートは、調整文書４２５に対する注釈である。これにより、販売者３３０は、調整文書４２５が表している控除を処理する際に、販売レコードに対して注釈を付加できる。又、調整ノートによれば、販売者３３０は、電子メールやその他の情報からの引用などの関係文書を調整文書４２５内に挿入することもできる。
【０１３０】
調整ノートの履歴とは、過去の調整ノートの集合体である。従って、販売者３３０が調整文書４２５内に調整ノートを入力するごとに、過去のメモが、このメモの履歴内に保存されることになる。
【０１３１】
調整文書４２５の顧客順守様式例９００のそれぞれの審査担当者用の状態インジケータは、それぞれの審査担当者による調整要求の解決の標識である。従って、調整文書４２５を審査し、調整文書４２５を承認または拒絶するすべての審査担当者は、この状態インジケータ内に各担当者の承認を包含できる。例えば、与信分析者が調整文書４２５を審査し、調整文書４２５を承認した場合には、与信分析者用の状態インジケータは「承認済み」と表示できる。逆に、別の審査担当者が調整文書４２５を拒絶した場合には、各担当者の状態インジケータは「拒絶済み」と表示できる。又、審査担当者が調整文書４２５をまだ審査していない場合には、各担当者の状態インジケータは、「未解決」と表示できる。更には、審査担当者を変更する選択肢を追加することもできる。例えば、ワークフローに応じて、特定の控除の場合には、与信分析者が審査担当者になれない場合があってもよい。
【０１３２】
図１０は、調整文書４２５の損傷様式の例１０００を示している。調整文書４２５の損傷様式例１０００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、損傷様式例１０００は、タイトル１０１０、作成者情報１０１５、審査担当者情報１０２０、顧客情報１０２５、販売員情報および与信分析者情報１０３０、トランザクション情報１０３５、マルチトランザクションチャート１０３７、調整チャート１０４０、影響が及ぶ在庫レコードインジケータ１０５０、ＣＭ支払条件１０５５、さらなる添付品に対するハイパーリンク１０６５、調整ノート１０７０、調整ノートの履歴１０７５、およびそれぞれの審査担当者用の状態インジケータ１０８０を含んでいる。
【０１３３】
損傷様式１０００においては、トランザクション情報１０３５、マルチトランザクションチャート１０３７、および、さらなる添付品１０６５を除いて、すべての要素が図９の様式９００に類似している。
【０１３４】
トランザクション情報１０３５は、参照番号（図中、Reference #）、請求書番号（図中、Invoice #）、請求書日付（図中、Date）、注文番号（図中、Order）、注文合計（図中、Total）、請求書条件（図中、Terms）、購入注文書番号（図中、P.O）、出荷日付（図中、Ship Date）、製品特定情報、単価、請求済みおよび支払済みの数量を含む第１の製品特定領域、製品特定情報、単価、請求済みおよび支払済みの数量を含む第２の製品特定領域、控除金額、合計割合金額、電子画像に対するいくつかのハイパーリンクを含んでいる。トランザクション情報は、損傷していると購入者によって記録された実際のアイテムと、例えば、オリジナルの購入注文書や出荷日付などの出荷の際に損傷したアイテムの出荷に関係するその他の情報を追跡するべく使用できる。又、図１０に示されているように、損傷に関連して、複数の製品を個々に記述することもできる。尚、図１０の様式１０００においては、２つの製品のみが個々に記述されているが、様式１０００は、任意の数の製品を示すようにカスタマイズできる。
【０１３５】
又、好ましくは、参照符号１０３５の各フィールドは、入力できるように、常に表示状態となっている。但し、損傷した製品が１つの特定の請求書／注文を参照していない場合には、これらのフィールドは空白のままに残される。しばしば、損傷した製品の大半が購入者の在庫から直接取得されたものであり、それらが関係している特定の請求書／注文を判定する方法が存在しない場合がある。この場合には、入力済みの様式は、好ましくは、製品、単価、および数量を含んでいる。図９の様式と関連して前述したように、好ましくは、トランザクション情報１０３５は、動的にユーザーが容易に構成できる。
【０１３６】
損傷チャート１０３７は、最大で１０個の別個の損傷商品クレームに関する調整のリストを含んでいる。尚、図１０の例は、最大で１０個のクレームを含んでいるが、図１０の様式は、任意の数のクレームを含むように、ユーザーが容易に拡張できる。チャートは、要求された控除の金額（図中、Amount）、要求された控除のＧＬコード（図中、GL code）、および年（図中、Year）を含んでいる。本様式１０００において求められている控除の金額は、チャートの第１列に示されている。
【０１３７】
様式１０００のさらなる添付品セクション１０６５は、顧客見積セクションを含むように補完されている。
【０１３８】
図１１は、調整文書４２５の割引様式の例１１００を示している。調整文書４２５の割引様式例１１００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、割引様式例１１００は、タイトル１１１０、作成者情報１１１５、審査担当者情報１１２０、顧客情報１１２５、販売員情報および与信分析者情報１１３０、トランザクション情報１１３５、調整チャート１１４０、Ｇ／Ｌアルファコード１１４５、影響が及ぶ在庫レコードインジケータ１１５０、ＣＭ支払条件１１５５、さらなる添付品に対するハイパーリンク１１６５、調整ノート１１７０、調整ノートの履歴１１７５、およびそれぞれの審査担当者用の状態インジケータ１１８０を含んでいる。
【０１３９】
割引様式１１００においては、トランザクション情報１１３５およびさらなる添付品１１６５を除いて、すべての要素が図９の様式９００に類似している。図９と関連して前述したように、さらなる添付品１１６５は、ユーザーによって自由に構成できる。
【０１４０】
トランザクション情報１１３５は、参照番号（図中、Reference #）、請求書番号（図中、Inv.#）、請求書日付（図中、Date）、注文番号（図中、Order）、注文合計（図中、Total）、請求書条件（図中、Terms）、購入注文書番号（図中、P.O）、控除金額（図中、Ded.）、合計割合金額（図中、Total %）、および電子画像に対するいくつかのハイパーリンクを含んでいる。トランザクション情報１１３５は、注文のオリジナルの条件において付与された割引を示しており、オリジナルの割引を控除として請求された金額に対してマッチングさせている。次いで、審査担当者が割引を承認できる。又、セクション１１３５内の１０個のフィールドは、１つの調整に対する複数の割引用に使用できる。
【０１４１】
さらなる添付品１１６５は、価格承認に対するリンクを含んでいる。好ましくは、割引を認可する前に、販売員は、割引を認可するための承認を管理者から受領している。このような書面による価格承認を読み取って様式１１００内に包含できる。
【０１４２】
図１２は、調整文書４２５の運賃様式の例１２００を示している。調整文書４２５の運賃様式例１２００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、運賃様式例１２００は、タイトル１２１０、作成者情報１２１５、審査担当者情報１２２０、顧客情報１２２５、販売員情報および与信分析者情報１２３０、トランザクション情報１２３５、調整チャート１２４０、Ｇ／Ｌアルファコード１２４５、影響が及ぶ在庫レコードインジケータ１２５０、運賃条件１２２５、さらなる添付品に対するハイパーリンク１２６５、調整ノート１２７０、調整ノートの履歴１２７５、およびそれぞれの審査担当者用の状態インジケータ１２８０を含んでいる。
【０１４３】
運賃様式１２００においては、トランザクション情報１２３５、運賃条件１２５５、さらなる添付品１２６５を除いて、すべての要素が図９の様式９００に類似している。図９と関連して前述したように、さらなる添付品は、ユーザーによって自由に構成できる。
【０１４４】
トランザクション情報１２３５は、参照番号、請求書番号、請求書日付、注文番号、請求書合計、運賃条件、請求済みの合計（運賃）、支払済みの運賃金額、購入注文書番号、控除金額、合計割合金額、電子画像に対するいくつかのハイパーリンクを含んでいる。又、トランザクション情報１２３５は、控除された請求書の実際の割合を「合計％」として示している。トランザクション情報１２３５の第２列を使用することにより、要求されている控除の一部を承認のために審査しつつ、要求されている控除の一部を拒絶できる。
【０１４５】
この注文の実際の運賃条件は、参照符号１２３５のセクション内に含まれている。セクション１２５５内の運賃条件は、顧客マスタ内にセットアップされている顧客の条件を表している。しばしば、異なる製品は、異なる方法で出荷される。このため、セクション１２３５は、好ましくは、その特定の出荷に関する運賃条件の真の表現を示している。
【０１４６】
さらなる添付品１２６５は、運賃の顧客見積を取得するためのリンクを含んでいる。この見積は、画像化して文書に添付できる。
【０１４７】
図１３は、調整文書４２５のマーケティング様式の例１３００を示している。調整文書４２５のマーケティング様式例１３００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、マーケティング様式例１３００は、タイトル１３１０、作成者情報１３１５、審査担当者情報１３２０、顧客情報１３２５、販売員情報および与信分析者情報１３３０、トランザクション情報１３３５、マルチトランザクションチャート１３３７、調整チャート１３４０、プロモコード１３４５、影響が及ぶ在庫レコードインジケータ１３５０、マーケティングコメントインジケータ１３５５、さらなる添付品に対するハイパーリンク１３６５、調整ノート１３７０、調整ノートの履歴１３７５、およびそれぞれの審査担当者用の状態インジケータ１３８０を含んでいる。
【０１４８】
マーケティング様式１３００においては、トランザクション情報１３３５、マルチトランザクションチャート１３３７、プロモコード１３４５、マーケティングコメント１３５５、およびさらなる添付品１３６５を除いて、すべての要素が図９の様式９００に類似している。但し、マルチトランザクションチャート１３３７およびさらなる添付品１３６５は、図１０のものに類似している。
【０１４９】
トランザクション情報１３３５は、参照番号、請求書番号（あるいは、この場合には、借方伝票番号が参照符号である）、借方日付、小切手ＩＤ、借方合計、控除合計、および合計割合金額（特定の請求書を参照している場合）を含んでいる。トランザクション情報１３３５の第２列（または、その他の列）を使用することにより、要求されている調整の一部を更に審査しつつ、要求されている調整の一部を拒絶できる。
【０１５０】
プロモコード１３４５およびマーケティングコメント１３５５は、控除を提供する促進コードを一覧表示している。調整を提供する複数の促進コードが存在できる。このため、セクション１３３７は、（１つの特定の調整用に１０個の別個の促進コードを入力するべく）最大で１０個のフィールドのオプションを具備している（尚、セクション１３３７は、好ましくは、任意の所望の数のフィールドに動的に構成できる）。「プロモコード」の好ましい意味は、購入者のＧ／Ｌコードがリンクされているシステム上の場所である。
【０１５１】
図１４は、調整文書４２５のその他様式の例１４００を示している。調整文書４２５のその他様式例１４００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、その他様式例１４００は、タイトル１４１０、作成者情報１４１５、審査担当者情報１４２０、顧客情報１４２５、販売員情報および与信分析者情報１４３０、トランザクション情報１４３５、調整チャート１４４０、Ｇ／Ｌアルファコード１４４５、影響が及ぶ在庫レコードインジケータ１４５０、ＣＭ支払条件インジケータ１４５５、さらなる添付品に対するハイパーリンク１４６５、調整ノート１４７０、調整ノートの履歴１４７５、与信分析者審査担当者用の状態インジケータ１４８０を含んでいる。
【０１５２】
その他様式１４００においては、さらなる添付品１４６５および与信分析者審査担当者１４８０を除いて、すべての要素が図９の様式９００に類似している。その他様式１４００は、その他の様式によってカバーされない状況において有用であろう。さらなる添付品１４６５は、その他の控除用の価格承認の画像を添付するための価格承認セクションを含んでいる。与信分析者審査担当者１４８０は、与信分析者のみを含んでいる。但し、いくつかの販売者の場合には、与信分析者は、この調整タイプを審査する要員でなくてもよい。あるいは、この代わりに、このフィールドを第１の審査担当者として指定することもできる。例えば、いくつかの販売者は、調整のみを審査する専門の要員を具備できる。又、その他様式１４００は、通常、例えば、調整を別の様式に再分類するために必要な文書が購入者から受領される時点まで、一時的にのみ使用することもできる。
【０１５３】
図１５は、調整文書４２５の価格様式の例１５００を示している。調整文書４２５の価格様式例１５００は、図９の顧客順守様式例９００と同一の多くのアイテムを含んでいる。例えば、価格様式例１５００は、タイトル１５１０、作成者情報１５１５、審査担当者情報１５２０、顧客情報１５２５、販売員情報および与信分析者情報１５３０、トランザクション情報１５３５、調整チャート１５４０、Ｇ／Ｌアルファコード１５４５、影響が及ぶ在庫レコードインジケータ１５５０、ＣＭ支払条件インジケータ１５５５、さらなる添付品に対するハイパーリンク１５６５、調整ノート１５７０、調整ノートの履歴１５７５、およびクレジット分析者審査担当者用の状態インジケータ１５８０を含んでいる。
【０１５４】
トランザクション情報１５３５は、参照番号、請求書日付、注文番号、請求書合計、請求書条件、購入注文書番号、出荷日付、製品特定情報、数量、請求済みの価格および支払済みの価格を含む第１の製品特定領域、製品特定情報、数量、請求済みの価格および支払済みの価格を含む第２の製品特定領域、控除金額、合計割合金額、および電子画像に対するいくつかのハイパーリンクを含んでいる。トランザクション情報を使用することにより、請求済みの商品の価格に基づいて控除を管理できる。又、図１５に示されているように、価格に関連して複数の製品を個々に記述できる。尚、図１５の様式１５００には、２つの製品のみが個々に記述されているが、様式１５００は、任意の数の製品を表示するようにカスタマイズできる。又、販売者が、画像化された購入注文書に対するハイパーリンクを追加することを所望する場合があるが、その場合には、それらは、好ましくは、さらなる添付品フィールド内に読み取られることになる。
【０１５５】
図１６は、調整文書４２５の数量様式の例１６００を示している。数量様式例１６００は、図１０の損傷様式例１０００と同一の情報を含んでいる。数量様式例１６００は、図９に示されているものと同様に、タイトル１６１０、作成者情報１６１５、審査担当者情報１６２０、顧客情報１６２５、販売員情報および与信分析者情報１６３０、参照番号、請求書番号、注文番号、合計割合金額、電子画像に対するいくつかのハイパーリンクを含むトランザクション情報セクション１６３５、調整チャート１６４０、Ｇ／Ｌアルファコードインジケータ１６４５、影響が及ぶ在庫レコードインジケータ１６５０、ＣＭ支払条件１６５５、さらなる添付品に対するハイパーリンク１６６５、調整ノート１６７０、調整ノートの履歴１６７５、それぞれの審査担当者用の状態インジケータ１６８０、Ｐ．Ｏ．インジケータ、出荷日付、製品インジケータ、単価インジケータ、請求済みの数量、および支払済みの数量を含んでいる。
【０１５６】
図１７は、調整文書４２５の返品様式の例１７００を示している。返品様式例１７００は、図１０の損傷様式例１０００と同一の情報を含んでいる。返品様式例１７００は、図９に示されているものと同様に、タイトル１７１０、作成者情報１７１５、審査担当者情報１７２０、顧客情報１７２５、販売員情報および与信分析者情報１７３０、参照番号、請求書番号、注文番号、合計割合金額、電子画像に対するいくつかのハイパーリンクを含む情報セクション１７３５、調整チャート１７４０、Ｇ／Ｌアルファコードインジケータ１７４５、影響が及ぶ在庫レコードインジケータ１７５０、ＣＭ支払条件１７５５、さらなる添付品に対するハイパーリンク１７６５、調整ノート１７７０、調整ノートの履歴１７７５、それぞれの審査担当者用の状態インジケータ１７８０、Ｐ．Ｏ．インジケータ、出荷日付、製品インジケータ、単価インジケータ、請求済みの数量、および支払済みの数量を含んでいる。
【０１５７】
あるいは、この代わりに、返品様式１７００は、ＲＧＡ番号用のフィールドを含むこともできる。例えば、返品が発生した場合には、購入者は、通常、販売者に対してＲＧＡを要求し、次いで、購入者は、返品について控除する際に、その番号を参照する。又、返品は、常に１つの請求書に固有のものでなくてもよい。
【０１５８】
図１８は、調整文書４２５の税金様式の例１８００を示している。税金様式例１８００は、タイトル１８１０、作成者情報１８１５、審査担当者情報１８２０、顧客情報１８２５、販売員情報および与信分析者情報１８３０、参照番号、請求書番号、注文番号、借方日付、小切手特定情報、請求書合計、控除または支払金額、合計割合金額、電子画像に対するいくつかのハイパーリンクを含む情報セクション１８３５、調整チャート１８４０、Ｇ／Ｌアルファコード１８４５、影響が及ぶ在庫レコードインジケータ１８５０、ＣＭ支払条件１８５５、さらなる添付品に対するハイパーリンク１８６０、運賃クレームに対するハイパーリンク１８６５、調整ノート１８７０、調整ノートの履歴１８７５、およびそれぞれの審査担当者用の状態インジケータ１８８０などの顧客順守様式例９００と同一の多くの情報を含んでいる。請求済みの運賃対支払済みの運賃を反映している前述の運賃様式と同様に、税金様式は、請求済みの税金対支払済みの税金を反映している。
【０１５９】
図１９は、調整文書４２５の保証様式の例１９００を示している。保証様式例１９００は、図１０の損傷様式例１０００と同一の情報を含んでいる。例えば、保証様式例１９００は、タイトル１９１０、作成者情報１９１５、審査担当者情報１９２０、顧客情報１９２５、販売員情報および与信分析者情報１９３０、および参照番号、請求書番号）、注文番号、電子画像に対するいくつかのハイパーリンクを含む情報セクション１９３５、製品販売追跡セクション１９３７、調整チャート１９４０、影響が及ぶ在庫レコードインジケータ１９５０、ＣＭ支払条件１９５５、さらなる添付品に対するハイパーリンク１９６５、調整ノート１９７０、調整ノートの履歴１９７５、およびそれぞれの審査担当者用の状態インジケータ１９８０を含んでいる。又、保証様式例１９００は、図９に示されているものと同様に、製品インジケータおよび単価インジケータをも含んでいる。
【０１６０】
あるいは、この代わりに、いくつかの購入者の場合には、損傷していると考えられる保証製品の返却を購入者が求められる場合がある。その他の購入者の場合には、製品は、単純に破壊できる。保証アイテムを返却する場合には、追加のフィールドを保証様式に追加することにより、ＲＧＡ番号またはその他の設定可能なフィールドを提供できる。
【０１６１】
次に、図４の控除管理アプリケーションを再度参照すれば、調整文書生成器４２０が調整文書４２５を生成した後に、調整文書は、ワークフロー承認プロセッサ４３０に伝達される。次いで、ワークフロー承認プロセッサは、販売者３３０の必要な審査担当者に調整文書４２５を回付する。
【０１６２】
さらなる様式には、銀行手数料様式が含まれる。銀行手数料様式は、例えば、電信送金および信用状に関する手数料などの金融機関から課金される手数料を反映できる。しばしば、金融機関は、手数料を総収入から差し引いた後に、残りの金額を販売者のロックボックスに預金する。
【０１６３】
図２０は、事前に設定された購入者に固有の調整承認ワークフローによるワークフロー承認プロセッサ４３０の模範的な動作を示してる。図２０においては、ワークフロー承認プロセッサ４３０が調整文書４２５を受領している。好ましくは、ワークフロー承認プロセッサ４３０は、調整文書４２５と共に、事前に設定されている購入者に固有の調整承認ワークフローをも受領する。次いで、ワークフロー承認プロセッサ４３０は、事前に設定されている購入者に固有の承認調整ワークフローに従って、利用可能な審査担当者２０１０〜２０８０の組の１つまたは複数のものに調整文書４２５を回付できる。即ち、ワークフロー承認プロセッサ４３０は、好ましくは、調整文書を販売者の審査部門２０１０〜２０８０に対して自動的に回付する。又、販売者の部門２０１０〜２０８０のそれぞれは、好ましくは、調整文書内に内蔵可能な図８に示されている関連メモおよび文書８１０〜８７０のすべてに対してアクセスできる。
【０１６４】
ワークフロー承認プロセッサ４３０が、事前に設定されている購入者に固有の調整承認ワークフローを受領しない場合には、ワークフロー承認プロセッサ４３０は、調整文書を審査担当者２０１０〜２０８０の中の１人または複数のものからなる既定の組に回付できる。又、複数の審査担当者が同時に調整文書を参照する場合には、衝突を解決するための手順を実装できる。あるいは、この代わりに、ワークフロー規則は、ビジネス規則と同様に動作することもできる。即ち、状況に固有の規則によって無効にされない限り遵守される既定のワークフローを実装できる。購入者に固有であり且つ状況に固有の規則は、状況に固有の規則の一例であってよい。
【０１６５】
図２０の例においては、利用可能な審査担当者は、与信分析者２０１０、会計部門２０２０、業務部門２０３０、１つまたは複数の特定の業務要員２０４０、担当窓口２０５０、販売者のＣＦＯ（Chief Financial Officer）２０６０、販売部門２０７０、および輸送部門２０８０を含んでいる。さらなる審査担当者および自動分析エンジンを追加することも可能であり、図２０の審査担当者２０１０〜２０８０は模範的なものに過ぎない。
【０１６６】
又、この図には、それぞれの審査担当者が、それぞれ近接したものとのみ直接通信するものとして示されているが、動作の際には、それぞれの審査担当者は、好ましくは、任意のその他の審査担当者と通信できる。例えば、担当窓口２０５０は、調整文書４２５をＣＦＯ２０６０に送信できる。又、ＣＦＯ２０６０は、調整文書４２５を会計部門２０２０に送付できる。
【０１６７】
審査担当者は、それぞれ、調整文書４２５の個々の承認または拒絶をワークフロー承認プロセッサ４３０に送付できる。それぞれの審査担当者からの個々の承認または拒絶を受領した後に、ワークフロー承認プロセッサ４３０は、図３に示されているように、承認データ３４５を販売者３３０に送付する。あるいは、この代わりに、すべての審査担当者が調整を承認する権限を具備していなくてもよい。例えば、特定の審査担当者は、単に、特定の文書を付加し、あるいは、調整文書４２５になんらかの特定のデータを包含するべく、ワークフロー内に含まれていてもよい。既に登録データが販売者の会計システムに送付済みであるため、審査担当者の承認は、調整文書内に含まれている既に紛争状態となっているアイテムに対して発行されるクレジットを得るための許可を付与するものである。
【０１６８】
ワークフロー承認プロセッサ４３０は、調整文書４２５を審査するべき審査担当者を判定し、好ましくは、調整文書を１人または複数の審査担当者に対して自動的に回付する。この判定は、販売者３３０によってカスタマイズされた購入者に固有のワークフロー基準に基づいて実行される。調整文書を受領すると、好ましくは、付随しているカスタマイズ可能な基準が、ワークフロー承認プロセッサ４３０内において電子的に保存され、調整文書と付随している。
【０１６９】
次いで、ワークフロー承認プロセッサは、購入者に固有のワークフローに基づいて調整文書を回付する。例えば、単純な購入者に固有のワークフローは、調整文書を与信分析者２０１０、次いで、ＣＦＯ２０２０に送付するように通知できる。この結果、調整文書を与信分析者２０１０に対して伝送できる。与信分析者２０１０が調整を承認すると、与信分析者の承認がワークフロー承認プロセッサ４３０に返送される。ワークフロー承認プロセッサ４３０は、この承認を受領し、次いで、購入者に固有のワークフローをチェックし、さらなる承認が必要であるか否かを判定する。購入者に固有のワークフローに加え、購入者に固有のコードおよび調整の理由コードの組み合わせにより、ワークフローを判定することもできる。
【０１７０】
さらなる承認が必要な場合には、調整文書は、承認のために次の要員に回付されることになる。このケースにおいては、ＣＦＯの承認も必要であり、従って、調整文書は、ＣＦＯに回付される。
【０１７１】
逆に、与信分析者２０１０が調整を承認しない場合には、ワークフロー承認プロセッサ４３０は、不承認を受領し、次いで、ワークフロー承認プロセッサ４３０は、調整文書をさらなるアクションのために集金に回す。
【０１７２】
さらなる承認が不要な場合には、購入者に固有のワークフロー内のすべての要員による調整文書の承認が完了しており、調整を含む購入者の支払が承認されている。
【０１７３】
あるいは、この代わりに、購入者に固有のワークフローは、単に調整文書と関連する購入者を超えた調整文書の分析を含むこともできる。即ち、販売者は、調整文書の回付経路を判定する際に、調整文書からのさらなるデータを考慮するように、ワークフロー承認プロセッサを構成できる。例えば、単一の購入者の場合に、例えば、１０，０００ドルなどの特定の閾値を下回る調整については、与信分析者２０１０に回付するようにワークフロー承認プロセッサを構成できる。閾値を上回る調整は、ＣＦＯに対して直接回付できる。
【０１７４】
あるいは、この代わりに、ワークフロー承認プロセッサは、グローバルな閾値を上回るすべての購入者のすべての調整が審査担当者の異なる組に自動的に回付されるように、すべての購入者用のグローバルな閾値を実装することもできる。例えば、１００，０００ドルを上回るすべての調整を販売管理者に直接回付できる。
【０１７５】
調整の金額に基づいた調整文書の回付に加え、ワークフロー承認プロセッサ４３０は、例えば、調整文書４２５の顧客順守様式例９００の販売員情報、注文番号、請求書合計、控除金額、合計割合金額、影響が及ぶ在庫レコードインジケータ、及び/又は不順守理由インジケータのいずれかをチェックするカスタマイズ可能な基準を具備することにより、調整文書の回付を支援することもできる。
【０１７６】
ワークフロー承認プロセッサ４３０は、カスタマイズ可能な基準と調整文書内の情報の比較によって判定されるさらなる審査担当者に対して調整文書４２５を送付することもできる。例えば、ワークフロー承認プロセッサ４３０のカスタマイズ可能な基準は、顧客順守様式例９００の合計割合金額をチェックすることもできる。カスタマイズ可能な基準は、調整文書４２５の合計割合金額が、例えば、２０％などの所与の金額を上回っている場合に、調整文書のＣＦＯ２０６０への送付を必要とするものであってよい。図９の顧客順守様式例９００と比較された場合に、ワークフロー承認プロセッサ４３０の基準により、合計割合金額が２０％を下回っていることを判定できる。この結果、ワークフロー承認プロセッサ４３０は、調整文書４２５をＣＦＯ２０６０に送信しなくてもよい。但し、すべての文書が１つの特定の請求書を参照しているわけではないため、すべての調整文書が割合を具備可能ではないことに留意されたい。
【０１７７】
ワークフロー承認プロセッサ４３０は、調整文書４２５を審査するべき審査担当者を判定した後に、選択された審査担当者のそれぞれに対して調整文書４２５を送信する。例えば、ワークフロー承認プロセッサ４３０は、与信分析者２０１０、業務部門２０３０、ＣＦＯ２０６０、および販売部門２０８０は、調整文書４２５を審査する必要があるが、会計部門２０２０、業務審査担当者２０４０、担当窓口２０５０、および輸送部門２０８０は、調整文書４２５を審査する必要がないと判定できる。この場合には、ワークフロー承認プロセッサ４３０は、与信分析者２０１０、業務部門２０３０、ＣＦＯ２０６０、および販売部門２０８０にのみ、調整文書４２５を送付することになろう。
【０１７８】
あるいは、この代わりに、複数の要員が審査し、同一の調整文書に対して異なる情報を保存するべく試みることに伴う問題点を販売者が具備する可能性もある。例えば、調整の背景となっているオリジナルの理由がもはや有効ではない場合が、これに該当しよう。この場合には、調整文書を再分類する必要があり、次いで、審査担当者の新しいグループの全員に対する送信が必要となろう。この結果、フロープロセスは、一度に１人の審査担当者のみが必要な情報を取得し、次いで、調整文書を次の審査担当者に回付するように、調整文書を回付できる。
【０１７９】
それぞれの審査担当者が調整文書４２５を受領したら、審査担当者は、調整文書４２５内に含まれている情報を審査する。次いで、それぞれの審査担当者は、調整文書４２５を承認、拒絶、またはさらなる審査のために回付する。調整文書の審査担当者の承認および拒絶は、主にそれぞれの審査担当者の個々の基準に基づいている。例えば、与信分析者２０１０が、自身の基準に基づいて、調整文書４２５が与信分析者２０１０の基準を満足していないと判定した場合には、与信分析者２０１０は、調整文書４２５を拒絶できる。逆に、調整文書４２５が与信分析者２０１０の基準を満足している場合には、与信分析者２０１０は、調整文書４２５を承認できる。
【０１８０】
調整文書４２５を受領したそれぞれの審査担当者は、調整文書４２５を審査し、これを承認、部分承認、拒絶するか、またはさらなる審査担当者に対して回付する。次いで、それぞれの審査担当者は、調整文書４２５の承認または拒絶をワークフロー承認プロセッサ４３０に送付する。あるいは、この代わりに、第１審査担当者による評価が完了した際に、調整文書４２５を次の審査担当者に直接送付することもできる。あるいは、この代わりに、審査担当者は、調整文書のスケジュールされているフローを中断し、現在の審査担当者によって指定された特定の新しい審査担当者に対して調整文書を直接送付することもできる。例えば、担当窓口が調整文書を審査している場合に、調整文書は、担当窓口の審査が完了したら、販売部門に伝達されるようにスケジュールできる。しかしながら、担当窓口は、通常の手順を取り消し、例えば、調整文書をＣＦＯに直接送付するように決定できる。
【０１８１】
一実施例においては、審査担当者が調整を拒絶した場合には、ワークフロープロセッサは、さらなる処理のために調整文書を集金に回す。すべての審査担当者が調整を承認した場合には、調整が購入者の支払に対して適用され、購入者の調整が承認されて貸方伝票が送信される。即ち、好ましくは、購入者から送付された金額が即座に登録されることになる。調整または控除が後から承認された場合には、貸方伝票が販売者のシステムに送信されて支払不足が相殺される。控除が拒絶された場合には、不足額が口座に保持され、問題が集金に回される。
【０１８２】
別の実施例においては、調整文書は、以前の審査担当者が調整を承認または拒絶したか否かとは無関係に、１人または複数の審査担当者に対して回付できる。例えば、調整文書は、第１の審査担当者によって拒絶され得るが、この場合にも、第２の審査担当者に回付できる。そして、第２の審査担当者は、調整文書の拒絶を確認または逆転できる。例えば、与信分析者２０１０、担当窓口２０５０、および販売部門２０７０が、いずれも、それぞれの審査のために調整文書４２５を受領し、販売分析者２０１０と販売部門２０７０の両方が、調整文書４２５を承認したが、担当窓口２０５０が調整文書４２５を拒絶した場合には、ワークフロー承認プロセッサ４３０は、調整文書４２５を拒絶できる。
【０１８３】
ワークフロー承認プロセッサ４３０が調整文書４２５を承認するべきであると判定した場合には、ワークフロー承認プロセッサ４３０は、調整文書４２５が請求金額の控除または過払いに対する返金を要求しているか否かを判定できる。ワークフロー承認プロセッサ４３０が、調整文書４２５が過払いに対する返金を求めていると判定した場合には、ワークフロー承認プロセッサ４３０は、登録データ３４５を生成できる。登録データ３４５は、過払いの金額を有する請求書を生成する指示を包含できる。
【０１８４】
一方、ワークフロー承認プロセッサ４３０が、調整文書４２５が請求書金額の控除を要求していると判定した場合には、ワークフロー承認プロセッサ４３０は、購入者３１０の請求書金額を控除するべき金額の貸方伝票を含むことができる（これは、既に控除されており、４２５文書は、そのように生成されている。又、これは、１つの特定の請求書番号を常に参照するものではない）。
【０１８５】
逆に、ワークフロー承認プロセッサ４３０が、調整文書４２５を拒絶するべきであると判定した場合には、ワークフロー承認プロセッサ４３０は、調整文書を販売者の集金部門に回し、集金プロセスを開始できる。集金プロセスとは、未解決の請求書上の支払期日を超過した資金を集金するプロセスである。このようにして、ワークフロー承認プロセッサは、購入者３１０が販売者３３０の商品に対して販売者３３０にまだ支払っていない金額（即ち、認可されていない控除）を集金するための作業を開始できる。
【０１８６】
あるいは、この代わりに、ワークフロー承認プロセスにおいて、審査担当者は、カスタマイズ可能な許容値に基づいて調整文書４２５を承認または拒絶することもできる。例えば、第１実施例においては、単一の審査担当者が調整文書４２５を拒絶した結果、ワークフロー承認プロセッサ４３０が調整文書４２５を拒絶できる。しかしながら、代替実施例においては、審査担当者による調整文書４２５の１つまたは複数の拒絶に対してより大きな許容値を許容するように、ワークフロー承認プロセッサ４３０をカスタマイズできる。この結果、少なくとも審査担当者の過半数が調整文書４２５を拒絶した場合にのみ調整文書４２５を拒絶するように、ワークフロー承認プロセッサ４３０をカスタマイズできる。あるいは、この代わりに、審査担当者の承認に対する審査担当者の拒絶の比率が所与の値を上回った場合にのみ、調整文書４２５を拒絶するように、ワークフロー承認プロセッサ４３０をカスタマイズすることもできる。
【０１８７】
あるいは、この代わりに、ワークフローの一部として含まれている任意の要員が任意のポイントにおいて調整文書を拒絶できるようにすることもできる。但し、最終承認者は、１人だけ存在していることが好ましい。このようなシステムによれば、調整の拒絶によって集金に時間を要することにならないように、審査担当者がすべてのものを承認してしまうことを防止できる。
【０１８８】
図２１は、審査担当者による承認を待っているすべての未解決の調整を要約した審査担当者用の模範的なタスクリスト２１００を示している。タスクリスト２１００は、複数の未解決の調整または紛争２１０５、審査担当者名２１１０、紛争理由コード２１１５、調整番号２１２０、顧客名２１２５、顧客番号２１３０、請求書／参照番号２１３５、請求書日付（これは、好ましくは、その調整が生成された日付である）２１４０、および締切期日２１４５を含んでいる。締切期日は、好ましくは、販売者が調整の解決を予定している販売者が設定した日付である。例えば、販売者は、調整の解決のために３０日の内部締切期日を設定できる。あるいは、この代わりに、締切期日２１４５を除去するか、または、最初の支払を受領した受領日付に変更することもできる。
【０１８９】
又、タスクリスト２１００は、未解決の調整の合計通貨金額２１５０および調整経過時間列２１５５をも含んでいる。タスクリスト２１００の内容は、好ましくは、特定の審査担当者に割り当てられている承認プロセッサ４３０内の未解決の要素を表示している。又、タスクリストの内容は、好ましくは、ワークフロー承認プロセッサと通信状態において稼働しているコンピュータアプリケーションによって生成される。
【０１９０】
タスクリスト２１００の外観および内容は、好ましくは、自由に構成できる。例えば、タスクリストは、顧客識別子、調整の大きさ、調整の経過時間、調整の割合、およびこれらに類似のグループ分けなどのいくつかのユーザー選択可能なパラメータに基づいて、グループ分けしてその内容を表示するべく容易に再構成できる。
【０１９１】
タスクリスト２１００は、承認を待っているもの以外の調整も包含できる。例えば、タスクリストは、分類、リサーチ、承認、審査を待っているアイテムや、販売者が利用可能なその他の任意の状態コードを包含できる。又、調整の審査に伴って、調節を再分類することもできる。例えば、第１の審査担当者が、調整を第２の審査担当者に伝達したとしよう。そして、第２の審査担当者が、誤ったタイプの調整様式が使用されていると判定したとしよう。この場合には、第２の審査担当者は、調整様式のタイプを変更し、ワークフローの設定にのみ従って、さらなる審査のために第１の審査担当者に、またはそれ以外の要員に修正済みの調整様式を返却できる。
【０１９２】
動作の際には、複数の未解決の調整２１０５が、承認、拒絶、部分承認、またはさらなる審査のために審査担当者２１１０に回付される。審査担当者２１１０は、顧客請求書データ、締切期日、または未解決の残高などの列基準２１１５〜２１５５のいずれかにより、未解決の調整２１０５をソートできる。
【０１９３】
図２１においては、審査担当者２１１０は、紛争理由コード２１１５により、未解決の調整２１０５のソートを完了している。前述のように、紛争理由コードのそれぞれを図９〜図１９の調整文書の１つと付随してできる。あるいは、この代わりに、紛争コードは、その他の販売者が選択した状態となるように設定することもできる。又、それぞれの紛争理由コードごとに、紛争理由コードごとの合計ドル金額２１６０が示されている。
【０１９４】
調整文書が審査担当者２１１０に回付され、要約シート２１００として編成されると、審査担当者２１１０は、未解決の紛争２１０５のいずれかを単純にクリックすることにより、その未解決の紛争と関連する調整文書を表示できる。又、前述のように、調整文書のそれぞれは、好ましくは、未解決の調整２１０５の承認、拒絶、部分承認、またはさらなる回付を行うために審査担当者２１１０が必要としているすべての関係するデータ及び/又は読み取られた画像を含んでいる。
【０１９５】
この結果、好ましくは、審査担当者２１１０は、迅速であって相対的に容易な方式で、すべての未解決の調整２１０５を解決するのに必要なすべての情報を取得する。支払に関係するすべての情報が審査担当者用に既に取り纏められているため、審査担当者２１１０が情報をサーチし、異なるシステムから情報を取得する必要はない。
【０１９６】
逆に、いくつかの状況においては、タスクリストを中間審査担当者に提供することにより、中間審査担当者が所望の文書によってタスクリスト上の調整の中の１つまたは複数のものを更新できるようにすることもできる。次いで、更新済みの調整を評価のために審査担当者に伝達できる。
【０１９７】
又、審査担当者が調整を承認したが、異なる審査担当者によるさらなる審査が通知された場合には、調整文書は、単純に第１の審査担当者のタスクリスト２１００から第２の審査担当者の要約シートに移動することになる。例えば、第１の審査担当者がその審査を完了すると、第１の審査担当者は、調整を第２の審査担当者に送付できる。この結果、第１審査担当者の要約シートから第２審査担当者の要約シートへの調整文書の電子的な転送には、転送の遅延が伴わず、審査担当者間の調整文書の転送の際の情報の消失が回避される。この結果、調整文書の回付が低速であって、困難であり、且つ、しばしば、回付プロセスにおける必要な情報の消失を伴っている従来技術によるシステムの問題点が除去される。
【０１９８】
あるいは、この代わりに、第１の審査担当者のタスクリストから第２審査担当者のタスクリストに移動する代わりに、調整の状態を、例えば、単純に、「未処理」から、「承認済み」、「未承認」、またはなんらかのその他の状態コードに変更することもできる。
【０１９９】
図２３は、図９〜１９の調整文書などの調整文書を概要的な表現２３００で表す。調整文書２３００は、調整状態制御２３０５、ヘッダ情報２３１０、状態情報２３２０、顧客情報２３２５、請求書／借方情報２３３５、追加情報２３４０、メモ２３６０、編集履歴２３７０、ワークフローデータ２３８０、添付ファイル制御２３６５、および添付ファイル２３７０を含んでいる。
【０２００】
前述のように、調整文書内に含まれている情報の実際のアイテムは、いくつかのレベルにおいて設定できる。例えば、販売者は、特定タイプの様式用に既定の外観および情報コンテンツを設定できる。又、顧客ごとの既定値を利用して販売者に固有の既定値を変更することもできる。又、調整文書のコンテンツは、好ましくは、審査担当者によって微調整可能であり、調整文書内に表示される情報のアイテムは、好ましくは、審査担当者によって動的に変更できる。尚、この概略的な調整文書２３００は、好ましくは調整文書のコンテンツを構成する情報の一般的なカテゴリを示している。
【０２０１】
まず、調整状態制御２３０５との関連においては、審査担当者は、調整状態制御２３０５とやり取りし、調整文書の状態を変更できる。例えば、調整状態制御２３０５は、審査担当者が選択可能な調整文書の様々な状態を表す複数のボタンを包含できる。
【０２０２】
ヘッダ情報２３１０は、好ましくは、調整を要求している会社の名前、調整のカテゴリ、調整文書の識別番号、および紛争フラグなどの調整文書に関係する基本的な情報を含んでいる。
【０２０３】
状態情報２３２０は、好ましくは、例えば、承認済み、部分承認済み、拒絶済み、または、承認待ちなどの調整文書の現在の状態を示している。顧客情報２３２５は、例えば、顧客のコンタクト情報及び/又は顧客の割引などの顧客に固有の会計情報などの顧客に関係する情報を含んでいる。
【０２０４】
請求書／借方情報２３３５は、顧客と紛争になっている請求書に関する情報を含んでいる。例えば、請求書／借方情報２３３５は、好ましくは、請求書の日付および金額、送付された商品のリスト、並びに、損傷した商品及び/又は受領されなかった商品に関する（購入者から提供された）任意の情報を包含できる。
【０２０５】
追加情報２３４０は、審査担当者によって自由に設定可能であり、審査担当者が調整文書内に内蔵することを選択した追加データを包含できる。メモ２３６０は、例えば、販売者の要求されている調整に関連する１人の審査担当者から次の審査担当者へのメモを含むことができる。編集履歴２３７０は、好ましくは、その調整文書に発生したすべての状態変化のリストを含んでいる。ワークフローデータ２３８０は、好ましくは、その調整文書を審査したすべての審査担当者のリストを含んでいる。
【０２０６】
添付ファイル制御２３６５は、好ましくは、審査担当者が外部ファイルを調整文書に容易に添付できるようにするインターフェイスである。添付されたファイル自体は、添付ファイル２３６７として表されている。
【０２０７】
従って、本発明の好適な実施例は、自動販売支払処理および例外管理ソリューションを提供している。この自動ソリューションは、販売者が設定した購入者に固有のビジネス規則の組に従って多数の調整を迅速に処理できる。従って、この自動ソリューションは、大多数の調整を解決するのに従来必要とされている時間と作業を劇的に低減できる。この結果、販売者は、労働力を極小化し、且つ、多数の調整を処理する速度を極大化することによって大きな節約を実現できる。
【０２０８】
又、好適な実施例においては、支払のマッチング、ビジネス規則、およびワークフローが、いずれも、金融機関を通じて提供されている。金融機関の中には、現金による支払を自動的に解決するべく試みているものも存在しているが、販売者から受領したデータを支払の解決プロセス内に直接一体化している金融機関は存在しない。
【０２０９】
又、本出願においては、「購入者」という用語を使用しているが、実際の購入者は、彼らの支払活動の一部またはすべてを第三者にアウトソーシング可能であり、あるいは、サードパーティによってホスティングまたは提供される様々な活動を具備することもできることを認識されたい。例えば、購入者は、文書の画像化をアウトソーシングできる。「購入者」という用語は、代理店、購入グループ、独立したサードパーティ、フランチャイズ加盟店、運送業者、または購入プロセスに関与するその他のエンティティを含む任意の支払を実行するエンティティを含むべく広範な意味を有している。
【０２１０】
同様に、本明細書においては、「販売者」という用語も使用されているが、これも、実際には、サードパーティ、またはホスティングされたアプリケーション、またはその他の構成表すことができる。従って、「販売者」という用語は、商品またはサービスの支払を受領する任意のエンティティを含むべく、広範な意味を有している。
【０２１１】
又、前述のように、本支払および調整管理アプリケーションの実施例は、様々な実装のいずれかにおいて供給できる。例えば、管理アプリケーションは、金融機関にインストールしたり、販売者によってホスティングされたり、サードバーティのプロバイダにアウトソーシングされたり、あるいは、販売者にインストールしたりすることができる。
【０２１２】
本実施例は、まず、ＸＸＸＸに出願された「System And Method For Automated Incoming Payment And Invoice Reconciliation」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に更に記述されているシステムなどの受領したすべての支払を請求書とマッチングさせるべく試みるシステムにおいて最も有用であろう（この出願の内容は、本引用により、そのすべてが本明細書に包含される）。そして、請求書マッチングシステムによって直接的にマッチング不可能な受領された請求書は、ＸＸＸＸに出願された「System And Method For Automated Payment And Adjustment Processing」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に更に記述されている自動支払処理および例外管理システムに回付できる（この出願の内容は、本引用により、そのすべてが本明細書に包含される）。そして、最終的に、自動支払処理および例外管理システムが購入者の調整を自動的に処理できない場合には、前述のように、調整文書を生成し、承認のために要員に回付できる。
【０２１３】
以上、本発明の特定の要素、実施例、およびアプリケーションについて図示および説明した。しかしながら、当業者であれば、以上の開示内容に鑑み、変更を加えることができるため、本発明は、これらに限定されるものではないことを理解されたい。従って、添付の請求項は、そのような変更をも含んでおり、本発明の精神および範囲内に属するそれらの特徴をも包含するものと考えられたい。
【図面の簡単な説明】
【０２１４】
【図１】従来技術による商品購入の代表的なトランザクションを示す図である。
【図２】商品を販売するトランザクションを処理する代表的なワークフローを示す図である。
【図３】本発明の一実施例による自動支払処理および例外管理システムを示す図である。
【図４】図３の調整管理アプリケーションの一実施例を更に詳細に示す図である。
【図５】支払データ内に包含可能な情報源のいくつかのタイプの一例を示す図である。
【図６】本発明の一実施例によるビジネスデータフィルタの動作のフローチャートを示す図である。
【図７】調整文書生成器による調整文書の生成および回付を実現するべく調整文書生成器が受領可能な購入者固有情報の一例を示す図である。
【図８】調整文書内に内蔵する様々な模範的な文書およびその他のアイテムを示す図である。
【図９】本発明の一実施例による顧客順守様式の例を示す図である。
【図１０】本発明の一実施例による損傷様式の例を示す図である。
【図１１】本発明の一実施例による割引様式の例を示す図である。
【図１２】本発明の一実施例による運賃様式の例を示す図である。
【図１３】本発明の一実施例によるマーケティング様式の例を示す図である。
【図１４】本発明の一実施例によるその他様式の例を示す図である。
【図１５】本発明の一実施例による価格様式の例を示す図である。
【図１６】本発明の一実施例による数量様式の例を示す図である。
【図１７】本発明の一実施例による返品様式の例を示す図である。
【図１８】本発明の一実施例による税金様式の例を示す図である。
【図１９】本発明の一実施例による保証様式の例を示す図である。
【図２０】事前に設定された購入者に固有の調整承認ワークフローによるワークフロー承認プロセッサの模範的な動作を示す図である。
【図２１】審査担当者による審査を待っているすべての未解決の調整を要約した審査担当者用の模範的なタスクリストを示す図である。
【図２２】調整様式を処理するための手順の一実施例のフローチャートを示す図である。
【図２３】図９〜図１９に示した調整文書を概要的な表現で表す図である。
【図１】
2007507800.tif 000004
【図２】
2007507800.tif 000005
【図３】
2007507800.tif 000006
【図４】
2007507800.tif 000007
【図５】
2007507800.tif 000008
【図６】
2007507800.tif 000009
【図７】
2007507800.tif 000010
【図８】
2007507800.tif 000011
【図９】
2007507800.tif 000012
【図１０】
2007507800.tif 000013
【図１１】
2007507800.tif 000014
【図１２】
2007507800.tif 000015
【図１３】
2007507800.tif 000016
【図１４】
2007507800.tif 000017
【図１５】
2007507800.tif 000018
【図１６】
2007507800.tif 000019
【図１７】
2007507800.tif 000020
【図１８】
2007507800.tif 000021
【図１９】
2007507800.tif 000022
【図２０】
2007507800.tif 000023
【図２１】
2007507800.tif 000024
【図２２】
2007507800.tif 000025
【図２３】
2007507800.tif 000026
【国際調査報告】
2007507800.tif 000027