JP2019192044A - 会計処理サーバーおよび会計処理方法 - Google Patents

Abstract

【課題】証憑の仕訳の正確性を高めるための改善が求められていた。【解決手段】会計処理サーバーは、証憑の電子データである証憑データを受信する証憑受信部と、前記証憑データの仕訳の依頼を外部の依頼先へ送信する依頼送信部と、前記依頼先から返信された、前記依頼に対する仕訳結果を示す仕訳結果データを受信する仕訳受信部と、前記仕訳結果データに基づいて、前記証憑データの仕訳結果を取得する仕訳処理部と、を備える。前記会計処理サーバーは、ＳＮＳを提供するシステムと接続し、前記依頼送信部は、前記ＳＮＳを介して前記依頼を送信し、前記仕訳受信部は、前記ＳＮＳを介して前記仕訳結果データを受信する。【選択図】図３

Description

本発明は、会計処理サーバーおよび会計処理方法に関する。

ウェブ明細データから識別した各取引の、取引内容の記載をキーワードに分節し、各キーワードに対応づけられた１又は複数の勘定科目の出現頻度を参照して、特定の勘定科目に自動的に仕訳する会計処理装置が知られている（特許文献１参照）。

特開２０１７‐１６６９６号公報

自動的に仕訳を行う会計処理装置においては、多種多様な証憑に対して仕訳の精度、正確性が不足することがあり、仕訳の正確性を高めるための改善が求められていた。

会計処理サーバーは、証憑の電子データである証憑データを受信する証憑受信部と、前記証憑データの仕訳の依頼を外部の依頼先へ送信する依頼送信部と、前記依頼先から返信された、前記依頼に対する仕訳結果を示す仕訳結果データを受信する仕訳受信部と、前記仕訳結果データに基づいて、前記証憑データの仕訳結果を取得する仕訳処理部と、を備える。

システムの構成を簡易的に示す図。 本実施形態にかかる処理の一部を示すフローチャート。 本実施形態にかかる処理のうち図２の処理以外の処理を示すフローチャート。 第１端末が表示するＳＮＳ画面の例を示す図。 図４のＳＮＳ画面から遷移後のＳＮＳ画面の例を示す図。 図５のＳＮＳ画面から遷移後のＳＮＳ画面の例を示す図。 依頼先評価テーブルを示す図。 第２端末が表示するＳＮＳ画面の例を示す図。 図８のＳＮＳ画面から遷移後のＳＮＳ画面の例を示す図。 仕訳画面の例を示す図。

以下、各図を参照しながら本発明の実施形態を説明する。なお各図は、本実施形態を説明するための例示に過ぎない。

１．システムの概略説明：
図１は、本実施形態にかかるシステム１の構成を簡易的に示している。システム１は、会計処理サーバー１０、ソーシャルネットワーキングサービス（ＳＮＳ）サーバー７０、および複数の端末（第１端末３０、第２端末４０）を含んでいる。システム１の全部あるいは一部を、会計処理システムや仕訳システム等と呼んでもよい。

会計処理サーバー１０、ＳＮＳサーバー７０は、インターネット通信網を通じてユーザーにサービスを提供可能なサーバーである。会計処理サーバー１０、ＳＮＳサーバー７０は、ネットワークＮＷ上でサーバーとして機能する一台あるいは複数台の情報処理装置によって実現される。ネットワークＮＷは、インターネット通信網やローカルエリアネットワーク（ＬＡＮ）やその他の公衆通信回線を含む。ネットワークＮＷは、有線か無線かを問わない。

会計処理サーバー１０は、会計処理方法の実行主体であり、制御部１１、記憶部１７、通信インターフェイス（ＩＦ）１８等を備える。制御部１１は、プロセッサーとしてのＣＰＵ１１ａ、ＲＯＭ１１ｂ、ＲＡＭ１１ｃ等を有する１つ又は複数のＩＣや、その他のメモリー等を含んで構成される。制御部１１では、プロセッサー（ＣＰＵ１１ａ）が、ＲＯＭ１１ｂや記憶部１７等に保存されたプログラムに従った演算処理を、ＲＡＭ１１ｃ等をワークエリアとして用いて実行することにより、会計処理サーバー１０を制御する。

制御部１１はプログラム１２に従い、第１通信部１３、第２通信部１４、仕訳処理部１５、ポイント処理部１６等として機能する。プログラム１２を、会計処理プログラムとも呼ぶ。また、会計処理サーバー１０を、会計処理装置とも呼ぶ。なお、プロセッサーは、１つのＣＰＵに限られることなく、複数のＣＰＵや、ＡＳＩＣ等のハードウェア回路により処理を行う構成としてもよいし、ＣＰＵとハードウェア回路とが協働して処理を行う構成としてもよい。

記憶部１７は、例えば、ハードディスクドライブや不揮発性のメモリーによって構成される記憶手段であり、仕訳エンジン１９、依頼先評価テーブル２０等を予め記憶している。仕訳エンジン１９はプログラムの一種である。プログラム１２だけでなく仕訳エンジン１９を含めて会計処理プログラムと呼んでもよい。あるいは、仕訳エンジン１９は、プログラム１２の一部であると解釈してもよい。また、プログラムとしての仕訳エンジン１９を実行する制御部１１を、仕訳処理部１５と呼んでもよい。通信ＩＦ１８は、会計処理サーバー１０が公知の通信規格を含む所定の通信プロトコルに準拠してネットワークＮＷを通じて外部と通信するための１つまたは複数のＩＦの総称である。

会計処理サーバー１０は、ＳＮＳサーバー７０と通信可能に接続している。ＳＮＳサーバー７０は、ユーザーに所定のＳＮＳを提供するシステムを実現している。一般に、様々な種類のＳＮＳが多くのユーザーに利用されている。本実施形態では、ＳＮＳサーバー７０が提供するＳＮＳの具体例は特に問わない。以下においてＳＮＳと言った場合は、ＳＮＳサーバー７０が提供するＳＮＳを意味する。

第１端末３０、第２端末４０は、例えば、パーソナルコンピューター（ＰＣ）、スマートフォン、タブレット型端末、携帯電話機、或いはそれらと同程度の処理能力を有する通信装置によって実現される。第１端末３０は、制御部３１、表示部３４、操作受付部３５、通信ＩＦ３６等を備える。制御部３１は、プロセッサーとしてのＣＰＵ３１ａ、ＲＯＭ３１ｂ、ＲＡＭ３１ｃ等を有する１つ又は複数のＩＣや、その他のメモリー等を含んで構成される。

制御部３１では、プロセッサー（ＣＰＵ３１ａ）が、ＲＯＭ３１ｂ等に保存されたプログラムに従った演算処理を、ＲＡＭ３１ｃ等をワークエリアとして用いて実行することにより、第１端末３０を制御する。制御部３１はプログラムの１つとしてのアプリケーション３２を実行する。アプリケーション３２は、ＳＮＳを端末上で利用するためのアプリケーションである。

表示部３４は、視覚的情報を表示するための手段であり、例えば、液晶ディスプレイ（ＬＣＤ）や、有機ＥＬディスプレイ等により構成される。表示部３４は、ディスプレイと、ディスプレイを駆動するための駆動回路とを含む構成であってもよい。操作受付部３５は、ユーザーによる操作を受け付けるための手段であり、例えば、物理的なボタンや、タッチパネルや、マウスや、キーボード等によって実現される。むろん、タッチパネルは、表示部３４の一機能として実現されるとしてもよい。通信ＩＦ３６は、第１端末３０が公知の通信規格を含む所定の通信プロトコルに準拠してネットワークＮＷを通じて外部と通信するための１つまたは複数のＩＦの総称である。
第２端末４０の構成については、ＳＮＳを端末上で利用するためのアプリケーションを搭載していることを含めて第１端末３０と基本的に同様であるため、説明を省略する。

