JP2019191916A

JP2019191916A - 取引管理システム、及び取引管理方法

Info

Publication number: JP2019191916A
Application number: JP2018083794A
Authority: JP
Inventors: 元徳広田; Motonori Hirota
Original assignee: Individual
Current assignee: Individual
Priority date: 2018-04-25
Filing date: 2018-04-25
Publication date: 2019-10-31
Anticipated expiration: 2038-04-25
Also published as: JP6562484B1

Abstract

【課題】売掛金を現金化する際に、煩雑な手続を必要とせず、売掛金の現金化の有無、タイミング、金額の指定を柔軟に行うことができる取引管理システムを提供することにある。【解決手段】取引管理サーバ３０は、取引先企業端末２０から受信した、商品等の納品等に関する取引情報に基づいて取引管理テーブル３６３を更新し、さらに、その取引管理テーブル３６３等に基づいて早期払い上限額を決定し、商品等提供者端末１０から早期払いリクエストを受信した場合に、早期払い上限額の範囲で商品等提供者の預金口座に早期払い額を支払うよう指示する。【選択図】図７

Description

この発明は、ファクタリングを利用した取引等を管理する取引管理システムに関する。

企業が資金を調達するために、ファクタリングを利用する場合がある。ファクタリングとは、企業における未回収の売掛金をファクタリング会社が買い取る仕組みであり、この仕組みによって、企業は、売掛金を早期に現金化することができる。

一般的に、ＢｔｏＢ取引は、掛取引（すなわち、代金決済を商品等の受け渡し時点ではなく、将来のある期日に行うことを約束して売買する信用取引）であり、商品やサービスを提供する企業が商品やサービスの提供を行ってから、提供先の企業がその商品・サービスに対する報酬を支払うまでに、例えば、１ヶ月から３ヶ月といった長い期間を要する場合が多い。

また、商品やサービスを提供する企業は、商品・サービスの提供に至るまでにすでにその商品・サービスに係る投資を行っており、その点を考慮すると、商品・サービスに投入された資金を回収し利益を生じるまでの期間は、より長い期間であると言える。

商品やサービスを提供する企業にとっては、商品・サービスに投入された資金をできるだけ早く回収することが、資金繰りの正常化につながる。

上記のファクタリングは、このような場合に、売掛金を早期に現金化し、資金繰りを安定化させることができる。ただし、このファクタリングでは、ファクタリング会社が、取引先の売掛債務を一定期間、立て替える構造となるため、商品やサービスを提供する企業は、取引先の信用リスク等に応じて、ファクタリング手数料を負担することになる。

特許文献１では、ファクタリングの管理をシステム化し、各グループ会社の債権譲渡に関する債権者管理の一元化を図るためのファクタリング管理装置が開示されている。このファクタリング管理装置は、債権譲渡にかかる債権者の情報処理端末装置から債権譲渡代金の情報を受信し、受信したその債権譲渡代金の情報に基づいて、グループ会社ごとに設けられたゼロバランス決済口座から、所定の金額を出金するように構成される。

特開２００３−１０８７８４号公報

しかしながら、上述した従来のファクタリングでは、ファクタリング会社が売掛債権を買い取る際に、商品やサービスを提供する企業が、各取引の成立を証明するために、個別に一定の書類を用意してファクタリング会社に提示する必要があり、ファクタリングの当事者に煩雑な手続を強いることになる。

また、商品やサービスを提供する企業においては、資金繰りの状況等によって、早期の現金化を必要としない売掛金もあり、また、指定したタイミングで現金化したい場合もある。さらに、一取引の売掛金の一部についてだけ現金化したい場合や、複数の取引の売掛金についてまとめて現金化したい場合もある。しかしながら、従来のファクタリングや上記の特許文献１のファクタリング管理装置では、このような現金化の有無、タイミング、金額の指定を柔軟に行うことができる仕組みが存在しない。

また、ファクタリング会社を介さずに（ファクタリングを用いずに）、商品やサービスを提供する企業が、指定したタイミングで所望の金額を現金化したい場合に、当該タイミングで取引先から入金を行わせるようにすることができる仕組みが存在しない。

したがって、本発明の目的は、売掛金をファクタリングによって現金化する際に、煩雑な手続を必要とせず、売掛金の現金化の有無、タイミング、金額の指定を柔軟に行うことができる取引管理システムを提供することにある。

また、本発明の更なる目的は、売掛金をファクタリングを用いずに現金化する（指定したタイミングで所望の金額を取引先から入金させる）際に、煩雑な手続を必要とせず、売掛金の現金化の有無、タイミング、金額の指定を柔軟に行うことができる取引管理システムを提供することにある。

本発明の第１の実施態様に係る発明は、下記の構成を有する。
第１ユーザ（商品等提供者によるサービスを受ける「取引先企業」）と第２ユーザ（商品やサービスを提供する「商品等提供者」）との間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理手段は、前記所定金額を前記第２ユーザに支払う場合に、前記第２ユーザが負担する手数料の金額を決定し、
前記手数料の金額は、前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されるよう構成される。

本発明のこのような構成によって、第２ユーザは、簡単なコンピュータの操作によって、必要なタイミングで、必要な分だけ売掛金の現金化を指示することができ、さらに、第２ユーザは、早期払いリクエストのタイミングにより、徴収される手数料の額を調整することができ、結果的に、売掛債権にかかる資金調達コストを柔軟にコントロールすることができる。例えば、手数料（システム利用手数料）は、早期払いリクエスト等のタイミングが、本来の支払期日に近いほど低い割合に設定される。

本発明の第２の実施態様に係る発明は、第１の実施態様において下記の構成を有する。
前記リクエスト管理手段は、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されるように構成される。

本発明のこのような構成によって、第２ユーザは、新たな取引や新たな早期払いの依頼によって状況が変化した場合でも、早期払いリクエストにより早期払いが可能な金額を容易に把握することができる。また、早期払いが可能な金額が、早期払いリクエスト等のタイミング等によって変動し、状況に応じて速やかに更新されるよう管理される。例えば、第１ユーザに商品等が納品されたり、取引が第１ユーザにおいて確定した場合に、その納品や確定に応じて、取引の代金の所定割合がそれぞれ上限額に加算される。また、こうした納品と確定とで、上記の所定割合が別個に設定されうる。

本発明の第３の実施態様に係る発明は、第１又は第２の実施態様において下記の構成を有する。
前記リクエスト管理手段は、
前記取引を、その納品日又は確定日に基づいて所定期間の単位にまとめて、前記所定期間ごとの早期払い可能額を算出し、
前記早期払い可能額を表示するための表示データを、前記第２ユーザによる前記コンピュータの操作に応じて、前記コンピュータに送信するように構成される。

本発明のこのような構成によって、第２ユーザは、簡単なコンピュータの操作によって、所定期間ごと（例えば、月ごと）の早期払い可能額を容易に認識することができる。

本発明の第４の実施態様に係る発明は、第１ないし第３のいずれかの実施態様において下記の構成を有する。
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われるように構成される。

本発明のこのような構成によって、第２ユーザは、簡単なコンピュータの操作によって、必要なタイミングで、所定事業者（例えば、ファクタリング会社）に必要な分だけ売掛金の現金化を指示することができる。

本発明の第５の実施態様に係る発明は、下記の構成を有する。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理ステップは、前記所定金額を前記第２ユーザに支払う場合に、前記第２ユーザが負担する手数料の金額を決定し、
前記手数料の金額は、前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されるように構成される。

本発明の第６の実施態様に係る発明は、下記の構成を有する。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理手段は、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されるように構成される。

本発明のこのような構成によって、第２ユーザは、簡単なコンピュータの操作によって、必要なタイミングで、必要な分だけ売掛金の現金化を指示することができる。また、早期払いが可能な金額が、早期払いリクエスト等のタイミング等によって変動し、状況に応じて速やかに更新されるよう管理される。

本発明の第７の実施態様に係る発明は、下記の構成を有する。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理ステップは、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されるように構成される。

本発明の第８の実施態様に係る発明は、下記の構成を有する。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われるように構成される。

本発明のこのような構成によって、第２ユーザは、簡単なコンピュータの操作によって、必要なタイミングで、必要な分だけ、所定事業者（例えば、ファクタリング会社）に売掛金の現金化を指示することができる。

本発明の第９の実施態様に係る発明は、下記の構成を有する。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われるように構成される。

本発明に係る取引管理システムによって、商品等を提供する事業者は、簡単なコンピュータの操作によって、必要なタイミングで、必要な分だけ売掛金の現金化を指示することができる。また、商品等を提供する事業者のキャッシュフローが改善され、新たな企画や開発への投資を積極的に行うことが期待できる。

また、商品等の提供を受ける事業者は、取引管理システムを利用することで、大きな資金負担をすることなく、取引相手に対するサービスを向上することができ、結果として、このことが競合他社との差別化になり、有望な取引相手を多く取り込むことが期待できる。また、商品等の提供を受ける事業者は、資金に余裕がある場合であっても、取引管理システムを利用することで、容易に、取引相手に対して売掛金の早期現金化を提供することができる。

商品・サービスの提供に関する代金支払方法を説明するための概略図である。商品・サービスの提供に関する代金支払いのタイミングを示す概略図である。商品・サービスの提供に関する代金支払いのタイミングを示す概略図である。ファクタリング会社を利用した、商品・サービスの提供に関する従来の代金支払方法を説明するための概略図である。ファクタリング会社を利用した、商品・サービスの提供に関する従来の代金支払いのタイミングを示す概略図である。ファクタリング会社を利用した、商品・サービスの提供に関する従来の代金支払いのタイミングを示す概略図である。本発明の第１実施形態に係る、ファクタリング会社を利用した、商品・サービスの提供と支払いに関する取引管理システムの概要を示す概略図である。本発明の第１実施形態に係る取引管理システムの商品等提供者端末のハードウェア構成の例を示す略線図である。本発明の第１実施形態に係る取引管理システムの取引管理サーバのハードウェア構成の例を示す略線図である。本発明の第１実施形態に係る取引管理システムの商品等提供者端末の機能ブロック図である。本発明の第１実施形態に係る取引管理システムの取引先企業端末の機能ブロック図である。本発明の第１実施形態に係る取引管理システムの取引管理サーバの機能ブロック図である。本発明の第１実施形態に係る取引管理システムのテーブルの例を示す略線図である。本発明の第１実施形態に係る取引管理システムのテーブルの例を示す略線図である。本発明の第１実施形態に係る取引管理システムのテーブルの例を示す略線図である。本発明の第１実施形態に係る取引管理システムにおける納品時処理の手順を表すフローチャートである。本発明の第１実施形態に係る取引管理システムにおける確定時処理の手順を表すフローチャートである。本発明の第１実施形態に係る取引管理システムにおける早期払いリクエスト処理の手順を表すフローチャートである。本発明の第１実施形態に係る取引管理システムにおける月次処理の手順を表すフローチャートである。本発明の第１実施形態に係る取引管理システムにおける、商品・サービスの提供に関する代金支払いと早期払いのタイミングを示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品・サービスの提供に関する代金支払いと早期払いの一例を示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品等提供者端末の表示画面を示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品等提供者端末の表示画面を示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品・サービスの提供に関する代金支払いと早期払いのタイミングを示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品・サービスの提供に関する代金支払いと早期払いのタイミングを示す概略図である。本発明の第１実施形態に係る取引管理システムにおける、商品等提供者端末の表示画面を示す概略図である。本発明の第２実施形態に係る、ファクタリング会社を利用した、商品・サービスの提供と支払いに関する取引管理システムの概要を示す概略図である。本発明の第２実施形態に係る取引管理システムの商品等提供者端末の機能ブロック図である。本発明の第２実施形態に係る取引管理システムの取引先企業端末の機能ブロック図である。本発明の第２実施形態に係る取引管理システムの取引管理サーバの機能ブロック図である。本発明の第２実施形態に係る取引管理システムのテーブルの例を示す略線図である。本発明の第２実施形態に係る取引管理システムのテーブルの例を示す略線図である。本発明の第２実施形態に係る取引管理システムにおける納品時処理の手順を表すフローチャートである。本発明の第２実施形態に係る取引管理システムにおける確定時処理の手順を表すフローチャートである。本発明の第２実施形態に係る取引管理システムにおける早期払いリクエスト処理の手順を表すフローチャートである。本発明の第２実施形態に係る取引管理システムにおける月次処理の手順を表すフローチャートである。本発明の第３実施形態に係る、商品・サービスの提供と支払いに関する取引管理システムの概要を示す概略図である。本発明の第３実施形態に係る取引管理システムにおける、商品・サービスの提供に関する代金支払いと早期払いのタイミングを示す概略図である。

最初に、従来の基本的な企業間商取引（ＢｔｏＢ取引）の構成を、図１を参照して説明する。本明細書では、商品やサービスを提供する企業等を「商品等提供者」と称し、商品等提供者から商品を購入し、又は商品等提供者によるサービスを受ける企業等を「取引先企業」と称する。商品やサービスには、取引の対象となるすべての物・労務が含まれる。なお、商品等提供者や取引先企業は、法人に限られず、個人や他の組織を含むものである。

商品としては、完成品のほか部品等も含まれる。例えば、取引先企業が家電量販店などの小売業であれば、商品等提供者（メーカー）から完成品を仕入れて顧客に販売し、取引先企業が製造業であれば、商品等提供者から原材料や部品を仕入れて加工・組み立てを行い、完成品や半製品を製造する。

図１に示すように、商品等提供者が取引先企業に対して商品・サービスを提供すると、その商品・サービスの提供を受けた取引先企業において、当該商品等提供者に対する債務が発生し、一方、商品等提供者において売掛金が発生する。その後、取引先企業は、所定のタイミングで、商品等提供者に対して商品・サービスの代金（報酬）支払いを行う。代金支払いは、例えば、商品等提供者の預金口座への振込というかたちで実現される。

図２Ａには、商品等提供者による商品の納品と、取引先企業による当該商品の代金支払いのタイミングの一般的な一例が示されている。この例では、取引先企業が、商品等提供者による商品の納品が行われた日の月末を締日として設定し、その締日の翌月末に、その商品の代金を商品等提供者に支払うようにしている。例えば、商品等提供者が、１月（当月）１０日と２０日にそれぞれ商品を納品した場合、これらの納品に係る商品の代金が締日（１月末）で集計され、集計された代金が２月（翌月）末に支払われる。

図２Ｂには、商品等提供者による商品の納品と、取引先企業による当該商品の代金支払いのタイミングの他の例が示されている。この例では、取引先企業が、商品等提供者による商品の納品が行われた場合に、その商品に関する取引が確定した日（確定日）の月末を締日として設定し、その締日の翌月末に、その商品の代金を商品等提供者に支払うようにしている。なお、確定日は、納品された商品の検収を行って、その商品の品質が認められた日や、形式的に納品の１月後とするなど、様々な方法により決定されうる。ここでは、納品の翌月の応答日を確定日としている。例えば、商品等提供者が、１月（当月）１０日と２０日にそれぞれ商品を納品した場合、これらの納品が確定する日がそれぞれ２月（翌月）１０日、２０日となり、こうして確定した商品の代金が締日（２月末）で集計され、集計された代金が３月（翌々月）末に支払われる。

図３には、取引先企業による商品の取引確定のタイミングと当該商品の代金支払いのタイミングの一例が示されている。この例では、取引先企業が、商品等提供者による商品の納品タイミングとは別に、商品に関する取引が確定した日（確定日）を設定し、確定日が決定された場合に、その確定日の月末を締日として設定し、その締日の翌々月１５日に、その商品の代金を商品等提供者に支払うようにしている（したがって、この場合、商品が納品されたタイミングは、商品の代金支払いのタイミングには影響しない）。例えば、商品等提供者の納品した商品の確定日が、１月（当月）１２日と１９日である場合、これらの商品の代金が締日（１月末）で集計され、集計された代金が３月（翌々月）１５日に支払われる。さらに、商品等提供者の納品した商品の確定日が、２月１０日と２２日である場合、これらの商品の代金が締日で集計され、集計された代金が４月１５日に支払われる。

図２、及び図３に示したように、商品等提供者は、商品を納品してからその商品の代金を受け取るまでに少なくとも１ヶ月以上かかっており、その期間は、２ヶ月〜４ヶ月といった期間であることも珍しくない。商品等提供者は、納品する商品を完成させるまでに原材料費や人件費等をすでに負担しており、そのような費用負担の時点から、それらの費用を回収し、さらに利益を得るまでに必要な期間が極めて長いことがわかる（このような問題は、サービスを提供する商品等提供者も同じである）。商品等提供者においては、様々な事情により、納品した商品等の代金を早急に回収する必要に迫られる場合があるが、そのような場合に、後述するファクタリング企業を利用して、早期に売掛金を回収することができる。

図４には、ファクタリング企業を利用した、従来の基本的な企業間商取引（ＢｔｏＢ取引）の構成が示されている。図４は、従来の３社間ファクタリングの構成を示すものである。ファクタリング企業は、商品等提供者から売掛債務（売掛金）を買い取り、取引先企業から（支払期日に）当該売掛債務に基づいて商品・サービスの代金を受領する。

３社間ファクタリングは、図４に示すように、商品等提供者、取引先企業、及びファクタリング会社の３社で、ファクタリング取引に関する事前合意を行い、契約書を取り交わすものである。なお、商品等提供者、及びファクタリング会社の２社で、ファクタリング取引に関する合意を行う２社間ファクタリングという仕組みも存在する。２者間ファクタリングでは、ファクタリング企業が、商品等提供者から売掛債務（売掛金）を買い取り、取引先企業から（支払期日に）商品等提供者に支払いが行われた場合に、その支払代金をファクタリング企業から受領する。

３社間ファクタリングでは、商品等提供者は、早期に売掛債務（売掛金）を現金化できるが、売掛債務をファクタリング会社に売却する際、ファクタリング手数料が差し引かれるので、当然ながら、ファクタリング会社から受領する額は、支払期日に取引先企業から支払われる代金よりも少ないものとなる。

