JP2002049880A - 料金照合システムおよびそのプログラム記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 収納したはずの金額と実際の口座への入金額
とを自動的に突合処理することにより，確実に運用可能
な資金を把握できるようにする。 【解決手段】 支払者が支払った請求書に付随する払込
票から得た入金情報を入力し，資金決済マスタ12を更新
する一方，支払われた料金について実際に企業の口座に
入金された口座入金額の情報を口座照会通知センタから
入力し，入出金マスタ10を更新する。この資金決済マス
タ12に格納された入金情報と，入出金マスタ10に格納さ
れた口座入金額とを入金情報突合処理手段14により照合
してチェックし，チェックした結果を結果出力手段19に
より出力する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，請求書に付随する
払込票にもとづき金融機関等の委託契約窓口や企業の支
店において実際に収納したはずの金額と，実際の口座へ
の入金額とを照合するシステムに関する。

【０００２】

【従来の技術】例えば，電話会社では，収納すべき金額
を記した請求書等を利用者に送付し，利用者が口座振替
やコンビニエンスストアの窓口，各支店の窓口などでそ
の請求金額を支払うことにより，電話料金を回収し，こ
の回収した資金を資金運用部門へ回して運用することが
行われている。このため，自社口座に振り込まれた実際
の金額と収納すべき金額とをいち早く確認して，運用資
金額を確定する必要がある。

【０００３】図２４は，従来の収納処理の流れを説明す
るための図である。図２４では，電話料金の収納を例に
する。電話料金の収納方法は，銀行，郵便局等の金融機
関窓口での現金収納，口座振替，支店窓口での現金収
納，コンビニエンスストアなど委託窓口での現金収納な
どがある。また，電話のサービス契約の形態により様々
な収納方法がある。ここでは，説明を簡略化するため，
銀行窓口での現金収納および支店窓口での現金収納につ
いて説明する。

【０００４】まず，利用者は，払込票が添付された請求
書１１０により，銀行／郵便局１２０の窓口で，払込票
とともに料金を支払う。銀行／郵便局１２０では，支払
われた代金１２１を払込先の金融機関１３０の口座１２
２へ振り替える。払込先の金融機関１３０では，口座１
２２の入出金明細１２３を口座照会通知センタ１４０へ
送付する。

【０００５】口座照会通知センタ１４０は，例えば
（株）ＮＴＴデータが提供する銀行ＡＮＳＥＲの管理セ
ンタであり，利用者からの口座照会要求に対して金融機
関１３０に問い合わせを行い，金融機関１３０から送信
された入出金明細１２３を口座照会情報１２４として通
知する機能を持つ。

【０００６】さらに，銀行／郵便局１２０では，利用者
の持参した請求書１１０の払込票の部分を回収し，払込
票に記載された払込人名，払込金額のデータに，銀行／
郵便局名，口座番号，払込日時等のデータを付与し，こ
れらのデータを収納情報１３１として，料金計算サービ
スセンタ１８０へ送信する。

【０００７】一方，支店／コンビニ１６０では，代金１
２５を支店（経理部）１７０の資金１２６へ送金し，支
店（経理部）１７０では，資金１２６の出納情報１２７
を本社（資金運用部）１００へ送信する。さらに，支店
／コンビニ１６０では，銀行／郵便局１２０の窓口での
収納情報１３１と同様の収納情報１３４を料金計算サー
ビスセンタ１８０へ送信する。

【０００８】料金計算サービスセンタ１８０では，請求
書１１０を発行した顧客ごとに請求形態，請求金額，支
払期限，消込区分等を料金管理情報１３２によって管理
しており，支店／コンビニ１６０から送信された収納情
報１３４と，銀行／郵便局１２０から送信された収納情
報１３１とを，料金管理情報１３２に反映させる。さら
に，この料金管理情報１３２に対して消込み処理を行
い，入金通知書情報１３３を生成する。入金通知書情報
１３３は，収納されたはずの収納金額，正常収納の件数
および金額，異常収納の件数および金額等の情報であ
る。

【０００９】本社（資金運用部）１００では，口座照会
通知センタ１４０に対して口座照会を行い，口座照会情
報１２４を取得する。また，料金計算サービスセンタ１
８０から入金通知書情報１３３を取得する。資金運用担
当者は，口座照会情報１２４の実際の口座入金額および
支店（経理部）１７０から受け取った出納情報１２７
と，入金通知書情報１３３の正常収納金額および異常収
納金額とを突き合わせて，正常に収納して実際に資金運
用可能な金額を確認する。従来，以上のような料金の収
納処理が行われていた。

【００１０】

【発明が解決しようとする課題】図２４に示す例におい
て，収納すべき金額が１００万円であるのに，例えば，
銀行１２０での口座振替え時のミスにより，１０００万
円の代金１２１が自社の口座１２２に振り替えられてし
まった場合のケースを説明する。