本実施形態では、第１端末３０を操作するユーザーを「依頼人」と呼び、第２端末４０を操作するユーザーを「仕訳人」と呼ぶ。むろん、第１端末３０、第２端末４０はそれぞれ複数存在している。依頼人とは、会計処理サーバー１０が提供するサービス（仕訳サービス）を利用するユーザー、つまり証憑の仕訳を依頼する立場のユーザーである。例えば、個人事業主、法人の代表者、法人における経理や会計の担当者等が依頼人に該当する。一方、仕訳人とは、仕訳の知識や経験を有する有識者、専門家であり、仕訳サービスの一部を提供する者として会計処理サーバー１０に登録されている。つまり、仕訳の能力を持った個人が、仕訳サービスにおいて仕訳人として登録されている。会計処理サーバー１０は、このような仕訳人の能力を利用することにより、依頼人に対して質の高い仕訳サービスを提供する。

２．システムによる証憑の仕訳：
図２および図３は、本実施形態にかかる処理の全体の流れをフローチャートにより示している。図２には、第１端末３０側処理と、第１アカウント側処理と、サーバー１０側処理の一部と、を示している。図３には、サーバー１０側処理の一部と、第２アカウント側処理と、第２端末４０側処理と、を示している。これらフローチャートの少なくとも一部は、会計処理方法を示している。なお、これらフローチャートにおける各ステップの全てが本実施形態に必須の工程である訳ではない。

図２に示す第１端末３０側処理は、アプリケーション３２の機能により実現される。同様に、図３に示す第２端末４０側処理は、第２端末４０が搭載するＳＮＳのアプリケーションの機能により実現される。また、図２，３に示すサーバー１０側処理は、会計処理サーバー１０においてプログラム１２を実行する制御部１１により実現される。また、図２に示す第１アカウント側処理および図３に示す第２アカウント側処理は、ＳＮＳサーバー７０により実現される。

第１アカウントとは、会計処理サーバー１０がＳＮＳを利用するために設定されたアカウントの１つである。制御部１１は、第１アカウントを自身のＳＮＳアカウントとして用いて、依頼人、つまり依頼人の第１端末３０と通信する。言い換えると、依頼人は、ＳＮＳのアプリケーションに第１アカウントを登録することで、ＳＮＳを通じて会計処理サーバー１０とメッセージ等のやり取りを行うことができる。第２アカウントも、会計処理サーバー１０がＳＮＳを利用するために設定されたアカウントの１つである。制御部１１は、第２アカウントを自身のＳＮＳアカウントとして用いて、仕訳人、つまり仕訳人の第２端末４０と通信する。言い換えると、仕訳人は、ＳＮＳのアプリケーションに第２アカウントを登録することで、ＳＮＳを通じて会計処理サーバー１０とメッセージ等のやり取りを行うことができる。

プログラム１２、つまりプログラム１２を実行する制御部１１は、ＳＮＳサーバー７０側のプログラムとのＩＦであるＡＰＩ（Application Programming Interface）を通じて、第１アカウント宛や第２アカウント宛の通信を受信したり、第１アカウントや第２アカウントからのデータ送信をＳＮＳサーバー７０に実行させたりすることができる。

ステップＳ１００では、第１端末３０は、証憑の電子データである証憑データを取得する。依頼人は、例えば、商品購入の際に店舗で発行されたレシートを、スマートフォンとしての第１端末３０が備えるカメラで撮影する。第１端末３０は、このようなレシートを撮影した画像を証憑データとして取得する。また、依頼人は、レシートをスキャナーに読み取らせ、ＰＣとしての第１端末３０は、スキャナーからレシートの読取結果としての画像を証憑データとして取得する、としてもよい。

ステップＳ１０１では、第１端末３０は、ステップＳ１００で取得した証憑データを、会計処理サーバー１０へ送信する。ただし、この場合、第１端末３０は第１アカウント宛に証憑データを送信する。ステップＳ１０１の処理は、第１端末３０による証憑の仕訳依頼に該当する。

図４，５，６はそれぞれ、アプリケーション３２が第１端末３０の表示部３４に表示させるＳＮＳの画面（ＳＮＳ画面５０）の例を示している。ＳＮＳ画面５０は、依頼人、つまり依頼人のＳＮＳのアカウントと、第１アカウントとのやり取りをタイムラインの形式で表示している。図４，５，６は、ＳＮＳ画面５０の内容が遷移する様子を示している。図４，５，６において、符号“Ｍ１‐”を用いて示す各メッセージは、プログラム１２が第１アカウント側のメッセージとして生成しＳＮＳサーバー７０から依頼人のＳＮＳのアカウントへ送信させたものである。

図４のＳＮＳ画面５０内のメッセージＭ１‐１は、証憑データを送信することを依頼人に促す内容のメッセージである。つまり、依頼人は、メッセージＭ１‐１を見ることにより、第１端末３０を操作して、第１端末３０にステップＳ１００，Ｓ１０１を実行させる。図４のＳＮＳ画面５０内の画像Ｐ１は、レシートＲを撮影した画像であり、ステップＳ１００で取得され、ステップＳ１０１で送信された証憑データの例である。

ステップＳ２００では、ＳＮＳサーバー７０は、第１端末３０から第１アカウント宛に送信された証憑データを受信し、受信した証憑データを会計処理サーバー１０へ送信する。
ステップＳ３００では、第１通信部１３は、第１アカウント宛に送信された証憑データをＳＮＳサーバー７０から受信する。

依頼人は、レシート等の証憑をカメラで撮影したりスキャナーで読み取ったりして生成された画像としての証憑データだけでなく、証憑の仕訳において有用な追加情報も併せて第１端末３０から送信することができる。つまり、依頼人は、第１端末３０を操作することにより、ＳＮＳ画面５０に追加情報としてのメッセージを入力し、入力したメッセージを証憑データとともに第１アカウント宛に送信させる（ステップＳ１０１）、としてもよい。追加情報は、例えば「出張時の朝食代。」といったような、証憑の内容を補足するメッセージが考えられる。

依頼人による追加情報の入力方法は、操作受付部３５を介した文字（テキスト）入力であってもよいし、第１端末３０が備える不図示のマイクロフォンに対する声の入力であってもよい。依頼人が、証憑データとともに文字データや音声データによる追加情報を第１端末３０から第１アカウント宛に送信させることで、ステップＳ２００を経てステップＳ３００では、第１通信部１３は、証憑データとともに追加情報を受信する。

ステップＳ３０１では、仕訳処理部１５は、ステップＳ３００で受信した証憑データの仕訳を実行する。ステップＳ３００で証憑データとともに追加情報が受信された場合には、ステップＳ３０１では、仕訳処理部１５は、追加情報も利用して仕訳を実行する。ステップＳ３０１における仕訳は、会計処理サーバー１０による仕訳、つまり自動仕訳である。

