JP2016146166A - 入金管理システム、入金管理装置、入金管理方法および入金管理プログラム - Google Patents

Abstract

【課題】「ビルのオーナー会社とテナントとの間に管理会社が存在し、テナントから集金した賃料が管理会社からオーナー会社に一括で（総額で）振り込まれてくる」といった不動産賃貸管理の業務形態におけるオーナー会社での入金消込業務の効率を改善することができる入金管理システム等を提供することを課題とする。【解決手段】本実施形態では、オーナー会社のＰＣにおいて、ビル管理会社（テナントの管理会社）から送信される入金データに基づく入金総額と請求総額とが一致する場合には、自動入金消込を行い、入金総額と請求総額とが一致しない場合には、該当ビルの請求データを出力し、ビル管理会社（テナントの管理会社）のＰＣに対して送付する。【選択図】図５

Description

本発明は、入金管理システム、入金管理装置、入金管理方法および入金管理プログラムに関する。

不動産賃貸管理の業務形態として、「ビルのオーナー会社とテナントとの間に管理会社が存在し、テナントから集金した賃料が管理会社からオーナー会社に一括で（総額で）振り込まれてくる」といった業務形態が存在する。なお、特許文献１には、不動産賃料等の料金徴収支援システムが開示されている。

特開２００７−４１８０９号公報

しかしながら、上記業務形態におけるオーナー会社での入金消込業務について、効率化という観点で改善の余地が残されていた。

本発明は、上記問題点に鑑みてなされたものであって、上記業務形態におけるオーナー会社での入金消込業務の効率を改善することができる入金管理システム、入金管理装置、入金管理方法および入金管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る入金管理システムは、制御部と表示部を備えた物件管理装置と、制御部を備えた入金管理装置とを通信可能に接続した入金管理システムであって、前記入金管理装置の前記制御部は、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定手段と、前記判定手段で一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供手段と、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込手段と、を備え、前記物件管理装置の前記制御部は、前記入金管理装置から送信された前記入金チェックリストデータを前記表示部に表示させ、請求額について入金済みかをチェックさせるチェック手段を備えたこと、を特徴とする。

また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記管理データには、未入金残額が複数格納されており、前記比較対象額は、未入金残額の総額であり、前記消込手段は、前記判定手段で一致すると判定された場合、当該判定のときに用いられた前記比較対象額の基となった全ての未入金残額の消込処理を行うこと、を特徴とする。また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記比較対象額は、請求額と同じ未入金残額の総額であること、を特徴とする。また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記比較対象額は、請求額と同じで且つ同じ賃貸物件の未入金残額の総額であること、を特徴とする。

また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記管理データには、未入金残額が複数格納されており、前記比較対象額は、請求額と同じ未入金残額であり、前記消込手段は、前記判定手段で一致すると判定された場合、当該判定のときに用いられた前記比較対象額の基となった未入金残額の消込処理を行うこと、を特徴とする。

また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記管理データには、未入金残額と、テナントに対応する取引先コードであるテナントコードと、テナントの名寄せ先に対応する取引先コードである名寄せコードと、が複数格納されており、前記判定手段は、名寄せコードが同じ未入金残額を比較対象額の基とすること、を特徴とする。

また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記管理データには、未入金残額が複数格納されており、前記消込手段は、所定の消込優先順に従って、入金総額を上限として未入金残額の消込処理を行うこと、を特徴とする。また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記消込手段は、前記上限を超える原因となる未入金残額があるときは、当該未入金残額の一部の消込処理を行うこと、を特徴とする。また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記管理データには、未入金残額と、テナントに対応する取引先コードであるテナントコードと、テナントの名寄せ先に対応する取引先コードである名寄せコードと、が複数格納されており、前記消込手段は、名寄せコードが同じ未入金残額を消込対象とすること、を特徴とする。

また、本発明に係る入金管理システムは、前記入金管理システムにおいて、前記入金チェックリストデータは、前記チェック結果を入力するためのチェック欄を含むものであること、を特徴とする。

また、本発明に係る入金管理装置は、物件管理装置に通信可能に接続された、制御部を備えた入金管理装置であって、前記制御部は、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定手段と、前記判定手段で一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供手段と、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込手段と、を備えたことを特徴とする。

また、本発明に係る入金管理方法は、制御部と表示部を備えた物件管理装置と、制御部を備えた入金管理装置とを通信可能に接続した入金管理システムで実行される入金管理方法であって、前記入金管理装置の前記制御部で実行される、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、前記入金管理装置の前記制御部で実行される、前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、前記物件管理装置の前記制御部で実行される、前記入金管理装置から送信された前記入金チェックリストデータを前記表示部に表示させ、請求額について入金済みかをチェックさせるチェックステップと、前記入金管理装置の前記制御部で実行される、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、を含むことを特徴とする。

また、本発明に係る入金管理方法は、物件管理装置に通信可能に接続された、制御部を備えた入金管理装置で実行される入金管理方法であって、前記制御部で実行される、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、を含むことを特徴とする。

また、本発明に係る入金管理プログラムは、物件管理装置に通信可能に接続された、制御部を備えた入金管理装置に実行させるための入金管理プログラムであって、前記制御部に実行させるための、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、を含むことを特徴とする。

