JP7519515B1 - 決済処理装置、決済処理方法、及びプログラム - Google Patents

Abstract

【課題】サプライヤーが登録した売上データに基づく請求データを自動生成し、他システムに対して所定の処理を依頼するためのデータを生成する。【解決手段】決済処理装置は、サプライヤー及びバイヤー間の同一支払日の取引に関する請求データ及び請求明細データであって、そのステータスが「口座振替依頼待ち」を示す請求データ及び請求明細データから電子請求書生成用データを生成し、請求明細データに基づいて口座振替依頼データを生成し、口座振替処理の結果に応答して、口座振替依頼データに対応する入金依頼データを生成する。決済処理装置は、サプライヤーの早期資金化の依頼を受けて試算依頼を生成し、バイヤーの支払先延ばし依頼を受けて試算依頼を生成する。生成されたデータは、関連するシステムに送信されるためのデータである。【選択図】図８

Description

特許法第３０条第２項適用 発行者名 株式会社三井住友銀行 刊行物名 「ｉＢ－ｔｌｅ」請求企業向けチラシ 発行日 令和５年４月２４日

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

企業間取引（ＢｔｏＢ：Business to Business）の分野において、金融機関は、請求、決済、ファイナンス、保証、調達などの各種業務をサポートする各種システムのうちの１または複数を個々の企業のニーズに合わせて提供し、企業間取引をサポートしてきた。各企業は、金融機関から提供される各種システム、及び他のシステムベンダーから提供される外部システムを併用して自社の決済関連業務を行っていた。これらのシステムの中には、取引先同士が同じシステムを利用することが必須のものもあった。

複数のシステムを併用する事例は、これまでにも存在していた。特許文献１には、外部ベンダーの会計ソフトウェアが作成した請求書を受信し、選択した請求書に係る売掛債権を買い取って送金するファクタリングの仕組みが開示されている。

従来、企業間取引の決済は、サプライヤー発の口座振替（収納代行サービス）及びバイヤー発の振込により行われていた。口座振替は、収納代行サービス会社に対して口座振替に必要なデータを送信し、バイヤー取引銀行の口座から引き落としがなされ、所定の日数後にサプライヤー取引銀行の口座に対して入金が行われていた。振込は、企業間取引の契約内容に従って、所定の支払日に支払が行われていた。

特許７０３３６４４号公報

従来、各企業は、複数のシステムを併用して決済関連業務を行わざるを得なかった。例えば、サプライヤーが請求書を発行する際には会計システムに商取引データを入力する必要があり、その商取引に対して口座振替で請求する際には金融機関の提供する口座振替受付システムに所定フォーマットでデータ登録する必要があり、売掛債権を早期に資金化したいときにはファクタリング会社に申し込む必要があった。このため、各企業は、それぞれのシステムごとに要求される所定フォーマットのデータを登録する必要があり、同じ内容のデータをそれぞれのシステムに合わせてフォーマット化して各システムに送信するのは非常に不便であった。

従来、サプライヤーは、バイヤー毎に異なる決済条件を許容していたため、売上日に応じた請求額の算出や決済条件に応じた支払期日をバイヤー毎に計算して請求書に記載し、バイヤー毎に異なる支払期日までに入金されたかどうかを、口座明細等を参照し随時確認する必要があり、期日管理が手間であった。

従来の口座振替では、バイヤーの事前合意の上でサプライヤーが収納依頼をかけるとバイヤーの口座から自動的に引落される仕組みであった。企業間決済においては、バイヤーは、サプライヤーからの請求金額や内容を事前に確認し社内決裁をとった上で支払手続きを行うことが多いため、サプライヤーのみの指示で口座から引き落とされる口座振替はバイヤーからは許容しづらい点があった。サプライヤーも引落日の数営業日前の特定期間中に口座振替の請求を登録する必要があるため、販売先毎に異なる決済条件を許容しているサプライヤーにとっては期日管理が大変で利用しづらかった。

本発明は、このような課題を解決するためになされたものであり、サプライヤーが登録した売上データに基づく請求データを自動生成し、他システムに対して所定の処理を依頼するためのデータを生成する決済処理装置、決済処理方法、及びプログラムを提供することを目的とする。

また、本発明は、登録されている決済条件に従って、予め定められたタイミングで、他システムに対して所定の処理を依頼するためのデータを生成する決済処理装置、決済処理方法、及びプログラムを提供することを目的とする。

また、本発明は、サプライヤーが登録した売上データに基づく未承認請求データをサプライヤー及びバイヤーが互いに承認することで収納代行実行用のデータを自動生成し、他システムに収納代行処理を依頼するためのデータを生成する決済処理装置、決済処理方法、及びプログラムを提供することを目的とする。

上記の課題を解決するために、本発明の決済処理装置は、外部ネットワークと通信するための通信部、記憶部、及び制御部を備えた決済処理装置であって、
前記制御部は、
第１のユーザ及び第２のユーザ間の取引を示し、かつ同一の支払日を示す請求データ及び請求明細データであって、それぞれのステータスが口座振替依頼待ちを示す請求データ及び請求明細データを前記記憶部から読み出して電子請求書生成用データを生成し、前記第２のユーザに提示する電子請求書を請求処理システムに発行させるために、前記電子請求書生成用データを前記通信部を介して前記請求処理システムに送信することであって、前記請求データ及び前記請求明細データは、前記第１のユーザからの売上データに基づく、ことと、
そのステータスが前記口座振替依頼待ちを示す前記請求明細データを読み出し、読み出した前記請求明細データに基づいて、前記第２のユーザの口座から決済代行業者の口座への口座振替依頼データを生成し、前記通信部を介して口座振替システムに送信するとともに、読み出した前記請求明細データと、読み出した前記請求明細データに関連付けられる請求データのそれぞれのステータスを入金待ちに更新することと、
前記口座振替依頼データに基づいて行われた口座振替処理の結果に応答して、前記決済代行業者の口座から前記第１のユーザの口座への入金依頼データを生成し、前記通信部を介して前記入金依頼データを前記口座振替システムに送信するとともに、前記口座振替依頼データに関連付けられる請求データ及び請求明細データのそれぞれのステータスを入金済に更新することと、
を実行する。

本発明によれば、サプライヤーは、一度のデータ登録とその後のシステム操作だけで各種サービスの申込が可能となる。

本発明によれば、サプライヤーは、請求金額及び支払期日を管理する事務を削減でき、また入金明細と請求書などを見比べることなく回収状況を把握することが可能になる。

本発明によれば、バイヤーは、事前に支払額と支払日を確認できるため、口座振替であっても勝手に引き落とされる不安を解消でき、サプライヤーも収納代行実行用データを登録する期日管理を気にする必要がなくなり効率的となる。

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。
決済処理装置１０を含むシステム全体の構成図である。 決済処理装置１０のシステム構成図である。 ユーザマスタ１０６のデータ構造の一例を示す図である。 契約／決済情報１０７のデータ構造の一例を示す図である。 請求データ１０８のデータ構造の一例を示す図である。 請求明細データ１０９のデータ構造の一例を示す図である。 売上ファイルのアップロードから電子請求書の提供までの処理を説明するフロー図である。 サプライヤー及びバイヤー間の口座振替による資金移動処理を説明するフロー図である。 （ａ）は、サプライヤーにとってのファイナンス処理を説明するフロー図であり、（ｂ）は、バイヤーにとってのファイナンス処理を説明するフロー図である。 契約／決済情報登録画面１０００の一例を示す図である。

（全体構成）
図１は、本発明の実施形態に係る決済処理装置１０、サプライヤー端末１１、バイヤー端末１２、請求処理システム１３、口座振替システム１４、ファイナンスシステム１５、入金処理システム１６、第１の銀行システム１７、及び第２の銀行システム１８を含むシステム全体の構成図である。

決済処理装置１０は、インターネットなどの第１のネットワーク１９を介してサプライヤー端末１１及びバイヤー端末１２と相互に通信可能に接続されている。決済処理装置１０は、インターネットあるいはＬＡＮやＷＡＮなどの第２のネットワーク２０を介して請求処理システム１３、口座振替システム１４、ファイナンスシステム１５、入金処理システム１６、第１の銀行システム１７、及び第２の銀行システム１８と相互に通信可能に接続されている。

本明細書では、決済処理装置１０を１つのシステムあるいは装置として説明するが、決済処理装置１０によって実行される様々な処理を複数のシステムあるいは装置で分散して実行するように構成してもよい。図１では、説明の簡便化のため、サプライヤー端末１１及びバイヤー端末１２は１つずつしか示されていないが、これらは複数存在し得る。

サプライヤー端末１１は、企業間取引におけるサプライヤーによって使用される端末である。サプライヤー端末１１は、通信機能やＷｅｂブラウザによるデータ編集・閲覧機能を備えたパーソナルコンピュータ（ＰＣ）やタブレット型端末などのコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

バイヤー端末１２は、企業間取引におけるバイヤーによって使用される端末である。バイヤー端末１２は、通信機能やＷｅｂブラウザによるデータ編集・閲覧機能を備えたパーソナルコンピュータ（ＰＣ）やタブレット型端末などのコンピュータとすることができるが、特定の装置やデバイスに限定されることはない。

請求処理システム１３、口座振替システム１４、ファイナンスシステム１５、及び入金処理システム１６は、所定の処理を実行するためのシステムであり、金融機関の外部システムまたはサブシステムであってよく、後述するような機能を提供する。

第１の銀行システム１７及び第２の銀行システム１８は、金融機関によって制御される勘定系システムなどの銀行システムである。第１の銀行システム１７は、サプライヤー取引銀行のシステムであり、第２の銀行システム１８は、バイヤー取引銀行のシステムである。サプライヤー取引銀行及びバイヤー取引銀行が同一金融機関となる場合には、第１の銀行システム１７及び第２の銀行システム１８は同一のシステムである。

決済処理装置１０は、企業間取引の決済関連処理のために使用される装置であり、本願明細書で説明するような、基盤データの登録処理、請求処理、決済処理、ファイナンス処理、保証処理、入金処理、入金消込処理などをサポートする様々な機能を、ウェブベースの統一されたインターフェースを介してサプライヤー端末１１及びバイヤー端末１２に提供する。以下、決済処理装置１０によって提供される様々な機能を説明する。

（基盤データの登録処理）
本明細書において「基盤データ」は、サプライヤー及びバイヤーに関連するユーザ情報及び企業間取引の契約情報、並びに企業間取引の実態を示す情報（例えば、売上データ）である。決済処理装置１０は、サプライヤー及びバイヤーのそれぞれに対してＩＤを発行し、サプライヤー及びバイヤーに関連する情報を受信してユーザ情報として記憶する。決済処理装置１０は、締日、売上データ登録日、支払日などの決済関連の契約情報をサプライヤー端末１１から受信して記憶する。

決済処理装置１０は、サプライヤー端末１１から受信した売上データと、ユーザ情報及び契約情報とに基づいて予め定められたタイミングで未承認請求データを生成してサプライヤー端末１１に提供する。決済処理装置１０は、未承認請求データがサプライヤー端末１１によって承認されたことに応答して、当該未承認請求データをバイヤー端末１２に提供する。バイヤーは、当該未承認請求データの内容を確認してバイヤー端末１２を介して承認すると、当該データは、承認済請求データとして決済処理装置１０によって扱われる。承認済の請求データは、サプライヤー及びバイヤーの決済口座、サプライヤー及びバイヤー間の契約情報に基づく支払日などの情報を含んでいる。このため、バイヤーは、実際に支払を行う前に、支払額及び支払日を事前に確認することができる。以下の記載では、承認済請求データのことを単に「請求データ」あるいは「請求明細データ」と呼び、承認されていない請求データのことを「未承認請求データ」あるいは「未承認請求明細データ」と呼ぶこととする。

（請求処理）
決済処理装置１０は、請求データ及び請求明細データとバイヤーの通知先情報とを請求処理システム１３に送信して、バイヤー端末１２に提供するための電子請求書を請求処理システム１３に発行させる。

（決済処理）
決済処理装置１０は、請求データ及び請求明細データの金額情報とサプライヤー及びバイヤーの口座情報とに基づいて口座振替依頼データを生成する。決済処理装置１０は、口座振替依頼データを口座振替依頼データによって示される引落日に処理が行われるように口座振替システム１４に送信する。口座振替依頼データは、引落日、引落口座、入金口座、引落金額などの情報を含んでおり、口座振替システム１４は、口座振替依頼データを受信すると即座に（引落日は当日あるいは翌営業日にセット）、口座振替電文を生成して第２の銀行システム１８に対して送信する。

第２の銀行システム１８は、口座振替処理を実行し、資金は、口座振替システム１４を管理する決済代行業者の口座に送金される。決済処理装置１０は、口座振替依頼データのサプライヤー口座の情報に基づいて、決済代行業者の口座からサプライヤー口座への資金移動を示す振込電文を生成し、第１の銀行システム１７に送信する。その後、第１の銀行システム１７がサプライヤー口座に対する入金処理を実行する。

（ファイナンス処理、入金処理、保証処理）
ファイナンスとは、金融機関による立替払のことであり、ファイナンスの種類として、サプライヤー（債権者）にとっての早期資金化、及びバイヤー（債務者）にとっての支払先延ばしがある。

