特開 2024-165219 取引承認方法、取引承認プログラム及び取引承認システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024165219

(43)【公開日】2024-11-28

(54)【発明の名称】取引承認方法、取引承認プログラム及び取引承認システム

(51)【国際特許分類】

   G06Q 10/0633 20230101AFI20241121BHJP

【ＦＩ】

G06Q10/0633

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023081167

(22)【出願日】2023-05-17

(71)【出願人】

【識別番号】712005584

【氏名又は名称】株式会社Ｄｏｎｕｔｓ

(74)【代理人】

【識別番号】230116539

【弁護士】

【氏名又は名称】恩田 俊明

(72)【発明者】

【氏名】西村 啓成

【テーマコード（参考）】

5L010

5L049

【Ｆターム（参考）】

5L010AA07

5L049AA07

(57)【要約】      （修正有）

【課題】事業者内で特定の事業者との取引の当否を判断するにあたり、決裁権者がワークフロー上で、定量的な見地から取引の適否判断をすることを容易にする取引承認方法、取引承認プログラム及び取引承認システムを提供する。
【解決手段】処理をコンピュータを用いて実行する取引承認システムは、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける。取引ＩＤ取得部と、前記取引と関連する適格請求書発行事業者登録番号を取得する番号取得部と、当該取得結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する処理結果出力部と、を備える。
【選択図】図５

【特許請求の範囲】

【請求項1】

事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける取引ＩＤ取得ステップと、
前記取引と関連する適格請求書発行事業者登録番号を取得する番号取得ステップと、
番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する処理結果出力ステップと、
をコンピュータを用いて実行する取引承認方法。

【請求項2】

処理結果出力ステップの出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断を受け付ける承認受付ステップと、
前記判断結果を、前記取引ＩＤの入力元であるユーザに対し出力する判断結果出力ステップと、
をさらに有する請求項１に記載の取引承認方法。

【請求項3】

番号取得ステップの処理結果と、前記取引ＩＤと紐づく他の情報とを用いて取引当否判断のためのスコアリングを行うスコアリング処理ステップをさらに有し、
処理結果出力ステップは、前記番号取得ステップの処理結果とともに前記スコアリング結果をも出力するスコア出力サブステップをさらに有する請求項１に記載の取引承認方法。

【請求項4】

取引ＩＤ取得ステップは、
所定の取引における目的とともに取引ＩＤの入力を受け付ける目的取得サブステップをさらに有する請求項１に記載の取引承認方法。

【請求項5】

事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける取引ＩＤ取得ステップと、
前記取引と関連する適格請求書発行事業者登録番号を取得する番号取得ステップと、
番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する処理結果出力ステップと、
をコンピュータにて実行可能とする取引承認プログラム。

【請求項6】

事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける取引ＩＤ取得部と、
前記取引と関連する適格請求書発行事業者登録番号を取得する番号取得部と、
番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する処理結果出力部と、
を有する取引承認システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、事業者間で行われる取引に関し一方事業者内での取引承認に資する方法などに関する。

【背景技術】

【0002】

事業者においては、日々の取引を行うなかで、特に取引相手が新規の取引先である場合には、当該取引の妥当性を内部で検討することが少なくない。事業者内の決裁権者としては、与信判断や反社チェックなどの検討結果を踏まえて当該取引を承認すべきか否かの判断をすることになり、従来から、当該判断を支援するための各種の技術が構想されてきた。具体的には、特許文献１記載のように、サプライチェーン上に連なるような関連性を有する者に関するウェブページを抽出して表示可能とするための技術が開示されている。当該技術を用いることで、事業者内における取引当否検討のための情報収集を支援することができる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２０－１６６５０６号

【発明の概要】

【発明が解決しようとする課題】

【0004】

ただ、こうした技術を用いたとしても、そこで収集される情報によって推し量れる自社への事業上の影響は「リスクがあるかどうか」といった定性的なものであることが多く、定量的な評価が極めて困難だった。

【課題を解決するための手段】

【0005】

以上のような課題を解決すべく、本発明は、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける取引ＩＤ取得ステップと、前記取引と関連する適格請求書発行事業者登録番号を取得する番号取得ステップと、番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する処理結果出力ステップと、をコンピュータを用いて実行する取引承認方法などを提案する。

【0006】

また、上記発明に関連して、処理結果出力ステップの出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断を受け付ける承認受付ステップと、前記判断結果を、前記取引ＩＤの入力元であるユーザに対し出力する判断結果出力ステップと、をさらに有する取引承認方法をも提案する。

【0007】

また、上記発明に関連して、番号取得ステップの処理結果とともに、前記取引ＩＤと紐づく他の情報を用いて取引当否判断のためのスコアリングを行うスコアリング処理ステップをさらに有し、処理結果出力ステップは、前記処理結果とともに前記スコアリング結果をも出力するスコア出力サブステップをさらに有する取引承認方法なども提案する。

【0008】

また、取引ＩＤ取得ステップが、所定の取引における目的とともに取引ＩＤの入力を受け付ける目的取得サブステップをさらに有する取引承認方法なども提案する。

【0009】

さらに、上記各方法に関連したプログラムやシステムなどに関する発明も提案する。

【発明の効果】

【0010】

主に以上のような構成をとる本発明によって、決裁権者がワークフロー上で、定量的な見地から取引の適否判断をすることが容易になる。

【図面の簡単な説明】

【0011】

【図1】本発明のシステムの概略図

【図2】実施形態１のシステムの機能ブロックの一例を示す図

【図3】取引ＩＤ取得部にて取得される取引ＩＤの保持の一例を示す図

【図4】実施形態１のシステムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図

【図5】実施形態１のシステムにおける処理の流れの一例を示す図

【図6】実施形態２のシステムの機能ブロックの一例を示す図

【図7】実施形態２のシステムにおける処理の流れの一例を示す図

【図8】実施形態３のシステムの機能ブロックの一例を示す図

【図9】実施形態３のシステムにおける処理の流れの一例を示す図

【発明を実施するための形態】

【0012】

まず図１を示す。図１は本発明の概要を示す図である。同図に示されているように、本発 明は、一又は複数のサーバコンピュータ０１０１、０１０２と、事業者における決裁権者が管理する端末（決裁者端末）０１１１や前記決裁権者とは別の権限を有する者が管理する端末（従業者端末）０１１２、０１１３などとの間で行われるネットワークを介した情報の送受信を通じて実現されうる。

【0013】

なお、さきに述べたとおり、本発明は一又は複数のサーバコンピュータ０１０１、０１０２により実現されうる。複数のサーバコンピュータを用いる場合の具体例を上げると、取引相手の与信情報や反社チェックの結果、具体的な取引実績など取引内容を特定の取引相手と紐づけて格納する取引相手管理データベースサーバや、事業者内におけるワークフローその他の業務遂行を管理するための業務管理サーバなどが相互にオンライン又はオフラインのネットワークを介して接続することで用いることが考えられる。また、これらのサーバコンピュータは、外部のサーバコンピュータ０１２１、０１２２（例えば、適格請求書発行事業者登録番号を管理する国税庁のサーバ等であったり、取引相手の管理する端末である取引相手端末であったりしうる）とオンラインにて接続されていてもよい。

【0014】

次に、本発明を実現する各種コンピュータと接続される各種端末については、その種別を特に限定することはなく、例えば、パソコン０１１１、０１１３やスマートフォン０１１２などが考えられ、その他にもタブレットや各種ワークフロー管理端末といったように、事業場所にて取引遂行の意思決定のために用いられうる各種端末などが考えられる。

【0015】

