JP5927304B2 - 決済業務支援システムおよび決済業務支援方法 - Google Patents

Description

本発明は、決済業務支援システムおよび決済業務支援方法に関する。

昨今、企業間取引の電子化が図られており、債権債務に関する処理が電子的に行われるケースも増えている。例えば、入金と電子債権との対応関係を確実に管理し、効率的な消込管理を可能とする技術として、以下の技術が提案されている。

すなわち、買掛債務の情報を買掛債務者端末より受信してメモリに格納し当該メモリにおける各買掛債務情報毎に一意の電子債権コードの割り振りを実行し買掛債務情報を電子債権原簿データベースに登録する電子債権管理部と、買掛債務者から電子債権コードを指定してなされた入金の情報を金融機関の端末より取得し入金データベース６に格納する決済管理部と、入金データベースに格納されている入金情報を読み出して電子債権原簿データベースでの電子債権情報の検索を実行しこの検索処理で特定された電子債権情報のレコードを電子債権原簿データベースから削除等の消込処理を実行する消込管理部と、消込処理がなされた電子債権の属性情報を電子債権原簿データベースより抽出し買掛債務者端末等へ通知する消込結果通知部とから構成された、売掛債権消込管理システム（特許文献１参照）などが提案されている。

特開２００７−１０２４５７号公報

上述した企業間取引の電子化に伴い、複数企業間で情報を共有し、インターネット上での企業間取引の場となる、いわゆるＢｔｏＢプラットフォームのサービスも登場している。こうしたプラットフォームでは、製品の設計、販売、生産、調達、支払といった様々な業務に関して企業間連携を実現している。一方、こうしたプラットフォームにおける取引で、企業間の債権債務は確定するが、その決済方法（例えば、送金、口座振替、手形、小切手等）は該当企業間で個別に取り決められ、プラットフォームを通じて統一されていない。従って、上述のプラットフォームでの企業間取引と、その後の決済に伴う銀行取引との間で有為な連携は図られていない。

そのため、例えばバイヤーは、サプライヤーから受け取る多数であり、紙で送付されるインボイス（請求書）の内容を請求書データとして記録し、それに従って送金等の買掛金支払業務を逐一実行する必要があり、作業負荷や、送金、決済コストが大きくなりやすい。一方、サプライヤーは、バイヤーからの売掛金の入金情報を銀行システムから得られるものの、この入金情報は必ずしも請求書単位となっていないため、売掛債権との紐付け（消し込み）を行う際に、相応の手間や時間、販売管理費がかかってしまう。

また、上述した企業間取引と銀行取引との間の連携が無いことで、例えば、企業同士が合意した支払条件が実際には遵守されなかった場合のエビデンスが確保しにくく、不正行為や事務処理ミスが放置される懸念もある。こうした懸念は、公正なビジネス慣習が確立されていない新興国等で特に強い。

そこで本発明の目的は、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減を可能とする技術を提供することにある。

上記課題を解決する本発明の決済業務支援方法は、企業間の電子商取引を仲介するコンピュータが、
電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理を実行し、
前記バイヤーの端末が、
当該バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理を実行し、
前記コンピュータが、
前記バイヤーの端末から受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理を実行し、
前記サプライヤーの端末が、
前記請求書データに基づいて仕訳作成処理を実行して、当該サプライヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、売掛金情報を生成して前記コンピュータに送信する処理を実行し、
前記バイヤーの端末が、
前記請求書データに基づいて仕訳作成処理を実行して、当該バイヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、買掛金情報を生成して前記コンピュータに送信する処理を実行し、
前記コンピュータが、
前記バイヤーの端末からの決済処理の依頼に基づいて前記買掛金情報の消込処理を実行し、当該買掛金情報消込処理の結果を前記バイヤーの端末に送信し、前記バイヤーの利用銀行のシステムである銀行システムから受信する入金通知に基づいて前記売掛金情報の消込処理を実行し、当該売掛金情報消込処理の結果を前記サプライヤーの端末に送信する処理を実行し、
前記サプライヤーの端末が、
受信した前記売掛金消込処理の結果に基づいて、前記売掛金情報に関する仕訳作成処理を実行し、前記サプライヤーでの総勘定元帳を更新する処理を実行し、
前記バイヤーの端末が、
受信した前記買掛金消込処理の結果に基づいて、前記買掛金情報に関する仕訳作成処理を実行し、前記バイヤーでの総勘定元帳を更新する処理を実行する、ことを特徴とする。

また、本発明の決済業務支援システムは、
電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理と、
前記バイヤーの端末が、前記請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して生成した、前記サプライヤー宛の支払予定データを受信する処理と、
前記受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データにマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理と、前記バイヤーの端末からの決済処理の依頼に基づいて前記買掛金情報の消込処理を実行し、当該買掛金情報消込処理の結果を前記バイヤーの端末に送信し、前記バイヤーの利用銀行のシステムである銀行システムから受信する入金通知に基づいて前記売掛金情報の消込処理を実行し、当該売掛金情報消込処理の結果を前記サプライヤーの端末に送信する処理とを実行する演算装置を備え、企業間の電子商取引を仲介するコンピュータと、
前記バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理と、前記請求書データに基づいて仕訳作成処理を実行して、当該バイヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、買掛金情報を生成して前記コンピュータに送信する処理と、受信した前記買掛金消込処理の結果に基づいて、前記買掛金情報に関する仕訳作成処理を実行し、前記バイヤーでの総勘定元帳を更新する処理とを実行する演算装置を備えた、バイヤーの端末と、
電子商取引におけるバイヤーに宛てた請求書データを、前記コンピュータに送信する処理と、前記請求書データに基づいて仕訳作成処理を実行して、当該サプライヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、売掛金情報を生成して前記コンピュータに送信する処理と、受信した前記売掛金消込処理の結果に基づいて、前記売掛金情報に関する仕訳作成処理を実行し、前記サプライヤーでの総勘定元帳を更新する処理とを実行する演算装置を備えたサプライヤーの端末と、を備えることを特徴とする。

本発明によれば、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減が可能となる。

本実施形態の決済業務支援システムを含むネットワーク構成例を示す図である。 本実施形態のプラットフォームサーバの構成例を示す図である。 本実施形態のサプライヤー端末の構成例を示す図である。 本実施形態のバイヤー端末の構成例を示す図である。 本実施形態の決済業務支援方法の処理手順例１を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例２を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例３を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例４を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例５を示すデータフロー図である。 本実施形態の決済業務支援方法の処理手順例６を示すデータフロー図である。 本実施形態におけるバイラテラル・ネッティング前後の支払予定データの具体的変遷例を示す図である。 本実施形態におけるマルチラテラル・ネッティング前後の支払予定データの具体的変遷例を示す図である。 本実施形態におけるマルチラテラル・ネッティング前の債権・債務関係の具体例を示す図である。 本実施形態におけるマルチラテラル・ネッティング後の債権・債務関係の具体例を示す図である。 本実施形態におけるインボイスデータの具体例を示す図である。 本実施形態における支払予定データの具体例を示す図である。 本実施形態における集約後支払予定データの具体例を示す図である。 本実施形態におけるバイヤー口座情報の具体例を示す図である。 本実施形態におけるステータス値リストの具体例を示す図である。 本実施形態における支払通知の具体例を示す図である。 本実施形態における買掛金情報の具体例を示す図である。 本実施形態における入金予定情報の具体例を示す図である。 本実施形態における売掛金情報の具体例１を示す図である。 本実施形態における売掛金消込予定情報の具体例を示す図である。 本実施形態における入金情報の具体例を示す図である。 本実施形態における売掛金情報の具体例２を示す図である。 本実施形態における入金過不足情報の具体例を示す図である。 本実施形態における出力画面例１を示す図である。 本実施形態における出力画面例２を示す図である。 本実施形態における出力画面例３を示す図である。 本実施形態における出力画面例４を示す図である。 本実施形態における出力画面例５を示す図である。 本実施形態における出力画面例６を示す図である。