本発明によれば、「ビルのオーナー会社とテナントとの間に管理会社が存在し、テナントから集金した賃料が管理会社からオーナー会社に一括で（総額で）振り込まれてくる」といった不動産賃貸管理の業務形態におけるオーナー会社での入金消込業務の効率を改善することができる（具体的には、当該業務に掛かるオーナー会社の作業負担を軽減することができる）という効果を奏する。

図１は、入金処理の一例を示す図である。 図２は、入金管理装置の構成の一例を示すブロック図である。 図３は、入金消込処理の一例を示す図である。 図４は、入金消込処理の一例を示す図である。 図５は、入金消込処理の一例を示す図である。 図６は、アンマッチリストのデータイメージの一例を示す図である。 図７は、アンマッチリストのデータイメージの一例を示す図である。 図８は、入金消込処理の一例を示す図である。 図９は、入金消込処理の一例を示す図である。 図１０は、自動入金消込画面の一例を示す図である。 図１１は、マッチングパターンの一例を示す図である。 図１２は、マッチングパターンの一例を示す図である。 図１３は、マッチングパターンの一例を示す図である。 図１４は、マッチングパターンの一例を示す図である。 図１５は、マッチングパターンの一例を示す図である。 図１６は、マッチングパターンの一例を示す図である。 図１７は、取引先登録画面の一例を示す図である。

本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。

［１．概要］
不動産賃貸管理業務において、賃貸物件のオーナー会社とテナントとの間にビル管理会社が存在し、テナントから集金した賃料がビル管理会社からオーナー会社に一括で振り込まれてくる場合がある。具体的には、賃料の請求先は各テナントだが、この請求に対する入金は、ビル管理会社１本で銀行から振り込まれる場合がある。
そして、この場合、オーナー会社側では、ビル管理会社からの入金について、自動消込せずに人の判断で（手動で）消込登録する必要があり、その結果、消込業務に多くの時間が掛かっていた。
一方、請求先を各テナントでなくビル管理会社に設定すれば、オーナー会社側で自動消込することは可能だが、このような設定をすると、オーナー会社側で各テナントの収益把握をすることができなくなってしまう。
そして、これまで、入金消込業務の自動化と各テナントの収益把握という２つの要件を同時に満たす合理的な手法が存在しなかった。
そこで、ビル管理会社からの一括入金に対する自動消込に関する本実施形態では、ビル管理会社のコードを“まとめ入金先”としてマスタに設定しておくことで、請求先を各テナントとして設定した場合でも、オーナー会社側で、ビル管理会社からの一括入金に対する自動消込と各テナントの収益把握を両立できるようにしている。

また、本実施形態において、ビル管理会社からの入金がオーナー会社からの各テナントへの請求と合致していれば自動消込は行われるが、合致しなかったとき（入金総額≠請求総額）に自動消込は行われずに手動消込を要求する（例えば、１棟のビルのうち１テナントだけ入金が滞ったことが原因で「入金総額≠請求総額」という状況が発生したときに、入金を行ったテナントを含む全テナントについて手動消込を要求する）のでは、オーナー会社に「結局のところ、手動消込で対応していたこれまでと作業効率の点で然程の進展がない」と認識されることが想定される。
そこで、本実施形態では、以下の手順を実装することで、「入金総額≠請求総額」という状況が発生した場合における入金消込がより便利に実施できるようにしている。具体的には、オーナー会社において、全テナント分について手動消込を行うよりも大幅な作業削減が見込まれる。なお、ビル管理会社においては、多少の作業が求められることになるものの、入金詳細の報告を最終的にオーナー会社に行う必要がある実情を踏まえれば、この追加の作業により大きな負担増にはならない。また、ビル管理会社においては、オーナー会社はお客様であるが、求められる作業はオーナー会社の作業負担を削減することに寄与するものなので、オーナー会社の顧客満足を上げることが期待出来る。
［手順１］オーナー会社のＰＣは、「入金総額≠請求総額」（アンマッチ）だった場合に、該当するビルの全請求データ（明細レベル）を出力する。
［手順２］オーナー会社のＰＣは、手順１で出力された全請求データをビル管理会社に対して送付する。
［手順３］ビル管理会社のＰＣは、受け取った請求データに対して、どのテナントのどの費用項目分が入金されたのかをチェックさせ、そして、担当者は、チェックした結果を請求データに追加入力する。なお、ビル管理会社側では、一般的に、どのテナントのどの費用項目分が入金されたかを把握できている。
［手順４］ビル管理会社のＰＣは、手順３で追加入力が済んだ請求データをオーナー会社のＰＣに送付する。
［手順５］オーナー会社のＰＣは、手順４で送付された請求データを受け取り、データ取り込みを行う。
［手順６］オーナー会社のＰＣは、取り込んだデータのうち、最初に取り込んだアンマッチとなってしまった入金データと実際に入金があった請求データ（ビル管理会社にチェックを付けて貰った請求データ）とを比較して、金額が合致すれば自動入金消込を行う。
［手順７］手順６においてもアンマッチとなるような場合は、特殊な入金（もしくは請求）だと考えられるので、オーナー会社のＰＣは、手動入金消込の実施を要求する。なお、ほとんどの場合、手順６までで自動入金消込が実施出来る。

ここで、図１を参照して、本実施形態の処理概要について説明する。図１は、入金処理の一例を示す図である。オーナー会社のコンピュータに導入されている本実施形態に係るシステムは、ＥＢ（Ｅｌｅｃｔｒｏｎｉｃ Ｂａｎｋｉｎｇ）入金データ取込機能、入金登録機能、自動入金消込機能、及び入金消込登録機能を有している。ＥＢ入金データ取込機能は、銀行（具体的には銀行におけるビル管理会社の口座）からＥＢシステムを介して入金データファイル（例えば、全銀協のフォーマット（振込入金通知）を使用したもの）を取り込む機能である。システムは、入金関係の帳票として、例えば、入金登録チェックリスト、入金未消込リスト、入金消込リスト及び入金予定表などを出力することが可能である。ここで、入金登録チェックリストは、入金登録機能やＥＢ入金データ取込機能で作った入金データをチェックするための帳票である。入金未消込リストは、請求データとの消込がされていない入金データを確認するための帳票である（入金額の残や自動消込のアンマッチ理由なども確認できる）。入金消込リストは、消込した入金データと請求データを確認するための帳票である。入金予定表は、消込されていない請求データを確認する帳票である。
そして、システムは、登録されたＥＢ入金データに基づいて、ビル管理会社からの賃貸物件のＥＢ入金データと賃貸物件のテナントへの請求データとが一致するか否か判定（マッチング）を行う。そして、システムは、一致すると判定された場合、自動入金消込処理を行い、且つ、入金消込登録を行う。
このように、本実施形態においては、入金消込登録や自動入金登録といった機能を特徴としている。これら機能を作った背景として、「同一物件で管理会社等からオーナーに一括して入金があるケースが多く、オーナー側においてテナント単位での消込が難しかった」ことが挙げられる。また、任意組合からの入金の場合も、これと同様であった（この場合のテナントは、仮想テナントで、かつ、管理が差し引かれている）。
ここで、入金消込登録の機能では、取引先（請求先）コードを絞っての消込を標準としているが、この標準では、同一物件で管理会社等から一括して入金がある上記ケースのとき、１入金に対してテナント数分の呼出しを行って入金消込を行う必要があるので、手間が掛かることが想定される。そこで、入金消込登録の機能では、物件コードを絞って請求先を跨いでの消込も可能としている。
また、自動入金消込の機能では、異なる請求先ＣＤで振込カナ名が一致したときはカナ名重複エラーとすることを標準としているが、この標準では、１入金に複数テナント分の金額が合算で振込まれたとき、自動消込での判断が不可となるので、全て手動消込対象となってしまい手間が掛かることが想定される。そこで、自動入金消込の機能では、「請求先ＣＤが異なる同一振込カナ名」の請求データを名寄せして、出来る限り自動消込を可能としている。

［２．構成］
本実施形態に係る入金管理システムの構成の一例について、図２を参照して説明する。図２は、オーナー会社側の入金管理装置１００と、ビル管理会社側の賃貸物件管理装置４００と、を通信可能に接続した入金管理システムの構成の一例を示すブロック図である。

［入金管理装置１００の構成］
入金管理装置１００は、市販のデスクトップ型パーソナルコンピュータである。なお、入金管理装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。

入金管理装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。入金管理装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、入金管理装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、入金管理装置１００と他の装置（例えば、サーバ２００、賃貸物件管理装置４００、各テナントの端末装置、および／または、ＥＢシステム等）とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。なお、サーバ２００は、一般に市販されるワークステーション、または、パーソナルコンピュータ等の情報処理装置であってもよい。また、サーバ２００の各機能は、サーバ２００のハードウェア構成中のＣＰＵ、ディスク装置、メモリ装置、入力装置、出力装置、通信制御装置等およびそれらを制御するプログラム等により実現される。なお、後述する請求データファイル、入金データファイルおよび入金チェックリストデータなどをサーバ２００に保管してもよい。この場合、入金管理装置１００は、サーバ２００から必要なデータを適宜取得してもよい。

記憶部１０６には、各種のデータベース、テーブル、及びファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。記憶部１０６は、請求データファイル１０６ａ（本発明の管理データに相当）と入金データファイル１０６ｂ（本発明の入金データに相当）とを備えている。なお、上述した入金関係の帳票に関するデータは記憶部１０６に記憶されてもよい。

請求データファイル１０６ａは、テナントへの請求額に対する未入金残額などをビル単位で記憶するファイルである。ここで、請求データファイル１０６ａは、例えば、賃貸物件の名称、テナントへ発行した請求書の識別番号、テナントへの請求額、当該請求額から消し込まれた額である消込済額、及び当該請求額に対し入金されていない額である未入金残額などに関するデータを格納可能なものであってもよい。また、請求データファイル１０６ａは、例えば、入金予定日、請求書の識別番号、当該請求書に含まれる請求項目の行番号、当該請求項目、請求額、消込済額、及び未入金残額などに関するデータを格納可能なものであってもよい。また、請求データファイル１０６ａは、例えば、賃貸物件の名称、請求書の識別番号、請求額、消込済額、未入金残額、テナントの識別コード、当該テナントの名称、当該テナントの読み仮名、及び当該テナントの名寄せ先の識別コードなどのデータを格納可能なものであってもよい。

入金データファイル１０６ｂは、複数の賃貸物件を含むビルに含まれる賃貸物件のテナントからの入金額に基づく当該ビル単位の入金総額を記憶するファイルである。ここで、入金データファイル１０６ｂは、例えば、ビル単位の入金総額などに関するデータを格納可能なものであってもよい。また、入金データファイル１０６ｂは、例えば、代表となる請求先（名寄せ先）の読み仮名及び入金総額などに関するデータを格納可能なものであってもよい。なお、入金データファイル１０６ｂは、例えば、全銀協のフォーマット（振込入金通知）を使用したものであってもよい。