仕訳処理部１５は、仕訳エンジン１９を用いて証憑データの仕訳を実行する。この場合、仕訳処理部１５は、証憑データに対して文字認識（ＯＣＲ：Optical Character Recognition）処理を実行することにより、画像としての証憑データ内に表現されている文字を文字データ化する。また、証憑データとともに受信した追加情報が音声データである場合には、追加情報としての音声データも文字データに変換する。そして、仕訳処理部１５は、仕訳エンジン１９を起動させ、文字データとしての証憑データや追加情報を仕訳エンジン１９に入力させ、仕訳エンジン１９から出力された仕訳の結果を取得する。

一例として、仕訳エンジン１９は、機械学習により作成された仕訳用モデルである。より具体的には、仕訳エンジン１９は、機械学習の１つであるDeep Learning技術により作成された仕訳用モデルである。このような仕訳エンジン１９は、多層構造のニューラルネットワークに大量の学習用文字データ（サンプルとしての証憑や追加情報）を入力することで証憑に記載されている取引内容や追加情報の特徴と勘定科目との対応関係を学習済みであり、入力された証憑から仕訳の結果を生成できるように予め構築されている。

ステップＳ３０１で仕訳処理部１５が仕訳エンジン１９を用いて実行した仕訳の結果を、「仮仕訳結果」と呼ぶ。これは、ステップＳ３０１における仕訳の結果は、後述のステップＳ３１０で修正される可能性があるためである。

ステップＳ３０３では、第１通信部１３は、追加情報の要求をステップＳ３００で受信した証憑データの送信元の第１端末３０へ送信する。ただし、ステップＳ３０３で第１通信部１３が送信する要求は、ＳＮＳサーバー７０が一旦受信する（ステップＳ２０１）。ＳＮＳサーバー７０は、一旦受信した前記要求を、第１アカウントからの送信データとして、証憑データの送信元の第１端末３０へ送信する（ステップＳ２０１）。

図２から判るように、ステップＳ３０３は必ず実行される訳ではなく、追加情報が必要な場合に実行される。追加情報が必要な場合とは、例えば、ステップＳ３００で受信した証憑データに追加情報が付されていない場合が挙げられる。また、ステップＳ３０１において、仕訳エンジン１９から出力された仕訳の結果がエラー、つまり仕訳失敗を示す場合も、追加情報が必要な場合に該当する。仕訳処理部１５は、ステップＳ３０１の後のステップＳ３０２において、追加情報が必要であるか否かを判定し、追加情報が必要であれば（ステップＳ３０２において“Ｙｅｓ”）、第１通信部１３にステップＳ３０３を実行させる。一方、追加情報が必要でなければ（ステップＳ３０２において“Ｎｏ”）、ステップＳ３０５へ処理が進む。ステップＳ３０３が実行されない場合は、第１アカウント側処理としてのステップＳ２０１，Ｓ２０２および第１端末３０側処理としてのステップＳ１０２，Ｓ１０３，Ｓ１０３Ａ，Ｓ１０４，Ｓ１０５，Ｓ１０５Ａも実行されず、ステップＳ３０４も実行されない。

ステップＳ１０２では、第１端末３０は、追加情報の要求をＳＮＳサーバー７０から、つまり第１アカウントから受信する。
ステップＳ１０３では、第１端末３０は、ステップＳ１０２で受信した追加情報の要求を表示部３４に表示させる。

依頼人は、表示部３４に表示された追加情報の要求を見ることにより、証憑データの仕訳のために追加情報が必要であることを認識し、操作受付部３５を介して追加情報を入力する。第１端末３０は、このような依頼人による追加情報の入力を受け付ける（ステップＳ１０４）。
そして、ステップＳ１０５では、第１端末３０は、ステップＳ１０４で入力を受け付けた追加情報を会計処理サーバー１０へ向けて、つまり第１アカウント宛に送信する。

ステップＳ２０２では、ＳＮＳサーバー７０は、第１端末３０から第１アカウント宛に送信された追加情報を受信し、受信した追加情報を会計処理サーバー１０へ送信する。
ステップＳ３０４では、第１通信部１３は、第１アカウント宛に送信された追加情報をＳＮＳサーバー７０から受信する。

図５は、図４に示した状態から時間が経過した後のＳＮＳ画面５０を示している。メッセージＭ１‐２は、証憑データの仕訳に取り掛かる旨を依頼人に通知するメッセージである。図２のフローチャートでは特に示していないが、第１通信部１３は、ステップＳ３００で証憑データを受信した後であって、ステップＳ３０１の前に、ＳＮＳサーバー７０を介してメッセージＭ１‐２を証憑データの送信元の第１端末３０へ送信し、ＳＮＳ画面５０内に表示させることができる。

メッセージＭ１‐３は、ステップＳ１０３においてＳＮＳ画面５０に表示される追加情報の要求の例である。メッセージＭ１‐３は、例えば「おそらく“消耗品費”だと思いますが、使用用途を追加しますか？」といったように、依頼人に対して、ステップＳ３０１の仕訳の結果、つまり仮仕訳結果の内容を伝えつつ、証憑が示す取引の用途や目的を問いかけている。メッセージＵＭは、追加情報の要求に対して依頼人が入力したメッセージ、つまり、ステップＳ１０４で第１端末３０が受け付けた入力の内容である。依頼人は、追加情報の要求に応じて、例えば「出張時の朝食代。」と入力する。

図５の例では、ＳＮＳ画面５０には、メッセージＭ１‐４やメッセージＭ１‐５も表示されている。メッセージＭ１‐４，Ｍ１‐５は、ステップＳ１０３〜Ｓ１０５の途中あるいは前後においてＳＮＳ画面５０に表示されるメッセージの例である。メッセージＭ１‐４は、ステップＳ１０３Ａのタイミングで表示され、メッセージＭ１‐５は、ステップＳ１０５Ａのタイミングで表示される。

メッセージＭ１‐３内には「おそらく“消耗品費”だと思いますが、使用用途を追加しますか？」といった文字列に加え、「する」および「しない」の選択欄が設けられている。依頼人は、「する」、「しない」の選択欄のいずれか一方をタップやクリック等することにより、追加情報を入力する意思の有無を、ＳＮＳサーバー７０を介して会計処理サーバー１０へ通知する。第１通信部１３は、「する」が選択された場合、つまり追加情報を入力する意思が有る旨の通知を受けた場合、ＳＮＳサーバー７０を介してメッセージＭ１‐４を証憑データの送信元の第１端末３０へ送信し、ＳＮＳ画面５０内に表示させる。

メッセージＭ１‐４は、例えば「では、追加する使用用途を教えてください。」といった内容であり、このようなメッセージＭ１‐４も、会計処理サーバー１０による追加情報の要求としてのメッセージの１つと言える。メッセージＭ１‐５は、追加情報の要求に応じて追加情報が入力された旨、および、仕訳のプロすなわち仕訳人にこれから仕訳をさせる旨を依頼人に通知するメッセージである。ステップＳ３０４で追加情報を受信した第１通信部１３は、ＳＮＳサーバー７０を介してメッセージＭ１‐５を証憑データの送信元の第１端末３０へ送信し、ＳＮＳ画面５０内に表示させる。なお、図２のフローチャートでは、メッセージＭ１‐４やメッセージＭ１‐５を第１端末３０がＳＮＳ画面５０内に表示するための第１端末３０、ＳＮＳサーバー７０、会計処理サーバー１０間のやり取りは記載を省略している。

