JP7413487B2 - 情報処理方法、プログラム及び情報処理装置 - Google Patents
情報処理方法、プログラム及び情報処理装置 Download PDFInfo
- Publication number
- JP7413487B2 JP7413487B2 JP2022182006A JP2022182006A JP7413487B2 JP 7413487 B2 JP7413487 B2 JP 7413487B2 JP 2022182006 A JP2022182006 A JP 2022182006A JP 2022182006 A JP2022182006 A JP 2022182006A JP 7413487 B2 JP7413487 B2 JP 7413487B2
- Authority
- JP
- Japan
- Prior art keywords
- user
- purchase
- factoring
- transaction
- amount
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000010365 information processing Effects 0.000 title claims description 24
- 238000003672 processing method Methods 0.000 title claims description 11
- 238000000034 method Methods 0.000 claims description 17
- 230000004044 response Effects 0.000 claims description 4
- 238000011156 evaluation Methods 0.000 description 52
- 238000012545 processing Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 16
- 238000012552 review Methods 0.000 description 13
- 238000007726 management method Methods 0.000 description 12
- 238000012546 transfer Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 2
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
本発明は、情報処理方法、プログラム及び情報処理装置に関する。
金融サービスの一つに、債権者の売掛債権を買い取り、債務者から売掛金を回収するファクタリングサービスがある。例えば特許文献1では、電子記録債権法に規定された電子記録債権のファクタリングを行うファクタリングシステムが開示されている。
しかしながら、特許文献1に記載されているように、一般的にファクタリングは法人の間で行われるものであり、個人がファクタリングサービスを利用することが困難だった。
一つの側面では、個人ユーザであってもファクタリングサービスを利用することができる情報処理方法等を提供することを目的とする。
一つの側面では、情報処理方法は、ユーザが使用している会計ソフトウェアであって、請求書の作成及び相手方への送信を行う会計ソフトウェアとの連携設定を受け付け、ユーザから取引の相手方に対して発行された複数の請求書であって、前記会計ソフトウェアを提供する外部装置から取得した前記請求書の一覧を表示部に表示し、売掛債権を買い取る際に必要とされる手数料を表示し、前記複数の請求書から、売掛債権の買取を申し込むために選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する処理をコンピュータに実行させる。
一つの側面では、個人ユーザであってもファクタリングサービスを利用することができる。
以下、本発明をその実施の形態を示す図面に基づいて詳述する。(実施の形態)
図1は、ファクタリングシステムの構成例を示す模式図である。本実施の形態では、個人ユーザ向けのファクタリングサービスを提供するファクタリングシステムについて説明する。ファクタリングシステムは、情報処理装置1、端末2、2、2…を有する。各装置は、インターネット等のネットワークNを介して通信接続されている。
図1は、ファクタリングシステムの構成例を示す模式図である。本実施の形態では、個人ユーザ向けのファクタリングサービスを提供するファクタリングシステムについて説明する。ファクタリングシステムは、情報処理装置1、端末2、2、2…を有する。各装置は、インターネット等のネットワークNを介して通信接続されている。
情報処理装置1は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態では情報処理装置1がサーバ装置であるものとし、以下の説明では簡潔のため、情報処理装置1をサーバ1と読み替える。サーバ1は、本システムに係るファクタリングサービスを管理する管理装置であり、ファクタリングに利用する金融口座の管理、ファクタリングに伴う審査、ユーザへの送金等の処理を行う。
後述するように、本実施の形態でサーバ1は、個人ユーザ向けのファクタリングを行う。具体的には、サーバ1は、個人ユーザ(個人事業主等)と、ユーザに依頼して商品等の納品を受ける取引の相手方(以下では「クライアント」と呼ぶ)との間の取引について、当該取引によって発生する売掛債権を買い取り、売掛金から手数料を差し引いた金額をユーザに支払うファクタリングを行う。
端末2は、本サービスを利用する各ユーザの端末装置であり、例えば多機能端末、パーソナルコンピュータ等の情報処理装置である。例えば各端末2にはサーバ1が提供する本サービス専用のアプリケーションプログラムがインストールされており、各ユーザは当該アプリケーション上でファクタリングの申込、情報の閲覧等を行う。
図2は、サーバ1の構成例を示すブロック図である。サーバ1は、制御部11、主記憶部12、通信部13、及び補助記憶部14を備える。
制御部11は、一又は複数のCPU(Central Processing Unit)、MPU(Micro-Processing Unit)、GPU(Graphics Processing Unit)等の演算処理装置を有し、補助記憶部14に記憶されたプログラムPを読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。主記憶部12は、SRAM(Static Random Access Memory)、DRAM(Dynamic Random Access Memory)、フラッシュメモリ等の一時記憶領域であり、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は、通信に関する処理を行うための処理回路等を含み、端末2等と情報の送受信を行う。
制御部11は、一又は複数のCPU(Central Processing Unit)、MPU(Micro-Processing Unit)、GPU(Graphics Processing Unit)等の演算処理装置を有し、補助記憶部14に記憶されたプログラムPを読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。主記憶部12は、SRAM(Static Random Access Memory)、DRAM(Dynamic Random Access Memory)、フラッシュメモリ等の一時記憶領域であり、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は、通信に関する処理を行うための処理回路等を含み、端末2等と情報の送受信を行う。
補助記憶部14は大容量メモリ、ハードディスク等であり、制御部11が処理を実行するために必要なプログラムP、その他のデータを記憶している。また、補助記憶部14は、ユーザDB141、請求書DB142、ユーザ評価テーブル143、クライアント評価テーブル144、取引評価テーブル145、取引クラスタDB146、資料判定テーブル147、手数料評価テーブル148、手数料クラスタDB149を記憶している。
ユーザDB141は、各ユーザの情報を格納するデータベースである。請求書DB142は、各ユーザが取引の相手方に対して発行した請求書のデータを格納するデータベースである。ユーザ評価テーブル143は、ユーザの与信評価を行うためのテーブルである。クライアント評価テーブル144は、取引の相手方であるクライアントの与信評価を行うためのテーブルである。取引評価テーブル145は、ユーザ及びクライアントの与信情報に基づき、ファクタリングを行う上でユーザとクライアントとの間の取引がどの程度信用できるか、信用の度合いを評価するためのテーブルである。
取引クラスタDB146は、取引評価テーブル145による評価に応じて段階的に区分される、取引の信用度合いを表す区分(以下では「取引クラスタ」と呼ぶ)の情報を格納したデータベースである。資料判定テーブル147は、取引の審査に必要な取引資料の情報を格納したテーブルである。手数料評価テーブル148は、取引クラスタと、取引額とに応じて、ファクタリングの手数料を評価するためのテーブルである。手数料クラスタDB149は、手数料評価テーブル148による評価に応じた手数料の区分(以下では「手数料クラスタ」と呼ぶ)に関する情報を格納したデータベースである。
なお、補助記憶部14はサーバ1に接続された外部記憶装置であってもよい。また、サーバ1は複数のコンピュータからなるマルチコンピュータであってもよく、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。
図3は、ユーザDB141、請求書DB142、ユーザ評価テーブル143、及びクライアント評価テーブル144のレコードレイアウトの一例を示す説明図である。
ユーザDB141は、ユーザID列、氏名列、ユーザ情報列、個人口座列、ファクタリング口座列、口座連携列、会計連携列を含む。ユーザID列は、各ユーザを識別するための識別情報を記憶している。氏名列は、ユーザIDと対応付けて、ユーザの氏名を記憶している。個人口座列は、ユーザIDと対応付けて、個人ユーザが所定の金融機関に開設している金融口座であって、ユーザがファクタリングの代金(買取額)の送金先として設定した金融口座(以下では「個人口座」と呼ぶ)の情報を記憶している。ファクタリング口座列は、ユーザIDと対応付けて、本実施の形態に係るファクタリングサービスを受けるための振込専用口座であるファクタリング口座の情報を記憶している。ファクタリング口座は、本システムの管理者の金融口座に関連付けられた金融口座であって、管理者の金融口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された、金融機関のシステムにおける仮想的な振込専用口座である。口座連携列は、ユーザIDと対応付けて、ユーザの個人口座の入出金情報を本システムと連携するか否かについて、ユーザによる許諾の有無を記憶している。会計連携列は、ユーザIDと対応付けて、ユーザが使用している所定の会計ソフトウェアと連携してサーバ1に請求書のデータをアップロードするか否かについて、ユーザによる設定の有無を記憶している。
ユーザDB141は、ユーザID列、氏名列、ユーザ情報列、個人口座列、ファクタリング口座列、口座連携列、会計連携列を含む。ユーザID列は、各ユーザを識別するための識別情報を記憶している。氏名列は、ユーザIDと対応付けて、ユーザの氏名を記憶している。個人口座列は、ユーザIDと対応付けて、個人ユーザが所定の金融機関に開設している金融口座であって、ユーザがファクタリングの代金(買取額)の送金先として設定した金融口座(以下では「個人口座」と呼ぶ)の情報を記憶している。ファクタリング口座列は、ユーザIDと対応付けて、本実施の形態に係るファクタリングサービスを受けるための振込専用口座であるファクタリング口座の情報を記憶している。ファクタリング口座は、本システムの管理者の金融口座に関連付けられた金融口座であって、管理者の金融口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された、金融機関のシステムにおける仮想的な振込専用口座である。口座連携列は、ユーザIDと対応付けて、ユーザの個人口座の入出金情報を本システムと連携するか否かについて、ユーザによる許諾の有無を記憶している。会計連携列は、ユーザIDと対応付けて、ユーザが使用している所定の会計ソフトウェアと連携してサーバ1に請求書のデータをアップロードするか否かについて、ユーザによる設定の有無を記憶している。
請求書DB142は、請求書ID列、ユーザ列、クライアント列、取引金額列、請求日列、期限列、即日決済列、買取額列を含む。請求書ID列は、各請求書を識別するための識別情報を記憶している。ユーザ列は、請求書IDと対応付けて、請求書の発行者であるユーザのユーザIDを記憶している。クライアント列は、請求書IDと対応付けて、請求先であるクライアントの識別情報を記憶している。取引金額列は、請求書IDと対応付けて、ユーザとクライアントとの間の取引金額、つまり請求書の請求額を記憶している。請求日列は、請求書IDと対応付けて、請求日を記憶している。期限列は、請求書IDと対応付けて、売掛金の支払期限を記憶している。即日決済列は、請求書IDと対応付けて、本サービスを利用してファクタリング(即日決済)を行ったか否かを記憶している。なお、即日決済列の「審査中」は、ファクタリングを認証するか否か、管理者が審査中であることを意味している。買取額列は、請求書IDと対応付けて、ファクタリングを行った場合の買取額を記憶している。
ユーザ評価テーブル143は、スコア列、格付け列、状態列、判断基準列、取引限度列を含む。スコア列は、ユーザの与信情報を数値化したスコアを記憶している。格付け列は、スコアと対応付けて、スコアに応じてユーザに与えられる格付けを記憶している。状態列は、スコアと対応付けて、ユーザの与信情報を表すステータスを記憶している。判断基準列は、スコアと対応付けて、スコアの算定基準とする各種条件を記憶している。取引限度列は、スコアと対応付けて、ユーザの与信情報に応じて承認する取引限度額を記憶している。
クライアント評価テーブル144は、スコア列、格付け列、状態列、判断基準列を含む。スコア列は、クライアントの与信情報を数値化したスコアを記憶している。格付け列は、スコアと対応付けて、スコアに応じてクライアントに与えられる格付けを記憶している。状態列は、スコアと対応付けて、クライアントの与信情報を表すステータスを記憶している。判断基準列は、スコアと対応付けて、スコアの算定基準とする各種条件を記憶している。
図4は、取引評価テーブル145、取引クラスタDB146、及び資料判定テーブル147のレコードレイアウトの一例を示す説明図である。
取引評価テーブル145は、ユーザ及びクライアントそれぞれの格付けと、当該ユーザとクライアントとの間の取引の信用度合いを段階的に表す区分(取引クラスタ)とを対応付けた対応表である。図4に示すように、取引評価テーブル145は、取引の信用度合いを段階的に表す「T1」から「N」までの取引クラスタを、それぞれユーザ及びクライアントの格付けと対応付けて格納してある。サーバ1は、ユーザ評価テーブル143に従って評価したユーザの与信情報(格付け)と、クライアント評価テーブル144に従って評価したユーザの与信情報(格付け)とに基づき、ユーザとクライアントとの間の取引を複数の取引クラスタのいずれかに分類する。
取引評価テーブル145は、ユーザ及びクライアントそれぞれの格付けと、当該ユーザとクライアントとの間の取引の信用度合いを段階的に表す区分(取引クラスタ)とを対応付けた対応表である。図4に示すように、取引評価テーブル145は、取引の信用度合いを段階的に表す「T1」から「N」までの取引クラスタを、それぞれユーザ及びクライアントの格付けと対応付けて格納してある。サーバ1は、ユーザ評価テーブル143に従って評価したユーザの与信情報(格付け)と、クライアント評価テーブル144に従って評価したユーザの与信情報(格付け)とに基づき、ユーザとクライアントとの間の取引を複数の取引クラスタのいずれかに分類する。
取引クラスタDB146は、区分列、格付け列、評価列、自動審査限度額列、手動審査限度額列、取引資料列、PD期待値列を含む。区分列は、各取引クラスタの大分類を記憶している。格付け列は、区分と対応付けて、各取引クラスタを表す格付け(記号)を記憶している。評価列は、区分及び格付けと対応付けて、各取引クラスタが示す評価を記憶している。自動審査限度額及び手動審査限度額はそれぞれ、取引クラスタに応じて承認するファクタリングの限度額を記憶している。具体的には、自動審査限度額はサーバ1による自動審査で承認される限度額を、手動審査限度額は管理者による手動審査で承認される限度額を記憶している。取引資料列は、区分及び格付けと対応付けて、手動審査時に要求される取引資料の程度(格付け)を記憶している。取引資料は、ユーザとクライアントとの間で取引が行われたことを証明する資料であり、管理者が審査を行う上で参考にする資料である。PD期待値列は、区分及び格付けと対応付けて、各取引クラスタに分類された取引において、売掛債権の回収不能に陥るであろう確率(言わば事故率)を記憶している。
資料判定テーブル147は、格付け列、状態基準列、必要資料列を含む。格付け列は、取引資料の必要の程度を表す格付けを記憶している。状態基準列は、格付けと対応付けて、各格付けで必要となる取引資料の具体的程度(数量など)を記憶している。必要資料列は、格付けと対応付けて、必要となる具体的な取引資料を記憶している。
図5は、手数料評価テーブル148及び手数料クラスタDB149のレコードレイアウトの一例を示す説明図である。
手数料評価テーブル148は、取引クラスタ及び取引金額(請求額)と、ファクタリングの手数料の区分(手数料クラスタ)とを対応付けた対応表である。図5に示すように、手数料評価テーブル148は、「C1」から「C10」までの手数料クラスタを、取引クラスタ及び取引金額に対応付けて格納してある。サーバ1は、取引評価テーブル145に従って分類した取引クラスタと、請求書に記載されている請求額(取引金額)とに応じて手数料クラスタを決定する。
手数料評価テーブル148は、取引クラスタ及び取引金額(請求額)と、ファクタリングの手数料の区分(手数料クラスタ)とを対応付けた対応表である。図5に示すように、手数料評価テーブル148は、「C1」から「C10」までの手数料クラスタを、取引クラスタ及び取引金額に対応付けて格納してある。サーバ1は、取引評価テーブル145に従って分類した取引クラスタと、請求書に記載されている請求額(取引金額)とに応じて手数料クラスタを決定する。
手数料クラスタDB149は、格付け列、想定PD列、標準手数料列、回収期間列、手数料列を含む。格付け列は、各手数料クラスタを表す格付けを記憶している。想定PD列は、格付けと対応付けて、取引クラスタDB146と同様に、各手数料クラスタにおいて想定されるPD期待値を記憶している。標準手数料列は、格付けと対応付けて、各手数料クラスタで標準とする手数料を記憶している。回収期間列は、格付けと対応付けて、請求書の発行日から支払期限に至るまでの期間、つまり売掛債権の回収期間を記憶している。手数料列は、格付け及び回収期間と対応付けて、回収期間に応じて基本手数料から変動させた個別の手数料であって、実際に課されるファクタリングの手数料を記憶している。
図6は、ファクタリングシステムの概要を示す説明図である。図6に基づき、本システムの概要について説明する。
既に説明したように、本実施の形態では個人ユーザ向けのファクタリングを行う。図6では、個人であるユーザと法人であるクライアントとの間で取引が行われた場合に、取引によって生じる売掛金について、サーバ1がファクタリングを実施する様子を図示している。ユーザは、クライアントから依頼を受けて商品(あるいはサービス)を納品する納品者であり、クライアントはユーザから商品の納品を受ける依頼者である。
既に説明したように、本実施の形態では個人ユーザ向けのファクタリングを行う。図6では、個人であるユーザと法人であるクライアントとの間で取引が行われた場合に、取引によって生じる売掛金について、サーバ1がファクタリングを実施する様子を図示している。ユーザは、クライアントから依頼を受けて商品(あるいはサービス)を納品する納品者であり、クライアントはユーザから商品の納品を受ける依頼者である。
一般的に行われているように、ユーザは商品の納品後、クライアントに対して取引代金の請求書を発行し、代金を請求する。しかしながら、代金の請求時点から実際の入金時点までにはいくらか時間的な相違が生じる。その間にユーザは資金が必要となり、売掛金の何割かでも収入を得たいとの需要が存在する。
上記の需要に応えて、ファクタリングサービスが提供される。ファクタリングは売掛債権の買取であり、債権者(納品者)から売掛債権を買い取り、債務者(依頼者)から売掛金を回収する金融サービスである。本実施の形態でサーバ1は、個人向けのファクタリングサービスであって、ユーザとクライアントとの間の売掛債権を買い取り、ユーザに対して売掛金の一部を即日決済するサービスを提供する。
本実施の形態に係るファクタリング処理について詳述する。まずユーザは、商品の納品後、請求書を発行してクライアントに送付する。当該請求書は、郵送や電子メールで送付するものであってもよく、外部のサービス事業者が提供する所定の会計ソフトウェアによって作成、送信されるものであってもよい。サーバ1は、ネットワークNを介して当該請求書のデータを取得する。例えばサーバ1は、ユーザの端末2から所定のファイル形式(例えばPDF(Portable Document Format、登録商標)ファイル)で請求書のアップロードを受ける。また、例えばサーバ1は、ユーザが会計ソフトウェアを使用している場合に、当該会計ソフトウェアと連携して、外部のサービス事業者の装置から請求書のデータを取得するようにしてもよい。サーバ1は、取得した請求書のデータをユーザIDと対応付けて請求書DB142に記憶する。
ここで、本システムを利用するユーザは、ファクタリングサービスを受けるための金融口座(ファクタリング口座)を所定の金融機関に開設している。ファクタリング口座は、ユーザ毎に開設された金融口座であって、ユーザが普段使用している個人口座とは異なるファクタリング専用の金融口座である。本実施の形態では、当該ファクタリング口座を介して売掛金の入出金が行われる。
具体的には、ファクタリング口座は本システムの管理者の金融口座(以下では「管理口座」と呼ぶ)に関連付けられた金融口座であり、管理口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された振込専用口座である。より詳細には、ファクタリング口座は所謂バーチャル口座であり、口座の名義人はユーザとなっているが、実際には各ユーザのファクタリング口座を取りまとめる管理口座と関連付けられた、金融機関のシステム内の仮想的な金融口座である。一般的には、バーチャル口座は企業が各顧客からの入金を区別するために利用されるが、本実施の形態ではバーチャル口座を売掛金の入金先(振込先)として利用することで、各ユーザ宛に入金された売掛金を容易に識別可能とする。
本システムを利用するユーザは、取引代金の入金先(振込先)として、自らのファクタリング口座を指定した請求書を発行する。これによりクライアントは、取引代金(売掛金)をファクタリング口座に入金することになる。
サーバ1は、端末2から売掛金の即日決済(送金)の要求、つまりファクタリングの申込を受け付けた場合、売掛金から手数料を差し引いた買取額を即日送金し、ユーザの個人口座に買取額を送金する。具体的には後述するように、サーバ1はユーザ評価テーブル143及びクライアント評価テーブル144を参照して、売掛債権の債権者であるユーザの与信情報と、債務者であるクライアントの与信情報とを評価(設定)する。そしてサーバ1は、ユーザ及びクライアントの与信情報に基づいて売掛債権に係る取引の信用度合い(取引クラスタ)を評価し、ファクタリングの限度額及び手数料を算出する。このようにしてサーバ1はファクタリングの審査を行い、限度額以下の請求書について、算出した手数料を差し引いた買取額を、管理口座からユーザの個人口座に即日送金する。
なお、サーバ1は端末2からの要求に応じて買取額をユーザの個人口座に送金可能であればよく、送金のタイミングは金融機関の翌営業日等であってもよい。つまり、本システムのファクタリングは即日決済に限定されない。
ファクタリングの実施後、クライアントからユーザのファクタリング口座に売掛金が入金される。この場合、サーバ1は当該売掛金を、各ユーザのファクタリング口座を取りまとめる管理口座に振り替える。すなわちサーバ1は、売掛金を回収する。
なお、売掛金についてファクタリングを行わないままファクタリング口座へ入金があった場合、サーバ1は、売掛金をそのままファクタリング口座からユーザの個人口座へと送金する。このように、ユーザの個人口座、及び売掛債権を買い取る管理者の管理口座以外にファクタリング口座を活用することで、ファクタリングに伴う一連の入出金管理を容易にし、金融取引の信用が法人よりも低い個人ユーザであっても利用することができるファクタリングサービスを提供する。
図7は、請求書の一覧画面の一例を示す説明図である。以下では、端末2における表示画面と、当該画面上での操作に基づくファクタリング処理とについて説明する。
一覧画面は、請求書の一覧のほかに、与信スコア71、銀行口座連携72、会計ソフト連携73、取引上限74、及び標準手数料75が表示されている。与信スコア71は、ファクタリングに関する過去の取引実績(履歴情報)などに応じて評価したユーザの与信情報である。銀行口座連携72は、ユーザの個人口座における入出金情報について、個人口座を管理する金融機関のシステムと本システムとの連携設定の有無を表す。会計ソフト連携73は、本システムと会計ソフトウェアとの連携設定の有無を表す。取引上限74は、ユーザの与信情報に応じて設定されるファクタリングの上限総額である。標準手数料75は、ユーザの与信情報に応じたファクタリングの標準手数料である。
端末2は上述の各種情報のほかに、ユーザが各クライアントに発行した複数の請求書それぞれの情報を一覧画面に表示する。例えば図7に示すように、端末2は各請求書について、取引先名(クライアント名)、請求額、請求日、払込期限(支払期限)、買取額等を表示する。なお、図7では既に買取額が表示されているが、一覧画面で表示される買取額は仮の金額であり、後述するようにサーバ1はユーザからのファクタリングの申込を受け付けてから審査を行い、具体的な買取額を決定する。
また、端末2は各請求書に対応して、申込ボックス76を表示する。申込ボックス76への操作入力を受け付けた場合、端末2は、対応する請求書に係る売掛債権の買取をサーバ1に要求し、ファクタリングの申込を行う。ファクタリングの申込を端末2から受け付けた場合、サーバ1は、当該請求書に係るユーザ及びクライアントの与信情報を評価し、当該与信情報に基づいてファクタリングの審査を行って、審査結果に応じてユーザの個人口座に売掛債権の買取額を送金する。
まずサーバ1は、ユーザ評価テーブル143を参照して、売掛債権の債権者であるユーザの信用度合いを表す与信情報を評価する。具体的には、サーバ1はユーザの過去のファクタリングの実績、つまり履歴情報などを請求書DB142から読み出し、ユーザの履歴情報に応じてユーザの格付けを決定する。例えばサーバ1は、ユーザの過去の格付け、ファクタリングの回数、金額、遅延案件や回収不能案件の有無、その他のユーザ情報に応じて、ユーザの格付けを「AAA」から「N」までのいずれかの格付けに決定する。
次にサーバ1は、クライアント評価テーブル144を参照して、売掛債権の債務者であるクライアントの与信情報を評価する。具体的には、サーバ1はユーザの場合と同様に、クライアントの過去のファクタリングの実績、つまり履歴情報を参照して、クライアントの過去の格付け、ファクタリングの回数、金額、遅延案件や回収不能案件の有無、その他のクライアント情報から格付けを決定する。
なお、取引代金の請求先として請求書に記載されているクライアントが本システムにとって新規のクライアントであり、各データベースに当該クライアントの情報が記憶されていない場合、サーバ1は、当該クライアントの情報の入力を端末2に要求する。例えばサーバ1は、クライアントである法人の法人番号の入力を端末2に要求する。具体的には、サーバ1は請求書に記載されているクライアント名に基づき、当該クライアントの法人名と同一の法人の法人番号を所定の外部API(Application Programmable Interface)を利用して検索し、検索結果を端末2に出力する。ユーザは当該検索結果から、正しいクライアントを選択して法人番号をサーバ1に通知する。サーバ1は、通知された法人番号に基づきクライアントの情報をネットワークN上から検索する。サーバ1は、検索されたクライアントの情報に基づいて与信情報を評価する。
このように、ファクタリングの実績がなく、履歴情報を参照してもクライアントが特定不可能な場合、サーバ1は、端末2に対して法人番号の入力要求を行い、入力された法人番号に基づきクライアントの与信情報を評価する。これにより、サーバ1は新規のクライアントであっても与信情報を適切に評価することができる。
サーバ1は、上記で評価したユーザ及びクライアントそれぞれの与信情報に基づき、請求書に記載されているユーザとクライアントとの間の取引の信用度合いを評価する。具体的には、サーバ1は取引評価テーブル145を参照して、ユーザ及びクライアントの格付けに基づき、取引の信用度合いを段階的に表す複数の取引クラスタのいずれかに当該取引を分類する。例えばサーバ1は、図4で示したように、「T1」から「N」までのいずれかの取引クラスタに分類する。
サーバ1は、上記で分類した取引クラスタに応じて、ファクタリングを承認する買取限度額を決定する。具体的には、サーバ1は取引クラスタDB146を参照して、ファクタリングの自動審査限度額と、手動審査限度額とを決定する。自動審査限度額は、サーバ1による自動審査で承認可能な限度額である。手動審査限度額は、管理者による手動審査で承認可能な限度額である。手動審査限度額は、自動審査限度額よりも高い金額に設定されている。
サーバ1は、端末2からファクタリングの申込を受け付けた請求書の請求額が、自動審査限度額以下であるか否かを判定する。自動審査限度額以下であると判定した場合、サーバ1はファクタリングを承認し、ユーザの個人口座への送金を行う。
具体的には、サーバ1は、上記で分類した取引クラスタと、請求書の請求額(取引金額)とに基づき、ファクタリングの手数料を決定する。例えばサーバ1は手数料評価テーブル148を参照して、手数料を段階的に定めた複数の手数料クラスタのいずれかに、ファクタリングが申し込まれた請求書を分類する。サーバ1は手数料クラスタDB149を参照して、分類した手数料クラスタに応じて手数料を決定する。
サーバ1は、決定した手数料を端末2に出力し、売掛債権の買取額を不図示の画面でユーザに提示する。そしてサーバ1は、提示した買取額(手数料)に同意するか否か、端末2から入力を受け付ける。ユーザから同意が得られた場合、サーバ1は、請求書の請求額から手数料を差し引いた金額を買取額として、当該買取額をユーザの個人口座に送金する。
請求書の請求額が自動審査限度額以上であると判定した場合、サーバ1は、請求額が手動審査限度額以下であるか否かを判定する。手動審査限度額以下であると判定した場合、サーバ1は、管理者が操作する所定の端末装置(不図示)に当該請求書のデータを出力する。管理者は、出力された請求書について審査を行い、ファクタリングを承認するか否か、審査結果をサーバ1に入力する。
手動審査を実施する場合、サーバ1は上述の取引の評価(取引クラスタ)に応じて、当該取引が実際に行われたことを示す取引資料の送信を端末2に要求する。取引資料は、例えばユーザがクライアントに納品した商品の納品書、納品完了を通知するメール等であり、手動審査において管理者が参考にすることができる資料である。サーバ1は手動審査の用に供するため、取引資料の送信を端末2に要求する。
図8は、取引資料の送信処理に関する説明図である。例えばサーバ1は、取引クラスタがリスク取引に区分されるクラスタである場合(図4参照)、取引資料の送信を端末2に要求する。この場合にサーバ1は、取引資料の送信先として、ワンタイムアドレスを生成して端末2に出力する。図8に、サーバ1から送信されたワンタイムアドレスの表示画面の一例を図示している。端末2は、ユーザからの操作入力に従い、取引資料である所定の添付ファイルを添付して、当該アドレス宛に電子メールを返信する。これによりサーバ1は取引資料を端末2から取得する。例えばサーバ1は、端末2から取得した取引資料と共に、資料判定テーブル147に格納されている審査基準の情報を出力して管理者に提示する(図4参照)。
管理者は取引資料も参考に、ファクタリングを承認するか否かを判断し、審査結果をサーバ1に入力する。ファクタリングが承認された場合、サーバ1はファクタリングを実施し、ユーザの個人口座に売掛債権の買取額を送金する。具体的には自動審査時と同じく、サーバ1は手数料評価テーブル148を参照して手数料を決定し、請求書の請求額から手数料を差し引いた金額をユーザの個人口座に送金する。
ファクタリングが申し込まれた請求書の請求額が手動審査限度額を超過する場合、あるいは手動審査によってファクタリングが承認されなかった場合などは、サーバ1は、ファクタリングが承認されなかった旨の審査結果を端末2に通知する。
なお、上記ではクライアントから売掛金(請求額)が取引通りに入金され、正常にファクタリングが行われる場合について説明したが、売掛金が回収不能となる場合もあり得る。そこで本システムでは、売掛金の一定額を保証する債権保証を併せて行う。
具体的には、ファクタリングを実施していない取引について、請求書で指定した支払期限を経過してもクライアントから請求額がファクタリング口座に入金されていない場合、売掛債権の債権保証を行う。上述の場合にサーバ1は、請求書においてユーザがクライアントに請求した請求額のうち、所定割合(例えば10%)の金額を保証額としてユーザの個人口座に送金する。
なお、保証額を送金するタイミングは支払期限の経過直後に限定されず、支払期限から所定期間が経過後であってもよい。つまり、保証額を送金するタイミングは少なくとも支払期限の経過後であればよい。
以上より、サーバ1はファクタリング口座を活用して売掛債権の買取及び債権保証を行う。ユーザ毎に開設されているファクタリング口座を活用することで、各ユーザに対してクライアントから支払われる売掛金の管理を容易にし、個人のユーザであってもファクタリングを安定的かつ適切に行うことができる。また、ファクタリング口座はユーザが名義人となっており、本実施の形態におけるファクタリングは所謂2者(2社)間ファクタリングとなっている。従って、債務者であるクライアントに売掛債権の譲渡通知を行う必要がなく、クライアントに対するユーザの信用を損なうような事態を回避することができる。
図9は、サーバ1が実行する処理手順の一例を示すフローチャートである。図9に基づき、サーバ1が実行する処理内容について説明する。
サーバ1の制御部11は、ユーザから取引の相手方であるクライアントに対して発行された請求書のデータを取得する(ステップS11)。例えば制御部11は、端末2から請求書のデータのアップロードを受けるようにしてもよく、ユーザが使用している所定の会計ソフトウェアと連携して、当該会計ソフトウェアを提供する外部のサービス事業者の装置から請求書のデータを取得するようにしてもよい。
サーバ1の制御部11は、ユーザから取引の相手方であるクライアントに対して発行された請求書のデータを取得する(ステップS11)。例えば制御部11は、端末2から請求書のデータのアップロードを受けるようにしてもよく、ユーザが使用している所定の会計ソフトウェアと連携して、当該会計ソフトウェアを提供する外部のサービス事業者の装置から請求書のデータを取得するようにしてもよい。
制御部11は、取得した請求書で指定された売掛金の入金先が、ユーザのファクタリング口座(買取口座)であるか否かを判定する(ステップS12)。ファクタリング口座は、本システムにおけるファクタリングサービスを受けるためにユーザが個別に開設した金融口座であり、ユーザの個人口座とは異なるファクタリング用の口座である。具体的には、ファクタリング口座は、ユーザから売掛債権を買い取る本システムの管理者の金融口座(管理口座)に関連付けられた金融口座であって、管理口座の口座番号と、ユーザの名義とに関連付けて口座番号が発行された振込専用口座である。制御部11は、請求書で指定された入金先が、ユーザがファクタリング用に開設したファクタリング口座であるか否かを判定する。
ファクタリング口座であると判定した場合(S12:YES)、制御部11は、取得した請求書のデータをユーザIDと対応付けて請求書DB142に記憶(登録)する(ステップS13)。ファクタリング口座でないと判定した場合(S12:NO)、制御部11は、取得した請求書のデータを破棄する(ステップS14)。ステップS13又はS14の処理を実行後、制御部11は処理をステップS15に移行する。
制御部11は端末2からの要求に応じて、ユーザが各クライアントに発行した複数の請求書の一覧を端末2に出力する(ステップS15)。例えば図7に図示したように、制御部11は、ユーザの与信情報、及びユーザの請求書の一覧を示す一覧画面を端末2に出力する。
制御部11は、ステップS15で出力した複数の請求書から、売掛債権の買取を申し込む請求書、つまりファクタリングの対象とする請求書を選択する選択入力を受け付ける(ステップS16)。請求書の選択入力を受け付けた場合、制御部11は、選択された請求書に係る売掛債権をユーザから買い取り、ユーザの個人口座に対して買取額を送金するファクタリング処理のサブルーチンを実行する(ステップS17)。
制御部11は、クライアントからユーザのファクタリング口座に、請求書によってクライアントに請求した請求額が入金されたか否かを判定する(ステップS18)。入金されたと判定した場合(S18:YES)、制御部11は、入金された請求額に対応する請求書についてすでにファクタリングを実施し、ユーザの個人口座に買取額を送金済みであるか否かを判定する(ステップS19)。送金済みであると判定した場合(S19:YES)、制御部11は、クライアントからユーザのファクタリング口座に入金された請求額を管理口座に振り替える(ステップS20)。送金済みでないと判定した場合(S19:NO)、制御部11は、クライアントから入金された請求額を、そのままユーザの個人口座に送金する(ステップS21)。ステップS20又はS21の処理を実行後、制御部11は一連の処理を終了する。
クライアントから請求額が入金されていないと判定した場合(S18:NO)、制御部11は、請求書で指定された支払期限を経過したか否かを判定する(ステップS22)。支払期限を経過していないと判定した場合(S22:NO)、制御部11は一連の処理を終了する。支払期限を経過したと判定した場合(S22:YES)、制御部11は、請求書における請求額に応じた所定の保証額をユーザの個人口座に送金する(ステップS23)。制御部11は、一連の処理を終了する。
図10は、ファクタリングのサブルーチンの処理手順を示すフローチャートである。図10に基づき、ステップS17のサブルーチンの処理内容について説明する。
サーバ1の制御部11は、請求書DB142に格納されているファクタリングの履歴情報を参照して、ユーザが選択した請求書に請求先として記載されているクライアントが特定可能であるか否かを判定する(ステップS31)。特定可能でないと判定した場合(S31:NO)、制御部11は、当該クライアントの法人番号の入力要求を端末2に出力し、端末2から法人番号の入力を受け付ける(ステップS32)。例えば制御部11は、所定の外部APIを利用してクライアント名と同一の法人の法人番号を検索し、端末2に検索結果を出力する。端末2は、当該検索結果から、請求先として正しいクライアントを選択する選択入力を行う。これにより、制御部11はクライアントの法人番号を取得する。制御部11は、取得した法人番号に基づき、当該クライアントの情報をネットワークN上から取得する(ステップS33)。
サーバ1の制御部11は、請求書DB142に格納されているファクタリングの履歴情報を参照して、ユーザが選択した請求書に請求先として記載されているクライアントが特定可能であるか否かを判定する(ステップS31)。特定可能でないと判定した場合(S31:NO)、制御部11は、当該クライアントの法人番号の入力要求を端末2に出力し、端末2から法人番号の入力を受け付ける(ステップS32)。例えば制御部11は、所定の外部APIを利用してクライアント名と同一の法人の法人番号を検索し、端末2に検索結果を出力する。端末2は、当該検索結果から、請求先として正しいクライアントを選択する選択入力を行う。これにより、制御部11はクライアントの法人番号を取得する。制御部11は、取得した法人番号に基づき、当該クライアントの情報をネットワークN上から取得する(ステップS33)。
ステップS31でYES、又はステップS33の処理を実行後、制御部11は、ユーザ及びクライアントのファクタリングの履歴情報を請求書DB142から読み出し、ユーザ及びクライアントの双方について、信用の度合いを示す与信情報を評価(設定)する(ステップS34)。具体的には、制御部11はユーザ評価テーブル143に基づき、ユーザの過去のファクタリングの回数、金額、格付け等の実績からユーザの与信情報を評価する。また、制御部11はクライアントについても、クライアント評価テーブル144に基づいて与信情報を評価する。なお、ステップS33で法人番号に基づきクライアントの情報を取得した場合、サーバ1は、取得したクライアントの情報に基づいて与信情報を評価する。
制御部11は、ユーザ及びクライアントの与信情報に応じて、ユーザとクライアントとの間の取引について、ファクタリングを行う上での信用度合いを評価する(ステップS35)。具体的には上述の如く、制御部11は、ユーザの与信情報と、クライアントの与信情報とに基づき、取引の信用度合いを段階的に表す区分(取引クラスタ)に当該取引を分類する。制御部11は、ユーザとクライアントとの間の取引が所定上の評価であるか否かを判定する(ステップS36)。つまり制御部11は、ステップS35で分類した取引クラスタが、所定以上の格付けの取引クラスタであるか否かを判定する。
取引が所定以上の評価であると判定した場合(S36:YES)、制御部11は取引クラスタDB146を参照して、ファクタリングの買取限度額を決定する(ステップS37)。具体的には、制御部11は、サーバ1による自動審査で承認する自動審査限度額と、管理者による手動審査で承認する手動審査限度額とを決定する。
制御部11は、ユーザがファクタリングを申し込んだ請求書の請求額が自動審査限度額以下であるか否かを判定する(ステップS38)。自動審査限度額以下でないと判定した場合(S38:NO)、制御部11は、請求額が手動審査限度額以下であるか否かを判定する(ステップS39)。
手動審査限度額以下であると判定した場合(S39:YES)、制御部11はステップS35における取引の評価に応じて、ユーザとクライアントとの間で取引が行われたことを示す取引資料の送信先とするアドレスを発行し、ユーザの端末2に通知する(ステップS40)。具体的には、制御部11は、ファクタリングが申し込まれた請求書に係る取引をリスク取引と評価した場合、ワンタイムアドレスを発行して端末2に通知する。制御部11は端末2から、当該アドレス宛に送信された取引資料を取得する(ステップS41)。例えば制御部11は、ユーザからクライアントへの納品書、納品完了メール等を取引資料として取得する。管理者は、取引資料を含む各種情報を参考にファクタリングを承認するか否かを審査し、審査結果をサーバ1に入力する。制御部11は、管理者が入力した審査結果に従い、ファクタリングを承認するか否かを判定する(ステップS42)。
ステップS36、S39、又はS42でNOの場合、制御部11は、ファクタリングが承認されなかった旨の審査結果を端末2に出力し(ステップS43)、サブルーチンをリターンする。
ステップS38、又はS42でYESの場合、制御部11は手数料評価テーブル148を参照して、ファクタリングに伴う手数料を算出する(ステップS44)。制御部11は当該手数料を端末2に出力して、同意確認を行う。制御部11は、端末2における操作入力に基づき、ユーザが手数料に同意したか否かを判定する(ステップS45)。手数料に同意しなかったと判定した場合(S45:NO)、制御部11はサブルーチンをリターンする。
手数料に同意したと判定した場合(S45:YES)、制御部11は、請求書における請求額から手数料を差し引いた買取額をユーザの個人口座に送金する(ステップS46)。制御部11は、当該請求書に係るファクタリングの情報を請求書DB142に記憶し、サブルーチンをリターンする。
なお、上記では売掛債権の債権者であるユーザが個人であるものとしたが、債権者は企業等の法人であってもよい。債務者であるクライアントについても同様に、法人ではなく個人であってもよい。
また、サーバ1はユーザから受動的にファクタリングの申込を受け付けて送金を行うものとしたが、本実施の形態はこれに限定されるものではなく、ユーザに対してファクタリングを促すプッシュ通知を行ってもよい。例えばサーバ1は、ユーザの需要が高まるであろうと想定される所定のタイミング(例えば月末、週末等)で、各ユーザの端末2にファクタリングを促すプッシュ通知を行う。これにより、ユーザの需要が喚起され、本システムの利用を促すことができる。
以上より、本実施の形態によれば、ユーザの個人口座(金融口座)と異なるファクタリング専用のファクタリング口座(買取口座)をユーザ毎に開設し、当該ファクタリング口座を活用してファクタリングを行う。ユーザ毎に開設されているファクタリング口座を活用することで、各ユーザに対してクライアントから支払われる売掛金の管理を容易にし、個人のユーザであってもファクタリングを適切に行うことができる。
また、本実施の形態によれば、ファクタリング口座を、ファクタリングを実施する管理者の管理口座(金融口座)の口座番号、及びユーザの名義に関連付けて口座番号が発行される振込専用口座とする。これにより、売掛債権に係る入出金の管理を容易にすると共に、クライアントに対するユーザの信用を損なうような事態を防止し、個人向けのファクタリングをより適切に実施することができる。
また、本実施の形態によれば、端末2からファクタリングの申込を受け付け、申込が行われた請求書に関してファクタリングを行うことで、ユーザの利便性を高めることができる。
また、本実施の形態によれば、債権保証を提供することもでき、ユーザにとっての取引の安定性を高めることができる。
また、本実施の形態によれば、請求書の一覧画面からファクタリングを行う請求書を選択することができ、ユーザの利便性をより高めることができる。
また、本実施の形態によれば、ファクタリングを実施する前にユーザ及びクライアントの与信情報を評価して審査を行い、買取限度額及び手数料を決定する。これにより、本システムを適切に運用することができる。
また、本実施の形態によれば、ファクタリングの実績(履歴)のないクライアント(法人)についても、法人番号を元に与信情報を評価することができ、ファクタリングが実施不能に陥る事態を回避することができる。
また、本実施の形態によれば、取引資料の提出をユーザから取得することで、より正確な審査を実施することができる。
また、本実施の形態によれば、ファクタリングの需要が高まるであろうと想定される所定のタイミングでプッシュ通知を行い、ファクタリングの申込をユーザに促してもよい。これにより、ユーザの利便性を高めることができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
1 サーバ(情報処理装置)
11 制御部
12 主記憶部
13 通信部
14 補助記憶部
P プログラム
141 ユーザDB
142 請求書DB
143 ユーザ評価テーブル
144 クライアント評価テーブル
145 取引評価テーブル
146 取引クラスタDB
147 資料判定テーブル
148 手数料評価テーブル
149 手数料クラスタDB
11 制御部
12 主記憶部
13 通信部
14 補助記憶部
P プログラム
141 ユーザDB
142 請求書DB
143 ユーザ評価テーブル
144 クライアント評価テーブル
145 取引評価テーブル
146 取引クラスタDB
147 資料判定テーブル
148 手数料評価テーブル
149 手数料クラスタDB
Claims (10)
- ユーザが使用している会計ソフトウェアであって、請求書の作成及び相手方への送信を行う会計ソフトウェアとの連携設定を受け付け、
ユーザから取引の相手方に対して発行された複数の請求書であって、前記会計ソフトウェアを提供する外部装置から取得した前記請求書の一覧を表示部に表示し、
売掛債権を買い取る際に必要とされる手数料を表示し、
前記複数の請求書から、売掛債権の買取を申し込むために選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する
処理をコンピュータに実行させる情報処理方法。 - 前記買取要求に応じて前記売掛債権を買取済みの前記請求書と、前記売掛債権を未買取の前記請求書とを前記一覧に表示する
請求項1に記載の情報処理方法。 - 前記ユーザ毎に規定される前記売掛債権の買取の取引上限額から、前記売掛債権を買取済みの前記請求書に係る前記買取額の総額を差し引いた残り買取可能額を表示する
請求項1又は2に記載の情報処理方法。 - 前記取引上限額と、前記買取額の総額と、前記残り買取可能額とを示すグラフを表示する
請求項3に記載の情報処理方法。 - 前記売掛債権の買取に関する履歴情報に応じた前記ユーザの信用度合いを表す与信情報を表示する
請求項1~4のいずれか1項に記載の情報処理方法。 - 前記売掛債権の買取を申し込む前記請求書の選択入力を受け付けた場合、該請求書に係る前記相手方の法人番号の入力を受け付け、
前記法人番号を含む前記買取要求を出力する
請求項1~5のいずれか1項に記載の情報処理方法。 - 前記請求書は、前記ユーザの金融口座とは異なり、売掛債権の買取を行うための前記ユーザ毎に個別の買取口座を入金先に指定した請求書であり、
前記売掛債権の買取を申し込む前記請求書の選択入力を受け付けた場合、前記買取額を前記ユーザの金融口座に送金する送金要求を、前記買取口座を管理する管理装置に出力する
請求項1~6のいずれか1項に記載の情報処理方法。 - 前記表示部に、売掛債権を買い取るための手数料を差し引いた差引買取額を表示し、
前記会計ソフトウェアを提供する外部装置から取得した前記複数の請求書から、売掛債権の買取を申し込むために選択された前記請求書の前記差引買取額で前記売掛債権を買い取る買取要求を出力する
請求項1~7のいずれか1項に記載の情報処理方法。 - ユーザが使用している会計ソフトウェアであって、請求書の作成及び相手方への送信を行う会計ソフトウェアとの連携設定を受け付け、
ユーザから取引の相手方に対して発行された複数の請求書であって、前記会計ソフトウェアを提供する外部装置から取得した前記請求書の一覧を表示部に表示し、
売掛債権を買い取る際に必要とされる手数料を表示し、
前記複数の請求書から、売掛債権の買取を申し込むために選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する
処理をコンピュータに実行させるプログラム。 - ユーザが使用している会計ソフトウェアであって、請求書の作成及び相手方への送信を行う会計ソフトウェアとの連携設定を受け付ける受付部と、
ユーザから取引の相手方に対して発行された複数の請求書であって、前記会計ソフトウェアを提供する外部装置から取得した前記請求書の一覧を表示する第1表示部と、
売掛債権を買い取る際に必要とされる手数料を表示する第2表示部と、
前記複数の請求書から、売掛債権の買取を申し込むために選択された前記請求書の請求額に応じた買取額で前記売掛債権を買い取る買取要求を出力する出力部と
を備える情報処理装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022182006A JP7413487B2 (ja) | 2022-02-28 | 2022-11-14 | 情報処理方法、プログラム及び情報処理装置 |
JP2023221605A JP2024023982A (ja) | 2022-02-28 | 2023-12-27 | 情報処理方法、プログラム及び情報処理装置 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2022030114A JP7178521B2 (ja) | 2020-12-23 | 2022-02-28 | 情報処理方法、プログラム及び情報処理装置 |
JP2022182006A JP7413487B2 (ja) | 2022-02-28 | 2022-11-14 | 情報処理方法、プログラム及び情報処理装置 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022030114A Division JP7178521B2 (ja) | 2020-12-23 | 2022-02-28 | 情報処理方法、プログラム及び情報処理装置 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2023221605A Division JP2024023982A (ja) | 2022-02-28 | 2023-12-27 | 情報処理方法、プログラム及び情報処理装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2023001390A JP2023001390A (ja) | 2023-01-04 |
JP7413487B2 true JP7413487B2 (ja) | 2024-01-15 |
Family
ID=81124694
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022182006A Active JP7413487B2 (ja) | 2022-02-28 | 2022-11-14 | 情報処理方法、プログラム及び情報処理装置 |
JP2023221605A Pending JP2024023982A (ja) | 2022-02-28 | 2023-12-27 | 情報処理方法、プログラム及び情報処理装置 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2023221605A Pending JP2024023982A (ja) | 2022-02-28 | 2023-12-27 | 情報処理方法、プログラム及び情報処理装置 |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP7413487B2 (ja) |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000181974A (ja) | 1998-12-14 | 2000-06-30 | Sakura Bank Ltd | 一括ファクタリング装置 |
JP2001142987A (ja) | 1999-03-31 | 2001-05-25 | Central Factors Ltd | 代行支払事務装置 |
JP2001319060A (ja) | 2000-05-02 | 2001-11-16 | Yasuhiko Miura | 売掛債権担保融資方法およびシステム |
WO2002023421A1 (fr) | 2000-09-14 | 2002-03-21 | Kabushiki Kaisha Toshiba | Systeme mediateur d'affacturage |
JP2002109224A (ja) | 2000-10-02 | 2002-04-12 | Smbc Finance Co Ltd | 売掛債権ファクタリング方法およびそのシステム |
JP2002329068A (ja) | 2001-02-27 | 2002-11-15 | Smbc Factor Co Ltd | 売上債権処理システム及び処理方法 |
US20070061206A1 (en) | 2005-08-15 | 2007-03-15 | Lefebvre Dale | System and method for providing rapid rebate payments |
JP2017162157A (ja) | 2016-03-09 | 2017-09-14 | フリー株式会社 | 会計支援装置、会計支援方法、及び会計支援プログラム |
JP2017204234A (ja) | 2016-05-13 | 2017-11-16 | 株式会社八十二銀行 | 決済支援システム、方法及びプログラム |
JP6313529B1 (ja) | 2017-03-31 | 2018-04-18 | 株式会社Leis | 保険立替処理または保険ファクタリング処理システム |
-
2022
- 2022-11-14 JP JP2022182006A patent/JP7413487B2/ja active Active
-
2023
- 2023-12-27 JP JP2023221605A patent/JP2024023982A/ja active Pending
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2000181974A (ja) | 1998-12-14 | 2000-06-30 | Sakura Bank Ltd | 一括ファクタリング装置 |
JP2001142987A (ja) | 1999-03-31 | 2001-05-25 | Central Factors Ltd | 代行支払事務装置 |
JP2001319060A (ja) | 2000-05-02 | 2001-11-16 | Yasuhiko Miura | 売掛債権担保融資方法およびシステム |
WO2002023421A1 (fr) | 2000-09-14 | 2002-03-21 | Kabushiki Kaisha Toshiba | Systeme mediateur d'affacturage |
JP2002109224A (ja) | 2000-10-02 | 2002-04-12 | Smbc Finance Co Ltd | 売掛債権ファクタリング方法およびそのシステム |
JP2002329068A (ja) | 2001-02-27 | 2002-11-15 | Smbc Factor Co Ltd | 売上債権処理システム及び処理方法 |
US20070061206A1 (en) | 2005-08-15 | 2007-03-15 | Lefebvre Dale | System and method for providing rapid rebate payments |
JP2017162157A (ja) | 2016-03-09 | 2017-09-14 | フリー株式会社 | 会計支援装置、会計支援方法、及び会計支援プログラム |
JP2017204234A (ja) | 2016-05-13 | 2017-11-16 | 株式会社八十二銀行 | 決済支援システム、方法及びプログラム |
JP6313529B1 (ja) | 2017-03-31 | 2018-04-18 | 株式会社Leis | 保険立替処理または保険ファクタリング処理システム |
Non-Patent Citations (1)
Title |
---|
「コンカー」とアライアンスパートナー契約を締結,[online],2016年11月28日,[2022年10月7日検索],インターネット, <URL: https://corp.infomart.co.jp/news/detail.html?itemid=247&dispmid=486&TabModule5 |
Also Published As
Publication number | Publication date |
---|---|
JP2023001390A (ja) | 2023-01-04 |
JP2024023982A (ja) | 2024-02-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8396794B1 (en) | Method and system for processing a financial transaction | |
US8571978B2 (en) | Method and system for providing assurance and financing services | |
US20140136412A1 (en) | Least cost routing interchange for b2b purchase card payments | |
US20140344046A1 (en) | Electronic payment system with payer controlled transaction fees and variable rebate capabilities | |
JP6059319B1 (ja) | 代金支払管理システム、及び代金支払管理方法 | |
US8521646B2 (en) | System and method for assigning an initial transaction fee tier to a vendor in a payment system with a variable transaction fee | |
KR20020083898A (ko) | 금전 소비 대차 계약 변경의 권유 방법 | |
US20120290479A1 (en) | Integration of a Payment Network with Systems of Multiple Participating Banks | |
US8538872B1 (en) | Credit card account shadowing | |
JP6816062B2 (ja) | 情報処理装置、情報処理方法及びプログラム | |
JP2022158871A (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP7033644B2 (ja) | 情報処理方法、プログラム及び情報処理装置 | |
JP2020003960A (ja) | 債権保証システム | |
JP4591612B1 (ja) | 決済処理方法及び装置 | |
JP2011159225A (ja) | 与信取引システム及びその方法 | |
US20120290471A1 (en) | Payment Network with Multiple Vendor Participation Levels | |
JP4461618B2 (ja) | 決済装置及び方法 | |
JP7270801B1 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
JP7413487B2 (ja) | 情報処理方法、プログラム及び情報処理装置 | |
JP2020030817A (ja) | 情報処理装置、情報処理方法および情報処理プログラム | |
JP7178521B2 (ja) | 情報処理方法、プログラム及び情報処理装置 | |
JP2022158810A (ja) | 情報処理装置、情報処理方法、および情報処理プログラム | |
JP6564118B1 (ja) | 情報処理装置、情報処理方法および情報処理プログラム | |
JP7162791B1 (ja) | 情報処理装置、情報処理方法、およびプログラム | |
JP7308915B1 (ja) | 電子記録債権による決済代行システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20221114 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20231205 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20231227 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 7413487 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |