JP2021047915A - 情報処理方法、プログラム及び情報処理装置 - Google Patents

Abstract

【課題】個人ユーザであってもファクタリングサービスを利用することができる情報処理方法等を提供する。【解決手段】情報処理方法は、ユーザから取引の相手方に対して発行された複数の請求書の一覧を表示部に表示し、前記複数の請求書から、売掛債権の買取を申し込む前記請求書を選択する選択入力を受け付け、選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する処理をコンピュータに実行させる。【選択図】図１

Description

本発明は、情報処理方法、プログラム及び情報処理装置に関する。

金融サービスの一つに、債権者の売掛債権を買い取り、債務者から売掛金を回収するファクタリングサービスがある。例えば特許文献１では、電子記録債権法に規定された電子記録債権のファクタリングを行うファクタリングシステムが開示されている。

特開２０１５−２０４０６３号公報

しかしながら、特許文献１に記載されているように、一般的にファクタリングは法人の間で行われるものであり、個人がファクタリングサービスを利用することが困難だった。

一つの側面では、個人ユーザであってもファクタリングサービスを利用することができる情報処理方法等を提供することを目的とする。

一つの側面では、情報処理方法は、ユーザから取引の相手方に対して発行された複数の請求書の一覧を表示部に表示し、前記複数の請求書から、売掛債権の買取を申し込む前記請求書を選択する選択入力を受け付け、選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する処理をコンピュータに実行させる。

一つの側面では、個人ユーザであってもファクタリングサービスを利用することができる。

ファクタリングシステムの構成例を示す模式図である。 サーバの構成例を示すブロック図である。 ユーザＤＢ、請求書ＤＢ、ユーザ評価テーブル、及びクライアント評価テーブルのレコードレイアウトの一例を示す説明図である。 取引評価テーブル、取引クラスタＤＢ、及び資料判定テーブルのレコードレイアウトの一例を示す説明図である。 手数料評価テーブル及び手数料クラスタＤＢのレコードレイアウトの一例を示す説明図である。 ファクタリングシステムの概要を示す説明図である。 請求書の一覧画面の一例を示す説明図である。 取引資料の送信処理に関する説明図である。 サーバが実行する処理手順の一例を示すフローチャートである。 ファクタリングのサブルーチンの処理手順を示すフローチャートである。

以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態）
図１は、ファクタリングシステムの構成例を示す模式図である。本実施の形態では、個人ユーザ向けのファクタリングサービスを提供するファクタリングシステムについて説明する。ファクタリングシステムは、情報処理装置１、端末２、２、２…を有する。各装置は、インターネット等のネットワークＮを介して通信接続されている。

情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態では情報処理装置１がサーバ装置であるものとし、以下の説明では簡潔のため、情報処理装置１をサーバ１と読み替える。サーバ１は、本システムに係るファクタリングサービスを管理する管理装置であり、ファクタリングに利用する金融口座の管理、ファクタリングに伴う審査、ユーザへの送金等の処理を行う。

後述するように、本実施の形態でサーバ１は、個人ユーザ向けのファクタリングを行う。具体的には、サーバ１は、個人ユーザ（個人事業主等）と、ユーザに依頼して商品等の納品を受ける取引の相手方（以下では「クライアント」と呼ぶ）との間の取引について、当該取引によって発生する売掛債権を買い取り、売掛金から手数料を差し引いた金額をユーザに支払うファクタリングを行う。

端末２は、本サービスを利用する各ユーザの端末装置であり、例えば多機能端末、パーソナルコンピュータ等の情報処理装置である。例えば各端末２にはサーバ１が提供する本サービス専用のアプリケーションプログラムがインストールされており、各ユーザは当該アプリケーション上でファクタリングの申込、情報の閲覧等を行う。

図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、及び補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰを読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための処理回路等を含み、端末２等と情報の送受信を行う。

補助記憶部１４は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラムＰ、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１、請求書ＤＢ１４２、ユーザ評価テーブル１４３、クライアント評価テーブル１４４、取引評価テーブル１４５、取引クラスタＤＢ１４６、資料判定テーブル１４７、手数料評価テーブル１４８、手数料クラスタＤＢ１４９を記憶している。

ユーザＤＢ１４１は、各ユーザの情報を格納するデータベースである。請求書ＤＢ１４２は、各ユーザが取引の相手方に対して発行した請求書のデータを格納するデータベースである。ユーザ評価テーブル１４３は、ユーザの与信評価を行うためのテーブルである。クライアント評価テーブル１４４は、取引の相手方であるクライアントの与信評価を行うためのテーブルである。取引評価テーブル１４５は、ユーザ及びクライアントの与信情報に基づき、ファクタリングを行う上でユーザとクライアントとの間の取引がどの程度信用できるか、信用の度合いを評価するためのテーブルである。

取引クラスタＤＢ１４６は、取引評価テーブル１４５による評価に応じて段階的に区分される、取引の信用度合いを表す区分（以下では「取引クラスタ」と呼ぶ）の情報を格納したデータベースである。資料判定テーブル１４７は、取引の審査に必要な取引資料の情報を格納したテーブルである。手数料評価テーブル１４８は、取引クラスタと、取引額とに応じて、ファクタリングの手数料を評価するためのテーブルである。手数料クラスタＤＢ１４９は、手数料評価テーブル１４８による評価に応じた手数料の区分（以下では「手数料クラスタ」と呼ぶ）に関する情報を格納したデータベースである。

なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであってもよく、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。

また、本実施の形態においてサーバ１は上記の構成に限られず、例えば可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。

図３は、ユーザＤＢ１４１、請求書ＤＢ１４２、ユーザ評価テーブル１４３、及びクライアント評価テーブル１４４のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１４１は、ユーザＩＤ列、氏名列、ユーザ情報列、個人口座列、ファクタリング口座列、口座連携列、会計連携列を含む。ユーザＩＤ列は、各ユーザを識別するための識別情報を記憶している。氏名列は、ユーザＩＤと対応付けて、ユーザの氏名を記憶している。個人口座列は、ユーザＩＤと対応付けて、個人ユーザが所定の金融機関に開設している金融口座であって、ユーザがファクタリングの代金（買取額）の送金先として設定した金融口座（以下では「個人口座」と呼ぶ）の情報を記憶している。ファクタリング口座列は、ユーザＩＤと対応付けて、本実施の形態に係るファクタリングサービスを受けるための振込専用口座であるファクタリング口座の情報を記憶している。ファクタリング口座は、本システムの管理者の金融口座に関連付けられた金融口座であって、管理者の金融口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された、金融機関のシステムにおける仮想的な振込専用口座である。口座連携列は、ユーザＩＤと対応付けて、ユーザの個人口座の入出金情報を本システムと連携するか否かについて、ユーザによる許諾の有無を記憶している。会計連携列は、ユーザＩＤと対応付けて、ユーザが使用している所定の会計ソフトウェアと連携してサーバ１に請求書のデータをアップロードするか否かについて、ユーザによる設定の有無を記憶している。

請求書ＤＢ１４２は、請求書ＩＤ列、ユーザ列、クライアント列、取引金額列、請求日列、期限列、即日決済列、買取額列を含む。請求書ＩＤ列は、各請求書を識別するための識別情報を記憶している。ユーザ列は、請求書ＩＤと対応付けて、請求書の発行者であるユーザのユーザＩＤを記憶している。クライアント列は、請求書ＩＤと対応付けて、請求先であるクライアントの識別情報を記憶している。取引金額列は、請求書ＩＤと対応付けて、ユーザとクライアントとの間の取引金額、つまり請求書の請求額を記憶している。請求日列は、請求書ＩＤと対応付けて、請求日を記憶している。期限列は、請求書ＩＤと対応付けて、売掛金の支払期限を記憶している。即日決済列は、請求書ＩＤと対応付けて、本サービスを利用してファクタリング（即日決済）を行ったか否かを記憶している。なお、即日決済列の「審査中」は、ファクタリングを認証するか否か、管理者が審査中であることを意味している。買取額列は、請求書ＩＤと対応付けて、ファクタリングを行った場合の買取額を記憶している。

ユーザ評価テーブル１４３は、スコア列、格付け列、状態列、判断基準列、取引限度列を含む。スコア列は、ユーザの与信情報を数値化したスコアを記憶している。格付け列は、スコアと対応付けて、スコアに応じてユーザに与えられる格付けを記憶している。状態列は、スコアと対応付けて、ユーザの与信情報を表すステータスを記憶している。判断基準列は、スコアと対応付けて、スコアの算定基準とする各種条件を記憶している。取引限度列は、スコアと対応付けて、ユーザの与信情報に応じて承認する取引限度額を記憶している。

クライアント評価テーブル１４４は、スコア列、格付け列、状態列、判断基準列を含む。スコア列は、クライアントの与信情報を数値化したスコアを記憶している。格付け列は、スコアと対応付けて、スコアに応じてクライアントに与えられる格付けを記憶している。状態列は、スコアと対応付けて、クライアントの与信情報を表すステータスを記憶している。判断基準列は、スコアと対応付けて、スコアの算定基準とする各種条件を記憶している。

図４は、取引評価テーブル１４５、取引クラスタＤＢ１４６、及び資料判定テーブル１４７のレコードレイアウトの一例を示す説明図である。
取引評価テーブル１４５は、ユーザ及びクライアントそれぞれの格付けと、当該ユーザとクライアントとの間の取引の信用度合いを段階的に表す区分（取引クラスタ）とを対応付けた対応表である。図４に示すように、取引評価テーブル１４５は、取引の信用度合いを段階的に表す「Ｔ１」から「Ｎ」までの取引クラスタを、それぞれユーザ及びクライアントの格付けと対応付けて格納してある。サーバ１は、ユーザ評価テーブル１４３に従って評価したユーザの与信情報（格付け）と、クライアント評価テーブル１４４に従って評価したユーザの与信情報（格付け）とに基づき、ユーザとクライアントとの間の取引を複数の取引クラスタのいずれかに分類する。

取引クラスタＤＢ１４６は、区分列、格付け列、評価列、自動審査限度額列、手動審査限度額列、取引資料列、ＰＤ期待値列を含む。区分列は、各取引クラスタの大分類を記憶している。格付け列は、区分と対応付けて、各取引クラスタを表す格付け（記号）を記憶している。評価列は、区分及び格付けと対応付けて、各取引クラスタが示す評価を記憶している。自動審査限度額及び手動審査限度額はそれぞれ、取引クラスタに応じて承認するファクタリングの限度額を記憶している。具体的には、自動審査限度額はサーバ１による自動審査で承認される限度額を、手動審査限度額は管理者による手動審査で承認される限度額を記憶している。取引資料列は、区分及び格付けと対応付けて、手動審査時に要求される取引資料の程度（格付け）を記憶している。取引資料は、ユーザとクライアントとの間で取引が行われたことを証明する資料であり、管理者が審査を行う上で参考にする資料である。ＰＤ期待値列は、区分及び格付けと対応付けて、各取引クラスタに分類された取引において、売掛債権の回収不能に陥るであろう確率（言わば事故率）を記憶している。

資料判定テーブル１４７は、格付け列、状態基準列、必要資料列を含む。格付け列は、取引資料の必要の程度を表す格付けを記憶している。状態基準列は、格付けと対応付けて、各格付けで必要となる取引資料の具体的程度（数量など）を記憶している。必要資料列は、格付けと対応付けて、必要となる具体的な取引資料を記憶している。

図５は、手数料評価テーブル１４８及び手数料クラスタＤＢ１４９のレコードレイアウトの一例を示す説明図である。
手数料評価テーブル１４８は、取引クラスタ及び取引金額（請求額）と、ファクタリングの手数料の区分（手数料クラスタ）とを対応付けた対応表である。図５に示すように、手数料評価テーブル１４８は、「Ｃ１」から「Ｃ１０」までの手数料クラスタを、取引クラスタ及び取引金額に対応付けて格納してある。サーバ１は、取引評価テーブル１４５に従って分類した取引クラスタと、請求書に記載されている請求額（取引金額）とに応じて手数料クラスタを決定する。

手数料クラスタＤＢ１４９は、格付け列、想定ＰＤ列、標準手数料列、回収期間列、手数料列を含む。格付け列は、各手数料クラスタを表す格付けを記憶している。想定ＰＤ列は、格付けと対応付けて、取引クラスタＤＢ１４６と同様に、各手数料クラスタにおいて想定されるＰＤ期待値を記憶している。標準手数料列は、格付けと対応付けて、各手数料クラスタで標準とする手数料を記憶している。回収期間列は、格付けと対応付けて、請求書の発行日から支払期限に至るまでの期間、つまり売掛債権の回収期間を記憶している。手数料列は、格付け及び回収期間と対応付けて、回収期間に応じて基本手数料から変動させた個別の手数料であって、実際に課されるファクタリングの手数料を記憶している。

図６は、ファクタリングシステムの概要を示す説明図である。図６に基づき、本システムの概要について説明する。
既に説明したように、本実施の形態では個人ユーザ向けのファクタリングを行う。図６では、個人であるユーザと法人であるクライアントとの間で取引が行われた場合に、取引によって生じる売掛金について、サーバ１がファクタリングを実施する様子を図示している。ユーザは、クライアントから依頼を受けて商品（あるいはサービス）を納品する納品者であり、クライアントはユーザから商品の納品を受ける依頼者である。

一般的に行われているように、ユーザは商品の納品後、クライアントに対して取引代金の請求書を発行し、代金を請求する。しかしながら、代金の請求時点から実際の入金時点までにはいくらか時間的な相違が生じる。その間にユーザは資金が必要となり、売掛金の何割かでも収入を得たいとの需要が存在する。

上記の需要に応えて、ファクタリングサービスが提供される。ファクタリングは売掛債権の買取であり、債権者（納品者）から売掛債権を買い取り、債務者（依頼者）から売掛金を回収する金融サービスである。本実施の形態でサーバ１は、個人向けのファクタリングサービスであって、ユーザとクライアントとの間の売掛債権を買い取り、ユーザに対して売掛金の一部を即日決済するサービスを提供する。

本実施の形態に係るファクタリング処理について詳述する。まずユーザは、商品の納品後、請求書を発行してクライアントに送付する。当該請求書は、郵送や電子メールで送付するものであってもよく、外部のサービス事業者が提供する所定の会計ソフトウェアによって作成、送信されるものであってもよい。サーバ１は、ネットワークＮを介して当該請求書のデータを取得する。例えばサーバ１は、ユーザの端末２から所定のファイル形式（例えばＰＤＦ（Portable Document Format、登録商標）ファイル）で請求書のアップロードを受ける。また、例えばサーバ１は、ユーザが会計ソフトウェアを使用している場合に、当該会計ソフトウェアと連携して、外部のサービス事業者の装置から請求書のデータを取得するようにしてもよい。サーバ１は、取得した請求書のデータをユーザＩＤと対応付けて請求書ＤＢ１４２に記憶する。

ここで、本システムを利用するユーザは、ファクタリングサービスを受けるための金融口座（ファクタリング口座）を所定の金融機関に開設している。ファクタリング口座は、ユーザ毎に開設された金融口座であって、ユーザが普段使用している個人口座とは異なるファクタリング専用の金融口座である。本実施の形態では、当該ファクタリング口座を介して売掛金の入出金が行われる。

具体的には、ファクタリング口座は本システムの管理者の金融口座（以下では「管理口座」と呼ぶ）に関連付けられた金融口座であり、管理口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された振込専用口座である。より詳細には、ファクタリング口座は所謂バーチャル口座であり、口座の名義人はユーザとなっているが、実際には各ユーザのファクタリング口座を取りまとめる管理口座と関連付けられた、金融機関のシステム内の仮想的な金融口座である。一般的には、バーチャル口座は企業が各顧客からの入金を区別するために利用されるが、本実施の形態ではバーチャル口座を売掛金の入金先（振込先）として利用することで、各ユーザ宛に入金された売掛金を容易に識別可能とする。