仮に、依頼人によってメッセージＭ１‐３内の「しない」が選択された場合、第１通信部１３は、追加情報を入力する意思が無い旨の通知を受けることとなり、その場合はサーバー１０側処理をステップＳ３０５へ進める。図２の符号ＮＳは、メッセージＭ１‐３内の「しない」が選択された場合に第１端末３０からＳＮＳサーバー７０を介して会計処理サーバー１０へ送信される、追加情報を入力する意思が無い旨の通知を示している。つまり、ステップＳ１０３の表示（メッセージＭ１‐３）に対応する応答として通知ＮＳがなされた場合には、ステップＳ１０３Ａ，Ｓ１０４，Ｓ１０５，Ｓ１０５Ａ，Ｓ２０２，Ｓ３０４は実行されない。

ステップＳ３０５では、第２通信部１４は、ステップＳ３００で受信された証憑データの仕訳の依頼先を１つ以上決定する。依頼先とは、仕訳依頼の送信先であり、会計処理サーバー１０がＳＮＳを介して仕訳人と情報のやり取りを行う構成においては、ＳＮＳ上の仕訳人のアカウントが依頼先となる。仕訳の依頼先を決定することは、実質的には仕訳人を決定することである。

ステップＳ３０５における、依頼先の決定方法を説明する。
本実施形態では、第２通信部１４は、会計処理サーバー１０において予め登録されている複数の依頼先（登録依頼先）の中から依頼先を決定する。登録依頼先は、依頼先評価テーブル２０に記録されているため、第２通信部１４は、依頼先評価テーブル２０を参照して依頼先を決定する。

図７は、依頼先評価テーブル２０の一例を示している。依頼先評価テーブル２０には、複数の登録依頼先、つまり複数の仕訳人のＳＮＳのアカウントと、登録依頼先毎の能力や依頼状況等が記録されている。登録依頼先の能力とは、仕訳に関する能力であり、例えば、分野と成績の要素からなる。一般に、医療業界、飲食業界、不動産業界、農業等の様々な分野において様々な様式、種類の証憑が発行されている。そのため、仕訳人として会計処理サーバー１０に登録される者は、自身が得意とする分野を申告する。例えば、医療分野に関する証憑の仕訳を得意とする者は、医療分野を申告する。依頼先評価テーブル２０には、このように各仕訳人から申告された分野が、能力の一要素として記録されている。むろん、１つの登録依頼先に対して複数の分野が記録されていてもよい。

能力の一要素としての成績とは、仕訳人が会計処理サーバー１０からの依頼を受けて実行した仕訳に対する評価である。後述するように、仕訳人が行った仕訳に対しては、仕訳結果が正解であるか不正解であるかが仕訳処理部１５によって判定される。従って、過去に行った仕訳の正解数が多いか或いは過去に行った仕訳の正解率が高い登録依頼先ほど、成績は高い点数となっている。依頼先評価テーブル２０において、１つの登録依頼先の成績は、当該１つの登録依頼先の分野毎に記録される。

登録依頼先の依頼状況とは、現在の仕訳の依頼状況であり、受任中か非受任のいずれか一方である。具体的には、会計処理サーバー１０は、１つの依頼先に向けて仕訳依頼を送信してから、当該１つの依頼先から仕訳結果データを受信するまでの期間（図３のステップＳ３０６〜Ｓ３０７の期間）を、当該１つの依頼先の「受任中」の期間とする。会計処理サーバー１０は、登録依頼先毎に依頼状況が受任中に該当するか否かを判定し、受任中に該当する場合にのみ、依頼先評価テーブル２０における依頼状況を「非受任」から「受任中」に切り替える。

さらに、依頼先評価テーブル２０には、図７に示すように依頼可能時間帯が記録されていてもよい。依頼可能時間帯とは、仕訳人として会計処理サーバー１０に登録される者が各々自己の都合に応じて申告した時間帯であり、仕訳依頼を受けることが可能な曜日や時間帯を意味する。

第２通信部１４は、登録依頼先の中から、ステップＳ３００で受信された証憑データの種類に応じて、１つ以上（Ｎ個）の依頼先を決定する。例えば、Ｎ＝５とする。制御部１１は、ステップＳ３００で受信した証憑データは、依頼人に対して予め設定された業種の証憑データであると判定する。制御部１１は、依頼人（依頼人のＳＮＳのアカウント等の識別情報）と依頼人の業種とを対応付けて記録したテーブルを予め保持する等して、証憑データの送信元である依頼人に対応する業種、すなわち証憑データの種類を判定することができる。

そして、第２通信部１４は、ステップＳ３００で受信された証憑データが、例えば、医療関連の種類の証憑である場合、依頼先評価テーブル２０を参照し、登録依頼先の中から、能力が医療分野に対応しているＮ個の依頼先を決定する。ただし、この場合、第２通信部１４は、能力が医療分野に対応している登録依頼先のうち、成績が上位のＮ個の登録依頼先を依頼先に決定する。また、第２通信部１４は、依頼状況が「非受任」である登録依頼先を依頼先に決定する。さらに、第２通信部１４は、現在の日時を依頼可能時間帯に含む登録依頼先を依頼先に決定するとしてもよい。

このような各条件を考慮すると、第２通信部１４は、依頼先評価テーブル２０に記録されている登録依頼先であって、ステップＳ３００で受信された証憑データの種類に対応する分野の能力を有し、かつ、依頼状況が「非受任」であり、かつ、現在の日時を依頼可能時間帯に含む登録依頼先のうち、成績が上位のＮ個の登録依頼先を依頼先に決定する。

ただし、制御部１１が、ステップＳ３００で受信した証憑データについて、その種類を判別できないこともある。そのため、第２通信部１４は、ステップＳ３００で受信された証憑データの種類が不明である場合には、依頼先が対応する分野は問わず、成績や、依頼状況や、依頼可能時間帯といった各条件に基づいて、依頼先評価テーブル２０に記録されている登録依頼先の中からＮ個の依頼先を決定するとしてもよい。

ステップＳ３０６（図３参照）では、第２通信部１４は、ステップＳ３０５で決定したＮ個の依頼先へ、仕訳依頼を送信する。ただし、ステップＳ３０６で第２通信部１４が送信する仕訳依頼は、ＳＮＳサーバー７０が一旦受信する（ステップＳ４００）。第２通信部１４は、Ｎ個の依頼先のアカウントを、仕訳依頼とともにＳＮＳサーバー７０へ送信し、ＳＮＳサーバー７０は、一旦受信した仕訳依頼を、第２アカウントからの送信データとして、Ｎ個の依頼先の各アカウントへ送信する（ステップＳ４００）。

図３に示す第２端末４０側処理は、ステップＳ３０５で決定されたＮ個の依頼先のうちの１つの依頼先に対応する仕訳人が操作する第２端末４０における処理を示している。ステップＳ３０６で送信される仕訳依頼は、ステップＳ３００で受信された証憑データに、ステップＳ３００やステップＳ３０４で受信された追加情報や、仮仕訳結果等を加えたデータである。ただし、証憑データの追加情報がステップＳ３０５までの時点で受信されていない場合には、ステップＳ３０６で送信される仕訳依頼は、追加情報を含まない。

ステップＳ５００では、第２端末４０は、仕訳依頼をＳＮＳサーバー７０から、つまり第２アカウントから受信する。
ステップＳ５０１では、第２端末４０は、ステップＳ５００で受信した仕訳依頼に基づく画面を、第２端末４０が備える不図示の表示部に表示させる。

図８，９はそれぞれ、ＳＮＳのアプリケーションが第２端末４０の表示部に表示させるＳＮＳの画面（ＳＮＳ画面６０）の例を示している。ＳＮＳ画面６０は、仕訳人、つまり仕訳人のＳＮＳのアカウントと、第２アカウントとのやり取りをタイムラインの形式で表示している。図８，９は、ＳＮＳ画面６０の内容が遷移する様子を示している。