以下に本発明の実施形態について図面を用いて詳細に説明する。図１は本実施形態の決済業務支援システムを含むネットワーク構成例を示す図である。図１に示す決済業務支援システム１０は、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減を可能とするためのコンピュータシステムである。この決済業務支援システム１０は、企業間の電子商取引を仲介するコンピュータであり、ＢｔｏＢプラットフォームを提供するプラットフォームサーバ１００、このプラットフォームサーバ１００にアクセスしてプラットフォームサービスを利用するサプライヤー端末２００およびバイヤー端末３００を含んでいる。これら、プラットフォームサーバ１００、サプライヤー端末２００、バイヤー端末３００は、ネットワーク１２０を介して通信可能に結ばれている。

なお、上述のサプライヤー端末２００は、電子商取引において、商品を他社に販売するサプライヤー企業が利用する端末である。また、バイヤー端末３００は、電子商取引において、商品を他社から購入するバイヤー企業が利用する端末である。

また、上述のネットワーク１２０には、電子商取引に伴い決済に利用される銀行システム４００も接続されている。プラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らは、ネットワーク１２０を介して、口座開設している取引銀行の銀行システム４００に認証等を経てアクセスし、必要な情報や処理をリクエストすることが出来る。

また、決済業務支援システム１０を構成する各情報処理装置のハードウェア構成は以下の如くとなる。図２は、本実施形態のプラットフォームサーバ１００の構成例を示す図である。決済業務支援システム１０を構成するコンピュータたる、プラットフォームサーバ１００は、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置１０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワークと接続し他装置との通信処理を担う通信装置１０５を備える。なお、記憶装置１０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム１０２と、各種処理に必要なデータ類１１０が記憶されている。このデータ類１１０には、後述するインボイスデータ１２５や、このインボイスデータ１２５やその他の情報から生成した各種のデータが含まれる。こうした考えかたは、サプライヤー端末２００やバイヤー端末３００に関しても同様とする。

なお、図３にて示すように、上述のサプライヤー端末２００は、コンピュータとして一般的なハードウェア構成を備えており、プラットフォームサーバ１００と同様に、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置２０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ネットワークと接続し他装置との通信処理を担う通信装置２０５、ユーザたるサプライヤー企業の担当者からの入力を受け付けるキーボード、マウスといった入力装置２０６、および、処理結果を出力するディスプレイやスピーカー等の出力装置２０７を備える。記憶装置２０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム２０２と、各種処理に必要なデータ類２１０が記憶されている。

また、図４にて示すように、バイヤー端末３００も上述のサプライヤー端末２００と同様のハードウェア構成を備えており、ハードディスクドライブなど適宜な不揮発性記憶装置で構成される記憶装置３０１、ＲＡＭなど揮発性記憶装置で構成されるメモリ３０３、記憶装置３０１に保持されるプログラム３０２をメモリ３０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置３０４、ネットワークと接続し他装置との通信処理を担う通信装置３０５、ユーザたるバイヤー企業の担当者からの入力を受け付けるキーボード、マウスといった入力装置３０６、および、処理結果を出力するディスプレイやスピーカー等の出力装置３０７を備える。記憶装置３０１内には、本実施形態の決済業務支援システム１０を構成する情報処理装置として必要な機能を実装する為のプログラム３０２と、各種処理に必要なデータ類３１０が記憶されている。

続いて、本実施形態の決済業務支援システム１０を構成する各情報処理装置、すなわち、プラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らがそれぞれ備える機能について説明する。上述したように、以下に説明する機能は、例えば決済業務支援システム１０を構成する、プラットフォームサーバ１００、サプライヤー端末２００、バイヤー端末３００らが備えるプログラムをそれぞれ実行することで実装される機能と言える。

プラットフォームサーバ１００は、電子商取引におけるサプライヤーの端末、すなわちサプライヤー端末２００より、バイヤーに宛てた請求書データを受信して記憶装置１０１に格納し、バイヤーの端末、すなわちバイヤー端末３００からの取得要求に応じて請求書データを記憶装置１０１から読み出してバイヤー端末３００に送信する機能を有する。

一方、バイヤー端末３００は、当該バイヤー宛ての請求書データの取得要求をプラットフォームサーバ１００に送り、このプラットフォームサーバ１００から該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置３０１からバイヤーが指定した決済用の情報を付与して、サプライヤー宛の支払予定データを生成し、プラットフォームサーバ１００に送信する機能を有する。

他方、プラットフォームサーバ１００は、上述のバイヤー端末３００から受信した支払予定データのうち、予め定めた所定項目ないしバイヤー端末３００から指定を受けた所定項目が共通する支払予定データを特定し、ここで特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置１０１に格納する機能を有する。

こうした機能を備える決済業務支援システム１０は、サプライヤー側から得られる請求書データ（電子データ）に基づいて、バイヤー側で利用価値のある支払予定データを自動生成し、更に、入金先の銀行口座が同一であるなど、互いに支払金額を合算出来る支払予定についてはマージしてデータを集約し、以降に行われる予定の実際の決済処理（サプライヤー指定の銀行口座への振り込み処理）の件数を低減出来る。決済時の処理件数が低減出来ることで、処理効率が向上して、作業の手間や時間は勿論、決済コストも低減出来る。

なお、上述のバイヤー端末３００は、プラットフォームサーバ１００から受信した請求書データを出力装置３０７に表示させる機能を有している。

また、このバイヤー端末３００は、出力装置３０７に表示した請求書データが示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置３０６で受け付ける機能を有している。

この場合、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、上述の請求書データに基づく買掛金の情報の生成と、この買掛金の情報のプラットフォームサーバ１００への送信とを実行する機能を有している。また、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報をプラットフォームサーバ１００に送信する機能を有している。

このように、実際の紙媒体の請求書と請求書データ（電子データ）との照合結果を、その後の処理に反映させることで、請求書データのデータ品質や、請求書データを用いたその後の処理の正確性を良好に維持できる。

一方、プラットフォームサーバ１００は、上述の差異の情報をバイヤー端末３００から受信して、当該差異の情報を記憶装置１０１に格納し、サプライヤー端末２００に対し、上述の差異に関する確認要求を送信する機能を有している。なお、上述した紙媒体の請求書としては、例えば、中国で利用されているファーピャオが一例となる。ファーピャオ（発票）は、中国における請求書（Invoice）ないし領収書であり、税務機関が発行した法定の発票用紙が利用されている。

また、プラットフォームサーバ１００は、バイヤー端末３００より支払依頼を受信した場合、該当バイヤーに関する集約後支払予定データを記憶装置１０１より読み出し、当該集約後支払予定データが示す、バイヤーの利用銀行の銀行システム４００に対し、集約後支払予定データが示す内容に応じた決済処理の依頼を送信する機能を有している。

また、プラットフォームサーバ１００は、決済処理の依頼をバイヤーの利用銀行の銀行システム４００に送信する処理に伴い、決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤー端末２００に宛てて送信する機能を有している。

こうした機能を備える決済業務支援システム１０は、予め集約されている支払予定データに基づいた決済処理の依頼を銀行システム４００に送信することが可能となり、振込件数の低減や、それに伴う振込コスト低減も可能となる。また、上述の支払通知がなされることで、サプライヤー側では、バイヤー側での支払行為が済んだことを、銀行システム４００からの通知前に感知できる。また、決済業務支援システム１０におけるプラットフォームサーバ１００と、銀行システム４００との連携が図られる効果もある。

また、バイヤー端末３００は、支払依頼をプラットフォームサーバ１００に送信するに伴い、プラットフォームサーバ１００より集約後支払予定データを取得して出力装置３０７に表示させる機能を有している。この場合、バイヤー端末３００は、集約後支払予定データが示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、支払依頼の可否について判断した結果を、入力装置３０６で受け付ける機能を有している。

また、この場合、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、支払依頼を承認するものであった場合、支払依頼のプラットフォームサーバ１００への送信を実行する機能を有している。また、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、支払依頼を否認するものであった場合、支払依頼のプラットフォームサーバ１００への送信を実行せず、当該否認の旨を、予め定めたバイヤー企業内の管理者端末など所定の端末に送信する機能を有している。

決済業務支援システム１０が、このような機能を備えることで、紙媒体の請求書と集約後支払予定データとの照合結果をその後の処理に反映させ、支払依頼の正確性や、その後の処理の正確性を良好に維持できる。