本システムを利用するユーザは、取引代金の入金先（振込先）として、自らのファクタリング口座を指定した請求書を発行する。これによりクライアントは、取引代金（売掛金）をファクタリング口座に入金することになる。

サーバ１は、端末２から売掛金の即日決済（送金）の要求、つまりファクタリングの申込を受け付けた場合、売掛金から手数料を差し引いた買取額を即日送金し、ユーザの個人口座に買取額を送金する。具体的には後述するように、サーバ１はユーザ評価テーブル１４３及びクライアント評価テーブル１４４を参照して、売掛債権の債権者であるユーザの与信情報と、債務者であるクライアントの与信情報とを評価（設定）する。そしてサーバ１は、ユーザ及びクライアントの与信情報に基づいて売掛債権に係る取引の信用度合い（取引クラスタ）を評価し、ファクタリングの限度額及び手数料を算出する。このようにしてサーバ１はファクタリングの審査を行い、限度額以下の請求書について、算出した手数料を差し引いた買取額を、管理口座からユーザの個人口座に即日送金する。

なお、サーバ１は端末２からの要求に応じて買取額をユーザの個人口座に送金可能であればよく、送金のタイミングは金融機関の翌営業日等であってもよい。つまり、本システムのファクタリングは即日決済に限定されない。

ファクタリングの実施後、クライアントからユーザのファクタリング口座に売掛金が入金される。この場合、サーバ１は当該売掛金を、各ユーザのファクタリング口座を取りまとめる管理口座に振り替える。すなわちサーバ１は、売掛金を回収する。

なお、売掛金についてファクタリングを行わないままファクタリング口座へ入金があった場合、サーバ１は、売掛金をそのままファクタリング口座からユーザの個人口座へと送金する。このように、ユーザの個人口座、及び売掛債権を買い取る管理者の管理口座以外にファクタリング口座を活用することで、ファクタリングに伴う一連の入出金管理を容易にし、金融取引の信用が法人よりも低い個人ユーザであっても利用することができるファクタリングサービスを提供する。

図７は、請求書の一覧画面の一例を示す説明図である。以下では、端末２における表示画面と、当該画面上での操作に基づくファクタリング処理とについて説明する。

一覧画面は、請求書の一覧のほかに、与信スコア７１、銀行口座連携７２、会計ソフト連携７３、取引上限７４、及び標準手数料７５が表示されている。与信スコア７１は、ファクタリングに関する過去の取引実績（履歴情報）などに応じて評価したユーザの与信情報である。銀行口座連携７２は、ユーザの個人口座における入出金情報について、個人口座を管理する金融機関のシステムと本システムとの連携設定の有無を表す。会計ソフト連携７３は、本システムと会計ソフトウェアとの連携設定の有無を表す。取引上限７４は、ユーザの与信情報に応じて設定されるファクタリングの上限総額である。標準手数料７５は、ユーザの与信情報に応じたファクタリングの標準手数料である。

端末２は上述の各種情報のほかに、ユーザが各クライアントに発行した複数の請求書それぞれの情報を一覧画面に表示する。例えば図７に示すように、端末２は各請求書について、取引先名（クライアント名）、請求額、請求日、払込期限（支払期限）、買取額等を表示する。なお、図７では既に買取額が表示されているが、一覧画面で表示される買取額は仮の金額であり、後述するようにサーバ１はユーザからのファクタリングの申込を受け付けてから審査を行い、具体的な買取額を決定する。

また、端末２は各請求書に対応して、申込ボックス７６を表示する。申込ボックス７６への操作入力を受け付けた場合、端末２は、対応する請求書に係る売掛債権の買取をサーバ１に要求し、ファクタリングの申込を行う。ファクタリングの申込を端末２から受け付けた場合、サーバ１は、当該請求書に係るユーザ及びクライアントの与信情報を評価し、当該与信情報に基づいてファクタリングの審査を行って、審査結果に応じてユーザの個人口座に売掛債権の買取額を送金する。

まずサーバ１は、ユーザ評価テーブル１４３を参照して、売掛債権の債権者であるユーザの信用度合いを表す与信情報を評価する。具体的には、サーバ１はユーザの過去のファクタリングの実績、つまり履歴情報などを請求書ＤＢ１４２から読み出し、ユーザの履歴情報に応じてユーザの格付けを決定する。例えばサーバ１は、ユーザの過去の格付け、ファクタリングの回数、金額、遅延案件や回収不能案件の有無、その他のユーザ情報に応じて、ユーザの格付けを「ＡＡＡ」から「Ｎ」までのいずれかの格付けに決定する。

次にサーバ１は、クライアント評価テーブル１４４を参照して、売掛債権の債務者であるクライアントの与信情報を評価する。具体的には、サーバ１はユーザの場合と同様に、クライアントの過去のファクタリングの実績、つまり履歴情報を参照して、クライアントの過去の格付け、ファクタリングの回数、金額、遅延案件や回収不能案件の有無、その他のクライアント情報から格付けを決定する。

なお、取引代金の請求先として請求書に記載されているクライアントが本システムにとって新規のクライアントであり、各データベースに当該クライアントの情報が記憶されていない場合、サーバ１は、当該クライアントの情報の入力を端末２に要求する。例えばサーバ１は、クライアントである法人の法人番号の入力を端末２に要求する。具体的には、サーバ１は請求書に記載されているクライアント名に基づき、当該クライアントの法人名と同一の法人の法人番号を所定の外部ＡＰＩ（Application Programmable Interface）を利用して検索し、検索結果を端末２に出力する。ユーザは当該検索結果から、正しいクライアントを選択して法人番号をサーバ１に通知する。サーバ１は、通知された法人番号に基づきクライアントの情報をネットワークＮ上から検索する。サーバ１は、検索されたクライアントの情報に基づいて与信情報を評価する。

