JP2018190168A - 照合プログラムおよびデータ照合方法 - Google Patents

Abstract

【課題】 自社の受注（出荷）が確実に決済されたことを素早く正確に確認するために、収納代行業者から取得できる決済明細情報と自社の受注（出荷）明細情報を個別に照らし合わせ、決済情報に漏れが無いかを容易に確認できる照合プログラムを提供する。。【解決手段】 照合システム１３において、受発注システム１１からの取引データ１４１と収納代行システム２３からの決済データ１４３との照合を行う。そして、照合に成功した未収入請求データ１７１を請求入金照合部４７に出力する。請求入金照合部４７では、未収入請求データ１７１と、銀行システム２５からの入金データ１７３との照合を行う。【選択図】図３

Description

本発明は、複数の請求データと複数の入金データとの照合処理をコンピュータに実行させる照合プログラム、および複数の請求データと複数の入金データとの照合処理を行うデータ照合方法に関する。

一般的に、商取引の決済方法として振込による決済が広く利用されている。振込による決済においては、売り手は、買い手に商品等を販売した場合に、商品等の情報に基づいて買い手に請求書を発行する。買い手は、請求書の金額を、ＥＢ（Electronic Banking）を利用して、又は銀行等の金融機関の窓口、ＡＴＭ（現金自動預入払出機）などから売り手の銀行口座に振込みを依頼する。買い手から振込みを依頼された銀行は、全銀などの決済ネットワークを通じて、買い手の銀行口座から売り手の銀行口座に資金を移動する。これにより、振込による決済が行われる。

ところで、同一の売り手から同一の買い手に対して複数の請求書が発行される場合がある。このような場合、買い手が請求書１件毎に振込処理を行うことは、非常に煩雑である。また、振込手数料が振込処理毎にかかってしまう。そのため、買い手が複数の請求書の合計金額を合算して売り手の銀行口座に振込むことは、一般的に広く行われている。

しかしながら、買い手が複数の請求書の合計金額を合算して振込みを行った場合、入金された金額がどの請求書に基づいた金額であるのかを売り手が特定することが困難なことがある。ここで、例えば売り手が発行した未払いの請求書の全件について合算振込が行われ、かつ請求書の合計金額と合算振込が行われた金額とが互いに一致する場合には、売り手は、買い手についての全ての未払い請求書を一括して消込処理できる。しかし、売り手の請求合計金額と、買い手から合算振込された金額と、が互いに一致しないことがある。そのため、複数の請求データと、複数の入金データと、の照合処理において効率の向上および精度の向上が望まれている。

ところで、近年、BtoCをメインとするネットショップに限らず、企業間取引においても、クレジット決済、代引き決済など収納代行業者による第三者回収が主流となりつつあり、自社の受注（出荷）が確実に決済されたことを素早く正確に確認するために、収納代行業者から取得できる決済明細情報と自社の受注（出荷）明細情報を個別に照らし合わせ、決済情報に漏れが無いかを確認するという煩雑な管理作業を行うべきである。

また、収納代行業者を複数採用する場合があり、決済状況の管理が複雑になってきた。
また、決済明細情報と自社の受注・売上や出荷情報を自動照合して違算管理をしたいという要請がある。
また、BtoB/BtoC両方の取引があり、債権管理が煩雑になってしまっている。
さらには、上場前の監査対応等で、自社受注情報の決済前/決済済み/着金回収済みなどのステータス管理が必要になっている。
さらには、決済結果を自動仕訳して会計仕訳作成工数の合理化を図りたいという要請がある。

本発明は、前記課題を解決するためになされたものであり、自社の受注（出荷）が確実に決済されたことを素早く正確に確認するために、収納代行業者から取得できる決済明細情報と自社の受注（出荷）明細情報を個別に照らし合わせ、決済情報に漏れが無いかを容易に確認できる照合プログラムおよびデータ照合方法を提供することを目的とする。

本発明の照合プログラムは、取引データと決済データとの第１の照合を行う取引決済照合工程と、前記第1の照合により、未照合の前記取引データを示す未照合取引データを特定する未照合取引特定工程と、前記第１の照合により、未照合である前記決済データを示す未照合決済データを特定する未照合決済特定工程と、前記第１の照合に成功した前記決済データを基に未収入請求データを生成する未収入請求生成工程と、前記未収入請求生成工程で生成した前記未収入請求データを含む複数の請求データと、複数の入金データとの第２の照合を行う請求入金照合工程とをコンピュータに実行させる。

好適には、前記未照合取引特定工程で特定した前記未照合取引データについて、当該未照合取引データの削除、あるいはそれに対応する新たな請求データの発行を示す未照合取引ステータスデータを生成する未照合取引ステータス生成工程を前記コンピュータにさらに実行させる。

好適には、前記未照合取引ステータス生成工程で生成した前記未照合取引ステータスデータが前記新たな請求データの発行を示す前記未照合取引データを基に、新たな請求データを発行する新請求発行工程
を前記コンピュータにさらに実行させる。