また、プラットフォームサーバ１００は、バイヤー端末３００より、請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置１０１に格納する機能を有している。この場合、プラットフォームサーバ１００は、上述の決済処理の依頼を、バイヤーの利用銀行の銀行システム４００に送信する処理に伴い、決済処理の依頼が含む、請求書データの識別情報と対応する買掛金の情報を記憶装置１０１にて特定し、該当買掛金の情報に関する消込処理を実行する機能を有している。決済業務支援システム１０が、このような機能を備えることで、買掛金の消込処理が自動的に実行され、業務効率を向上させることができる。

また、プラットフォームサーバ１００は、上述の支払通知の生成ないしサプライヤー端末２００からの指示に応じて、決済処理の依頼ないし支払通知が含む、サプライヤーへの支払内容の情報により、サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、これを記憶装置１０１に格納する機能を有している。

この場合、プラットフォームサーバ１００は、サプライヤー端末２００より、請求書データに基づいた売掛金の情報を受信し記憶装置１０１に格納する機能を有している。また、プラットフォームサーバ１００は、上述の入金予定の情報と売掛金の情報とをマッチングし、入金予定の情報が含む、請求書データの識別情報と対応する売掛金の情報を記憶装置１０１にて特定し、該当売掛金の消込予定の情報を生成する機能を有している。

決済業務支援システム１０が、このような機能を備えることで、売掛金の消込予定の情報を自動生成することが可能となり、後に実際の入金が確認された際の売掛金の消込処理の効率を良好なものとできる。

また、プラットフォームサーバ１００は、上述のサプライヤーの口座への入金事実について、サプライヤーの利用銀行の銀行システム４００より通知を受信し、当該通知が示す入金内容と、上述の売掛金の消込予定の情報とをマッチングし、上述の入金内容と対応する売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する機能を有している。

この場合、プラットフォームサーバ１００は、上述の判定の結果、入金額の過不足が無かった場合、上記で特定した売掛金の消込処理を実行し、一方、上述の判定の結果、入金額の過不足があった場合、過不足額の情報をサプライヤー端末２００およびバイヤー端末３００に送信する機能を有している。なお、入金の過不足があった場合でも、売掛金の消込処理を行ってもよい。この場合、不足の場合は入金分のみの消し込みになる。また、過不足額の情報の送信と消し込みの両方を行ってもよい。

決済業務支援システム１０が、このような機能を備えることで、決済業務支援システム１０におけるプラットフォームサーバ１００と銀行システム４００との連携が図られる上、売掛金の消込業務を効率的なものと出来る。また、バイヤーからの入金額に過不足が生じてしまっている状況にも対応できる。

また、こうした入金額の過不足の発生原因として、例えば、サプライヤーとバイヤーとで取り決めた支払条件が遵守されずに一部入金のみされた状況が想定される。そうした状況であっても、本実施形態の決済業務支援システム１０であれば、入金額の過不足が生じている請求書データや売掛金の情報を特定し、その内容を追跡することもできる。当然、入金額の過不足発生時におけるエビデンスの確認などの事務が省力化され、事務処理ミスや不正を防ぐことができる。

また、プラットフォームサーバ１００は、１組以上のサプライヤーとバイヤーのそれぞれについて、上述の集約後支払予定データを記憶装置１０１から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行の銀行システム４００に対し、上述した残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する機能を有している。

決済業務支援システム１０が、このような機能を備えることで、電子商取引の参加者が保有する債権(売掛金)と債務(買掛金)に紐付く送金取引を相殺し、例えば、ある一定の期日に差額分だけを決済することが可能となる。そのため、取引のたびに決済を行う場合に比べ、銀行手数料や事務処理の手間を削減できる。

以下、本実施形態における決済業務支援方法の実際手順について図に基づき説明する。以下で説明する決済業務支援方法に対応する各種動作は、決済業務支援システム１０を構成する、上述のプラットフォームサーバ１００、サプライヤー端末２００、およびバイヤー端末３００らがそれぞれメモリ等に読み出して実行するプログラムによって実現される。また、処理の一部には、決済業務支援システム１０と銀行システム４００とのやりとりも含まれている。そして、これらのプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図５は、本実施形態における決済業務支援方法の処理手順例１を示すデータフロー図である。ここでまず、サプライヤー端末２００が、サプライヤー企業における販売部門の担当者が入力した請求書データたるインボイスデータを、プラットフォームサーバ１００に送信する（ｓ１００）。この時、プラットフォームサーバ１００では、サプライヤー端末２００から送信されてきたインボイスデータ１２５を受信し、これを記憶装置１０１における共有データフォルダに格納する。

一方、上述のインボイスデータ１２５の宛先となる、バイヤーの購買部門におけるバイヤー端末３００は、プラットフォームサーバ１００に対して、インボイス照会指示を出して（ｓ１０１）、プラットフォームサーバ１００よりインボイスデータ１２５を取得する（ｓ１０２）。この時、バイヤー端末３００は、プラットフォームサーバ１００より取得したインボイスデータ１２５を自身の記憶装置３０１に格納する。

図１２にインボイスデータ１２５の例を示す。このインボイスデータ１２５は、請求書情報をキーとして、商品情報、金額情報、およびサプライヤー情報が紐付けされたレコードの集合体となっている。このうち、請求書情報は、該当インボイスを一意に識別するための番号と、該当インボイスの発行日からなっている。また、商品情報は、代金請求の対象となる商品の識別情報である商品番号、および商品名の各情報からなっている。また、金額情報は、前述の商品情報が含む各商品に関する、数量、単価、金額（数量×単価の値）、税率、合計の各値の情報からなっている。また、サプライヤー情報は、商品販売者たるサプライヤー企業の企業名、その納税人番号、および、前述の商品情報が含む各商品の代金入金先となる銀行口座情報からなっている。

また、バイヤー端末３００は、記憶装置３０１に格納したインボイスデータ１２５に、予め定めた決済用の情報、ないし入力装置３０１からバイヤー企業の所定担当者が指定した決済用の情報を付与して、サプライヤー宛の支払予定データ１２６を生成し、プラットフォームサーバ１００に送信する（ｓ１０３）。なお、インボイスデータ１２５に付与する、上述の決済用の情報は、例えば、インボイスデータ１２５が含んでいた、インボイス支払期日の情報や、バイヤーが決定する支払予定日の情報、決済資金の振り込みにバイヤー企業が使用している銀行口座の情報である支払口座情報、などを想定できる。なお、支払予定日に関しては、インボイス発行日の値から一定日数を減算して算出してもよい。

図１２Ａに支払予定データ１２６の例を示す。この支払予定データ１２６は、支払予定情報、請求書情報、商品情報、金額情報、支払予定額、入金口座情報、および支払口座情報が互いに紐付けされたレコードの集合体となっている。これらの情報のうち、上述したインボイスデータ１２５と異なる情報は、支払予定情報、支払予定金額、および支払口座情報の各情報となる。

支払予定情報は、インボイスデータ１２５が含んでいた、支払期日の情報、インボイスデータ１２５が含んでいたバイヤーが決定する支払予定日の情報、および、ステータスの各情報となる。なお、支払予定日に関しては、インボイス発行日の値から一定日数を減算して算出してもよい。このステータスの情報は、当該支払予定データ１２６における該当レコードについてなされた処理の段階を示すものとなる。図１２Ａに示す例では、インボイスデータ１２５（における該当レコード）が示す内容と、バイヤーが所持している紙媒体の請求書が示す内容とをバイヤーが照合（リコンサイル）したか否かを示す値が設定されている。ステータスの値のリスト１３２Ａについては、図１３Ｂに例示する。以降、各処理に伴ってステータスの値が更新される場合、この図１３Ｂに示すリスト１３２Ａに基づいて、プラットフォームサーバ１００が更新を実行するものとする。

また、支払予定金額は、当該支払予定データ１２６における該当レコードに関し、バイヤーがサプライヤー宛てに入金予定である金額の値が設定されている。通常は、金額情報における合計の値と同額となる。ただし、預金残高不足、契約内容変更等の状況を踏まえたバイヤー側の判断で、金額情報における合計の値と同額でない値が設定される場合もありうる。これらの値は、バイヤー企業における所定の担当者が、バイヤー端末３００の入力装置３０６にて入力することとなる。

また、支払口座情報は、決済資金の振り込みにバイヤー企業が使用している銀行口座の情報であり、バイヤー企業の企業名、商品代金の出金元となる銀行口座情報からなっている。