なお、ここまでは図１を用いて、サーバコンピュータ０１０１、０１０２が決裁者端末０１１１とは別個に構成され、ネットワークを介しクラウドコンピューティングの形式にて提供されているケースを想定した説明を行ったが、本発明はかかる使用形態に限られるものではない。すなわち、本発明の機能を実行可能なプログラムを決裁者端末にインストールすることにより、本発明において提供可能な機能の全部又は一部の処理を決裁者端末において実行する、いわゆるオンプレミス型の形態にて提供されてももちろんよい。また、ここで述べたようなプログラムが格納された記録媒体を用いることによっても実現可能である。

【0016】

以下、本発明の各実施形態について図面とともに説明する。まず実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態１は主に請求項１、４、５、６などに対応する。実施形態２は主に請求項２などに対応する。実施形態３は主に請求項３などに対応する。ただし、各実施形態にて説明する技術的特徴は、他の実施形態にて説明する技術的特徴と組み合わせて用いられることも可能である。

【0017】

なお、本発明はこれらの実施形態に何ら限定されるものではなく、技術常識に従って特許請求の範囲の各請求項に記載の技術的思想を有し、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。

【0018】

＜＜実施形態１＞＞
＜概要＞
図２は、本実施形態の取引承認システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「取引承認システム」０２００は、「取引ＩＤ取得部」０２０１と、「番号取得部」０２０２と、「処理結果出力部」０２０３と、を有する。

【0019】

なお、以下で詳しく説明する取引承認システムは、その機能の一又は複数の機能を複数の装置にて実現するようにも構成され得るものであって、その機能ブロックは、いずれもハードウェア又はソフトウェアとして実現され得る。コンピュータを用いるものを例にすれば、ＣＰＵやメインメモリ、ＧＰＵ、ＴＰＵ、画像メモリ、バス、二次記憶装置（ハードディスクや不揮発性メモリ）、キーボードやマイク、タッチパネル、タッチパネルをタッチするための電子ペン、各種端末などの各種入力デバイス、スピーカ、ディスプレイその他各種出力デバイス、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインタフェース、通信用インタフェース、それらのハードウェアを制御するためのドライバプログラムやその他のアプリケーションプログラムなどが挙げられる。

【0020】

そしてメインメモリ上に展開したプログラムに従った演算処理によって、入力デバイスやその他インタフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が作成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムをクラウドコンピューティングその他の方法により組み合わせて一のプログラムとして実現されても良い。

【0021】

＜機能的構成＞
「取引ＩＤ取得部」０２０１は、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付けるように構成されている。ここで受け付ける取引ＩＤは、同じタイミングあるいは予め、所定の取引を識別可能にするための情報と紐付けられる識別子であって、具体的には、取引相手となる事業者や、取引目的、取引の費目、取引金額、取引時期その他取引を特定するために有用と考えられる情報を紐づけることが考えられる。

【0022】

ここで図３を示す。同図に示されているのは、取引ＩＤ取得部にて取得される取引ＩＤの保持の一例である。当該記録は、本発明において用いられるサーバにて適宜のタイミングで取得され、編集され、削除されうる。同図では、Ｓ１０４２３ないしＳ１０４２７との番号にて識別される取引ＩＤが、取引相手、取引目的、費目、金額（見込／確定）、取引時期などの情報と紐付けられて記録されている様子が示されている。事業者内の所定の権限を有するユーザによって、これらの情報が取引ＩＤを介して取得対象として特定されることとなる。同図に示された例のうち一つを挙げると、取引ＩＤ「Ｓ１０４２４」の入力を受け付けると、当該取引ＩＤと紐づけて保持されている情報として、取引相手が「オフィスＱ」、取引目的が「顧客」、費目が「サービス提供」であって、取引金額が「９６０，０００円」、取引開始時期が「２０２０年８月」といった具合である。

【0023】

ここで更に細かく、図３に示されている項目に関し、所定の取引における目的の入力を直接又は間接的に受け付ける一例を説明する。同図に示されている取引目的として「顧客」「仕入／調達」とあるが、このように取引の目的の入力を受け付けることにより、自己が取引の供給者側なのか、需要者側なのかの立場を明確にすることができる。取引の目的は、予め供給者側、需要者側のいずれの立場であるかの選択を受付可能な構成を通じてその入力を受け付けるような構成もあれば、ユーザにより任意に入力された取引目的に関するキーワード（例えば、「仕入」「購入」「販売」「トライアル」など）の入力を受付け、当該受け付けたキーワードから上記いずれの立場であるかを推測する処理を行い、当該処理結果の入力を受け付けるような構成、それらを組み合わせて利用する構成などが考えられる。

【0024】

なお、消費税が課税される取引においては、我が国の税制度上「仕入税額控除」と言う仕組みが採用されている（後述する）ところ、同控除の適用を受け一定の税制面・金銭面での恩恵に預かることができるのは、基本的に当該取引における需要者側である。つまり、特に需要者側にて取引を行おうという場合、仕入税額控除の適用が受けられるか否かは、当該取引における税負担、ひいては定量的な事業インパクトを推し量る上で有用な情報である。そのため、当該取引の目的に関する情報が直接又は間接的に取得され、決裁権者による判断の材料として用いられることが望ましい。

【0025】

なお、取引ＩＤ取得部では、取引ＩＤそのものの入力を受け付ける場合もあれば、図３や上記にあるように、取引ＩＤと紐づいて記録される各種の情報の入力を受け付けることで、間接的に取引ＩＤを取得するような場合もここでいう「所定の取引を識別する取引ＩＤの入力を受け付ける」処理に含まれる。図３に示されるようなデータベースを用いて特定の取引条件の取引相手を識別できるような情報を選択可能とし、当該選択に応じて所定の取引を識別可能な構成を採用することにより、取引相手の数が多い事業者においても、煩雑な管理コストをかけることなく本発明を実施することが可能となる。

【0026】

ちなみに、ユーザに関する事業者内の所定の権限の有無やその内容は、当該ユーザによる本システムの利用アカウントを登録する際に予め設定され、記録され、変更可能にされている。所定の権限としては、特定金額以上の取引であったり、特定目的あるいは特定費目の取引を扱うことができる権限などが考えられ、それらの権限の種別や内容が取引ＩＤの入力を行うユーザと紐付けられることにより、当該ユーザがそもそも、当該取引の決裁承認を求める資格があるのかを予め判断することができ、決裁権者において取引内容そのもの以外に検討すべき事項を限定しておくことができる。

【0027】

「番号取得部」０２０２は、前記取引と関連する適格請求書発行事業者登録番号を取得するように構成されている。適格請求書とはインボイスとも呼ばれ、消費税の分野にて仕入税額控除が認められる取引か否かを識別するために用いられる仕組みである。具体的には、適格請求書を発行可能な事業者として国税庁に登録を行っていれば、当該事業者が摘式に発行した適格請求書を用いてなされた取引については仕入税額控除が受けられ税制面での優遇を受けられることになる。当該優遇の適用有無によって事業者にとって納める消費税額が変化することになり、端的に言えば、適格請求書を発行していない事業者との取引では、発行している事業者に比べ、上記優遇を受けられない分事業上の利益が圧縮されることになる。取引金額が多ければ多いほど、あるいは取引頻度が多ければ多いほど、上記利益圧縮の事業上のインパクトは無視できなくなるため、決裁権者としては、当該取引を承認することをネガティブに捉えることとなる。

【0028】