図８のＳＮＳ画面６０内の画像Ｐ１およびメッセージＭ２‐１による領域は、ステップＳ５０１において第２アカウント側からの投稿として表示される、仕訳依頼に基づく画面の例であり、ここでは仕訳依頼画面と呼ぶ。画像Ｐ１は、上述したようにレシートＲの画像であり、仕訳依頼に含まれている証憑データに基づいて表示されている。メッセージＭ２‐１には、例えば「仕訳画面で登録をお願いします。」といったような、仕訳人に仕訳を依頼するメッセージが含まれている。さらに、メッセージＭ２‐１には、「借方は“消耗品費”だと思います。」といった、仕訳人に対して仮仕訳結果の内容を伝えるメッセージや、「使用用途は“出張時の朝食代”だそうです。」といった、依頼人により入力された追加情報の内容を伝えるメッセージが含まれている。

さらに、メッセージＭ２‐１には、「まず、レシートを見る」および「仕訳画面へ」の選択欄が設けられている。仕訳人は、「まず、レシートを見る」の選択欄をタップやクリック等することにより、レシートの拡大画像、つまり画像Ｐ１を拡大した画像を第２端末４０の表示部に表示させて、仕訳の対象とするレシートを詳細に見ることができる。また、仕訳人は、「仕訳画面へ」の選択欄をタップやクリック等することにより、第２端末４０の表示部における表示を、ＳＮＳ画面６０から仕訳画面６１へ切り替える。つまり、第２端末４０は、仕訳依頼画面の表示の後に、仕訳画面６１を表示部に表示させる（ステップＳ５０２）。仕訳画面６１も、ステップＳ５００で受信した仕訳依頼に基づく画面の一種である。

図１０は、第２端末４０の表示部に表示された仕訳画面６１の例を示している。仕訳画面６１には、支払日を入力するための入力欄Ｗ１、金額を入力するための入力欄Ｗ２、借方の勘定科目を入力するための入力欄Ｗ３、貸方の勘定科目を入力するための入力欄Ｗ４、および登録ボタンＲＢが含まれている。仕訳人は第２端末４０を操作し、画像Ｐ１が示すレシートＲの内容に基づいて、各入力欄Ｗ１〜Ｗ４へ、自身が正しいと思う情報を入力する。図１０では、仕訳人により各入力欄Ｗ１〜Ｗ４へ入力が行われた状態の仕訳画面６１を示している。第２端末４０は、このような仕訳画面６１に対する仕訳人による入力、つまり仕訳人による仕訳の入力を受け付ける（ステップＳ５０３）。

仕訳画面６１は、仕訳人による入力がされる前の状態において、各入力欄Ｗ１〜Ｗ４に仮仕訳結果の内容を表示するものであってもよい。各入力欄Ｗ１〜Ｗ４に仮仕訳結果の内容が表示されていれば、仕訳人は、仮仕訳結果のうち間違っていると思われる項目だけを修正すればよいため、仕訳人の作業が楽になる。

仕訳人は、各入力欄Ｗ１〜Ｗ４への入力を終えたら登録ボタンＲＢをタップやクリック等する。第２端末４０は、仕訳画面６１の登録ボタンＲＢが操作されたことを契機として、各入力欄Ｗ１〜Ｗ４に入力されている内容、つまり仕訳人による仕訳結果を、仕訳結果データとして会計処理サーバー１０へ送信する（ステップＳ５０４）。このとき、第２端末４０は、仕訳結果データを第２アカウント宛に送信する。

ステップＳ４０１では、ＳＮＳサーバー７０は、第２端末４０から第２アカウント宛に送信された仕訳結果データを受信し、受信した仕訳結果データを会計処理サーバー１０へ送信する。
ステップＳ３０７では、第２通信部１４は、第２アカウント宛に送信された仕訳結果データをＳＮＳサーバー７０から受信する。

ステップＳ３０８では、仕訳処理部１５は、Ｎ個の依頼先のうちの所定数、例えば半数以上の依頼先の仕訳結果が一致するか否かを判定し、Ｎ個の依頼先のうちの所定数以上の依頼先の仕訳結果が一致する場合にステップＳ３１０へ進む。図３では、会計処理サーバー１０と、仕訳の依頼先としての１つの第２端末４０とのやり取りを示しているが、第２通信部１４は、Ｎ個の依頼先のそれぞれから仕訳結果データを受信する。従って、例えばＮ＝５であれば、仕訳処理部１５は、５つの依頼先のうち３つ以上の依頼先からの仕訳結果データの内容が一致する場合に、ステップＳ３０８で“Ｙｅｓ”と判定してステップＳ３１０へ進む。なお、仕訳結果が一致するとは、比較する仕訳結果データ同士の内容（支払日、金額、借方の勘定科目、貸方の勘定科目）の全てが一致することを指す。一方、Ｎ個の依頼先のうちの所定数以上の依頼先の仕訳結果が一致する、という条件が成立しない場合（ステップＳ３０８において“Ｎｏ”）、仕訳処理部１５は、ステップＳ３０９へ進む。

ステップＳ３０９では、仕訳処理部１５は、仕訳の依頼先を新たに１つ決定し、つまり依頼先を１つ追加し、第２通信部１４に、追加した依頼先への仕訳依頼の送信を実行させる。ステップＳ３０９における依頼先の決定方法はステップＳ３０５を踏襲する。ただし、ステップＳ３０９では、仕訳処理部１５は、ステップＳ３０５で決定した依頼先を除いた登録依頼先の中から依頼先を決定する。このように追加した依頼先への仕訳依頼の送信以降の流れは、ステップＳ３０６以降の処理で説明した通りである。従って、ステップＳ３０９の後は、仕訳処理部１５は、ステップＳ３０９で追加した依頼先からの仕訳結果データを第２通信部１４が受信する処理（ステップＳ３０７）を待機する。仕訳処理部１５は、ステップＳ３０９の実行に伴い、Ｎの値を、ステップＳ３０９で追加した依頼先の数だけ増加させる。ステップＳ３０９の後、ステップＳ３０７を経たステップＳ３０８では、仕訳処理部１５は、Ｎ個の依頼先のうちの所定数（例えば半数）以上の依頼先の仕訳結果が一致するか否かの判定を再び行い、ステップＳ３０９またはステップＳ３１０へ進む。

なお、仕訳処理部１５は、第２通信部１４がある依頼先へ仕訳依頼の送信を行ってから第２通信部１４が当該依頼先からの仕訳結果データを受信するまでに要する時間に対して、上限を設けてもよい。ここで言う上限としては、例えば、数分あるいは数十分程度の時間が考えられる。つまり、仕訳処理部１５は、第２通信部１４がある依頼先へ仕訳依頼の送信を行ってから上限を超える時間が経過しても第２通信部１４が当該依頼先からの仕訳結果データを受信できない場合には、当該依頼先を、決定したＮ個の依頼先のうちの１つではないと見なす。そして、仕訳処理部１５は、このようなみなしによる依頼先の減少を補うため、ステップＳ３０９と同様に依頼先を追加し、追加した依頼先へ仕訳依頼を送信する。このように上限を設けることにより、仕訳処理部１５は、依頼先の１つとしたある仕訳人側の事情に起因して仕訳結果データが返信されてこない場合に、待機し続けてしまうという状況を回避することができる。