ファイナンスの一形態である早期資金化に関して、決済処理装置１０は、支払日が到来していない請求データ及び請求明細データを、決済処理装置１０が提供する画面インターフェース上でサプライヤー端末１１に提供する。決済処理装置１０は、サプライヤー端末１１によって選択された請求明細データについてファイナンス希望の旨をサプライヤー端末１１から受信すると、当該請求明細データに基づいて試算依頼データを生成してファイナンスシステム１５に送信する。ファイナンスシステム１５は、請求明細データの内容に基づいて早期資金化の試算を行い、試算結果を決済処理装置１０に送信する。決済処理装置１０は、試算結果を別の画面インターフェース上でサプライヤー端末１１に提供する。

決済処理装置１０は、試算結果を提供後にサプライヤー端末１１から早期資金化申込データを受信すると、当該申込データに基づいて入金依頼データを生成し、入金処理システム１６に送信する。入金処理システム１６は、入金依頼データに基づいて振込電文を生成して第１の銀行システム１７に送信する。第１の銀行システム１７は、振込電文に基づいてサプライヤー口座に対して入金処理を行う。また、決済処理装置１０は、当該申込データに関連付けられる請求明細データに基づいて口座振替依頼データを生成し、口座振替依頼データによって示される引落日に処理が行われるように口座振替システム１４に送信する。その後、上述したように、元々の支払予定日に口座振替処理が行われる。口座振替処理後には、サプライヤー口座宛の入金処理は行われない。

ファイナンスの他の形態である支払先延ばしに関して、決済処理装置１０は、支払日が到来していない請求データ及び請求明細データを、決済処理装置１０が提供する画面インターフェース上でバイヤー端末１２に提供する。決済処理装置１０は、バイヤー端末１２によって選択された請求明細データ及び希望支払日についてのファイナンス希望の旨をバイヤー端末１２から受信すると、当該請求明細データ及び希望支払日に基づいて試算依頼データを生成してファイナンスシステム１５に送信する。ファイナンスシステム１５は、請求明細データの内容及び希望支払日の情報に基づいて支払先延ばしの試算を行い、試算結果を決済処理装置１０に送信する。決済処理装置１０は、試算結果を別の画面インターフェース上でバイヤー端末１２に提供する。

決済処理装置１０は、試算結果を提供後にバイヤー端末１２から支払先延ばし申込データを受信すると、当該申込データに基づいて入金依頼データを生成し、入金処理システム１６に送信する。入金処理システム１６は、入金依頼データに基づいて振込電文を生成して第１の銀行システム１７に送信する。第１の銀行システム１７は、振込電文に基づいてサプライヤー口座に対して入金処理を行う。この入金は、元々の支払予定日に行われる。また、決済処理装置１０は、当該申込データに関連付けられる請求明細データに基づいて口座振替依頼データを生成し、口座振替依頼データによって示される引落日に処理が行われるように口座振替システム１４に送信する。この引落日は、バイヤーが設定した希望支払日である。口座振替処理後には、サプライヤー口座宛の入金処理は行われない。

なお、ファイナンス処理における振込電文の振込元口座は、入金処理システム１６を管理する事業者の銀行の口座であり、口座振替処理における入金口座は、決済代行業者の口座である。

さらに、決済処理装置１０は、早期資金化申込データまたは支払先延ばし申込データを受信すると、それぞれの申込に対応する保証申込データを生成してファイナンスシステム１５に送信する。ファイナンスシステム１５は、保証申込データに基づいて早期資金化あるいは支払先延ばしについての保証取組の処理を実行する。

（入金消込処理）
決済処理装置１０は、請求明細データに紐づく入金消込情報を一元管理することができる。決済処理装置１０は、口座振替処理によって入金された場合には、請求明細データのステータスに入金済と記憶されるので、入金消込結果をサプライヤー端末に提供する。口座振替処理によらず、バイヤーが振込を行う場合には、決済処理装置１０は、入金消込処理を希望する請求明細データをサプライヤー端末１１から受信し、請求処理システム１３に送信する。請求処理システム１３は、各金融機関システムから入金明細データを取得して入金消込処理を行い、処理結果を決済処理装置１０に送信する。決済処理装置１０は、請求処理システム１３から受信した入金消込処理結果を請求明細データのステータスに入金済と記憶することにより、入金消込結果をサプライヤー端末に提供する。

（金融機関の外部システムまたはサブシステムの機能）
請求処理システム１３は、決済処理装置１０から、請求データ及び請求明細データとバイヤーの通知先情報とを受信して、受信したデータに基づいて電子請求書を発行する。請求処理システム１３は、バイヤーの通知先情報に基づいて、あるいはバイヤー端末１２からの要求に応答して電子請求書をバイヤー端末１２に提供する。

請求処理システム１３は、入金消込処理を希望する請求明細データを決済処理装置１０から受信した後、各金融機関システムから入金明細データを受信して入金消込処理を実行し、入金消込処理結果を決済処理装置１０に提供する。

口座振替システム１４は、受信した口座振替依頼データに基づいて、バイヤー口座を有する金融機関の第２の銀行システム１８に対してバイヤー口座から資金を引き落とす口座振替処理を依頼し、第２の銀行システム１８は、引き落とした資金を所定の口座に資金移動する。受信した口座振替依頼データは、契約情報に含まれる支払予定日、すなわち、口座振替依頼データを受信した当日（あるいは翌営業日）、またはバイヤー希望のファイナンス（立替払）依頼の際に指定した希望支払日に口座振替が実行されることを示してもよい。

ファイナンスシステム１５は、ファイナンス希望のあった請求明細データ及び保証の情報に基づいて試算を行い、早期資金化に対する試算結果を決済処理装置１０に提供する。ファイナンスシステム１５は、ファイナンス希望のあった請求明細データ、保証の情報及びバイヤーが指定した希望支払日に基づいて試算を行い、支払先延ばしに対する試算結果を決済処理装置１０に提供する。ファイナンスシステム１５は、保証申込データに基づいて保証取組の処理を実行する。

入金処理システム１６は、決済処理装置１０から受信した入金依頼データに基づいて振込電文を生成し、入金依頼データに含まれる振込先口座に対応する金融機関のシステム、例えば、サプライヤー口座を有する第１の銀行システム１７に振込電文を送信して入金処理を実行する。

（決済処理装置１０のシステム構成）
次に、決済処理装置１０のシステム構成を説明する。図２は、本発明の実施形態に係る決済処理装置１０のシステム構成図である。図２に示すように、決済処理装置１０は、一般的なコンピュータと同様に、バス１２０などによって相互に接続された制御部１０１、主記憶部１０２、補助記憶部１０３、ＩＦ部１０４、及び出力部１０５を備える。補助記憶部１０３は、決済処理装置１０の各機能を実装するプログラム、及び当該プログラムで取り扱うデータを格納する。補助記憶部１０３は、ファイル／データベースなどの形式で、ユーザマスタ１０６、契約／決済情報１０７、請求データ１０８、及び請求明細データ１０９を備える。決済処理装置１０は、ユーザマスタ１０６、契約／決済情報１０７、請求データ１０８、及び請求明細データ１０９に格納されている情報を読み出し、編集し、あるいは更新できる。補助記憶部１０３に格納されている各種プログラムは、決済処理装置１０によって実行される。

