JP2007507799A - 自動支払と自動調整のためのシステムおよび方法 - Google Patents

Abstract

事前設定したビジネス規則のセットを使用し、調整処理を自動的に実施するシステムと方法とを提供する。販売者は、特定の購入者との調整処理を行うのに使用するビジネス規則のセットを、事前設定する。ビジネス規則のセットは、各購入者及び/又は広範囲のセットに向け可変にすることができる。支払が販売者で受領され、調整が必要になったとき、調整管理アプリケーションは、購入者のビジネス規則のセットを販売者から検索する。ビジネス規則のセットは、受領した支払と購入者の未払い請求書とをマッチングすることを試みる。マッチングが、成功したとき、購入者の支払処理が進められる。

Description

本出願は、一般に、販売者に送金される支払いに関連して、購入者による調整または控除などの例外処理を管理するシステムおよび方法に関するものである。さらに詳しくは、本出願は、販売者に送金される支払いに関連して、購入者が要求する控除や購入者に対する与信などのような調整を処理し、販売者側のトランザクションを処理し、トランザクションを完結させ、且つ、販売者の会計システムを更新するための自動化システムおよび方法を提供する。

図１は、従来技術による商品購入の代表的なトランザクション１００を示している。図１に示されているように、このトランザクションには、購入者１１０、販売者１３０、および金融機関１２０が関与している。通常、購入者１１０は、購買要求書１０２または購入注文書を販売者１３０に対して送付する。購買要求書１０２は、購入者１１０が所望する商品を特定している。販売者１３０は、購入者の購入注文書を受領した後、対象商品を購入者１１０に対して出荷する。

商品と同時または別ルートで、販売者１３０は、明細書または請求書１０５を送付することになる。請求書１０５は、通常、出荷された商品を記載しており、価格、数量、販売者コードまたはＳＫＵ番号などの特定情報などの情報、及び/又はその他の注文情報を包含することもできる。あるいは、この代わりに、同一の購入者に対して複数の出荷が行われる場合には、１つの出荷用の１枚の請求書の代わりに、複数の出荷を反映した明細書を利用することもできる。

販売者の商品と請求書１０５とを受領すると、購入者１１０は、この時点（または、この後の時点）において、商品に対する支払を行わなければならない。現在、多くの場合に、購入者は、現金、小切手、クレジットカード、自動決済機関（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 Adjustment Processing」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書にさらに記述されており、この内容は、本引用により、そのすべてが本明細書に包含される。

調整処理アプリケーション３４０が支払および送金データ３２５および注文データ３３５を処理して購入者の調整が解決されたら、調整処理アプリケーション３４０は、登録データ３４５を販売者３３０に対して送信する。後述するように、登録データ３４５は、貸方伝票を生成するための指示、在庫に対する調整、または控除を集金部門に回すための指示などのいくつかの形態の中のいずれかであってよい。

前述のように、請求書情報３０５は、いくつかの形態のいずれかを取ることができる。例えば、請求書情報３０５は、紙の文書であるか、あるいは、電子メール、ウェブ対応様式、またはその他のＥＤＩ情報交換などの電子的な文書であってもよい。

尚、以上においては、購入者による商品の注文に関連し、本実施例について説明しているが、この代わりに、購入者がサービスの入手に関心を持つこともできる。調整管理に関連し、サービスを入手するという環境においても同様に考えることができる。この説明においては、商品に合焦しているが、本支払処理および例外管理システムは、同様にサービスに対しても適用され、商品に限定されるものではない。

前述のように、請求書情報は、後述するように大量の情報を包含することができる。しかしながら、以下に一覧表示する情報アイテムのすべてが請求書情報内に存在している必要はない。請求書情報の一部として包含するアイテムは、販売者が設定することができる。例えば、請求書情報は、販売者３３０から購入者３１０に販売された商品及び/又はサービスの数量および価格に関する情報を包含することができる。請求書情報３０５は、出荷日、購入者３１０の名前および住所、販売者３１０の名前および住所、購入者３１０から販売者３３０に対する支払期限を超過した金額、または販売者３３０において購入者３１０が具備している利用可能な与信などの情報を包含することもできる。さらには、請求書情報３０５は、特定および追跡のために販売者３３０が使用する請求書番号を含むこともできる。例えば、請求書情報３０５は、購入者３１０に配送または提供された商品及び/又はサービスを販売者３３０が追跡できるように請求書番号を包含することができる。さらには、請求書情報３０５は、運送証券、並びに／あるいは、運賃請求書、配送証明書、及び/又は価格見積などのその他の文書を含むこともできる。

前述の請求書情報と同様に、支払情報は、多数の形態の中から購入者が選択したいずれかの形態を取ることができる。従って、例えば、支払情報３１５は、小切手、金融機関の為替手形、銀行小切手、送金為替、与信限度に借方登録する命令、約束手形、または受領した商品及び/又はサービスに対する支払を示すその他の文書を含むことができる。また、支払情報３１５は、支払の形態の電子画像を含むこともできる。例えば、支払情報３１５は、商品及び/又はサービスに対する支払に使用される小切手の電子画像を包含することができる。

前述の説明に加え、好ましくは、支払データ及び/又は送金情報が電子的な形態で購入者から提供されていない場合には、金融機関３２０が支払および送金データを作成する。即ち、金融機関３２０は、例えば、小切手などの到来した支払情報を審査し、次いで、小切手に関係するデータの組を生成できる。例えば、金融機関３２０は、受領日、金額、支払人、被支払人、および任意の口座、ＭＩＣＲ、または請求書番号を小切手の上に電子的に書き留めることができる。金融機関は、受領した小切手を電子的に画像化することもできる。次いで、金融機関３２０によって施されたこの記録を支払および送金データ３２５の一部として調整管理アプリケーションに伝達することができる。

あるいは、この代わりに、支払情報が金融機関３２０に対して電子的に配送される場合には、支払情報は、様々な形態のいずれかを取ることができる。金融機関３２０は、通常、受領した支払情報を処理し、金融機関の内部的な処理基準に合致したものになるように、支払情報を再表現または再フォーマット化する。次いで、この電子的に再処理済みの受領した支払情報は、支払および送金データの一部として調整処理アプリケーション３４０に対して送信することができる。

支払データおよび送金データ自体は、金融機関３２０が選択する様々な形態のいずれかを採用することができる。例えば、支払および送金データ３２５は、この代わりに、ＸＭＬ文書、ＥＤＩ文書、インターネットベースの金融サービスからの情報、あるいは、商品またはサービスの支払に関係する電子的データのその他の形態から構成することができる。

注文データ３３５および登録データ３４５も、例えば、電子メール、ＸＭＬ文書、ＨＴＭＬ文書、またはＥＤＩなどの様々な形態のいずれかを取ることができる。

又、調整処理アプリケーション３４０は、例えば、パッケージソフトウェアアプリケーションとして実装可能であり、あるいは、ＡＳＰ（Application Service Provider）として、金融機関またはその他のサードパーティにインストールすることもできる。ＡＳＰとしては、調整処理アプリケーション３４０を金融機関３２０、販売者３３０、またはサードパーティによって直接ホスティングすることができる。調整処理アプリケーション３４０が、金融機関３２０および販売者３３０と通信状態に維持されている限り、その実際の物理的な場所は関係ない。例えば、調整処理アプリケーション３４０は、サードパーティにホスティングまたはインストールされるか、または、その他の方法でアウトソーシングすることもできる。

図４は、図３の調整処理アプリケーション３４０の一実施例を詳細に示している。図４に示されているように、調整処理アプリケーション３４０は、ビジネスデータフィルタ４１０、調整文書生成器４２０を含んでいる。図３に関連して前述したように、調整処理アプリケーション３４０は、金融機関３２０から支払および送金データ３２５を、そして、販売者３３０から注文データ３３５を受領する。次いで、支払および送金データ３２５および注文データ３３５は、調整処理アプリケーション３４０のビジネスデータフィルタ４１０に引き継がれる。

ビジネスデータフィルタ４１０は、注文データ３３５と支払および送金データ３２５とを受領し、動作の際には、支払および送金データ３２５と注文データ内に含まれている１つまたは複数の請求書とをマッチングさせるべく試みる。ビジネスデータフィルタ４１０が、支払および送金データ３２５を注文データ３３５内の１つまたは複数の請求書にマッチングさせることができた場合には、ビジネスデータフィルタは、前述のように、登録データ３４５を販売者３３０に送付してトランザクションを完結させる。ビジネスデータフィルタ４１０が、支払および送金データ３２５を注文データ３３５内の１つまたは複数の請求書にマッチングさせることができない場合には、支払および送金データ３２５は、図６と関連して後述するように、ビジネスデータフィルタによってさらに処理されることになる。