入出力インターフェース部１０８には、入力装置１１２及び出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。

制御部１０２は、入金管理装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、機能概念的に、入金判定部１０２ａ（本発明の判定手段に相当）とリストデータ作成部１０２ｂ（本発明の提供手段に相当）と入金消込部１０２ｃ（本発明の消込手段に相当）とを備えている。

入金判定部１０２ａは、請求データファイル１０６ａ及び入金データファイル１０６ｂに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う。ここで、比較対象額として、例えば、未入金残額の総額を設定してもよい。また、比較対象額として、例えば、請求額と同じ未入金残額（換言すると、一度も消込が行われてない未入金残額）の総額を設定してもよい。また、比較対象額として、例えば、請求額と同じで且つ同じ賃貸物件の未入金残額の総額を設定してもよい。また、比較対象額として、例えば、請求額と同じ未入金残額を設定してもよい（この設定を採用する場合、「一致する」と判定されればその時点で処理を終了してもよい）。
また、後述する入金消込部１０２ｃで所定の消込優先順による消込処理が行われる場合には、入金判定部１０２ａは、請求データファイル１０６ａから未入金残額を所定の消込優先順に従って１つずつ指定しながら、当該指定を行う毎に、これまでに指定された未入金残額の総額を比較対象額として設定して当該比較対象額が入金総額を超えるか否かを判定してもよい。また、同場合には、入金判定部１０２ａは、（１）入金総額を所定の変数に初期値としてセットし、（２）請求データファイル１０６ａから未入金残額を所定の消込優先順に従って一つずつ指定しながら、当該指定を行う度に、指定された未入金残額を比較対象額として当該比較対象額が当該変数で特定される額以下であるか否かを判定し、「以下である」と判定されたときは当該変数で特定される額から当該比較対象額の基となった未入金残額を減算して当該変数を更新し、（３）「以下でない」と判定されるまで当該判定及び当該更新を繰り返してもよい。なお、所定の消込優先順は、例えば取引先毎に定められた消込の優先順序に関するものであり、例えば入金予定日や請求書Ｎｏ、行Ｎｏ、物件コード、管理項目コードなどの昇順又は降順や管理項目の印字順などを基準として設定された順序に関するものであってもよい。
また、入金判定部１０２ａは、名寄せコード（名寄せ先の識別コード）が同じ未入金残額を比較対象額の基として、上述した処理を行ってもよい。
入金判定部１０２ａが実施する処理の具体例については、以下の［３．処理の具体例］にて詳細に説明する。

リストデータ作成部１０２ｂは、請求データファイル１０６ａ等に基づいて、賃貸物件についての入金チェックリストデータを作成し、作成した入金チェックリストデータを賃貸物件管理装置４００に送信する。ここで、入金チェックリストデータは、ビルの識別コード、ビルの名称、テナントの識別コード、テナントの名称、請求に係る費目のコード、当該費目の名称、当該費目のテナントへの請求額、テナントへ発行した請求書の発行日、入金予定日、及び入金済みかのチェック結果（例えば、入金済みであることを意味する予め定義した所定の番号（例えば１など）など）などのデータを格納可能なものであってもよい。リストデータ作成部１０２ｂが実施する処理の具体例については、以下の［３．処理の具体例］にて詳細に説明する。

入金消込部１０２ｃは、請求データファイル１０６ａに格納されている未入金残額について入金消込処理を行う。
なお、入金消込部１０２ｃは、入金済みかのチェック結果が反映されている賃貸物件管理装置４００から送信された入金チェックリストデータに基づいて、入金消込処理を行ってもよい。
また、入金消込部１０２ｃは、入金判定部１０２ａにより「一致する」と判定された場合、入金消込処理を行ってもよい。具体的には、入金消込部１０２ｃは、当該判定のときに用いられた比較対象額の基となった全ての未入金残額の消込処理を行ってもよい。また、入金消込部１０２ｃは、当該判定のときに用いられた比較対象額の基となった未入金残額の消込処理を行ってもよい。
また、入金消込部１０２ｃは、所定の消込優先順に従って、入金総額を上限として未入金残額の消込処理を行ってもよい。例えば、入金判定部１０２ａにより「超える」と判定された場合、入金消込部１０２ｃは、当該判定の直前の判定のときに用いられた比較対象額の基となった全ての未入金残額の消込処理を行ってもよい。また、入金判定部１０２ａにより「以下である」と判定された場合、入金消込部１０２ｃは、当該判定のときに用いられた比較対象額の基となった未入金残額の消込処理を行ってもよい。また、入金消込部１０２ｃは、上限を超える原因となる未入金残額があるときは、当該未入金残額の一部の消込処理を行ってもよい。例えば、入金判定部１０２ａにより「超える」と判定された場合、入金消込部１０２ｃは、当該判定の原因となった未入金残額の一部の消込処理を行ってもよい。また、入金判定部１０２ａにより「以下でない」と判定された場合、入金消込部１０２ｃは、当該判定のときに用いられた比較対象額の基となった未入金残額の一部の消込処理を行ってもよい。なお、これらの一部消込処理については、例えば、この処理の実行を制御するためのフラグとしての数値（１：実行しない、２：実行する）を消込単位で記憶する所定のマスタを参照して、その実行を制御してもよい。
また、入金消込部１０２ｃは、名寄せコード（名寄せ先の識別コード）が同じ未入金残額を消込対象として、上述した処理を行ってもよい。
入金消込部１０２ｃが実施する処理の具体例については、以下の［３．処理の具体例］にて詳細に説明する。

［賃貸物件管理装置４００の構成］
賃貸物件管理装置４００は、一般に市販されるワークステーションまたはパーソナルコンピュータ等の情報処理装置であってもよい。

賃貸物件管理装置４００は、制御部４０２と通信インターフェース部４０４と記憶部４０６と入力装置１１２及び出力装置１１４が接続されている入出力インターフェース部４０８と、を備えている。賃貸物件管理装置４００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部４０４は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、賃貸物件管理装置４００をネットワーク３００に通信可能に接続する。通信インターフェース部４０４は、他の装置（例えば、サーバ２００、入金管理装置１００、各テナントの端末装置、および／または、ＥＢシステム等）と通信回線を介してデータを通信する機能を有する。

記憶部４０６には、各種のデータベース、テーブル、及びファイルなどが格納される。記憶部４０６には、ＯＳと協働してＣＰＵに命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部４０６として、例えば、ＲＡＭ・ＲＯＭ等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。記憶部４０６は、入金データファイル４０６ａを備えている。なお、入金データファイル４０６ａの説明については、上述した入金データファイル１０６ｂと重複するので省略する。記憶部４０６は、入金管理装置１００から送信された入金チェックリストデータを記憶してもよい。

入出力インターフェース部４０８には、入力装置４１２及び出力装置４１４が接続されている。出力装置４１４には、モニタの他、スピーカやプリンタを用いることができる。入力装置４１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。

制御部４０２は、賃貸物件管理装置４００を統括的に制御するＣＰＵ等である。制御部４０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部４０２は、機能概念的に、チェック部４０２ａ（本発明のチェック手段に相当）を備えている。

チェック部４０２ａは、入金管理装置１００から送信された入金チェックリストデータを出力装置４１４に表示させることにより、ビル管理会社の担当者に各テナントの入金チェックを行わせ、テナントの入金チェックが完了した入金チェックリストデータを入金管理装置１００に送信する。チェック部４０２ａが実施する処理の具体例については、以下の［３．処理の具体例］にて詳細に説明する。

［３．処理の具体例］
本実施形態で行われる処理の具体例について、図３から図１７を参照して説明する。

ここで、図３から図９を参照して、金額アンマッチ（入金総額≠請求総額）だった場合における入金消込処理の一例について説明する。図３、図４、図５、図８、および、図９は、入金消込処理の一例を示す図である。

まず、図３に示すように、ビルオーナーは、ビルの各テナント（テナントＡ、テナントＢ、テナントＣおよびテナントＤ）に対して、請求を行う（ステップＳＡ−１）。なお、本説明では、テナントＡへの請求額は４００円、テナントＢへの請求額は３００円、テナントＣへの請求額は２００円、テナントＤへの請求額は１００円とする。

つぎに、図４に示すように、ビルの各テナントからビル管理会社にＥＢシステムで入金が行われ（本説明では、テナントＡ、テナントＣおよびテナントＤからそれぞれ、請求額に相当する４００円、２００円および１００円が入金され、テナントＢからは入金がされなかったものとする。）、そして、ビル管理会社からビルオーナーにＥＢシステムで入金が行われると（本説明では、入金があったテナントからの入金額の総額である７００円が入金されたものとする。）、ビルオーナーは入金管理装置１００にビル管理会社からの入金額（本説明では７００円）を取り込ませ、入金判定部１０２ａは、取り込まれたビル管理会社からの入金額と各テナントＡ〜Ｄへの請求額の総額とが一致するか否かを判定する（ステップＳＡ−２）。

つぎに、入金判定部１０２ａにより「一致する」と判定された場合（ステップＳＡ−２：Ｙｅｓ）、入金消込部１０２ｃは入金消込処理を実施する。なお、本実施形態の入金消込処理については、後述の図１０から図１７にて詳細に説明する。

一方、入金判定部１０２ａにより「一致しない（アンマッチ）」と判定された場合（ステップＳＡ−２：Ｎｏ）、図５に示すように、リストデータ作成部１０２ｂは、該当するビルの全テナントの賃貸物件を対象として入金チェックリストデータ（アンマッチリストデータ）を作成（出力）し、アンマッチリストデータを電子メール等でビル管理会社の賃貸物件管理装置４００に送信する（ステップＳＡ−３）。なお、本説明では、テナントＢからの入金がされなかったことにより１，０００円の請求に対して７００円の入金しかされなかったものとしているため、入金判定部１０２ａでは「アンマッチ」と判定されることになる。また、リストデータ作成部１０２ｂは、入金済チェック欄（ビル管理会社が、入金が既に行われた明細については「１」を入力させるための入力欄）を含む図６や図７に示すような入金チェックリストデータを作成してもよい。

つぎに、図８に示すように、チェック部４０２ａは、入金管理装置１００から送信されたアンマッチリストデータを出力装置４１４に表示させ、そしてビル管理会社の担当者にテナントの入金チェックを実行させ、テナントの入金チェック（入金済みチェック）が完了したアンマッチリストデータ（チェック済アンマッチリストデータ）を入金管理装置１００に電子メール等で送信（送付）する（ステップＳＡ−４）。ここで、各テナントの各費用項目に対する入金額に関するデータが賃貸物件管理装置４００に保管されている場合、チェック部４０２ａは、アンマッチリストデータに対し行うべき入金済みチェックを、当該保管されている入金額に関するデータを参照して自動で行ってもよい（さらに、自動で行われた入金済みチェックの結果の確認を担当者に促すようにしてもよい）。