制御部１０１は、中央処理装置（ＣＰＵ）とも呼ばれ、決済処理装置１０の各構成要素の制御やデータの演算を行い、また、補助記憶部１０３に格納されている各種プログラムを主記憶部１０２に読み出して実行する。主記憶部１０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令及び当該命令による演算処理後のデータなどを記憶する。補助記憶部１０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

図２の実施形態は、制御部１０１、主記憶部１０２及び補助記憶部１０３を同一のコンピュータの内部に設ける実施形態について説明するが、他の実施形態として、決済処理装置１０は、制御部１０１、主記憶部１０２及び補助記憶部１０３を複数個使用することにより、複数のコンピュータによる並列分散処理を実現するように構成することもできる。他の実施形態として、決済処理装置１０のための複数のサーバを設置し、複数サーバが一つの補助記憶部１０３を共有する実施形態にすることも可能である。

ＩＦ部１０４は、他のシステムや装置との間でデータを送受信する際のインターフェース（ＩＦ）の役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供する。出力部１０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供する。

ユーザマスタ１０６は、本発明に係る決済処理装置１０を利用するサプライヤー及びバイヤーなどのユーザの情報を格納する。図３は、本発明の実施形態に係るユーザマスタ１０６のデータ構造の一例を示す図である。ユーザマスタ１０６は、ユーザＩＤ３０１、ユーザ名称３０２、ユーザ部署ＩＤ３０３、ユーザ部署名称３０４、及びユーザ情報３０５を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

ユーザＩＤ３０１は、本発明に係る決済処理装置１０を利用するユーザ（企業など）を識別する識別子である。ユーザは、企業間取引においてサプライヤーにもなり得るし、バイヤーにもなり得る。ユーザ名称３０２は、ユーザの名称（企業名など）を示す。ユーザ部署ＩＤ３０３は、ユーザの組織内の部署を識別する識別子である。ユーザは、企業間取引の当事者となり得る組織や企業内の管理部門の組織を登録し得る。ユーザ部署名称３０４は、ユーザの組織内の部署名（例えば、〇〇営業部、△△企画部など）を示す。

ユーザ情報３０５は、ユーザの連絡先（電子メールアドレス、電話番号、住所など）、決済口座、決裁者、及び決裁ルートなどのユーザの各種情報を示す。決済口座は、入出金処理の際に使用される銀行口座の情報を示す。決裁者は、未承認請求データに対してサプライヤーやバイヤーにおいて承認を行う者を示し、承認を行う者は、ユーザにおける部署であってよい。決裁ルートは、決裁者が複数いる場合の決裁順序のルートを示し、決裁順序は、ユーザ部署ＩＤに順序を付する形で設定されてよい。なお、決裁ルートは、予め登録せずに承認画面上で都度選択するように構成されてもよい。

本発明の一実施形態では、決済処理装置１０は、権限登録画面（不図示）をユーザに提供することにより、ユーザ部署ＩＤ３０３ごとに登録された操作権限に従って各種メニューの操作の実行可否を制御するように構成されることが可能である。例えば、ユーザ企業の３つの部署が登録されており、部署Ａは、売上データの登録、全部署の請求データ承認、早期資金申込、及びデータ閲覧の全てが実行可能であり、他の部署Ｂ、Ｃは、売上データの登録ができず、自部署のみの請求データ承認、早期資金申込、及びデータ閲覧が実行可能なように制御されてよい。

図２に戻って説明すると、契約／決済情報１０７は、企業間取引におけるサプライヤー及びバイヤー間の取引に関する契約情報及び決済情報を格納する。サプライヤーは、決済処理装置１０によって提供される契約／決済情報登録画面１０００を介して、契約情報及び決済情報を登録する。図４は、本発明の実施形態に係る契約／決済情報１０７のデータ構造の一例を示す図である。契約／決済情報１０７は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、決済条件４０３、及び与信状況４０４を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

サプライヤーＩＤ４０１は、企業間取引におけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、企業間取引におけるバイヤーを示す識別子である。サプライヤーＩＤ４０１及びバイヤーＩＤ４０２として設定される識別子は、ユーザＩＤ３０１またはユーザ部署ＩＤ３０３であってよい。決済条件４０３は、サプライヤーとバイヤーの間で予め取り交わされている決済条件を示す。決済条件は、締日、売上データ登録期限、及び支払日（例えば、月末）などであってよい。与信状況４０４は、サプライヤーがバイヤーに対して設定した債権の枠（上限額）及び現在残高を示す。

図１０は、契約／決済情報登録画面１０００の一例を示す図である。サプライヤーは、サプライヤー端末１１を介して契約／決済情報登録画面１０００の各データを登録することができる。

図２に戻って説明すると、請求データ１０８は、サプライヤーによってアップロードされた売上データのサマリー情報を格納する。サマリー情報は、未承認請求データまたは請求データを示す。図５は、本発明の実施形態に係る請求データ１０８のデータ構造の一例を示す図である。請求データ１０８は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、ファイルＩＤ５０１、ファイル名５０２、作成日５０３、データ件数５０４，合計金額５０５、支払日５０６、変更前支払日５０７、支払方法５０８、ステータス５０９、及び承認期限５１０を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

サプライヤーＩＤ４０１は、請求データにおけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、請求データにおけるバイヤーを示す識別子である。ファイルＩＤ５０１は、サプライヤーによってアップロードされた売上データファイルを識別する識別子である。売上データファイルには、１または複数の未承認請求明細データが含まれている。ファイル名５０２は、アップロードされた売上データファイルに付された名称である。作成日５０３は、売上データファイルの作成日である。データ件数５０４は、売上データファイルに含まれる明細データのデータ件数である。合計金額５０５は、売上データファイルに含まれる請求明細の合計請求額を示す。

支払日５０６は、支払が行われる予定日を示す。変更前支払日５０７は、支払日が変更された場合の以前の支払予定日を示す。支払方法５０８は、バイヤーからサプライヤーに対する支払が行われる方法（例えば、口座振替、振込など）を示す。ステータス５０９は、未承認請求データまたは請求データの状態を示す。この状態は、例えば、サプライヤー承認待ち、バイヤー承認待ち、口座振替依頼待ち、入金待ち、入金済などを示し、通常、請求明細データ１０９の対応するデータ群のステータスと同期する。承認期限５１０は、未承認請求データに対するサプライヤー及びバイヤーの承認期限を示す。