例えば、受領した注文データが、購入者の未払いの請求伝票の表記番号とマッチングし、受領した支払金額が、請求伝票の金額とマッチングした場合、登録データ３４５は、販売者の会計システムに受領した支払を登録するために、販売者３３０に送信される。

しかし、受領した支払の総計が、請求書の金額とマッチングしないとき、ビジネスデータフィルタ４１０は、図６と関連して後述するように、注文データ３３５と支払データ３２５をマッチングさせるように試みるべく、一連のビジネス規則を適用する。ビジネス規則の適用後に、ビジネスデータフィルタ４１０がマッチングを検出できた場合には、ビジネスデータフィルタ４１０は、登録データ３４５を販売者３３０に伝達する。さらに、調整ドキュメントが生成されるように、ビジネスデータフィルタ４１０は、支払データ３２５を調整文書生成器４２０に送信する。そして、調整文書４２５も販売者３３０に送信される。しかし、購入者との調整は、ビジネス規則を充足しているので、さらなる人が介在する対話や承認作業をすることなく、購入者の調整は、販売者によって自動的に受理される。

ビジネスデータフィルタ４１０のビジネス規則を適用した後でも、注文データと支払データがマッチングしないとき、支払データ３２５は調整文書生成器４２０に送付され、調整文書が生成される。しかし、生成された調整文書が、調整内容がビジネス規則を充足していないため、販売者の会計システムで自動的に処理されないことがある。さらに、ビジネスデータフィルタに適用されるビジネス規則は、後述するように、購入者の規定を設定することが望ましい。

調整承認様式の構造、承認様式の回付は、「System And method For Seller-Assisted Automated Payment Processing and Exception Management」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に、さらに記述されており、この内容は、本引用により、そのすべてが本明細書に包含される。

調整文書４２５は、好ましくは、支払データ並びに購入者に関係するすべての関連データを含んでいる。購入者と関係する関連データは、好ましくは、信用の格付けを含む購入者の以前の購入および支払活動、並びに、購入者を担当している販売者の担当窓口または購入者に付与された以前の割引などの購入者に関係する販売者側の情報を含んでいる。

ビジネスデータフィルタ４１０は、購入者の情報がトランザクションから消失している場合に、支払データを検証するように要求することもできる。例えば、支払データが購入者の特定情報を含んでいない場合には、ビジネスデータフィルタ４１０は、全購入者の未解決のすべての請求書に対して、支払金額またはその他の利用可能な情報にマッチングさせるべく、試行することができる。マッチングが検出された場合には、ビジネスデータフィルタ４１０は、例えば、請求書以外の特定のフィールドなどの二次的な基準により、試行したマッチングを確認できるように、ユーザーに対して自動的に要求することができる。

好ましくは、ビジネス規則によって提供されるトランザクションの検証は、トランザクションの下記の面からの検証を含む。
（１）購入者３１０の顧客情報に関する検証
（２）購入者に運搬された商品の配送情報、好ましくは、例えば、積み荷の請求書及び/又は運送証券を含む配送情報、さらにドル金額を含む配送情報に関する検証
（３）購入者の支払が既に受領した支払の重複であるか否か、または、合計金額で既定の閾値の許容値より下回る金額で、購入者から送金されてきた金額が請求金額と異なっているか否か、あるいは、合計請求書金額が既定の金額を下回っているか否かのような判定をするための購入者の支払に関する検証

図５は、支払データ３２５内に包含可能な情報源のタイプのいくつかの例を示している。前述のように、支払データ３２５は、ＸＭＬ文書５１０、ＥＤＩ文書５２０、電子データ５４０、及び/又はウェブサービスからのデータ５３０から導出されたデータを包含することができる。電子データ５４０は、図３に示されているように、支払情報３１５の電子画像を含むことができる。支払データ及び送金データ３２５は、調整処理アプリケーション３４０により解析が可能である金融機関が所望する内部フォーマットに設定することができる。