つぎに、図９に示すように、入金消込部１０２ｃは、賃貸物件管理装置４００から送信されたチェック済アンマッチリストデータを取り込み、チェック済アンマッチリストデータに基づいて、入金消込処理を再度実施する（ステップＳＡ−５）。なお、チェック済アンマッチリストデータ（テーブル）において、入金済チェック欄に「１」が入力されているデータ（レコード）については、入金があったものと見做す（要するに消込済データとして扱う）。

上記ステップＳＡ−１からステップＳＡ−５の処理により、ビル管理会社からビルオーナーへの入金とビルオーナーからテナントへの請求とがアンマッチだった場合におけるビルオーナーの入金消込の手間が削減される。なお、それでも尚、未収のテナントについては、ビルオーナーは「手動」入金消込を実施してもよい。なお、未収となった場合の翌月以降の処理について、例えば、ある月の入金予定に対して未収となったテナントに対しては、未収分も含めて翌月以降の入金消込処理を実施してもよい。そして、引き続いて未収が続くようなテナントに対しては、例外運用なので手動での消込処理を実施してもよい。

ここで、図１０から図１７を参照して、本実施形態における入金消込処理の一例について説明する。図１０は、自動入金消込画面の一例を示す図である。図１１から図１６は、マッチングパターンの一例を示す図である。図１７は、本実施形態における取引先登録画面の一例を示す図である。

図１０に示すように、自動入金消込画面を介して、入金登録やＥＢ入金データ取込でできた入金データを使用して、未入金の請求データに対して自動で消込を行う。具体的には、入金日の欄に入金データの入金日を入力し、請求日の欄に消込対象とする請求データを絞るための日付を入力する。これにより、入力した日付までの請求データが消込対象となる。例えば、未入金の請求データとして以下の（１）と（２）がある場合において、請求日の欄に２０＊＊／０５／１０が入力されたとき、下記（１）のデータは消込の対象となるが、下記（２）のデータは消込の対象外となる。
（１）請求書発行日：２０＊＊／０５／１０（金額：１，０５０）
（２）請求書発行日：２０＊＊／０５／２５（金額：２，１００）

つぎに、図１１から図１６を参照して、本実施形態の自動消込（自動入金消込）の機能について説明する。自動消込では、１件の入金に対して、図１１から図１６のパターンで自動マッチングを行い、金額が一致した場合に消し込みを行う（一致しなかった際には全請求データ（明細データ）を出力してもよい。）。また、本自動消込の機能では、図１１から図１６のパターンのどのパターンをどの順序で使用するかを選択することができる。なお、自動消込では、入金の振込カナ名が、請求先マスタの振込カナ名と一致することを前提としてもよい。

図１１に示すように、入金判定部１０２ａが、賃貸物件（物件Ａおよび物件Ｂ）の入金額（１，０００，０００円）と、テナントへの請求に対する未入金残額の全合計額とが一致すると判定した場合、入金消込部１０２ｃは自動消込を行ってもよい。すなわち、図１１に示すマッチングパターンでは、入金額とのマッチング判定を行う対象を、未入金残（請求残）全て（請求書Ｎｏ．１の未入金残４００，０００円、請求書Ｎｏ．２の未入金残３００，０００円、請求書Ｎｏ．３の未入金残２００，０００円および請求書Ｎｏ．４の未入金残１００，０００円の総額）としている。

また、図１２に示すように、入金判定部１０２ａが、賃貸物件（物件Ａおよび物件Ｂ）の入金額（１，０００，０００円）と、テナントへの請求に対する未入金残額であって消込が一度もされていないものの全合計額とが一致すると判定した場合、入金消込部１０２ｃは自動消込を行ってもよい。すなわち、図１２に示すマッチングパターンでは、入金額とのマッチング判定を行う対象額を、一度も消込されていない未入金残（請求残）全て（請求書Ｎｏ．１の未入金残６００，０００円、請求書Ｎｏ．２の未入金残３００，０００円および請求書Ｎｏ．４の未入金残１００，０００円の総額）としている。

また、図１３に示すように、入金判定部１０２ａが、賃貸物件（物件Ａおよび物件Ｂ）の入金額（１，０００，０００円）と、テナントへの請求に対する未入金残額であって消込が一度もされていないものの各々とが一致すると判定した場合、入金消込部１０２ｃは自動消込を行ってもよい。すなわち、図１３に示すマッチングパターンでは、入金額とのマッチング判定を行う対象額を、一度も消込されていない未入金残の各々（請求書Ｎｏ．１の未入金残６００，０００円、請求書Ｎｏ．２の未入金残３００，０００円および請求書Ｎｏ．４の未入金残１，０００，０００円の各々）としている。