【００１１】本社（資金運用部）１００で運用資金を把
握する際，口座照会情報（入出金明細）１２４では，実
際に口座１２２に振り替えられた金額「１０００万円」
が入金額として通知されるだけで，本来収納されるべき
料金の額「１００万円」を口座照会情報（入出金明細）
１２４のみから把握することができない。この場合に
は，収納金額の１００万円が運用可能な決済資金額であ
り，１０００万円すべてを運用することはできない。そ
のため，口座照会情報１２４の入金額を別の資金情報
（入金通知書情報１３３）により確認する突合処理が必
要である。本来，実際に利用者が支払った金額（入出金
明細１２３の入金（振替）金額）と回収すべき金額（収
納情報１３１の収納金額）とは一致するはずであり，そ
うであれば，口座照会情報１２４のみにもとづいて運用
資金を把握することができる。

【００１２】しかし，以下のような要因で，実際に入金
される金額と収納される額とが異なってしまうケースが
しばしば発生する。 (1) 請求書が改ざんされた。 (2) ＯＣＲ処理での読み取りミスがあった。 (3) 金融機関で振込金額と異なる金額で振込をした。 (4) 金融機関で誤った金額を入金通知書に記載した。

【００１３】ここで，口座照会情報１２４と突合する入
金通知書情報１３３は，銀行／郵便局１２０や支店／コ
ンビニ１６０の窓口で回収された払込票をＯＣＲ等で読
み取った収納情報１３１，１３４をもとに生成され，料
金計算サービスセンタ１８０で管理されるものであり，
金融機関１３０の入出金明細１２３をそのまま収集する
口座照会情報１２４とは，別ルートであるうえ，相互の
処理を考慮したものではない。

【００１４】また，口座照会情報１２４は，各金融機関
で使用する固有の情報をそのまま収集して提供されるも
のであるため，口座照会情報１２４のなかには，存在し
ない金融機関コードが残存したり，口座番号が特殊な形
式で表示されたりすることがあった。そのため，他の情
報との突合の際には，これら固有情報についての知識を
熟知した者がその差異を訂正する必要があり，訂正作業
における人的，時間的負担が大きかった。

【００１５】このように，企業の資金運用担当者は，企
業が開設した金融機関口座への入金額にもとづいて使用
可能な企業内の資金を把握するが，口座への入金額だけ
では明確な資金の把握ができないため突合を行う。しか
し，突合のためのもう一方の資金情報のもとである払込
票の回収には時間がかかり，収納料金の集計処理も時間
を要するうえ，突合自体を資金運用者の人手により行っ
ていた。

【００１６】特に，収納した料金が金融機関のどの口座
に入金されているかを確認することが困難であったた
め，回収した料金額と実際の口座への入金額が合ってい
ない状況が発生した場合には，原因の追求に多大な時間
がかかっていた。

【００１７】このような状況から，正確に資金額を把握
するまで金融機関の口座に資金が滞留してしまい，円滑
な資金運用に支障をきたすという問題が生じていた。

【００１８】本発明の目的は，料金の照合を正確にかつ
自動で行うシステムを提供することにある。特に，本発
明は，収納したはずの金額と実際の口座への入金額とを
自動的に突合処理することにより，正確かつ円滑な資金
把握を実現することを目的とする。また，口座照会情報
に混在する各金融機関の固有データを自動的に補正して
データを正規化を実現することを目的とする。

【００１９】

【課題を解決するための手段】上記目的を達成するた
め，本発明は，支払者が支払った請求書に付随する払込
票をもとに生成された入金情報を入力し，資金決済マス
タを更新する一方，支払われた料金について実際に企業
の口座に入金された口座入金額の情報を口座照会通知セ
ンタから入力し，入出金マスタを更新する。この資金決
済マスタに格納された入金情報と，入出金マスタに格納
された口座入金額とを照合してチェックし，一致するか
どうかの結果を出力する手段を持つ。これにより，実際
に運用可能な資金の把握が可能になり，円滑な資金運用
ができるようになる。また，不一致の場合の原因追求
も，不一致の状況から容易に行えるようになる。

【００２０】さらに，支払者に対して発行した請求書の
情報とその請求書に対して支払われた金額情報との照合
による入金チェック消込情報を入力し，その情報と資金
決済マスタに格納された入金情報とを照合しチェックす
る手段を設けることにより，回収した料金の妥当性検証
などを容易に行うことができるようになる。

【００２１】また，口座情報の照会により得た口座入金
額の情報について補正が必要な条件項目のパターンと補
正内容との組の情報が設定された変換テーブルを用い，
口座照会通知センタから得た口座入金額の情報が，変換
テーブルにおける条件項目のパターンに一致するか否か
を判定し，一致する場合に対応する補正内容に基づいて
口座入金額の情報を補正する補正処理手段を設ける。こ
れにより，ある金融機関が固有の口座情報を口座照会通
知センタに通知していた場合であっても，入出金マスタ
に格納する情報を正規化して統一された情報に変換する
ことができ，照合エラーまたは照合漏れを防ぐことがで
きる。

【００２２】変換テーブルは，必要な条件項目のパター
ンと補正内容との組を網羅的に登録するだけでよいの
で，特に変換テーブルに補正が必要な条件項目のパター
ンと補正内容との組の情報を設定する変換情報設定手段
を設けることにより，エラーの発生時に金融機関のシス
テムを変更することなく，口座照会情報を受けた側で容
易にかつ迅速に対処することが可能になる。

【００２３】以上の処理手段をコンピュータによって実
現するためのプログラムは，コンピュータが読み取り可
能な可搬媒体メモリ，半導体メモリ，ハードディスクな
どの適当な記録媒体に格納することができる。

【００２４】

【発明の実施の形態】図１は本発明に係る料金照合シス
テムのブロック構成例を示す。図２は本発明の処理の流
れの概要を説明する図である。本実施の形態では，図２
４と同様に電話料金の収納を例にするが，本発明は，電
話料金の収納に限らず，請求書を多数発行して請求金額
を収納するシステムに広く適用することができる。

【００２５】突合処理装置１は，図１に示すように，入
出金マスタ１０を更新する入出金マスタ更新手段１６，
入金チェック資金１１を取得し，資金決済マスタ１２に
反映させる資金決済マスタ更新手段１７，入金チェック
消込３７を取得し消込結果マスタ１３を更新する消込結
果マスタ更新手段１８，入出金マスタ１０と資金決済マ
スタ１２とを突合処理する入金情報突合処理手段１４，
消込結果マスタ１３と資金決済マスタ１２とを突合処理
する消込突合処理手段１５，突合結果を出力する結果出
力手段１９を備える。

【００２６】また，入出金明細補正装置５は，口座照会
通知センタ（ＡＮＳＥＲセンタ）４から口座照会情報
（ＡＮＳＥＲ情報）２４を得て，そのデータを変換テー
ブル５２を用いて正規化する補正処理手段５１を備え
る。変換テーブル５２は，口座情報の照会により通知さ
れた口座照会情報について補正が必要な条件項目のパタ
ーンと補正内容との組の情報を持つテーブルである。変
換情報設定手段５３は，キーボード・ディスプレイ等の
入出力装置５４からの入力により，変換テーブル５２に
補正が必要な条件項目のパターンと補正内容との組の情
報を登録する。

【００２７】図１では，突合処理装置１と入出金明細補
正装置５とを別装置として表しているが，入出金明細補
正装置５を突合処理装置１内に組み込む形で構成するこ
ともできる。また，入出金明細補正装置５を独立した装
置として構成することもできる。

【００２８】図２において，利用者の銀行／郵便局２の
窓口での料金支払いから，口座照会通知センタ４での口
座照会情報（入出金明細）２４の生成までの処理の流れ
は，図２４において説明した処理と同様である。

【００２９】まず，利用者は，払込票が添付された請求
書２０により，銀行／郵便局２の窓口で払込票とともに
料金を支払う。銀行／郵便局２では，支払われた代金２
１を払込先の金融機関３の口座２２へ振り替える。払込
先の金融機関３では，各口座２２ごとに入出金明細２３
を管理し，口座照会通知センタ４から口座２２に関する
入出金明細２３の問い合わせがあれば，その入出金明細
２３を口座照会通知センタ４へ送付する。口座照会通知
センタ４は，利用者（入出金明細補正装置５）からの口
座照会の要求に対して，金融機関３に該当する口座の入
出金明細２３を問い合わせを行い，取得した入出金明細
２３を口座照会情報２４として要求元の利用者へ通知す
る。

【００３０】図３に，口座照会情報の構成例を示す。口
座照会情報２４は，口座照会通知センタ４へ要求するこ
とにより取得できる金融機関ごとの入出金明細情報であ
る。口座照会情報２４は，金融機関名，支店名，口座番
号等を含むヘッダ部情報と，取引区分，取扱月日，金額
等の各取引ごとの取引データ部情報とから構成される。

【００３１】入出金明細補正装置５は，口座照会通知セ
ンタ４へ口座照会の要求を送信することにより，口座照
会情報２４を取得する。補正処理手段５１は，変換テー
ブル５２を検索し，取得した口座照会情報２４に各金融
機関固有のデータが含まれているため補正が必要な場
合，そのデータを変換テーブル５２に設定されている該
当する補正内容で置き換えることにより補正する。補正
後の口座照会情報２８は，突合処理装置１へ送信され
る。

【００３２】支店／コンビニ６での支払いから，出納情
報２７の生成までの処理は，図２４において説明した処
理と同様である。すなわち，支店／コンビニ６では，利
用者から支払われた代金２５を支店（経理部）７の資金
２６へ送金し，支店（経理部）７では，資金２６の出納
情報２７を突合処理装置１へ送信する。

【００３３】図４に，出納情報の構成例を示す。出納情
報２７は，支店（経理部）７における資金２６の実際の
入出金明細である。出納情報２７は，支店／事業部Ｉ
Ｄ，レコード件数，合計金額および個別の出納の情報で
ある各レコード（取引月日，処理月日，金額，勘定科
目）等からなる。出納情報２７は，突合処理装置１へ送
信される。

【００３４】また，銀行／郵便局２では，利用者の持参
した請求書２０の払込票の部分を回収し，払込票に記載
された払込人名，払込金額のデータに，銀行／郵便局
名，口座番号，払込日時等のデータを付与し，これらの
データを収納情報３１として，銀行ＶＡＮセンタ９へ送
信する。銀行ＶＡＮセンタ９は，金融機関業務に関する
データ処理を行うセンタであり，各銀行／郵便局２から
送信された収納情報３１を銀行収納情報３２として管理
し，料金計算サービスセンタ８へ送信する。支店／コン
ビニ６でも，同様に収納情報３８を料金計算サービスセ
ンタ８へ送信する。

【００３５】図５に，収納情報の構成例を示す。収納情
報３１（収納情報３８も同様）は，金融機関ＩＤ，入金
通知書データ（収納機関コード（収納情報３８では支店
コード），資金決済日，処理年月日，払込票合計枚数，
払込票合計金額），各払込票のデータ（加入者データ，
収納金額，収納機関コード，収納年月日）等からなる。

【００３６】銀行ＶＡＮセンタ９の銀行収納情報３２
は，各銀行等からの収納情報３１からなり，ほぼ同様の
構成である。

【００３７】料金計算サービスセンタ８では，請求書２
０を発行した顧客ごとに請求形態，請求金額，支払期
限，消込区分等を料金管理情報３３によって管理してお
り，支店／コンビニ６から送信された収納情報３８と，
銀行ＶＡＮセンタ９から送信された銀行収納情報３２と
を，料金管理情報３３に反映させる。さらに，この料金
管理情報３３から資金決済情報３４を生成し，また消込
み処理手段８１により消込み処理を行って入金通知書情
報３５を生成する。消込み処理とは，発行した請求書２
０に記載された請求金額の一覧情報と，銀行収納情報３
２および収納情報３８として通知された金額情報との照
合で，一致するものを抽出する処理である。資金決済情
報３４は，正常回収して資金決済が確認された収納金額
等の情報である。入金通知書情報３５は，収納されたは
ずの収納金額，正常収納の件数および金額，異常収納の
件数および金額等の消込み処理手段８１により消込み処
理を行った結果の入金情報である。

【００３８】図６に，資金決済情報３４の構成例を示
す。資金決済情報３４は，例えば，データＩＤ，資金決
済日，収納年月日，払込票合計枚数，払込票合計金額か
らなる。

【００３９】図７に，入金通知書情報３５の構成例を示
す。入金通知書情報３５は，例えば，レコードＩＤ，資
金決済日，収納年月日，収納機関コード，払込票合計枚
数，払込票合計金額，消込年月日，突合区分，正常収納
件数，正常収納金額，異常収納件数，異常収納金額から
なる。

【００４０】図８は，料金計算サービスセンタ８での消
込み処理を説明するための図である。消込み処理手段８
１では，銀行ＶＡＮセンタ９から受け取った銀行収納情
報３２の顧客番号をもとに，料金管理情報３３の該当す
る顧客番号の消込区分を「済」にして，収納情報のデー
タ（例えば，データ区分である束番号，収納機関コー
ド）を転記する。

【００４１】その後，資金決済日をキーに消込区分が
「済」のレコードを抽出する。抽出したデータの束番
号，資金決済日，収納機関，収納年月日，消込年月日，
件数，金額を入金通知書情報３５とする。これにより，
収納機関の束番号単位での収納料金の消込みが可能とな
る。

【００４２】銀行ＶＡＮセンタ９では，料金計算サービ
スセンタ８から受け取った資金決済情報３４および入金
通知書情報３５を入金チェック資金３６，入金チェック
消込３７として管理し，突合処理装置１へ送信する。

【００４３】突合処理装置１の入出金マスタ更新手段１
６では，所定の期日，例えば決済日ごとに，口座照会情
報２８および出納情報２７を取得し，入出金マスタ１０
を更新する。入出金マスタ１０は，図３に示す口座照会
情報（入出金明細）２４とほぼ同じである。

【００４４】資金決済マスタ更新手段１７は，銀行ＶＡ
Ｎセンタ９が管理する入金チェック資金３６を取得し，
入金チェック資金１１とする。さらに，このデータを資
金決済マスタ１２に反映させる。

【００４５】図９に，資金決済マスタ１２の構成例を示
す。資金決済マスタ１２は，例えば，資金決済機関コー
ド，金融機関名，口座番号，口座用途，資金決済日，突
合状況，収納機関コード，収納年月日，収納情報金額
（収納情報３８の収納金額を積み上げた額），銀行仮受
金（口座照会情報による入金額），データ区分（束番号
等）等からなる。

【００４６】入金情報突合処理手段１４では，資金決済
マスタ１２または入出金マスタ１０の更新時もしくは所
定時に突合処理を行う。

【００４７】図１０に，入金情報突合の処理フローを示
す。入金情報突合処理手段１４では，入出金マスタ１０
から，収納機関（銀行）コード，口座番号，資金決済日
単位でデータを取得する（ステップＳ１）。資金決済マ
スタ１２から，事業部コード（銀行コード，口座番
号），資金決済日単位でデータを取得する（ステップＳ
２）。資金決済マスタ１２から取得したデータを入出金
マスタ１０のレコード単位である銀行コード，口座番
号，資金決済日に並び替えて集計する（ステップＳ
３）。次に，資金決済マスタ１２の収納情報金額と入出
金マスタ１０の入金額（実際の入金額）とを突き合わせ
る（ステップＳ４）。これらの金額が合致した場合には
（ステップＳ５），突合状況を符合とし（ステップＳ
６），合致しなかった場合には，突合状況を不符合とす
る（ステップＳ７）。

【００４８】消込結果マスタ更新手段１８は，銀行ＶＡ
Ｎセンタ９から入金チェック消込３７を取得し消込結果
マスタ１３を更新する。

【００４９】図１１に，消込突合の処理フローを示す。
消込突合処理手段１５では，消込結果マスタ１３から，
資金決済機関（銀行）コード，口座番号，資金決済日，
収納年月日等の単位でデータを取得する（ステップＳ１
１）。資金決済マスタ１２から，事業部コード（資金決
済機関コード，口座番号），資金決済日，収納年月日，
束番号等の単位でデータを取得する（ステップＳ１
２）。資金決済マスタ１２を消込結果マスタ１３のレコ
ード単位である収納機関コード，収納年月日，束番号，
資金決済日に並び替えて集計する（ステップＳ１３）。
次に，資金決済マスタ１２の収納金額と，消込結果マス
タ１３の消込金額とを突き合わせる（ステップＳ１
４）。これらの金額が合致した場合には（ステップＳ１
５），突合状況を符合とし（ステップＳ１６），合致し
なかった場合には，突合状況を不符合とする（ステップ
Ｓ１７）。

【００５０】図１２に，入金情報突合・消込突合処理を
したデータの例を示す。入出金マスタ１０のデータは，
収納機関コード（銀行番号），口座番号，資金決済日，
金額の順に並べられているので，入金情報突合処理手段
１４では，資金決済マスタ１２のデータを，資金決済機
関コード（銀行番号），資金決済日の順に並べ替える。
銀行番号，口座番号，資金決済日をキーとして，入出金
マスタ１０のレコードの金額と，並べ替えた資金決済マ
スタ１２のレコードの金額を照合する。

【００５１】さらに，消込結果マスタ１３のデータを，
資金決済機関コード（銀行番号），資金決済日，データ
区分（帳票区分，消込センタコード等）の順に並べ替え
る。銀行番号，資金決済日，データ区分をキーとして，
資金決済マスタ１２のレコードの金額と，消込結果マス
タ１３の金額を照合する。

【００５２】入出金マスタ１０の金額（入出金），資金
決済マスタ１２の金額（収納金額），消込結果マスタの
金額（入金通知書金額）が合致した場合には，入出金マ
スタ１０のそのレコードの突合状況を「符合」とし，い
ずれかの金額が合致しない場合には「不符合」とする。

【００５３】不符合と判断される場合として，以下のよ
うな場合がある。ここで，○＝一致（符合），×＝不一
致（不符合）とする。

【００５４】１）収納金額：○，入金通知書金額：○，
入出金明細金額：×の場合→銀行の振込ミスが考えられ
る。

【００５５】２）収納金額：○，入金通知書金額：×，
入出金明細金額：○の場合→銀行入金通知書記入ミスが
考えられる。

【００５６】３）収納金額：×，入金通知書金額：○，
入出金明細金額：○の場合→請求書改ざんの疑い，また
はＯＣＲ読込みミスが考えられる。

【００５７】結果出力手段１９では，入金情報突合処理
および消込突合処理の結果を出力する。

【００５８】図１３〜図２０に，子会社３社および親会
社からなる企業において，料金の収納が銀行または複数
の支店窓口で行われ，各子会社および親会社の担当分に
応じて決済資金を分配する場合の突合処理結果の出力例
を示す。図１３〜図１６は，金融機関での収納分の突合
処理結果の出力例を示す図である。

【００５９】図１３に，突合状況照会結果リストの例を
示す。突合状況照会結果リストには，支払日（決済
日），仕訳番号，入金チェック資金３６から積算した全
社合計の収納情報金額合計，口座照会情報２８から抽出
した企業口座への入金分である仮受金を表示する。さら
に，仮払金は，口座入金額が収納情報金額より少ない場
合にその差額分を計上したものである。また，差額仮受
金は，口座入金額が収納情報金額より多い場合にその差
額を計上したものである。

【００６０】図１４に，図１３に示す突合状況照会結果
リストの明細の例を示す。これは，決済金融機関の口座
への入金についての突合状況および各子会社への分配状
況（支払状況）の一覧を示している。図１５に，銀行口
座別の突合状況一覧の例を示す。図１６は，口座からの
支払状況一覧の例を示している。

【００６１】図１４に示すように，収納情報金額と銀行
仮受金が合致しない場合には「突合状況」の欄に「不符
合」と表示される。例えば，Ｄ銀行の自行・窓口収納分
の５月１７日の決済日分は「不符合」であり，銀行仮受
金が１，０００，０００円多く入金されている。しか
し，収納情報金額と消込金額とは合致しているので，銀
行側の振込ミスによる不符合の可能性があることが判明
する。また，この場合には，銀行仮受金が収納情報金額
より多いため，収納情報金額の全額を資金運用できるこ
とがわかる。また，入金チェック資金３６のデータ区分
（会社コード）から各社の収納金額を，さらに入金チェ
ック消込３７から各データ区分（会社コード）ごとの消
込金額を抽出しているので，各社ごとの明細も把握する
ことができる。

【００６２】一方，図１５に示すように，Ｄ銀行の自行
・窓口収納分の５月１５日の決済日分は「不符合」であ
り，収納情報金額として集計された５，０００円が入金
されていない。この場合も，収納情報金額と消込金額と
は合致しているので，銀行側の振込ミスによる不符合の
可能性があることが判明する。したがって，５，０００
円を仮払に計上して資金運用可能として扱っている。

【００６３】さらに，Ｄ銀行の自行・口座振替収納分の
５月１７日分は「符合」であるため，入金された全額を
直ちに資金運用に使用可能であることが判明する。

【００６４】図１７〜図１９は，支店窓口での収納分の
突合処理結果の出力例を示す図である。

【００６５】図１７に，突合状況照会結果リストの例を
示す。突合状況照会結果リストには，支払日（資金決済
日），仕訳番号，入金チェック資金３６から積算した全
社合計の収納情報の合計額，各子会社および親会社の担
当についての請求分，出納情報２７での窓口収納した合
計額を表示する。さらに，仮払金は，窓口収納額が収納
情報金額より少ない場合にその差額分を計上したもので
ある。また，仮受金は，窓口収納額が収納情報金額より
多い場合にその差額を計上したものである。

【００６６】図１８に，図１７に示す突合状況照会結果
リストの明細の例を示す。収納情報金額と窓口仮受金が
合致しない場合には「突合状況」の欄に「不符合」と表
示される。図１９に，事業所／収納形態別突合状況およ
び各社への分配状況（支払状況）の一覧例を示す。これ
らの図の各項目については，図１５に示す状況一覧の例
とほぼ同様である。

【００６７】次に，口座照会情報（ＡＮＳＥＲ情報）の
補正処理について説明する。

【００６８】口座照会通知センタ４から取得した口座照
会情報２４は，各金融機関固有の情報が含まれているた
め，補正処理手段５１では，資金決済マスタ１２，消込
み結果マスタ１３との照合を可能とするため，口座照会
情報２４に含まれるこれらの固有情報を自動的に正規化
する。

【００６９】口座照会情報２４は，図３に示すような構
成であるが，例えば口座番号データは，各銀行内のシス
テムで使用している口座番号データをそのまま抽出して
いるものがあったりするため，ある銀行のものはそのま
までは使用できない場合がある。また，金融機関コード
も，一部欠番のままで空白データになっているような場
合があり，そのままではエラーになってしまう場合があ
る。

【００７０】すべての金融機関３が，統一された口座番
号データ，金融機関コード等を統一された形式で入出金
明細２３として出力するようになっていれば，口座照会
情報２４を正規化する補正は不要であが，現状では入出
金明細２３に統一されていない独自のコードが設定され
てくることもあり，エラーが生じることがある。このと
き，エラーの原因となった金融機関３のシステムの変更
を待ち，変更後のシステムから再度，入出金明細２３を
もらうという対処は時間的な問題および金融機関３側の
システムの都合から現実的ではない。また，人間が目視
によりエラーを検出しそれを手作業で修正するというこ
とも，データ量が膨大であることから実現はきわめて困
難である。

【００７１】本システムでは，補正処理手段５１を設け
ることにより，以上の問題を解決する。補正処理手段５
１では，変換テーブル５２を用いて不統一のデータを正
規化されたデータに自動補正する。

【００７２】具体例として，いくつか補正処理を説明す
る。

【００７３】マイナス金額の補正処理 マイナス金額の補正処理として，口座照会情報２４の入
出金の金額がマイナス計上されている場合には，取引名
を変更する。すなわち取引名が「出金」で金額がマイナ
ス計上の場合は，金額のマイナスを削除し，取引名を
「入金」に変更する。また，取引名が「入金」で金額が
マイナス計上の場合は，金額のマイナスを削除し，取引
名を「出金」に変更する。

【００７４】口座番号の補正処理 例えば，□□銀行のデータの場合には，口座番号の上４
桁が開設口座の下４桁を意味する場合，口座番号「４５
６７×××」のうち「４５６７」が開設口座番号の下４
桁で「×××」は□□銀行内で使用する固有データであ
るときには，口座番号「４５６７×××」を，あらかじ
め変換テーブル５２に補正内容として設定された「１２
３４５６７」に変更する処理を行う。

【００７５】図２０に，口座番号の補正処理用の変換テ
ーブルの例を示す。例えば変換テーブルの１行目は，変
換元の銀行コード＝０１８０（□□銀行），支店コード
＝１００，口座番号＝６５４３２１０の条件に合致する
レコードがある場合には，そのレコードの口座番号を
「０５４３２１０」に変換することを意味する。２行目
以降も同様である。

【００７６】金融機関コードの補正処理 例えば，○○銀行の金融機関コードは「０１９８（欠
番）」として照会されるので，正しい金融機関コードに
補正する。

【００７７】図２１に，金融機関コードの補正処理用の
変換テーブルの例を示す。例えば変換テーブルの１行目
は，変換元の銀行コード＝０１９８（欠番），支店コー
ド＝１６０，口座番号＝００５０５０５であるレコード
について，変換後銀行コードを銀行コード「０１２１」
に変更することを意味する。

【００７８】取引日付／起算日設定処理 取引日付と起算日の両方が設定されている必要があるた
め，いずれか一方が空白の場合には，補充して設定す
る。

【００７９】図２２に，取引日付／起算日設定処理用の
変換テーブルの例を示す。変換テーブルの２行目は，変
換元の口座番号＝００５０５５５で，起算日が空白のレ
コードについて，取引日付（１月２６日）を参照して起
算日（１月２６日）を設定することを意味する。また，
変換テーブルの３行目は，変換元の口座番号＝０３３４
４５５で，取引日付が空白のレコードについて，起算日
（１月２１日）を参照して取引日付（１月２１日）を設
定することを意味する。

【００８０】科目設定処理 口座照会情報２４の取引名にもとづいて，科目を設定す
る。例えば，取引名が「出金」であれば，科目＝資金移
動と設定し，取引名が「入金」であれば，科目＝銀行入
金額と設定する。

【００８１】変換情報設定手段５３は，管理者からの入
力指示により，これらの変換テーブルの編集を行う。口
座照会通知センタ４から入力した口座照会情報２４にエ
ラーがあった場合，そのエラーのパターンを条件項目と
して登録し，正しい内容を補正項目として登録する。口
座照会情報２４のエラーは，ランダムに発生するという
ことはほとんどなく，金融機関に応じてエラーのパター
ンが定型化している場合が多いので，そのエラーのパタ
ーンを条件項目として登録し，正しい内容を補正項目と
して登録することにより，入力情報と条件項目との簡単
なパターン照合により，入力情報の自動補正を実現する
ことができる。すなわち，新しいエラーが発見されたと
き，管理者は，そのエラーのパターンを解析し，変換情
報設定手段５３を用いて変換テーブル５２にそのエラー
のパターンを条件項目として設定し，正しい内容を補正
項目として設定する。これにより，以後の同様のエラー
に対して自動的に口座照会情報を修正することが可能に
なる。

【００８２】変換情報設定手段５３は，ＧＵＩ（Graphi
cal User Interface）を用いて対話処理により変換テー
ブル５２への設定情報を入力するものでもよく，また，
例えば変換テーブル５２をテキストファイルで実現し，
簡単なテキストエディタのようなもので変換情報設定手
段５３を実現することも可能である。

【００８３】図２３に，補正処理の処理フローを示す。

【００８４】口座照会情報２４を取得すると（ステップ
Ｓ２１），変換テーブルの条件をキーとして照合する
（ステップＳ２２）。全ての条件キーが合致したら（ス
テップＳ２３），変換テーブルの補正項目にもとづいて
該当するデータを変更する（ステップＳ２４）。条件キ
ーが合致しない場合には情報の変換を行わず処理を終了
する。これによって，人手を要さずに，確実な照合処理
を実現することができるようになる。

【００８５】

【発明の効果】以上説明したように，本発明によれば，
収納金額と実際の口座入金額とを自動的に突合処理し，
さらに，消込結果マスタに消込情報を反映させる。これ
により，迅速，正確かつ円滑な資金把握が可能になる。
また，口座照会情報に混在する各金融機関の固有情報を
自動的に補正して情報を正規化する。これにより，突合
処理を正確に行うことができる。

【図面の簡単な説明】

【図１】本発明に係る料金照合システムのブロック構成
例を示す図である。

【図２】本発明の処理概要を示す図である。

【図３】口座照会情報の例を示す図である。

【図４】出納情報の例を示す図である。

【図５】収納情報の例を示す図である。

【図６】資金決済情報の例を示す図である。

【図７】入金通知書情報の例を示す図である。

【図８】消込処理を説明するための図である。

【図９】資金決済マスタの例を示す図である。

【図１０】入金情報突合処理の処理フローである。

【図１１】消込突合処理の処理フローである。

【図１２】入金情報突合・消込突合処理をしたデータの
例を示す図である。

【図１３】金融機関収納分の突合状況照会結果リストの
例を示す図である。

【図１４】金融機関収納分の突合状況明細の例を示す図
である。

【図１５】銀行口座・資金決済日別突合状況一覧の例を
示す図である。

【図１６】口座からの支払状況一覧の例を示す図であ
る。

【図１７】支店窓口収納分の突合状況照会結果リストの
例を示す図である。

【図１８】支店窓口収納分の突合状況明細の例を示す図
である。

【図１９】事業所／収納形態別の突合状況一覧の例を示
す図である。

【図２０】口座番号補正用の変換テーブルの例を示す図
である。

【図２１】金融機関コード補正用の変換テーブルの例を
示す図である。

【図２２】取引日付／起算日設定用の変換テーブルの例
を示す図である。

【図２３】口座照会情報補正処理の処理フローを示す図
である。

【図２４】従来の収納から資金決済までの処理の流れを
説明するための図である。

【符号の説明】

１ 突合処理装置 ２ 銀行／郵便局 ３ 金融機関 ４ 口座照会通知センタ ５ 入出金明細補正装置 ６ 支店／コンビニエンスストア ７ 支店（経理） ８ 料金計算サービスセンタ ９ 銀行ＶＡＮセンタ １０ 入出金マスタ １１ 入金チェック資金 １２ 資金決済マスタ １３ 消込結果マスタ １４ 入金情報突合処理手段 １５ 消込突合処理手段 ２０ 請求書 ２１ 代金 ２２ 口座 ２３ 入出金明細 ２４ 口座照会情報（入出金明細） ２５ 代金 ２６ 資金 ２７ 出納情報 ２８ 口座照会情報（入出金明細） ３１ 収納情報 ３２ 銀行収納情報 ３３ 料金管理情報 ３４ 資金決済情報 ３５ 入金通知書情報 ３６ 入金チェック資金 ３７ 入金チェック消込 ３８ 収納情報 ５１ 補正処理手段 ５２ 変換テーブル ５３ 変換情報設定手段 ５４ 入出力装置 ８１ 消込処理手段

───────────────────────────────────────────────────── フロントページの続き (72)発明者 櫻井 貞雄 東京都新宿区西新宿一丁目21番１号 エ ヌ・ティ・ティ・インターネット株式会社 内 (72)発明者 田中 秀和 東京都新宿区西新宿一丁目21番１号 エ ヌ・ティ・ティ・インターネット株式会社 内 Ｆターム(参考） 3E040 AA06 BA18 CA14 CB01 DA05 EA01 5B055 CB03 CC00 CC08

Claims (5)

【特許請求の範囲】
1. 【請求項１】 支払われた料金情報と口座に入金された
   金額とを照合する料金照合システムであって，請求書に
   付随する払込票をもとに生成された入金情報を入力し，
   資金決済マスタを更新する手段と，支払われた料金につ
   いて実際に企業の口座に入金された口座入金額の情報を
   入力し，入出金マスタを更新する手段と，前記資金決済
   マスタに格納された入金情報と，前記入出金マスタに格
   納された口座入金額とを照合し，一致または不一致を検
   出する手段と，検出した結果を出力する手段とを備える
   ことを特徴とする料金照合システム。
2. 【請求項２】 請求項１記載の料金照合システムにおい
   て，支払者に対して発行した請求書の情報とその請求書
   に対して支払われた金額情報との照合による入金チェッ
   ク消込情報を入力し，消込結果マスタを更新する手段
   と，前記資金決済マスタに格納された入金情報と，前記
   消込結果マスタに格納された入金チェック消込情報とを
   照合し，消込み結果を確認する手段とを備えることを特
   徴とする料金照合システム。
3. 【請求項３】 支払われた料金情報と口座に入金された
   金額とを照合する料金照合システムであって，口座情報
   の照会により得た口座入金額の情報について補正が必要
   な条件項目のパターンと前記条件項目のパターンが一致
   したときに置き換える補正内容との組の情報が設定され
   た変換テーブルと，前記変換テーブルを参照し，口座情
   報の照会により得た口座入金額の情報が前記条件項目の
   パターンに一致するか否かを判定し，一致する場合に対
   応する補正内容に基づいて口座入金額の情報を補正する
   補正処理手段と，前記変換テーブルに補正が必要な条件
   項目のパターンと補正内容との組の情報を設定する変換
   情報設定手段とを備えることを特徴とする料金照合シス
   テム。
4. 【請求項４】 支払われた料金情報と口座に入金された
   金額とを，コンピュータによって照合するためのプログ
   ラムを記録したプログラム記録媒体であって，請求書に
   付随する払込票をもとに生成された入金情報を入力し，
   資金決済マスタを更新する処理と，支払われた料金につ
   いて実際に企業の口座に入金された口座入金額の情報を
   入力し，入出金マスタを更新する処理と，前記資金決済
   マスタに格納された入金情報と，前記入出金マスタに格
   納された口座入金額とを照合し，一致または不一致を検
   出する処理と，検出した結果を出力する処理とを，コン
   ピュータに実行させるためのプログラムを記録したこと
   を特徴とする料金照合用プログラム記録媒体。
5. 【請求項５】 支払われた料金情報と口座に入金された
   金額とを，コンピュータによって照合するためのプログ
   ラムを記録したプログラム記録媒体であって，口座情報
   の照会により得た口座入金額の情報について補正が必要
   な条件項目のパターンと前記条件項目のパターンが一致
   したときに置き換える補正内容との組の情報が設定され
   た変換テーブルを参照し，口座情報の照会により得た口
   座入金額の情報が前記条件項目のパターンに一致するか
   否かを判定し，一致する場合に対応する補正内容に基づ
   いて口座入金額の情報を補正する補正処理と，前記変換
   テーブルに補正が必要な条件項目のパターンと補正内容
   との組の情報を設定する変換情報設定処理とを，コンピ
   ュータに実行させるためのプログラムを記録したことを
   特徴とする料金照合用プログラム記録媒体。