なお、上述のインボイスデータ１２５に含まれる一部の情報が記載された紙媒体の請求書が、電子データのインボイスデータ１２５とは別に、サプライヤー企業からバイヤー企業に宛てて郵送されている。この紙媒体の請求書としては、例えば、中国で利用されているファーピャオが一例となる。図５以降の各図においても、「ファーピャオ」と記している。ファーピャオ（発票）は、中国における請求書（Invoice）ないし領収書であり、税務機関が発行した法定の発票用紙が利用されている。バイヤー企業では、サプライヤー企業からこのファーピャオを受領し、保管しているものとする。

一方、サプライヤー端末２００においては、インボイスデータ１２５やファーピャオなどに基づいて通常の仕訳作成処理（ｓ１０４）が実行され、それにより生成した売掛金情報１２７をプラットフォームサーバ１００にアップロードする。また、仕訳作成処理（ｓ１０４）に伴って総勘定元帳１２８（図中では“ＧＬ”と記す）の生成も通常通り行われ、この総勘定元帳１２８はサプライヤー端末２００の記憶装置２０１に保持される。

他方、プラットフォームサーバ１００は、サプライヤー端末２００より売掛金情報１２７を受信し、これを記憶装置１０１に格納する。売掛金情報１２７の例は図１５Ａに示す。売掛金情報１２７は、記帳日、販売先企業を示す売掛先、販売した商品の商品番号や商品名を示す商品情報、その金額情報、インボイスデータ１２５の識別情報や発行日を示す請求書情報、回収予定情報といったデータを含んでいる。回収予定情報は、該当売掛金の回収日、とその回収状況を示すステータスの各情報を含む。

なお、上述のファーピャオの郵送に伴い、バイヤー企業の所定の担当者が、取引の正確性を維持するためにも、このファーピャオと、上述したインボイスデータ１２５との整合性について照合する必要がある。そこで、バイヤー端末３００は、プラットフォームサーバ１００から受信したインボイスデータ１２５を出力装置３０７に表示させ、上述の担当者による照合に供するものとする。

この担当者は、紙媒体のファーピャオの記載内容と、出力装置３０７に表示されたインボイスデータ１２５とを見比べ、対応項目の各値が互いに一致するか照合作業（リコンサイル）を行う。

この時、バイヤー端末３００は、こうして、出力装置３０７に表示したインボイスデータ１２５が示す内容と、紙媒体のファーピャオが示す内容とをバイヤーが照合した結果を、入力装置３０６で受け付ける（ｓ１０５）。リコンサイル画面の例としては、図１７、図１７Ａにて示すとおりである。図１７には、処理対象となるインボイスデータ１２５のリストが表示され、図１７Ａには、そのうちの１つのインボイスデータ１２５の詳細情報が表示されている。

バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、インボイスデータ１２５の内容と紙媒体のファーピャオの内容とに差異が無いことを示す場合（ｓ１０６：Ｙ）、上述のインボイスデータ１２５に基づく仕訳作成（ｓ１０９）および買掛金情報１３０（図１４Ａ参照）の生成と、この買掛金情報１３０のプラットフォームサーバ１００への送信とを実行する。また、バイヤー端末３００は、この処理に伴って、支払予定データ１２６において、該当レコードのステータスを「リコンサイル済」と更新する。なお、上述のステップｓ１０９で仕訳作成を行うことで、通常の総勘定元帳１３１（図中では、“ＧＬ”と記す）が生成される。

なお、上述の買掛金情報１３０は、図１４Ａに例示するように、記帳日、購入先企業を示す仕入れ先、購入した商品の商品番号や商品名を示す商品情報、その金額情報、インボイスデータ１２５の識別情報を示す請求書情報、および、買掛に対する支払状況を示す消込区分、といったデータを含んでいる。図１４Ａの例では、「消込区分」の値が、「全部支払済」、または「一部支払済」となっている。買掛金情報１３０は、インボイスデータ１２５に基づいて作成されているため、消込有無を示す「消込区分」の値の他は、インボイスデータ１２５と同様の構成となる。

一方、バイヤー端末３００は、入力装置３０６で受け付けた上述の結果が、インボイスデータ１２５の内容と紙媒体のファーピャオの内容とに差異があることを示す場合（ｓ１０６：Ｎ）、その差異の情報、すなわち差分情報１２９を、プラットフォームサーバ１００に送信する（ｓ１０７）。上述の差分情報１２９は、例えば、上述の差異が生じている項目名と、該当項目に関する、インボイスデータ１２５と紙媒体のファーピャオでの各値とが含まれたデータとなる。

他方、プラットフォームサーバ１００は、上述の差分情報１２９をバイヤー端末３００から受信して記憶装置１０１に格納する。また、プラットフォームサーバ１００は、サプライヤー端末２００に対し、この差分情報１２９に関する確認要求を送信する（ｓ１０８）。サプライヤー側では、この差分情報１２９をサプライヤー端末２００にて確認し、所定の担当者が、ファーピャオの修正と再発行、或いはインボイスデータ１２５の修正と再度のアップロードといった以後の対応を決め、必要な措置をとることとなる。

続いて、上述した支払予定データ１２６の集約処理について図に基づき説明する。図６は、本実施形態における決済業務支援方法の処理手順例２を示すデータフロー図である。この場合、プラットフォームサーバ１００は、図６に示すように、例えばインボイス発行日の夜間まで、サプライヤー端末２００から受信した最新の各インボイスデータ１２５について、上述した支払予定データ１２６に関する処理を繰り返し、記憶装置１０１に複数の支払予定データ１２６のレコードを蓄積しているものとする（ｓ１２０）。

ここでプラットフォームサーバ１００は、例えば、記憶装置１０１に一定数以上の支払予定データ１２６のレコードが蓄積されたことを検知するなどし、支払予定集約提案をバイヤー端末３００に通知する（ｓ１２１）。この時、バイヤー端末３００では、この通知を受けて、支払予定データ１２６の集約指示をプラットフォームサーバ１００に返す（ｓ１２２）。この集約指示は、バイヤー企業における所定の担当者がバイヤー端末３００の入力装置３０６にて入力し、これを受けたバイヤー端末３００がプラットフォームサーバ１００に送信するものとしてもよい。

プラットフォームサーバ１００は、バイヤー端末３００より上述の支払予定情報の集約指示を受信した場合、該当バイヤーに関する支払予定データ１２６を、上述の「支払口座情報」が示す「企業名」の値等に基づいて記憶装置１０１より読み出し、読み出した支払予定データ１２６のうち、予め定めた所定項目ないしバイヤー端末３００から指定を受けた所定項目が共通する支払予定データ１２６を特定し、ここで特定した各支払予定データ１２６における支払金額を合算して該当支払予定データ１２６らマージし、当該マージ後の支払予定データを集約後支払予定データ１３２として記憶装置１０１に格納する（ｓ１２３）。

集約対象となる支払予定データ１２６を特定する際に利用する、上述の所定項目としては、例えば、「支払予定情報」における「支払期日」、「支払予定情報」における「支払予定日」、「請求書情報」における「番号」、「入金口座情報」における「企業名」と「銀行」、「支店」、「口座番号」、といったものがあげられる。

こうした所定項目が、「銀行」：あ銀行、かつ「口座番号」：６６６６６６６６、および、「銀行」：い銀行、かつ「口座番号」：６６６６６６６７、であったとする。その場合、プラットフォームサーバ１００は、図１２Ａに例示した支払予定データ１２６のうち、上から２つのレコード同士、および下から２つのレコード同士をそれぞれ集約対象として特定することとなる。また、各レコード同士において、「支払予定情報」の「予定金額」を合算し、集約後支払予定データ１３２における「金額情報」の「金額」値を算定する。図１３に集約後支払予定データ１３２の例を示す。ここで例示した集約後支払予定データ１３２は、上述したように、支払予定データ１２６における４レコードを２レコードずつ集約したものであるから、２レコードを有している。

また、プラットフォームサーバ１００は、バイヤー端末３００に対し、上述の如く生成した集約後支払予定データ１３２の照会通知を送る。バイヤー端末３００ではこの通知を受けて、集約後支払予定データ１３２をプラットフォームサーバ１００より得て出力装置３０７に表示し（ｓ１２４）、所定担当者による、支払口座の選択指示を入力装置３０６にて受け付ける（ｓ１２５）。