図４を参照すると、３社間でファクタリング取引に関する合意がされた状況で、最初に、商品等提供者が、取引先企業に対して商品・サービスを提供すると、その商品・サービスの提供を受けた取引先企業において、当該商品等提供者に対する債務が発生し、一方、商品等提供者において売掛金が発生する。

ここで、商品等提供者は、売掛債務をファクタリング会社に売却し、ファクタリング会社から商品等提供者の預金口座には、当該売掛債務の買取代金（ファクタリング手数料減算後の金額）が送金される。このような売掛債務の売却は、商品等提供者による納品と同時、又は直後でもよいし、契約等で取引先企業の確認が必要とされる場合は、その確認の後に行われるようにしてもよい。

この場合、例えば、商品等提供者からファクタリング会社に、商品・サービスの提供に係る納品確認書、納品証明書、発注書、納品書、又は請求書等を送付するようにし、これらの書類に基づいて、ファクタリング会社が商品等提供者の預金口座に送金を行うようにしてもよい。これらの手続は、契約書の規定に従う。

その後、本来の支払期日に、取引先企業からファクタリング会社に、商品・サービスの代金が支払われる。例えば、取引先企業からファクタリング会社の預金口座に代金の振り込みが行われる。

このようなファクタリングのスキームによって、商品等提供者は、ファクタリング手数料を負担する必要はあるものの、売掛金をいち早く現金化することができ、キャッシュフローの適正化を図ることができる。一方、ファクタリング会社は、商品等提供者の売掛債務に基づいて現金を立て替えるものであり、その後の取引先企業による代金支払が行われないというリスクと金利を考慮して、ファクタリング手数料が設定される。

図５Ａは、図２Ａに示した商品の納品と代金支払いにおいて、上記の３社間ファクタリングを提供した状況を示している。商品等提供者が、１月（当月）１０日に商品を納品した場合、翌日の１１日にファクタリング会社に売掛債権の譲渡が行われ、同日にファクタリング会社から商品等提供者に、納品した商品の代金に対応する資金が提供される。また、このとき、商品等提供者からファクタリング会社に対して、売掛債権の存在と金額を証明するための書類（例えば、商品・サービスの提供に係る納品確定書等（図５Ａの「Ｄ」））が送付される。

同様に、商品等提供者が、１月（当月）２０日に商品を納品した場合、翌日の２１日にファクタリング会社に売掛債権の譲渡が行われ、同日にファクタリング会社から商品等提供者に、納品した商品の代金に対応する資金が提供される。また、このとき、商品等提供者からファクタリング会社に対して、商品の納品が行われ、売掛債権の存在と金額を証明するための書類（例えば、商品・サービスの提供に係る納品確定書等（図５Ａの「Ｄ」））が送付される。

このように、３社間ファクタリングを利用することによって、商品等提供者は、納品した商品に係る代金に対応する資金を、本来の支払期日より前に回収することができる。

図５Ｂは、図２Ｂに示した商品の納品、確定と代金支払いにおいて、上記の３社間ファクタリングを提供した状況を示している。商品等提供者が、１月（当月）１０日に商品を納品した場合、翌日の１１日にファクタリング会社に売掛債権の譲渡が行われ、同日にファクタリング会社から商品等提供者に、納品した商品の代金に対応する資金が提供される。また、このとき、商品等提供者からファクタリング会社に対して、売掛債権の存在と金額を証明するための書類（例えば、商品・サービスの提供に係る納品確定書等（図５Ｂの「Ｄ」））が送付される。

このように、３社間ファクタリングを利用することによって、商品等提供者は、納品した商品に係る代金に対応する資金を、その商品の確定日に関わらず、本来の支払期日より前に回収することができる。

図６は、図３に示した商品の確定と代金支払いにおいて、上記の３社間ファクタリングを提供した状況を示している。商品等提供者の納品した商品の確定日が、１月（当月）１２日である場合、翌日の１３日にファクタリング会社に売掛債権の譲渡が行われ、同日にファクタリング会社から商品等提供者に、確定した商品の代金に対応する資金が提供される。また、このとき、商品等提供者からファクタリング会社に対して、売掛債権の存在と金額を証明するための書類（例えば、商品・サービスの提供に係る納品確定書等（図６の「Ｄ」））が送付される。

同様に、商品等提供者の納品した商品の確定日が、１月（当月）１９日である場合、翌日の２０日にファクタリング会社に売掛債権の譲渡が行われ、同日にファクタリング会社から商品等提供者に、確定した商品の代金に対応する資金が提供される。また、このとき、商品等提供者からファクタリング会社に対して、売掛債権の存在と金額を証明するための書類（例えば、商品・サービスの提供に係る納品確定書等（図６の「Ｄ」））が送付される。

このように、３社間ファクタリングを利用することによって、商品等提供者は、納品した商品に係る代金に対応する資金を、本来の支払期日より前に（その商品の確定日の後）、回収することができる。

図７は、本発明の第１実施形態の取引管理システムの概要を表している。図７に示す本発明の第１実施形態に係る取引管理システム１では、商品等提供者が、自身の納品した商品等の代金に基づいて、一定額を、（取引先企業による）本来の支払期日より前に（３社間ファクタリングの仕組みにより）受領できるよう依頼することができる。本明細書では、このような、本来の支払期日より前の、商品等提供者に対する支払いを「早期払い」と称する。また、商品等提供者による早期払いのための、取引管理システム１に対する依頼を「早期払いリクエスト」と称する。

図７に示す取引管理システム１は、商品等提供者が利用する商品等提供者端末１０、取引先企業により運営・管理される取引先企業端末２０、及びファクタリング会社により運営・管理される取引管理サーバ３０を含む。なお、ここでは、便宜上、取引管理システム１が、上記の商品等提供者端末１０、取引先企業端末２０、及び取引管理サーバ３０を含むものとして説明するが、取引管理システム１を、商品等提供者端末１０や取引先企業端末２０を含まないように構成することもできる。

商品等提供者、取引先企業、及びファクタリング会社の３社は、上述した３社間ファクタリングの当事者であり、基本的に、ファクタリング取引に関する合意を行い、相互に契約書を取り交わしていることを前提とする。

取引先企業が、商品等提供者から商品等の納品を受け付けた場合、ユーザ（取引先企業）が、取引先企業端末２０を操作することにより、その商品に係る取引情報（納品された商品等の納品日や代金）が取引管理サーバ３０に送信される。また、商品等提供者から納品された商品等の受け入れが、取引先企業において確定した場合（すなわち、取引が確定した場合）、取引先企業のユーザが、取引先企業端末２０を操作することにより、その商品に係る取引情報（納品された商品等の確定日や代金）が取引管理サーバ３０に送信される。なお、商品等が納品された場合、又は商品等の受け入れが確定した場合のどちらかで、取引情報が取引管理サーバ３０に送信されるようにしてもよい。また、こうした取引情報、又は取引情報の元となる情報は、商品等提供者端末１０から送信されるようにしてもよい。商品等提供者端末１０から送信される取引情報等は、例えば、取引先企業から承認された情報である。

取引管理サーバ３０は、取引先企業端末２０から受信した取引情報等に基づいて、商品等提供者に支払い可能な早期払い額を計算し、又さらに、取引先企業に請求する請求額を計算する。

商品等提供者は、商品等提供者端末１０を操作し、必要に応じて、早期払いリクエストを取引管理サーバ３０に送信する。取引管理サーバ３０は、早期払いリクエストを受信すると、当該リクエストに基づいて決済処理を行う。この決済処理は、例えば、ファクタリング会社の預金口座から商品等提供者の預金口座にリクエストされた金額を振り込むよう、所定のサーバに早期払い依頼のメッセージを送信する。また、早期払いの残金があれば、本来の支払期日に決済処理を行う。例えば、その残金を商品等提供者の預金口座に振り込むよう、所定のサーバに通常払い依頼のメッセージを送信する。

さらに、取引管理サーバ３０は、本来の支払期日に、商品等の代金請求に係るメッセージを取引先企業端末２０に送信する。取引先企業端末２０は（又は、取引先企業の事務処理等により）、取引管理サーバ３０からの商品等の代金請求に応じて決済処理を行う。例えば、取引先企業の預金口座からファクタリング会社の預金口座に請求された金額を振り込むよう、所定のサーバに商品等代金支払い依頼のメッセージを送信する。

なお、図７では、説明の便宜上、同じ金融機関に商品等提供者、取引先企業、及びファクタリング会社の預金口座が存在するように表記したが、預金口座は、それぞれ異なる金融機関であってもよい。また、決済方法についても、口座間振替以外の様々な方法を選択することができる。

また、図７では、ファクタリング会社が取引管理サーバ３０を運営・管理するようになっているが、ファクタリング会社の業務を委託・代行するかたちで、他社が取引管理サーバ３０を運営・管理してもよく、その他、取引管理サーバ３０について様々な運営形態をとることができる。

次に、図８を参照して、商品等提供者端末１０のハードウェア構成の例について説明する。取引先企業端末２０も、図８に示すも構成の端末を使用することができる。また、図８の構成は、スマートフォンのような携帯機器の代表的構成を例示したにすぎない。パーソナルコンピュータなどを含む、他の様々なコンピュータを商品等提供者端末１０、取引先企業端末２０として利用することができる。

商品等提供者端末１０は、ＣＰＵ（Central Processing Unit）１０１、メモリ１０２、カメラ１０３、ＧＰＳ制御部１０４、ＧＰＳ用アンテナ１０５、無線信号処理部１０６、無線通信用アンテナ１０７、オーディオ制御部１０８、マイクロフォン１０９、スピーカ１１０、ディスプレイ制御部１１１、入力機器インタフェース１１２、タッチスクリーン１１３、非接触ＩＣカードリーダ／ライタ１１４、センサー１１５、補助記憶装置１１６、及び外部記録媒体インタフェース１１７を含んでいる。

ＣＰＵ１０１は、商品等提供者端末１０の各構成要素の動作を制御し、ＯＳの制御下で、各機能を実行する。

メモリ１０２は通常ＲＡＭ（Random Access Memory）で構成される。メモリ１０２には、ＣＰＵ１０１で実行される各機能を実現するためのプログラムが実行時にロードされ、当該プログラムに必要なデータ等が一時的に記憶される。

カメラ１０３は、商品等提供者端末１０に内蔵される小型の撮像装置で、撮像素子がＣＣＤやＣＭＯＳといったタイプのものがある。

ＧＰＳ制御部１０４は、ＧＰＳ用アンテナ１０５を介して、複数のＧＰＳから信号を受信し、商品等提供者端末１０の位置を特定する。こうして求められた位置情報は、後述する補助記憶装置１１６等に記憶され、必要に応じてプログラムで利用される。

無線信号処理部１０６は、無線通信用アンテナ１０７を介して携帯電話基地局と通信を行い、他の機器との間での通話データの送受信や、（インターネットを介した）他端末との間でのＷＥＢページやメールデータの送受信を制御する。また、無線信号処理部１０６は、無線通信用アンテナ１０７を用いて無線ＬＡＮアクセスポイントとの間で無線ＬＡＮによる通信を実現し、インターネット経由のデータ送受信を行う（ここでは、便宜上、無線信号処理部１０６と無線通信用アンテナ１０７が、携帯電話基地局との間の無線通信及び無線ＬＡＮアクセスポイントとの間の無線通信を行うものとした）。

オーディオ制御部１０８は、マイクロフォン１０９とスピーカ１１０を制御して無線通信による通話を実現し、一方で、アプリケーションにおいて動画や音楽を再生する場合に、音声を出力するよう制御する。

タッチスクリーン１１３は、例えば、ＬＣＤ（Liquid Crystal Display）などで構成される表示装置で、情報を表示するとともに、ユーザが指などで画面表面をタッチした（押した）位置を、抵抗膜方式や静電容量方式などのタッチセンサーで検知する。ディスプレイ制御部１１１は、ＣＰＵ１０１が発行する描画データを処理して、例えば、ＷＥＢページや動画等を、タッチスクリーン１１３の表示装置に出力する。入力機器インタフェース１１２は、タッチスクリーン１１３のタッチセンサーが、ユーザによる操作を検知し、これを所定の信号としてＣＰＵ１０１に送信する。

非接触ＩＣカードリーダ／ライタ１１４は、非接触ＩＣチップが埋め込まれたカードが商品等提供者端末１０の所定の位置にかざされた場合に、ＣＰＵ１０１の指令に基づいて、そのＩＣチップに記憶されているデータを読み取り、又は、ＩＣチップに所定のデータを書き込む。

センサー１１５は、タッチスクリーン１１３のタッチセンサー以外のセンサーであり、モーションセンサー、光センサー、近接センサーなどがある。

補助記憶装置１１６は、例えば、フラッシュメモリと呼ばれる半導体メモリやハードディスクで構成される。補助記憶装置１１６は、ＣＰＵ１０１で実行される各機能を実現するためのプログラムを記憶するほか、各種データを記憶する。

外部記録媒体インタフェース１１７は、外部記録媒体１２０にアクセスして、そこに記録されているデータを読み取る。外部記録媒体１２０は、例えば、可搬型のフラッシュメモリである。ＣＰＵ１０１で実行され本発明の各機能を実現するためのプログラムは、この外部記録媒体インタフェース１１７や、前述したような、無線信号処理部１０６及び無線通信用アンテナ１０７を介した携帯電話網やネットワークを経由して商品等提供者端末１０に提供される。

なお、商品等提供者端末１０がパーソナルコンピュータ等のコンピュータであれば、外部ネットワークに接続するためのネットワークインタフェースが追加され、ディスプレイ制御部１１１には、ＬＣＤ等からなる組み込み型又は別筐体の表示装置が接続され、入力機器インタフェース１１２には、キーボードやマウスが接続される。

次に、図９を参照して、取引管理サーバ３０のハードウェア構成の例について説明する。ただし、図９の取引管理サーバ３０は、一般的なサーバコンピュータについての代表的な構成を例示したにすぎない。他の様々なコンピュータを取引管理サーバ３０として利用することができる。

取引管理サーバ３０は、ＣＰＵ３０１、メモリ３０２、ネットワークインタフェース３０３、ディスプレイコントローラ３０４、ディスプレイ３０５、入力機器インタフェース３０６、キーボード３０７、マウス３０８、外部記憶装置３０９、及び外部記録媒体駆動装置３１０を含んでいる。

ＣＰＵ３０１は、取引管理サーバ３０の各構成要素の動作を制御し、ＯＳの制御下で、各機能を実行する。

メモリ３０２は通常、不揮発性メモリであるＲＯＭ（Read Only Memory）、及び揮発性メモリであるＲＡＭ（Random Access Memory）から構成される。ＲＯＭには、取引管理サーバ３０の起動時に実行されるプログラム等が格納される。ＲＡＭには、ＣＰＵ３０１で実行されるプログラムや、それらのプログラムが実行中に使用するデータ等が一時的に格納される。

ネットワークインタフェース３０３は、ネットワーク３２０に接続するためのインタフェースである。ネットワーク３２０は、例えば、無線通信ネットワーク、及びインターネットを含むネットワークである。

ディスプレイコントローラ３０４は、ＣＰＵ３０１が発行する描画命令を実際に処理するための専用コントローラである。ディスプレイコントローラ３０４で処理された描画データは、一旦グラフィックメモリに書き込まれ、その後、ディスプレイ３０５に出力される。ディスプレイ３０５は、例えば、ＬＣＤ（Liquid Crystal Display）で構成される表示装置である。

入力機器インタフェース３０６は、キーボード３０７やマウス３０８から入力された信号を受信して、その信号パターンに応じて所定の指令をＣＰＵ３０１に送信する。

外部記憶装置３０９は、例えば、ハードディスクドライブ（ＨＤＤ）のような記憶装置であり、この装置内には上述したプログラムやデータが記録され、実行時に、必要に応じてそこからメモリ３０２のＲＡＭにロードされる。

外部記録媒体駆動装置３１０は、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）などの可搬型の外部記録媒体３３０の記録面にアクセスして、そこに記録されているデータを読み取る装置である。外部記録媒体３３０には、本発明に係る取引管理方法を実現するためのプログラムを記録することが可能である。外部記録媒体３３０に記録されているデータは、外部記録媒体駆動装置３１０を介して外部記憶装置３０９に格納され、プログラムであれば、実行時にメモリ３０２のＲＡＭにロードされる。

なお、取引管理サーバ３０では、管理者等による操作の必要がない場合や、リモート接続によって操作される場合は、上述したディスプレイコントローラ３０４、ディスプレイ３０５、入力機器インタフェース３０６、キーボード３０７、及びマウス３０８は不要である。

次に、図１０の機能ブロック図を参照して、本発明の第１実施形態に係る取引管理システム１における商品等提供者端末１０の機能の概要について説明する。図１０に示すように、商品等提供者端末１０は、アクセス制御部１５１、早期払い情報表示制御部１５２、早期払いリクエスト送信部１５３、入出力制御部１５４、及びネットワークＩ／Ｆ部１５５を含んでいる。

アクセス制御部１５１は、商品等提供者端末１０を操作するユーザが正当なユーザであるかを、取引管理サーバ３０の判定結果に基づいてチェックする。正当なユーザである場合にのみログインが許可され、以降の処理が可能となる。

早期払い情報表示制御部１５２は、ユーザの操作に応じて、取引管理サーバ３０に早期払い情報リクエストを送信し、当該リクエストの応じて取引管理サーバ３０から受信した（早期払い上限額や納品した商品の代金等を含む）早期払い情報表示用データを、商品等提供者端末１０のタッチスクリーン１１３に表示するよう制御する。

早期払いリクエスト送信部１５３は、ユーザの操作に応じて、早期払いリクエストを取引管理サーバ３０に送信する。

入出力制御部１５４は、図８に示す商品等提供者端末１０のタッチスクリーン１１３、及び入力機器インタフェース１１２を介して得られるユーザの操作に係る信号をＣＰＵ１０１に送信するとともに、ＣＰＵ１０１の指令に基づいて、早期払い情報等を、ディスプレイ制御部１１１を介してタッチスクリーン１１３に表示するよう制御する。