このように、ファクタリングの実績がなく、履歴情報を参照してもクライアントが特定不可能な場合、サーバ１は、端末２に対して法人番号の入力要求を行い、入力された法人番号に基づきクライアントの与信情報を評価する。これにより、サーバ１は新規のクライアントであっても与信情報を適切に評価することができる。

サーバ１は、上記で評価したユーザ及びクライアントそれぞれの与信情報に基づき、請求書に記載されているユーザとクライアントとの間の取引の信用度合いを評価する。具体的には、サーバ１は取引評価テーブル１４５を参照して、ユーザ及びクライアントの格付けに基づき、取引の信用度合いを段階的に表す複数の取引クラスタのいずれかに当該取引を分類する。例えばサーバ１は、図４で示したように、「Ｔ１」から「Ｎ」までのいずれかの取引クラスタに分類する。

サーバ１は、上記で分類した取引クラスタに応じて、ファクタリングを承認する買取限度額を決定する。具体的には、サーバ１は取引クラスタＤＢ１４６を参照して、ファクタリングの自動審査限度額と、手動審査限度額とを決定する。自動審査限度額は、サーバ１による自動審査で承認可能な限度額である。手動審査限度額は、管理者による手動審査で承認可能な限度額である。手動審査限度額は、自動審査限度額よりも高い金額に設定されている。

サーバ１は、端末２からファクタリングの申込を受け付けた請求書の請求額が、自動審査限度額以下であるか否かを判定する。自動審査限度額以下であると判定した場合、サーバ１はファクタリングを承認し、ユーザの個人口座への送金を行う。

具体的には、サーバ１は、上記で分類した取引クラスタと、請求書の請求額（取引金額）とに基づき、ファクタリングの手数料を決定する。例えばサーバ１は手数料評価テーブル１４８を参照して、手数料を段階的に定めた複数の手数料クラスタのいずれかに、ファクタリングが申し込まれた請求書を分類する。サーバ１は手数料クラスタＤＢ１４９を参照して、分類した手数料クラスタに応じて手数料を決定する。

サーバ１は、決定した手数料を端末２に出力し、売掛債権の買取額を不図示の画面でユーザに提示する。そしてサーバ１は、提示した買取額（手数料）に同意するか否か、端末２から入力を受け付ける。ユーザから同意が得られた場合、サーバ１は、請求書の請求額から手数料を差し引いた金額を買取額として、当該買取額をユーザの個人口座に送金する。

請求書の請求額が自動審査限度額以上であると判定した場合、サーバ１は、請求額が手動審査限度額以下であるか否かを判定する。手動審査限度額以下であると判定した場合、サーバ１は、管理者が操作する所定の端末装置（不図示）に当該請求書のデータを出力する。管理者は、出力された請求書について審査を行い、ファクタリングを承認するか否か、審査結果をサーバ１に入力する。

手動審査を実施する場合、サーバ１は上述の取引の評価（取引クラスタ）に応じて、当該取引が実際に行われたことを示す取引資料の送信を端末２に要求する。取引資料は、例えばユーザがクライアントに納品した商品の納品書、納品完了を通知するメール等であり、手動審査において管理者が参考にすることができる資料である。サーバ１は手動審査の用に供するため、取引資料の送信を端末２に要求する。

図８は、取引資料の送信処理に関する説明図である。例えばサーバ１は、取引クラスタがリスク取引に区分されるクラスタである場合（図４参照）、取引資料の送信を端末２に要求する。この場合にサーバ１は、取引資料の送信先として、ワンタイムアドレスを生成して端末２に出力する。図８に、サーバ１から送信されたワンタイムアドレスの表示画面の一例を図示している。端末２は、ユーザからの操作入力に従い、取引資料である所定の添付ファイルを添付して、当該アドレス宛に電子メールを返信する。これによりサーバ１は取引資料を端末２から取得する。例えばサーバ１は、端末２から取得した取引資料と共に、資料判定テーブル１４７に格納されている審査基準の情報を出力して管理者に提示する（図４参照）。

管理者は取引資料も参考に、ファクタリングを承認するか否かを判断し、審査結果をサーバ１に入力する。ファクタリングが承認された場合、サーバ１はファクタリングを実施し、ユーザの個人口座に売掛債権の買取額を送金する。具体的には自動審査時と同じく、サーバ１は手数料評価テーブル１４８を参照して手数料を決定し、請求書の請求額から手数料を差し引いた金額をユーザの個人口座に送金する。

ファクタリングが申し込まれた請求書の請求額が手動審査限度額を超過する場合、あるいは手動審査によってファクタリングが承認されなかった場合などは、サーバ１は、ファクタリングが承認されなかった旨の審査結果を端末２に通知する。

なお、上記ではクライアントから売掛金（請求額）が取引通りに入金され、正常にファクタリングが行われる場合について説明したが、売掛金が回収不能となる場合もあり得る。そこで本システムでは、売掛金の一定額を保証する債権保証を併せて行う。