好適には、前記未照合決済特定工程で特定した前記未照合決済データについて、当該未照決済データに手動による取引データと対応付けを行うか否かを示す未照合決済ステータスデータを生成する未照合決済ステータス生成工程
を前記コンピュータにさらに実行させる。

好適には、前記未照合決済ステータス生成工程で生成した前記未照合決済ステータスデータが手動による取引データとの対応付けを行うことを示す前記未照合決済データを基に、手動による対応付け処理を行う未照合決済手動処理工程を前記コンピュータにさらに実行させる。

好適には、前記未収入請求生成工程は、前記未照合決済手動処理で手動による対応付けを行った前記未照合決済データに対応する未収入請求を含む前記未収入請求データを生成する。

好適には、受発注システムから前記取引データを入力する取引データ入力工程を前記コンピュータにさらに実行させ、前記取引データの入力時には、当該取引データに係る売上は、当該取引に係る発注者への売掛金として管理する。

好適には、前記未収入請求生成工程で生成した前記未収入請求データに係る未収入金は、前記決済データを発行した決済機関に対する未収入金として管理する。

好適には、前記請求入金照合工程は、予め設定された照合順序に基づいて前記請求データと前記入金データとを照合し、前記複数の請求データのうちで未入金の前記請求データと入金済みの前記請求データとを自動的に特定する一括消込処理と、前記一括消込処理において消し込みが行われずに残った前記複数の請求データのうちで未入金の前記請求データと入金済みの前記入金データとを手動で特定する個別消込処理と、前記個別消込処理において消し込みが行われたパターンを学習して学習履歴として保存し、保存した前記学習履歴を前記一括消込処理に反映させる学習履歴処理と、を前記コンピュータに実行させる。

好適には、期日現金の支払通知に関する情報が入力されると前記請求データと前記入金データとを照合し消込処理を行うとともに前記支払通知により通知された支払予定日を期日とする新たな請求データを自動的に生成する期日現金処理を前記コンピュータにさらに実行させる。

本発明のデータ照合方法は、取引データと決済データとの第１の照合を行う取引決済照合工程と、前記第1の照合により、未照合の前記取引データを示す未照合取引データを特定する未照合取引特定工程と、前記第１の照合により、未照合である前記決済データを示す未照合決済データを特定する未照合決済特定工程と、前記第１の照合に成功した前記決済データを基に未収入請求データを生成する未収入請求生成工程と、前記未収入請求生成工程で生成した前記未収入請求データを含む複数の請求データと、複数の入金データとの第２の照合を行う請求入金照合工程とをコンピュータに実行させる。

本発明によれば、自社の受注（出荷）が確実に決済されたことを素早く正確に確認するために、収納代行業者から取得できる決済明細情報と自社の受注（出荷）明細情報を個別に照らし合わせ、決済情報に漏れが無いかを容易に確認できる照合プログラムおよびデータ照合方法を提供することができる。

本実施形態に係るシステムの全体構成図である。 図１に示す照合システムの機能ブロック図である。 照合システムの機能を実現するためのハードウェア構成図である。 図１〜図３に示す照合システム１３による照合処理の流れを説明するためのフローチャートである。 図３に示す請求入金照合部の一括消込処理に係る機能ブロック図である。 本実施形態の一括消込処理を説明する表である。 本実施形態の照合順序の設定を説明する表である。 本実施形態の個別消込処理を説明する表である。 本実施形態の個別消込処理における請求データの設定を説明する表である。 本実施形態の個別消込処理における入金データの設定を説明する表である。 本実施形態の消込シミュレーション処理を説明する表である。 本実施形態の期日現金処理を説明する表である。

以下に、本発明の好ましい実施形態を、図面を参照して詳しく説明する。
なお、以下に説明する実施形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は、以下の説明において特に本発明を限定する旨の記載がない限り、これらの態様に限られるものではない。また、各図面中、同様の構成要素には同一の符号を付して詳細な説明は適宜省略する。

図１は、本実施形態に係るシステム１の全体構成図である。図２は、図１に示す照合システム１３の機能ブロック図である。
なお、図１に表したブロック図は、照合プログラムＰＲＧが格納された消込処理システムの要部構成の一例であり、必ずしも実際のプログラムモジュールの構成とは一致しない場合がある。また、図１に示したハードウェア構成は、一例である。本実施形態に係る照合プログラムＰＲＧが格納された消込処理システムの一部、又は全部として、ＬＳＩ（Large Scale Integration）等の集積回路、または、ＩＣ（Integrated Circuit）チップセットが用いられてもよい。各機能ブロックは、個別にプロセッサ化されてもよい。各機能ブロックの一部又は全部は、集積されプロセッサ化されてもよい。集積回路化の手法は、ＬＳＩには限定されず、専用回路又は汎用プロセッサで集積回路化が行われる手法であってもよい。

本実施形態に係る照合プログラムＰＲＧは、コンピュータ読取可能な記録媒体に記録されていてもよい。記録媒体は、ネットワークに接続されたサーバ等の記憶装置であってもよい。また、本実施形態に係る照合プログラムＰＲＧは、ネットワークを介して配信されてもよい。

図１に示すように、本実施形態の取引システム１は、受発注システム１１及び照合システム１３を有し、顧客端末２１、収納代行システム２３及び銀行システム２５と通信を行いながら処理を行う。

受発注システム１１は、顧客端末２１との間で商品・サービスの受発注及び決済処理を行い、その取引データを照合システム１３に出力する。取引データは項目として決済代行会社コード、顧客コード、取引ID、注文ID、売上日、決済予定日、取引金額等を有している。受発注システム１１は、取引の回収依頼を収納代行システム２３に行う。

収納代行システム２３は、受発注システム１１からの回収依頼に応じて、顧客端末２１に対して収納代行処理等を行い、決済データを照合システム１３に出力する。決済データは項目として決済代行会社コード、決済日、決済金額の他、注文IDなどに使用可能な複数の自由作成項目を有している。

図２に示すように、照合システム１３は、例えば、取引決済照合部３９、未照合取引特定部４１、未照合決済特定部４３、未収入請求生成部４５、請求入金照合部４７、未照合取引ステータス生成部４９及び新請求発行部５１を有する。

取引決済照合部３９は、受発注システム１１から入力した取引データ１４１と収納代行システム２３から入力した決済データ１４３との第１の照合を行う。
当該第１の照合は、取引データのある項目と決済データのある項目を複数選択して設定する、決済代行会社ごとに自由にパターン化した照合キーを用いて取引データと決済データとの間の一致・不一致を照合する。

未照合取引特定部４１は、取引決済照合部３９による上記第１の照合により、未照合の取引データを示す未照合取引データを特定する。ここで、未照合の取引データとは、上記第１の照合によって当該取引データに対応する決済データが特定できない取引データである。

未照合決済特定部４３は、取引決済照合部３９による上記第１の照合により、未照合である決済データを示す未照合決済データを特定する。ここで、未照合の決済データとは、上記第１の照合によって当該決済データに対応する取引データが特定できない決済データである。

未照合決済ステータス生成部５３は、未照合決済特定部４１で特定した未照合決済データについて、当該未照決済データに手動による取引データと対応付けを行うか否かを示す未照合決済ステータスデータ１６１を生成する。

未照合決済手動処理部５５は、未照合決済ステータス生成部５３で未照合決済ステータスデータが「対応づけを行う」ことを示す未照合決済データについて、手動による対応づけを行う。具体的には、未照合決済ステータスデータが「対応づけを行う」ことを示す未照合決済データと、未照合取引データとを図３に示すディスプレイ１２２上に表示し、操作者が操作部１２３を用いて対応付け（紐づけ）を行う。

未収入請求生成部４５は、取引決済照合部３９による上記第１の照合に成功した決済データを基に未収入請求データ１７１を生成する。
このとき、未収入請求生成部４５は、未照合決済手動処理部５５によって手動による対応づけが行われ未照合決済データを含めて未収入請求データを生成する。

請求入金照合部４７は、未収入請求生成部４５で生成した未収入請求データ１７１を含む複数の請求データと、銀行システム２５からの複数の入金データ１７３との第２の照合を行う。
当該第２の照合は、得意先マスタに設定されたカナ情報や学習履歴マスタに保存されているカナ情報と入金データ上の振込依頼人カナ情報、金額等の予め決められた項目を用いて請求データと入金データ１７３との間の一致・不一致を照合する。

未照合取引ステータス生成部４９は、未照合取引特定部４１で特定した未照合取引データについて、当該未照合取引データの削除、あるいはそれに対応する新たな請求データの発行を示す未照合取引ステータスデータ１６３を生成する。具体的には、未照合取引データを図３に示すディスプレイ１２２上に表示し、操作者が操作部１２３を用いて、その削除あるいは新たな請求の発行操作を行うかの指示を入力する。

新請求発行部５１は、前記未照合取引ステータス生成部４９で未照合取引ステータスデータ１６３が上記新たな請求データの発行を示す未照合取引データを基に、新たな請求データを発行する。

図３は、上述した照合システム１３の機能を実現するためのハードウェア構成図である。
図３に示すように、照合システム１３は、例えば、インタフェース１２１、ディスプレイ１２２、操作部１２３、メモリ１２４及び処理回路１２５を有し、これらがバス１２０を介して接続されている。

インタフェース１２１は、例えば、受発注システム１１、収納代行システム２３及び銀行システム２５等の他のコンピュータと通信を行うために用いられる。
ディスプレイ１２２は、処理回路２５が実行する照合プログラムＰＲＧが提供する様々な画面を表示する。

操作部１２３は、キーボードやマウス等の操作手段である。
メモリ１２４は、処理回路１２５が実行する照合プログラムＰＲＧ、処理回路１２５の処理に用いられるデータを一時的に記憶する。
処理回路１２５は、照合プログラムＰＲＧを実行して、カウンセリング支援装置１の処理を統括的に制御する。
本実施形態で示される照合システム１３の処理は、照合プログラムＰＲＧに記述されている。