所定の取引と関連する適格請求書発行事業者登録番号を取得する具体的な方法としては、当該取引ＩＤと直接又は間接的に紐付けられる事業者の連絡先に、適格請求書発行事業者登録番号の有無及び当該番号を確認する通知を送信し、当該通知への応答により取得したり、国税庁その他の第三者が管理するサーバに保持されている適格請求書発行事業者登録番号の検索が可能な外部システムをＡＰＩその他の連携を通じて用いて取得したりする方法が考えられる。当該構成を採用することで、アナログな聞き取りなどの煩雑な対応を要することなく、決裁権者にて、対象となる取引において仕入税額控除の恩恵を受けることの有無を把握することが可能となる。

【0029】

「処理結果出力部」０２０３は、番号取得部での処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力するように構成されている。ここで出力対象となる処理結果としては、取引ＩＤと紐付けられる事業者の適格請求書発行に関する登録番号そのものであるほか、当該登録番号を有しているか否か（検索処理の結果ヒットしたか否かや、前記事業者の連絡先に対する通知からの応答があったか否かなど、間接的に登録番号の有無を推認可能な処理結果を含む）を認識可能な情報が広く含まれうる。当該構成を採用することにより、決裁権者に対し、特定の取引を進めることの当否判断において、仕入税額控除の適用有無を容易に把握させ、ひいては当該情報を踏まえた定量的な観点からの決裁判断を支援することが可能となる。

【0030】

ちなみに、上記効用の観点から、番号取得部での処理結果は、前記取引ＩＤと紐づけられるほか、その他決裁判断に資する他の情報とともに出力することを妨げるものではない。例えば、当該取引の取引金額をもとに、当該取引において仕入税額控除の適用がある場合の節税額その他の節税効果を算出して出力したり、過去に同事業者において行われた同種取引（図３に示された情報のうち「費目」や「取引時期」などの情報から推測する方法などが考えられる）と比較して、上記節税効果の有無又は節税規模などを算出して出力したりする方法なども考えられる。過去に記録され保持されている取引ＩＤと紐付けられた取引に関する情報をも用いて出力する当該構成を採用することにより、決裁権者に対し、経時的な要素を踏まえた定量的な事業インパクトを踏まえた観点からの決裁判断を支援することが可能となる。

【0031】

＜具体的な構成＞
ここで図４を示す。同図は本実施形態の取引承認システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図である。各装置はいずれも、それぞれ各種演算処理を実行するための「ＣＰＵ」０４０１と、「記憶装置（記憶媒体）」０４０２と、「メインメモリ」０４０３と、「入出力インタフェース」０４０４、「ネットワークインタフェース」０４０５と、を備え、入出力インタフェースを介して、例えば「キーボード」０４０６などの外部周辺装置と情報の送受信を行う。

【0032】

また、本実施形態の取引承認システムは、ネットワークインタフェースを介して複数の「決裁者端末」０４０７や「従業者端末」０４０８、あるいは外部にて各種処理を行う「外部サーバ」０４０９などの外部装置と情報の送受信を行いうる。このネットワークインタフェースの具体的な態様は有線、無線を問わず、また通信の方法も、両端末間で直接、間接なされるかを問わない。よって特定の外部装置ないし同装置の利用者と紐づけられた第三者の管理するサーバとの間で情報の送受信を行ういわゆるクラウドコンピューティングの形式を採用することも可能である。

【0033】

記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０４９９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う（以上の構成の基本的な構成は、以下で説明する他の装置のいずれについても同様である。

【0034】

（取引ＩＤ取得部の具体的な構成）
取引ＩＤ取得部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「取引ＩＤ取得プログラム」０４１０をメインメモリに読み出して実行し、事業者内の所定の権限を有するユーザの操作する端末から、所定の取引を識別する取引ＩＤの入力を受け付け、メインメモリの所定のアドレスに格納する。

【0035】

なお、このとき、前記所定ＩＤとともに前記所定の取引における目的の入力を受け付けるような処理を行ってもよく、その場合には、当該処理により受付けた情報もまた、メインメモリの所定のアドレスに格納する。

【0036】

（番号取得部の具体的な構成）
番号取得部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「番号取得プログラム」０４２０をメインメモリに読み出して実行し、前記取引と関連する適格請求書発行事業者登録番号を外部のサーバとの情報の送受信を通じるなどして取得し、メインメモリの所定のアドレスに格納する。

【0037】

（処理結果出力部の具体的な構成）
処理結果出力部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「処理結果出力プログラム」０４３０をメインメモリに読み出して実行し、番号取得プログラムの実行を通じて行った処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザの管理する端末に対し出力する。

【0038】

＜処理の流れ＞
図５は、本実施形態の取引承認システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０５０１では、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける（取引ＩＤ取得ステップ）と、ステップＳ０５０２として、前記取引と関連する適格請求書発行事業者登録番号を取得するための処理を行う（番号取得ステップ）。そしてステップＳ０５０３では、番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する（処理結果出力ステップ）。

【0039】

ちなみに、取引ＩＴ取得ステップにおいては、所定の取引における目的とともに取引ＩＤの入力を受け付ける（目的取得サブステップ）処理を行う場合もあり、例えば、同処理の結果、当該取引が需要者側ではなく供給者側にて行われる予定のものであるとの判定が可能な場合には、以後の番号取得ステップを行わずに、当該判定結果を処理結果出力ステップにて出力するような構成があってもよい。当該構成を採用すれば、番号取得ステップに要する時間やコストの省力化が図れ、決裁権者による迅速な意思決定を支援可能となる。

【0040】

＜効果＞
以上の構成を採用する取引承認システムを利用することにより、決裁権者がワークフロー上で、定量的な見地から取引の適否判断をすることが容易になる。

【0041】

＜＜実施形態２＞＞
＜概要＞
本実施形態の取引承認システムは、基本的には実施形態１に記載の取引承認システムの技術的特徴と同様であるが、処理結果の出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断を受け付け、当該判断結果を前記取引ＩＤの入力元であるユーザに対し出力する点において更なる特徴を有している。

【0042】

＜機能的構成＞
図６は、本実施形態の取引承認システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「取引承認システム」０６００は、「取引ＩＤ取得部」０６０１と、「番号取得部」０６０２と、「処理結果出力部」０６０３と、「承認受付部」０６０４と、「判断結果出力部」０６０５と、を有する。基本的な構成は、実施形態１の図２を用いて説明した取引承認システムと共通するため、以下では相違点である「承認受付部」０６０４と「判断結果出力部」０６０５の機能について説明する。

【0043】

「承認受付部」０６０４は、処理結果出力部における出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断を受け付けるように構成されている。実施形態１にて度々言及してきた、決裁権者による決裁処理のいち態様であり、決裁権者による、決済端末の操作入力を通じた受付処理という以外に、当該判断がどのように示されるかについては特に限定を付さない。敢えて一例を挙げるとすれば、当該取引を承認するかしないかのみの意思表示に関する情報のほか、当該取引における定量的な確認事項を付した意思表示（例えば、値下げの可否や許容可能な金額変動幅等に関する情報、予算を踏まえた取引時期の調整等）とともに示された判断を受け付けるような構成が考えられる。当該構成を採用することで、決裁権者の意思を簡易迅速に周知することが可能となる。

【0044】

「判断結果出力部」０６０５は、前記承認受付部における判断結果を、前記取引ＩＤの入力元であるユーザに対し出力するように構成されている。予め登録されている当該ユーザの連絡先に対するメール送信や、本システム上のメッセージ機能を通じたメッセージ出力など、出力態様は特に問わないが、いずれにしても当該構成を採用することにより、取引を行うか否かの決裁権者の意思を、当該取引の承認を申請した従業者に対して迅速に伝えることができるようになる。

【0045】