また、図１４に示すように、入金判定部１０２ａが、賃貸物件（物件Ａおよび物件Ｂ）の入金額（１，０００，０００円）と、テナントへの請求に対する未入金残であって消込が一度もされておらず且つ同じ物件のものの全合計額とが一致すると判定された場合、入金消込部１０２ｃは自動消込を行ってもよい。すなわち、図１４に示すマッチングパターンでは、入金額とのマッチング判定を行う対象額を、一度も消込されていない物件単位の未入金残（請求残）全て（物件Ａに係る請求書Ｎｏ．１の未入金残４００，０００円および請求書Ｎｏ．２の未入金残３００，０００円の総額並びに物件Ｂに係る請求書Ｎｏ．４の未入金残１，０００，０００円）としている。

また、図１５に示すように、入金消込部１０２ｃは、賃貸物件の入金額（１，０００，０００円）の範囲内で、所定の消込優先順に、テナントへの請求に対する未入金残（本説明では、図１５に示す上から５つの未入金残の各々）の自動消込を行ってもよい。ここで、取引先ごとに、以下の［１］から［６］に示す消込優先順の中から所望のものを選択してもよい。なお、図１５に示す消込パターンは［１］の消込優先順での消込に相当する。
［１］入金予定日＞請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、入金予定日が早いものを優先し、入金予定日が同一の場合は請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
［２］入金予定日＞物件コード＞請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、入金予定日が早いものを優先し、入金予定日が同一の場合は物件コードが小さいものを優先し、物件コードが同一の場合は請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
［３］請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
［４］物件コード＞請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、物件コードが小さいものを優先し、物件コードが同一の場合は請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
［５］管理項目印字順＞管理項目コード＞入金予定日＞請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、管理項目印字順が早いものを優先し、管理項目印字順が同一の場合は管理項目コードが小さいものを優先し、管理項目コードが同一の場合は入金予定日が早いものを優先し、入金予定日が同一の場合は請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
［６］管理項目印字順＞管理項目コード＞入金予定日＞物件コード＞請求書Ｎｏ＞行Ｎｏ（未入金残の消込は、管理項目印字順が早いものを優先し、管理項目印字順が同一の場合は管理項目コードが小さいものを優先し、管理項目コードが同一の場合は入金予定日が早いものを優先し、入金予定日が同一の場合は物件コードが小さいものを優先し、物件コードが同一の場合は請求書Ｎｏが小さいものを優先し、請求書Ｎｏが同一の場合は行Ｎｏが小さいものを優先する。）
また、入金消込部１０２ｃは、選択された消込優先順で請求データテーブルのレコードを並べ替え（図１５に示す請求データテーブルは、［１］の消込優先順で並べ替えられた後のものの一例である。）、並び替え後のテーブルの上から１番目のレコードから順に、賃貸物件の入金額（１，０００，０００円）の範囲で消し込みできる分まで、未入金残の消込を行ってもよい。なお、図１５に示す例では、消し込まれた未入金残の合計が９５０，０００円となるので、残りの５０，０００円は仮受入金としてもよい。ただし、この残りの額についても一部消込を行うように設定しておくことで、仮受を作らないようにすることも可能である。例えば、図１５を例とすると、入金予定日が２０＊＊／８／３１の共益費を５０，０００円分消し込むことで、仮受を作らないようにすることも可能である。なお、当該設定は、コントロールマスタの自動消込単位で決定してもよい（１：明細（一部消込しない）、２：金額（一部消込する））。

また、図１６に示すように、入金判定部１０２ａが、賃貸物件の（物件Ａおよび物件Ｂ）の入金額（１，０００，０００円）と、テナント（テナントＡ、テナントＢおよびテナントＣ）の名寄せ先（図１６の例では、取引先コードが「Ａ０００１」の取引先名「オー」）への請求に対する未入金残とが一致すると判定した場合、入金消込部１０２ｃは自動消込を行ってもよい。なお、図１６に示すパターンは、図１１に示すパターンに、「名寄せコードが同じ未入金残」という条件を追加してカスタマイズしたものに相当する。なお、図１２から図１５に示す各パターンに、この条件を追加してカスタマイズすることも可能である。すなわち、このカスタマイズは、取引先コードではなくてＥＢ名寄せコードで消込判断を行うことを意図したものである。なお、振込手数料が発生する場合、名寄せ先の代表となる請求先にあててもよい。また、名寄せについては、代表となる取引先に対する債権（請求データ）が存在しなくても消込を可能としてもよい。
なお、名寄せコードについては、例えば、図１７に示す取引先登録画面の請求先タブ項目にＥＢ入金名寄せコード（ＥＢ名寄せコード）を入力するための欄を追加し、この欄で、名寄せ先となる取引先コードを登録しておくことで、各テナントの取引先コードと名寄せ先の取引先コードの紐付けを行ってもよい。なお、ＥＢ名寄せコードが設定されていない場合、標準機能に準拠した自動入金消込処理を実施し、ＥＢ名寄せコードが設定されている場合、ＥＢ名寄せコードを基準とした自動入金消込処理（消込ロジックは標準機能と同等）を実施するように制御してもよい。また、本実施形態においては、振込手数料が発生した場合、名寄せ先の代表となる請求先にあてることができる。

［４．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、入金管理装置１００及び賃貸物件管理装置４００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、入金管理装置１００が備える処理機能、特に制御部１０２にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて入金管理装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、入金管理装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。

また、入金管理装置１００や賃貸物件管理装置４００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、入金管理装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、特に、「ビルのオーナー会社とテナントとの間に管理会社が存在し、テナントから集金した賃料が管理会社からオーナー会社に一括で（総額で）振り込まれてくる」といった不動産賃貸管理の業務形態などにおいて有用である。