以下、照合システム１３による照合処理の流れを説明する。
図４は、図１〜図３に示す照合システム１３による照合処理の流れを説明するためのフローチャートである。
各ステップについて説明する。
ステップＳＴ１：
図４に示すインタフェース１２１を介して、図１に示す受発注システム１１から取引データ１４１を入力する。
取引データ１４１は、メモリ１２４に記憶される。当該タイミングでは、照合システム１３は、取引データに係る売上は、当該取引に係る取引者（顧客端末２１のユーザ）への売掛金とし管理（データ記憶）する。

ステップＳＴ２：
図４に示すインタフェース１２１を介して、図１に示す収納代行システム２３から決済データ１４３を入力する。
決済データ１４３は、メモリ２４に記憶される。

ステップＳＴ３
取引決済照合部３９は、ステップＳＴ１で入力した取引データと、ステップＳＴ２で入力した決済データとの第１の照合を行う。当該第１の照合は、取引データのある項目と決済データのある項目を複数選択して設定する、決済代行会社ごとに自由にパターン化した照合キーを用いて取引データと決済データとの間の一致・不一致を照合する。

ステップＳＴ４：
未照合取引特定部４１は、取引決済照合部３９による上記第１の照合により、未照合の取引データを示す未照合取引データを特定する。
未照合決済特定部４３は、取引決済照合部３９による上記第１の照合により、未照合である決済データを示す未照合決済データを特定する。

ステップＳＴ５：
未照合決済ステータス生成部５３は、未照合決済特定部４１で特定した未照合決済データについて、当該未照決済データに手動による取引データと対応付けを行うか否かを示す未照合決済ステータスデータ１６１を生成する。
未照合取引ステータス生成部４９は、未照合取引特定部４１で特定した前記未照合取引データについて、当該未照合取引データの削除、あるいはそれに対応する新たな請求データの発行を示す未照合取引ステータスデー１６３タを生成する。

ステップＳＴ６：
未照合決済手動処理部５５は、未照合決済ステータス生成部５３で未照合決済ステータスデータが「対応づけを行う」ことを示す未照合決済データについて、手動による対応づけを行う。

ステップＳＴ７：
未収入請求生成部４５は、取引決済照合部３９による上記第１の照合に成功した決済データを基に未収入請求データ１７１を生成する。
このとき、未収入請求生成部４５は、未照合決済手動処理部５５によって手動による対応づけが行われ未照合決済データを含めて未収入請求データ１７１を生成する。
照合システム１３は、未収入請求データ１７１に係る未収入金を、それに対応する決済データを発行した銀行システム２５（銀行）に対する未収入金として管理（データ記憶）する。

ステップＳＴ８：
請求入金照合部４７は、未収入請求生成部４５で生成した未収入請求データ１７１を含む複数の請求データと、複数の入金データ１７３との第２の照合を行う。

ステップＳＴ９：
新請求発行部５１は、前記未照合取引ステータス生成部４９で未照合取引ステータスデータ１６３が上記新たな請求データの発行を示す未照合取引データを基に、新たな請求データを発行する。

照合システム１３の図３及び図４に示す機能により、通常の振込をはじめとする入金管理全般にフォーカスすると同時に、これら決済代行業者を利用した決済情報の違算管理もまとめて処理し、貴社運用中の基幹システムや会計システムへ連携するデータを作成することで、決済代行業者を利用した新しい決済手段にも柔軟に対応できる債権管理システムとして、新しい役割を担うことができる。

照合システム１３によれば、決済明細情報と自社の受注・売上や出荷情報を自動照合して違算管理をすることができる。
また、顧客端末２１との取引（BtoB）と、収納代行システム２３との間の取引（BtoC）の両方の取引がある場合でも、債権管理が適切に行うことができる。
さらには、上場前の監査対応等で、自社受注情報の決済前/決済済み/着金回収済みなどのステータス管理が必要になっている場合でも、適切に対処できる。さらには、決済結果を自動仕訳して会計仕訳作成工数の合理化を図ることができる。

以下、図２に示す請求入金照合部４７が行う第２の照合（消込処理）について詳細に説明する。
請求入金照合部４７は、未収入請求生成部４５で生成した未収入請求データ１７１を含む複数の請求データと、複数の入金データ１７３との第２の照合を行う。

請求入金照合部４７は、一括消込処理部２５１と、個別消込処理部２５２と、学習履歴処理部２５３と、期日現金処理部２５４と、を有する。一括消込処理部２５１は、過入金表示処理部２５１ａと、誤差調整処理部２５１ｂと、照合順序設定処理部２５１ｃと、を有する。個別消込処理部２５２は、誤差調整処理部２５２ａと、消込シミュレーション処理部２５２ｂと、前受金処理部２５２ｃと、を有する。

次に、プログラム格納部２５に格納された照合プログラムＰＲＧの詳細を、図面を参照して説明する。
図５は、図３に示す請求入金照合部４７の一括消込処理に係る機能ブロック図である。
図６は、図５に示す一括消込処理を説明する表である。
図７は、本実施形態の照合順序の設定を説明する表である。