ネットワークＩ／Ｆ部１５５は、図８に示す商品等提供者端末１０の無線信号処理部１０６等を制御して、取引管理サーバ３０との間のデータ送受信を実現する。

なお、アクセス制御部１５１、早期払い情報表示制御部１５２、及び早期払いリクエスト送信部１５３は、商品等提供者端末１０にインストールされた専用アプリケーションで実現できるが、一般的なＷＥＢブラウザにより取引管理サーバ３０からｈｔｍｌ等を読み込むことで実現することも可能である。

次に、図１１の機能ブロック図を参照して、本発明の第１実施形態に係る取引管理システム１における取引先企業端末２０の機能の概要について説明する。図１１に示すように、取引先企業端末２０は、アクセス制御部２５１、取引入力部２５２、請求書受付部２５３、入出力制御部２５４、及びネットワークＩ／Ｆ部２５５を含んでいる。

アクセス制御部２５１は、取引先企業端末２０を操作するユーザが正当なユーザであるかを、アクセス先の判定結果に基づいてチェックする。正当なユーザである場合にのみログインが許可され、以降の処理が可能となる。

取引入力部２５２は、納品された商品等の納品日や代金、又は納品された商品等の確定日や代金を含む取引情報を、ユーザ力操作に応じて取引管理サーバ３０に送信する。

請求書受付部２５３は、本来の支払期日に、取引管理サーバ３０から商品等の代金請求のメッセージを受信し、その後、必要に応じて、その代金請求に係る決済処理を行う。

入出力制御部２５４は、取引先企業端末２０のタッチスクリーン、及び入力機器インタフェースを介して得られるユーザの操作に係る信号をＣＰＵに送信するとともに、ＣＰＵの指令に基づいて、取引情報を入力するための画面等を、ディスプレイ制御部を介してタッチスクリーンに表示するよう制御する。

ネットワークＩ／Ｆ部２５５は、取引先企業端末２０の無線信号処理部等を制御して、取引管理サーバ３０との間のデータ送受信を実現する。

上述したアクセス制御部２５１、取引入力部２５２、及び請求書受付部２５３は、商品等提供者端末１０にインストールされた専用アプリケーションで実現できるが、一般的なＷＥＢブラウザにより取引管理サーバ３０からｈｔｍｌ等を読み込むことで実現することも可能である。

次に、図１２の機能ブロック図を参照して、本発明の第１実施形態に係る取引管理サーバ３０の機能の概要について説明する。図１２に示すように、取引管理サーバ３０は、アクセス制御部３５１、取引管理部３５２、リクエスト管理部３５３、早期払い上限額管理部３５４、決済処理制御部３５５、月次処理制御部３５６、及びネットワークＩ／Ｆ部３５７を含んでいる。また、外部記憶装置３６０には、取引先企業管理テーブル３６１、商品等提供者管理テーブル３６２、取引管理テーブル３６３、上限額設定テーブル３６４、手数料管理テーブル３６５、及び早期払い管理テーブル３６６が記憶される。

アクセス制御部３５１は、商品等提供者端末１０や取引先企業端末２０からのアクセスに対して、ユーザ認証を行い、判定結果を各端末に返す。正当なユーザであると判定された場合にのみ、その端末のログインが許可される。

取引管理部３５２は、取引先企業端末２０から入力された取引情報を受信し、その情報を、取引管理テーブル３６３に記憶する。これに連動して、早期払い上限額管理部３５４が、早期払い管理テーブル３６６の早期払い上限額を更新する。

リクエスト管理部３５３は、商品等提供者端末１０から早期払いリクエストを受信した場合に、その早期払いリクエストに応じて、商品等提供者に早期払いを行うよう早期払い上限額管理部３５４、及び決済処理制御部３５５を制御する。

また、リクエスト管理部３５３は、商品等提供者端末１０から早期払い情報リクエストを受信した場合に、取引管理テーブル３６３や早期払い管理テーブル３６６を参照し、早期払い上限額や納品した商品の代金等を含んだ、早期払い情報表示用データを生成し、商品等提供者端末１０に送信する。

早期払い上限額管理部３５４は、取引先企業端末２０から受信した取引情報等に基づいて、早期払い上限額を決定して早期払い管理テーブル３６６を更新するとともに、商品等提供者端末１０から早期払いリクエストを受信した場合に、早期払い管理テーブル３６６を参照して、受信した早期払いリクエストの金額が早期払い上限額以下であるか否かを判定する。

また、早期払い上限額管理部３５４は、早期払いリクエストによる早期払いが行われた場合に、早期払い管理テーブル３６６の早期払い上限額を更新する。

決済処理制御部３５５は、早期払い上限額管理部３５４により、受信した早期払いリクエストの金額が早期払い上限額以下であるとされた場合に、その金額を商品等提供者に支払うよう、例えば、全銀システム（全国銀行データ通信システム）のサーバ等に対して早期払い依頼のメッセージを送信する。また、早期払いの残金があれば、本来の支払期日において、その残金を商品等提供者に支払うよう、例えば、全銀システムのサーバ等に対して通常払い依頼のメッセージを送信する。

月次処理制御部３５６は、取引情報を記憶した取引管理テーブル３６３を参照して、本来の支払期日に、商品等の代金請求のメッセージを取引先企業端末２０に送信する。また、早期払い管理テーブル３６６等を参照して、本来の支払期日に支払うべき金額（早期払いの残金）を求め、決済処理制御部３５５により、その残金を通常払いとして商品等提供者に支払うよう制御する。この通常払いに連動して、早期払い上限額管理部３５４が、早期払い管理テーブル３６６の早期払い上限額を更新する。

なお、本実施形態では、月次処理制御部３５６により月次の処理が行われるものとしたが、これに限定されるものではない。この処理の実行タイミングは、それぞれの取引先企業が設定した支払期日のタイミングに応じて決定される。例えば、取引先企業が、商品等提供者に応じて異なる支払期日を設定している場合、その取引先企業についての上記処理は、月に複数回行われることになるし、また、１ヶ月ごとのサイクルで行われる必要もない。

ネットワークＩ／Ｆ部３５７は、図９に示す取引管理サーバ３０のネットワークインタフェース３０３等を制御して、インターネット等のネットワークに接続し、商品等提供者端末１０や取引先企業端末２０との間のデータ送受信を実現する。

次に、図１３ないし図１５を参照して、本発明の第１実施形態に係る取引管理システム１におけるテーブルの例について説明する。

図１３Ａには、取引先企業管理テーブル３６１の例が示されている。取引先企業管理テーブル３６１は、取引先企業の属性等を管理、記憶するもので、例えば、取引先企業ＩＤ、名称、支払条件、パスワードの各項目を記憶する。

ここで、取引先企業ＩＤは、取引先企業を特定するための識別子である。また、支払条件には、商品等の受け入れ確定日をどのような基準で設定するかを規定する確定日と、どのタイミングで締め処理を行い、どのタイミングで支払いを行うかを規定する支払日（本来の支払期日）が含まれる。

なお、本実施形態では、取引先企業ごとに１つの支払条件が設定されているが、複数の支払条件のパターンを用いることもできる。例えば、商品等を受領した商品等提供者に応じて、支払条件を変えることができる。また、取引管理システム１で予め固定的に支払条件のパターンを設定しておき、取引先企業ごとに、１つ又は複数のパターンに対応するパターンＩＤが対応付けられるようにしてもよい。

図１３Ｂには、商品等提供者管理テーブル３６２の例が示されている。商品等提供者管理テーブル３６２は、商品等提供者の属性等を管理、記憶するもので、例えば、商品等提供者ＩＤ、名称、パスワード、振込口座ＮＯの各項目を記憶する。

ここで、商品等提供者ＩＤは、商品等提供者を特定するための識別子である。なお、これらの項目のほか、例えば、月間の早期払いリクエストの上限回数や、個別の早期払い上限額等を記憶し、これらの項目によって、商品等提供者からの早期払いリクエストに応じるか否かの判断を行うようにしてもよい。

図１４Ａには、取引管理テーブル３６３の例が示されている。取引管理テーブル３６３は、取引先企業端末２０から送信された取引情報を記憶するもので、例えば、取引先企業ＩＤ、（当該取引先企業に商品等を納品した商品等提供者の）商品等提供者ＩＤ、取引ＮＯ、商品ＩＤ、納品日、確定日、取引金額の各項目を記憶する。

本実施形態では、各取引について１つの商品の商品ＩＤを記憶しているが、取引ＮＯに対応する取引が複数の商品を含む場合は、これに応じて複数の商品ＩＤを含むようにできる。また、取引管理テーブル３６３に商品ＩＤを記憶しないように設計することもできる。このような構成により、ファクタリング会社が、取引先企業における取引の詳細を把握できないようにすることができる。

取引ＮＯは、取引先企業における商品等提供者との取引を特定するための識別子であるが、取引先企業の取引ＮＯを用いずに、取引管理システム１で独自に採番したものを使用することもできる。

本実施形態では、商品等提供者による納品の際に、取引先企業端末２０から送信された取引情報に基づいて、取引管理テーブル３６３にレコードを挿入して納品日を記憶し、その後、取引先企業が（商品等の検収完了等によって）商品等の受け入れを確定させた際に、取引先企業端末２０から送信された取引情報に基づいて、対応するレコードに確定日をセットする。また、上述の取引先企業管理テーブル３６１の支払条件によって、納品日に基づいて確定日が自動的に決定される場合は、納品の際に取引先企業端末２０から送信された取引情報に基づいて、納品日と確定日をセットするようにしてもよい。

図１４Ｂには、上限額設定テーブル３６４の例が示されている。上限額設定テーブル３６４は、取引先企業ＩＤ、納品日〜確定日までの早期払い上限額比率、及び確定日〜支払期日までの早期払い上限額比率を記憶している。納品日〜確定日までの早期払い上限額比率は、商品等提供者が、商品等を納品した納品日から、取引先企業においてその商品の受け入れを確定させた確定日までに、商品等提供者がリクエスト可能な早期払い額の上限比率（納品した商品の代金に占める割合）を示している。また、確定日〜支払期日までの早期払い上限額比率は、取引先企業においてその商品の受け入れを確定させた確定日から、本来、取引先企業が商品等提供者に商品の代金を支払う支払期日までに、商品等提供者がリクエスト可能な早期払い額の上限比率（納品した商品の代金に占める割合）を示している。これらの比率は、基本的にファクタリング会社によって設定される。

本実施形態において、納品日〜確定日までの早期払い上限額比率が、確定日〜支払期日までの早期払い上限額比率より低く設定されているのは、納品日〜確定日までは、返品の可能性や、検収不合格の可能性があるためであり、また、本来の支払期日までの期間が長く、取引先企業の倒産リスクなども考慮されている。一方、確定日〜支払期日までの早期払い上限額比率は、返品の可能性や、検収不合格の可能性がなく、本来の支払期日までの期間も短いため、１００％や８０％といった比率が設定されている。

また、本実施形態では、支払期日の１０日前や１週間前といったタイミングで（すなわち、本来の支払期日の直前において）、早期払いのリクエストが不可とされる。これは、取引管理システム１において、取引先企業に送信する代金請求のメッセージを事前に準備し、所定のサーバに送信するのに、取引先企業への請求額を前もって確定させる必要があるからである。

なお、本実施形態では、取引先企業ごとに２つの期間における早期払い上限額比率を記憶しているが、取引管理システム１において、すべての取引先企業に亘って一律の上限額比率を設定することもでき、また、早期払いの上限額比率を単一の期間で設定することもできる。また、取引先企業と商品等提供者との組合せに応じて、早期払いの上限額比率を設定することもできる。

図１５Ａには、手数料管理テーブル３６５の例が示されている。手数料管理テーブル３６５は、商品等提供者から徴収されるシステム利用手数料について、基本手数料、支払期日当月加算分、納品月以降・支払期日前月加算分（各月）の各項目を記憶している。

本実施形態では、取引管理システム１において、早期払いによる支払い（すなわち、商品等提供者に対する立て替え）に関する手数料が、立替の対象となる商品等の代金に関する支払期日から遠ければ遠い程、高い手数料となるよう設計されている。よって、図１５Ａの例では、本来の支払期日の前々月に納品（又は確定となった）された商品等について早期払いリクエストを行うと、基本手数料３％のほかに、支払期日当月加算分１％が加算され、さらに、納品月以降・支払期日前月加算分（各月）が２ヶ月分で２％加算され、合計で６％のシステム利用手数料となり、このシステム利用手数料が、早期払い額から差し引かれる（すなわち、商品等提供者の負担となる）。

例えば、本来の支払期日の前月に納品（又は確定となった）された商品等について早期払いリクエストを行うと、基本手数料３％のほかに、支払期日当月加算分１％が加算され、さらに、納品月以降・支払期日前月加算分（各月）が１ヶ月分で１％加算され、合計で５％のシステム利用手数料となり、このシステム利用手数料が、早期払い額から差し引かれる。このように、システム利用手数料は、立替の期間が長いほどシステム利用手数料が高く設定されており、商品等提供者は、早期払いリクエストのタイミングを遅らせれば遅らせるほど、システム利用手数料の負担の面で有利となる。

なお、手数料管理テーブル３６５のシステム利用手数料を、基本手数料のみとすることもできるし、また、取引先企業ごと、あるいは取引先企業と商品等提供者との組合せに応じて異なるように設定することもできる。

図１５Ｂには、早期払い管理テーブル３６６の例が示されている。早期払い管理テーブル３６６は、取引先企業ＩＤ、商品等提供者ＩＤ、種別、取引ＮＯ、基準日、金額、早期払い上限額を記憶する。

本実施形態では、種別は、早期払い上限額に関係する取引やリクエストを判別するためのものであり、商品等提供者による納品に関する取引情報を取引先企業端末２０から受信した場合は「納品」がセットされ、このとき、基準日には納品日がセットされ、金額には納品に係る商品の代金がセットされる。取引先企業による商品等の確定に関する取引情報を取引先企業端末２０から受信した場合は「確定」がセットされ、このとき、基準日には確定日がセットされ、金額には確定した商品の代金がセットされる。

また、商品等提供者端末１０から早期払いリクエストを受信した場合は「早期払い」がセットされ、このとき、基準日には当該リクエストの送信日がセットされ、金額には、商品等提供者がリクエストした早期払い額がセットされる。また、残金を商品等提供者に支払う場合は「通常払い」がセットされ、このとき、基準日には残金の支払日（本来の支払期日）がセットされ、金額には、残金の額がセットされる。

取引管理サーバ３０の早期払い上限額管理部３５４は、上記のような取引情報の受信と早期払いリクエストの受信に対応する早期払いに応じて、上限額設定テーブル３６４等を参照して、その商品等提供者が受領可能な早期払い上限額を決定し、早期払い管理テーブル３６６の早期払い上限額にセットする。

次に、図１６ないし図１９を参照して、本発明の第１実施形態に係る取引管理システム１における各処理について説明する。なお、図１６ないし図１９は、取引管理システム１の各処理に関する手順を説明するためのフローチャートであり、商品等提供者端末１０、取引先企業端末２０、及び取引管理サーバ３０の処理が、それぞれ時間の経過とともに表されている。

図１６は、取引管理サーバ３０が、取引先企業端末２０から納品に係る取引情報を受信する、納品時処理の手順を示した図である。

最初に、商品等提供者から取引先企業に対して、商品、又はサービスの提供が行われると、取引先企業のユーザは、取引先企業端末２０を操作して、商品・サービスの納品に係る取引の内容を表す取引情報の入力を行う。

ここで、取引先企業端末２０は、こうして入力された取引情報を受信し、これを取引管理サーバ３０に送信する（ステップＳ１１）。このとき、取引情報には、例えば、取引先企業ＩＤ、商品等提供者ＩＤ、取引ＮＯ、取引金額、納品日等が含まれる。また、このとき、取引先企業端末２０からパスワード等が取引管理サーバ３０に送信されてユーザ認証が行われ、取引管理サーバ３０が取引先企業管理テーブル３６１のパスワードと比較して正当なユーザであると判定した場合に、以降の処理が可能となる。

取引管理サーバ３０は、取引先企業端末２０から取引情報を受信すると、この内容を取引管理テーブル３６３に記憶する（ステップＳ１２）。

次に、取引管理サーバ３０は、この取引情報に基づいて、早期払い上限額を決定する（ステップＳ１３）。この早期払い上限額は、上限額設定テーブル３６４の納品日〜確定日の上限額比率に基づいて決定される。その後、取引管理サーバ３０は、決定された早期払い上限額を含むレコード（種別＝「納品」）を追加するよう、早期払い管理テーブル３６６を更新する（ステップＳ１４）。

この後、商品等提供者端末１０において、後述する早期払い上限額確認画面を表示させるよう指示すると、上記のように決定・記憶された早期払い上限額が、例えば、納品月と本来の支払期日ごとにまとめられて（すなわち、システム利用手数料が同じものにまとめられて）一覧表示される（ステップＳ１５）。

図１７は、取引管理サーバ３０が、自動的に確定タイミング到来をチェックする場合、及び取引先企業端末２０から商品の受け入れ確定に係る取引情報を受信する場合の確定時処理の手順を示した図である。

最初に、取引管理サーバ３０が、自動的に確定タイミング到来をチェックする確定時処理の手順を説明する。まず、取引管理サーバ３０は、取引管理テーブル３６３に記憶されたレコードで、確定日がセットされていない取引について、取引先企業管理テーブル３６１に記憶された支払条件を参照し、その確定日を求める（ステップＳ２１）。

次に、確定日が到来しているか否かを判定し（ステップＳ２２）、確定日が到来していると判定された場合（ステップＳ２２のＹＥＳ）、取引管理サーバ３０は、求めた確定日に基づいて取引管理テーブル３６３を更新する（ステップＳ２２ａ）。次に、ステップＳ２３に進み、そこで、早期払い上限額を決定する。この早期払い上限額は、上限額設定テーブル３６４の確定日〜支払期日の上限額比率に基づいて決定される。その後、取引管理サーバ３０は、対応するレコードの種別を「納品」から「確定」に変更し、さらに早期払い上限額を変更して、早期払い管理テーブル３６６を更新する（ステップＳ２４）。

確定日が到来していないと判定された場合（ステップＳ２２のＮＯ）、ステップＳ２１の処理に戻り、取引管理テーブルのすべての対象取引についてチェックが完了した場合に、処理を終了する。

次に、取引管理サーバ３０が、取引先企業端末２０から商品の受け入れ確定に係る取引情報を受信する場合の確定時処理の手順を説明する。

最初に、取引先企業のユーザが、商品・サービスの検収等を完了して、当該商品等の受け入れが確定した場合に、取引先企業のユーザは、取引先企業端末２０を操作して、商品・サービスの確定に係る取引の内容を表す取引情報の入力を行う。

このために、取引先企業端末２０は、ユーザの操作に応じて、過去に送信された取引で確定日が入力されていないものを取得するための取引取得指示を取引管理サーバ３０に送信する（ステップＳ２５）。

取引管理サーバ３０は、取引管理テーブル３６３を参照して、取引取得指示を受信した取引先企業ＩＤの確定日未入力取引を検索し、検索結果として得られた取引情報を取引先企業端末２０に送信する（ステップＳ２６）。

取引管理サーバ３０から取引情報を受信した取引先企業端末２０は、取引情報の取引を確定日未入力取引として表示し、そこで、取引先企業のユーザから、確定日の入力を受け付ける（ステップＳ２７）。その後、取引先企業端末２０は、受信した確定日を、取引ＮＯ等に対応付けて取引管理サーバ３０に送信する（ステップＳ２８）。

取引先企業端末２０から確定日を受信した取引管理サーバ３０は、受信した確定日に基づいて取引管理テーブル３６３を更新する（ステップＳ２９）。その後、上述したステップＳ２３によって早期払い上限額が決定され、ステップＳ２４によって早期払い管理テーブル３６６が更新される。

早期払い管理テーブル３６６が更新された後、商品等提供者端末１０において、後述する早期払い上限額確認画面を表示させるよう指示すると、上記のように決定・記憶された早期払い上限額が、例えば、納品月と本来の支払期日ごとにまとめられて（すなわち、システム利用手数料が同じものにまとめられて）一覧表示される（ステップＳ３０）。

図１８は、取引管理サーバ３０が、商品等提供者端末１０から早期払いリクエストを受信した場合の早期払いリクエスト（随時）処理の手順を示した図である。

最初に、商品等提供者（ユーザ）の操作により、後述する早期払い上限額表示画面の表示を指示すると、商品等提供者端末１０が、取引管理サーバ３０に対して早期払い上限額表示画面のためのリクエストを送信する（ステップＳ３１）。このリクエストには、その商品等提供者の商品等提供者ＩＤのほか、取引先企業ＩＤも含まれる。また、このとき、商品等提供者端末１０からパスワード等が取引管理サーバ３０に送信されてユーザ認証が行われ、取引管理サーバ３０が商品等提供者管理テーブル３６２のパスワードと比較して正当なユーザであると判定した場合に、以降の処理が可能となる。

取引管理サーバ３０が、早期払い上限額表示画面のためのリクエストを受信すると、早期払い管理テーブル３６６を参照して、商品等提供者ＩＤと取引先企業ＩＤに対応する早期払い上限額を特定し、その情報を商品等提供者端末１０に送信する（ステップＳ３２）。

商品等提供者端末１０は、早期払い上限額に関する情報を取引管理サーバ３０から受信すると、その情報に基づいて、後述する早期払い上限額表示画面をタッチスクリーン１１３に表示する（ステップＳ３３）。

その後、商品等提供者端末１０は、ユーザの操作により、後述する早期払いリクエスト画面をタッチスクリーン１１３に表示し、そこでユーザが早期払いリクエストの送信を指示すると、これに応じて、取引管理サーバ３０に早期払いリクエストを送信する（ステップＳ３４）。この早期払いリクエストには、ユーザが指定した早期払い額が含まれる。

取引管理サーバ３０は、商品等提供者端末１０から早期払いリクエストを受信すると、早期払い管理テーブル３６６の早期払い上限額を参照して、早期払いリクエストに指定された早期払い額が、早期払い上限額以下か否かを判定する（ステップＳ３５）。早期払い額が早期払い上限額以下でない場合（ステップＳ３５のＮＯ）、早期払い額が上限を超えた旨のエラーメッセージを生成し、商品等提供者端末１０に送信する（ステップＳ３６）。商品等提供者端末１０は、このエラーメッセージを受信すると、それをタッチスクリーン１１３に表示する（ステップＳ３７）。

一方、早期払い額が早期払い上限額以下であると判定された場合（ステップＳ３５のＹＥＳ）、取引管理サーバ３０は、早期払いリクエストに基づいて、指定された早期払い額を、商品等提供者の預金口座にあてて振り込むための早期払い依頼を所定のサーバに送信する（ステップＳ３８）。

なお、早期払いリクエストに指定された早期払い額が、早期払い上限額以下か否かを判定する場合、商品等提供者が負担するシステム利用手数料が差し引かれる関係上、このシステム利用手数料を考慮して上記判定を行う必要がある。例えば、早期払い管理テーブル３６６の早期払い上限額が１０万円であって、早期払いリクエストに指定された早期払い額も１０万円である場合、システム利用手数料を差し引くことができないので、早期払いリクエストがエラーとなる。

また、このような場合、早期払いリクエストに指定された早期払い額から自動的にシステム利用手数料を差し引いて、指定する預金口座に振り込むようにしてもよい。また、上限額設定テーブル３６４によって、対応する期間の早期払い上限額比率が１００％でない場合に、上限額として設定された枠以外の金額に対してシステム利用手数料がチャージされるようにしてもよい。

また、本実施形態では、早期払いリクエストに指定された早期払い額が上限額を超えた場合に、その早期払いリクエストをエラーとしているが、この早期払い額からシステム利用手数料が差し引かれることを考慮して、早期払い額からシステム利用手数料が差し引かれた金額（すなわち、商品等提供者に実際に振り込まれる金額）に関する早期払い上限額を設定するようにしてもよい。

次に、取引管理サーバ３０は、商品等提供者の預金口座にあてて振り込んだ早期払い額に基づいて、早期払い管理テーブル３６６の早期払い上限額を減算し、早期払い管理テーブル３６６を更新する（ステップＳ３９）。

その後、取引管理サーバ３０は、早期払い額の振込手続が完了した旨の振込完了メッセージを生成し、商品等提供者端末１０に送信する（ステップＳ４０）。商品等提供者端末１０は、この振込完了メッセージを受信すると、それをタッチスクリーン１１３に表示する（ステップＳ４１）。

なお、商品等提供者端末１０に表示される早期払い上限額表示画面や早期払いリクエスト画面は、本実施形態では、取引管理サーバ３０から送信されるｈｔｍｌデータ等が商品等提供者端末１０のＷＥＢブラウザで解釈され表示されるものであるが、その表示内容や、取引先企業のポータルサイトからアクセス可能とする構成にすることによって、あたかも取引先企業から提供されているサービスであるように見せることができる。同様に、商品等提供者が、明らかにファクタリング会社のサイトから、そのファクタリング会社のサービスとして利用しているように感じさせるような見せ方をすることもできる。

図１９は、取引管理サーバ３０が実行する月次処理の手順を示した図である。なお、本実施形態では、取引先企業における本来の支払いタイミングが毎月末や毎月１５日としているため、そのタイミングで月次処理が行われるが、取引先企業の支払いタイミングに合わせて、適宜この処理を実行することができる。

月次処理では、最初に、取引管理サーバ３０が、取引先企業管理テーブル３６１の支払い条件や取引管理テーブル３６３の各取引を参照して、取引先企業ごとに請求額を決定する（ステップＳ５１）。

次に、取引管理サーバ３０は、決定された請求額に基づいて請求書を作成し、取引先企業端末２０に請求書を送信し、請求額を通知する（ステップＳ５２）。取引先企業は、通知された請求額に基づいて、金額をファクタリング会社に振り込む。なお、ステップＳ５２の処理は、少なくとも一部を手作業で行うこともでき、必ずしもすべてがシステム化されている必要はない。また、取引管理システム１のシステム利用手数料を取引先企業に対しても請求する場合は、例えば、この請求額にシステム利用手数料を付加して請求することもできる。

次に、取引管理サーバ３０は、取引先企業の本来の支払期日までに早期払いリクエストがされなかった残り金額（残金）を、早期払い管理テーブル３６６を参照して算出する（ステップＳ５４）。ここで、残り金額があるか否かを判定し（ステップＳ５５）、残り金額がある場合（ステップＳ５５のＹＥＳ）、その残り金額を商品等提供者の預金口座に振り込むための通常払い依頼を、所定のサーバに送信する（ステップＳ５６）。

なお、本実施形態では、上述したように、支払期日の１０日前や１週間前といったタイミングで（すなわち、本来の支払期日の直前において）、早期払いのリクエストが不可とされるため、このような支払期日の１０日前や１週間前の時点で、関連する取引先企業への請求額や、商品等提供者への通常払いの額が確定している。したがって、このようなタイミングにおいて、ステップＳ５１の請求額の決定や、ステップＳ５６の通常払い依頼の送信を行うことが好ましい。

なお、本実施形態では、このような通常払いとなった残金については、基本手数料を含め、いかなるシステム利用手数料も徴収しないようにしているが（ただし、振込手数料は差し引くこととする）、所定の基準により、このような場合もシステム利用手数料を徴収するようにしてもよい。

その後、取引管理サーバ３０は、通常払いの振込手続が完了した旨の振込完了メッセージを生成し、商品等提供者端末１０に送信する（ステップＳ５７）。商品等提供者端末１０は、この振込完了メッセージを受信すると、それをタッチスクリーン１１３に表示する（ステップＳ５８）。

次に、取引管理サーバ３０は、早期払い管理テーブル３６６に、種別＝「通常払い」のレコードを追加する（ステップＳ５９）。結果として、これで、対象の納品月と本来の支払期日に関する早期払い上限額がゼロとなる。また、このタイミングで、各取引に関し、本来の支払期日までの長さが月単位で変化し、それに応じてシステム利用手数料が変化するため、システム利用手数料が差し引かれることを加味して早期払い上限額が設定されている場合は、こうしたシステム利用手数料の変化に応じて、早期払い上限額を変更する必要がある。

ステップＳ５５において、残り金額がないと判定された場合（ステップＳ５５のＮＯ）、取引管理サーバ３０は、ステップＳ６０に進み、そこで、通常払いがない旨のメッセージを生成し、商品等提供者端末１０に送信する（ステップＳ６０）。商品等提供者端末１０は、このメッセージを受信すると、それをタッチスクリーン１１３に表示する（ステップＳ５８）。

図２０は、図５Ｂに示した商品の納品、確定と代金支払いにおいて、３社間ファクタリングを提供した状況において、本発明の第１実施形態に係る取引管理システム１を提供した様子を示している。商品等提供者が、１月（当月）１０日に商品を納品した場合（納品（１））、この納品に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この納品（１）の取引は、２月（翌月）１０日に確定され、３月（翌々月）末に本来の支払期日を迎えるものである。

このような納品（１）の取引により、商品等提供者は、納品したその日（１月１０日）にも、早期払いリクエストにより、納品（１）の商品に係る代金の一部を受領することができる。早期払いリクエスト「Ｒ」は、本実施形態では、上述のように、商品等提供者端末１０から取引管理サーバ３０に送信される。また、早期払いリクエストで指定した金額は、即時に商品等提供者の口座に振り込まれるようにしてもよいし、翌営業日や翌々営業日など、早期払いリクエスト後の所定のタイミングで振り込まれるようにしてもよい。また、商品等提供者の口座に振り込まれる金額は、早期払いリクエストで指定した金額から取引管理システムのシステム利用手数料を差し引いた額であるが、早期払いリクエストで指定した金額がそのまま商品等提供者の口座に振り込まれるようにし、システム利用手数料は、商品等提供者の残りの代金（売掛金）から徴収するようにしてもよい。

また、このとき、納品の時点で商品等提供者からファクタリング会社に売掛債権が譲渡されているが、ここではまだ取引が確定していないので、「納品（１）」に対応する取引が確定（「確定（１）」）となるタイミング（２月１０日）に、商品等提供者からファクタリング会社に売掛債権が譲渡されるとしてもよい。

さらに商品等提供者は、１月１５日に再び早期払いリクエストを行い、納品した納品（１）の商品に係る代金の残りを受領することができる。

次に、商品等提供者が、１月（当月）２０日に商品を納品したとする（納品（２））。そして、この納品に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この納品（２）の取引は、２月（翌月）２０日に確定され、３月（翌々月）末に本来の支払期日を迎えるものである。

ここで、商品等提供者は、２月２日に、早期払いリクエストにより、納品（１）の商品と納品（２）の商品に係る代金の一部を受領するものとする。納品（１）の商品に係る代金に残りがあれば、その枠の金額も早期払いリクエストに含むことができる。

また、納品（１）の商品と納品（２）の商品に係る代金の本来の支払期日は３月末であり、このような２月になっての早期払いは、１月の早期払いより支払期日までの期間が１ヶ月短くなるので、システム利用手数料が１ヶ月分少なく設定されることになる。

納品（１）の商品の確定に係る取引情報が、取引先企業から取引管理システム１に提供され、２月１０日にこの納品（１）が確定する（確定（１））。その後、商品等提供者が、２月１２日に商品を納品し（納品（３））、この納品に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この納品（３）の取引は、３月１２日に確定され、４月末に本来の支払期日を迎えるものである。

ここで、商品等提供者は、２月１５日に、早期払いリクエストにより、確定（１）の商品、納品（２）の商品、及び納品（３）の商品に係る代金の一部を受領するものとする。確定（１）、納品（２）の商品に係る代金に残りがあれば、その枠の金額も早期払いリクエストに含むことができる。また、今回の早期払いリクエストでは、納品（１）の取引が確定され、確定（１）となっているため、早期払い上限額がその分増加している（上限額設定テーブル３６４参照）。

その後、納品（２）の商品の確定に係る取引情報が、取引先企業から取引管理システム１に提供され、２月２０日にこの納品（２）が確定する（確定（２））。よって、その後の早期払いリクエストでは、納品（２）の取引が確定され、確定（２）となっているため、早期払い上限額がその分増加している（上限額設定テーブル３６４参照）。

確定（１）の商品と確定（２）の商品に係る代金は、２月末で締められ、これらの取引に対応する売掛金が、（取引先企業からの請求に基づき）３月末に、取引先企業からファクタリング会社に支払われる。一方、確定（１）の商品と確定（２）の商品に係る代金のうち、早期払いの対象となっていない残りの金額は、３月末にファクタリング会社から商品等提供者に（通常払いとして）支払われる。

このように、３社間ファクタリングを設定したうえで、本発明の取引管理システム１を利用することによって、商品等提供者は、納品した商品に係る代金に対応する資金を、早期払いリクエストによって、本来の支払期日より前に、所望のタイミングで所望の額を回収することができる。商品等提供者は、早期払いリクエストによって随時、売掛金を現金化できるので、資金繰りの状況に応じて、適宜、早期払いリクエストを行うか否かを柔軟に判断することができる。

また、システム利用手数料が、早期払いリクエストのタイミング又は早期払いが行われたタイミングから、本来の支払期日までの期間が短いほど少額になるよう設定されているため、商品等提供者は、このような状況を考慮し、資金調達コストを最小限にするように、早期払いリクエストを行うタイミングを判断することができる。

次に、図２１を参照して、図２０に示すような商品の納品、確定、代金支払い、及び早期払いリクエストがある場合の具体的な資金の動きについて説明する。

なお、この例では、取引先企業ＩＤ＝「Ｔ００２」で、商品の納品日の翌月応当日が確定日となり、さらに、それらの確定日を月末で締めて、翌月末に本来の支払期日とするものとする（図１３Ａの取引先企業管理テーブル３６１参照）。したがって、商品等提供者（ここでは、商品等提供者＝「０００２」）は、本来、商品が納品された月の翌々月の末に当該商品の代金を取引先企業から受け取るものである。

また、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％で、確定日〜支払期日までの早期払い上限額比率が１００％である（図１４Ｂの上限額設定テーブル３６４参照）。

図２１のグラフでは、Ｙ軸がプラスの方向に売掛金と早期払い上限額に関する表示が配置され、Ｙ軸がマイナスの方向に、商品等提供者への早期払い額に関する表示が配置されている。

最初に、図２０に示したように、１月１０日に、商品等提供者の納品（１）に関する取引情報（取引金額＝２００万円）が、取引先企業端末２０から取引管理サーバ３０に送信されると、図２１には、これに対応する２００万円の上側棒グラフ（上側の左端のグラフ）が示され、そのうち下側が早期払い可能な１００万円を表し、上側が残りの金銭債務（＝１００万円）を表している。上記のように、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％となっているため、この時点で、早期払い上限額は１００万円となる。また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の１番目の種別＝「納品」のレコードに示されている。

次に、同日、商品等提供者が、商品等提供者端末１０により早期払いリクエストを行うと（早期払い額＝６０万円）、図２１には、これに対応する６０万円の下側棒グラフ（下側の左端のグラフ）が示され、そのうち、下側がシステム利用手数料（＝３．６万円（６％））と振込手数料（＝１０００円）の合計３．７万円を表し、上側が、商品等提供者の預金口座に実際に振り込まれる金額（＝５６．３万円）を表している。なお、ここでは、早期払いリクエストで指定された早期払い額から、システム利用手数料と振込手数料が事前に差し引かれるものとする。

早期払いリクエストで指定された早期払い額の６０万円は、早期払い上限額の１００万円以下であるので、このリクエストは正常に受け付けられる。また、システム利用手数料は、この納品（１）に係る商品の代金が本来は、当該早期払いリクエストの翌々月末に支払われるので、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月＝１％、納品月翌月＝１％）の合計で６％となる。商品等提供者の預金口座への振込手数料は、ここでは一律１０００円とする。