ステップＳ３１０では、仕訳処理部１５は、依頼先からの仕訳結果データに基づいて、証憑データの仕訳結果を確定する。ステップＳ３１０で証憑データの仕訳結果を確定することが、ステップＳ３００で受信した証憑データの仕訳結果を取得することに該当する。仕訳処理部１５は、ステップＳ３０８でＮ個の依頼先のうちの所定数以上の依頼先の仕訳結果が一致すると判定したときの当該一致する仕訳結果を、正解の仕訳結果とする。例えば、Ｎ＝５であり、５つの依頼先（依頼先Ａ，Ｂ，Ｃ，Ｄ，Ｅ）のうち、半数以上である３つの依頼先（依頼先Ａ，Ｂ，Ｃ）からの仕訳結果データの内容が互いに一致しており、残りの２つの依頼先（依頼先Ｄ，Ｅ）からの仕訳結果データの内容が依頼先Ａ，Ｂ，Ｃからの仕訳結果データと一致していない場合を想定する。この場合、仕訳処理部１５は、依頼先Ａ，Ｂ，Ｃからの仕訳結果データを正解の仕訳結果とし、依頼先Ｄ，Ｅからの仕訳結果データを不正解の仕訳結果とする。

仕訳処理部１５は、仮仕訳結果を正解の仕訳結果により修正する。つまり、仮仕訳結果が正解の仕訳結果と異なれば、仮仕訳結果の替わりに正解の仕訳結果を、最終的な仕訳結果として確定することにより仕訳結果を取得する。仮仕訳結果が正解の仕訳結果と一致していれば、仕訳処理部１５は、仮仕訳結果を最終的な仕訳結果として確定することにより仕訳結果を取得する。

ステップＳ３１１では、第１通信部１３は、ステップＳ３１０で確定された仕訳結果（確定仕訳結果）を、ステップＳ３００で受信した証憑データの送信元の第１端末３０へ、ステップＳ３００で受信した証憑データとともに送信する。ステップＳ３１１で第１通信部１３が送信する確定仕訳結果は、ＳＮＳサーバー７０が一旦受信する（ステップＳ２０３、図２参照）。ＳＮＳサーバー７０は、一旦受信した確定仕訳結果を、第１アカウントからの送信データとして、証憑データの送信元の第１端末３０へ送信する（ステップＳ２０３）。

ステップＳ１０６では、第１端末３０は、確定仕訳結果をＳＮＳサーバー７０から、つまり第１アカウントから受信する。
ステップＳ１０７では、第１端末３０は、ステップＳ１０６で受信した確定仕訳結果を表示部３４に表示させる。

図６は、図５に示した状態から時間が経過した後のＳＮＳ画面５０を示している。
図６のＳＮＳ画面５０内の画像Ｐ１およびメッセージＭ１‐６による領域は、ステップＳ１０７において第１アカウント側からの投稿として表示される、確定仕訳結果の例である。画像Ｐ１は、確定仕訳結果とともに会計処理サーバー１０から送信された証憑データに基づいて表示されている。メッセージＭ１‐６には、例えば「仕訳のプロが確認しました。」といったような、仕訳人による仕訳が終了した旨のメッセージが含まれている。さらに、メッセージＭ１‐６には、借方の勘定科目や貸方の勘定科目等の確定仕訳結果の内容が含まれている。依頼人は、メッセージＭ１‐６を見ることで、第１アカウント宛にＳＮＳ上で送信した証憑データに対する仕訳結果を知ることができる。また、確定仕訳結果の表示の仕方として、図６のように、メッセージＭ１‐６を画像Ｐ１と併せて表示することで、依頼人に仕訳結果をより具体的に理解させることができる。

ステップＳ３１２（図３参照）では、仕訳処理部１５は、仕訳エンジン１９にフィードバック学習をさせる。つまり、仕訳処理部１５は、確定仕訳結果を、ステップＳ３００で受信した証憑データについての文字データや、ステップＳ３００やステップＳ３０４で受信した追加情報とともに、仕訳エンジン１９へ入力させることにより、仕訳エンジン１９に証憑や追加情報と確定仕訳結果との対応関係を学習させる。これにより、仕訳エンジン１９による証憑の仕訳能力が向上し、今後のステップＳ３０１における自動仕訳の正確性が増す。

ステップＳ３１３では、ポイント処理部１６は、仕訳依頼に対して仕訳結果データを返信した依頼先へ報酬としてのポイントを付与する。また、第２通信部１４は、ポイント処理部１６が依頼先へ付与したポイントを依頼先へ通知する。本実施形態において仕訳人へ付与するポイントは、仕訳人にとって報酬の価値があるポイントであれば何でもよい。大手流通グループや、小売り店や、クレジットカード会社等が扱う様々な種類のポイントが知られている。ポイント処理部１６は、ポイント付与の処理自体は、ポイントの発行主体である会社や団体が管理、運営するインターネット上の所定のサーバーと連携して実行する。例えば、ポイント処理部１６は、ポイントの発行主体である会社や団体が管理、運営するインターネット上の所定のサーバーに対して、ポイントの付与対象となる仕訳人の個人情報に紐づけて当該所定のサーバーにおいて現在貯められているポイントに前記報酬分のポイントを加えることを指示する。

ポイント処理部１６は、確定仕訳結果と一致する仕訳結果データの返信元である依頼先に対して付与するポイントを、確定仕訳結果と一致しない仕訳結果データの返信元である依頼先に対して付与するポイントよりも多くする、としてもよい。再び、Ｎ＝５であり、５つの依頼先（依頼先Ａ，Ｂ，Ｃ，Ｄ，Ｅ）のうち、３つの依頼先（依頼先Ａ，Ｂ，Ｃ）からの仕訳結果データの内容が互いに一致しており、残りの２つの依頼先（依頼先Ｄ，Ｅ）からの仕訳結果データの内容が依頼先Ａ，Ｂ，Ｃからの仕訳結果データと一致しない場合を想定する。依頼先Ａ，Ｂ，Ｃからの仕訳結果データが正解、つまり確定仕訳結果であり、依頼先Ｄ，Ｅからの仕訳結果データが不正解、つまり確定仕訳結果と一致しない仕訳結果である。

このような場合、ポイント処理部１６は、ステップＳ３１３で仕訳結果データの送信元である５つの依頼先に付与するポイント総数の、例えば６０％を、正解の仕訳結果データを出した依頼先へ分配し、残りの４０％を、これら５つの依頼先に分配する。つまり、ポイント処理部１６は、依頼先Ａ，Ｂ，Ｃ，Ｄ，Ｅのために用意したポイント総数のうちの６０％を依頼先Ａ，Ｂ，Ｃに等分して付与し、残りの４０％を依頼先Ａ，Ｂ，Ｃ，Ｄ，Ｅに等分して付与する。これにより、正解の仕訳結果を出した仕訳人に対して、より高い報酬を与えることができる。

上述したように、第２通信部１４は、ポイント処理部１６が依頼先へ付与したポイントを依頼先へ通知する（ステップＳ３１３）。この場合、第２通信部１４は、ポイント付与の対象となった依頼先へポイント通知を送信する。ステップＳ３１３で第２通信部１４が送信するポイント通知は、ＳＮＳサーバー７０が一旦受信する（ステップＳ４０２）。ＳＮＳサーバー７０は、一旦受信したポイント通知を、第２アカウントからの送信データとして、前記ポイント付与の対象となった依頼先のアカウントへ送信する（ステップＳ４０２）。