具体的には、ファクタリングを実施していない取引について、請求書で指定した支払期限を経過してもクライアントから請求額がファクタリング口座に入金されていない場合、売掛債権の債権保証を行う。上述の場合にサーバ１は、請求書においてユーザがクライアントに請求した請求額のうち、所定割合（例えば１０％）の金額を保証額としてユーザの個人口座に送金する。

なお、保証額を送金するタイミングは支払期限の経過直後に限定されず、支払期限から所定期間が経過後であってもよい。つまり、保証額を送金するタイミングは少なくとも支払期限の経過後であればよい。

以上より、サーバ１はファクタリング口座を活用して売掛債権の買取及び債権保証を行う。ユーザ毎に開設されているファクタリング口座を活用することで、各ユーザに対してクライアントから支払われる売掛金の管理を容易にし、個人のユーザであってもファクタリングを安定的かつ適切に行うことができる。また、ファクタリング口座はユーザが名義人となっており、本実施の形態におけるファクタリングは所謂２者（２社）間ファクタリングとなっている。従って、債務者であるクライアントに売掛債権の譲渡通知を行う必要がなく、クライアントに対するユーザの信用を損なうような事態を回避することができる。

図９は、サーバ１が実行する処理手順の一例を示すフローチャートである。図９に基づき、サーバ１が実行する処理内容について説明する。
サーバ１の制御部１１は、ユーザから取引の相手方であるクライアントに対して発行された請求書のデータを取得する（ステップＳ１１）。例えば制御部１１は、端末２から請求書のデータのアップロードを受けるようにしてもよく、ユーザが使用している所定の会計ソフトウェアと連携して、当該会計ソフトウェアを提供する外部のサービス事業者の装置から請求書のデータを取得するようにしてもよい。

制御部１１は、取得した請求書で指定された売掛金の入金先が、ユーザのファクタリング口座（買取口座）であるか否かを判定する（ステップＳ１２）。ファクタリング口座は、本システムにおけるファクタリングサービスを受けるためにユーザが個別に開設した金融口座であり、ユーザの個人口座とは異なるファクタリング用の口座である。具体的には、ファクタリング口座は、ユーザから売掛債権を買い取る本システムの管理者の金融口座（管理口座）に関連付けられた金融口座であって、管理口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された振込専用口座である。制御部１１は、請求書で指定された入金先が、ユーザがファクタリング用に開設したファクタリング口座であるか否かを判定する。

ファクタリング口座であると判定した場合（Ｓ１２：ＹＥＳ）、制御部１１は、取得した請求書のデータをユーザＩＤと対応付けて請求書ＤＢ１４２に記憶（登録）する（ステップＳ１３）。ファクタリング口座でないと判定した場合（Ｓ１２：ＮＯ）、制御部１１は、取得した請求書のデータを破棄する（ステップＳ１４）。ステップＳ１３又はＳ１４の処理を実行後、制御部１１は処理をステップＳ１５に移行する。

制御部１１は端末２からの要求に応じて、ユーザが各クライアントに発行した複数の請求書の一覧を端末２に出力する（ステップＳ１５）。例えば図７に図示したように、制御部１１は、ユーザの与信情報、及びユーザの請求書の一覧を示す一覧画面を端末２に出力する。

制御部１１は、ステップＳ１５で出力した複数の請求書から、売掛債権の買取を申し込む請求書、つまりファクタリングの対象とする請求書を選択する選択入力を受け付ける（ステップＳ１６）。請求書の選択入力を受け付けた場合、制御部１１は、選択された請求書に係る売掛債権をユーザから買い取り、ユーザの個人口座に対して買取額を送金するファクタリング処理のサブルーチンを実行する（ステップＳ１７）。

制御部１１は、クライアントからユーザのファクタリング口座に、請求書によってクライアントに請求した請求額が入金されたか否かを判定する（ステップＳ１８）。入金されたと判定した場合（Ｓ１８：ＹＥＳ）、制御部１１は、入金された請求額に対応する請求書についてすでにファクタリングを実施し、ユーザの個人口座に買取額を送金済みであるか否かを判定する（ステップＳ１９）。送金済みであると判定した場合（Ｓ１９：ＹＥＳ）、制御部１１は、クライアントからユーザのファクタリング口座に入金された請求額を管理口座に振り替える（ステップＳ２０）。送金済みでないと判定した場合（Ｓ１９：ＮＯ）、制御部１１は、クライアントから入金された請求額を、そのままユーザの個人口座に送金する（ステップＳ２１）。ステップＳ２０又はＳ２１の処理を実行後、制御部１１は一連の処理を終了する。

クライアントから請求額が入金されていないと判定した場合（Ｓ１８：ＮＯ）、制御部１１は、請求書で指定された支払期限を経過したか否かを判定する（ステップＳ２２）。支払期限を経過していないと判定した場合（Ｓ２２：ＮＯ）、制御部１１は一連の処理を終了する。支払期限を経過したと判定した場合（Ｓ２２：ＹＥＳ）、制御部１１は、請求書における請求額に応じた所定の保証額をユーザの個人口座に送金する（ステップＳ２３）。制御部１１は、一連の処理を終了する。