また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の２番目の種別＝「早期払い」のレコードに示されており、６０万円の早期払いを行ったので、早期払い上限額は１００万円から４０万円に減じられている。

図２１には、これに対応する１４０万円の上側棒グラフ（上側の左から２番目のグラフ）が示され、そのうち下側が早期払い可能な４０万円を表し、上側が残りの金銭債務（＝１００万円）を表している。

次に、図２０に示したように、１月１５日、商品等提供者が、商品等提供者端末１０により早期払いリクエストを行うと（早期払い額＝３０万円）、図２１には、これに対応する３０万円の下側棒グラフ（下側の左から２番目のグラフ）が示され、そのうち、下側がシステム利用手数料（＝１．８万円（６％））と振込手数料（＝１０００円）の合計１．９万円を表し、上側が、商品等提供者の預金口座に実際に振り込まれる金額（＝２８．１万円）を表している。

早期払いリクエストで指定された早期払い額の３０万円は、早期払い上限額の４０万円以下であるので、このリクエストは正常に受け付けられる。また、システム利用手数料は、この納品（１）に係る商品の代金が本来は、当該早期払いリクエストの翌々月末に支払われるので、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月＝１％、納品月翌月＝１％）の合計で６％となる。

また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の３番目の種別＝「早期払い」のレコードに示されており、３０万円の早期払いを行ったので、早期払い上限額は４０万円から１０万円に減じられている。

図２１には、これに対応する１１０万円の上側棒グラフ（上側の左から３番目のグラフ）が示され、そのうち下側が早期払い可能な１０万円を表し、上側が残りの金銭債務（＝１００万円）を表している。

次に、図２０に示したように、１月２０日に、商品等提供者の納品（２）に関する取引情報（取引金額＝１００万円）が、取引先企業端末２０から取引管理サーバ３０に送信されると、図２１には、これに対応する２１０万円の上側棒グラフ（上側の左から４番目のグラフ）が示され、そのうち下側が早期払い可能な６０万円を表し、上側が残りの金銭債務（＝１５０万円）を表している。上記のように、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％となっているため、納品（２）の取引金額の５０％の５０万円が加算されて、早期払い上限額は６０万円となり、同様に、金銭債務には５０万円が加算されて１５０万円となっている。また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の４番目の種別＝「納品」のレコードに示されている。

次に、図２０に示したように、２月２日に、商品等提供者が、商品等提供者端末１０により早期払いリクエストを行うと（早期払い額＝６０万円）、図２１には、これに対応する６０万円の下側棒グラフ（下側の左から３番目のグラフ）が示され、そのうち、下側がシステム利用手数料（＝３万円（５％））と振込手数料（＝１０００円）の合計３．１万円を表し、上側が、商品等提供者の預金口座に実際に振り込まれる金額（＝５６．９万円）を表している。

早期払いリクエストで指定された早期払い額の６０万円は、早期払い上限額の６０万円と同じであるので、このリクエストは正常に受け付けられる。また、システム利用手数料は、当該早期払い額が、納品（１）と納品（２）の代金に基づくものであり、これらの商品の代金が本来は、当該早期払いリクエストの翌月末に支払われるので、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月翌月＝１％）の合計で５％となる。

また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の５番目の種別＝「早期払い」のレコードに示されており、６０万円の早期払いを行ったので、早期払い上限額は６０万円から０に減じられている。

図２１には、これに対応する１５０万円の上側棒グラフ（上側の左から５番目のグラフ）が示され、早期払い可能な額は表わされておらず、残りの金銭債務（＝１５０万円）のみが表されている。

次に、図２０に示したように、２月１０日に、商品等提供者の納品（１）の商品の確定（確定（１））に関する取引情報（取引金額＝１００万円）が、取引先企業端末２０から取引管理サーバ３０に送信されると、図２１には、これに対応する１５０万円の上側棒グラフ（上側の左から６番目のグラフ）が示され、そのうち下側が早期払い可能な１００万円を表し、上側が残りの金銭債務（＝５０万円）を表している。上記のように、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％で、確定日〜支払期日までの早期払い上限額比率が１００％となっているため、確定（１）によって、納品（１）の取引金額の５０％の５０万円分が、残りの金銭債務から早期払い可能な額に移動し、早期払い上限額は１００万円となり、同様に、残りの金銭債務は５０万円となっている。また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の６番目の種別＝「確定」のレコードに示されている。

次に、図２０に示したように、２月１２日に、商品等提供者の納品（３）に関する取引情報（取引金額＝１００万円）が、取引先企業端末２０から取引管理サーバ３０に送信されると、図２１には、これに対応する２５０万円の上側棒グラフ（上側の左から７番目のグラフ）が示され、そのうち下段が早期払い可能な１００万円で、実質的にこれまでの納品（１）、納品（２）、確定（１）に関わる部分を表し、中段が早期払い可能な５０万円で、実質的に今回の納品（３）に関わる部分を表し、上段が残りの金銭債務（＝１００万円）を表している。上記のように、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％となっているため、納品（３）の取引金額の５０％の５０万円が加算されて、早期払い上限額は合計で１５０万円となり、同様に、金銭債務には５０万円が加算されて１００万円となっている。また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の７番目の種別＝「納品」のレコードに示されている。

次に、２月１５日に、商品等提供者が、商品等提供者端末１０により早期払いリクエストを行うと（早期払い額＝１２０万円）、図２１には、これに対応する１２０万円の下側棒グラフ（下側の左から４番目のグラフ）が示され、そのうち、下側がシステム利用手数料（うち、１００万円については５万円（５％）、うち２０万円については１．２万円（６％））と振込手数料（＝１０００円）の合計６．３万円を表し、上側が、商品等提供者の預金口座に実際に振り込まれる金額（＝１１３．７万円）を表している。

ここで、早期払い額として１２０万円が指定された場合、実質的に納品（１）、納品（２）、確定（１）に係る金額である１００万円と、実質的に納品（３）に係る金額である５０万円があるが、この時点で、上記の１００万円の方が、本来の支払期日までの期間が短く、低コストで調達できる資金であり、後述するように、システム利用手数料は５％である。一方、上記の５０万円のシステム利用手数料は６％となる。したがって、本実施形態の取引管理システム１では、システム利用手数料の低い金銭債権から早期払い額に対応させていくよう設計されている。なお、これとは逆に、システム利用手数料の高い金銭債権から早期払い額に対応させていくよう設計することもできる。また、どのようなシステム利用手数料の金銭債権を指定した早期払い額に対応させるかを、商品等提供者が指定できるようにしてもよい。

早期払いリクエストで指定された早期払い額の１２０万円は、早期払い上限額の１５０万円以下であるので、このリクエストは正常に受け付けられる。また、システム利用手数料は、この納品（１）、納品（２）、確定（１）に係る商品の代金が本来は、当該早期払いリクエストの翌月末に支払われるので、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月翌月＝１％）の合計で５％となる。一方、納品（３）に係る商品の代金が本来は、当該早期払いリクエストの翌々月末に支払われるので、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月＝１％、納品月翌月＝１％）の合計で６％となる。商品等提供者の預金口座への振込手数料は、ここでは一律１０００円とする。

また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の８番目の種別＝「早期払い」のレコードに示されており、１２０万円の早期払いを行ったので、早期払い上限額は１５０万円から３０万円に減じられている。

図２１には、これに対応する１３０万円の上側棒グラフ（上側の左から８番目のグラフ）が示され、そのうち下側が早期払い可能な３０万円を表し、上側が残りの金銭債務（＝１００万円）を表している。

次に、図２０に示したように、２月２０日に、商品等提供者の納品（２）の商品の確定（確定（２））に関する取引情報（取引金額＝１００万円）が、取引先企業端末２０から取引管理サーバ３０に送信されると、図２１には、これに対応する１３０万円の上側棒グラフ（上側の左から９番目のグラフ）が示され、そのうち下段が早期払い可能な３０万円で、実質的にこれまでの納品（１）、納品（２）、確定（１）、納品（３）に関わる部分を表し、中段が早期払い可能な５０万円で、実質的に今回の確定（２）に関わる部分を表し、上段が残りの金銭債務（＝５０万円）を表している。上記のように、この取引先企業は、納品日〜確定日までの早期払い上限額比率が５０％で、確定日〜支払期日までの早期払い上限額比率が１００％となっているため、確定（２）によって、納品（２）の取引金額の５０％の５０万円分が、残りの金銭債務から早期払い可能な額に移動し、早期払い上限額は８０万円となり、同様に、残りの金銭債務は５０万円となっている。また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の９番目の種別＝「確定」のレコードに示されている。

次に、図２０に示したように、３月末に、確定（１）と確定（２）の取引に基づいて、取引先企業には請求額が通知されるとともに、商品等提供者には、確定（１）と確定（２）の取引に基づいて、この支払期日（納品の翌々月末）に支払われるべき金額で、まだ早期払いがされていない金額が支払われる。

そうすると、上述のように、２月２０日に、確定（２）によって、納品（２）の取引金額の５０％の５０万円分が、残りの金銭債務から早期払い可能な額に移動し、その移動した金額について、早期払いがされていないので、ここで、通常払いとして、商品等提供者の預金口座にその残金が支払われる。図２１には、これに対応する５０万円の下側棒グラフ（下側の左から５番目のグラフ）が示され、そのうち、下側が振込手数料（＝１０００円）を表し、上側が、商品等提供者の預金口座に実際に振り込まれる金額（＝４９．９万円）を表している。なお、本実施形態では、このタイミングで支払われる金額には、システム利用手数料は適用されない。

また、この状況が、図１５Ｂに示す早期払い管理テーブル３６６の１０番目の種別＝「通常払い」のレコードに示されており、５０万円の通常払いを行ったので、早期払い上限額は８０万円から３０万円に減じられている。

この結果、図２１に示すように、この通常払いに対応する８０万円の上側棒グラフ（上側の左から１０番目のグラフ）が示され、そのうち下側が早期払い可能な３０万円を表し、上側が残りの金銭債務（＝５０万円）を表している。

次に、図２２、及び図２３を参照して、商品等提供者端末１０のタッチスクリーン１１３に表示される画面の例について説明する。

図２２Ａに示す早期払い上限額確認画面４００は、図１６のステップＳ１５や、図１７のステップＳ３０において表示される表示画面の例を示している。

例えば、図２２Ａの早期払い上限額確認画面４００は、図１５Ａ、図２０、及び図２１で例示した商品の納品、確定、代金支払いが行われる状況において、１月１０日時点で、商品等提供者ＩＤ＝「０００２」の商品等提供者が、取引先企業＝「Ｔ００２」にの取引先企業に関して表示したものを表している。

早期払い上限額確認画面４００の中段には、１月１０日の納品（１）の取引に応じて支払いが可能となった早期払い額の上限を示すリストが表示されている。上述したように、１月１０日には、取引金額＝２００万円の商品が納品されており（納品（１））、このリストは、その取引に対応するものである。当該リストにおいて、早期払い上限額は、取引金額の５０％に相当する１００万円に設定されている。また、システム利用手数料は「６％」と表示されている。

早期払い上限額確認画面４００の下段には、早期払い額を入力するための早期払い額入力エリアが配置され、その下に、早期払いリクエストを取引管理サーバ３０に送信するための早期払いリクエストボタンと、早期払いリクエストの履歴や各タイミングでの早期払い上限額を表示するための早期払い履歴表示ボタンが配置される。

ここで、商品等提供者（ユーザ）は、商品等提供者端末１０を操作して、上記のリストのチェックボックスをチェックすることで当該リストを選択し、さらに、早期払い額入力エリアに「６０００００」円を入力し、早期払いリクエストボタンをタッチすると、商品等提供者端末１０のタッチスクリーン１１３の表示が、図２２Ｂに示す早期払いリクエスト画面４１０に遷移する。

図２２Ｂの早期払いリクエスト画面４１０の中段上部には、商品等提供者の早期払いリクエストに応じて商品等提供者の預金口座に支払われる、お支払い金額が表示される。ここで、お支払い金額は、図２２Ａの早期払い上限額確認画面４００で指定した早期払い額の６０万円からシステム利用手数料（６０万円×６％＝３．６万円）と振込手数料（１０００円）を差し引いた「５６３０００」円となっている（図２１参照）。

図２２Ｂの早期払いリクエスト画面４１０の下段には、ＯＫボタンとキャンセルボタンが配置され、ＯＫボタンをタッチすると、表示されたお支払い金額の振り込みが確定し、実行される。キャンセルボタンをタッチすると、この早期払いリクエストがキャンセルされ、図２２Ａの早期払い上限額確認画面４００の表示に戻る。

図２３Ａの早期払い上限額確認画面４２０は、図１５Ａ、図２０、及び図２１で例示した商品の納品、確定、代金支払いが行われる状況において、図２２Ａとは別のタイミング（すなわち２月１日時点）で、商品等提供者ＩＤ＝「０００２」の商品等提供者が、取引先企業＝「Ｔ００２」にの取引先企業に関して表示したものを表している。

図２２Ａの早期払い上限額確認画面４００と同様に、中段には、早期払い額の上限を示すリストが表示されているが、ここでは、早期払いが可能な額である上限額が６０万となっている。これは、１月１０日の納品（１）、１月１０日の早期払い、１月１５日の早期払い、及び１月２０日の納品（２）の各取引が月単位にまとめられ、その単位で算出されたものである。

また、上記のリストでは、システム利用手数料は「５％」と表示されているが、これは、納品（１）の商品と納品（２）の商品に係る代金の本来の支払期日は３月末であり、１月の早期払いより支払期日までの期間が１ヶ月短くなるので、その分、システム利用手数料が１ヶ月分少なく設定されたものである。

図２３Ｂの早期払い上限額確認画面４３０は、図１５Ａ、図２０、及び図２１で例示した商品の納品、確定、代金支払いが行われる状況において、図２２Ａ、図２３Ａとは別のタイミング（すなわち２月１２日時点）で、商品等提供者ＩＤ＝「０００２」の商品等提供者が、取引先企業＝「Ｔ００２」にの取引先企業に関して表示したものを表している。

図２２Ａの早期払い上限額確認画面４００と同様に、中段には、早期払い額の上限を示すリストが表示されているが、ここでは、２つのリストが表示されており、上のリストは、早期払いが可能な額である上限額が１００万となっている。これは、１月１０日の納品（１）、１月１０日の早期払い、１月１５日の早期払い、１月２０日の納品（２）、２月２日の早期払い、及び２月１０日の確定（１）の各取引が月単位にまとめられ、その単位で算出されたものである。また、このリストのシステム利用手数料は「５％」と表示されているが、これは、納品（１）の商品、納品（２）の商品、及び確定（１）の商品に係る代金の本来の支払期日は３月末であり、１月の早期払いより支払期日までの期間が１ヶ月短くなるので、その分、システム利用手数料が１ヶ月分少なく設定されたものである。

下のリストは、早期払いが可能な額である上限額が５０万となっている。これは、２月１２日の納品（３）の取引が月単位にまとめられ、その単位で算出されたものである。また、このリストのシステム利用手数料は「６％」と表示されているが、これは、納品（３）の商品に係る代金の本来の支払期日は４月末であり、２月時点で早期払いをする場合、基本手数料（＝３％）、支払期日当月加算分（＝１％）、納品月以降・支払期日前月加算分（納品月＝１％、納品月翌月＝１％）の合計で６％となっている。

また、これら２つのリストにはそれぞれチェックボックスが設けられ、このチェックボックスをチェックすることにより、それぞれのリストを個別に選択することができる。例えば、早期払い額として３０万円を指定する場合、どちらのリストの早期払い額の枠を利用するかを、チェックボックスのチェックにより選択できる（通常は、システム利用手数料が低い方が有利である）。

また、この例で、早期払い額として１３０万円を指定する場合、両方のリストの早期払い額の枠を利用する必要があるが、チェックボックスのチェックがどちらにもない場合、どちらのリストの早期払い額の枠をどれだけ用いるかは、取引管理システム１が自動的に決定する。例えば、システム利用手数料が低い方の早期払い額の枠から使いきるというルールを用いることができるが、その逆のルールであってもよい。また、例えば、早期払い上限額確認画面４３０において、商品等提供者が各リストの早期払い額の枠をそれぞれどれだけ利用するかを個別に指定できるようにしてもよい。

図２４は、図６に示した商品の確定と代金支払いにおいて、３社間ファクタリングを提供した状況において、本発明の第１実施形態に係る取引管理システム１を提供した様子を示している。この例では、商品の納品タイミングに関わらず、商品の受け入れが確定したタイミングで売掛債権の譲渡が行われ、その時点から、当該商品に対応する代金について早期払いが可能となる。

商品等提供者が納品した商品が、１月（当月）１０日に確定した場合（確定（１））、この確定に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この確定（１）の取引は、１月末締めで、３月（翌々月）１５日に本来の支払期日を迎えるものである。

このような確定（１）の取引により、商品等提供者は、確定したその日（１月１０日）にも、早期払いリクエストにより、確定（１）の商品に係る代金の一部を受領することができる。早期払いリクエスト「Ｒ」は、本実施形態では、上述のように、商品等提供者端末１０から取引管理サーバ３０に送信される。

また、このとき、確定の時点で商品等提供者からファクタリング会社に売掛債権が譲渡される。

さらに商品等提供者は、１月１５日に再び早期払いリクエストを行い、確定（１）の商品に係る代金の残りを受領することができる。

次に、商品等提供者が納品した別の商品が、１月（当月）２０日に確定したとする（確定（２））。そして、この確定に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この確定（２）の取引は、１月末締めで、３月（翌々月）１５日に本来の支払期日を迎えるものである。

ここで、商品等提供者は、２月２日に、早期払いリクエストにより、確定（１）の商品と確定（２）の商品に係る代金の一部を受領するものとする。確定（１）の商品に係る代金に残りがあれば、その枠の金額も早期払いリクエストに含むことができる。