この時、バイヤー端末３００は、プラットフォームサーバ１００からバイヤー口座情報１３３（図１３Ａ参照）を読み出して、支払口座の選択用リストとして出力装置３０７にて表示することとなる。また、上述の担当者は、支払口座選択に伴って、該当銀行が提供する種々の振込方式中より所望の送金方式（例：個別振込、総合振込）を選択する。

バイヤー端末３００は、その選択事項を入力装置３０６で受け（ｓ１２６）、この選択事項と、上述のステップｓ１２５で得ている支払口座の選択事項とを含む支払予定申請をプラットフォームサーバ１００に通知する（ｓ１２７）。

プラットフォームサーバ１００では、バイヤー端末３００から、支払予定申請を受信し、当該申請が含む送金方式の値として、例えば「総振」（総合振込形式）の値を取得し、この値を、上述の集約後支払予定データ１３２の該当欄「総振」にて設定する。図３の例では、「総振」欄にて設定されるのは、該当銀行との総合振込形式の契約有無の値となる。また、プラットフォームサーバ１００は、上述の支払予定申請が含む支払口座の選択事項の値を、集約後支払予定データ１３２における該当欄「支払口座情報」に設定する。

次に、バイヤー側で実際に支払を行う日、集約後支払予定データ１３２における「支払予定日」が到来した場合の処理について図に基づき説明する。図７は、本実施形態における決済業務支援方法の処理手順例３を示すデータフロー図である。

この場合、例えば、プラットフォームサーバ１００が集約後支払予定データ１３２における「支払予定日」の到来を、自身の備えるカレンダー機能にて検知し、その旨をバイヤー端末３００に通知するとする（ｓ１２９）。バイヤー端末３００では、この通知を受けて、支払依頼の申請をプラットフォームサーバ１００に送信する（ｓ１３０）。勿論、バイヤー企業における所定の担当者が、バイヤー端末３００の入力装置３０６にて上述の支払依頼の申請データを入力し、バイヤー端末３００がプラットフォームサーバ１００に送信するとしてもよい。

一方、プラットフォームサーバ１００は、バイヤー端末３００より上述の支払依頼の申請を受信し（ｓ１３１）、該当バイヤー（例：企業名ＡＢ）に関する集約後支払予定データ１３２（例：「支払口座情報」欄の「企業名」の値が、“企業名ＡＢ”）を記憶装置１０１より読み出し、バイヤー端末３００に送る。

バイヤー端末３００は、プラットフォームサーバ１００より集約後支払予定データ１３２を取得して出力装置３０７に表示させる（図１８、図１８Ａ）。この場合、バイヤー端末３００は、集約後支払予定データ１３２が示す内容と、サプライヤーからバイヤー宛てに送付されていた紙媒体の請求書すなわちファーピャオが示す内容とをバイヤーが照合して、支払依頼の可否について判断した結果を、入力装置３０６で受け付ける（ｓ１３２）。こうした支払依頼の可否判断は、バイヤー企業における経理部門の担当者が実行することになる。

バイヤー端末３００は、入力装置３０６で受け付けた上述の可否判断の結果が、支払依頼を承認しないものであった場合（ｓ１３３：Ｎ）、支払依頼の否認通知をプラットフォームサーバ１００へ送信し、当該否認の旨を、バイヤー企業における購買部門のバイヤー端末３００など所定の端末に送信する（ｓ１３５）。

他方、バイヤー端末３００は、入力装置３０６で受け付けた上述の可否判断の結果が、支払依頼を承認するものであった場合（ｓ１３３：Ｙ）、該当集約後支払予定データ１３２における「支払口座情報」が示す銀行（例：う銀行）の銀行システム４００に対し、所定のログイン認証処理を経て、該当口座（例：上海支店、口座番号３３３３３３３）の残高照会を行う（ｓ１３６）。

銀行システム４００では、この残高照会を受けて（ｓ１３７）、該当口座の口座残高の値をバイヤー端末３００に返す（ｓ１３８）。バイヤー端末３００は、この口座残高の値が、上述の集約後支払予定データ１３２における「予定金額」の値を満たすか判定する（ｓ１３９）。バイヤー端末３００は、必要な残高があると判断した場合（ｓ１３９：Ｙ）、上述の支払依頼に関して承認登録指示をプラットフォームサーバ１００に送信する（ｓ１４１）。他方、バイヤー端末３００は、口座残高の値が「予定金額」に不足しており、必要な残高が無いと判断した場合（ｓ１３９：Ｎ）、例えば、バイヤー企業が保有する他の銀行口座から該当口座へ、上述の不足分の金額の入金処理を実行し（ｓ１４０）、処理を上述のステップｓ１３９に戻す。

一方、ステップｓ１４１にてバイヤー端末３００から承認登録指示が送信されたプラットフォームサーバ１００では、これを受けて、該当集約後支払予定データ１３２が示す、該当バイヤーの利用銀行（例：う銀行）の銀行システム４００に対し、集約後支払予定データ１３２における「支払口座情報」が示す口座から、「入金口座情報」が示す銀行口座への、「金額情報」が示す金額に応じた、決済処理の依頼を送信する（ｓ１４２）。銀行システム４００では、この決済処理の依頼を受け付けて（ｓ１４３）、バイヤー企業の口座からサプライヤー企業の口座への振込処理を行うなどして、所定の決済処理を実行する。

また、プラットフォームサーバ１００は、決済処理の依頼を銀行システム４００に送信する処理に伴い、決済処理の依頼が含む、集約後支払予定データ１３２における「請求書情報」の「番号」と対応する買掛金情報１３０（図１４Ａ参照）を、記憶装置１０１にて特定し、該当買掛金情報に関する消込処理を実行する（ｓ１４４）。図１４Ａの例においては、買掛金情報１３０における「消込区分」の値が、「全部支払済」、または「一部支払済」となっている。買掛金情報１３０は、インボイスデータ１２５に基づいて作成されているため、消込有無を示す「消込区分」の値の他は、インボイスデータ１２５と同様の構成となる。

なお、プラットフォームサーバ１００は、この買掛金情報１３０に関する消込処理の結果を、バイヤー端末３００に通知する。バイヤー端末３００では、この通知を受けて、消し込まれた買掛金情報に応じて仕訳作成処理を実行し（ｓ１４５）、総勘定元帳１３１を更新することになる。バイヤー企業における経理部門の担当者は、バイヤー端末３００を用いて、この総勘定元帳１３１の照会を行える。

また、プラットフォームサーバ１００は、買掛金情報の消込処理を実行後、決済処理の依頼がなされた該当インボイスデータ１２５（のレコード）に関する支払通知１３４（図１４参照）を生成して（ｓ１４７）、該当サプライヤー端末２００に宛てて送信する。支払通知１３４は、決済処理の依頼がなされた該当インボイスデータ１２５（のレコード）とデータ構成は同様である。但し、図１４の例では、支払通知１３４における「ステータス」の値は、サプライヤーから請求された金額に対してバイヤーの決済した額が一致する場合の「全部支払済」、または、サプライヤーから請求された金額に対してバイヤーの決済した額が不足する場合の「一部支払済」となっている。

次に、売掛金情報の消込処理について図に基づき説明する。図８は、本実施形態における決済業務支援方法の処理手順例４を示すデータフロー図であり、図９は、本実施形態における決済業務支援方法の処理手順例５を示すデータフロー図である。この場合、プラットフォームサーバ１００は、上述の支払通知１３４の生成を契機に、或いは、サプライヤー端末２００からの支払通知の照会や作成指示（ｓ１５０，ｓ１５１）に応じて、入金予定情報１３５の生成を実行し（ｓ１５２）、これを記憶装置１０１に格納する。

この入金予定情報１３５は、上述の決済処理の依頼ないし支払通知１３４が含む、サプライヤーへの支払内容の情報に基づいて生成するものであり、図１５に示すように、バイヤー端末３００から決済依頼を受けて支払通知を作成した日である支払通知受領日、バイヤー企業から入金がなされたサプライヤー企業の口座を示す入金口座情報、支払がなされた金額を示す金額情報、対応するインボイスデータ１２５の番号とその発行日を示す請求書情報、支払対象の商品の商品番号と商品名を示す商品情報、支払期日と実際の支払日と支払ステータスを示す支払情報、およびバイヤー企業が支払に用いた口座を示す支払口座情報の各データからなっている。図１５に示す例の場合、入金予定情報１３５における「ステータス」が、「支払未済」となっている。現時点では、入金の予定であって、プラットフォームサーバ１００が実際に銀行システム４００から入金通知を受信していない状態のためである。