従って、本実施例は、支払データと請求書データとを自動的にマッチングさせるべく機能する。前述のように、支払データと請求書データとをマッチングさせるための従来技術による方法は、大量の手作業を伴っており、極めて低速である。本実施例によれば、到来する大部分の支払を自動的にマッチングおよび処理することができる。従って、作業量と費用が低減され、利用可能な現金を相対的に正確に査定することができる。

さらに、本実施例は、販売者の金融機関と直接一体化して実施されることが望ましい。この結果、金融機関に通知する処理が不要となり、または金融機関に対する販売者内での会計の小部門が不要となる。

図６は、調整管理アプリケーションの動作のフローチャート６００をさらに詳しく示している。まず、段階６０１〜６０２において、支払データおよび注文データを受領する。次に、段階６０５において、支払データは、金融機関によって受信され、バッチ処理がなされる。即ち、金融機関は、１つの預金内にいくつかの支払を蓄積し、順番にバッチ処理することができる。次いで、販売者の要員は、全体として、支払のバッチ処理を行うために、金融機関のレコードにアクセスすることができる。

段階６１０において、支払のバッチ内のそれぞれの支払を評価する。好ましくは、支払データ６０１は、購入者によって実行された支払を販売者から購入者に送付された特定の請求書番号とリンクさせる請求書情報を含んでいる。好ましくは、注文データ６０２の一部として、請求書番号のリストが販売者から検索される。段階６１５において、注文データによって提供された請求書番号とマッチングする請求書番号を支払が含んでいるかどうかを判定する。マッチングする請求書番号が検出された場合には、処理は、段階６３０に進み、請求書を支払にマッチングさせる。請求書番号のマッチングが検出されない場合には、処理は段階６２０に進む。

段階６２０においては、受領した支払データと、注文データから回収された１以上の請求書とをマッチングさせるために、販売者による人との対話のような追加処理が要求されることがある。このような処理は、「System And Method For Seller-Assisted Automated Payment Processing and Exception Management」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に、さらに記述されており、この内容は、本引用により、そのすべてが本明細書に包含される。

段階６３０に進行した現在、受領した支払は、特定の請求書番号に対するマッチングが完了している。次に、段階６３２において、請求書内に含まれている請求している支払金額と、受領している支払とを比較する。受領している支払が請求している支払とマッチングした場合には、プロセスは段階６３５に進む。段階６３５において、販売者の会計システムに対する登録のために、支払がマーキングされる。

逆に、受領した支払が請求している支払とマッチングしない場合には、プロセスは、段階６４０に進む。段階６４０において、支払金額が請求している金額と正確にマッチングしない場合にも、支払が請求書と「マッチング」できるようにするべく、ビジネス規則を提供している。例えば、受領した支払が請求している支払金額と異なっている場合にも、その差が十分に小さい場合には、請求書と支払がマッチングしていると見なすように、本システムに対してグローバルな閾値を設定することができる。例えば、グローバルな閾値として、受領した支払が、１％未満または１００ドル未満だけ請求書金額と異なっている場合には、請求書と支払をマッチングしているものと見なすことができる。グローバルな閾値は、好ましくは、販売者によって設定される。

すべての購入者に対して適用可能なグローバルなビジネス規則以外に、購入者固有のビジネス規則を適用することもできる。受領した支払と請求書がマッチングできるようにするべく、グローバルな閾値の代わりまたは追加する閾値として、例えば、グローバルな閾値よりも寛容な購入者に固有の閾値を利用することができる。例えば、販売者は、２％または５００ドルの購入者固有の閾値を設定可能であり、この結果、受領した支払が、請求した金額から購入者固有の閾値を上回って異なっていない限り、支払は、請求書とマッチングしていると見なされる。また、割引やその他のインセンティブなどのその他の購入者に固有の基準を適用することができる。

グローバルな閾値および購入者固有の閾値を含むビジネス規則は、段階６０２において、注文データの一部として販売者から検索することができる。あるいは、この代わりに、ビジネス規則は、プロセスが段階６４０に進む際に、販売者から検索することもできる。別の代替例として、ビジネス規則は、調整処理アプリケーション内に保存することも可能であり、定期的な更新のために販売者が使用することができる。すべてのビジネス規則は、販売者によって設定されることが好ましい。

次に、段階６４２に向かうとき、ビジネス規則の適用後に、支払金額が請求済みの金額とマッチングしている場合には、プロセスは、段階６５０に進む。段階６５０において、請求書の支払額と受領した支払額との間の差を貸方登録するべく、Ｇ／Ｌ（総勘定元帳）の損金記録のような調整資料を生成する。次いで、本プロセスは、段階６３５に進み、登録のために支払をマーキングする。登録のための支払のマーキングが完了したら、段階６９０において、登録データを販売者に伝達する。

ビジネス規則の適用後も、購入価格がマッチングしないとき、プロセスは、さらなる処理のため、段階６２０へ進む。ここでは、販売者による人との対話のような処理が、受領した支払データと注文データの中で回収された１以上の請求書とをマッチングさせるために、必要とされることがある。

購入者固有の情報は、販売者から由来することもあり、先在する初期設定から由来することもある。または販売者によるプログラミング、購入者の団体の行動に関する自動的解析かにより由来することもある。例えば、ビジネスデータフィルタは、最新の発注書の規模または支払の規模に基づいて、閾値のパーセンテージまたは他の閾値を動的に増加させるように設定することがある。さらに、例えば、閾値のパーセンテージまたは他の閾値は、購入者と販売者との関係密度により動的に変化させることがある。

本発明のシステムは、販売者が控除のようなクレームや調整を受けたとき、販売者のために支払を自動的に処理することを提供することができる。ビジネス規則が含まれる調整の自動処理により、人のいろいろな対話処理が無く、調整での大きな作業量が、システムによって自動的に処理されるようになる。かわりに、人の対話処理は、ビジネス規則範囲外の少しの調整作業だけが必要とされる。この結果、調整／控除処理の多くは、自動的に処理されることになり、作業時間において顕著な費用節減が実現できる。

さらに、本発明のシステムは、控除の場合を損金処理の記録として調整書類に含めているので、販売者の会計システムを自動的に更新することができる。この結果、購入者の調整が自動的に処理されたときでさえ、必要であれば、購入者の調整記録は、販売者の会計システムに含まれ、レビューの実例または順守の目的として含まれる。

また、本発明のシステムは、販売者の金融機関と直接一体化することができる。このことは、実行の容易化と処理の高速化を追加することになる。しかし、本発明のシステムは、金融機関と販売者との情報交換方法によっては、サードバーティが主体となることもできる。

本実施例は、まず、ＸＸＸＸに出願された「System And Method For Automated Incoming Payment And Invoice Reconciliation」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書にさらに記述されているシステムなどの受領したすべての支払を請求書とマッチングさせるべく試みるシステムにおいて最も有用であろう。この出願の内容は、本引用により、そのすべてが本明細書に包含される。請求書の和解システムで、直接マッチングすることができなかった受領された請求書は、本発明の自動調整管理システムに委託することができる。さらに、本発明の自動調整管理システムが購入者の調整を自動的に処理できないときは、調整文書を生成し、承認の要員またはさらなる処理に回付することができる。このようなシステムは、ＸＸＸＸに出願された「System And Method For Seller-Assisted Automated Payment Processing And Exception Management」という名称の米国特許出願第ＸＸ／ＸＸＸ，ＸＸＸ号明細書に記述されている．この出願の内容は、本引用により、そのすべてが本明細書に包含される。また、本発明の実施例は、販売者の金融機関システムと直接一体化することが好ましい。

以上、本発明の特定の要素、実施例、およびアプリケーションについて図示および説明した。しかしながら、当業者であれば、以上の開示内容に鑑み、変更を加えることができるため、本発明は、これらに限定されるものではないことを理解されたい。従って、添付の請求項は、そのような変更をも含んでおり、本発明の精神および範囲内に属するそれらの特徴をも包含するものと考えられたい。

従来技術による商品購入の代表的なトランザクションを示す図である。 商品を販売するトランザクションを処理する代表的なワークフローを示す図である。 本発明の一実施例による自動調整管理システムを示す図である。 図３の調整管理アプリケーションの一実施例をさらに詳細に示す図である。 支払データ内に包含可能な情報源のいくつかのタイプの中での一例を示す図である。 本発明の一実施例によるビジネスデータフィルタの動作のフローチャートを示す図である。

Claims (26)

