(57)【要約】【課題】不適切な精算者をより精度よく特定可能な情報を提供する。【解決手段】精算管理システム１によれば、精算データ入力部１１により入力された精算データを登録し、精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者を示す情報を生成する。このように、精算管理システム１は、精算データを集計して、所定の精算パターンに基づいた条件に合致する精算者を示す情報を出力するので、容易に不正精算候補者を特定し得る。【選択図】図１
2020030799.tif 000002
【特許請求の範囲】
【請求項１】
精算データを管理する精算管理システムであって、
前記精算データの入力を受け付ける精算データ入力部と、
前記精算データ入力部により入力された精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者を示す情報を生成する情報生成部と、
を備える、精算管理システム。
【請求項２】
請求項１に記載の精算管理システムにおいて、
前記情報生成部は、生成した情報を用いて、前記精算パターンに基づいた条件に合致する精算をしている精算者へ、前記精算パターンに基づいた条件に合致する旨の通知をする、精算管理システム。
【請求項３】
請求項２に記載の精算管理システムにおいて、
前記情報生成部は、前記通知をした後に、前記精算データ入力部により入力された精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者を示す情報を再生成し、再生成した結果に基づき通知方法を変更する、精算管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、精算管理の技術に関し、精算管理システムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
従来、外出して業務を行う従業者は、外出に伴う交通費等の経費精算をする場合、従業者が経費の内容（精算額など）を入力して、当該内容に基づくデータである精算データを出力することにより、経費精算をする。
【０００３】
経費精算における不適切な精算（例えば、不正精算）を検出するために、精算データを集計する技術がある。このような精算データを集計する技術が、例えば、特開２００８−２３４４１２号公報（特許文献１）に記載されている。具体的に、当該特許文献１には、精算データが示す精算者とその精算データが示す発生日を予定の単位ごとにまとめた単位期間とを集計項目として、その精算データが示す精算額をクロス集計し、精算者ごとの精算額の合計を計算し、その合計が大きい順にソートした集計表を作成する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２３４４１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１に記載の技術では、精算者ごとの精算額の合計を計算して、その結果をソートすることにより、精算額が高い精算者を特定することができるが、単に集計しただけでは、適切でない精算をする者を特定できない可能性もある。例えば、精算頻度が高い精算者は、不正精算者でなくても精算額が高くなる傾向にある。
【０００６】
そこで本発明の目的は、不適切な精算者（不正精算の蓋然性のある精算者）をより精度よく特定可能な情報を提供する精算管理システムを提供することにある。
【０００７】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【０００８】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【０００９】
本発明の代表的な実施の形態による精算管理システムは、精算データを管理する精算管理システムであって、精算データの入力を受け付ける精算データ入力部と、精算データ入力部により入力された精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者を示す情報を生成する情報生成部と、を備える。
【発明の効果】
【００１０】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１１】
すなわち、本発明の代表的な実施の形態によれば、不適切な精算者をより精度よく特定可能な情報を提供することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態である精算管理システムの構成について概要を示した図である。
【図２】本発明の実施の形態である精算管理システムで管理する処理フェーズを示した図である。
【図３】本発明の実施の形態における事前チェックと事後チェックの例を示した図である。
【図４】本発明の実施の形態における申請データの例を示す図である。
【図５】本発明の実施の形態における精算管理システムが出力する散布図の例である。
【図６】本発明の実施の形態における不正精算者の候補を示す情報を出力する処理の流れを示すフローチャートである。
【図７】本発明の実施の形態における散布図情報を出力する処理の流れを示すフローチャートである。
【図８】本発明の実施の形態における日当の精算の傾向を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。
【００１４】
＜概要＞
図１は、本実施形態である精算管理システム１の構成について概要を示した図である。図１に示す精算管理システム１は、サーバ機器等である。この精算管理システム１は、精算者であるユーザ２（例えば、会社員）が使用する端末装置３と、図示しないＬＡＮ（Local Area Network）等のネットワークを介して情報を送受信することができる。精算管理システム１は、ユーザ２が端末装置３を介して入力した精算データを受け付け、当該精算データを管理するシステムである。ここで、精算データは、精算請求に関するデータであり、精算者を示す情報、精算内容（カテゴリ）、支払日（支払時刻も含む）、請求金額等を含むデータである。なお、当該精算データは、別途申請された出張申請と適切に関連付けられているものとする。
【００１５】
精算管理システム１は、入力を受け付けた精算データについて、精算内容（カテゴリ）およびユーザ毎に集計し、所定の精算パターンに基づいた条件に合致する精算者を示す情報を生成する。ここで、所定の精算パターンに基づいた条件とは、不正精算等の蓋然性がある条件である。また、精算パターンとは、頻度が高いと不正精算の可能性がある精算方法であり、例えば、手入力による精算などである。
【００１６】
なお、精算管理システム１は、上記所定の精算パターンに基づいた条件に合致する精算者を示す情報として、他のユーザの精算状況の頻度・合計金額に基づいて比較し得る情報（例えば、散布図等）を出力するようにしてもよい。
【００１７】
会社等の精算管理において、一般的には、不正申請または誤申請を防止するために、申請したユーザ２の上長の承認を得る必要がある。本実施形態における精算管理システム１では、上記のような上長の承認などの確認作業を省略または簡略化したとしても適切に管理する処理を行う。
【００１８】
例えば、精算管理システム１は、図２に示すような「事前チェック」、「可視化」、及び「事後チェック」の３つのフェーズで不正申請・誤申請を抑止したり、検出したりする。まず、「事前チェック」として、精算管理システム１は、端末装置３によって入力された精算データを登録する前に、入力された精算データが適切であるか否かを簡易チェックする。例えば、精算管理システム１は、入力された精算データにおける取引日（支払日）が適切であるか否か等をチェックする。
【００１９】
「可視化」として、精算管理システム１は、端末装置３によって入力された精算データについて、予め記憶している精算基準データを逸脱するか否かを判断し、逸脱する場合、その旨を示す情報（フラグ情報）を登録し、当該フラグ情報を含む情報を、経理部のメンバーや申請者の所属する部の上長に参照できるようにする。ここで、精算基準データとは、精算内容（カテゴリ）に関する基準（精算パターン）を定めたデータであり、精算が適切であるか否かを判断するための情報である。
【００２０】
「事後チェック」として、精算管理システム１は、登録した精算データを、精算内容およびユーザ２毎に集計し、他のユーザ２の請求状況と比較可能な情報（例えば、散布図）を提供することにより、不正精算している可能性のあるユーザ２（不正精算者候補）を特定可能な情報（所定の精算パターンに基づいた条件に合致する精算をしている精算者を特定する情報）を提供する。また、「事後チェック」として、精算管理システム１は、不正精算者候補の過去の精算について詳細にチェックし得る情報を提供する。
【００２１】
ここで、図３を用いて、事前チェックおよび事後チェックの例を説明する。図３に示すように、精算の内容（カテゴリ）として、「電車／バス」、「タクシー／高速バス」、「新幹線・特急」、「航空券代」、および「宿泊費」などがある。なお、上記のカテゴリに限らず、複数人が参加する飲み会（懇親会）もカテゴリとして含んでもよい。この場合、精算データとして、参加者の氏名等も含むことが考えられる。
【００２２】
例えば、「タクシー／高速バス」の場合、事前チェックとして、取引日が土日祝日（すなわち、業務日ではないと考えられる日）である場合、警告メッセージ（ワーニング）を出力する。また、事後チェックとして、業務時間データとマッチングをする。例えば、業務終了時間が深夜でないにも関わらず、タクシー利用している回数が他の会社員と比較して多いか否かをチェックする。
【００２３】
また、「宿泊費」の場合、事前チェックとして、標準手配（標準精算プラン）以外の宿泊か否かをチェックし、標準手配以外の宿泊の場合、ワーニングを出力する。ここで、標準手配とは、予め定められている推奨の宿泊プラン（例えば、旅行代理店推奨の宿泊プラン）を示す。また、事後チェックとして、地域別に件数・金額の多い社員をチェックする。この件数は、標準手配以外の宿泊件数でもよい。また、事後チェックとして、予め定められている上限値付近の社員をチェックしたり、業務時間データとマッチングしたりする。
【００２４】
図１に戻り、精算管理システム１の詳細を説明する。精算管理システム１は、例えば、上述のようにサーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバ等により構成される。また、精算管理システム１は、図示しないＣＰＵ（Central Processing Unit）により、ＨＤＤ（Hard Disk Drive）等の記録装置からメモリ上に展開したＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラム等のミドルウェアや、その上で稼働するソフトウェアを実行する。これにより、端末装置３から受信した精算データの管理に係る後述する各種機能を実現する。
【００２５】
精算管理システム１は、例えば、ソフトウェアとして実装された精算データ入力部１１、精算データ登録部１２、および情報生成部１５等の各部を有する。また、精算管理システム１は、データベースやファイル、メモリテーブル等により実装された精算データＤＢ１３、および精算基準データＤＢ１４（精算基準情報記憶部）等を有する。
【００２６】
精算データ入力部１１は、精算データの入力を受け付ける部分である。具体的に、精算データ入力部１１は、端末装置３により精算データの入力を受け付ける。例えば、会社が配布しているクレジットカードを利用して支払をしたユーザ２の端末装置３からの精算を受け付ける場合、精算データ入力部１１は、当該クレジットカードの会社から当該ユーザ２がクレジットカードを利用した情報を取得して、当該情報から精算対象をリスト等の中から選択させて入力を受け付ける。
【００２７】
また、会社等から配布された交通ＩＣカードを利用して支払をしたユーザ２の端末装置３からの精算を受け付ける場合、精算データ入力部１１は、当該交通ＩＣカードに記憶されている情報を公知の手段により取得して、当該情報から精算対象をリスト等の中から選択させて入力を受け付ける。
【００２８】
上述のように、精算管理システム１は、クレジットカードや交通ＩＣカード等の支払済みのデータを取得して、取得したデータに基づいて入力を受け付ける。これにより、精算管理システム１は、実際に支払いがなされたことが証明されたデータを受け付けることで、不正精算や誤精算を防止することができる。
【００２９】
なお、精算データ入力部１１は、上記のようなクレジットカードや交通ＩＣカードに連携したデータを用いずに、端末装置３のユーザ２から入力された情報（手入力された情報）に基づいて精算データの入力を受け付けるようにしてもよい。なお、精算管理システム１では、クレジットカードや交通ＩＣカードに連携したデータにより入力することを推奨しているものとする。
【００３０】
端末装置３は、精算データとして、申請日、所属、氏名、支払日（支払時刻も含む）、経費タイプ（精算内容を示すカテゴリ）、支払先、金額等を含む精算データを入力する。精算データ入力部１１は、これに応じて上記精算データの入力を受け付ける。
【００３１】
なお、精算データ入力部１１は、経費タイプや支払先などをリスト等の中から選択させて入力を受け付けるようにしてもよい。これにより、入力内容の表記ゆれを防止することができる。
【００３２】
また、精算データ入力部１１は、経費タイプが宿泊の場合、標準手配の宿泊であるか否かを示す情報の入力を受け付ける。
【００３３】
なお、精算データ入力部１１は、支払日が休日である場合や、標準手配の宿泊でない場合、事前チェックとして警告メッセージ（ワーニング）を出力するようにしてもよい。
【００３４】
精算データ入力部１１は、端末装置３によって入力された精算データの入力を受け付けると、当該精算データを精算データ登録部１２へ送出する。なお、精算データ入力部１１は、精算データに、手入力されたか否かを示す情報も含めて精算データ登録部１２へ送出する。
【００３５】
精算データ登録部１２は、精算データ入力部１１により入力された精算データを登録する部分である。精算データ登録部１２は、精算データ入力部１１から精算データを取得すると、当該精算データを精算データＤＢ１３へ登録する。なお、精算データ登録部１２は、入力された精算データに標準手配の宿泊であるか否かを示す情報があり、標準手配の宿泊でないことが示されている場合、精算データに標準手配（標準利用）以外を示すフラグ情報を付与して登録する。
【００３６】
精算データＤＢ１３は、精算データ登録部１２により登録された精算データを記憶するデータベースである。
【００３７】
精算基準データＤＢ１４は、精算内容ごとに、当該精算に関する基準を定めた精算基準情報を記憶するデータベースである。
【００３８】
例えば、精算基準データＤＢ１４は、各精算内容の閾値の金額や、各精算内容におけるワーニング対象の取引日等の精算基準情報を記憶する。カテゴリが電車利用である場合、平日（休日以外）の利用を基準とする情報を精算基準情報として記憶する。カテゴリがタクシー利用である場合、深夜（例えば、２３時以降）利用でないことを基準とする情報を精算基準として記憶する。
【００３９】
また、カテゴリが宿泊である場合、標準利用（標準手配の宿泊）であることを基準とする情報を精算基準情報として記憶する。また、カテゴリが宿泊である場合、宿泊基準金額を１泊３００００円未満であることを基準とする情報を精算基準情報として記憶する。
【００４０】
また、カテゴリに関わらず、手入力でないことを基準とする情報を精算基準情報として記憶する。
【００４１】
情報生成部１５は、精算データ入力部１１により入力された精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者（ユーザ２）を示す情報を生成する部分である。
【００４２】
例えば、情報生成部１５は、精算データＤＢ１３に登録された精算データと、精算基準データＤＢ１４に記憶されている精算基準情報の内、当該精算データの内容に対応する精算基準情報とを比較した結果に基づいた情報（フラグ情報）を生成する。
【００４３】
情報生成部１５は、ある程度精算データが登録されたタイミング（例えば、１週間に１回）で、フラグ情報の生成をする。すなわち、情報生成部１５は、所定のタイミング毎にフラグ情報を再生成する。
【００４４】
情報生成部１５は、例えば、精算データＤＢ１３に記憶されている精算データのカテゴリが電車利用（電車／バス）である場合、精算基準データＤＢ１４から、カテゴリが電車利用である場合における精算基準情報を取得する。上述のように、カテゴリが電車利用である場合、平日の利用を基準とする精算基準情報が記憶されているので、情報生成部１５は、精算データＤＢ１３に記憶されている精算データの支払日が平日か否かを判断する。精算データの支払日が休日である場合、情報生成部１５は、当該精算データに、フラグ情報として「休日利用」を示す情報を付与する。このように、情報生成部１５は、精算データの支払日と、精算基準情報とを比較した結果、当該精算基準情報の基準を満たさない場合、精算データに問題がある可能性があるので、当該精算データに「休日利用」を示す情報を付与する。
【００４５】
また、情報生成部１５は、精算データＤＢ１３に記憶されている精算データのカテゴリがタクシー利用である場合、精算基準データＤＢ１４から、カテゴリがタクシー利用である場合における精算基準情報を取得する。上述のように、カテゴリがタクシー利用である場合、深夜利用でないことを基準とする精算基準情報が記憶されているので、情報生成部１５は、精算データＤＢ１３に記憶されている精算データの支払い時刻が深夜（例えば、２３時以降）か否かを判断する。
【００４６】
精算データの支払い時刻が深夜を示す場合、情報生成部１５は、当該精算データに、フラグ情報として「深夜利用」を示す情報を付与する。このように、情報生成部１５は、精算データの支払時刻と、精算基準情報とを比較した結果、当該精算基準情報の基準を満たさない場合、精算データに問題がある可能性があるので、当該精算データに「深夜利用」を示す情報を付与する。
【００４７】
情報生成部１５は、例えば、精算データＤＢ１３に記憶されている精算データのカテゴリが宿泊である場合、精算基準データＤＢ１４から、カテゴリが宿泊利用である場合における精算基準情報を取得する。
【００４８】
上述のように、カテゴリが宿泊利用である場合、高額利用でないことを基準とする精算基準情報が記憶されているので、情報生成部１５は、精算データＤＢ１３に記憶されている精算データの金額が高額であるか否かを判断する。精算の金額が高額であることを示す場合、情報生成部１５は、当該精算データに、フラグ情報として「高額利用」を示す情報を付与する。このように、情報生成部１５は、精算データの金額と、精算基準情報とを比較した結果、当該精算基準情報の基準を満たさない場合、精算データに問題がある可能性があるので、当該精算データに「高額利用」を示す情報を付与する。
【００４９】
また、カテゴリが宿泊利用である場合、標準利用（標準手配の宿泊）であることを基準とする情報が精算基準情報として記憶されているので、情報生成部１５は、精算データＤＢ１３に記憶されている精算データが、標準利用であるか否かを判断し、標準利用でない場合、当該精算データに、フラグ情報として「標準利用外」を示す情報を付与する。これは、予め精算管理システム１側で設定している標準利用のルートをわざわざ使用していることは、不正のインセンティブを含む可能性があるためである。
【００５０】
また、情報生成部１５は、全てのカテゴリについて、手入力でないことを基準とする情報を精算基準情報に基づいて、手入力の精算データに、フラグ情報として「手入力」を示す情報を付与する。
【００５１】
ここで、図４に、情報生成部１５が、フラグ情報を生成した後における精算データの例を示す。図４は、精算データＤＢ１３に記憶されている精算データのレコードの例を説明する図である。
【００５２】
レコードＲ１は、カテゴリ（経費タイプ）が宿泊である精算データのレコードである。レコードＲ１の例の場合、利用金額が１０００００円と高額利用であるので、確認ポイントの高額利用のフラグ情報が設定されている。また、レコードＲ１は、標準利用外であることを示すフラグ情報も付与されている。
【００５３】
レコードＲ２は、カテゴリが電車移動である精算データのレコードである。レコードＲ２の例の場合、支払日が休日（土曜日）であるので、確認ポイントの休日利用のフラグ情報が設定されている。また、このレコードＲ２は、手入力により入力されたものであることを示すフラグ情報も設定されている。
【００５４】
レコードＲ３は、カテゴリがタクシー利用である精算データのレコードである（なお、支払時刻が、深夜を示す時刻であるものとする）。レコードＲ３の例の場合、支払日の支払時刻が深夜であるので、確認ポイントの深夜利用のフラグ情報が設定されている。
【００５５】
レコードＲ４は、カテゴリが宿泊である精算データのレコードである。レコードＲ４の例の場合、標準利用であり、利用金額が高額ではないため、確認ポイントにフラグ情報が設定されていない。
【００５６】
情報生成部１５は、所定のタイミングで図４に示したようなレコードを各種装置へ表示出力する。例えば、情報生成部１５は、図示しない経理部担当や各部署の管理職の端末装置へ図４に示したようなレコードを送信出力して、当該レコードを表示出力させる。これにより、精算管理システム１は、上述の「可視化」を実現することができる。
【００５７】
また、情報生成部１５は、上記フラグについて統計処理をして、当該統計処理の結果に基づいた情報を経理部担当や各部署の管理職の端末装置へ送信出力するようにしてもよい。
【００５８】
例えば、情報生成部１５は、所定のタイミングで精算データＤＢ１３に記憶されている精算データについて、精算者毎にフラグが設定されている数（フラグ数）を集計して、当該フラグ数が予め記憶している閾値以上となる精算者の精算データを経理部担当や各部署の管理職の端末装置へ送信出力するようにしてもよい。
【００５９】
この場合、情報生成部１５は、不正精算者である可能性の高い不正精算者の候補を抽出し、当該不正精算者の候補の精算データを出力することができる。
【００６０】
具体的に、情報生成部１５は、精算者毎に、手入力のフラグが設定されている数と、精算申請数とを集計して、手入力の比率が高い（例えば、１００回申請している内、８０回を手入力で申請している）精算者の精算データを経理部担当や各部署の管理職の端末装置へ送信出力する。また、情報生成部１５は、精算者毎に、標準利用外を示すフラグが設定されている数と、宿泊カテゴリの精算における精算申請数とを集計して、標準利用外の比率が高い精算者の精算データを経理部担当や各部署の管理職の端末装置へ送信出力する。
【００６１】
また、情報生成部１５は、所定の精算内容について、各精算者の請求頻度と請求金額とに基づいた不正精算候補者を示す情報を、精算データ登録部１２に登録された精算データを用いて生成し、当該情報を出力する。
【００６２】
例えば、情報生成部１５は、不正精算候補者を示す情報として、各精算者の請求頻度と請求金額とに基づいた散布図を出力する。
【００６３】
例えば、情報生成部１５は、不正精算候補者を示す情報として、各精算者のあるカテゴリ（例えば、タクシー利用）の請求頻度と、当該カテゴリの請求金額の合計に基づいた散布図を出力する。
【００６４】
タクシー利用に関する散布図を生成する場合、情報生成部１５は、精算データＤＢ１３の精算データを参照して、各精算者のカテゴリがタクシー利用となっているレコードを取得し、当該レコードの数と当該レコードの金額の合計（請求金額の合計）を算出し、算出した結果に基づいて散布図を生成する。この散布図の場合、縦軸が請求金額の合計であり、横軸が頻度であり、当該請求金額と頻度に基づいて、各請求者を示す点がプロットされる。
【００６５】
また、情報生成部１５は、不正精算候補者を示す情報として、各精算者の宿泊タイプの標準利用以外の請求頻度（予め定められている標準精算プランを利用しない頻度）と、当該宿泊による請求金額の合計に基づいた散布図を出力するようにしてもよい。
【００６６】
この場合、情報生成部１５は、精算データＤＢ１３の精算データを参照して、各精算者のカテゴリが宿泊となっているレコードを取得し、当該レコードにおける標準利用外のフラグ情報が設定さている数と、標準利用外のフラグ情報が設定さているレコードの金額の合計（請求金額の合計）を算出し、算出した結果に基づいて散布図を生成する。この散布図の場合、縦軸が請求金額の合計であり、横軸が頻度であり、当該請求金額と頻度に基づいて、各請求者を示す点がプロットされる。
【００６７】
ここで、図５に、情報生成部１５が生成する散布図の例を示す。図５に示すように、縦軸が請求金額の合計であり、横軸が頻度（回数）である。この場合、ポイント５に対応する精算者は、他の精算者と比較して、頻度は少ないものの、金額が高いことを示す。よって、ポイント５に対応する精算者は、不正精算者である可能性がある。また、ポイント６に対応する精算者は、他の精算者と比較して、頻度も金額も多い。この場合も、不正精算者である可能性がある。
【００６８】
このように、情報生成部１５は、頻度と、請求金額とに基づいた散布図を生成し、出力することにより、一見で不正精算している可能性がある精算者を特定し得る情報を提供することができる。
【００６９】
また、情報生成部１５は、出力先の端末装置において、散布図の各ポイントが選択されると、当該ポイントの不正精算者の精算データをさらに出力するようにしてもよい。例えば、情報生成部１５は、公知技術により、各ポイントと当該ポイントが示す精算者とを対応付けた散布図を出力する。情報生成部１５は、当該散布図においてあるポイントが選択されると、散布図において選択されたポイントが示す精算者を特定して、精算データＤＢ１３を参照し、当該精算者に対応する精算データを取得し、当該精算データを上記出力先の端末装置へ出力する。
【００７０】
また、情報生成部１５は、散布図以外に、頻度と請求金額とに基づいて、他の精算者の精算状況と比較し得る情報を出力するようにしてもよい。
【００７１】
なお、情報生成部１５は、散布図を、直近所定期間（例えば、１年）の精算データの履歴に基づいて作成する。また、情報生成部１５は、散布図ではなく、不正精算者の候補を特定して、出力するようにしてもよい。
【００７２】
情報生成部１５は、自身により生成された情報を用いて、精算パターンに基づいた条件に合致する精算をしている精算者へ、精算パターンに基づいた条件に合致する旨の通知をする。
【００７３】
上述では、精算者毎にフラグが設定されている数（フラグ数）を集計して、当該フラグ数が予め記憶している閾値以上となる精算者の精算データを経理部担当や各部署の管理職の端末装置へ送信出力する場合について述べた。これに代えて、情報生成部１５は、生成した情報を参照して、精算パターンに基づいた条件（例えば、手入力の比率が高い等）に合致する精算をしている精算者の端末装置３へ精算パターンに基づいた条件に合致する旨の通知をするようにしてもよい。当該通知として、例えば、カード利用ではなく、手入力による精算が多い傾向がある旨の警告などをする。また、当該通知として、例えば、標準精算プランを利用しない割合が高い傾向がある旨の警告をする。
【００７４】
このように、精算管理システム１は、不正精算または誤精算をしている可能性のあるユーザ２の端末装置３へ通知をすることで、不正発生を未然に防止することができる。
【００７５】
なお、情報生成部１５は、再生成された結果に基づき通知方法を変更するようにしてもよい。例えば、情報生成部１５は、一度通知済みの端末装置３のユーザ２が、再度精算パターンに基づいた条件に合致する精算をしている場合、通知メッセージを変更するようにしてもよい。例えば、精算管理システム１は、警告レベルを変えたメッセージを通知するようにしてもよい。または、精算パターンに基づいた条件に合致するユーザ数が増加傾向にあるなど、効果が見えない場合、情報生成部１５がフラグ情報を生成するタイミングを早めて、通知するタイミングを早めるようにするようにしてもよい。
【００７６】
このように、精算管理システム１は、通知した結果の後に、情報生成部１５により生成された情報を参照して、その結果により通知方法を変更することで、画一的に通知するだけでなく、通知した後の動向をウォッチして、その動向に応じて動的に通知方法を変更することで、不正発生を未然に防止することができる。
【００７７】
＜処理手順＞
図６は、本実施の形態における不正精算者の候補を示す情報を出力する処理の流れを示すフローチャートである。
【００７８】
まず、精算データ入力部１１は、端末装置３からの精算データの入力を受け付ける（Ｓ０１）。精算データ登録部１２は、当該精算データを精算データＤＢ１３に登録する（Ｓ０２）。所定のタイミングで、情報生成部１５は、精算データＤＢ１３に記憶されている精算データと、当該精算データの内容（カテゴリ）に対応する精算基準情報とを比較した結果に基づいて、フラグ情報を付与する（Ｓ０３）。
【００７９】
また、所定のタイミングにおいて、情報生成部１５は、当該フラグ情報等を集計し（Ｓ０４）、集計した結果に基づいて、精算パターンに基づいた条件に合致する精算をしている精算者の端末装置３へ精算パターンに基づいた条件に合致する旨の通知をする（Ｓ０５）。
【００８０】
図７は、本実施の形態における不正精算者の候補を示す情報として散布図情報を出力する処理の流れを示すフローチャートである。
【００８１】
まず、精算データ入力部１１は、端末装置３からの精算データの入力を受け付ける（Ｓ１１）。精算データ登録部１２は、当該精算データを精算データＤＢ１３に登録する（Ｓ１２）。所定のタイミングで、情報生成部１５は、精算データＤＢ１３に記憶されている精算データと、当該精算データの内容（カテゴリ）に対応する精算基準情報とを比較した結果に基づいて、フラグ情報を付与する（Ｓ１３）。
【００８２】
また、所定のタイミングにおいて、情報生成部１５は、不正精算候補者を示す情報として、各精算者の請求頻度と請求金額とに基づいた散布図を生成し（Ｓ１４）、当該散布図を経理部担当や各部署の管理職の端末装置へ送信出力する（Ｓ１５）。
【００８３】
上述の実施形態では特に述べなかったが、精算管理システム１が、予めユーザ２の住所情報を記憶して、当該住所情報に基づいてフラグ情報を生成するようにしてもよい。例えば、情報生成部１５は、支払先の住所と、ユーザ２の住所とを比較して、予め定めている基準距離を下回るか否かを判断して、下回る場合に私的利用の可能性がある旨の情報（フラグ情報）を付与するようにしてもよい。
【００８４】
上述の実施形態では特に述べなかったが、精算管理システム１が、予め互いに何らかの関連性（友人等）のあるユーザ２を定義した情報であるユーザ関連情報を記憶して、この情報に基づいてフラグ情報を生成するようにしてもよい。例えば、情報生成部１５は、
上記ユーザ関連情報で関連性があると定義されたユーザ２のそれぞれが同日支払日に精算請求している回数が多い場合、共謀して私的利用している可能性がある旨の情報（フラグ情報）を付与するようにしてもよい。
【００８５】
なお、上記のように関連性のあるユーザを特定する方法の一例として、特開２００９−１４００２９号公報に記載の技術を適用することが考えられる。
【００８６】
また、上述の実施形態では特に述べなかったが、精算管理システム１は、日当等、会社で上限が定められている精算内容についても、情報生成部１５が集計し、当該集計した結果に基づいて申請が適切であるか否かを判断し、判断した結果を出力するようにしてもよい。ここでいう日当とは、出張中に上限の範囲で請求可能なものである。
【００８７】
ここで図８に、上限３０００円とする日当の精算内容のグラフを示す。図８は、日当の精算の傾向を示す図である。図８に示すように、下限額である０円または上限額である３０００円を精算する者が多い傾向にある（グラフがフタこぶラクダ型になっている）。遠方の出張であれば、３０００円請求しても問題無いが、会社から近い場所でも３０００円を請求することは、日当の趣旨からして必ずしも適切なものではない。よって、常に上限額の申請をする精算者は、不正精算をしている可能性があると推定される。そこで、情報生成部１５が、日当の精算データについて、上限金額か否かを示すフラグ情報を生成するようにして、日当の精算件数全体に対する上限金額の請求数が多い精算者を判断し得る情報を出力するようにしてもよい。
【００８８】
この他にも様々な精算傾向の抽出パターンがあり得る。一例として、中間額（上限額と下限額の間の額）での精算頻度が多かった者が、業務に変化がないにもかかわらず、ある時点から上限額での精算頻度が多くなってきたら要注意である。実使用額のみ経費申請していた者が上限額一杯まで架空の経費を精算申請してくるようになったと推定されるからである。このように、ある時点での精算傾向だけでなく、時系列の精算傾向の変化に着目することが不正精算の抑止発見につながる。
【００８９】
なお、日当の精算データについて、出張先を示す情報も対応付けて、出張先が近いにも関わらず上限金額の日当を請求しているか否かを示すフラグ情報を生成するようにしてもよい。
【００９０】
また、上述の実施形態では特に述べなかったが、精算管理システム１は、予めユーザ２の顔画像を含むユーザ情報を記憶しておき、この情報に基づいてフラグ情報を生成するようにしてもよい。
【００９１】
例えば、精算管理システム１は、飲み会等の集団参加の請求の精算データとして、参加者の氏名と集合写真の画像を取得し、精算データＤＢ１３に登録する。情報生成部１５は、当該集合写真から顔部分を特定する。そして、情報生成部１５は、当該顔部分とユーザ情報の顔画像とを公知技術の画像解析処理により比較して、出席者を特定し、特定した結果と申請の参加者とを比較して、申請が適切か否かを判断し、不適切であれば、不正申請である旨の情報（フラグ情報）を付与するようにしてもよい。
【００９２】
また、上述の実施形態では特に述べなかったが、不正精算者と特定したユーザ２の過去の精算データの結果に基づいて、請求傾向を特定し、特定した結果に基づいて、不正請求の蓋然性のあるユーザ２を特定するようにしてもよい。
【００９３】
例えば、情報生成部１５が生成した散布図に基づいて指定された不正精算者を記憶する。情報生成部１５は、当該不正精算者の精算データの過去の精算データの傾向を特定し、当該傾向を示す情報を記憶する。例えば、情報生成部１５は、精算頻度の変化や請求額の変化傾向を示す情報を記憶する。情報生成部１５は、バッチ処理により、精算データが上記傾向に対応するユーザ２が不正精算者となる可能性があることを示す情報を出力する。
【００９４】
また、上述の実施形態では特に述べなかったが、精算データ入力部１１は、精算データとして、タクシー、交際費等の領収書の画像データの入力を受け付けるようにしてもよい。この場合、精算データ入力部１１は、当該画像データを画像解析した結果と、入力された金額等とを比較して入力された値が適切か否かを判断してもよい。
【００９５】
また、上述の実施形態では詳細を述べなかったが、予め各ユーザ２の出退勤の情報（業務時間データ）を記憶しておき、情報生成部１５が、この情報に基づいてフラグ情報を生成するようにしてもよい。すなわち、精算管理システム１は、上述の業務時間データとのマッチングをしてもよい。あるいは、会社より貸与した携帯電話やスマートフォンの位置と時間の情報とマッチングしてもよい。
【００９６】
例えば、情報生成部１５は、請求内容がタクシーや電車に関するものであり、支払時刻が、出退勤の時刻とあまりに異なる場合に、私的利用の可能性がある旨の情報（フラグ情報）を付与するようにしてもよい。例えば、出退勤の情報に基づくと、精算データの支払日に、ユーザ２が定時（例えば、１８時）に退勤しているにも関わらず、タクシー利用の精算データの支払い時刻が２２時である場合に、情報生成部１５は、フラグ情報を生成する。
【００９７】
また、精算管理システム１は、説明の便宜上１台のサーバ装置で実現する例を説明したが、複数台のサーバ装置等の情報処理装置で実現するようにしてもよい。例えば、精算データＤＢ１３に記憶されている精算データと、精算基準データＤＢ１４に記憶されている精算基準情報とを用いて、フラグ情報を生成する機能を有するサーバ装置と、精算データＤＢ１３に記憶されている精算データを用いて散布図を生成するサーバ装置とを別々に構成するようにしてもよい。
【００９８】
以上説明したように、精算管理システム１によれば、精算データ入力部１１により入力された精算データを登録し、精算データを集計して、所定の精算パターンに基づいた条件に合致する精算をしている精算者を示す情報を生成する。このように、精算管理システム１は、精算データを集計して、所定の精算パターン（例えば、手入力している）に基づいた条件（例えば、手入力の頻度が１００回中８０回等）に合致する精算者を示す情報を出力するので、容易に不正精算候補者をより精度よく特定し得る。すなわち、精算管理システム１は、不適切な精算者をより精度よく特定可能な情報を提供することができる。
【００９９】
上述の精算管理システム１は、カード（クレジットカードや交通ＩＣカード）に基づいて得られる情報を用いて精算をするので、確かな情報（正式に決済がなされたことを示す情報）と連携（データ連携）して精算することができ、精算者が容易に入力することができる（入力レス）。また、精算管理システム１は、上記のようなデータ連携により精算することにより、精算データの透明性を高めることができ、この結果、従来の承認処理を省略・簡略化することを可能としている。
【０１００】
また、精算管理システム１は、カードに基づいて得られるデータのみで精算することも考えられるが、カードが使用できない場合もあり、手入力による精算も認めないと、精算者の利便性を欠く。そこで、精算管理システム１は、手入力による精算も認める運用をしている。ただし、手入力による精算は、不正精算の可能性が高いので、精算管理システム１は、手入力による精算が多い精算者へは、事後に個別に通知することで、承認の省略（承認レス）・簡略化を実現する。
【０１０１】
そもそも、カードに基づいたデータによる精算を基本とすることで、全体のデータの透明性を高めているので、明るくないルートを通る人（不正精算の蓋然性の高い精算者）を特定しやすいように精算データを管理することができる。結果として、従来の事前承認制の場合以上の効果を得ることができる。精算管理システム１は、いわゆる不正の３要素（動機・機会・正当化）のうち、データ連携した精算をすると共に、事後チェックすることで、不正の機会を与えないようにするシステムを実現することができる。
【０１０２】
また、精算管理システム１は、手入力の頻度が高い精算者や標準プランを避けている精算者に対して警告をすることで、警告した精算者以外にも波及させる効果（割れ窓効果）も発揮することができる。このように、精算管理システム１は、アクションに対して相手がどのように、リアクションするかという影響に基づいて不正を事前検知し、不正の未然防止を実現することができる。
【０１０３】
また、精算管理システム１によれば、精算データ入力部１１により入力された精算データを登録し、当該精算データの精算内容（カテゴリ）について、各精算者の請求頻度と請求金額とに基づいた不正精算候補者を示す情報を、精算データＤＢ１３に登録された精算データを用いて生成し、当該情報を出力する。このように、精算管理システム１は、請求頻度と請求金額とに基づいた情報を出力するので、容易に不正精算候補者を特定し得る。すなわち、精算管理システム１は、不正精算者を特定可能な情報を提供することができる。
【０１０４】
また、精算管理システム１は、請求頻度と請求金額とに基づいた情報から請求者の請求データをさらに出力するので、不正精算候補者の精算データを確認させることができ、より具体的に不正精算の有無を判断可能な情報を提供することができる。
【０１０５】
また、精算管理システム１は、精算者の請求頻度と請求金額とに基づいた散布図を出力するので、一見して不正精算者を特定し得る情報を提供することができる。
【０１０６】
また、精算管理システム１は、標準精算プランを利用しない頻度と、当該標準精算プランを利用しない場合の請求金額とに基づいた情報を出力することにより、不正精算の蓋然性が高い例外請求に着目した結果を出力するので、より確実に不正精算候補者を特定し得る情報を出力することができる。
【０１０７】
また、精算管理システム１によれば、精算データ入力部１１により入力された精算データを登録し、精算基準データＤＢ１４で請求内容ごとに、当該精算に関する基準を定めた精算基準情報を記憶し、登録された精算データと、精算基準情報とを比較した結果に基づいた情報を生成し、当該情報を出力する。このように、精算管理システム１は、精算基準情報と精算データとを比較した情報を出力することで、不正精算者候補を特定し得る情報を出力することができる。
【０１０８】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【０１０９】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１１０】
また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
【産業上の利用可能性】
【０１１１】
本発明は、精算データを管理する精算管理システムに利用可能である。
【符号の説明】
【０１１２】
１…精算管理システム、２…ユーザ、３…端末装置、１１…精算データ入力部、１２…精算データ登録部、１３…精算データＤＢ、１４…精算基準データＤＢ、１５…情報生成部。
【図１】
2020030799.tif 000003
【図２】
2020030799.tif 000004
【図３】
2020030799.tif 000005
【図４】
2020030799.tif 000006
【図５】
2020030799.tif 000007
【図６】
2020030799.tif 000008
【図７】
2020030799.tif 000009
【図８】
2020030799.tif 000010