ステップＳ５０５では、第２端末４０は、ポイント通知をＳＮＳサーバー７０から、つまり第２アカウントから受信する。
ステップＳ５０６では、第２端末４０は、ステップＳ５０５で受信したポイント通知に基づく画面を、第２端末４０が備える不図示の表示部に表示させる。

図９のＳＮＳ画面６０内の画像Ｐ１およびメッセージＭ２‐２による領域は、ステップＳ５０６において第２アカウント側からの投稿として表示される、ポイント通知に基づく画面の例である。画像Ｐ１は、上述したようにレシートＲの画像であり、仕訳依頼に含まれている証憑データに基づいて表示されている。あるいは、証憑データはポイント通知とともに改めて会計処理サーバー１０から第２端末４０へ送信されるとしてもよい。メッセージＭ２‐２には、例えば「獲得：４．００ポイント」といったような、仕訳人に対して報酬としてのポイントが付与された旨のメッセージが含まれている。

さらに、メッセージＭ２‐２には「あなたが登録した内容は採用されました。」といった、仕訳人が仕訳画面６１（図１０参照）を介して入力した仕訳が正解の仕訳結果となった旨のメッセージが含まれている。むろん、不正解の仕訳を入力した仕訳人が操作する第２端末４０の表示部には、「あなたが登録した内容は採用されました。」のメッセージは表示されない。さらに、メッセージＭ２‐２には、仕訳人がこれまでの仕訳によって貯めたポイントの最新の残高が含まれていてもよい。さらに、メッセージＭ２‐２には「仕訳詳細」の選択欄が設けらてもよい。仕訳人は、「仕訳詳細」の選択欄をタップやクリック等することにより、自身が実行した仕訳、つまりメッセージＭ２‐２が示しているポイントの獲得の原因となった仕訳結果を第２端末４０の表示部に表示させて、改めて確認することができる。

以上により、図２，３に示す第１端末３０側処理、第１アカウント側処理、サーバー１０側処理、第２アカウント側処理、および第２端末４０側処理が終了する。
なお、仕訳処理部１５は、例えば、ステップＳ３１０で仕訳結果を確定したタイミング等で、依頼先評価テーブル２０に記録されている登録依頼先毎の成績を更新する。つまり、確定仕訳結果と一致する正解の仕訳結果を出した依頼先については、現在の成績の点数をより高い点数へ更新し、一方、確定仕訳結果と一致しない不正解の仕訳結果を出した依頼先については、現在の成績の点数をより低い点数へ更新する。

３．まとめ：
このように本実施形態によれば、会計処理サーバー１０は、証憑の電子データである証憑データを受信する証憑受信部と、証憑データの仕訳の依頼を外部の依頼先へ送信する依頼送信部と、依頼先から返信された、前記依頼に対する仕訳結果を示す仕訳結果データを受信する仕訳受信部と、仕訳結果データに基づいて、証憑データの仕訳結果を取得する仕訳処理部１５と、を備える。これまでの説明から明らかなように、会計処理サーバー１０の制御部１１における第１通信部１３は、依頼人側との情報のやり取りを実行しているため、証憑受信部に該当する。また、会計処理サーバー１０の制御部１１における第２通信部１４は、仕訳人側との情報のやり取りを実行しているため、依頼送信部や仕訳受信部に該当する。

前記構成によれば、会計処理サーバー１０は、証憑データを受信すると、証憑データの仕訳依頼を外部の依頼先へ送信し、依頼先から返信された仕訳結果データに基づいて、証憑データの仕訳結果を取得する。つまり、外部の依頼先の仕訳能力を利用して証憑データの仕訳結果を取得することにより、多種多様な証憑に対して仕訳の正確性を高めることができる。

また、本実施形態によれば、会計処理サーバー１０は、ＳＮＳを提供するシステム（ＳＮＳサーバー７０）と接続し、依頼送信部（第２通信部１４）は、ＳＮＳを介して前記依頼を送信し、仕訳受信部（第２通信部１４）は、ＳＮＳを介して仕訳結果データを受信する。
前記構成によれば、ＳＮＳという多くのユーザーに日常的に親しまれているコミュニケーションツールを介して外部の依頼先と通信を行うことにより、会計処理サーバー１０は、依頼先の仕訳能力を簡単に利用することができる。また、依頼先としての仕訳人にとっても、ＳＮＳを介して会計処理サーバー１０と通信を行うことにより、気軽かつ簡単に、会計処理サーバー１０が提供するサービスの一部を担うことが可能となる。

ただし、会計処理サーバー１０がＳＮＳを介して依頼先としての仕訳人や、依頼人と通信を行う構成は必須ではない。会計処理サーバー１０は、依頼人側の第１端末３０、仕訳人側の第２端末４０のそれぞれと直接、あるいは間接的に通信できればよく、通信手段としては、電子メール等を用いてもよい。

また、本実施形態によれば、仕訳処理部１５は、証憑データの仕訳（ステップＳ３０１）を実行し、実行した仕訳の結果を、依頼先から返信された仕訳結果データに基づいて修正することにより、証憑データの仕訳結果を取得する。
前記構成によれば、会計処理サーバー１０は、証憑データについて自動仕訳を実行しつつ、自動仕訳による仮仕訳結果を、依頼先から返信された仕訳結果データに基づいて修正する。これにより、証憑に対する仕訳の正確性をより高めることができる。

また、本実施形態によれば、仕訳処理部１５は、機械学習により作成された仕訳用モデル（仕訳エンジン１９）を用いて証憑データの仕訳（ステップＳ３０１）を実行し、取得した仕訳結果（確定仕訳結果）を仕訳用モデルに学習させる（ステップＳ３１２）。
前記構成によれば、会計処理サーバー１０は、機械学習により仕訳の精度を高めた仕訳エンジン１９を用いることで、自動仕訳の正確性を高めることができる。また、確定仕訳結果を仕訳エンジン１９に学習させることで、自動仕訳の正確性をより高めることができる。なお、仕訳エンジン１９は、Deep Learning以外の機械学習の手法により作成された仕訳用モデルであってもよい。

ただし、仕訳処理部１５が証憑データの仕訳（ステップＳ３０１）を実行する構成は必須ではない。つまり、図２，３のフローチャートにおいてステップＳ３０１，Ｓ３１２を省き、ステップＳ３１０では、Ｎ個の依頼先から送信された各仕訳結果データに基づいて正解の仕訳結果を決定し、この正解の仕訳結果を確定仕訳結果として取得してもよい。

また、本実施形態によれば、依頼送信部（第２通信部１４）は、前記依頼を複数の依頼先へ送信し、仕訳処理部１５は、複数の依頼先から仕訳受信部（第２通信部１４）が受信した複数の仕訳結果データに基づいて証憑データの仕訳結果を取得する。
前記構成によれば、会計処理サーバー１０は、外部の複数の依頼先の仕訳能力を利用して証憑データの仕訳結果を取得することにより、仕訳の正確性を高めることができる。

また、本実施形態によれば、依頼送信部（第２通信部１４）は、予め登録した複数の登録依頼先の中から証憑データの種類に応じて依頼先を１つ以上決定し（ステップＳ３０５）、決定した依頼先へ前記依頼を送信する。
前記構成によれば、会計処理サーバー１０は、複数の登録依頼先の中から証憑データの種類に応じて依頼先を決定することにより、証憑データに応じた最適な依頼先を決定することができる。