また、確定（１）の商品と確定（２）の商品に係る代金の本来の支払期日は３月１５日であり、このような２月になっての早期払いは、１月の早期払いより支払期日までの期間が（月単位で考えると）１ヶ月短くなるので、システム利用手数料が１ヶ月分少なく設定されることになる。

次に、商品等提供者が納品した別の商品が、２月１０日に確定したとする（確定（３））。そして、この確定に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この確定（３）の取引は、２月末締めで、４月１５日に本来の支払期日を迎えるものである。

ここで、商品等提供者は、２月１２日に、早期払いリクエストにより、確定（１）の商品、確定（２）の商品、及び確定（３）の商品に係る代金の一部を受領するものとする。確定（１）、確定（２）の商品に係る代金に残りがあれば、その枠の金額も早期払いリクエストに含むことができる。

なお、この場合、１月に確定した確定（１）と確定（２）の取引に係る早期払い額と、２月に確定した確定（３）の取引に係る早期払い額とでは、上述したように、システム利用手数料が１ヶ月分（本実施形態では１％）異なる。本実施形態の取引管理システム１では、基本的に、早期払いリクエストで指定した早期払い額を、システム利用手数料が低い方から割り当てるようにするが、逆の割り当て方法（すなわち、システム利用手数料が高い、確定（１）と確定（２）の取引に係る代金の枠から割り当てる）を採用することもできる。また、商品等提供者が、早期払い額を、どの取引の代金の枠から割り当てるか指定するようにすることもできる。

次に、商品等提供者が納品した別の商品が、２月２２日に確定したとする（確定（４））。そして、この確定に係る取引情報が、取引先企業から取引管理システム１に提供される。なお、この確定（４）の取引は、２月末締めで、４月１５日に本来の支払期日を迎えるものである。

確定（１）の商品と確定（２）の商品に係る代金は、１月末で締められ、これらの取引に対応する売掛金が、（取引先企業からの請求に基づき）３月１５日に、取引先企業からファクタリング会社に支払われる。一方、確定（１）の商品と確定（２）の商品に係る代金のうち、早期払いの対象となっていない残りの金額は、３月１５日にファクタリング会社から商品等提供者に（通常払いとして）支払われる。

このように、３社間ファクタリングを設定したうえで、本発明の取引管理システム１を利用することによって、商品等提供者は、確定した商品に係る代金に対応する資金を、早期払いリクエストによって、本来の支払期日より前に、所望のタイミングで所望の額を回収することができる。商品等提供者は、早期払いリクエストによって随時、売掛金を現金化できるので、資金繰りの状況に応じて、適宜、早期払いリクエストを行うか否かを柔軟に判断することができる。

図２５は、上記で示したものとは別の、商品の確定、代金支払い、及び早期払いのパターンを示したものである。ここでも、上記と同様に、３社間ファクタリングが利用され、本発明の第１実施形態に係る取引管理システム１が適用される。

この例では、１ヶ月の多くの商品が納品されて報酬（代金）が発生し、基本的に、同月においてその商品が承認され、最終的に報酬が確定して確定報酬となる。図２５では、取引件数が多いため、個々の取引は図示しない。また、確定報酬は、確定した時点でその確定報酬の１００％が、早期払いとして利用可能であるものとする。

図２５に示す例では、商品等提供者が１月（当月）に２１７件の取引に係る商品を納品し、その月にすべての取引について承認がされ、確定報酬として１３０４５５円が発生している。２月（翌月）には、１０７４件の取引に係る商品を納品し、その月にすべての取引について承認がされ、確定報酬として５９７２６６円が発生している。３月（翌々月）には、２６件の取引に係る商品を納品し、その月にすべての取引について承認がされ、確定報酬として２０６９６円が発生している。

さらに、商品等提供者が１月より前に納品した商品の取引に係る承認が繰り越しとなり、結果的に、３月に承認され、そのタイミングで確定報酬が発生している。このような繰越承認件数は、この例では４件であり、確定報酬として１７５５円が発生している。

一方、商品等提供者は、商品等提供者端末１０によって早期払いリクエストを取引管理サーバ３０に送信している。この例では、１月に８万円の早期払い額を指定して早期払いリクエストを行い、２月に３０万円の早期払い額を指定して早期払いリクエストを行い、３月に２０万円の早期払い額を指定して早期払いリクエストを行っている。これらの早期払いリクエストにより、指定した早期払い額からシステム利用手数料と振込手数料を差し引いた額が、ファクタリング会社から商品等提供者の預金口座に振り込まれる。

また、このような状況において、１月末で締めた場合に、残金として５０４５５円が算出され、この金額が、３月１５日に、ファクタリング会社から商品等提供者の預金口座に振り込まれる。また、取引先企業からファクタリング会社に、１月の確定報酬に対応する金額が振り込まれる。

また、２月末で締めた場合に、残金として９７２６６円が算出され、この金額が、４月１５日に、ファクタリング会社から商品等提供者の預金口座に振り込まれる。この残金は、２月の確定報酬から、２月にされた早期払いリクエストの早期払い額を差し引き、さらに、その２月分の残金から、３月にされた早期払いリクエストの早期払い額を差し引いたものである。

また、３月末で締めた場合に、残金として、確定報酬そのままの、２０６９６円が算出され、この金額が、５月１５日に、ファクタリング会社から商品等提供者の預金口座に振り込まれる。この残金は、３月にされた早期払いリクエストの早期払い額が、２月の確定報酬からすでに支払われているため、３月分の確定報酬そのままの額となっている。また、繰越承認によって、３月に確定した確定報酬の１７５５円についても、５月１５日に、ファクタリング会社から商品等提供者の預金口座に振り込まれる。

図２５に示した商品の確定、代金支払い、及び早期払いの状況において、商品等提供者端末１０に表示される照会画面４５０が図２６に示されている。なお、ここでは、商品等提供者端末１０は据え置き型のパーソナルコンピュータであり、これに接続されたＬＣＤモニタに上記の照会画面が表示されている。また、照会画面４５０は、例えば、上述した早期払い上限額確認画面等とは別に、商品等提供者による商品等提供者端末１０の操作によって、ＬＣＤモニタに表示される。

図２６に示す照会画面４５０は、３月末の基準日において、直近３ヶ月の月ごとの確定報酬等を示しており、また、その時点での前払い可能額も示されている。

図２６の照会画面４５０には、主として確定報酬に関する事項を月ごとに示した表示エリア４５１と、主として前払いに関する事項を月ごとに示した表示エリア４５２が配置されている。それぞれの表示エリアでは、各取引が確定日を基準として月単位にまとめられ、基準日の月と、前月、前々月について、確定報酬や確定報酬残高等が計算され、示されている。

表示エリア４５１の「確定報酬」の項目は、この例では、それぞれ「発生報酬」と同じ値となっている。ここで、２０１８年３月の確定報酬は、２０６９６円であり、早期払いリクエストが無ければ、５月１５日に振り込まれる予定の額である。同様に、２０１８年２月の確定報酬は、５９７２６６円であり、早期払いリクエストが無ければ、４月１５日に振り込まれる予定の額である。また、２０１８年１月の確定報酬は、１３０４５５円であり、早期払いリクエストが無ければ、３月１５日に振り込まれる予定の額である。

また、表示エリア４５１の「繰越承認」に対応する「確定報酬」は、１７５５円であり、この額は、３月に承認され、確定した報酬であるため、早期払いリクエストが無ければ、５月１５日に振り込まれる予定である。

表示エリア４５２の「確定報酬」の項目は、表示エリア４５１の「確定報酬」に対応し、それぞれの月で同じ金額が表示されている。表示エリア４５２の「早期払い額」の項目は、商品等提供者による早期払いリクエストによって指定された早期払い額を月ごとに示したものである。上述したように、この例では、２０１８年３月に２０万円の早期払い額が指定され、２０１８年２月に３０万円の早期払い額が指定され、２０１８年１月に８万円の早期払い額が指定されている。

表示エリア４５２の「確定報酬残高」の項目は、確定報酬から早期払い額を差し引いた金額である。ここで、２０１８年３月の確定報酬残高は、確定報酬の１３０４５５円から早期払い額の８万円が差し引かれて、５０４５５円となっている。また、２０１８年２月の確定報酬残高は、確定報酬の５９７２６６円から、２月の早期払い額の３０万円と３月の早期払い額の２０万円が差し引かれて、９７２６６円となっている。また、２０１８年３月の確定報酬残高は、確定報酬の２０６９６円から、何も差し引かれずに（３月の早期払い額の２０万円は、２月の確定報酬から差し引かれている）、そのまま、２０６９６９円となっている。

そして、基準日が３月３１日であることを考慮すると、３月１５日にすでに支払われた残金（５０４５５）を除いた確定報酬残高の合計（すなわち、１７５５＋９７２６６＋２０６９６＝１１９７１７）が、早期払い可能額として、図２６の照会画面４５０に示されている。

なお、基準日が４月1日になると、２０１８年２月の確定報酬残高が、早期払い可能額の計算の対象外となるため、図２６の照会画面４５０に示される早期払い可能額は、２２４５１円となる。

表示エリア４５２の「早期払い振込金額」の項目は、商品等提供者による早期払いリクエストによって、ファクタリング会社から商品等提供者の預金口座に振り込まれた金額を表している。

表示エリア４５２の「規定振込日の振込金額」の項目は、これから早期払いリクエストによる早期払い額の支払いがない場合に、本来の支払期日に、ファクタリング会社から商品等提供者の預金口座に振り込まれる、又は振り込まれた金額を表している。この例では、５月１５日に振り込まれる予定の金額は、２０６９６９円＋１７５５円であり、４月１５日に振り込まれる予定の金額は、９７２６６円である。そして、３月１５日に振り込まれた金額は、５０４５５円である。

なお、この例では、２０１８年３月の早期払い額（２０万円）に関して、２０１８年２月の確定報酬から差し引くようにしたが、上述のように、直近の確定報酬、すなわち、２０１８年３月の確定報酬（２０６９６円）から先に利用することも可能である。

また、この例では、「早期払い振込金額」や「規定振込日の振込金額」に関して、説明を簡潔にするため、システム利用手数料や振込手数料の差し引き計算を省略している。

次に、図２７ないし図３６を参照して、本発明の第２実施形態に係る取引管理システム１’について説明する。

図２７は、本発明の第２実施形態の取引管理システムの概要を表している。図２７に示す本発明の第２実施形態に係る取引管理システム１’では、第１実施形態の取引管理システム１と同様に、商品等提供者が、自身の納品した商品等の代金に基づいて、一定額を、（取引先企業による）本来の支払期日より前に（３社間ファクタリングの仕組みにより）受領できるよう依頼することができる。

図２７に示す取引管理システム１’は、商品等提供者が利用する商品等提供者端末１０’、取引先企業により運営・管理される取引先企業サーバ５０、及びファクタリング会社により運営・管理される取引管理サーバ６０を含む。なお、ここでは、便宜上、取引管理システム１’が、上記の商品等提供者端末１０’、取引先企業サーバ５０、及び取引管理サーバ６０を含むものとして説明するが、取引管理システム１’を、商品等提供者端末１０’や取引先企業サーバ５０を含まないように構成することもできる。

取引管理システム１’は、上述した取引管理システム１の変形例としてとられることができるため、以下では、取引管理システム１と異なる部分を中心に説明する。

取引管理システム１’では、取引先企業が、商品等提供者から商品等の納品を受け付けた場合、ユーザ（取引先企業）が、取引先企業サーバ５０に接続された取引先企業端末２０’を操作することにより、その商品に係る取引情報（納品された商品等の納品日や代金）が、取引先企業サーバ５０から取引管理サーバ６０に送信される。また、商品等提供者から納品された商品等の受け入れが、取引先企業において確定した場合、取引先企業のユーザが、取引先企業端末２０’を操作することにより、その商品に係る取引情報（納品された商品等の確定日や代金）が取引先企業サーバ５０から取引管理サーバ６０に送信される。なお、商品等が納品された場合、又は商品等の受け入れが確定した場合のどちらかで、取引情報が取引管理サーバ６０に送信されるようにしてもよい。

取引管理サーバ６０は、取引先企業サーバ５０から受信した取引情報等に基づいて、商品等提供者に支払い可能な早期払い額を計算し、又さらに、取引先企業に請求する請求額を計算する。

商品等提供者は、商品等提供者端末１０’を操作し、必要に応じて、早期払いリクエストを、取引先企業サーバ５０を介して取引管理サーバ６０に送信する。取引管理サーバ６０は、早期払いリクエストを受信すると、当該リクエストに基づいて、商品等提供者に早期払い額を支払うよう決済処理を行う。

さらに、取引管理サーバ６０は、本来の支払期日に、商品等の代金請求に係るメッセージを取引先企業サーバ５０に送信する。取引先企業サーバ５０は（又は、取引先企業の事務処理等により）、取引管理サーバ６０からの商品等の代金請求に応じて決済処理を行う。

なお、図２７では、説明の便宜上、同じ金融機関に商品等提供者、取引先企業、及びファクタリング会社の預金口座が存在するように表記したが、預金口座は、それぞれ異なる金融機関であってもよい。また、決済方法についても、口座間振替以外の様々な方法を選択することができる。

上述のように、取引管理システム１’では、取引管理システム１とは異なり、商品等提供者端末１０’が、取引管理サーバ６０ではなく、取引先企業サーバ５０にアクセスし、早期払いリクエストは、取引先企業サーバ５０を経由して取引管理サーバ６０に送信される。

なお、商品等提供者端末１０’のハードウエア構成は、基本的に、図８に示す商品等提供者端末１０のハードウェア構成と同様である。また、取引先企業サーバ５０と取引管理サーバ６０のハードウエア構成は、基本的に、図９に示す取引管理サーバ３０のハードウェア構成と同様である。

次に、図２８の機能ブロック図を参照して、本発明の第２実施形態に係る取引管理システム１’における商品等提供者端末１０’の機能の概要について説明する。図２８に示すように、商品等提供者端末１０’は、アクセス制御部１５１’、早期払い情報表示制御部１５２’、早期払いリクエスト送信部１５３’、入出力制御部１５４、及びネットワークＩ／Ｆ部１５５を含んでいる。なお、図１０に示す商品等提供者端末１０と基本的に同様の機能部には、図１０で示したものと同じ符号を付し、その機能部に関する説明を省略する。

アクセス制御部１５１’は、商品等提供者端末１０’を操作するユーザが正当なユーザであるかを、取引先企業サーバ５０の判定結果に基づいてチェックする。正当なユーザである場合にのみログインが許可され、以降の処理が可能となる。

早期払い情報表示制御部１５２’は、ユーザの操作に応じて、取引先企業サーバ５０に早期払い情報リクエストを送信し、当該リクエストの応じて取引先企業サーバ５０から受信した（早期払い上限額や納品した商品の代金等を含む）早期払い情報表示用データを、商品等提供者端末１０’のタッチスクリーンに表示するよう制御する。

早期払いリクエスト送信部１５３’は、ユーザの操作に応じて、早期払いリクエストを取引先企業サーバ５０に送信する。

なお、アクセス制御部１５１’、早期払い情報表示制御部１５２’、及び早期払いリクエスト送信部１５３’は、商品等提供者端末１０’にインストールされた専用アプリケーションで実現できるが、一般的なＷＥＢブラウザにより取引先企業サーバ５０からｈｔｍｌ等を読み込むことで実現することも可能である。

次に、図２９の機能ブロック図を参照して、本発明の第２実施形態に係る取引管理システム１’における取引先企業サーバ５０の機能の概要について説明する。図２９に示すように、取引先企業サーバ５０は、アクセス制御部５５１、取引管理部５５２、リクエスト管理部５５３、請求書受付部５５４、及びネットワークＩ／Ｆ部５５５を含んでいる。また、外部記憶装置５６０には、商品等提供者管理テーブル５６１、取引管理テーブル５６２、及び早期払い管理テーブル５６３が記憶される。

アクセス制御部５５１は、アクセスしてきた商品等提供者端末１０’が正当なユーザによるものかを、商品等提供者管理テーブル５６１のテーブルを参照してチェックし、判定結果を商品等提供者端末１０’に返す。

取引管理部５５２は、接続された取引先企業端末２０’等から入力された取引情報（納品された商品等の納品日や代金、又は納品された商品等の確定日や代金を含む取引情報）を受信し、その情報を、取引管理テーブル５６２に記憶する。また、所定のタイミングで、受信した取引情報を、取引管理サーバ６０に送信する。

リクエスト管理部５５３は、商品等提供者端末１０’から早期払いリクエストを受信した場合に、その早期払いリクエストを取引管理サーバ６０に送信する。

また、リクエスト管理部５５３は、商品等提供者端末１０’から早期払い情報リクエストを受信した場合に、取引管理テーブル５６２や早期払い管理テーブル５６３を参照し、早期払い上限額や納品した商品の代金等を含んだ、早期払い情報表示用データを生成し、商品等提供者端末１０’に送信する。

請求書受付部５５４は、本来の支払期日に、取引管理サーバ６０から商品等の代金請求のメッセージを受信し、その後、必要に応じて、その代金請求に係る決済処理を行う。

ネットワークＩ／Ｆ部５５５は、インターネット等のネットワークに接続し、商品等提供者端末１０’や取引管理サーバ６０との間のデータ送受信を実現する。

次に、図３０の機能ブロック図を参照して、本発明の第２実施形態に係る取引管理サーバ６０の機能の概要について説明する。図３０に示すように、取引管理サーバ６０は、取引管理部６５１、リクエスト管理部６５２、早期払い上限額管理部６５３、決済処理制御部６５４、月次処理制御部６５５、及びネットワークＩ／Ｆ部６５６を含んでいる。また、外部記憶装置６６０には、取引先企業管理テーブル６６１、商品等提供者管理テーブル６６２、取引管理テーブル６６３、上限額設定テーブル６６４、手数料管理テーブル６６５、及び早期払い管理テーブル６６６が記憶される。

取引管理部６５１は、取引先企業サーバ５０から取引情報を受信し、その情報を、取引管理テーブル６６３に記憶する。これに連動して、早期払い上限額管理部６５３が、早期払い管理テーブル６６６の早期払い上限額を更新する。

リクエスト管理部６５２は、取引先企業サーバ５０から早期払いリクエストを受信した場合に、その早期払いリクエストに応じて、商品等提供者に早期払いを行うよう早期払い上限額管理部６５３、及び決済処理制御部６５４を制御する。

早期払い上限額管理部６５３は、取引先企業サーバ５０から受信した取引情報等に基づいて、早期払い上限額を決定して早期払い管理テーブル６６６を更新するとともに、取引先企業サーバ５０から早期払いリクエストを受信した場合に、早期払い管理テーブル６６６を参照して、受信した早期払いリクエストの金額が早期払い上限額以下であるか否かを判定する。

また、早期払い上限額管理部６５３は、早期払いリクエストによる早期払いが行われた場合に、早期払い管理テーブル６６６の早期払い上限額を更新する。

決済処理制御部６５４は、早期払い上限額管理部６５３により、受信した早期払いリクエストの金額が早期払い上限額以下であるとされた場合に、その金額を商品等提供者に支払うよう、例えば、全銀システム（全国銀行データ通信システム）のサーバ等に対して早期払い依頼のメッセージを送信する。また、早期払いの残金があれば、本来の支払期日において、その残金を商品等提供者に支払うよう、例えば、全銀システムのサーバ等に対して通常払い依頼のメッセージを送信する。

月次処理制御部６５５は、取引情報を記憶した取引管理テーブル６６３を参照して、本来の支払期日に、商品等の代金請求のメッセージを取引先企業サーバ５０に送信する。また、早期払い管理テーブル６６６等を参照して、本来の支払期日に支払うべき金額（早期払いの残金）を求め、決済処理制御部６５４により、その残金を通常払いとして商品等提供者に支払うよう制御する。この通常払いに連動して、早期払い上限額管理部６５３が、早期払い管理テーブル６６６の早期払い上限額を更新する。

なお、本実施形態では、月次処理制御部６５５により月次の処理が行われるものとしたが、これに限定されるものではない。この処理の実行タイミングは、それぞれの取引先企業が設定した支払期日のタイミングに応じて決定される。例えば、取引先企業が、商品等提供者に応じて異なる支払期日を設定している場合、その取引先企業についての上記処理は、月に複数回行われることになるし、また、１ヶ月ごとのサイクルで行われる必要もない。

ネットワークＩ／Ｆ部６５６は、取引管理サーバ６０のネットワークインタフェース等を制御して、インターネット等のネットワークに接続し、取引先企業サーバ５０との間のデータ送受信を実現する。

また、外部記憶装置６６０に記憶されている、取引先企業管理テーブル６６１、商品等提供者管理テーブル６６２、取引管理テーブル６６３、上限額設定テーブル６６４、手数料管理テーブル６６５、早期払い管理テーブル６６６はそれぞれ、取引先企業管理テーブル３６１、商品等提供者管理テーブル３６２、取引管理テーブル３６３、上限額設定テーブル３６４、手数料管理テーブル３６５、早期払い管理テーブル３６６と同様の構成である。

図３１Ａには、商品等提供者管理テーブル５６１の例が示されている。商品等提供者管理テーブル５６１は、商品等提供者の属性等を管理、記憶するもので、例えば、商品等提供者ＩＤ、名称、パスワードの各項目を記憶する。商品等提供者ＩＤは、商品等提供者を特定するための識別子である。

図３１Ｂには、取引管理テーブル５６２の例が示されている。取引管理テーブル５６２は、商品等提供者端末１０’から送信された取引情報を記憶するもので、例えば、取引先企業に商品等を納品した商品等提供者の商品等提供者ＩＤ、取引ＮＯ、商品ＩＤ、納品日、確定日、取引金額の各項目を記憶する。取引管理テーブル５６２には、本発明の第１実施形態に係る取引管理システム１の取引管理テーブル３６３と同様のデータが記憶される（ただし、取引管理テーブル５６２には、その取引先企業に関する商品等提供者の取引のみが記憶される）。

本実施形態では、各取引について１つの商品の商品ＩＤを記憶しているが、取引ＮＯに対応する取引が複数の商品を含む場合は、これに応じて複数の商品ＩＤを含むようにできる。

本実施形態では、商品等提供者による納品の際に、商品等提供者端末１０’から送信された取引情報に基づいて、取引管理テーブル５６２にレコードを挿入して納品日を記憶し、その後、取引先企業が（商品等の検収完了等によって）商品等の受け入れを確定させた際に入力した取引情報に基づいて、対応するレコードに確定日をセットする。また、取引先企業における支払条件によって、納品日に基づいて確定日が自動的に決定される場合は、納品の際に商品等提供者端末１０’から送信された取引情報に基づいて、納品日と確定日をセットするようにしてもよい。

図３２には、早期払い管理テーブル５６３の例が示されている。早期払い管理テーブル５６３は、商品等提供者ＩＤ、種別、取引ＮＯ、基準日、金額、早期払い上限額を記憶する。早期払い管理テーブル５６３には、本発明の第１実施形態に係る取引管理システム１の早期払い管理テーブル３６６と同様のデータが記憶される（ただし、早期払い管理テーブル５６３には、その取引先企業に関する商品等提供者の取引に関するレコードのみが記憶される）。

次に、図３３ないし図３６を参照して、本発明の第２実施形態に係る取引管理システム１’における各処理について説明する。なお、図３３ないし図３６は、取引管理システム１’の各処理に関する手順を説明するためのフローチャートであり、商品等提供者端末１０’、取引先企業サーバ５０、及び取引管理サーバ６０の処理が、それぞれ時間の経過とともに表されている。

図３３は、取引管理サーバ６０が、取引先企業サーバ５０から納品に係る取引情報を受信する、納品時処理の手順を示した図である。

最初に、商品等提供者から取引先企業に対して、商品、又はサービスの提供が行われると、取引先企業のユーザは、取引先企業端末２０’を操作して、取引先企業サーバ５０に、商品・サービスの納品に係る取引の内容を表す取引情報の入力を行う。

ここで、取引先企業サーバ５０は、こうして入力された取引情報を受信すると、この内容を取引管理テーブル５６２に記憶する（ステップＳ１０１）。取引情報には、例えば、取引先企業ＩＤ、商品等提供者ＩＤ、取引ＮＯ、取引金額、納品日等が含まれる。このような構成により、商品等提供者による商品等の納品がされた場合に、取引先企業サーバ５０の取引管理テーブル５６２の内容を、取引管理サーバ６０の取引管理テーブル６６３の内容と（当該取引先企業に関して）同期させることができる。

次に、取引先企業サーバ５０は、この取引情報を、取引管理サーバ６０に送信する（ステップＳ１０２）。また、取引先企業サーバ５０は、商品等提供者との取引内容を入力している自社システムとインタフェースを行って、商品等提供者に係る取引情報を取得し、所定のタイミングで取引管理サーバ６０に送信するように構成することもできる。

取引管理サーバ６０は、取引先企業サーバ５０から取引情報を受信すると、この内容を取引管理テーブル６６３に記憶する（ステップＳ１０３）。

次に、取引管理サーバ６０は、この取引情報に基づいて、早期払い上限額を決定する（ステップＳ１０４）。この早期払い上限額は、上限額設定テーブル６６４の納品日〜確定日の上限額比率に基づいて決定される。その後、取引管理サーバ６０は、決定された早期払い上限額を含むレコード（種別＝「納品」）を追加するよう、早期払い管理テーブル６６６を更新する（ステップＳ１０５）。

次に、取引管理サーバ６０は、決定された早期払い上限額を含むレコードを取引先企業サーバ５０に送信する（ステップＳ１０６）。

取引先企業サーバ５０は、取引管理サーバ６０から、決定された早期払い上限額を含むレコードを受信すると、そのレコードを早期払い管理テーブル５６３に追加する（ステップＳ１０７）。このような構成により、商品等提供者による商品等の納品がされた場合に、取引先企業サーバ５０の早期払い管理テーブル５６３の内容を、取引管理サーバ６０の早期払い管理テーブル６６６の内容と（当該取引先企業に関して）同期させることができる。

この後、商品等提供者端末１０’において、後述する早期払い上限額確認画面を表示させるよう指示すると、取引先企業サーバ５０へのアクセスによって、上記のように決定・記憶された早期払い上限額が、例えば、納品月と本来の支払期日ごとにまとめられて（すなわち、システム利用手数料が同じものにまとめられて）一覧表示される（ステップＳ１０８）。

図３４は、取引先企業サーバ５０が、自動的に確定タイミング到来をチェックする場合、及び取引先企業サーバ５０において商品の受け入れ確定に係る取引情報が入力された場合の確定時処理の手順を示した図である。

最初に、取引先企業サーバ５０が、新たに商品等提供者との取引に関して確定日入力処理を選択したか否かをチェックする（ステップＳ１２１）。確定日入力処理が選択されていないと判定された場合（ステップＳ１２１のＮＯ）、所定のタイミングにおいて確定日の自動更新処理を行う。すなわち、取引管理テーブル５６２に記憶されたレコードで、確定日がセットされていない取引を抽出し、それらの取引について、取引先企業における支払条件によって確定日が到来したか否かを判定し、確定日が到来している取引については、取引管理テーブル５６２の対応するレコードに当該確定日をセットする（ステップＳ１２２）。

その後、取引先企業サーバ５０は、決定された確定日を取引管理サーバ６０に送信する（ステップＳ１２３）。

確定日を受信した取引管理サーバ６０は、その確定日に基づいて取引管理テーブル６６３を更新する（ステップＳ１２４）。次に、ステップＳ１２５に進み、そこで、早期払い上限額を決定する。この早期払い上限額は、上限額設定テーブル６６４の確定日〜支払期日の上限額比率に基づいて決定される。その後、取引管理サーバ６０は、種別が「確定」のレコードを生成し、さらにそのレコードの早期払い上限額を変更し、このレコードを早期払い管理テーブル６６６に追加する（ステップＳ１２６）。

次に、取引管理サーバ６０は、決定された早期払い上限額を含むレコードを取引先企業サーバ５０に送信する（ステップＳ１２７）。

取引先企業サーバ５０は、取引管理サーバ６０から、決定された早期払い上限額を含むレコードを受信すると、そのレコードを早期払い管理テーブル５６３に追加する（ステップＳ１２８）。このような構成により、商品等提供者による商品等の取引が確定された場合に、取引先企業サーバ５０の早期払い管理テーブル５６３の内容を、取引管理サーバ６０の早期払い管理テーブル６６６の内容と（当該取引先企業に関して）同期させることができる。

この後、商品等提供者端末１０’において、後述する早期払い上限額確認画面を表示させるよう指示すると、取引先企業サーバ５０へのアクセスによって、上記のように決定・記憶された早期払い上限額が、例えば、納品月と本来の支払期日ごとにまとめられて（すなわち、システム利用手数料が同じものにまとめられて）一覧表示される（ステップＳ１２９）。

ステップＳ１２１において、確定日入力処理が選択されていると判定された場合（ステップＳ１２１のＹＥＳ）、取引先企業サーバ５０において、確定日入力による確定時処理を行う。

取引先企業のユーザが、商品・サービスの検収等を完了して、当該商品等の受け入れが確定した場合に、取引先企業のユーザは、取引先企業端末２０’を操作して、商品・サービスの確定に係る取引の内容を表す取引情報の入力を行う。

このために、取引先企業サーバ５０は、取引管理テーブル５６２を参照して、過去に送信された取引で確定日が入力されていないものを取得する（ステップＳ１３０）。

取引先企業サーバ５０は、確定日未入力取引を取引先企業端末２０’に表示し、そこで、取引先企業のユーザから、確定日の入力を受け付ける（ステップＳ１３１）。その後、取引先企業サーバ５０は、取引先企業端末２０’を介して受信した確定日を、取引管理テーブル５６２の対応するレコードにセットし、当該確定日を取引管理サーバ６０に送信する（ステップＳ１３２）。

取引先企業サーバ５０から確定日を受信した取引管理サーバ６０の処理は、確定日の自動更新処理の場合と同じである（ステップＳ１２４ないしステップＳ１２９）。

図３５は、取引管理サーバ６０が、商品等提供者端末１０’から早期払いリクエストを受信した場合の早期払いリクエスト（随時）処理の手順を示した図である。

最初に、商品等提供者（ユーザ）の操作により、後述する早期払い上限額表示画面の表示を指示すると（ステップＳ１４１）、商品等提供者端末１０’が、取引先企業サーバ５０に対して早期払い上限額表示画面のためのリクエストを送信する（ステップＳ１４２）。このリクエストには、その商品等提供者の商品等提供者ＩＤが含まれる。また、このとき、商品等提供者端末１０’からパスワード等が取引先企業サーバ５０に送信されてユーザ認証が行われ、取引先企業サーバ５０が商品等提供者管理テーブル５６１のパスワードと比較して正当なユーザであると判定した場合に、以降の処理が可能となる。

取引先企業サーバ５０が、早期払い上限額表示画面のためのリクエストを受信すると、早期払い管理テーブル５６３を参照して、商品等提供者ＩＤに対応する早期払い上限額を特定し、その情報を商品等提供者端末１０’に送信する（ステップＳ１４２）。

商品等提供者端末１０’は、早期払い上限額に関する情報を取引先企業サーバ５０から受信すると、その情報に基づいて、図２２Ａに示したような早期払い上限額表示画面をタッチスクリーンに表示する（ステップＳ１４３）。

その後、商品等提供者端末１０’は、ユーザの操作により、図２２Ｂに示したような早期払いリクエスト画面をタッチスクリーンに表示し、そこでユーザが早期払いリクエストの送信を指示すると、これに応じて、取引先企業サーバ５０に早期払いリクエストを送信する（ステップＳ１４４）。この早期払いリクエストには、ユーザが指定した早期払い額が含まれる。

取引先企業サーバ５０は、商品等提供者端末１０’から早期払いリクエストを受信すると、早期払い管理テーブル５６３の早期払い上限額を参照して、早期払いリクエストに指定された早期払い額が、早期払い上限額以下か否かを判定する（ステップＳ１４５）。早期払い額が早期払い上限額以下でない場合（ステップＳ１４５のＮＯ）、早期払い額が上限を超えた旨のエラーメッセージを生成し、商品等提供者端末１０’に送信する（ステップＳ１４６）。商品等提供者端末１０’は、このエラーメッセージを受信すると、それをタッチスクリーンに表示する（ステップＳ１４７）。

一方、早期払い額が早期払い上限額以下であると判定された場合（ステップＳ１４５のＹＥＳ）、取引先企業サーバ５０は、早期払いリクエストを取引管理サーバ６０に送信する（ステップＳ１４８）。

取引管理サーバ６０は、早期払いリクエストを受信すると、このリクエストに基づいて、指定された早期払い額を、商品等提供者の預金口座にあてて振り込むための早期払い依頼を所定のサーバに送信する（ステップＳ１４９）。

なお、早期払いリクエストに指定された早期払い額が、早期払い上限額以下か否かを判定する場合、商品等提供者が負担するシステム利用手数料が差し引かれる関係上、このシステム利用手数料を考慮して上記判定を行う必要がある。例えば、早期払い管理テーブル６６６の早期払い上限額が１０万円であって、早期払いリクエストに指定された早期払い額も１０万円である場合、システム利用手数料を差し引くことができないので、早期払いリクエストがエラーとなる。

また、このような場合、早期払いリクエストに指定された早期払い額から自動的にシステム利用手数料を差し引いて、指定する預金口座に振り込むようにしてもよい。また、上限額設定テーブル６６４によって、対応する期間の早期払い上限額比率が１００％でない場合に、上限額として設定された枠以外の金額に対してシステム利用手数料がチャージされるようにしてもよい。また、システム利用手数料が差し引かれることを加味して、早期払い上限額が設定されるようにしてもよい。

次に、取引管理サーバ６０は、商品等提供者の預金口座にあてて振り込んだ早期払い額に基づいて、早期払い管理テーブル６６６の早期払い上限額を減算し、早期払い管理テーブル６６６を更新する（ステップＳ１５０）。

その後、取引管理サーバ６０は、早期払い上限額の更新を指示するための上限額更新指示と、早期払い額の振込手続が完了した旨の振込完了メッセージを生成し、これらを取引先企業サーバ５０に送信する（ステップＳ１５１）。

取引先企業サーバ５０は、取引管理サーバ６０から、上限額更新指示を受信すると、それに基づいて早期払い管理テーブル５６３を更新する（ステップＳ１５２）。このような構成により、商品等提供者から早期払いリクエストがされた場合に、取引先企業サーバ５０の早期払い管理テーブル５６３の内容を、取引管理サーバ６０の早期払い管理テーブル６６６の内容と（当該取引先企業に関して）同期させることができる。

また、取引先企業サーバ５０は、取引管理サーバ６０から、振込完了メッセージを受信すると、これを商品等提供者端末１０’に送信する（ステップＳ１５３）。商品等提供者端末１０’は、この振込完了メッセージを受信すると、それをタッチスクリーンに表示する（ステップＳ１５４）。

図３６は、取引管理サーバ６０が実行する月次処理の手順を示した図である。なお、本実施形態では、取引先企業における本来の支払いタイミングが毎月末や毎月１５日としているため、そのタイミングで月次処理が行われるが、取引先企業の支払いタイミングに合わせて、適宜この処理を実行することができる。

月次処理では、最初に、取引管理サーバ６０が、取引先企業管理テーブル６６１の支払い条件や取引管理テーブル６６３の各取引を参照して、取引先企業ごとに請求額を決定する（ステップＳ１７１）。

次に、取引管理サーバ６０は、決定された請求額に基づいて請求書を作成し、取引先企業サーバ５０に請求書を送信し、請求額を通知する（ステップＳ１７２）。取引先企業サーバ５０は、受信した請求書の請求額を取引管理テーブル５６２等を参照してチェックし（ステップＳ１７３）、正しい請求額か否かを判定する（ステップＳ１７４）。