図１０は、ファクタリングのサブルーチンの処理手順を示すフローチャートである。図１０に基づき、ステップＳ１７のサブルーチンの処理内容について説明する。
サーバ１の制御部１１は、請求書ＤＢ１４２に格納されているファクタリングの履歴情報を参照して、ユーザが選択した請求書に請求先として記載されているクライアントが特定可能であるか否かを判定する（ステップＳ３１）。特定可能でないと判定した場合（Ｓ３１：ＮＯ）、制御部１１は、当該クライアントの法人番号の入力要求を端末２に出力し、端末２から法人番号の入力を受け付ける（ステップＳ３２）。例えば制御部１１は、所定の外部ＡＰＩを利用してクライアント名と同一の法人の法人番号を検索し、端末２に検索結果を出力する。端末２は、当該検索結果から、請求先として正しいクライアントを選択する選択入力を行う。これにより、制御部１１はクライアントの法人番号を取得する。制御部１１は、取得した法人番号に基づき、当該クライアントの情報をネットワークＮ上から取得する（ステップＳ３３）。

ステップＳ３１でＹＥＳ、又はステップＳ３３の処理を実行後、制御部１１は、ユーザ及びクライアントのファクタリングの履歴情報を請求書ＤＢ１４２から読み出し、ユーザ及びクライアントの双方について、信用の度合いを示す与信情報を評価（設定）する（ステップＳ３４）。具体的には、制御部１１はユーザ評価テーブル１４３に基づき、ユーザの過去のファクタリングの回数、金額、格付け等の実績からユーザの与信情報を評価する。また、制御部１１はクライアントについても、クライアント評価テーブル１４４に基づいて与信情報を評価する。なお、ステップＳ３３で法人番号に基づきクライアントの情報を取得した場合、サーバ１は、取得したクライアントの情報に基づいて与信情報を評価する。

制御部１１は、ユーザ及びクライアントの与信情報に応じて、ユーザとクライアントとの間の取引について、ファクタリングを行う上での信用度合いを評価する（ステップＳ３５）。具体的には上述の如く、制御部１１は、ユーザの与信情報と、クライアントの与信情報とに基づき、取引の信用度合いを段階的に表す区分（取引クラスタ）に当該取引を分類する。制御部１１は、ユーザとクライアントとの間の取引が所定上の評価であるか否かを判定する（ステップＳ３６）。つまり制御部１１は、ステップＳ３５で分類した取引クラスタが、所定以上の格付けの取引クラスタであるか否かを判定する。

取引が所定以上の評価であると判定した場合（Ｓ３６：ＹＥＳ）、制御部１１は取引クラスタＤＢ１４６を参照して、ファクタリングの買取限度額を決定する（ステップＳ３７）。具体的には、制御部１１は、サーバ１による自動審査で承認する自動審査限度額と、管理者による手動審査で承認する手動審査限度額とを決定する。

制御部１１は、ユーザがファクタリングを申し込んだ請求書の請求額が自動審査限度額以下であるか否かを判定する（ステップＳ３８）。自動審査限度額以下でないと判定した場合（Ｓ３８：ＮＯ）、制御部１１は、請求額が手動審査限度額以下であるか否かを判定する（ステップＳ３９）。

手動審査限度額以下であると判定した場合（Ｓ３９：ＹＥＳ）、制御部１１はステップＳ３５における取引の評価に応じて、ユーザとクライアントとの間で取引が行われたことを示す取引資料の送信先とするアドレスを発行し、ユーザの端末２に通知する（ステップＳ４０）。具体的には、制御部１１は、ファクタリングが申し込まれた請求書に係る取引をリスク取引と評価した場合、ワンタイムアドレスを発行して端末２に通知する。制御部１１は端末２から、当該アドレス宛に送信された取引資料を取得する（ステップＳ４１）。例えば制御部１１は、ユーザからクライアントへの納品書、納品完了メール等を取引資料として取得する。管理者は、取引資料を含む各種情報を参考にファクタリングを承認するか否かを審査し、審査結果をサーバ１に入力する。制御部１１は、管理者が入力した審査結果に従い、ファクタリングを承認するか否かを判定する（ステップＳ４２）。

ステップＳ３６、Ｓ３９、又はＳ４２でＮＯの場合、制御部１１は、ファクタリングが承認されなかった旨の審査結果を端末２に出力し（ステップＳ４３）、サブルーチンをリターンする。

ステップＳ３８、又はＳ４２でＹＥＳの場合、制御部１１は手数料評価テーブル１４８を参照して、ファクタリングに伴う手数料を算出する（ステップＳ４４）。制御部１１は当該手数料を端末２に出力して、同意確認を行う。制御部１１は、端末２における操作入力に基づき、ユーザが手数料に同意したか否かを判定する（ステップＳ４５）。手数料に同意しなかったと判定した場合（Ｓ４５：ＮＯ）、制御部１１はサブルーチンをリターンする。

手数料に同意したと判定した場合（Ｓ４５：ＹＥＳ）、制御部１１は、請求書における請求額から手数料を差し引いた買取額をユーザの個人口座に送金する（ステップＳ４６）。制御部１１は、当該請求書に係るファクタリングの情報を請求書ＤＢ１４２に記憶し、サブルーチンをリターンする。

なお、上記では売掛債権の債権者であるユーザが個人であるものとしたが、債権者は企業等の法人であってもよい。債務者であるクライアントについても同様に、法人ではなく個人であってもよい。

また、サーバ１はユーザから受動的にファクタリングの申込を受け付けて送金を行うものとしたが、本実施の形態はこれに限定されるものではなく、ユーザに対してファクタリングを促すプッシュ通知を行ってもよい。例えばサーバ１は、ユーザの需要が高まるであろうと想定される所定のタイミング（例えば月末、週末等）で、各ユーザの端末２にファクタリングを促すプッシュ通知を行う。これにより、ユーザの需要が喚起され、本システムの利用を促すことができる。