また、プラットフォームサーバ１００は、入金予定情報１３５の生成の旨を、サプライヤー端末２００に通知する。これを受けたサプライヤー端末２００は、入金予定情報１３５をプラットフォームサーバ１００より取得し（ｓ１５３）、これを閲覧した経理部門の担当者からの指示を入力装置２０６にて受け付ける。この指示は、売掛金の消込予定の作成指示となる。この作成指示はサプライヤー端末２００からプラットフォームサーバ１００に送信される（ｓ１５４）。

この場合、プラットフォームサーバ１００は、サプライヤー端末２００より上述の作成指示を受けて、記憶装置１０１に格納している入金予定情報１３５および売掛金情報１２７（図１５Ａ参照）を読み出し、更に、入金予定情報１３５が含む、インボイスデータ１２５の識別情報すなわち「請求書情報」における「番号」の値と対応する、売掛金情報１２７（のレコード）を記憶装置１０１にて特定（マッチング）する（ｓ１５５）。なお、売掛金情報１２７は、インボイスデータ１２５から生成されるもので、既に述べたように、記帳日、売掛先、商品情報、金額情報、請求書情報、回収予定情報といったデータを含んでいる。回収予定情報は、該当売掛金の回収日、とその回収状況を示すステータスの各情報を含む。

この時、プラットフォームサーバ１００は、上述のステップｓ１５５で特定した、該当売掛金の消込予定の情報１３６（図１５Ｂ参照）を生成する。売掛金消込予定情報１３６は、上述した売掛金情報１２７とほぼ同様のデータ構成となっており、入金予定日、売掛先、請求書情報、商品情報、金額情報、および回収予定情報から構成されている。なお、サプライヤー端末２００では、上述の売掛金消込予定情報１３６を取得して出力装置２０７に図１９、図１９Ａのごとく表示し（ｓ１５６）、サプライヤー企業における経理部門の担当者の閲覧に供する。

上述のごとく、バイヤー企業からサプライヤー企業に対する支払行為が実行された後、実際に、「支払口座情報」で指定されたバイヤーの銀行口座から、「入金口座情報」で指定されたサプライヤーの銀行口座への振込が実行された際の処理について、続いて説明する。

この場合、バイヤー側からの入金を受けたサプライヤー側の銀行の銀行システム４００は、上述の入金事実を示す入金通知を、プラットフォームサーバ１００およびサプライヤー端末２００に送信するものとする。

サプライヤー端末２００は上述の入金通知を受けて、入金情報１３７の作成指示をプラットフォームサーバ１００に送る（ｓ１５７）。

一方、プラットフォームサーバ１００は、上述のサプライヤーの口座に関する入金通知を受信し、更には、サプライヤー端末２００から上述の入金情報作成指示を受けて、前記入金通知が示す情報に基づいて、入金情報１３７を作成し、記憶装置１０１に格納する（ｓ１５８）。入金情報１３７は、図１６に示すように、銀行に実際に入金があった日付を示す入金日、入金があった口座を示す入金口座、入金の依頼人すなわち振込の実行企業たる依頼人、および入金された金額を示す金額情報の各データから構成されている。

他方、サプライヤー端末２００は、上述の入金情報作成指示をプラットフォームサーバ１００に送信した後、上述の入金通知を出力装置２０７に表示させて、サプライヤー企業における経理部門の担当者による、ファーピャオとの照合作業に供する。この経理部門の担当者は、入金通知の示す内容がファーピャオの示す内容と整合性がとれているか確認することになる。経理部門の担当者は、両者の整合性がとれていると判断した場合、サプライヤー端末２００の入力装置２０６において、上述の入金通知に対応した売掛金に関する消込処理の依頼指示を入力する。

サプライヤー端末２００は、この消込処理の依頼指示を入力装置２０６にて受けて、これをプラットフォームサーバ１００に送信する（ｓ１５９）。一方、プラットフォームサーバ１００は、この売掛金消込依頼を受けて、上述の入金情報１３７と、上述の売掛金消込予定情報１３６とをマッチングし、上述の入金通知の内容と対応する売掛金の売掛金消込予定情報１３６を特定し、該当売掛金に関する消込処理を売掛金情報１２７にて実行する（ｓ１６０）。このステップにて具体的には、プラットフォームサーバ１００は、図１６Ａに示す売掛金情報１２７にて、「金額情報」における「売掛金残高」の値を「０」、「１７０」などと設定し、「消込区分」における「区分」の値を、「全部消込済」、「一部消込済」と設定している。また、プラットフォームサーバ１００は、この売掛金の消込処理の実行通知をサプライヤー端末２００に送る。

サプライヤー端末２００は、上述の売掛金の消込処理の実行通知を受信し、売掛金情報１２７に関する仕訳作成処理を実行し（ｓ１６１）、総勘定元帳１２８を更新する。サプライヤー端末２００は、サプライヤー企業における経理部門の担当者からの指示を受け、この総勘定元帳１３１の照会を行える。（ｓ１６２）。

一方、上述のステップｓ１６０にて売掛金の消込処理を実行した後、上述の入金通知の内容と対応する売掛金情報１２７ないし売掛金消込予定情報１３６を特定し、当該特定した売掛金に対する入金額の過不足を判定する（ｓ１６３）。この場合、プラットフォームサーバ１００は、例えば、上述の図１６Ａに示す売掛金情報１２７にて、「金額情報」における「売掛金残高」の値と、「消込区分」における「区分」の値とを読み取り、「売掛金残高」の値が「０」以外であるレコード、或いは、「消込区分」における「区分」の値が「全部消込済」以外であるレコードを検索し、該当レコードを検索できた場合、売掛金に対する入金額の過不足が生じていると判定することとなる。

プラットフォームサーバ１００は、上述の判定の結果、入金額の過不足が無かった場合（ｓ１６４：Ｙ）、上記で特定した売掛金消込の連絡をサプライヤー端末２００に実行する（ｓ１６５）。或いは、入金額の過不足が無かった場合（ｓ１６４：Ｙ）に、上記で特定した売掛金消込の処理を実行するとしてもよい。なお、入金の過不足があった場合でも、売掛金の消込処理を行ってもよい。この場合、不足の場合は入金分のみの消し込みになる。また、過不足額の情報の送信と消し込みの両方を行ってもよい。

一方、上述の判定の結果、入金額の過不足があった場合（ｓ１６４：Ｎ）、過不足額の情報たる入金過不足情報１３９を作成し（ｓ１６７）、これをサプライヤー端末２００に送信する（ｓ１６８）。図１６Ｂに入金過不足情報１３９を示している。この入金過不足情報１３９は、入金額の過不足があった売掛金情報１２７のレコード（元のインボイスデータ１２５のレコードとも言える）に関する、入金日、入金口座情報、金額情報、請求書情報、支払情報、商品情報、支払口座情報、および備考の各情報からなっている。「備考」の情報には、サプライヤー企業やバイヤー企業にてとられるべき所定の対応策案がプラットフォームサーバ１００にて設定される。

サプライヤー端末２００では、上述の入金過不足情報１３９をプラットフォームサーバ１００より受信し（ｓ１６９）、これを受けて、プラットフォームサーバ１００における共有フォルダ（バイヤー端末３００からもアクセス可能なフォルダ）に格納される、入金過不足情報１４０の作成指示を、プラットフォームサーバ１００に送る（ｓ１７０）。プラットフォームサーバ１００ではこの作成指示を受け、上述の入金過不足情報１３９をコピーして入金過不足情報１４０とし、記憶装置１０１における共有フォルダに格納する（ｓ１７１）。また、プラットフォームサーバ１００は、この入金過不足情報１４０に基づいて、過不足情報の連絡をバイヤー端末３００に送る（ｓ１７２）。

バイヤー端末３００では、上述の過不足情報の連絡をプラットフォームサーバ１００より受信し、これを出力装置３０７にて表示、バイヤー企業における購買部門の担当者に閲覧させる（ｓ１７３）。入金額に過不足があった事実を感知したサプライヤー企業およびバイヤー企業では、例えば、連絡を取り合って契約内容の再確認や修正、過不足分の金額の決済などの後処理を実行することとなる。