一括消込処理部２５１は、予め設定された照合順序に基づいて、請求データ（未収入請求データ１７１等）と、入金データ１７３と、を照合する。図６に表したように、一括消込処理における請求データは、例えば請求書発行先コード（得意先コード）と、請求書発行先名（得意先名）と、請求金額と、に関する情報を含む。請求書発行先コードは、請求書発行先ごとに付与された符号である。請求書発行先名は、請求書発行先（得意先）の名称である。なお、一括消込処理における請求データに含まれる情報は、利用者により適宜選択されてもよい。

一括消込処理における入金データ１７３は、振込依頼人名（請求書発行先カナ名）と、入金額と、手数料負担と、消込残と、に関する情報を含む。振込依頼人名（請求書発行先カナ名）は、請求書発行先の名称のカナ表示である。手数料負担は、振込手数料を負担する者に関する情報である。つまり、手数料負担は、相手先（得意先）が振込手数料を負担するのか、あるいは自社が振込手数料を負担するのか、に関する情報である。消込残は、請求金額と入金額との差額（未入金額）を表している。なお、一括消込処理における入金データ１７３に含まれる情報は、利用者により適宜選択されてもよい。

そして、一括消込処理部２５１は、複数の請求データのうちで未入金の請求データと入金済みの請求データとを自動的に特定する（一括消込処理）。例えば、図６に表した項番「１」のように、「株式会社Ａ」に対する請求金額が「２７９，０００」であり、「株式会社Ａ」からの入金額が「２００，０００」である場合には、消込残を「７９，０００」とする処理が実行される。すなわち、一括消込処理部２５１は、請求金額「２７９，０００」のうちで、未入金額「７９，０００」と入金額「２００，０００」とを自動的に特定する。あるいは、例えば図６に表した項番「４」のように、「株式会社Ｄ」に対する請求金額が「３１，５００」であり、「株式会社Ｄ」からの入金額が「３１，５００」である場合には、消込残を「０」とする処理が実行される。すなわち、一括消込処理部２５１は、請求金額「３１，５００」の全額「３１，５００」が株式会社Ｄから入金されたとして消し込みを行う。

ここで、図５に関して前述したように、一括消込処理部２５１は、照合順序設定処理部２５１ｃを有する。照合順序設定処理部２５１ｃは、請求書発行先コードと、学習履歴と、専用入金口座と、請求書発行先カナ名と、の少なくともいずれかに対して照合順序を設定し一括消込処理を実行する（照合順序設定処理）。すなわち、一括消込処理は、照合順序設定処理を有する。

図７に表したように、本実施形態では、一括消込処理部２５１が請求データと入金データ１７３との照合処理を実行する順序（照合順序）は、請求書発行先コードと、学習履歴と、専用入金口座と、請求書発行先カナ名と、の少なくともいずれかに対して設定される。専用入金口座は、請求書発行先ごとに割り振られた口座である。学習履歴の詳細については、後述する。

照合項目（照合ロジック名称）の順序および使用有無の設定は、利用者により適宜行われる。図７に表した例では、請求書発行先コードと、学習履歴と、専用入金口座と、請求書発行先カナ名と、を使用する照合処理は、この順序で実行される。また、図７に表した例では、請求書発行先コードと、学習履歴と、専用入金口座と、請求書発行先カナ名と、の全てが、照合処理において使用される。

図５に関して前述したように、一括消込処理部２５１は、過入金表示処理部２５１ａを有する。過入金表示処理部２５１ａは、請求書発行先に関する入金済みの請求データの金額が請求書発行先に関する複数の請求データの合計金額よりも多い場合に、入金済みの金額と、請求データの合計金額と、の差額を過入金として表示する（過入金表示処理）。すなわち、一括消込処理は、過入金表示処理を有する。例えば、図６に表した項番「６」のように、「株式会社Ｆ」からの入金額「２３４，２８０」が「株式会社Ｆ」に対する請求金額「２３２，０００」よりも多い場合には、過入金表示処理部２５１ａは、消込残を「−２，２８０」として過入金表示（例えばマイナス表示）を行う。

また、図５に関して前述したように、一括消込処理部２５１は、誤差調整処理部２５１ｂを有する。誤差調整処理部２５１ｂは、請求書発行先に関する複数の請求データの合計金額と、請求書発行先に関する入金済みの請求データの金額と、の差額が予め設定された誤差金額以内である場合に、請求データの合計金額が入金済みの金額と同額であるとみなして消込処理を行う（誤差調整処理）。すなわち、一括消込処理は、誤差調整処理を有する。例えば、図６に表した項番「３」のように、手数料負担が相手先（株式会社Ｃ）ではなく「自社」である場合であって、消込残「５２５」が予め設定された手数料誤差金額以内である場合には、誤差調整処理部２５１ｂは、消込残「５２５」が手数料誤差であると判断し、請求データの合計金額が入金済みの金額と同額であるとみなして消込処理を行う。