１００ 入金管理装置
１０２ 制御部
１０２ａ 入金判定部
１０２ｂ リストデータ作成部
１０２ｃ 入金消込部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 請求データファイル
１０６ｂ 入金データファイル
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク
４００ 賃貸物件管理装置
４０２ 制御部
４０２ａ チェック部
４０４ 通信インターフェース部
４０６ 記憶部
４０６ａ 入金データファイル
４０８ 入出力インターフェース部
４１２ 入力装置
４１４ 出力装置

Claims (14)

1. 制御部と表示部を備えた物件管理装置と、制御部を備えた入金管理装置とを通信可能に接続した入金管理システムであって、
   前記入金管理装置の前記制御部は、
   複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定手段と、
   前記判定手段で一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供手段と、
   入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込手段と、
   を備え、
   前記物件管理装置の前記制御部は、
   前記入金管理装置から送信された前記入金チェックリストデータを前記表示部に表示させ、請求額について入金済みかをチェックさせるチェック手段
   を備えたこと、
   を特徴とする入金管理システム。
2. 前記管理データには、未入金残額が複数格納されており、
   前記比較対象額は、未入金残額の総額であり、
   前記消込手段は、前記判定手段で一致すると判定された場合、当該判定のときに用いられた前記比較対象額の基となった全ての未入金残額の消込処理を行うこと、
   を特徴とする請求項１に記載の入金管理システム。
3. 前記比較対象額は、請求額と同じ未入金残額の総額であること、
   を特徴とする請求項２に記載の入金管理システム。
4. 前記比較対象額は、請求額と同じで且つ同じ賃貸物件の未入金残額の総額であること、
   を特徴とする請求項３に記載の入金管理システム。
5. 前記管理データには、未入金残額が複数格納されており、
   前記比較対象額は、請求額と同じ未入金残額であり、
   前記消込手段は、前記判定手段で一致すると判定された場合、当該判定のときに用いられた前記比較対象額の基となった未入金残額の消込処理を行うこと、
   を特徴とする請求項１に記載の入金管理システム。
6. 前記管理データには、未入金残額と、テナントに対応する取引先コードであるテナントコードと、テナントの名寄せ先に対応する取引先コードである名寄せコードと、が複数格納されており、
   前記判定手段は、名寄せコードが同じ未入金残額を比較対象額の基とすること、
   を特徴とする請求項１から５のいずれか１つに記載の入金管理システム。
7. 前記管理データには、未入金残額が複数格納されており、
   前記消込手段は、所定の消込優先順に従って、入金総額を上限として未入金残額の消込処理を行うこと、
   を特徴とする請求項１に記載の入金管理システム。
8. 前記消込手段は、前記上限を超える原因となる未入金残額があるときは、当該未入金残額の一部の消込処理を行うこと、
   を特徴とする請求項７に記載の入金管理システム。
9. 前記管理データには、未入金残額と、テナントに対応する取引先コードであるテナントコードと、テナントの名寄せ先に対応する取引先コードである名寄せコードと、が複数格納されており、
   前記消込手段は、名寄せコードが同じ未入金残額を消込対象とすること、
   を特徴とする請求項７又は８に記載の入金管理システム。
10. 前記入金チェックリストデータは、前記チェック結果を入力するためのチェック欄を含むものであること、
    を特徴とする請求項１から９のいずれか１つに記載の入金管理システム。
11. 物件管理装置に通信可能に接続された、制御部を備えた入金管理装置であって、
    前記制御部は、
    複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定手段と、
    前記判定手段で一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供手段と、
    入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込手段と、
    を備えたことを特徴とする入金管理装置。
12. 制御部と表示部を備えた物件管理装置と、制御部を備えた入金管理装置とを通信可能に接続した入金管理システムで実行される入金管理方法であって、
    前記入金管理装置の前記制御部で実行される、複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、
    前記入金管理装置の前記制御部で実行される、前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、
    前記物件管理装置の前記制御部で実行される、前記入金管理装置から送信された前記入金チェックリストデータを前記表示部に表示させ、請求額について入金済みかをチェックさせるチェックステップと、
    前記入金管理装置の前記制御部で実行される、入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、
    を含むことを特徴とする入金管理方法。
13. 物件管理装置に通信可能に接続された、制御部を備えた入金管理装置で実行される入金管理方法であって、
    前記制御部で実行される、
    複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、
    前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、
    入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、
    を含むことを特徴とする入金管理方法。
14. 物件管理装置に通信可能に接続された、制御部を備えた入金管理装置に実行させるための入金管理プログラムであって、
    前記制御部に実行させるための、
    複数の賃貸物件を含む集合物件に含まれる賃貸物件のテナントからの入金額に基づく当該集合物件単位の入金総額に関する入金データ及びテナントへの請求額に対する未入金残額が格納されている管理データに基づいて、未入金残額に基づく比較対象額と入金総額が一致するか否かの判定を行う判定ステップと、
    前記判定ステップで一致しないと判定された場合、請求額について入金済みかをチェックさせるための入金チェックリストデータを前記管理データに基づいて作成し、作成した当該入金チェックリストデータを前記物件管理装置に送信する提供ステップと、
    入金済みかのチェック結果が反映されている前記物件管理装置から送信された前記入金チェックリストデータに基づいて、未入金残額の消込処理を行う消込ステップと、
    を含むことを特徴とする入金管理プログラム。

Images