なお、当該判断結果を、前記ユーザに出力するとともに、図３で示したように、取引ＩＤと紐づけて記録する構成があってもよい。当該構成を採用すれば、別の機会に検索処理などをすることにより、ある取引に関する決裁処理の過程を容易に把握することができ、従業者においても、同様の取引を行うに際して、決裁権者に対し不要な負荷をかけることのないよう、事前準備のうえ決裁の承認申請を行うことができるようになる。

【0046】

＜具体的な構成＞
本実施形態の取引承認システムを構成する各装置のハードウェア構成は、基本的には、図４を用いて説明した実施形態１の取引承認システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「承認受付部」及び「判断結果出力部」の具体的な処理について説明する。

【0047】

（承認受付部の具体的な構成）
承認受付部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「承認受付プログラム」をメインメモリに読み出して実行し、処理結果出力プログラムの実行による情報の出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断を受け付け、当該判断結果をメインメモリの所定のアドレスに格納する。

【0048】

（判断結果出力部の具体的な構成）
判断結果出力部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「判断結果出力プログラム」をメインメモリに読み出して実行し、前記判断結果を読み出すとともに、前記取引ＩＤの入力元であるユーザの管理する端末に対し出力する。

【0049】

＜処理の流れ＞
図７は、本実施形態の取引承認システムにおける処理の流れの一例を示す図である。同図の処理の流れは、以下のステップからなる。最初にステップＳ０７０１では、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける（取引ＩＤ取得ステップ）と、ステップＳ０７０２として、前記取引と関連する適格請求書発行事業者登録番号を取得するための処理を行う（番号取得ステップ）。そしてステップＳ０７０３では、番号取得ステップの処理結果を、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する（処理結果出力ステップ）。

【0050】

その後、ステップＳ０７０４として、処理結果出力ステップでの出力先から、前記取引ＩＤにて識別される取引を承認するか否かの判断が出力されたかどうかを判断し、そこでの判断結果が出力されたとの内容である場合には、ステップＳ０７０５として、当該出力内容を、前記取引ＩＤの入力元であるユーザに対し出力する（判断結果出力ステップ）。判断結果が出力されたとの内容でない場合には、その後の処理を行わない。

【0051】

＜効果＞
本実施形態の取引承認システムを用いることにより、実施形態１の取引承認システムを用いる場合に比べて、決裁権者の意思を迅速かつ明確に承認申請をした従業者に伝達することが可能となる。

【0052】

＜＜実施形態３＞＞
＜概要＞
本実施形態の取引承認システムは、基本的には実施形態１に記載の取引承認システムの技術的特徴と同様であるが、番号取得部における処理結果と、前記取引ＩＤと紐づく他の情報とを用いて取引当否判断のためのスコアリングを行い、処理結果出力部にて、前記番号取得部における処理結果とともに前記スコアリング結果をも出力するスコア出力サブステップをさらに有する点を更なる特徴として備えている。

【0053】

＜機能的構成＞
図８は、本実施形態の取引承認システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「取引承認システム」０８００は、「取引ＩＤ取得部」０８０１と、「番号取得部」０８０２と、「処理結果出力部」０８０３と、「スコアリング処理部」０８０４と、を有し、処理結果出力部は、「スコア出力手段」０８１３をさらに有する。基本的な構成は、実施形態１の図２を用いて説明した取引承認システムと共通するため、以下では相違点である「スコアリング処理部」０８０４と「スコア出力手段」０８１３の機能について説明する。

【0054】

「スコアリング処理部」０８０４は、番号取得部での処理結果と、前記取引ＩＤと紐づく他の情報とを用いて取引当否判断のためのスコアリングを行うように構成されている。ここでいう他の情報とは、これまでも説明してきた、図３にて示された取引相手や取引目的、費目、取引金額や取引時期などの情報であることが考えられるが、その他にも例えば、当該取引相手に関連する情報を間接的に用いることも含まれる。例えば、当該取引相手との従来の取引実績や、当該取引相手に関するプレスリリースその他の報道、当該取引相手の競合事業者によるプレスリリースその他の報道などである。これらの情報をも用いることで、取引当否の判断に資するような分析の精度向上を図ることができる。