図８は、本実施形態の個別消込処理を説明する表である。
図９は、本実施形態の個別消込処理における請求データの設定を説明する表である。
図１０は、本実施形態の個別消込処理における入金データ１７３の設定を説明する表である。
なお、図９および図１０に示した表は、図６に関して前述した一括消込処理における請求データおよび入金データ１７３の設定に用いられてもよい。

個別消込処理部２５２は、図６に関して前述した一括消込処理において消し込みが行われずに残った複数の請求データのうちで未入金の請求データと入金済みの請求データとを手動で特定する（個別消込処理）。個別消込処理における請求データは、例えば、請求書発行先コード（得意先コード）と、請求書発行先名（得意先名）と、請求日と、入金予定日と、請求金額と、に関する情報を含む。個別消込処理における入金データ１７３は、振込依頼人名（請求書発行先カナ名）と、入金日と、入金額と、に関する情報を含む。

個別消込処理における請求データに含まれる情報は、利用者により適宜選択されてもよい。具体的には、個別消込処理における請求データに含まれる情報の順序および使用有無は、利用者により適宜行われてもよい。図９に表した例では、請求区分と、請求残の正負と、請求残（入金予定額）の絶対値と、入金予定日と、請求日と、請求書発行先コード（得意先コード）と、期日現金予定フラグと、に関する全ての情報が、この順序で個別消込処理における請求データとして使用される。

個別消込処理における入金データ１７３に含まれる情報は、利用者により適宜選択されてもよい。具体的には、個別消込処理における入金データ１７３に含まれる情報の順序および使用有無は、利用者により適宜行われてもよい。図１０に表した例では、相殺データと、入金残の正負と、入金日と、振込依頼人名（請求書発行先カナ名）と、仕向銀行と、仕向支店と、入金残の絶対値と、入金区分と、に関する全ての情報が、この順序で個別消込処理における入金データ１７３として使用される。

例えば、図６に表した項番「３」では、請求金額「１０，５００」のうちで、未入金額「５２５」と入金額「９，９７５」とが一括消込処理により自動的に特定されている。この場合において、請求金額「１０，５００」の全額が入金額として特定されているわけではない。そのため、一括消込処理において、「株式会社Ｃ」に関する請求データの消し込みは、行われずに残ったままである。

そこで、図８に表したように、図６に表した項番「３」については、個別消込処理部２５２が、複数の請求データのうちで、未入金の請求データと、入金済みの請求データと、を手動で特定することができる。具体的には、個別消込処理部２５２は、図８に表した項番１〜３の複数の請求データの中から、入金額「９，９７５」の範囲内で消し込みを行う請求データを手動で選択することができる。

このとき、学習履歴処理部２５３（図５参照）は、個別消込処理において消し込みが行われたパターンを学習して学習履歴として保存し、保存した学習履歴を一括消込処理に反映させる（学習履歴処理）。つまり、図６に関して前述した一括消込処理では、学習履歴処理において保存された学習履歴が参照され、請求データと入金データ１７３との照合に利用される。例えば、個別消込処理において消し込みが行われると、請求書発行先コード（図９参照）と、振込依頼人名（図１０参照）、仕向銀行（図１０参照）および仕向支店（図１０参照）の少なくともいずれかと、の間の照合履歴が学習履歴として保存される。そして、保存された学習履歴が、一括消込処理における照合処理の対象になる。

図８に表した例では、学習履歴処理部２５３は、項番１〜３の複数の請求データの中から、入金額「９，９７５」の範囲内で消し込みが行われた請求データのパターンを学習して学習履歴として保存する。そして、学習履歴処理部２５３は、保存された学習履歴を図６に関して前述した一括消込処理に反映させる。

本実施形態に係る照合プログラムＰＲＧによれば、学習履歴処理が実行されるため、一括消込処理および個別消込処理が実行されると、一括消込処理において請求データと入金データ１７３とを照合する精度が次第に向上する。これにより、複数の請求データと、複数の入金データ１７３と、の照合処理において効率の向上および精度の向上を図ることができる。

また、図５に関して前述したように、一括消込処理において、入金済みの請求データの金額が複数の請求データの合計金額よりも多い場合に過入金として表示する過入金表示処理が実行される。そのため、利用者は、過入金があったことを効率的に把握することができる。

ここで、図５に関して前述したように、個別消込処理部２５２は、前受金処理部２５２ｃを有する。前受金処理部２５２ｃは、請求書発行先に関する入金済みの請求データの金額が請求書発行先に関する複数の請求データの合計金額よりも多い場合に、入金済みの金額と請求データの合計金額との差額を前受金として処理する（前受金処理）。

例えば、図６に表した項番「６」では、請求金額「２３２，０００」のうちで、未入金額「−２，２８０」と入金額「２３４，２８０」とが一括消込処理により自動的に特定されている。この場合において、入金額「２３４，２８０」が請求金額「２３２，０００」よりも多いため、一括消込処理において、「株式会社Ｆ」に関する請求データの消し込みは、行われずに残ったままである。この場合において、前受金処理部２５２ｃは、入金済みの金額と請求データの合計金額との差額（過入金額）「２，２８０」を前受金として処理することができる。これにより、次回の照合処理において、前受金と請求データとの照合が可能になる。