また、本実施形態によれば、会計処理サーバー１０は、複数の登録依頼先毎の仕訳能力を記録した依頼先評価テーブル２０を保持しており、依頼送信部（第２通信部１４）は、依頼先評価テーブル２０を参照して、複数の登録依頼先の中から証憑データの種類に応じて依頼先を決定する。
前記構成によれば、依頼先評価テーブル２０に記録された登録依頼先の仕訳能力、例えば、対応する分野や、これまでに実行した仕訳の成績を参照することにより、証憑データの仕訳の依頼先に相応しい優秀な依頼先を確実に決定することができる。

また、本実施形態によれば、会計処理サーバー１０は、前記依頼に対して仕訳結果データを返信した依頼先に対して報酬としてのポイントを付与するポイント処理部１６を備える。
前記構成によれば、前記依頼に対して仕訳結果データを返信した依頼先に対して適切に報いることができる。また、依頼先に、会計処理サーバー１０が提供するサービスの一部を担うことに対する動機を与えることができる。

また、本実施形態によれば、ポイント処理部１６は、前記取得された仕訳結果（確定仕訳結果）と一致する仕訳結果データの返信元である依頼先に対して付与するポイントを、前記取得された仕訳結果と一致しない仕訳結果データの返信元である依頼先に対して付与するポイントよりも多くする。
前記構成によれば、正確な仕訳結果を提供してくれた依頼先に対して、より高い報酬（ポイント）を与えることができる。

また、本実施形態によれば、会計処理サーバー１０は、証憑データの仕訳に用いられる追加情報の要求を証憑データの送信元へ送信する要求送信部（第１通信部１３）を備え、証憑受信部（第１通信部１３）は、証憑データの送信元から前記要求に対して返信された追加情報を受信し（ステップＳ３０４）、依頼送信部（第２通信部１４）は、前記依頼と追加情報とを、依頼先へ送信する。
前記構成によれば、会計処理サーバー１０は、証憑データだけでなく追加情報も証憑データの送信元から取得し、この追加情報を仕訳依頼の依頼先へ送信する。これにより、依頼先が実行する仕訳の正確性をより高めることができる。

なお、ステップＳ３０８（図３参照）の判定において、仕訳処理部１５は、Ｎ個の依頼先のうちの半数以上の依頼先の仕訳結果が一致するか否かを判定する、と説明した。しかし、“半数以上”という判定基準は一例である。仕訳処理部１５は、Ｎ個の依頼先のうちの、例えば７０％以上の依頼先の仕訳結果が一致するか否かを判定する、としてもよい。この場合、ステップＳ３１０では、仕訳処理部１５は、ステップＳ３０８でＮ個の依頼先のうちの７０％以上の依頼先の仕訳結果が一致すると判定したときの当該一致する仕訳結果を、正解の仕訳結果とする。

また、第２通信部１４は、ステップＳ３０６において送信する仕訳依頼に含める証憑データについては、証憑内の個人情報をマスクするためのフィルター処理を施したり、複製防止のためのマークを付与したりした上で、仕訳依頼に含めて送信するとしてもよい。

１…システム、１０…会計処理サーバー、１１…制御部、１１ａ…ＣＰＵ、１１ｂ…ＲＯＭ、１１ｃ…ＲＡＭ、１２…プログラム、１３…第１通信部、１４…第２通信部、１５…仕訳処理部、１６…ポイント処理部、１７…記憶部、１８…通信ＩＦ、１９…仕訳エンジン、２０…依頼先評価テーブル、３０…第１端末、４０…第２端末、５０，６０…ＳＮＳ画面、６１…仕訳画面、７０…ＳＮＳサーバー

Claims (11)

1. 証憑の電子データである証憑データを受信する証憑受信部と、
   前記証憑データの仕訳の依頼を外部の依頼先へ送信する依頼送信部と、
   前記依頼先から返信された、前記依頼に対する仕訳結果を示す仕訳結果データを受信する仕訳受信部と、
   前記仕訳結果データに基づいて、前記証憑データの仕訳結果を取得する仕訳処理部と、を備えることを特徴とする会計処理サーバー。
2. 前記会計処理サーバーは、ソーシャルネットワーキングサービスを提供するシステムと接続し、
   前記依頼送信部は、前記ソーシャルネットワーキングサービスを介して前記依頼を送信し、
   前記仕訳受信部は、前記ソーシャルネットワーキングサービスを介して前記仕訳結果データを受信する、ことを特徴とする請求項１に記載の会計処理サーバー。
3. 前記仕訳処理部は、前記証憑データの仕訳を実行し、前記実行した仕訳の結果を前記仕訳結果データに基づいて修正することにより、前記証憑データの仕訳結果を取得することを特徴とする請求項１または請求項２に記載の会計処理サーバー。
4. 前記仕訳処理部は、機械学習により作成された仕訳用モデルを用いて前記証憑データの仕訳を実行し、前記取得した仕訳結果を前記仕訳用モデルに学習させることを特徴とする請求項３に記載の会計処理サーバー。
5. 前記依頼送信部は、前記依頼を複数の依頼先へ送信し、
   前記仕訳処理部は、前記複数の依頼先から前記仕訳受信部が受信した複数の前記仕訳結果データに基づいて前記証憑データの仕訳結果を取得する、ことを特徴とする請求項１〜請求項４のいずれかに記載の会計処理サーバー。
6. 前記依頼送信部は、予め登録した複数の登録依頼先の中から前記証憑データの種類に応じて前記依頼先を１つ以上決定し、前記決定した依頼先へ前記依頼を送信することを特徴とする請求項１〜請求項５のいずれかに記載の会計処理サーバー。
7. 前記会計処理サーバーは、前記複数の登録依頼先毎の仕訳能力を記録した依頼先評価テーブルを保持しており、
   前記依頼送信部は、前記依頼先評価テーブルを参照して、前記複数の登録依頼先の中から前記証憑データの種類に応じて前記依頼先を決定する、ことを特徴とする請求項６に記載の会計処理サーバー。
8. 前記依頼に対して前記仕訳結果データを返信した前記依頼先に対して報酬としてのポイントを付与するポイント処理部を備えることを特徴とする請求項１〜請求項７のいずれかに記載の会計処理サーバー。
9. 前記依頼送信部は、前記依頼を複数の依頼先へ送信し、
   前記仕訳処理部は、前記複数の依頼先から前記仕訳受信部が受信した複数の前記仕訳結果データに基づいて前記証憑データの仕訳結果を取得し、
   前記ポイント処理部は、前記取得された仕訳結果と一致する前記仕訳結果データの返信元である前記依頼先に対して付与するポイントを、前記取得された仕訳結果と一致しない前記仕訳結果データの返信元である前記依頼先に対して付与するポイントよりも多くする、ことを特徴とする請求項８に記載の会計処理サーバー。
10. 前記証憑データの仕訳に用いられる追加情報の要求を前記証憑データの送信元へ送信する要求送信部を備え、
    前記証憑受信部は、前記証憑データの送信元から前記要求に対して返信された前記追加情報を受信し、
    前記依頼送信部は、前記依頼と前記追加情報とを前記依頼先へ送信する、ことを特徴とする請求項１〜請求項９のいずれかに記載の会計処理サーバー。
11. 証憑の電子データである証憑データを受信する証憑受信工程と、
    前記証憑データの仕訳の依頼を外部の依頼先へ送信する依頼送信工程と、
    前記依頼先から返信された、前記依頼に対する仕訳結果を示す仕訳結果データを受信する仕訳受信工程と、
    前記仕訳結果データに基づいて、前記証憑データの仕訳結果を取得する仕訳処理工程と、を備えることを特徴とする会計処理方法。

Images