以上より、本実施の形態によれば、ユーザの個人口座（金融口座）と異なるファクタリング専用のファクタリング口座（買取口座）をユーザ毎に開設し、当該ファクタリング口座を活用してファクタリングを行う。ユーザ毎に開設されているファクタリング口座を活用することで、各ユーザに対してクライアントから支払われる売掛金の管理を容易にし、個人のユーザであってもファクタリングを適切に行うことができる。

また、本実施の形態によれば、ファクタリング口座を、ファクタリングを実施する管理者の管理口座（金融口座）の口座番号、及びユーザの名義に関連付けて口座番号が発行される振込専用口座とする。これにより、売掛債権に係る入出金の管理を容易にすると共に、クライアントに対するユーザの信用を損なうような事態を防止し、個人向けのファクタリングをより適切に実施することができる。

また、本実施の形態によれば、端末２からファクタリングの申込を受け付け、申込が行われた請求書に関してファクタリングを行うことで、ユーザの利便性を高めることができる。

また、本実施の形態によれば、債権保証を提供することもでき、ユーザにとっての取引の安定性を高めることができる。

また、本実施の形態によれば、請求書の一覧画面からファクタリングを行う請求書を選択することができ、ユーザの利便性をより高めることができる。

また、本実施の形態によれば、ファクタリングを実施する前にユーザ及びクライアントの与信情報を評価して審査を行い、買取限度額及び手数料を決定する。これにより、本システムを適切に運用することができる。

また、本実施の形態によれば、ファクタリングの実績（履歴）のないクライアント（法人）についても、法人番号を元に与信情報を評価することができ、ファクタリングが実施不能に陥る事態を回避することができる。

また、本実施の形態によれば、取引資料の提出をユーザから取得することで、より正確な審査を実施することができる。

また、本実施の形態によれば、ファクタリングの需要が高まるであろうと想定される所定のタイミングでプッシュ通知を行い、ファクタリングの申込をユーザに促してもよい。これにより、ユーザの利便性を高めることができる。

今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

１ サーバ（情報処理装置）
１１ 制御部
１２ 主記憶部
１３ 通信部
１４ 補助記憶部
Ｐ プログラム
１４１ ユーザＤＢ
１４２ 請求書ＤＢ
１４３ ユーザ評価テーブル
１４４ クライアント評価テーブル
１４５ 取引評価テーブル
１４６ 取引クラスタＤＢ
１４７ 資料判定テーブル
１４８ 手数料評価テーブル
１４９ 手数料クラスタＤＢ

Claims (10)

1. ユーザから取引の相手方に対して発行された複数の請求書の一覧を表示部に表示し、
   前記複数の請求書から、売掛債権の買取を申し込む前記請求書を選択する選択入力を受け付け、
   選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する
   処理をコンピュータに実行させる情報処理方法。
2. 前記買取要求に応じて前記売掛債権を買取済みの前記請求書と、前記売掛債権を未買取の前記請求書とを前記一覧に表示する
   請求項１に記載の情報処理方法。
3. 前記ユーザ毎に規定される前記売掛債権の買取の取引上限額から、前記売掛債権を買取済みの前記請求書に係る前記買取額の総額を差し引いた残り買取可能額を表示する
   請求項１又は２に記載の情報処理方法。
4. 前記取引上限額と、前記買取額の総額と、前記残り買取可能額とを示すグラフを表示する
   請求項３に記載の情報処理方法。
5. 前記ユーザが使用している会計ソフトウェアであって、前記請求書の作成及び前記相手方への送信を行う会計ソフトウェアとの連携設定を受け付け、
   前記会計ソフトウェアを提供する外部装置から取得した前記請求書を前記一覧に表示する
   請求項１〜４のいずれか１項に記載の情報処理方法。
6. 前記売掛債権の買取に関する履歴情報に応じた前記ユーザの信用度合いを表す与信情報を表示する
   請求項１〜５のいずれか１項に記載の情報処理方法。
7. 前記売掛債権の買取を申し込む前記請求書の選択入力を受け付けた場合、該請求書に係る前記相手方の法人番号の入力を受け付け、
   前記法人番号を含む前記買取要求を出力する
   請求項１〜６のいずれか１項に記載の情報処理方法。
8. 前記請求書は、前記ユーザの金融口座とは異なり、売掛債権の買取を行うための前記ユーザ毎に個別の買取口座を入金先に指定した請求書であり、
   前記売掛債権の買取を申し込む前記請求書の選択入力を受け付けた場合、前記買取額を前記ユーザの金融口座に送金する送金要求を、前記買取口座を管理する管理装置に出力する
   請求項１〜７のいずれか１項に記載の情報処理方法。
9. ユーザから取引の相手方に対して発行された複数の請求書の一覧を表示部に表示し、
   前記複数の請求書から、売掛債権の買取を申し込む前記請求書を選択する選択入力を受け付け、
   選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する
   処理をコンピュータに実行させるプログラム。
10. ユーザから取引の相手方に対して発行された複数の請求書の一覧を表示する表示部と、
    前記複数の請求書から、売掛債権の買取を申し込む前記請求書を選択する選択入力を受け付ける受付部と、
    選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する出力部と
    を備える情報処理装置。

Images