1. 調整を自動的に処理する方法において、
   購入者からの支払を販売者において受領する段階と、
   前記購入者に関する購入者の特定情報を、前記販売者から検索する段階であって、前記購入者の特定情報は、前記販売者への少なくとも１の未払い請求書と少なくとも１のビジネス規則とを含む段階と、
   前記支払と前記少なくとも１の未払い請求書とを比較するビジネス規則を使用する段階と、
   前記ビジネス規則の基準内で、前記支払が前記少なくとも１の未払い請求書とマッチングするときに、前記支払を処理する段階と、を含む方法。
2. 前記ビジネス規則は、前記請求書に対する購入者の特定の値引きである請求項１に記載の方法。
3. 前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定の数的な閾値である請求項１に記載の方法。
4. 前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定のパーセンテージの閾値である請求項１に記載の方法。
5. 前記ビジネス規則は、前記請求書の総額よりも少ない支払が購入者に許容される前記購入者への特定な決定である請求項１に記載の方法。
6. 前記受領段階の前に前記請求書に関する調整を受領する段階と、
   前記ビジネス規則を使用する前に前記請求書に前記調整を使用する段階と、をさらに備える請求項１に記載の方法。
7. 前記ビジネス規則の基準内で、前記支払が前記少なくとも１の未払い請求書にマッチングしないとき、前記支払を販売調整文書生成器に送信する段階を、さらに備える請求項１に記載の方法。
8. 前記支払が前記少なくとも１の未払い請求書にマッチングしないことを前記販売者に通知するために、登録データを前記販売者に送信する段階を、さらに備える請求項７に記載の方法。
9. 複数の購入者に向けて変更できるような販売者が設定可能なビジネス規則を使用することによって、販売者が支払の調整を処理するための方法であって、
   第１の購入者からの調整処理で使用するために、販売者におけるビジネス規則の第１のセットを格納する段階と、
   第２の購入者からの調整処理で使用するために、販売者におけるビジネス規則の第２のセットを格納する段階と、を含む方法において、
   前記ビジネス規則の第１のセットは、前記ビジネス規則の第２のセットとはまったく同一でないとき、
   第１の購入者から第１の支払いを前記販売者において受領する段階と、
   第２の購入者から第２の支払いを前記販売者において受領する段階であって、前記第１の支払と前記第２の支払の両方が調整を必要としている段階と、
   前記ビジネス規則の第１のセットを使用して、前記第１の支払を調整処理する段階と、
   前記ビジネス規則の第２のセットを使用して、前記第２の支払を調整処理する段階と、を備える方法。
10. 前記ビジネス規則の第１のセットと前記ビジネス規則の第２のセットとの１において、少なくとも１の前記ビジネス規則は、前記請求書に対する購入者の特定の値引きである請求項９に記載の方法。
11. 前記ビジネス規則の第１のセットと前記ビジネス規則の第２のセットとの１において、少なくとも１の前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定の数的な閾値である請求項９に記載の方法。
12. 前記ビジネス規則の第１のセットと前記ビジネス規則の第２のセットとの１において、少なくとも１の前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定のパーセンテージの閾値である請求項９に記載の方法。
13. 前記ビジネス規則の第１のセットと前記ビジネス規則の第２のセットとの１において、少なくとも１の前記ビジネス規則は、前記請求書の総額よりも少ない支払が購入者に許容される前記購入者への特定な決定である請求項９に記載の方法。
14. 前記処理がアプリケーション・サーバープロバイダー（ＡＳＰ）によって実行される請求項９記載の方法。
15. 前記処理が金融機関で実行される請求項９記載の方法。
16. 前記処理がサードパーティにアウトソースされる請求項９記載の方法。
17. 購入者から販売者に行われる支払に関する調整を自動的に処理するシステムであって、
    販売者におけるデータソースであって、購入者の支払調整を処理するときに使用するように設定された購入者特定のビジネス規則のセットを含むデータソースと、
    前記販売者から前記購入者への未払いの請求書を受領し、かつ購入者からの支払を受領するビジネスデータフィルタであって、前記支払は調整を必要としているビジネスデータフィルタと、
    前記ビジネスデータフィルタは、前記データソースから前記購入者特定のビジネス規則のセットを受領し、前記購入者特定のビジネス規則のセットを使用して、前記支払を未払いの請求書にマッチングさせることにより、前記支払を処理するシステム。