図２に戻って説明すると、請求明細データ１０９は、未承認請求データに関連付けられる未承認請求明細データまたは請求データに関連付けられる請求明細データを格納する。図６は、本発明の実施形態に係る請求明細データ１０９のデータ構造の一例を示す図である。請求明細データ１０９は、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、ファイルＩＤ５０１、支払日５０６、請求番号６０１、請求内容６０２、請求金額６０３、支払予定日６０４、ステータス６０５、ファイナンスフラグ６０６、保証フラグ６０７、入金口座６０８、及び出金口座６０９を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことができる。

サプライヤーＩＤ４０１は、請求明細データにおけるサプライヤーを示す識別子である。バイヤーＩＤ４０２は、請求明細データにおけるバイヤーを示す識別子である。ファイルＩＤ５０１は、それぞれの請求明細データに関連付けられる売上ファイルの識別子である。支払日５０６は、請求明細データに関連付けられる請求データの支払日を示し、サプライヤー及びバイヤー間の１つ以上の明細データをまとめる単位となる。請求番号６０１は、請求明細データを識別する識別子である。請求内容６０２は、請求の内容（例えば、物品代、サービス代）を示す。請求金額６０３は、請求明細データによって示される請求金額を示す。支払予定日６０４は、個々の請求に対して支払が予定される日を示す。

ステータス６０５は、請求明細データの状態を示す。請求明細データの状態は、例えば、サプライヤー承認待ち、バイヤー承認待ち、口座振替依頼待ち、入金待ち、入金済などを示す。ファイナンスフラグ６０６は、サプライヤー及びバイヤーの間で予め取り決めた支払サイトよりも早期に資金化する希望があるかどうか、あるいはバイヤーが支払先延ばしを希望しているかどうかを示すフラグである。保証フラグ６０７は、銀行保証または自社保証が選択されているかどうかを示す。入金口座６０８は、入金口座、例えば、サプライヤー口座を示す。出金口座６０９は、出金口座、例えば、バイヤー口座を示す。

（各種フローについての説明）
図７～図９を参照しながら、決済処理装置１０によって実行される様々な処理、すなわち、売上ファイルのアップロードから電子請求書の提供、口座振替及び振込による資金移動、ファイナンス及び保証取組の処理のフローを説明する。これらの処理フローを説明する前提として、サプライヤー及びバイヤーとなり得るユーザは、決済処理装置１０によってユーザＩＤが割り当てられており、ユーザ関連の各種情報はユーザマスタ１０６に登録されているものとする。企業間取引におけるサプライヤー及びバイヤー間の取引に関する契約情報及び決済情報は、契約／決済情報１０７に登録されているものとする。

（処理フロー：売上ファイルのアップロードから電子請求書の提供）
図７は、売上ファイルのアップロードから電子請求書の提供までの処理を説明するフロー図である。より詳細に言えば、決済処理装置１０が、サプライヤーからアップロードされた売上データファイルのデータを基に未承認請求データを生成し、サプライヤー及びバイヤーにおける１または複数の決裁者の承認を受けた後に請求書発行の元データを請求処理システム１３に送信し、請求処理システム１３が電子請求書を生成してバイヤーに提供する処理フローを説明する。

Ｓ７０１にて、決済処理装置１０は、サプライヤー端末１１から、サプライヤーとバイヤー間の取引結果を示す売上データファイルを受信する。売上データファイルは、所定のフォーマットに基づいて生成されており、決済処理装置１０は、例えば、任意のアップロード画面（不図示）を介して売上データファイルを受信する。売上データファイルのアップロードは、サプライヤーとバイヤーの間で取り決めた締日の後、売上データ登録期限までに行われる。本発明の実施形態では、売上データファイルをアップロードする部署と、売上データの内容を承認する部署は同一であっても、異なっていてもよい。決済処理装置１０が売上データを受信する方法は、ファイルアップロードに限らず、任意の方法によって実行されてよく、特に限定されない。

Ｓ７０２にて、決済処理装置１０は、売上データファイルを受信すると、受信した売上データファイルに含まれるサプライヤーＩＤ及びバイヤーＩＤに基づいて、ユーザマスタ１０６及び契約／決済情報１０７に問い合わせを行ってサプライヤー及びバイヤーの決済口座、支払日、決裁者、及び決裁ルートなどの情報を取得し、売上データファイルの内容に基づいて、データ件数、請求合計金額を算出する。決済処理装置１０は、これらの情報に基づいて未承認請求データのサマリー情報を生成して請求データ１０８に格納し、未承認請求明細データを生成して請求明細データ１０９に格納する。格納された未承認請求データのステータス５０９及び未承認請求明細データのステータス６０５は、「サプライヤー承認待ち」となり、それぞれの未承認請求明細データの入金口座６０８にはサプライヤーの口座がセットされており、出金口座６０９にはバイヤーの口座がセットされている。

Ｓ７０３にて、決済処理装置１０は、請求データ１０８及び請求明細データ１０９から未承認請求データ及び未承認請求明細データを読み出して、サプライヤー承認画面（不図示）を介してサプライヤー端末１１に提供する。サプライヤー承認画面は、任意の未承認請求データに関連付けられる未承認請求明細データを一覧表示し、サプライヤーの承認者は、個々のデータについてそのまま承認するか、あるいは変更するかを登録することができる。サプライヤーの承認者は、例えば、修正する場合にコメントを入力することができ、早期入金を希望する場合にその旨を指定することができ、早期入金を指定する場合に銀行保証とするか自社保証とするかを指定することができる、といった各種の操作を行うことができる。

決済処理装置１０は、未承認請求データ及び未承認請求明細データが生成されたことをサプライヤーの最初の決裁者に通知してもよい。サプライヤーの決裁者は、サプライヤー承認画面に表示されているデータの内容に誤りがないか等を確認し、サプライヤー端末１１を介して画面上の承認ボタンを押下する。サプライヤーにおいて次の決裁者が存在する場合には、決済処理装置１０は、次の決裁者に確認すべき未承認データが存在することを通知する。このような承認処理は、サプライヤーにおける決裁者の数だけ繰り返される。サプライヤーが設定した全ての決裁者による承認処理が完了すると、決済処理装置１０は、未承認請求データのステータス５０９及び未承認請求明細データのステータス６０５をそれぞれ「バイヤー承認待ち」に更新する。

なお、サプライヤーの任意の決裁者は、データに不備を発見した場合、コメント付きの否認通知を登録することができ、かかる場合、決済処理装置１０は、売上データファイルをアップロードした部署に対してコメント付きの否認通知を送信し、データ修正を促すことができる。