また、図５に関して前述したように、一括消込処理において、複数の請求データの合計金額と、入金済みの請求データの金額と、の差額が予め設定された誤差金額以内である場合に、複数の請求データの合計金額と、入金済みの請求データの金額と、が互いに同額であるとみなして消込処理を行う誤差調整処理が実行される。すなわち、一括消込処理における消込残「５２５」が予め設定された手数料誤差金額以内である場合には、誤差調整処理部２５１ｂは、消込残「５２５」が手数料誤差であると判断する。そうすると、図８に表したように、一括消込処理における消込残「５２５」は、個別消込処理において手数料「５２５」として処理されている。そのため、請求データの合計金額が入金済みの金額と同額であるとみなして消込処理が実行される。これによれば、「株式会社Ｃ」に関する請求データの消し込みは、一括消込処理においてより確実に行われ、未処理のままで残ることを抑えられる。そのため、消込処理がより高い精度で実行される。

また、図５に関して前述したように、一括消込処理における照合順序が、請求書発行先ごとに割り振られた専用入金口座と、請求書発行先コードと、学習履歴と、請求書発行先カナ名と、の少なくともいずれかに対して設定される。そのため、利用者は、専用入金口座と、請求書発行先コードと、学習履歴と、請求書発行先カナ名と、のうちで照合順序を変更したり、照合項目の使用および不使用の適宜選択を行ったりして、一括消込処理における照合処理の効率向上および精度向上を図ることができる。

図１１は、本実施形態の消込シミュレーション処理を説明する表である。
図５に関して前述したように、個別消込処理部２５２は、消込シミュレーション処理部２５２ｂを有する。消込シミュレーション処理部２５２ｂは、請求書発行先に関する複数の請求データの合計金額が請求書発行先に関する入金済みの請求データの金額と一致しない場合に、複数の請求データの合計金額の中から入金済みの金額と一致する組み合わせを検出し候補として挙げる（消込シミュレーション処理）。すなわち、個別消込処理は、消込シミュレーション処理を有する。

例えば、図６に表した項番「２」では、請求金額「２，６８５，０００」のうちで、未入金額「１５５，０００」と入金額「２，５３０，０００」とが一括消込処理により自動的に特定されている。この場合において、請求金額「２，６８５，０００」の全額が入金額として特定されているわけではない。そのため、一括消込処理において、「株式会社Ｂ」に関する請求データの消し込みは、行われずに残ったままである。

そこで、図１１に表したように、個別消込処理部２５２が、図６に表した項番「２」についての個別消込処理を実行する。このとき、消込シミュレーション処理部２５２ｂは、複数の請求データの合計金額の中から入金済みの金額と一致する組み合わせを検出し候補として挙げる。図１１に表した例では、複数の請求金額「１，０００，０００」、「６３７，０００」、「５００，０００」、「３９３，０００」および「１５５，０００」の中から、入金額「２，５３０，０００」と一致する組み合わせ「１，０００，０００」、「６３７，０００」、「５００，０００」および「３９３，０００」が候補として挙げられている。挙げられた候補が問題ない場合には、利用者は、所定ボタンの押下などの所定の操作を行うことで消し込みを行うことができる。

これによれば、利用者は、消込シミュレーション処理の結果に問題がなければ、効率的に消込処理を行うことができる。また、消込シミュレーション処理部２５２ｂは、組み合わせを候補として挙げるため、個別消込処理において組み合わせを適宜組み替えることがでる。これにより、照合処理の効率向上を図ることができる。

図１２は、本実施形態の期日現金処理を説明する表である。
図１に関して前述したように、プログラム格納部２５は、期日現金処理部２５４を有する。期日現金処理部２５４は、期日現金の支払通知７（図１参照）に関する情報が入力されると、請求データと、入金データ１７３と、を照合し消込処理を行うとともに、支払通知７により通知された支払予定日を期日とする新たな請求データを自動的に生成する（期日現金処理）。

例えば、図１２に表したように、請求日「３月１０日」の請求書３１に対する支払通知７が４月３０日に到着した場合には、回収区分を「期日現金」とする消込処理が実行される。つまり、請求データと入金データ１７３との１回目の照合処理において、売掛金額（請求金額）残は、減額される。

さらに、支払通知７により通知された支払予定日（図１２に表した例では７月３１日）を期日とし、回収区分を「振込」とする新たな請求データが自動的に生成される。そして、請求データと入金データ１７３（現金振込データ）との２回目の照合処理が実行される。このように、支払通知７の回収日と、支払通知７により通知された支払予定日（期日）と、の２回にわたって消込処理が実行される。そのため、照合処理の効率向上および精度向上を図ることができる。

以上、本発明の実施形態について説明した。しかし、本発明は、上記実施形態に限定されず、特許請求の範囲を逸脱しない範囲で種々の変更を行うことができる。上記実施形態の構成は、その一部を省略したり、上記とは異なるように任意に組み合わせたりすることができる。