次に、決済金額の相殺処理について図に基づき説明する。図１０は、本実施形態における決済業務支援方法の処理手順例６を示すフロー図である。ここでは、プラットフォームサーバ１００における電子商取引の参加者が保有する債権(売掛金)と債務(買掛金)に紐付く送金取引を相殺し、ある一定の期日に差額分だけを決済する手法について示す。こうした処理を行うことで、取引のたびに決済を行う場合と比較して、銀行手数料や事務処理の手間を削減できる効果がある。なお、２者間について相殺処理を行う方式（バイラテラルネッティング）、統括会社などが仲介して３者以上で相殺処理を行う方式（マルチラテラルネッティング）のいずれかを状況に応じて採用できる。

この場合、プラットフォームサーバ１００は、互いに債権、債務を負っている、すなわち、インボイスデータ１２５や支払予定データ１３２、或いは集約後支払予定データ１３２における「支払口座情報」の「企業名」の値がお互いを指し合っている、１組以上のサプライヤーとバイヤーを、「支払口座情報」の「企業名」の値をキーに特定する（ｓ１８０）。

次にプラットフォームサーバ１００は、上記で特定した１組以上のサプライヤーとバイヤーのそれぞれについて、上述の集約後支払予定データ１３２を記憶装置１０１から読み出して（ｓ１８１）、それら集約後支払予定データ１３２における支払金額の値を、該当サプライヤーと該当バイヤーとの間で相殺する（ｓ１８２）。

また、プラットフォームサーバ１００は、当該相殺後に残債分の内容のみが残された支払予定データ１３２が示す、サプライヤーないしバイヤーの利用銀行の銀行システム４００に対し、上述した残債分の集約後支払予定データ１３２が示す内容に応じた決済処理の依頼を送信する（ｓ１８３）。該当銀行システム４００ではこの依頼に応じて決済処理を実行することとなる。

例えば、上述のステップｓ１８０で特定できたサプライヤーとバイヤーの組みが１組であった場合、いわゆるバイラテラル・ネッティングが実行されることになる。支払金額の相殺すなわちネッティング前、図１１に例示するような３つの取引をＡ社とＢ社が行っていたとする。上述のステップｓ１８２を実行すれば、図１１の下段にて示すように、相殺後に残債分の内容のみが残された支払予定データ１３２Ｂは、「債務者」が「Ａ社」、「債権者」が「Ｂ社」、決済金額の残債は「２００」となる。このように、従来どおり１取引ごとに決済した場合、為替／送金取引は、３取引分そのままの３回分必要となるが、ネッティング後は１回分のみとなる。

また、上述のステップｓ１８０で特定できたサプライヤーとバイヤーの組みが２組以上であった場合、いわゆるマルチラテラル・ネッティングが実行されることになる。支払金額の相殺すなわちネッティング前、図１１Ａ、図１１Ｂに例示するような６つの取引を、Ａ社、Ｂ社、Ｃ社、Ｄ社が行っていたとする。上述のステップｓ１８２を実行すれば、図１１Ａの下段、および図１１Ｃにて示すように、相殺後に残債分の内容のみが残された支払予定データ１３２Ｂは、「債務者」が「Ａ社」、「債権者」が「Ｃ社」、決済金額の残債は「１８４６」となる。このように、従来どおり１取引ごとに決済した場合、為替／送金取引は、６取引分そのままの６回分必要となるが、ネッティング後は１回分のみとなった。つまり、為替／送金取引を大幅に減らし、手数料を削減できる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、企業間取引と銀行取引とを連携させ、各種の決済業務の効率化およびコスト削減が可能となる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の決済業務支援方法において、前記バイヤーの端末が、前記コンピュータから受信した請求書データを出力装置に表示させる処理と、前記請求書データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置で受け付ける処理とを実行し、前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、前記請求書データに基づく買掛金の情報の生成と、この買掛金の情報の前記コンピュータへの送信を実行し、前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報を前記コンピュータに送信する処理を実行し、前記コンピュータが、前記差異の情報を前記バイヤーの端末から受信して、当該差異の情報を記憶装置に格納し、前記サプライヤーの端末に前記差異に関する確認要求を送信する処理を実行する、としてもよい。

また、本実施形態の決済業務支援方法において、前記コンピュータが、前記バイヤーの端末より支払依頼を受信した場合、前記バイヤーに関する集約後支払予定データを記憶装置より読み出し、当該集約後支払予定データが示す、前記バイヤーの利用銀行のシステムに対し、前記集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理と、前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤーの端末に宛てて送信する処理と、を実行するとしてもよい。

また、本実施形態の決済業務支援方法において、前記バイヤーの端末が、前記支払依頼をコンピュータに送信するに伴い、前記コンピュータより前記集約後支払予定データを取得して出力装置に表示させる処理と、前記集約後支払予定データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、前記支払依頼の可否について判断した結果を、入力装置で受け付ける処理とを実行し、前記入力装置で受け付けた結果が、前記支払依頼を承認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行し、前記入力装置で受け付けた結果が、前記支払依頼を否認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行せず、当該否認の旨を予め定めた所定の端末に送信する処理を実行する、としてもよい。

また、本実施形態の決済業務支援方法において、前記コンピュータが、前記バイヤーの端末より、前記請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置に格納する処理と、前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼が含む、請求書データの識別情報と対応する前記買掛金の情報を特定し、該当買掛金の情報に関する消込処理と、を実行するとしてもよい。

また、本実施形態の決済業務支援方法において、前記コンピュータが、前記支払通知の生成ないし前記サプライヤーの端末からの指示に応じて、前記決済処理の依頼ないし前記支払通知が含む、前記サプライヤーへの支払内容の情報により、前記サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、記憶装置に格納する処理と、前記サプライヤーの端末より、前記請求書データに基づいた売掛金の情報を受信し記憶装置に格納する処理と、前記入金予定の情報と前記売掛金の情報とをマッチングし、前記入金予定の情報が含む、請求書データの識別情報と対応する前記売掛金の情報を特定し、該当売掛金の消込予定の情報を生成する処理と、を実行するとしてもよい。

また、本実施形態の決済業務支援方法において、前記コンピュータが、前記サプライヤーの口座への入金事実について、前記サプライヤーの利用銀行より通知を受信し、当該通知が示す入金内容と、前記売掛金の消込予定の情報とをマッチングし、前記入金内容と対応する前記売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する処理と、前記判定の結果、入金額の過不足が無かった場合、前記特定した売掛金の消込処理を実行し、前記判定の結果、入金額の過不足があった場合、過不足額の情報を前記サプライヤーの端末および前記バイヤーの端末に送信し、前記特定した売掛金の消込処理を、前記過不足額分について実行する、としてもよい。 また、本実施形態の決済業務支援方法において、前記コンピュータが、１組以上のサプライヤーとバイヤーのそれぞれについて、前記集約後支払予定データを記憶装置から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行のシステムに対し、前記残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理を実行する、としてもよい。

１０ 決済業務支援システム
１００ プラットフォームサーバ（コンピュータ）
１０１、２０１、３０１ 記憶装置
１０２、２０２、３０２ プログラム
１０３、２０３、３０３ メモリ
１０４、２０４、３０４ 演算装置
２０６、３０６ 入力装置
２０７、３０７ 出力装置
１０５、２０５、３０５ 通信装置
１１０、２１０、３１０ データ類
１２０ ネットワーク
１２５ インボイスデータ
１２６ 支払予定データ
１２７ 売掛金情報
１２８、１３１ 総勘定元帳
１２９ 差分情報
１３０ 買掛金情報
１３２ 集約後支払予定データ
１３３ バイヤー口座情報
１３４ 支払通知
１３５ 入金予定情報
１３６ 売掛金消込予定情報
１３７ 入金情報
１３９、１４０ 入金過不足情報
２００ サプライヤー端末
３００ バイヤー端末
４００ 銀行システム

Claims (9)