Ｓ７０４にて、決済処理装置１０は、ステータス５０９、６０５が「バイヤー承認待ち」を示す未承認請求データ及び未承認請求明細データを請求データ１０８及び請求明細データ１０９からそれぞれ読み出して、バイヤー承認画面（不図示）を介してバイヤー端末１２に提供する。バイヤー承認画面は、「バイヤー承認待ち」の未承認請求データに関連付けられる未承認請求明細データを一覧表示し、バイヤーの承認者は、個々のデータについてそのまま承認するか、あるいは変更するかを登録することができる。バイヤーは、バイヤー承認画面のおかげで、支払額及び支払日を事前に確認することができ、承認した内容であれば口座振替により支払が行われても安心できる。バイヤーの承認者は、支払予定日の先延ばしを希望する場合には、希望支払日を登録することもできる。本願発明では、請求データがサマリー情報を示し、請求明細データが個々の明細を示すため、任意の請求明細データの支払予定日が変更された場合、サマリー情報としての請求データが更新され、新規の請求データが生成される。例えば、あるサプライヤーとバイヤーの取引について、４月末日支払のデータが３件あり、そのうちの１件の支払予定日を５月に先延ばしする場合、５月支払の請求データが１件追加されるとともに、既存の４月払いの請求データの情報がアップデートされることとなる。

決済処理装置１０は、サプライヤーによる承認が完了したら、バイヤー承認待ちのデータがあることをバイヤーの最初の決裁者に通知してもよい。バイヤーの決裁者は、通知を受信した後、バイヤー承認画面に表示されているデータの内容を確認し、場合によっては、支払予定日の情報を変更した上でバイヤー端末１２を介して画面上の承認ボタンを押下する。バイヤーにおいて次の決裁者が存在する場合には、決済処理装置１０は、次の決裁者に確認すべき未承認データが存在することを通知する。このような承認処理は、バイヤーにおける決裁者の数だけ繰り返される。バイヤーが設定した全ての決裁者による承認処理が完了すると、決済処理装置１０は、未承認請求データのステータス５０９及び未承認請求明細データのステータス６０５を「口座振替依頼待ち」に更新する。サプライヤー及びバイヤーによって承認された未承認請求データ及び未承認請求明細データは、それぞれ、請求データ及び請求明細データと呼ぶこととする。

なお、バイヤーの任意の決裁者は、データに不備を発見した場合（例えば、支払予定日が望ましくない場合など）、コメント付きの否認通知を登録することができ、かかる場合、決済処理装置１０は、不備のあるデータを登録した部署あるいは最初に承認した部署に対してコメント付きの否認通知を送信し、データ修正を促すことができる。

Ｓ７０５にて、決済処理装置１０は、ステータス５０９が「口座振替依頼待ち」の請求データ及びステータス６０５が「口座振替依頼待ち」の請求明細データを読み出し、サプライヤーＩＤ４０１、バイヤーＩＤ４０２、及び支払日５０６のセット単位で請求書用データを生成して請求処理システム１３に送信する。請求処理システム１３は、受信した請求書用データに基づいて電子請求書を生成し、生成した電子請求書をバイヤー端末１２に提供する。

上述したように、サプライヤーが売上データファイルをアップロードした後は、各種画面上で請求内容を確認し、必要に応じて内容を修正し、承認するだけで電子請求書がバイヤーに対して提供されるようになる。請求データの承認後は、図８を参照しながら説明される口座振替処理が実行されたり、あるいはバイヤーが契約に従って振込処理を行ったりすることとなる。決済処理装置１０は、ウェブベースの統一インターフェースを介してサプライヤー端末１１及びバイヤー端末１２との間でやり取りを行って電子請求書の送付まで実行できるので、サプライヤーの従来の手間は大幅に削減されることになる。

（処理フロー：口座振替及び振込による資金移動）
図８は、サプライヤー及びバイヤー間の口座振替による資金移動処理を説明するフロー図である。より詳細に言えば、決済処理装置１０が、支払予定日が到来する請求明細データに基づいて口座振替依頼データを生成し、口座振替システム１４に口座振替依頼データを送信して資金移動を実行する処理フローを説明する。

Ｓ８０１にて、決済処理装置１０は、支払予定日が到来する、ステータス６０５が「口座振替依頼待ち」を示す請求明細データを請求明細データ１０９から読み出す。すなわち、決済処理装置１０は、処理当日が支払予定日であるデータを読み出す。

Ｓ８０２にて、決済処理装置１０は、読み出した請求明細データに含まれる支払予定日６０４、請求金額６０３、入金口座６０８，及び出金口座６０９の情報に基づいて口座振替依頼データを生成するとともに、読み出した請求明細データと当該請求明細データに関連付けられる請求データのステータス５０９、６０５をそれぞれ「入金待ち」に更新する。口座振替依頼データの入金口座は、サプライヤー口座あるいは口座振替システム１４を管理する決済代行業者の口座であってよい。

決済処理装置１０は、口座振替依頼データを口座振替システム１４に送信する。口座振替システム１４は、口座振替依頼データに基づいて所定フォーマットに基づく口座振替依頼電文を生成し、口座振替依頼データに含まれるバイヤー口座に対応する金融機関の第２の銀行システム１８に口座振替依頼電文を送信する。第２の銀行システム１８は、口座振替処理の結果データを口座振替システム１４を介して決済処理装置１０に送信する。また、第２の銀行システム１８は、バイヤー口座から資金を引き落とし、決済代行業者の口座を有する銀行に送金する。当該銀行は、決済代行業者の口座に対して入金処理を行う。

Ｓ８０３にて、決済処理装置１０は、口座振替処理の結果データを第２の銀行システム１８から受信したことに応答して、口座振替依頼データに対応する入金依頼データを生成する。入金依頼データは、決済代行業者の口座を出金口座として、サプライヤー口座を入金口座とする入金依頼データであってよい。決済処理装置１０は、入金依頼データを口座振替システム１４に送信し、口座振替システム１４が入金依頼データに基づいて振込電文を生成し、第１の銀行システム１７に送信する。第１の銀行システム１７は、振込電文に基づいてサプライヤー口座に対して入金処理を実行する。

Ｓ８０４にて、決済処理装置１０は、口座振替処理の結果データに基づいて、口座振替処理に関連付けられる請求明細データのステータス６０５を「入金済み」に更新するとともに、当該請求明細データに関連付けられる請求データのステータス５０９を「入金済み」に更新する。

これらの処理により、サプライヤーは、請求金額及び支払期日を管理する事務作業を大幅に削減することができるようになる。また、Ｓ８０４の更新処理により、請求データ及び請求明細データのステータスが「入金済」と表示されることにより、それぞれの請求に対する入金消込の事務作業を従来よりも簡便に行うことができるようになる。サプライヤー端末１１は、ステータスが「入金済」の請求データ及び請求明細データを取得できるので、サプライヤーは、入金消込の確認が簡単に行えるようになる。