18. 前記ビジネス規則の第１のセットと前記ビジネス規則の第２のセットとの１において、少なくとも１の前記ビジネス規則は、前記請求書に対する購入者の特定の値引きである請求項１７に記載のシステム。
19. 少なくとも１の前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定の数的な閾値である請求項１７に記載のシステム。
20. 少なくとも１の前記ビジネス規則は、前記支払と前記請求書との額の差に対する購入者特定のパーセンテージの閾値である請求項１７に記載のシステム。
21. 少なくとも１の前記ビジネス規則は、前記請求書の総額よりも少ない支払が購入者に許容される前記購入者への特定な決定である請求項１７に記載のシステム。
22. 購入者から販売者に行われる支払に関する調整を自動的に処理するシステムであって、
    販売者におけるデータソースであって、購入者の支払調整を処理するときに使用するように設定された購入者特定のビジネス規則のセットを含むデータソースと、
    前記販売者から前記購入者への未払い請求書を受領し、かつ購入者からの支払を受領するビジネスデータフィルタであって、前記支払は調整を必要としているビジネスデータフィルタと、を含むシステムにおいて、
    前記ビジネスデータフィルタは、前記データソースから前記購入者特定のビジネス規則のセットを受領し、前記購入者特定のビジネス規則のセットを使用して、前記支払を未払い請求書にマッチングさせることにより、前記支払を処理するビジネスデータフィルタであって、
    前記ビジネスデータフィルタが、アプリケーション・サーバープロバイダー（ＡＳＰ）であるシステム。
23. 購入者から販売者に行われる支払に関する調整を自動的に処理するシステムであって、
    販売者におけるデータソースであって、購入者の支払調整を処理するときに使用するように設定された購入者特定のビジネス規則のセットを含むデータソースと、
    前記販売者から前記購入者への未払い請求書を受領し、かつ購入者からの支払を受領するビジネスデータフィルタであって、前記支払は調整を必要としているビジネスデータフィルタと、を含むシステムにおいて、
    前記ビジネスデータフィルタは、前記データソースから前記購入者特定のビジネス規則のセットを受領し、前記購入者特定のビジネス規則のセットを使用して、前記支払を未払い請求書にマッチングさせることにより、前記支払を処理するビジネスデータフィルタであって、
    前記ビジネスデータフィルタは、金融機関におけるソフトウェア・アプリケーションであるシステム。
24. 調整を自動的に処理する方法であって、
    購入者からの支払を販売者において受領する段階と、
    前記購入者に関する購入者の特定情報を、前記販売者から検索する段階であって、前記購入者の特定情報は、前記販売者への少なくとも１の未払い請求書と少なくとも１のビジネス規則とを含む段階と、
    前記支払と前記少なくとも１の未払い請求書とを比較するビジネス規則を使用する段階と、
    前記ビジネス規則の基準内で、前記支払が前記少なくとも１の未払い請求書とマッチングするときに、前記支払を処理する段階と、を含む方法おいて、
    前記処理が、アプリケーション・サーバープロバイダー（ＡＳＰ）によって実行される方法。
25. 調整を自動的に処理する方法であって、
    購入者からの支払を販売者において受領する段階と、
    前記購入者に関する購入者の特定情報を、前記販売者から検索する段階であって、前記購入者の特定情報は、前記販売者への少なくとも１の未払い請求書と少なくとも１のビジネス規則とを含む段階と、
    前記支払と前記少なくとも１の未払い請求書とを比較するビジネス規則を使用する段階と、
    前記ビジネス規則の基準内で、前記支払が前記少なくとも１の未払い請求書とマッチングするときに、前記支払を処理する段階と、を含む方法おいて、
    前記処理が、金融機関においてソフトウェア・アプリケーションによって実行される方法。
26. 調整を自動的に処理する方法であって、
    購入者からの支払を販売者において受領する段階と、
    前記購入者に関する購入者の特定情報を、前記販売者から検索する段階であって、前記購入者の特定情報は、前記販売者への少なくとも１の未払い請求書と少なくとも１のビジネス規則とを含む段階と、
    前記支払と前記少なくとも１の未払い請求書とを比較するビジネス規則を使用する段階と、
    前記ビジネス規則の基準内で、前記支払が前記少なくとも１の未払い請求書とマッチングするときに、前記支払を処理する段階と、を含む方法おいて、
    前記処理が、サードパーティにアウトソーシングされたソフトウェアによって実行される方法。

Images