ここで、取引先企業サーバ５０が、正しい請求額でないと判定した場合（ステップＳ１７４のＮＯ）、取引先企業端末２０’にエラーメッセージを表示する（ステップＳ１７５）。一方、取引先企業サーバ５０が、正しい請求額であると判定した場合（ステップＳ１７４のＹＥＳ）、請求額をファクタリング会社に振り込むための振込依頼を所定のサーバに送信する（ステップＳ１７６）。

なお、本実施形態では、取引先企業サーバ５０が、受信した請求額をチェックし、その請求額が正しい場合に振込依頼の送信までを行うようにしたが、そのすべて、又は一部を手作業により行うようにしてもよい。

取引管理サーバ６０は、ステップＳ１７２の後、取引先企業の本来の支払期日までに早期払いリクエストがされなかった残り金額（残金）を、早期払い管理テーブル６６６を参照して算出する（ステップＳ１８１）。ここで、残り金額があるか否かを判定し（ステップＳ１８２）、残り金額がある場合（ステップＳ１８２のＹＥＳ）、その残り金額を商品等提供者の預金口座に振り込むための通常払い依頼を、所定のサーバに送信する（ステップＳ１８３）。

なお、本実施形態では、支払期日の１０日前や１週間前といったタイミングで（すなわち、本来の支払期日の直前において）、早期払いのリクエストを不可とすることができ、その場合には、このような支払期日の１０日前や１週間前の時点で、関連する取引先企業への請求額や、商品等提供者への通常払いの額が確定している。したがって、このようなタイミングにおいても、ステップＳ１７１の請求額の決定や、ステップＳ１８３の通常払い依頼の送信を行うことができる。

その後、取引管理サーバ６０は、早期払い上限額の更新を指示するための上限額更新指示と、通常払いの振込手続が完了した旨の振込完了メッセージを生成し、これらを取引先企業サーバ５０に送信する（ステップＳ１８４）。

取引先企業サーバ５０は、取引管理サーバ６０から、上限額更新指示を受信すると、それに基づいて早期払い管理テーブル５６３を更新する（ステップＳ１８５）。このような構成により、月次処理が行われた場合に、取引先企業サーバ５０の早期払い管理テーブル５６３の内容を、取引管理サーバ６０の早期払い管理テーブル６６６の内容と（当該取引先企業に関して）同期させることができる。

また、取引先企業サーバ５０は、取引管理サーバ６０から、振込完了メッセージを受信すると、これを商品等提供者端末１０’に送信する（ステップＳ１８６）。商品等提供者端末１０’は、この振込完了メッセージを受信すると、それをタッチスクリーンに表示する（ステップＳ１８７）。

ステップＳ１８３の後、取引管理サーバ６０は、早期払い管理テーブル６６６に、種別＝「通常払い」のレコードを追加する（ステップＳ１８８）。結果として、これで、対象の納品月と本来の支払期日に関する早期払い上限額がゼロとなる。また、このタイミングで、各取引に関し、本来の支払期日までの長さが月単位で変化し、それに応じてシステム利用手数料が変化するため、システム利用手数料が差し引かれることを加味して早期払い上限額が設定されている場合は、こうしたシステム利用手数料の変化に応じて、早期払い上限額を変更する必要がある。

ステップＳ１８２において、残り金額がないと判定された場合（ステップＳ１８２のＮＯ）、取引管理サーバ６０は、ステップＳ１８９に進み、そこで、通常払いがない旨のメッセージを生成し、取引先企業サーバ５０に送信する（ステップＳ１８９）。取引先企業サーバ５０は、取引管理サーバ６０から、上記メッセージを受信すると、これを商品等提供者端末１０’に送信する（ステップＳ１９０）。商品等提供者端末１０’は、このメッセージを受信すると、それをタッチスクリーンに表示する（ステップＳ１８７）。

次に、図３７、図３８を参照して、本発明の第３実施形態に係る取引管理システム１’’について説明する。

図３７は、本発明の第３実施形態の取引管理システムの概要を表している。図３７に示す本発明の第３実施形態に係る取引管理システム１’’では、第１実施形態の取引管理システム１とは異なり、３者間ファクタリングの仕組みを用いない。ここでは、商品等提供者が、自身の納品した商品等の代金に基づいて、一定額を、（取引先企業による）本来の支払期日より前に、取引先企業から支払わせるように依頼することができる。

図３７は、本発明の第３実施形態の取引管理システムの概要を表している。図３７に示す本発明の第３実施形態に係る取引管理システム１’’では、商品等提供者が、自身の納品した商品等の代金に基づいて、一定額を、（取引先企業による）本来の支払期日より前に受領できるよう依頼することができる。本明細書では、このような、本来の支払期日より前の、商品等提供者に対する支払いを「早期払い」と称する。また、商品等提供者による早期払いのための、取引管理システム１’’に対する依頼を「早期払いリクエスト」と称する。

図３７に示す取引管理システム１’’は、商品等提供者が利用する商品等提供者端末１０’’、取引先企業により運営・管理される取引先企業端末２０’’、及び取引管理会社により運営・管理される取引管理サーバ７０を含む。第３実施形態では、３者間ファクタリングの仕組みは利用されないため、取引管理サーバ７０は、第三者企業である取引管理会社によって運営・管理される。取引管理会社は、取引管理サーバ７０により、商品等提供者からの依頼に応じて、取引先企業の口座から所定金額を商品等提供者に振り込むよう管理するものであり、その点で、事務代行会社といえる。

なお、ここでは、便宜上、取引管理システム１’’が、上記の商品等提供者端末１０’’、取引先企業端末２０’’、及び取引管理サーバ７０を含むものとして説明するが、取引管理システム１’’を、商品等提供者端末１０’’や取引先企業端末２０’’を含まないように構成することもできる。

取引先企業が、商品等提供者から商品等の納品を受け付けた場合、ユーザ（取引先企業）が、取引先企業端末２０’’を操作することにより、その商品に係る取引情報（納品された商品等の納品日や代金）が取引管理サーバ７０に送信される。また、商品等提供者から納品された商品等の受け入れが、取引先企業において確定した場合（すなわち、取引が確定した場合）、取引先企業のユーザが、取引先企業端末２０’’を操作することにより、その商品に係る取引情報（納品された商品等の確定日や代金）が取引管理サーバ７０に送信される。なお、商品等が納品された場合、又は商品等の受け入れが確定した場合のどちらかで、取引情報が取引管理サーバ７０に送信されるようにしてもよい。また、こうした取引情報、又は取引情報の元となる情報は、商品等提供者端末１０’’から送信されるようにしてもよい。商品等提供者端末１０’’から送信される取引情報等は、例えば、取引先企業から承認された情報である。

取引管理サーバ７０は、取引先企業端末２０’’から受信した取引情報等に基づいて、商品等提供者に支払い可能な早期払い額を計算する。なお、第１実施形態の取引管理サーバ３０は、取引先企業に請求する請求額を計算し、請求する処理を行うが、本実施形態では必要ない。

商品等提供者は、商品等提供者端末１０’’を操作し、必要に応じて、早期払いリクエストを取引管理サーバ７０に送信する。取引管理サーバ７０は、早期払いリクエストを受信すると、当該リクエストに基づいて決済処理を行う。この決済処理は、例えば、取引先企業の預金口座から商品等提供者の預金口座にリクエストされた金額を振り込むよう、所定のサーバに早期払い依頼のメッセージを送信する。また、早期払いの残金があれば、本来の支払期日に決済処理を行う。例えば、その残金を、取引先企業の預金口座から商品等提供者の預金口座に振り込むよう、所定のサーバに通常払い依頼のメッセージを送信する。

なお、ここでは、取引管理会社が、取引先企業に代わって、取引先企業の口座から商品等提供者の預金口座に、早期払いに係るリクエストされた金額や通常払いの金額を振り込むが、このような処理は、例えば、取引管理会社、取引先企業、及び取引先企業の口座の金融機関が、事前に契約や取り決めを行うことによって実現可能である。

なお、図３７では、説明の便宜上、同じ金融機関に商品等提供者、及び取引先企業の預金口座が存在するように表記したが、預金口座は、それぞれ異なる金融機関であってもよい。また、決済方法についても、口座間振替以外の様々な方法を選択することができる。

また、取引管理システム１’’では、システム利用手数料を商品等提供者から徴収することができ、取引管理サーバ７０を運営・管理する取引管理会社は、この手数料を受け取るように設定できる。また、取引管理システム１’’では、取引先企業が、商品等の代金の少なくとも一部を、本来の支払期日より前に商品等提供者に支払うこととなるため、このような早期払いに対して、所定の手数料を商品等提供者から徴収するように設定することもできる。

図３７に示した商品等提供者端末１０’’の構成は、図８、図１０に示した、第１実施形態の商品等提供者端末１０と同様である。また、図３７に示した取引先企業端末２０’’の構成は、図８、図１１に示した、第１実施形態の取引先企業端末２０と同様である。

また、図３７に示した取引管理サーバ７０の構成は、図９、図１２に示した、第１実施形態の取引管理サーバ３０と基本的に同様であるが、上述の通り、取引先企業の口座から商品等提供者の預金口座に、早期払いに係るリクエストされた金額や通常払いの金額を振り込むよう制御するとともに、取引先企業へ商品等の代金請求を行わないように制御される。

図３７に示した取引管理システム１’’に関しては、上記のような第１実施形態との相違点を考慮したうえで、図１３〜図１５に示した取引管理サーバ３０の各テーブルを取引管理サーバ７０のテーブルとして読み替えることができ、同様に、図１６〜図１９に示した取引管理システム１における各処理を取引管理システム１’’における処理として読み替えることができる。

次に、図３８を参照して、図５Ｂに示した商品の納品、確定と代金支払いにおいて、本発明の第３実施形態に係る取引管理システム１’’を提供した様子を示している（ただし、ここでは、図５Ｂに示されるような売掛債権の譲受・支払はなく、また、取引先企業からファクタリング企業への売掛金支払もない）。

商品等提供者が、１月（当月）１０日に商品を納品した場合（納品（１））、この納品に係る取引情報が、取引先企業から取引管理システム１’’に提供される。なお、この納品（１）の取引は、２月（翌月）１０日に確定され、３月（翌々月）末に本来の支払期日を迎えるものである。

このような納品（１）の取引により、商品等提供者は、納品したその日（１月１０日）にも、早期払いリクエストにより、納品（１）の商品に係る代金の一部を受領することができる。早期払いリクエスト「Ｒ」は、本実施形態では、上述のように、商品等提供者端末１０’’から取引管理サーバ７０に送信される。また、早期払いリクエストで指定した金額は、即時に商品等提供者の口座に振り込まれるようにしてもよいし、翌営業日や翌々営業日など、早期払いリクエスト後の所定のタイミングで振り込まれるようにしてもよい。

また、商品等提供者の口座に振り込まれる金額は、早期払いリクエストで指定した金額から取引管理システム１’’のシステム利用手数料を差し引いた額であるが、早期払いリクエストで指定した金額がそのまま商品等提供者の口座に振り込まれるようにし、システム利用手数料は、商品等提供者の残りの代金（売掛金）から徴収するようにしてもよい。なお、早期払いリクエストで指定した金額からシステム利用手数料を差し引く場合は、早期払いリクエストのたびにシステム利用手数料が徴収されることになるが、システム利用手数料を残りの代金から徴収する場合は、取引管理システム１’’の内部でシステム利用手数料を累計しておき、所定のタイミングでまとめて徴収するようにしてもよい。

次に、商品等提供者が、１月（当月）２０日に商品を納品したとする（納品（２））。そして、この納品に係る取引情報が、取引先企業から取引管理システム１’’に提供される。なお、この納品（２）の取引は、２月（翌月）２０日に確定され、３月（翌々月）末に本来の支払期日を迎えるものである。

納品（１）の商品の確定に係る取引情報が、取引先企業から取引管理システム１’’に提供され、２月１０日にこの納品（１）が確定する（確定（１））。その後、商品等提供者が、２月１２日に商品を納品し（納品（３））、この納品に係る取引情報が、取引先企業から取引管理システム１’’に提供される。なお、この納品（３）の取引は、３月１２日に確定され、４月末に本来の支払期日を迎えるものである。

その後、納品（２）の商品の確定に係る取引情報が、取引先企業から取引管理システム１’’に提供され、２月２０日にこの納品（２）が確定する（確定（２））。よって、その後の早期払いリクエストでは、納品（２）の取引が確定され、確定（２）となっているため、早期払い上限額がその分増加している（上限額設定テーブル３６４参照）。

確定（１）の商品と確定（２）の商品に係る代金は、２月末で締められ、確定（１）の商品と確定（２）の商品に係る代金のうち、早期払いの対象となっていない残りの金額は、３月末に商品等提供者に（通常払いとして）支払われる。

このように、本発明の取引管理システム１’’を利用することによって、商品等提供者は、納品した商品に係る代金に対応する資金を、早期払いリクエストによって、本来の支払期日より前に、所望のタイミングで所望の額を回収することができる。商品等提供者は、早期払いリクエストによって随時、売掛金を現金化できるので、資金繰りの状況に応じて、適宜、早期払いリクエストを行うか否かを柔軟に判断することができる。

ここまで、本発明の第１実施形態に係る取引管理システム１、第２実施形態に係る取引管理システム１’、第３実施形態に係る取引管理システム１’’について、具体的な構成例を示しながら説明してきたが、これらの実施形態は一例に過ぎない。上記以外の様々な構成によって、本発明の取引管理システムを実現することができる。

また、本明細書では、商品等の取引に関する取引金額について、説明を簡潔にするために消費税の記載を省略したが、実際に本発明の取引管理システムが適用される場合には、当然ながら消費税を含んだ取引金額が扱われることになる。

また、本発明の第１実施形態に係る取引管理システム１では、取引管理サーバ３０によって本発明の特徴的な構成の少なくとも一部が実現されるが、このような取引管理サーバ３０が、（例えば、機能毎に１台のコンピュータが利用され）複数のコンピュータによって構成されてもよい。同様に、第２実施形態に係る取引管理システム１’の取引先企業サーバ５０や取引管理サーバ６０、第３実施形態に係る取引管理システム１’’の取引管理サーバ７０も、複数のコンピュータによって構成することができる。

また、本発明の第１実施形態に係る取引管理システム１や、第３実施形態に係る取引管理システム１’’に関する説明では、商品等提供者が１つの取引先企業と取引した場合の状況を前提としたが、商品等提供者が２つ以上の取引先企業と取引した場合にも、本発明の取引管理システムを適用することができる。例えば、早期払い上限額の表示や、早期払いリクエストの送信を、取引先企業ごとに管理して実現することができる。また、複数の取引先企業に亘って（複数の取引先企業に関する取引を統合した形で）、納品月（又は確定月）ごと、支払期日ごとに早期払い上限額を表示したり、早期払いリクエストの送信を可能としたりすることもできる。

１，１’，１’’・・・取引管理システム
１０，１０’，１０’’・・・商品等提供者端末
２０，２０’，２０’’・・・取引先企業端末
３０，６０，７０・・・取引管理サーバ
５０・・・取引先企業サーバ

Claims

第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理手段は、前記所定金額を前記第２ユーザに支払う場合に、前記第２ユーザが負担する手数料の金額を決定し、
前記手数料の金額は、前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されることを特徴とする取引管理システム。
前記リクエスト管理手段は、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されることを特徴とする、請求項１に記載の取引管理システム。
前記リクエスト管理手段は、
前記取引を、その納品日又は確定日に基づいて所定期間の単位にまとめて、前記所定期間ごとの早期払い可能額を算出し、
前記早期払い可能額を表示するための表示データを、前記第２ユーザによる前記コンピュータの操作に応じて、前記コンピュータに送信することを特徴とする、請求項１又は２に記載の取引管理システム。
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われることを特徴とする、請求項１ないし３のいずれかに記載の取引管理システム。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理ステップは、前記所定金額を前記第２ユーザに支払う場合に、前記第２ユーザが負担する手数料の金額を決定し、
前記手数料の金額は、前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されることを特徴とする、取引管理方法。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理手段は、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されることを特徴とする取引管理システム。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記リクエスト管理ステップは、前記早期払いリクエストが所定条件を満たす場合に、前記所定金額を前記第２ユーザに支払うよう制御し、
前記所定条件は、前記早期払いリクエストの指定額に関する金額の上限についての条件を含み、
前記上限についての条件は、
前記金額情報、
支払い済みの前記所定金額、又は支払い済みの前記所定金額に係る前記早期払いリクエストの指定額、及び、
前記早期払いリクエストの受信タイミング又は前記早期払いリクエストによる前記所定金額の支払いタイミングに基づいて決定されることを特徴とする取引管理方法。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムであって、
前記取引管理サーバは、
前記取引に関する取引情報を受信する取引情報受信手段と、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信手段と、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理手段とを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われることを特徴とする取引管理システム。
第１ユーザと第２ユーザとの間の取引に関し、前記第２ユーザに対する報酬の少なくとも一部を、本来の支払期日より早期に支払う早期払いを可能とする取引管理サーバを備えた取引管理システムで実行される取引管理方法であって、
前記取引管理サーバにおいて実行される、
前記取引に関する取引情報を受信する取引情報受信ステップと、
前記第２ユーザが利用するコンピュータでの操作に基づいて送信される早期払いリクエストを受信するリクエスト受信ステップと、
前記早期払いリクエストを受信した場合に、前記早期払いリクエストの指定額に基づいて、所定金額を前記第２ユーザに支払うよう制御するリクエスト管理ステップとを含み、
前記取引情報は、前記報酬に関する金額情報を含み、
前記第１ユーザと前記第２ユーザは、所定事業者とファクタリング契約を締結し、
前記取引に係る前記第２ユーザの債権は、前記所定事業者に譲渡され、
前記所定金額は、前記所定事業者から、前記第２ユーザに支払われることを特徴とする取引管理方法。