（処理フロー：ファイナンス及び保証取組）
ファイナンスとは、金融機関による立替払のことであり、ファイナンスの種類として、サプライヤー（債権者）にとっての早期資金化、及びバイヤー（債務者）にとっての支払先延ばしがある。図９（ａ）は、サプライヤーにとってのファイナンス処理を説明するフロー図であり、図９（ｂ）は、バイヤーにとってのファイナンス処理を説明するフロー図である。

図９（ａ）を参照しながら、決済処理装置１０が、サプライヤーからのファイナンス依頼（早期資金化依頼）を受信したことに応答して試算を行った結果をサプライヤーに提供し、サプライヤーからファイナンス申込を受信したことに応答して入金依頼データを生成するとともに、保証申込データを生成する処理フローを説明する。

Ｓ９０１にて、決済処理装置１０は、サプライヤー端末１１からの要求に応答して、口座振替依頼データを生成していない請求明細データ、すなわち、ステータス６０５が「口座振替依頼待ち」の請求明細データを、それらに関連付けられる売上データファイル単位でサプライヤー端末１１に提供する。サプライヤーは、ディスプレイに表示されている請求明細データのうち早期資金化を希望するデータを選択し、早期資金化依頼ボタン（不図示）を押下する。決済処理装置１０は、選択された請求明細データについての早期資金化依頼を受信する。受信した請求明細データのファイナンスフラグ６０６には早期資金化希望を示す所定の値（例：銀行保証を示す値、自社保証を示す値）がセットされている。

Ｓ９０２にて、決済処理装置１０は、早期資金化依頼された請求明細データの内容及び保証の情報（例えば、所定の値）に基づいて早期資金化するための試算依頼をファイナンスシステム１５に送信する。ファイナンスシステム１５は、受信した請求明細データの内容及び保証の情報に基づいて試算を行い、試算結果を決済処理装置１０に送信する。ファイナンスシステム１５は、支払予定日までの日数によって試算結果が変わることを示してもよい。

Ｓ９０３にて、決済処理装置１０は、ファイナンスシステム１５から試算結果を受信したことに応答して、サプライヤー端末１１に試算結果を提供する。試算結果が許容可能なものであれば、サプライヤーは、サプライヤー端末１１を介して早期資金化申込を登録する。決済処理装置１０は、サプライヤー端末１１から試算結果に基づく早期資金化申込を受信する。

Ｓ９０４にて、決済処理装置１０は、早期資金化申込を受信すると、ユーザマスタ１０６に問い合わせを行ってサプライヤーの決済口座の情報を取得し、サプライヤー口座に対する入金処理を行うための入金依頼データを生成して入金処理システム１６に送信する。入金処理システム１６は、入金依頼データに基づいて第１の銀行システム１７に振込電文を送信し、第１の銀行システム１７は、サプライヤー口座に対して入金処理を行う。

Ｓ９０５にて、決済処理装置１０は、早期資金化申込を受信すると、銀行による保証を受けるための保証申込データを生成し、生成した保証申込データをファイナンスシステム１５に送信する。ファイナンスシステム１５は、保証申込データに基づいて保証取組の処理を実行する。

上述の処理により、サプライヤーは、入金予定日よりも早期に債権を資金化することができるようになる。決済処理装置１０は、早期資金化を行った請求明細データについては支払予定日に口座振替処理を行う。口座振替の結果、バイヤー口座から引き落とされた資金は、決済代行業者の口座に入金され、その後、振込電文の出金元口座に入金される。

次に、図９（ｂ）を参照しながら、決済処理装置１０が、バイヤーからのファイナンス依頼（支払先延ばし依頼）を受信したことに応答して試算を行った結果をバイヤーに提供し、バイヤーからファイナンス申込を受信したことに応答して入金依頼データを生成するとともに、保証申込データを生成して、選択した請求明細の支払予定日を変更する処理フローを説明する。

Ｓ９１１にて、決済処理装置１０は、バイヤー端末１２からの要求に応答して、口座振替依頼データを生成していない請求明細データ、すなわち、ステータス６０５が「口座振替依頼待ち」の請求明細データを、それらに関連付けられる売上データファイル単位でバイヤー端末１２に提供する。バイヤーは、ディスプレイに表示されている請求明細データのうち支払先延ばしを希望するデータを選択するとともに、希望支払日を入力し、支払先延ばし依頼ボタン（不図示）を押下する。決済処理装置１０は、選択された請求明細データについての支払先延ばし依頼を受信する。支払先延ばし依頼は、入力された希望支払日の情報を含んでいる。受信した請求明細データのファイナンスフラグ６０６には支払先延ばし希望を示す所定の値がセットされている。

Ｓ９１２にて、決済処理装置１０は、支払先延ばしを依頼された請求明細データの内容について支払予定日を希望支払日に先延ばしするための試算依頼をファイナンスシステム１５に送信する。ファイナンスシステム１５は、受信した請求明細データの内容と希望支払日に基づいて試算を行い、試算結果を決済処理装置１０に送信する。

Ｓ９１３にて、決済処理装置１０は、ファイナンスシステム１５から試算結果を受信したことに応答して、バイヤー端末１２に試算結果を提供する。試算結果が許容可能なものであれば、バイヤーは、バイヤー端末１２を介して支払先延ばし申込を登録する。決済処理装置１０は、バイヤー端末１２から試算結果に基づく支払先延ばし申込を受信する。

Ｓ９１４にて、決済処理装置１０は、支払先延ばし申込を受信すると、請求明細データに元々登録されていた支払予定日に入金処理を行うための入金依頼データを生成して入金処理システム１６に送信する。入金処理システム１６は、入金依頼データに基づいて第１の銀行システム１７に振込電文を送信し、第１の銀行システム１７は、サプライヤー口座に対して入金処理を行う。

Ｓ９１５にて、決済処理装置１０は、支払先延ばし申込を受信すると、銀行による保証を受けるための保証申込データを生成し、生成した保証申込データをファイナンスシステム１５に送信する。ファイナンスシステム１５は、保証申込データに基づいて保証取組の処理を実行する。

Ｓ９１６にて、決済処理装置１０は、支払先延ばし申込を行った請求明細データの支払予定日６０４に希望支払日を、入金口座６０８に保証取組を行っている金融機関の所定の口座をそれぞれセットして更新処理を行う。更新処理された請求明細データに基づいて口座振替処理が行われ、希望支払日にバイヤー口座から資金（請求明細データに元々セットされていた金額）が引き落とされ、引き落とされた資金は、決済代行業者口座を経由して入金処理システム１６を管理する事業者の口座に入金される。

上述の処理により、保証取組を行っている金融機関がサプライヤーに対する立替払いを行うため、サプライヤーは、当初の入金予定日に資金を受け取ることができ、一方、バイヤーは、当初の支払予定日を希望支払日に先延ばしすることができるようになる。なお、保証料については別途請求される。

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成及び細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施態様を採ることが可能である。