【0055】

なお、ここでいうスコアリングについて、具体的な処理態様や処理手段は特に問わない。上述したような定性的な情報を定量的な情報に変換するために一般的に用いられる態様であれば様々な手法がとられてよい。例えば、各種定性的な情報に関しては、その内容や種別について予め重み付けのための設定をしておくとともに、特定の取引ＩＤと紐づけて取得された情報に関し、当該重み付け処理を行ったうえで、所定のルールに基づいたり、人工知能に基づく分析を行ったりすることによりスコアリング処理を行う。

【0056】

なお、上記特定の取引ＩＤと紐づく情報のほか、事業者内部の情報をも用いてスコアリングを行う構成があってもよい。例えば、事業者の当期売上や予算消化率、各種設定済みのＫＰＩ達成度合いなどの定量的な情報を事業者にて管理するサーバから取得して、前記スコアリングに用いるような構成が考えられる。当該構成を採用することにより、一般的抽象的な決裁判断を超え、事業者における当該時点の取引当否を検討するに資するような情報を提供することが可能となる。

【0057】

「スコア出力手段」０８１３は、処理結果出力部にて、前記番号取得部での処理結果とともに前記スコアリング結果をも出力するように構成されている。スコアリング結果は、定量的な情報として提示されることが望ましく、例えば「本取引に伴う節税効果は●●円相当で、取引許容度８０％」とか、「仕入税額控除が適用されず、過去の取引実績もＤランク」などと言った具合である。仕入税額控除適用の有無以外の要素についても定量的な情報を提供する当該構成を採用することで、決裁権者による、より直感的な決裁判断を支援することができる。

【0058】

＜具体的な構成＞
本実施形態の取引承認システムを構成する各装置のハードウェア構成は、基本的には、図４を用いて説明した実施形態１の取引承認システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「スコアリング処理部」及び「スコア出力手段」の具体的な処理について説明する。

【0059】

（スコアリング処理部の具体的な構成）
スコアリング処理部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「スコアリング処理プログラム」をメインメモリに読み出して実行し、番号取得プログラムの実行結果と前記取引ＩＤと紐づく他の情報を用いて取引当否判断のためのスコアリングを行い、当該処理結果をメインメモリの所定のアドレスに格納する。

【0060】

（スコア出力手段の具体的な構成）
スコア出力手段は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、処理結果出力プログラムの実行に際し、ＣＰＵが記憶装置から「スコア出力サブプログラム」をメインメモリに読み出して実行し、番号取得プログラムの実行結果とともに前記スコアリング結果をも出力する。

【0061】

＜処理の流れ＞
図９は、本実施形態の取引承認システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０９０１では、事業者内の所定の権限を有するユーザから、所定の取引を識別する取引ＩＤの入力を受け付ける（取引ＩＤ取得ステップ）と、ステップＳ０９０２として、前記取引と関連する適格請求書発行事業者登録番号を取得するための処理を行う（番号取得ステップ）。

【0062】

次にステップＳ０９０３として、番号取得ステップの処理結果と前記取引ＩＤと紐づく他の情報を用いて取引当否判断のためのスコアリングを行い（スコアリング処理ステップ）、ステップＳ０９０４にて、番号取得ステップの処理結果と、前記スコアリング結果とを、前記取引ＩＤと紐づけて、前記事業者内の別の権限を有するユーザに対し出力する（スコア出力ステップ）。

【0063】

＜効果＞
本実施形態の取引承認システムを用いることにより、実施形態１の取引承認システムを用いる場合に比べて、複合的な要素を踏まえた定量的な取引当否判断の支援が可能となる。

【符号の説明】

【0064】

０２００・・・取引承認システム、０２０１・・・取引ＩＤ取得部、０２０２・・・番号取得部、０２０３・・・処理結果出力部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】