１…取引システム
１１…受発注システム
２１…顧客端末
２３…収納代行システム
２５…銀行システム
３９…取引決済照合部
４１…未照合取引特定部
４３…未照合決済特定部
４５…未収入請求生成部
４７…請求入金照合部
４９…未照合取引ステータス生成部
５１…新請求発行部
５３…未照合決済ステータス生成部
５５…未照合決済手動処理部
１４１…取引データ
１４３…決済データ
１７１…未収入請求データ
１７３…入金データ
２５１…一括消込処理部
２５１ａ…過入金表示処理部
２５１ｂ…誤差調整処理部
２５１ｃ…照合順序設定処理部
２５２…個別消込処理部
２５２ａ…誤差調整処理部
２５２ｂ…消込シミュレーション処理部
２５２ｃ…前受金処理部
２５３…学習履歴処理部
２５４…期日現金処理部

Claims (11)

1. 取引データと決済データとの第１の照合を行う取引決済照合工程と、
   前記第1の照合により、未照合の前記取引データを示す未照合取引データを特定する未照合取引特定工程と、
   前記第１の照合により、未照合である前記決済データを示す未照合決済データを特定する未照合決済特定工程と、
   前記第１の照合に成功した前記決済データを基に未収入請求データを生成する未収入請求生成工程と、
   前記未収入請求生成工程で生成した前記未収入請求データを含む複数の請求データと、複数の入金データとの第２の照合を行う請求入金照合工程と
   をコンピュータに実行させることを特徴とする照合プログラム。
2. 前記未照合取引特定工程で特定した前記未照合取引データについて、当該未照合取引データの削除、あるいはそれに対応する新たな請求データの発行を示す未照合取引ステータスデータを生成する未照合取引ステータス生成工程
   を前記コンピュータにさらに実行させる請求項１に記載の照合プログラム。
3. 前記未照合取引ステータス生成工程で生成した前記未照合取引ステータスデータが前記新たな請求データの発行を示す前記未照合取引データを基に、新たな請求データを発行する新請求発行工程
   を前記コンピュータにさらに実行させる請求項２に記載の照合プログラム。
4. 前記未照合決済特定工程で特定した前記未照合決済データについて、当該未照決済データに手動による取引データと対応付けを行うか否かを示す未照合決済ステータスデータを生成する未照合決済ステータス生成工程
   を前記コンピュータにさらに実行させる請求項１〜３のいずれかに記載の照合プログラム。
5. 前記未照合決済ステータス生成工程で生成した前記未照合決済ステータスデータが手動による取引データとの対応付けを行うことを示す前記未照合決済データを基に、手動による対応付け処理を行う未照合決済手動処理工程
   を前記コンピュータにさらに実行させる請求項４に記載の照合プログラム。
6. 前記未収入請求生成工程は、前記未照合決済手動処理で手動による対応付けを行った前記未照合決済データに対応する未収入請求を含む前記未収入請求データを生成する
   請求項５に記載の照合プログラム。
7. 受発注システムから前記取引データを入力する取引データ入力工程
   前記コンピュータにさらに実行させ、
   前記取引データの入力時には、当該取引データに係る売上は、当該取引に係る発注者への売掛金として管理する
   請求項１〜６のいずれかに記載の照合プログラム。
8. 前記未収入請求生成工程で生成した前記未収入請求データに係る未収入金は、前記決済データを発行した決済機関に対する未収入金として管理する
   請求項１〜７のいずれかに記載の照合プログラム。
9. 前記請求入金照合工程は、
   予め設定された照合順序に基づいて前記請求データと前記入金データとを照合し、前記複数の請求データのうちで未入金の前記請求データと入金済みの前記請求データとを自動的に特定する一括消込処理と、
   前記一括消込処理において消し込みが行われずに残った前記複数の請求データのうちで未入金の前記請求データと入金済みの前記入金データとを手動で特定する個別消込処理と、
   前記個別消込処理において消し込みが行われたパターンを学習して学習履歴として保存し、保存した前記学習履歴を前記一括消込処理に反映させる学習履歴処理と、
   を前記コンピュータに実行させる請求項１〜８のいずれかに記載の照合プログラム。
10. 期日現金の支払通知に関する情報が入力されると前記請求データと前記入金データとを照合し消込処理を行うとともに前記支払通知により通知された支払予定日を期日とする新たな請求データを自動的に生成する期日現金処理を前記コンピュータにさらに実行させることを特徴とする請求項１〜９のいずれかに記載の照合プログラム。
11. 取引データと決済データとの第１の照合を行う取引決済照合工程と、
    前記第1の照合により、未照合の前記取引データを示す未照合取引データを特定する未照合取引特定工程と、
    前記第１の照合により、未照合である前記決済データを示す未照合決済データを特定する未照合決済特定工程と、
    前記第１の照合に成功した前記決済データを基に未収入請求データを生成する未収入請求生成工程と、
    前記未収入請求生成工程で生成した前記未収入請求データを含む複数の請求データと、複数の入金データとの第２の照合を行う請求入金照合工程と
    をコンピュータに実行させることを特徴とするデータ照合方法。
    
    
    
    

Images