1. 企業間の電子商取引を仲介するコンピュータが、
   電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理を実行し、
   前記バイヤーの端末が、
   当該バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理を実行し、
   前記コンピュータが、
   前記バイヤーの端末から受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理を実行し、
   前記サプライヤーの端末が、
   前記請求書データに基づいて仕訳作成処理を実行して、当該サプライヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、売掛金情報を生成して前記コンピュータに送信する処理を実行し、
   前記バイヤーの端末が、
   前記請求書データに基づいて仕訳作成処理を実行して、当該バイヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、買掛金情報を生成して前記コンピュータに送信する処理を実行し、
   前記コンピュータが、
   前記バイヤーの端末からの決済処理の依頼に基づいて前記買掛金情報の消込処理を実行し、当該買掛金情報消込処理の結果を前記バイヤーの端末に送信し、前記バイヤーの利用銀行のシステムである銀行システムから受信する入金通知に基づいて前記売掛金情報の消込処理を実行し、当該売掛金情報消込処理の結果を前記サプライヤーの端末に送信する処理を実行し、
   前記サプライヤーの端末が、
   受信した前記売掛金消込処理の結果に基づいて、前記売掛金情報に関する仕訳作成処理を実行し、前記サプライヤーでの総勘定元帳を更新する処理を実行し、
   前記バイヤーの端末が、
   受信した前記買掛金消込処理の結果に基づいて、前記買掛金情報に関する仕訳作成処理を実行し、前記バイヤーでの総勘定元帳を更新する処理を実行する、
   ことを特徴とする決済業務支援方法。
2. 前記バイヤーの端末が、
   前記コンピュータから受信した請求書データを出力装置に表示させる処理と、
   前記請求書データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合した結果を、入力装置で受け付ける処理とを実行し、
   前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異が無いことを示す場合、前記請求書データに基づく買掛金の情報の生成と、この買掛金の情報の前記コンピュータへの送信を実行し、
   前記入力装置で受け付けた結果が、請求書データの内容と紙媒体の請求書の内容とに差異があることを示す場合、その差異の情報を前記コンピュータに送信する処理を実行し、
   前記コンピュータが、
   前記差異の情報を前記バイヤーの端末から受信して、当該差異の情報を記憶装置に格納し、前記サプライヤーの端末に前記差異に関する確認要求を送信する処理を実行する、
   ことを特徴とする請求項１に記載の決済業務支援方法。
3. 前記コンピュータが、
   前記バイヤーの端末より支払依頼を受信した場合、前記バイヤーに関する集約後支払予定データを記憶装置より読み出し、当該集約後支払予定データが示す、前記バイヤーの利用銀行のシステムに対し、前記集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理と、
   前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼がなされた該当請求書データに関する支払通知を生成して、該当サプライヤーの端末に宛てて送信する処理と、
   を実行することを特徴とする請求項１に記載の決済業務支援方法。
4. 前記バイヤーの端末が、
   前記支払依頼をコンピュータに送信するに伴い、前記コンピュータより前記集約後支払予定データを取得して出力装置に表示させる処理と、
   前記集約後支払予定データが示す内容と、サプライヤーから送付されていた紙媒体の請求書が示す内容とをバイヤーが照合して、前記支払依頼の可否について判断した結果を、入力装置で受け付ける処理とを実行し、
   前記入力装置で受け付けた結果が、前記支払依頼を承認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行し、
   前記入力装置で受け付けた結果が、前記支払依頼を否認するものであった場合、前記支払依頼の前記コンピュータへの送信を実行せず、当該否認の旨を予め定めた所定の端末に送信する処理を実行する、
   ことを特徴とする請求項３に記載の決済業務支援方法。
5. 前記コンピュータが、
   前記バイヤーの端末より、前記請求書データに基づいた買掛金の情報を受信し、当該買掛金の情報を記憶装置に格納する処理と、
   前記決済処理の依頼を前記バイヤーの利用銀行のシステムに送信する処理に伴い、前記決済処理の依頼が含む、請求書データの識別情報と対応する前記買掛金の情報を特定し、該当買掛金の情報に関する消込処理と、
   を実行することを特徴とする請求項３に記載の決済業務支援方法。
6. 前記コンピュータが、
   前記支払通知の生成ないし前記サプライヤーの端末からの指示に応じて、前記決済処理の依頼ないし前記支払通知が含む、前記サプライヤーへの支払内容の情報により、前記サプライヤーの利用銀行における当該サプライヤーの口座への入金予定の情報を生成し、記憶装置に格納する処理と、
   前記サプライヤーの端末より、前記請求書データに基づいた売掛金の情報を受信し記憶装置に格納する処理と、
   前記入金予定の情報と前記売掛金の情報とをマッチングし、前記入金予定の情報が含む、請求書データの識別情報と対応する前記売掛金の情報を特定し、該当売掛金の消込予定の情報を生成する処理と、
   を実行することを特徴とする請求項３に記載の決済業務支援方法。
7. 前記コンピュータが、
   前記サプライヤーの口座への入金事実について、前記サプライヤーの利用銀行より通知を受信し、当該通知が示す入金内容と、前記売掛金の消込予定の情報とをマッチングし、前記入金内容と対応する前記売掛金の消込予定の情報を特定し、当該特定した売掛金に対する入金額の過不足を判定する処理と、
   前記判定の結果、入金額の過不足が無かった場合、前記特定した売掛金の消込処理を実行し、
   前記判定の結果、入金額の過不足があった場合、過不足額の情報を前記サプライヤーの端末および前記バイヤーの端末に送信し、前記特定した売掛金の消込処理を、前記過不足額分について実行する、
   ことを特徴とする請求項６に記載の決済業務支援方法。
8. 前記コンピュータが、
   １組以上のサプライヤーとバイヤーのそれぞれについて、前記集約後支払予定データを記憶装置から読み出して、サプライヤーとバイヤーとの間の支払金額を相殺し、当該相殺後に残債分の内容のみとなった支払予定データが示す、サプライヤーないしバイヤーの利用銀行のシステムに対し、前記残債分の集約後支払予定データが示す内容に応じた決済処理の依頼を送信する処理を実行する、
   ことを特徴とする請求項１に記載の決済業務支援方法。
9. 電子商取引におけるサプライヤーの端末より、バイヤーに宛てた請求書データを受信して記憶装置に格納し、前記バイヤーの端末からの取得要求に応じて前記請求書データを記憶装置から読み出してバイヤーの端末に送信する処理と、
   前記バイヤーの端末が、前記請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して生成した、前記サプライヤー宛の支払予定データを受信する処理と、
   前記受信した支払予定データのうち、予め定めた所定項目ないし前記バイヤー端末から指定を受けた所定項目が共通する支払予定データを特定し、前記特定した各支払予定データにおける支払金額を合算して該当支払予定データらマージし、当該マージ後の支払予定データを集約後支払予定データとして記憶装置に格納する処理と、前記バイヤーの端末からの決済処理の依頼に基づいて前記買掛金情報の消込処理を実行し、当該買掛金情報消込処理の結果を前記バイヤーの端末に送信し、当該バイヤーの利用銀行のシステムである銀行システムから受信する入金通知に基づいて前記売掛金情報の消込処理を実行し、当該売掛金情報消込処理の結果を前記サプライヤーの端末に送信する処理とを実行する演算装置を備え、企業間の電子商取引を仲介するコンピュータと、
   前記バイヤー宛ての請求書データの取得要求を前記コンピュータに送り、前記コンピュータから該当する請求書データを受信し、当該請求書データに、予め定めた決済用の情報ないし入力装置からバイヤーが指定した決済用の情報を付与して前記サプライヤー宛の支払予定データを生成し、前記コンピュータに送信する処理と、前記請求書データに基づいて仕訳作成処理を実行して、当該バイヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、買掛金情報を生成して前記コンピュータに送信する処理と、受信した前記買掛金消込処理の結果に基づいて、前記買掛金情報に関する仕訳作成処理を実行し、前記バイヤーでの総勘定元帳を更新する処理とを実行する演算装置を備えた、バイヤーの端末と、
   電子商取引におけるバイヤーに宛てた請求書データを、前記コンピュータに送信する処理と、前記請求書データに基づいて仕訳作成処理を実行して、当該サプライヤーにおける総勘定元帳を生成して記憶装置に保持するとともに、売掛金情報を生成して前記コンピュータに送信する処理と、受信した前記売掛金消込処理の結果に基づいて、前記売掛金情報に関する仕訳作成処理を実行し、前記サプライヤーでの総勘定元帳を更新する処理とを実行する演算装置を備えたサプライヤーの端末と、
   を備える決済業務支援システム。

Images