１０ 決済処理装置
１１ サプライヤー端末
１２ バイヤー端末
１３ 請求処理システム
１４ 口座振替システム
１５ ファイナンスシステム
１６ 入金処理システム
１７ 第１の銀行システム
１８ 第２の銀行システム
１９ 第１のネットワーク
２０ 第２のネットワーク
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ インターフェース（ＩＦ）部
１０５ 出力部
１０６ ユーザマスタ
１０７ 契約／決済情報
１０８ 請求データ
１０９ 請求明細データ
１０００ 契約／決済情報登録画面

Claims (8)

1. 外部ネットワークと通信するための通信部、記憶部、及び制御部を備えた決済処理装置であって、
   前記制御部は、
   第１のユーザ及び第２のユーザ間の取引を示し、かつ同一の支払日を示す請求データ及び請求明細データであって、それぞれのステータスが口座振替依頼待ちを示す請求データ及び請求明細データを前記記憶部から読み出して電子請求書生成用データを生成し、前記第２のユーザに提示する電子請求書を請求処理システムに発行させるために、前記電子請求書生成用データを前記通信部を介して前記請求処理システムに送信することであって、前記請求データ及び前記請求明細データは、前記第１のユーザからの売上データに基づく、ことと、
   そのステータスが前記口座振替依頼待ちを示す前記請求明細データを読み出し、読み出した前記請求明細データに基づいて、前記第２のユーザの口座から決済代行業者の口座への口座振替依頼データを生成し、前記通信部を介して口座振替システムに送信するとともに、読み出した前記請求明細データと、読み出した前記請求明細データに関連付けられる請求データのそれぞれのステータスを入金待ちに更新することと、
   前記口座振替依頼データに基づいて行われた口座振替処理の結果に応答して、前記決済代行業者の口座から前記第１のユーザの口座への入金依頼データを生成し、前記通信部を介して前記入金依頼データを前記口座振替システムに送信するとともに、前記口座振替依頼データに関連付けられる請求データ及び請求明細データのそれぞれのステータスを入金済に更新することと、
   を実行する決済処理装置。
2. 前記制御部は、
   第１のユーザ端末によって選択された、そのステータスが前記口座振替依頼待ちの前記請求明細データについての第１のファイナンス依頼を受信することと、
   前記通信部を介してファイナンスシステムに送信するための第１の試算依頼であって、前記第１のファイナンス依頼に関連付けられる前記選択された請求明細データの内容に基づいて早期資金化するための第１の試算依頼を生成することと、
   をさらに実行する、請求項１の決済処理装置。
3. 前記制御部は、
   前記第１の試算依頼に対する試算結果に基づく早期資金化申込を受信したことに応答して、前記通信部を介して入金処理システムに送信するための、前記入金処理システムを管理する事業者の口座から第１のユーザ口座に対する入金処理を行う第１の入金依頼データを生成することと、
   をさらに実行する、請求項２の決済処理装置。
4. 前記制御部は、
   第２のユーザ端末によって選択された、そのステータスが前記口座振替依頼待ちの前記請求明細データについての第２のファイナンス依頼を受信することであって、前記第２のファイナンス依頼は、第２のユーザによって入力された希望支払日を含む、ことと、
   前記通信部を介してファイナンスシステムに送信するための第２の試算依頼であって、前記第２のファイナンス依頼に関連付けられる前記選択された請求明細データの内容と前記希望支払日に基づく立替払のための第２の試算依頼を生成することと、
   をさらに実行する、請求項１の決済処理装置。
5. 前記制御部は、
   前記第２の試算依頼に対する試算結果に基づく支払先延ばし申込を受信したことに応答して、前記通信部を介して入金処理システムに送信するための第１の入金依頼データであって、前記第２のユーザ端末によって選択された請求明細データに含まれている支払日に前記入金処理システムを管理する事業者の口座から前記第１のユーザの口座に対する入金処理を行うための第１の入金依頼データを生成することと、
   前記通信部を介して口座振替システムに送信するための口座振替依頼データであって、前記第２のユーザ端末によって選択された請求明細データに含まれている請求額を引落額とし、前記希望支払日を支払日とし、入金口座を前記入金処理システムを管理する事業者の口座とする口座振替依頼データを生成することと、
   をさらに実行する、請求項４の決済処理装置。
6. 前記制御部は、
   第１のユーザ端末から受信した前記売上データに基づいて、未承認請求データ及び未承認請求明細データを生成して前記記憶部に格納することと、
   前記未承認請求データ及び前記未承認請求明細データを前記第１のユーザ端末に提供し、前記第１のユーザ端末から第１の承認を受信して前記未承認請求データ及び前記未承認請求明細データのそれぞれのステータスをバイヤー承認待ちに更新することと、
   それぞれのステータスが前記バイヤー承認待ちを示す未承認請求データ及び未承認請求明細データを第２のユーザ端末に提供し、前記第２のユーザ端末から第２の承認を受信して前記それぞれのステータスが前記バイヤー承認待ちを示す未承認請求データ及び未承認請求明細データのそれぞれのステータスを前記口座振替依頼待ちに更新することにより、請求データ及び請求明細データを前記記憶部に格納することと、
   をさらに実行する、請求項１の決済処理装置。
7. 決済処理装置によって実行される方法であって、
   前記決済処理装置は、外部ネットワークと通信するための通信部、記憶部、及び制御部を備え、前記方法は、
   第１のユーザ及び第２のユーザ間の取引を示し、かつ同一の支払日を示す請求データ及び請求明細データであって、それぞれのステータスが口座振替依頼待ちを示す請求データ及び請求明細データを前記記憶部から読み出して電子請求書生成用データを生成し、前記第２のユーザに提示する電子請求書を請求処理システムに発行させるために、前記電子請求書生成用データを前記通信部を介して前記請求処理システムに送信することであって、前記請求データ及び前記請求明細データは、前記第１のユーザからの売上データに基づく、ことと、
   そのステータスが前記口座振替依頼待ちを示す前記請求明細データを読み出し、読み出した前記請求明細データに基づいて、前記第２のユーザの口座から決済代行業者の口座への口座振替依頼データを生成し、前記通信部を介して口座振替システムに送信するとともに、読み出した前記請求明細データと、読み出した前記請求明細データに関連付けられる請求データのそれぞれのステータスを入金待ちに更新することと、
   前記口座振替依頼データに基づいて行われた口座振替処理の結果に応答して、前記決済代行業者の口座から前記第１のユーザの口座への入金依頼データを生成し、前記通信部を介して前記入金依頼データを前記口座振替システムに送信するとともに、前記口座振替依頼データに関連付けられる請求データ及び請求明細データのそれぞれのステータスを入金済に更新することと、
   を備える方法。
8. 請求項７に記載の方法をコンピュータに実行させるためのプログラム。

Images