JP2020166869A - 会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法 - Google Patents

Abstract

【課題】顧問先を複数抱える会計事務所や税理士事務所、税理士法人の、一連の業務処理を支援するための会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供する。【解決手段】会計事務所の日常作業の中で、顧問先からの様々なデータに対して、素早く受信に気付けるようにすると共に、１つの統合画面からの単純操作で、データの取り込みやデータに不備がないかの確認が出来るように操作性を統一する。更にデータの取り込み、監査、帳表作成、決算・申告処理、税務申告等までの実務をメニュー化し、統合することにより、財務・税務の一体処理を実現する。【効果】財務システムや税務システム、顧客情報システムなど、関連するシステムを自在に行き来できることで、突き付けが必要なデータの参照・確認なども手際よく行え、会計事務所の実務を総合的に効率化できる。【選択図】図１−２

Description

本発明は、お客様、顧客（以下、顧問先）を複数抱５える会計事務所や税理士事務所、税理士法人（以下、会計事務所）の、一連の業務処理を支援するための技術に関するものである。

昨今の会計事務所は、主に記帳を受託する事務所や主に監査を得意とする事務所など、事務所毎の業務処理に対して様々な特色を持つことが多いが、その中で基本的な業務として、「顧問先への経理指導、記帳・自計化指導」→「データ受取」→「会計処理」→「決算税務・電子申告」→「顧問先への資料提出」という一連の順番・流れ・状況の把握をする、ワークフローや業務フローとも呼ばれる業務処理において、精度、早さの要求は、今もなお顧問先への対応において、求められている。

この、顧問先から会計事務所、そして顧問先へと返るの一連の業務処理に対し、自動化や省力化を導入することで緊密な連携となり、双方にまたがる一連の処理を、スムーズかつシームレスに実現するものである。

会計事務所では、顧問先を１〜Ｎ社のサポートをしている。
昨今の技術進歩により、顧問先内の業務システムは、多種多様になっているなか、会計事務所では、所内で担当者を割り当てながら、各顧問先へのサポートをしている。
また、会計事務所では、その顧問先に対する進捗を確認しながら、会計事務所のアドバンテージを出せるように、過去の傾向、記帳アプリケーションソフトウェア（以下、アプリ）の操作、仕訳科目の出現頻度、仕訳後の状況を見ながら、日頃から顧問先の自計化を推進・教育・アドバイスなどをしている。

その中で、会計事務所では、様々なデータ形式のデータ（領収書等、カード明細、銀行カード情報等や、顧問先で入力した仕訳情報、帳簿情報等）を受信し、仕訳が正常であることを確認し、決算情報としてまとめ、監査し、作成した財務帳表等を顧問先に報告確認し、電子申告を行うような、一連の対応をしている。

財務帳表等の作成の過程では、顧問先毎に統一したメッセージを用意して、顧問先に提出する際のメッセージを添えることで、簡単に更なるアドバイスができるような効率的な手法を含めた、統合管理システムの改良も進められてる。

従来、会計事務所では、複数の顧問先から、様々なベンダのアプリで作成されたデータが送られてくるが、データが送られてきたかどうかを確認する方法として、送られてきたデータに適したアプリを起動して確認する方法や、メッセージやデータの送受信管理システムを使用する方法がある。

また、送られてきたデータに異常がないかを確認する方法として、データを編集用アプリで開いて目視でチェックする方法や、チェック用アプリを利用して自動チェックする方法がある。ただし、データをチェックするためのチェック用アプリは１つとは限らず、複数のチェック用アプリを利用して１つのデータをチェックしなければならない場合もある。

送られてきたデータは、どのような処理を望んだものか、依頼内容のメッセージと共に送られてくるものがある一方、定期的な報告のためや、アプリ内でのデータの送信やり取りのため等の理由で、依頼内容のメッセージがないものもある。依頼内容のメッセージがないデータに対しては、依頼内容を、送信元の顧問先に電話等で聞いたり、会計事務所内で作業履歴を確認することで推測したり、アプリ内のワークフロー管理機能で把握したりすることで対応している。

このように会計事務所では、複数の顧問先の様々なベンダのアプリのデータを、受信したかを様々な方法でキャッチアップし、データが正しいものかを色々な方法で確認し、作業順番を重要度・優先度で判断しながら割り振り、データの取り込みを進捗確認しながら行い、仕訳等の実際の作業をデータ毎の専用アプリで行うなどの一連の作業を、作業履歴を残しながら顧問先毎に対応している。また、一連の作業を可能とするために、複数の顧問先が送信するデータを取り扱うための様々なベンダのアプリの管理（インストール、バージョンアップ等）や、メンテナンスも行っている。

そのため、受信データの管理を簡易化する方法や、データを受信してから迅速に対応する方法、複数の顧問先から同時に依頼があった際に効率良く処理する方法、対応するための様々な操作を簡易化する方法、作業の履歴を効率よく行う方法が重要になっていた。また、様々なベンダのアプリ管理も重要になっていた。

もう一方の見方として、会計事務所に関して、設立当初は顧問先が少ないながらも、主に記帳代行を受託する会計事務所や、主に監査を得意とする会計事務所、主に相続対応を得意とする会計事務所など、様々な特色を持たせて顧問先の数を増やし、会計事務所の所員（以下、作業員）も増員していく成長過程で、日々の業務を遂行しながら、日頃から顧問先の自計化を推進・教育・アドバイスなどをしている状況がある。

日々の業務では、顧問先から伝票（紙ベース）をそのまま受領したり、多種多様の業務システム、様々なベンダのアプリケーションソフトウェア（以下、アプリ）を持つ顧問先の、それらアプリや業務システムなどで生成された様々な形式のデータ（領収書、カード明細、銀行カード情報、顧問先で入力した仕訳情報、帳簿情報、顧問先情報等）を、メーラーやクラウドストレージ、アプリ独自の送受信機能を使うなどで、インターネットで受信、またはＵＳＢメモリ等のメディアを用いて受領するなどの体制を整えたり、受領したデータに不備がないかを確認したりしながら、会計事務所内の会計アプリへ入力して（取り込んで）仕訳作業をするために、過去の状況における傾向や、仕訳科目の出現頻度などを見たり、記帳アプリの記帳支援機能を活用したり、会計事務所内の作業員同士の情報共有や顧問先から付加情報を聞き出したり、仕訳した会計データが正しいことをチェック専用アプリでチェックをしたりして、最終的には、記帳代行や仕訳、決算財務帳表作成なども含んだ基本的な業務である、「顧問先への経理指導、記帳・自計化指導」→「データ受取」→「会計処理」→「決算税務・電子申告」→「顧問先への資料提出」という順番、流れ、ワークフローや業務フローとも呼ばれる一連の業務を、状況を把握しながら、各対応アプリを個別に起動して確認する手間、組み合わせの問題、整合性の問題、操作性の問題もある。

これら日々の業務は、複数の顧問先に対して行う業務であって、効率良く作業を進めるためには、顧問先毎に進捗管理と合わせて、全ての顧問先の進捗状況を管理する必要もあり、会計処理という実務の他に係る業務が多岐に渡る。
例えば、顧問先からデータとして証憑を受信する際の業務フローは、データが送られてきたかどうかを確認、チェック用アプリを利用してデータに異常がないか、不足情報がないかを確認、データを編集用アプリで開いて目視で間違いがないか、不足情報がないかを確認、データの間違い修正、不足情報（仕訳、勘定科目等）の追記等を行い、データを保存する、という流れに沿って対応する。

データが送られてきたことを認識するには、主にアプリを起動してデータの有無を確認して認識しているが、顧問先からの電話やメール等の連絡を受けて気付く、または問い合わせて認識するなど、多くは人手に頼った方法で認識していた。 最近では、バックグラウンドで動作するシステムまたはアプリが、画面上に受信したことを表示させたりするが、対応するデータしか表示できなかったり、短時間の表示だったりと利便性は低い。

何のデータなのか、どのような処理を望んだデータなのかを把握した後、そのデータに適したアプリ（編集用アプリ、チェック用アプリ、取り込み用アプリなど）を、複数の業務アプリから自己判断で選んでアプリを起動していた。

記帳関連データであれば記帳関連アプリ等へ、監査関連データであれば会計アプリ等へ、汎用アプリで作成された会計データであれば、汎用アプリで変換してから会計アプリ等へ、メーカー独自の会計アプリ（システム）のデータであれば、必要に応じて変換してから会計アプリ等へ、証憑画像であれば、OCR解析アプリ等から証憑関連アプリへと取り込んでいた。以上から分かる通り、顧問先から受信するデータを取り込む入口がバラバラで煩雑であった。

受信したデータのチェックにチェック用アプリを使用したりするが、使用するチェック用アプリは１つとは限らず、データによっては複数のチェック用アプリを利用し、最初はチェック用アプリＡ、次はチェック用アプリＢ・・・など、順番通りにアプリを起動してチェックすることで、やっと１つのデータのチェックを終えることができるものもあった。

前述の「適したアプリ」に関して補足すると、財務の業務は財務アプリ系（または財務システム、更に会計データ入力や帳表作成などの詳細な分類をアプリ化しているものもある）で、税務の業務は税務アプリ系（または税務システム、更に法人税申告や電子申告作成などの詳細な分類をアプリ化しているものもある）でと、それぞれの業務毎に独立したアプリを起動し、必要に応じて顧客ファイル管理アプリ（またはシステム）、業務進捗管理アプリ（またはシステム）、スケジュール管理アプリ（またはシステム）などで作業を行っていた。

このように会計事務所では、複数の顧問先の様々なベンダのアプリで生成されたデータを、様々な方法で受信したことをキャッチアップ（認識）し、色々な方法でデータにエラーや不備がないことを確認し、重要度・優先度で作業順番を判断しながら、作業員に業務を割り振り（分担し）、データの取り込みの進捗確認をしながら、データ毎に適したアプリを起動させて、仕訳などの実際の作業を、顧問先毎に作業履歴を残しながら対応している。 また、このような作業を行うために、会計事務所内の環境を、顧問先が使用している様々なベンダのアプリに合わせている（アプリのインストール、バージョンアップなどのメンテナンスをしている）。

一方、顧問先からは、顧問先サービスに対しての対応の正確さや早さの要求があるため、受信データの管理を簡易化する方法や、データを受信してから迅速に対応する方法、複数の顧問先から同時に依頼があった際に効率良く処理する方法、対応するための様々な操作を簡易化する方法、作業の履歴を効率よく行う方法、顧問先のサポート効率化が重要になっている。また、様々なベンダのアプリ管理も重要になっている。

そして、顧客満足度アップや、他の会計事務所との比較でアドバンテージを出すことは、今もなお会計事務所における課題でもある。
会計事務所の人手不足、職員の退職による作業員のスキルによる作業ばらつきなど、課題も多い。

それらの課題に対して、メッセージやデータの送受信管理システムを使用する方法や、顧問先毎に統一したメッセージを用意して、顧問先に提出する際のメッセージを添えることで、簡単に更なるアドバイスができるような効率的な手法を含めた、統合管理システムの改良などの技術を発展させてきた。

しかし、今もなお、顧問先データの取り込みの入り口がバラバラであることや、アプリを起動するまでデータの受信が分からないことから、色々なアプリベンダを使い分けしている会計事務所の日常作業の中で、顧問先からのデータ受信に気付くのが遅れることがあり、人手に頼った確認方法は、非効率的である状況は変わらない。

そのような問題を解決するために、受信データの管理を簡易化する方法として、アプリのデータを顧問先毎、年度毎、業務種別毎に管理する技術が開示されている（例えば、特許文献１参照）。
しかし、この技術では、顧問先毎に管理するため、その日に受信した複数の顧問先のデータを一括表示することができず、その日の業務量を見積もることや、複数の顧問先からの受信データを全て見並べて優先度をつけることができない課題がある。

また、一連の作業に融通を持たすやり方を簡易的に管理する方法として、作業者がリストから選択することで、適切なワークフローでの作業が実施でき、かつその作業履歴を管理できる技術が開示されている（例えば、特許文献２参照）。
しかし、この技術では、作業者が作業に対して適切なワークフローを知っていることが前提のため、ワークフローの選択肢の数の多さ、複雑さと、作業者の熟練度によっては、リストから選択することが難しくなるという課題がある。

また、ＥＲＰ（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ）パッケージという、例えば、代表的な承認ワークフローや決裁ワークフローなどを統合的に管理するシステムもあるが、その環境を維持したまま、ＥＣ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ）メディアが提供するサービスを利用する技術が公開されている（例えば、特許文献３参照）。
しかし、この技術では、ＥＲＰパッケージ内での、１つのワークフローの管理に留まっているため、顧問先から受信したデータ毎に発生する、複数のワークフローに対応することができないという課題もある。

さらに、様々なベンダのアプリの管理を容易にする方法として、指定日時に確実にアプリを稼働させる記述が開示されている（例えば、特許文献４参照）。
しかし、この技術では、作業者が起動するアプリを指定しなければならないため、受信したデータ形式に対応する様々なアプリを管理するには、作業者の管理システムがどのアプリのどのバージョンに対応しているかという知識が必要であり、容易に管理できないという課題もある。

特許第４９９１２４７号公報 特開平１１−３０６２５３ 特開平１１−１６７５９０ 特開２００４−２２００７９

従来、会計事務所のみならず、顧問先でも、様々なベンダのアプリが使われる環境がある。そのため、顧問先から会計事務所に提供されるデータは、様々なデータ形式のものが存在する。会計事務所では、様々なデータ形式のデータであっても、会計事務所にあるアプリに取り込むようにする技術も必要になる。しかも、会計事務所では、複数の顧問先に対する業務を行うため、顧問先毎に管理する必要があるし、全ての顧問先の進捗状況を管理する必要もあり、会計処理という実務の他に係る業務が多岐に渡る。

そのような中、会計事務所の日常作業の中で、顧問先からのデータ受信に気付くのが遅れることが課題である。
また、受信データをアプリに取り込む前に、データに不備があることに気付かず、余計な手間が掛かることが課題である。
また、受信データに対し、アプリへの取り込み作業やデータに不備がないかの確認作業は、受信データ毎に適したアプリや、チェック用アプリを、それぞれに起動して行う必要があり、操作性が煩雑な点も課題である。
また、データ受信の履歴や作業の履歴は、アプリ毎等で記録できていたが、一連の作業の進捗を把握するのにそれぞれの履歴を確認して時系列に並べるなどをしなければならないため、時間が掛かるという課題がある。
また、多岐に渡る会計事務所の作業には、作業員の知識レベルや熟練度によって、適切なアプリの選択判断や選択スピードに違いが生じてしまう課題がある。
また、会計データ、法人税申告関連データ、消費税関連データなどは、連動したアプリで生成されるデータのため、複数のチェック用アプリでデータに不備がないかを確認する必要があり、煩雑な作業になってしまう課題がある。
また、アプリのメニューやアイコンからアプリを個々に起動したりする必要があったり、操作がその都度異なったり出力指示も統一されていないという課題がある。
また、法人税申告書の作成、減価償却の振替処理、内訳書の作成などの法人申告業務は、私用するアプリケーションや集計する金額が多岐にわたり、会計データとの照合に手間がかかるという課題がある。

会計事務所の実際の業務において、会計事務所と顧問先とを一体したシステムの課題について、解決するための構想となる「財務から税務へと繋がる一連の処理を一筆書きで実行する」とは、「顧問先への経理指導、記帳・自計化指導」→「データ受取」→「会計処理」→「決算税務・電子申告」→「顧問先への資料提出」という一連のワークフローにおいて、顧問先から会計事務所、そして顧問先へと返るの一連の実務の流れに対し、自動化や省力化を導入することで緊密な連携が必要となり、双方にまたがる一連の処理を、スムーズかつシームレスに実現したいという課題がある。

そのためには、取引の発生現場である顧問先の処理を、適切かつ迅速にチェックすることがこれまで以上に重要となり、両者が緊密に連携できるシステムが不可欠となる。また、専門知識を必要とせず、作業員の誰にでも簡単に使いこなせる親和性・利便性が重要である。

そして、データ受信の認識に対する効率化を図る機能として、従来、データ形式毎に異なるアプリを起動させて、データ受信を認識していた（人手に頼った）認識方法を、「管理システム」が複数のアプリまたはシステムの連動によって、受信したデータを一括管理することで、バックグラウンド処理による画面表示と、その管理システム（メニュー）のポータルサイトで、受信データの一括表示（通知）をすることで効率的な作業ができる

そして、本発明は、会計事務所の日常作業の中で、顧問先からの様々なデータに対して、素早く受信に気付けるようにすると共に、１つの統合画面からの単純操作で、データの取り込みやデータに不備がないかの確認が出来るように操作性を統一し、データの取り込み、監査、帳表作成、決算・申告処理、税務申告等までの実務をメニュー化し、統合することにより、財務・税務の一体処理を実現し、財務システムや税務システム、顧客情報システムなど、関連するシステムを自在に行き来できることで、突き付けが必要なデータの参照・確認なども手際よく行え、会計事務所の実務を総合的に効率化することで、一筆書きのような明確な業務フローを支援できるシステムを提供しつつ、イベントや作業等の履歴も管理することができる会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供する。

本発明は、以下のような解決手段により、前記課題を解決する。

第１の発明は、会計事務所の端末（以下、会計事務所端末）と、複数の顧問先の端末（以下、顧問先端末）がネットワークで接続された構成において、複数の顧問先からの様々なアプリケーション（以下、アプリ）用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができるシステムであって、顧問先端末は、様々なアプリ用データを送受信することが可能なデータ送受信手段を備え、会計事務所端末は、複数の前記顧問先端末により前記データ送受信手段から送信された前記アプリ用データを受信するデータ受信手段と、前記データ受信手段により受信した受信データの状況を判断するデータ状況判断手段と、前記データ状況判断手段により判断されたデータ状況に応じ、重要度または処理優先度を判定するデータ重要度判定手段と、 前記受信データの受信時に異常を判断するデータ異常判断手段と、前記受信データの内容を表示、または編集、またはチェックするために最適なアプリを１ないし複数起動させるアプリ起動手段と、前記受信データを適切なアプリに取り込むためのデータ取込手段と、前記アプリ用データに関するイベントが発生する度に、その履歴と、一連の業務処理内での進捗状況をイベントログ記録部に記録するイベントログ記録手段と、前記データ受信手段によりデータを受信したことを通知するデータ受信通知手段と、複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち１以上と、受信データとを一括表示する受信データ一括表示手段と、データ形式をシンボル化して操作手段も付加したシンボル表示手段と、前記データ状況判断手段で判断された状況を表示するデータ状況表示手段と、前記データ重要度判定手段により判定された重要度、または処理優先度を表示するデータ重要度表示手段と、前記データ異常判断手段で異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示手段と、前記アプリ起動手段でアプリを起動させるためのボタンを表示するアプリ開始ボタン表示手段と、前記データ取込手段で取り込みを開始するためのボタンを表示する取込開始ボタン表示手段と、前記データ異常判断手段により、異常があると判断された前記受信データの内容を確認する適切なアプリを起動するための、ボタンを表示する異常データ確認開始ボタン表示手段と、前記イベントログ記録手段により、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化する進捗状況表示手段とを備える会計事務所端末とを備えることを特徴とする会計処理システムである。
第２の発明は、第１の発明に記載の会計処理システムにおいて、前記会計事務所端末は、前記受信データを管理できる前記会計処理システムとは異なる１ないし複数の会計処理システムを備え、前記会計処理システムから、前記会計処理システムとは異なる会計処理システムへの切替えを、ボタン、プルダウンメニューの一つを含むインターフェースによる操作で切り替えることが可能な会計処理システム切替手段を備える会計事務所端末を特徴とする会計処理システムである。
第３の発明は、第１の発明ないし第２の発明に記載の会計処理システムにおいて、前記顧問先端末と前記会計事務所端末は、アプリのインストールやバージョンアップのイベントのうちの一つが発生した時や、手動要求、遠隔操作要求、曜日指定による定期的な要求のうちの一つが発生した時に、アプリの名称、バージョン、インストール日、バージョンアップ日のアプリ情報のうち、一つ以上をアプリ情報管理記録部またはイベントログ記録部に記録するアプリ情報記憶手段を備え、前記会計事務所端末は、さらに前記顧問先端末の前記アプリ情報を取得する送信元端末装置アプリ情報取得手段と、前記送信元端末装置アプリ情報取得手段により取得した前記顧問先端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定する送信元アプリ対応判定手段と、前記会計処理システムに対応していないと判定した場合は、その旨を表示する送信元端末装置非対応通知手段と、前記会計事務所端末のアプリ情報取得手段により取得した前記会計事務所端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定するアプリ対応判定手段と、前記会計処理システムに対応していないと判定した場合は、その旨を表示する端末装置非対応通知手段とを備えること、を特徴とする会計処理システムである。
第４の発明は、会計事務所端末と、複数の顧問先端末がネットワークで接続された構成において、複数の顧問先からの様々なアプリ用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができる装置あって、顧問先端末は、様々なアプリ用データを送受信することが可能なデータ送受信手段を備え、会計事務所端末は、複数の前記顧問先端末により前記データ送受信手段から送信された前記アプリ用データを受信するデータ受信手段と、前記データ受信手段により受信した受信データの状況を判断するデータ状況判断手段と、前記データ状況判断手段により判断されたデータ状況に応じ、重要度または処理優先度を判定するデータ重要度判定手段と、 前記受信データの受信時に異常を判断するデータ異常判断手段と、前記受信データの内容を表示、または編集、またはチェックするために最適なアプリを１ないし複数起動させるアプリ起動手段と、前記受信データを適切なアプリに取り込むためのデータ取込手段と、前記アプリ用データに関するイベントが発生する度に、その履歴と、一連の業務処理内での進捗状況をイベントログ記録部に記録するイベントログ記録手段と、前記データ受信手段によりデータを受信したことを通知するデータ受信通知手段と、複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち１以上と、受信データとを一括表示する受信データ一括表示手段と、データ形式をシンボル化して操作手段も付加したシンボル表示手段と、前記データ状況判断手段で判断された状況を表示するデータ状況表示手段と、前記データ重要度判定手段により判定された重要度、または処理優先度を表示するデータ重要度表示手段と、前記データ異常判断手段で異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示手段と、前記アプリ起動手段でアプリを起動させるためのボタンを表示するアプリ開始ボタン表示手段と、前記データ取込手段で取り込みを開始するためのボタンを表示する取込開始ボタン表示手段と、前記データ異常判断手段により、異常があると判断された前記受信データの内容を確認する適切なアプリを起動するための、ボタンを表示する異常データ確認開始ボタン表示手段と、前記イベントログ記録手段により、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化する進捗状況表示手段とを備える会計事務所端末とを備えることを特徴とする会計処理装置である。
第５の発明は、第４の発明に記載の会計処理装置において、前記会計事務所端末は、前記受信データを管理できる前記会計処理システムとは異なる１ないし複数の会計処理システムを備え、前記会計処理システムから、前記会計処理システムとは異なる会計処理システムへの切替えを、ボタン、プルダウンメニューの一つを含むインターフェースによる操作で切り替えることが可能な会計処理システム切替手段を備える会計事務所端末を特徴とする会計処理装置である。
第６の発明は、第４の発明ないし第５の発明に記載の会計処理装置において、前記顧問先端末と前記会計事務所端末は、アプリのインストールやバージョンアップのイベントのうちの一つが発生した時や、手動要求、遠隔操作要求、曜日指定による定期的な要求のうちの一つが発生した時に、アプリの名称、バージョン、インストール日、バージョンアップ日のアプリ情報のうち、一つ以上をアプリ情報管理記録部またはイベントログ記録部に記録するアプリ情報記憶手段と、を備え、前記サーバー装置または前記会計事務所端末は、さらに前記顧問先端末の前記アプリ情報を取得する送信元端末装置アプリ情報取得手段と、前記送信元端末装置アプリ情報取得手段により取得した前記顧問先端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定する送信元アプリ対応判定手段と、前記会計処理システムに対応していないと判定した場合は、その旨を表示する送信元端末装置非対応通知手段と、前記サーバー装置または前記会計事務所端末のアプリ情報取得手段により取得した前記会計事務所端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定するアプリ対応判定手段と、前記会計処理システムに対応していないと判定した場合は、その旨を表示する端末装置非対応通知手段とを備えること、を特徴とする会計処理装置である。
第７の発明は、税務申告を行なうためになされる一連の処理に対応する複数の作業項目を含む作業手順の順序に従って実行する会計処理装置において、証憑の電子データを参照して仕訳を入力する会計データを作成し、前記会計データと前記証憑の電子データと関連付けする会計参照入力手段と、前記会計データを参照して帳表データを作成し、前記帳表データと前記会計データと関連付けする帳表作成手段と、前記会計データを参照して明細データを作成し、前記明細データと前記会計データと関連付けする明細書作成手段と、前記帳表データと前記明細データを参照して申告データを作成し、前記申告データと前記帳表データと前記明細データと関連付けする申告書作成手段と、前記申告データに署名を付与する電子署名手段と、作業項目として前記会計参照入力手段、前記帳表作成手段、前記明細書作成手段、前記申告書作成手段又は前記電子署名手段のいずれかを実行し、実行終了時に終了通知を発行する作業項目実行手段と、を備え、前記作業項目手段は所定の作業手順である作業項目を実行して、前記作業項目終了後に終了通知を発行する作業項目実行処理を行ない、全ての作業手順が終了するまで前記終了通知を受け付けるたびに前記作業項目実行処理を繰り返すことを特徴とする会計処理装置である。
第８の発明は、第７の発明に記載の会計処理装置において、前記作業手順に従って発行した作業項目毎の通知を作業手順の順序に並べて表示することで作業項目の進捗状況として表示する進捗状況管理手段を備えることを特徴とする会計処理装置である。
第９の発明は、第７の発明または第８の発明に記載の会計処理装置において、前記作業項目毎の処理履歴を記録する履歴記録手段を備えることを特徴とする会計処理装置である。
第１０の発明は、
第９の発明に記載の会計処理装置において、少なくとも前記進捗状況と前記処理履歴との組み合わせを学習した学習モデルと、前記進捗状況と前記処理履歴との組み合わせから最適な作業手順となる組み合わせを前記学習モデルが判定する作業手順判定手段と、を備えることを特徴とする会計処理装置である。
第１１の発明は、
会計事務所の端末（以下、会計事務所端末）と、複数の顧問先の端末（以下、顧問先端末）がネットワークで接続された構成において、複数の顧問先からの様々なアプリケーション（以下、アプリ）用データを、会計事務所が一元的に受信管理することが可能であり、かつ受信データの取り込みから税務申告までを一筆書きのように行うことができる方法であって、顧問先端末は、様々なアプリ用データを送受信することが可能なデータ送受信ステップを含み、会計事務所端末は、複数の前記顧問先端末により前記データ送受信手段から送信された前記アプリ用データを受信するデータ受信ステップと、前記データ受信ステップにより受信した受信データの状況を判断するデータ状況判断ステップと、前記データ状況判断ステップにより判断されたデータ状況に応じ、重要度または処理優先度を判定するデータ重要度判定ステップと、前記受信データの受信時に異常を判断するデータ異常判断ステップと、前記受信データの内容を表示、または編集、またはチェックするために最適なアプリを１ないし複数起動させるアプリ起動ステップと、前記受信データを適切なアプリに取り込むためのデータ取込ステップと、前記アプリ用データに関するイベントが発生する度に、その履歴と、一連の業務処理内での進捗状況をイベントログ記録部に記録するイベントログ記録ステップと、前記データ受信ステップによりデータを受信したことを通知するデータ受信通知ステップと、複数の顧問先から受信した複数のデータに関して、データ形式、商号コード、商号名、決算年月日のうち１以上と、受信データとを一括表示する受信データ一括表示ステップと、データ形式をシンボル化して操作手段も付加したシンボル表示ステップと、前記データ状況判断ステップで判断された状況を表示するデータ状況表示ステップと、前記データ重要度判定ステップにより判定された重要度、または処理優先度を表示するデータ重要度表示ステップと、 前記データ異常判断ステップで異常と判断された場合に前記受信データが異常であることを通知するデータ異常表示ステップと、前記アプリ起動ステップでアプリを起動させるためのボタンを表示するアプリ開始ボタン表示ステップと、前記データ取込ステップで取り込みを開始するためのボタンを表示する取込開始ボタン表示ステップと、前記データ異常判断ステップにより、異常があると判断された前記受信データの内容を確認する適切なアプリを起動するための、ボタンを表示する異常データ確認開始ボタン表示ステップと、前記イベントログ記録ステップにより、前記受信データの業務処理状況を取得し、前記受信データに対する業務進捗状況を視覚化する進捗状況表示ステップとを含む会計事務所端末とを含むことを特徴とする会計処理方法である。
第１２の発明は、
第１１の発明に記載の会計処理方法において、前記会計事務所端末は、前記受信データを管理できる前記会計処理システムとは異なる１ないし複数の会計処理方法であって、前記会計処理システムから、前記会計処理システムとは異なる会計処理システムへの切替えを、ボタン、プルダウンメニューの一つを含むインターフェースによる操作で切り替えることが可能な会計処理システム切替ステップ
を含む会計事務所端末を特徴とする会計処理方法である。
第１３の発明は、
第１１の発明ないし第１２の発明に記載の会計処理システムにおいて、前記顧問先端末と前記会計事務所端末は、アプリのインストールやバージョンアップのイベントのうちの一つが発生した時や、手動要求、遠隔操作要求、曜日指定による定期的な要求のうちの一つが発生した時に、アプリの名称、バージョン、インストール日、バージョンアップ日のアプリ情報のうち、一つ以上をアプリ情報管理記録部またはイベントログ記録部に記録するアプリ情報記憶ステップと、を含み、前記会計事務所端末は、さらに前記顧問先端末の前記アプリ情報を取得する送信元端末装置アプリ情報取得ステップと、前記送信元端末装置アプリ情報取得ステップにより取得した前記顧問先端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定する送信元アプリ対応判定ステップと、前記会計処理システムに対応していないと判定した場合は、その旨を表示する送信元端末装置非対応通知ステップと、前記会計事務所端末のアプリ情報取得ステップにより取得した前記会計事務所端末の前記アプリ情報が前記会計事務所端末の前記会計処理システムに対応できるか否かを判定するアプリ対応判定ステップと、前記会計処理システムに対応していないと判定した場合は、その旨を表示する端末装置非対応通知ステップとを含むこと、を特徴とする会計処理方法である。
第１４の発明は、
第１〜３の発明のいずれかに記載の会計処理装置としてコンピュータに機能させるためのプログラムである。

本発明によれば、
本発明である図５−２、図２−２のように、顧問先から送られたデータや資料の受信を一元的に管理し、受信したことを即時に会計事務所内へ通知するため、かつ重要度や優先度を踏まえてデータを一覧表示するため、日々の作業の中で、受信したデータの確認が迅速に行える。

また、
受信したデータ内に不備がある場合や注意が必要である場合には、作業員へ通知されるため、顧問先に再度データを送信してもらうなどの迅速な対応が出来るほか、経験不足の作業員でも、高いレベルでデータの不備や注意に気付くことができる。

そこで従来は、アプリ毎にアプリ起動時にデータの有無を確認し、取込処理を実行するものであったものを、
本発明によれば、図５−２の表示画面において、
１．アプリ起動しなくてもデータの有無を確認し、データの状態（金額相違や未決定勘定科目データチェックやバランスチェックや入力漏れ等の各種チェック結果、エラー状態や顧問先からのデータ受信、監査依頼や監査状況）等の情報（通知）を表示（データを選択した場合は連動して該当アプリを起動）、
２．選択したデータや重要度を加味して、必要な情報が把握しやすいような表示、
３．アプリ起動前にデータの状態を確認してデータの取り込み、データのエラーの確認、
再チェックやエラー内容（読み取れない画像データがある等）の確認や通知等を行う、
４．通知履歴の管理（履歴の一覧表示等）、
５．対象データと関連するデータ（財務と税務と画像）の対応関係をわかりやすく表示（電
子申告システムや法人申告統合システム等）、
６．ユーザーが行ったオペレーション（ジョブ記録）と顧問先からの受信データとチェック
結果を関連付けたデータ管理、
７．対象データと関連するデータを資料の用途に応じた一括管理及び出力（印刷、電子
帳表、データ出力、顧問先へデータ送信）設定、
８．受信した画像データを仕訳データに変換、
９．対象データと電子申告に関する情報（処理年、納税先、署名や納税者等）を関連付けて
一括管理、
１０．対象データと使用アプリを管理（ロックして他のアプリからは編集不可）
することができ、顧問先と会計事務所との関係強化と業務負担の軽減、ワークフローの支援をすることができる。

また、煩雑なプロセスを踏む決算・申告処理なども、作業員の知識レベル、熟練度に左右されず、
データの状況に応じて、業務フローに基づいた作業ができるアプリを、
迷うことなく簡素化された操作で起動でき、効率よく、迅速に作業を進めることができる。

また、様々なアプリやシステムも統合的に連携させることで、受信したデータがどのようなデータかを判別することができ、それによって、監査状況などデータの状態をアイコンやメッセージなどで表示することができ、次の業務フローが何かの参考にできる。また、それによって自動エラーチェックを行い、エラーがあった場合は警告通知をし、データの取り扱いに注意することができ、重要なエラーがあった場合には、重要なエラーがあることがわかるようなアイコンを表示することで、再度顧問先へデータを要求するなどの対応をしなければならないことを迅速に把握することができる。

また、エラー確認機能へ対応した受信したデータがある場合にのみ、エラーの確認／修正ボタンを表示したり、もし、受信したデータや作業等のログ等を情報源に、ユーザーへ通知する情報がない場合は、データの確認に必要となる最小限の情報（例えば、データの種類、コード、商号名、決算年月日など）に絞ったりして、画面に余分な表示をしないため、作業員の誤操作を防止できる。

また、多岐に渡る会計データと税務データを突き合わせながら行う決算・申告処理も、関連データの突き合わせチェックなどを容易する支援機能により、スムーズかつ素早く操作すること、ミスに気付くことができる。

また、可視化したスケジュールの支援機能により、迅速かつ漏れなく業務が遂行できる。

まとめると、本発明によれば、
財務・税務のデータ連携や連動により、財務と税務の一体処理を可能なるため、会計事務所の日常作業の中で、顧問先からの様々なデータに対して、素早く受信に気付けるようにすると共に、１つの管理画面で、受信したデータの一覧表示とそのデータにエラーがあるか、業務フロー内でどの位置にあるか、の情報等が一目で把握でき、次の作業ステップである、データの取り込みやデータに不備がないかの１ないし複数のチェックツールの起動、データを編集するための１ないし複数のアプリの起動などを簡素化、統一化された操作の入り口から進み、監査、帳表作成、決算・申告処理、決算報告、税務申告、電子申告まで、会計事務所における一連の様々な業務フローを、シームレスな一筆書きのように、明確な作業ルーチンを支援できるように提供し、イベントや作業等の履歴も管理することができる会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供することができる。

本発明の実施例になるシステム全体の構成図である。 上記本発明で使用されるデータの種類や流れを示す図である。 上記本発明のシステム全体における機能を示すブロック図である。 上記本発明によって財務、税務業務を一体処理するメニューを示す図である。 上記本発明で一体処理を実現するための管理データ構造とデータの一例を示す図である。 上記本発明で処理されるイベントや状態などのログを記録する例を示す図である。 上記本発明で業務の進行状況を管理するデータの構造とデータの一例を示す図である。 上記本発明におけるワークフロー処理のフローチャート図である。 上記本発明において、様々な受信データを一元的に受付するメニューの図である。 上記本発明において、様々な受信データについて条件表示するメニューの図である。 上記本発明におけるワークフロー処理のフローチャート図である。

以下、本発明を実施するための形態について、図を参照しながら説明する。なお、これは、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。
以下、説明する実施例１〜６において、
図１−１の端末装置１０、図２−１の顧問先端末１（１０１）は、それぞれ記載が異なるが、同一の顧問先の端末装置のことを指し、
図１−１のサーバー装置２０、図２−１のサーバー装置２（２０１）は、それぞれ記載が異なるが、同一の会計事務所のサーバー装置のことを指し、
図１−１の端末装置２１、図２−１の会計事務所端末３（４０１）は、それぞれ記載が異なるが、同一の会計事務所の端末装置のことを指す。

（実施例１）
以下に実施例１を記載するが、この実施例１によって本発明は限定されるものではない。
[全体構成]
図１−１は、本発明の実施例になるシステム全体の構成図である。

図１−１に示すシステム構成は１例であり、図中の会計事務所のサーバー装置２０は、サーバー装置２０の機能を端末装置２１と統合した端末装置に置き換えてもよい。
図２−１は、上記本発明のシステム全体における機能を示すブロック図である。
また、図２−１は、会計事務所の会計事務所端末３と、複数の顧問先（例えば、顧問先Ａ、顧問先Ｂ、・・・顧問先Ｎ）の内、一例として１つの顧問先のとした顧問先端末１と、会計事務所と顧問先の間で行われるデータのやり取りで中継されるサーバー装置２がネットワークで接続されたネットワークシステムの実施例でもある。

図１−１では、顧問先−会計事務所間のシステムとして示しているが、企業の本社等が各部門や各支店（の従業員）等を対象に財務管理を行う場合には、顧問先−会計事務所を支店−本社間のシステムとしてもよい。

図１−１の会計事務所の端末装置２１は１台あるように記載しているが、複数台あってもよい。
図１−１の顧問先の端末装置１０は、顧問先毎に１台あるように記載しているが、顧問先毎に複数台あってもよい。
また、会計事務所の端末装置２１や顧問先の端末装置１０は、デスクトップ型ＰＣやノート型ＰＣに限らず、スマートフォンやタブレット等の携帯端末でもよいし、実体が仮想化された仮想マシンでもよいし、必ずしも会計事務所内に設けられる必要はなく、外出先や自宅勤務の職員の端末装置や外注先の職員の端末装置でもよいし、端末装置が存在する場所を含め、その記載に限定されるものではない。

図２−１のサーバー装置２は、図１−１ではサーバー装置２０として１台で示しているが、複数台であってもよい。また、図２−１のサーバー装置２は、複数台を各地に点させてもよいし、業務委託等のサービスを行っている企業内に存在させてもよいし、クラウドサービスのようにデータセンターに存在させてもよいし、その記載に限定されるものではない。

[システム構成：データの流れ]
図１−２は、本実施形態に係る会計処理システムのデータの流れを示す図である。
図１−２に示すシステム構成上のデータの流れは、顧問先が会計事務所に対し、様々なデータを１つのアプリで送信し、会計事務所内で取り込まれ、監査、財務帳表の作成を行い、電子申告や顧問先への帳表提出などの一連の流れを記したものである。

図２−２は、上記本発明によって財務、税務業務を一体処理するメニューを示す図である。
図２−２に示すデータ連携は、受信したデータを財務処理業務５０１ないし税務処理業務５０２へ自由に行き来できるデータ連携を示すものであり、図１−２の会計事務所内の処理（財務帳表作成の前後）の監査処理２５３や電子申告２５５に係るものである。

[顧問先端末、会計事務所端末、サーバー装置のハードウェア]
図２−１は、本実施形態に係る装置の機能を示すのブロック図である。
図２−１に示す顧問先端末１、会計事務所端末３、サーバー装置２は、入力部、画像取込部、出力部（表示、印字）、通信部、制御部、記憶部の６つの機能を備える。これら６つの機能は、一般的なコンピュータの機能のため、詳細な説明は省略する。ただし、サーバー装置２に限っては、会計事務所端末３等から通信部を介して、サーバー装置２を操作する機能を備えた場合は、表示部を備えなくてもよい。

[顧問先端末：顧問先]
図２−１の顧問先端末１には、様々なアプリがインストールされており、様々なアプリによって、様々なデータ形式のデータが生成される。

従来は、顧問先（データを送る方）しか、データ形式、データ状況などを知らず、会計事務所は、顧問先とのメールやメッセージ、口頭などでの伝達によって、その情報を知ったあとでないと、作業が開始できないという状況だった。

本実施例では、顧問先端末１でデータを生成した際、図３−２のイベントログテーブルには、データを作成した目的が明確な場合はその目的をデータ状況、データ形式として記録されるほか、図３−１のアプリ情報テーブルの情報を元に、どのアプリのどのバージョンで作成したものか等の情報も記録される。その他、顧問先がデータを送る際に、データ形式を指定するようにしてもよい。
イベントログテーブル（図３−２）は、顧問先側（顧問先端末１）の他、会計事務所側（サーバー装置２）に存在する。 イベントログテーブルの項目は共通であるが、顧問先側のみ、または会計事務所側のみで記録される項目もある。

イベントログ情報を効果として、会計事務所でデータをチェックする際のチェック専用アプリはなにか、なんの作業から開始すればよいか、データを取り込む際のアプリはなにかなど、が分かることに加え、データのチェックや取り込みの作業を自動化してもよい。

例えば、顧問先が会計事務所に対してＡ銀行の入出金ＣＳＶファイルと指定して送信することで、会計事務所は、CSVファイルを選ぶだけで、Ａ銀行の取込設定を利用して、銀行明細データの取り込みが実行され、さらに口座名義情報含めて、科目や補助も決定し、自動入力できるようにしてもよい。
また、同じCSVのデータ形式でも、Ａ社の仕訳CSVであれば、会計データの取り込みをＡ社の設定で実行でき、資産データ一覧のデータ形式であれば、減価償却アプリへの取り込みが実行できる。

顧問先の顧問先端末１（図２−１）からサーバー装置２（図２−１）又は会計事務所の会計事務所端末３（図２−１）へ、データを送信する際、顧問先では、汎用性を持ったメーラーや、送信するデータ専用のアプリが持つデータ送受信機能等で送信することができる。

本実施例では、図１−２のように顧問先から会計事務所へ、送受信するための専用アプリを介して送信する。 送信されるデータは、顧問先にて様々なアプリで生成されたデータと、そのデータに関するイベントログ情報を一緒に送信する。 データに関するイベントログ情報とは、データの更新日時とイベントログテーブル（図３−２）の日時情報とを照合して合致した情報である。

[サーバー装置：会計事務所]
顧問先が会計事務所に送信したデータは、サーバー装置２（図２−１）が受信する。本実施例では、受信はサーバー装置２（図２−１）が行うものとして説明するが、会計事務所端末３（図２−１）で受信してもよいし、その記載に限定されるものではない。

サーバー装置２（図２−１）は、顧問先から送信されたデータ（イベントログ情報を含む）を受信すると、顧問先にて様々なアプリで生成されたデータは、記憶部（図２−１の２０３）にあるデータ記録部２１６へ記録し、受信したイベントログ情報（顧問先でデータを生成したときのアプリ名とアプリバージョン、データ形式など）は、会計事務所が受信した日時や受信したこと（データ状況）、受信データの名称、受信データの保存先、顧問先情報（商号コードや担当者等）等と共に記憶部（図２−１の２０３）にあるイベントログ記録部２１８のイベントログテーブル（図３−２）へ記録する。

また、サーバー装置２（図２−１）は、データを受信すると、受信したデータに問題ないかを自動でチェックする。具体的には、受信したデータのデータ形式に適した１以上のデータチェック専用アプリを作業員の操作なしで実行し、データが正常に読めるか、データをアプリに取り込む際に不足している箇所がないか、データ内の値に整合性が取れていない部分があるか（例えば、取引の税率が適切に軽減税率となっているかなどの会計処理の観点を含む）、取込済のデータと重複していないかなどの不備や異常を判定し、データに異常があった場合、受信データの記録と共に、軽度エラーや重度エラー等のエラー情報をイベントログテーブル（図３−２）に記録する。

また、データの不備など以外に、役員報酬が発生している月なのか、消耗品費だが１０万円以上の取引がないかなど、取り扱いに対する注意が必要なデータを自動で判別し、警告してもよい。

なお、データ内の値に整合性が取れていない部分があるかの判定項目に関しては、様々なチェック項目が考えられるが、本発明の本質とは異なるため、詳細な説明は省略する。

また、サーバー装置２（図２−１）は、データを受信すると、受信したデータの状況を判断する。
具体的には、受信したデータのイベントログ情報にデータ状況がある場合はその情報から、ない場合は、受信したデータと同じデータ形式の履歴のうち直近のデータ状況を、イベントログテーブル（図３−２）から検出し、業務進行テーブル（図３−３）に基づき、次のステップをデータ状況として判断する。

業務進行テーブル（図３−３）とは、記憶部（図２−１の２０３）に存在する業務進行記録部２１９（図２−１）に保存されており、データ形式ごとに行われる作業手順をテーブルにしたもので、例えば、データ形式が「伝票」の場合、「依頼受信→データ組込み→データ確認→修正確認→修正データ受信→データ確認済→監査→月次報告書作成→月次報告承認待ち→月次報告→報告完了」というステップ（図３−３に図示せず）を記録しているものである。
業務進行テーブル（図３−３）は、会計処理システムに既定値として持っているほか、作業員がテーブルを修正することや、新たなステップを追加することなどもできる。

また、サーバー装置２（図２−１）は、データを受信すると、受信したことを会計事務所端末３（図２−１）（の作業員）に通知する。具体的には、サーバー装置２（図２−１）から会計事務所端末３（図２−１）に対し、いつ、どの顧問先から、何のデータが届いたか等の簡易情報を含んだパケットを送信する。

[会計事務所端末：会計事務所]
会計事務所端末３（図２−１）は、サーバー装置２（図２−１）からデータを受信したという情報を通知するためのパケットを受信すると、アプリを立ち上げることなく、すぐに通知（画面に表示）する。

作業員は、本発明である会計処理システムの管理コンソールを起動する。この管理コンソールでは、画面に、新規に受信したデータの他、まだアプリに取り込んでいない過去に受信したデータや送信したデータが一覧で表示される。 具体的には、送受信日時、顧問先名、データ名称、ファイルの種類を示すアイコン、データの簡易チェックでエラーした際のエラーアイコン、データの進捗状況、などを少なくとも１つを含むデータに関する情報を、サーバー装置２（図２−１）から取得して一覧表示される。

サーバー装置２（図２−１）から様々な情報を取得する際に、会計事務所端末３（図２−１）からサーバー装置２（図２−１）に対し要求をするが、サーバー装置２（図２−１）が、その情報を取り扱える作業者なのかを、会計事務所端末３（図２−１）の名前情報や会計事務所端末３（図２−１）にログインしたユーザー情報から判断して、取り扱える権限を持つ作業者（の会計事務所端末３（図２−１））にのみ、データの要求に応じて様々な情報を会計事務所端末３（図２−１）に送信する（アクセス権を与える）セキュリティ管理機能を、本発明に入れるか、別のシステムで用意するかして、様々な情報を、複雑なセキュリティ設定を行うことなく運用でき、機密保持も万全に利用できるようにしてもよい。

また、上記セキュリティ管理機能のアクセス権において、作業員毎ではなく、複数の作業員を１グループとして、そのグループに対してアクセス権を与えたり、使用する会計事務所端末３（図２−１）に対して（会計事務所端末３（図２−１）にログイン出来るユーザーに対して）アクセス権を与えたりしてもよい。 なお、新たにグループへ追加された作業員も同グループのアクセス権を引き継げるようにしてもよい。

データに関する情報には、その他に、顧問先の管理番号、顧問先の決算年月日、顧問先内の担当者、会計事務所内の担当者、顧問先の業種など、もあってもよい。
エラーアイコンの表示は、エラーの重症度、緊急対応度などにより、色分けや点滅などのアニメーションで視覚的効果を付してもよい。
なお、ファイルの種類を示すアイコンや、データの簡易チェックでエラーした際のエラーアイコンのアイコンは、作業員への通知手段の一例とした記載したものであり、アイコンに限定するものではなく、ポップアップ通知やエラー音通知、音声通知などの通知であってもよい。

なお、この一覧表示は、条件を付することができる。例えば、管理コンソール内にプルダウンメニューを用意し、そのプルダウンメニューで一覧表示の条件を選択することで、条件に合致したデータのみを、すぐに表示できる。また、表示設定ボタン、およびその表示設定ボタンを押下することで別途表示される表示設定画面を用意して、一覧表示の詳細条件（商号コードの指定、対象期間、受信データのみ、送信データのみ、組込み済みデータを含めた全送受信データなど）を指定したり、データに関する情報の要素を取捨選択したりして、表示する情報を細かく設定することができる。

管理コンソールでは、一覧表示されたデータの１つを選択して、そのデータの詳細情報を表示すると共に、そのデータを受信した後の作業を行う為の操作ボタンを用意する。具体的には、受信したデータを編集するための操作ボタンを１つ、受信したデータを取り込むための操作ボタンを１つ、受信したデータが簡易チェックでエラーした場合は、そのデータに適したチェック用アプリを１ないし複数起動させるための操作ボタンを１つ用意する。

従来、作業員は、受信データに対して、そのデータに適した編集用アプリ、チェック用アプリ、取り込み用アプリを、複数の業務アプリから選択して起動していたが、本発明では、選択する手間を省くため、１つのボタン操作で作業に適したアプリを選択することができるように改良した。

図２−２は、財務、税務業務を一体処理する統合メニューの機能を説明する図である。
本発明で、１つのボタンで作業を開始すると、その先の取り込みから監査、帳表作成、決算・申告処理、電子申告まで、会計事務所における一連の実務を、財務・税務のデータ連携や連動により、財務と税務の一体処理を可能とする。関連するアプリないしシステムを自由に行き来できることで、突き付けが必要なデータの参照・確認なども手際よく行え、会計事務所の実務を総合的に効率することができる。

その他、データの詳細情報を表示する際に、別の管理システムへ切り替えるための操作ボタンを用意してもよい。具体的には、本発明である会計処理システムは、データを一元管理するシステムであるため、複数の顧問先のデータを一元的に表示できる一方、顧問先毎の管理においては、情報が多いことから、顧問先毎に管理できるシステムを使用した方が便利な時もあり、そのシステムへの切り替えをスムーズに行うために、プルダウンメニューで複数ある会計処理システムを選択した後、１つの操作ボタンを押下することで、管理システムの切り替えを行う。

会計処理システムを切り替える方法として記載したプルダウンメニューは、プルダウンメニューに限定するものではなく、スワイプ等のジェスチャー操作やキーボードのファンクションキーの割り当てによる入力、音声入力などでもよいし、その記載に限定されるものではない。

（実施例２）
以下に実施例２を記載するが、この実施例２によって本発明は限定されるものではない。
（１） データを送る方（顧問先）で、データの種類を指定して送ることで、データを取り込む方（会計事務所）で取り込みの機能や種類等を指定しなくてすむようにしてもよい。
従来は送る方しか知らない情報を、メール本文や口頭などで伝達し、その情報を元に事務所の担当が処理システムを選択していた。例えば、顧問先が「Ａ銀行」の「入出金CSV」と指定してデータを会計事務所へ送信することで、会計事務所側はその受信したデータを選び、作業を開始すると、起動Ａ銀行の取込設定がされた状態で銀行明細取込アプリが起動できる。口座名義もあれば科目や補助も決定ができる。同様に、同じCSVでも、「Ａ社」の「仕訳CSV」と指定して送信した場合は、他社会計データ取込アプリをＡ社の設定でアプリが起動でき、「資産データの一覧」と指定して送信した場合は、減価償却システムが起動（取込）できる。

（２）イベントログ情報を元に、顧問先毎にデータ状況を表示・管理してもよい。
例えば、顧問先単位の情報として、データが来ている状況や、会計データにエラーがある状況、電子申告データを作成済みの状況などを表示させることで、顧問先のデータ管理を容易にすることができる。

（３）会計事務所で今まさに処理しようとしている機能と、データの状況とを突きあわせ、現在のワークフローの段階において、重要となる情報を強調して表示、または絞って表示してもよい。
例えば、会計データを入力する時であれば、顧問先からのデータ受信の情報（値など）を会計データのエラー箇所より優先させて強調表示するようにしてもよい。
また例えば、個々の申告書データにエラーがある場合には、複数の申告書間に対するエラーチェックの結果表示はまだ省略し、それぞれの申告書に対するエラーのみを表示するようにしてもよい。
また例えば、電子申告データを作成しようとした場合には、各種エラー結果を強調表示するようにしてもよい。

（４）データ状況の変更をきっかけに各種処理を自動実行してもよい。
例えば、顧問先からの受信データがなくなったら（全ての受信データを会計データＤＢに取り込みができたら）、会計データの自動チェックするようにしてもよい。
また例えば、電子申告をするための申告書の全てのデータにエラーがなくなったら、電子申告用のデータを自動作成するようにしてもよいし、顧問先へ署名を頂くための連絡をするように促すようにしてもよい。

（実施例３）
以下に実施例３を記載するが、この実施例３によって本発明は限定されるものではない。

［全体構成］
図１−１は、本実施形態に係る会計処理全体のシステム構成を示す図である。
図１−１に示すシステム構成は、会計事務所の会計事務所端末（端末装置２１）と、複数の顧問先の顧問先端末（端末装置１０）と、会計事務所と顧問先の間で行われるデータのやり取りで中継されるサーバー装置２０がネットワーク（３００、３０１）で接続されたネットワークシステム例である。

サーバー装置２０（図１−１）は、サーバー装置２０の機能を統合した端末装置（端末装置２１（図１−１）と同じハードウェア）に置き換えてもよいし、別途用意された装置上に仮想化されたサーバーでもよいし、サーバー装置２０を経由せずに顧問先の端末装置１０（図１−１）から直接、会計事務所のサーバー装置２０の機能を統合した端末装置２１（図１−１）に接続されたネットワークシステムでもよい。
サーバー装置２０の台数において、図１−１ではサーバー装置２０として１台ずつで示しているが、複数台であってもよい。
サーバー装置２０の設置場所は、会計事務所内に設置することに限らず、複数台を１ヶ所に設置せずに各地に点在させてもよいし、業務委託等のサービスを行っている企業内に存在してもよいし、クラウドサービスのようにデータセンターに存在してもよく、この記載に限定されるものではない。
端末装置（１０，２１）は、デスクトップ型ＰＣやノート型ＰＣに限らず、スマートフォンやタブレット等の携帯端末でもよいし、実体が仮想化された仮想マシンでもよい。
端末装置（１０，２１）の台数において、図１−１では顧問先の端末装置１０および会計事務所の端末装置２１をそれぞれ１台ずつで示しているが、それぞれに複数台であってもよい。
端末装置（１０，２１）の設置位置において、必ずしも顧問先内や会計事務所内に設けられる必要はなく、外出先や自宅勤務の職員の端末装置、外注先の職員の端末装置でもよく、端末装置が存在する場所を含め、この記載に限定されるものではない。
また、図１−１では、顧問先−会計事務所間のシステムとして示しているが、企業の本社等が各支部や各支店、各支社（の従業員）等を対象に財務管理を行う場合には、支社等−本社間のシステムとしてもよい。

［システム構成：データの流れ］
図１−２は、本実施形態に係る会計処理システムのデータの流れを示す図であり、本発明は、このデータの流れをスムーズに処理できるように、顧問先と会計事務所との関係強化、および業務負担の軽減、そして会計事務所におけるワークフローの確立を支援、実現するシステム（装置）である。
図１−２に示すシステム構成上のデータの流れは、顧問先１００は会計事務所２００に対して、他社データＣＳＶ１５２（他社アプリで作成された汎用データでTEXT形式やXML形式、CSV形式など）や領収書等１５３、通帳／カード明細１５４、銀行カード／クレジットカード１５５、顧問先による記帳データ１５７、その他１５６の様々な種類のデータを様々な顧問先アプリケーション１５０からあらゆる情報の受け渡し方法で、インターネット３００（通信回線）を介して送信（３５０）する。会計事務所では、データ受領の統一された会計事務所の入り口である会計事務所アプリケーション２５０によって受信し、端末２５１によってデータが取り込まれ２５２、財務システムなどのデータチェック機能の活用２５６をしながら、監査２５３、財務帳表作成２５４を行い、関連資料を自動収集して電子申告２５５をしたり、様々な形式の資料（決算報告書や帳表等）を一つの操作で出力・一括印刷（出力指示の統一）したり、顧問先１００（または端末１５１）へメールや転送ツールなどで帳表を提出し（２５７、３５１、３５２）、顧問先１００で仕訳や元帳の表示１５８をして正しい帳簿の参照確認をするなどの一連の業務の流れを記したものである。 この会計事務所内のデータの流れは、本発明である会計処理システム（図１−２の２００の中の統合メニューの機能（ポータルサイト））の支援によって、シームレスな一筆書きのワークフローを実現する。
なお、顧問先１００と会計事務所２００との間のデータのやり取りおいて、インターネットを介す方法以外に、ＵＳＢメモリ等のメディアによるやり取りや、顧問先の端末１５１と会計事務所の端末２５１とが無線や有線などで直接接続して行うデータのやり取り、請求書やレシート等の紙媒体で受理するやり取りなどもあるが、この記載に限定されるのもではない。

そこで実施例の詳細を説明する前に、
アプリ毎にアプリ起動時にデータの有無を確認し、取込処理を実行するものであったものを、
本発明の実施例のポイントとして、
図５−２の表示画面において、
１．アプリ起動しなくてもデータの有無を図５−２で確認可能となり、データの状態（金額相違や未決定勘定科目データチェックやバランスチェックや入力漏れ等の各種チェック結果、エラー状態
や図５−１で確認できる、顧問先からのデータ受信、監査依頼や監査状況）等の情報（通知）を表示（データを選択した場合は連動して該当アプリを起動）、
２．選択したデータや重要度を加味して、必要な情報が把握しやすいような表示
３．図５−２において、アプリ起動前にデータの状態を確認してデータの取り込み、データのエラーの確認、再チェックやエラー内容（読み取れない画像データがある等）の確認や通知等を行う
４．図５−２において、通知履歴の管理（履歴の一覧表示等）
５．図５−１において、対象データと関連するデータ（財務と税務と画像）の対応関係をわかりやすく表示（電子申告システムや法人申告統合システム等）
６．図５−２において、ユーザーが行ったオペレーション（ジョブ記録）と顧問先からの受信データとチェック結果を関連付けたデータ管理
７．図５−１、図５−２において、対象データと関連するデータを資料の用途に応じた一括管理及び出力（印刷、電子帳表、データ出力、顧問先へデータ送信）設定
８．受信した画像データを仕訳データに変換
９．図２−２において対象データと電子申告に関する情報（処理年、納税先、署名や納税者等）を関連付けて一括管理
１０．対象データと使用アプリを管理（ロックして他のアプリからは編集不可）
することが可能になる。

[顧問先端末、会計事務所端末、サーバー装置のハードウェア構成]
図２−１は、本実施形態に係る装置の機能を示すブロック図である。
図２−１に示す顧問先端末１、サーバー装置２、会計事務所端末３は、コンピューターシステムの制御部（１０２，２０２，４０２）、入力部（１０４、２０４、４０４）、出力部（１０６、２０６、４０６）、記憶部（１０３，２０３，４０３）、画像取込部（１０５、２０５、４０５）から構成され、本実施形態に係る顧問先と会計事務所のデータ等の処理を、通信部（１０７，２０７，４０７）を通してやり取りを行うためのブロック図例である。
なお、サーバー装置２と会計事務所端末３とを統合した装置と顧問先端末１とが直接接続される構成であってもよい。

[顧問先]
図２−１の１０１は顧問先を示す。
顧問先端末１では、証憑データを処理するためや、記帳入力（帳簿入力）を行うため、決算するためなどの会計データが、様々なアプリを利用して様々なデータ形式で生成され、データ記録部１１１に記録されると共に、管理番号の会計データＩＤを生成し、会計データに関するイベントログ情報（例えば、データ形式やデータ状況（例えば、会計事務所送信前など）、顧問先名、顧問先担当者名など）と、アプリケーション情報管理記録部１１２に記録されているアプリケーション情報テーブル（図３−１）から取得した会計データを生成したアプリに関する情報（例えば、アプリ名、バージョン、リリース日など）を、会計データＩＤ（図示せず）に紐付けてイベントログ記録部１１３のイベントログテーブル（図３−２）へ記録する。
なお、アプリケーション情報管理記録部１１２に記録されているアプリケーション情報テーブル（図３−１）は、アプリのインストール時、バージョンアップ時、アンインストール時などのイベントや、手動要求／遠隔操作要求／曜日指定等による定期的な要求などのアプリ情報を意図的に記録するための要求（メンテナンスなどを考慮した要求）をきっかけに、管理番号のアプリＩＤ（図示せず）を基準としたテーブルへ、アプリ名、アプリバージョン、ファイル拡張子、データ形式、ファイル名に含まれる識別文字列、リリース日（図示せず）、ベンダ名（図示せず）、インストール日（図示せず）、バージョンアップ日（図示せず）などの情報が記録される。
顧問先が会計事務所へデータを送信する際、顧問先端末１（図２−１）は、データ送受信部１１０によって、データ記録部１１１から会計データを取得すると共に、イベントログ記録部１１３から会計データに付随する会計データＩＤを検索キーとして、直近のイベントログ情報（会計データ生成時のアプリ情報を含む）を取得し、それらを合わせて、通信部１０７へ引き渡し、会計事務所へ送信する。
このイベントログ情報を合わせて送信することにより、従来、会計事務所の作業者が、顧問先から受信した会計データを処理する前に行っていた、顧問先とのメールや電話（口頭）などで会計データに関する情報を入手する作業が不要となり、かつ本システムで会計データの処理の開始をスムーズに支援することができるようになる。 さらには、会計データに対するチェックや取り込みの作業を自動化することも可能となる。
イベントログテーブル（図３−２）のうち、直近のイベントログ情報と送信する考えは、イベントログを記録し続けると、イベントログテーブルのデータサイズが大きくなってしまうため、送信データも肥大化することを考慮したもので、具体的には、例えば、会計データＩＤで検索した結果に対し、さらに送信する会計データの更新日時とイベントログテーブルの日時情報とを照合して、合致した情報のみを、イベントログ情報としてデータと一緒に送信する手法もある。
このイベントログは、図５−２の５２７の履歴で確認できる。
会計データのイベントログ情報を使わずに、例えば、顧問先が会計事務所に対してデータを送信する際に、顧問先アプリケーション（図１−２の１５０）上で、「Ａ銀行」の「入出金」の「ＣＳＶ（ファイル）」と指定して送信する方法でもよい。 その方法によって、会計事務所側でデータを受信した際に、受信した会計データを選ぶだけで、Ａ銀行の取込設定が自動選択され、銀行明細データの取り込みがスムーズに実行でき、さらに口座名義情報を含めて、科目や補助も自動で判断し、自動入力することも可能となる。
また、同じ「ＣＳＶ」のデータ形式でも、Ａ社製の会計データ入力アプリで作成された会計データであれば、会計事務所側で会計データの取り込みを自動でＡ社の設定で実行することも可能となる。
その他、同じ「ＣＳＶ」のデータ形式でも、資産データ入力アプリで作成された会計データであれば、会計事務所側で減価償却アプリへの自動取り込みなどをすることも可能となる。

[会計事務所]
図２−１の２０１ないし４０１は、会計事務所を示す。
顧問先端末１から会計事務所へ、サーバー装置２が、通信部２０７を介してデータ送受信部２１０でデータを受信する。
なお、サーバー装置２の制御部２０２および記憶部２０３の機能を、会計事務所端末３に統合させることで、サーバー装置２を利用せずに、会計事務所端末３が直接、顧問先端末１から送信されたデータを受信することも可能である。 以降の説明ではサーバー装置２を用いた説明をするが、前述と同様に、サーバー装置２の機能を会計事務所端末３に持たせ、サーバー装置２を介さない構成としてもよい。

受信したデータ内の会計データは、今まで受信した会計データの追番（管理番号）である会計データＩＤとともに記憶部（図２−１の２０３）のデータ記録部２１６へ、受信したデータ内のイベントログ情報（会計データのアプリ情報を含む）は、会計データＩＤと紐付けて記憶部（図２−１の２０３）のイベントログ記録部２１８のイベントログテーブル（図３−２）へ記録される。さらに、イベントログ情報として、受信日時、受信したこと、受信データの名称、受信データの保存先、受信データの数、受信データ形式、どんなデータ（決算書作成依頼や監査依頼など）を受信したか、何のために送信されたのか、相手先情報（商号コードや担当者等）、会計事務所の作業員に受信したことを知らせる通知を出したか等の履歴も記録される。

そして、データ受信認識部２１１（図２−１）が、会計データを受信したことを認識すると、データ受信通知部２１５が、通信部（２０７、４０７）を介して、会計事務所端末３に会計データを受信した旨の通知を行い、会計事務所端末３では、データ新着表示部４１０が出力部４０６の画面やスピーカー（図示せず）等で、作業員へ迅速に会計データを受信したことを通知する。

データが受信されたことを認識した作業員（会計事務所）は、会計事務所端末３（図２−１）より、本システムの統合画面（詳細表示）（図５−２）を起動させて、受信した会計データの確認や次の作業などを行う。
本システムである統合画面（詳細表示）（図５−２の５２０）には、新着の会計データと既に受信済みの会計データの両方に対して、表示条件に合致した会計データとその会計データに関する様々な情報とを合わせて、受信データ一括表示部４１１（図２−１）が出力部４０６（画面）（図２−１）に表示する（図５−２の５２６）。 その他、データアイコン表示部４１５（図２−１）よりアイコンでデータ形式（データの種類）や状況の情報（図５−２の５２６）、データ状況表示部４１４（図２−１）より会計データの状況（ファイル）の情報（図５−２の５２３）、会計データを受信した時などをきっかけに動作するデータ異常判断部２１２（図２−１）より会計データに異常があった場合に、異常データ確認開始ボタン表示部４１７（図２−１）次の操作（作業）のボタン（エラー通知５２４）、データ編集ボタン表示部４２０（図２−１）とデータ編集部４２１（図２−１）より、データを編集するためのアプリを起動するボタン（処理５２５）、取込開始ボタン表示部４１８（図２−１）とデータ取り込み部４１９（図２−１）よりデータを会計データＤＢ（図２−１に図示せず）への取り込みを操作するボタン（データ取込５２８）という、情報の表示と次の操作を開始する手段の提供をする。 さらに、会計データのファイル種類５２１、会計データの顧問先情報５２２、受信データなどの履歴を見るための手段（履歴（ボタン）５２７）を、統合画面（詳細表示）５２０で提供する。
この統合画面（詳細表示）５２０の画面操作を終了するためのキャンセル（ボタン）５２９もあり、押下されると、次に統合画面（データ一覧表示）（図５−１の５１０）が表示される。

統合画面（データ一覧表示）５１０内には、データ異常判断部２１２（図２−１）より会計データに異常があったと判断されたデータに対する通知（視覚効果）や、データ重要度表示部４１３（図２−１）より会計データがどれだけ重要なものであるかの通知（視覚効果）を、受信データ一括表示部（図５−１の５１４）で表示する。 また、メイン画面選択４１６（図２−１）より本システムと連動した様々なシステムへの切替選択手段（図５−１や図５−２に図示せず）を提供する。 統合画面（データ一覧表示）５１０には、その他の表示、操作ボタンがあるが、後で説明する。
以上、ブロック図（図２−１）のブロックにより、上述した統合画面（５１０、５２０）で受信した会計データに対する状況・情報を容易に把握でき、そして次の作業へのスムーズな開始を支援するための操作が提供できる。

図２−２は、受信した会計データ（決算データ）に対して、申告書類を作成する（電子申告５０７）までのアプローチの業務概要を示す。
具体的には、財務アプリまたはシステム（財務５０１）や税務アプリまたはシステム（税務５０２）を必要に応じて切り替えながら、資料作成（監査／帳表作成５０３、申告書作成５０４）やチェックを行い、電子申告に必要な資料を、財務５０１および税務５０２のそれぞれから収集（データ収集（５０５、５０６））し、電子申告形式データ作成５０８を行い、電子申告５１７を行う流れである。
本システムでは、財務５０１と税務５０２を自由に行き来できているかのように切り替えをスムーズに行えるような操作性を提供し、また、財務５０１においては、顧問先データの活用によりデータ入力なしに監査／帳表作成およびデータ収集ができ、税務５０２においては、関連データの連動で速やかに申告書作成およびデータ収集ができ、最終的に電子申告を手際よく申請することができることから、一連の処理を効率よく実行５００できる。 このような本システムの支援によって、会計事務所が顧問先に対して、新サービスを創出したり、顧客開拓に投資したりできるような余力の創出５０９ができること（効果）を、図２−２で概要的に示す。

図３−１は、アプリケーション情報テーブルであり、アプリケーション情報管理記録部（１１２、２１７）（図２−１）に記録される。 前述の通り、会計データを生成した時に、どのアプリで生成したかなどの情報を記録するためのテーブルであり、顧問先−会計事務所間で会計データをやり取りする際に付加し、相互の連携を潤滑にする。 具体的には、アプリ毎に管理番号であるアプリＩＤ（図示せず）を割り振り、アプリＩＤをキーとして、アプリ名、アプリVer、ファイル拡張子、データ形式、ファイル名に含まれる識別文字列、自端末への対応、非対応理由、非対応時の通知、商号コード（顧問先を特定するための情報）などの項目が記録される。 なお、項目「データ形式」については、アプリケーション情報テーブル（図３−１）の他、後述するイベントログテーブル（図３−２）と業務進行テーブル（図３−３）にも共通する項目である。 この項目「データ形式」は、データをどのアプリで編集・チェック・取り込みをするかを判断するための要素の一つであり、項目の値として、アプリ特有のファイル拡張子や該当アプリ名などが記録される。

図３−２は、イベントログテーブルであり、イベントログ記録部（１１３、２１８）（図２−１）に記録される。
イベントログとは、会計データに対して操作（オペレーション）を行った際に、イベントが発生した事項で、その操作履歴や結果、会計データに関する付加情報などを記録する。
例えば、データをいつ、だれが（顧問先担当者や会計事務所作業員）、どこで（顧問先名や会計事務所名）、どのアプリで、何をしたか（開いた、データ一部を保存した、追記した、一部を削除した、エラーチェックを実施してエラーを検出したなど）、更に人の手を介さずバックグラウンドで自動チェックした際にエラーを検出した結果など、データに対する変化や操作、結果などを記録したものである。
会計データに対する次の作業をシステムが支援したり、業務進捗を把握したり、いつ・誰が・どのように編集を行ったかなどの５Ｗ１Ｈに基づいた作業履歴を後から確認したりを可能にする。
具体的には、顧問先からのデータ受信時、顧問先へのデータ送信時、会計事務所内での受信データの取込時、「会計データ入力、次期繰越、会計ファイル編集、仕訳データ合併、残データ合併、業種区分変更、決算年月日変更、財務ファイル管理、公開データ管理、在宅入力の会計ファイル変換、OCR 連携システムなど」での会計ファイル登録時、期首残高のバランスエラー、月別開始残高のバランスエラー、科目未決定勘定の使用、諸口バランスエラーなどの各種エラーをチェックするための法人税申告書などの申告書作成アプリ終了時に行うチェック実行時、チェックリストに基づいた法人申告、減価償却、勘定科目内訳などのチェックアプリでの金額相違チェック実行時、電子申告、事業概況説明などの形式チェック実行時、アプリ終了時に、会計データや電子申告データ形式などの自動チェックが実行された時などに、イベントログテーブル（図３−２）に対して、いつ（年月日、時刻）、だれが（自社情報２＝作業員など）、どの端末で（自社情報１＝端末名）、だれの何のデータを（相手先情報１＝顧問先名、相手先情報２＝顧問先担当者名、データ名称、データ状況など）、どのアプリでまたはどのシステムで（データ形式）、結果などのどうしたか（イベント内容）などを記録する。
例えば、データを受信した際は、受信した会計データ毎に管理番号である会計データＩＤ（図示せず）を割り振り、会計データＩＤをキーとして、イベントが発生した年月日、時刻、イベント内容、追加情報１〜Ｎ（例えば、顧問先Ａや顧問先Ｃなどの顧問先情報や、チェッカー１ Ver.1.3などの使用アプリ情報、などの関連情報）、データ名称、データ保存先（例えば、絶対パスや相対パス、どのサーバーなど）、データ形式（例えば、会計データ、帳表、電子申告などのどのようなデータなのかを把握するための情報）、データ状況（例えば、新規受信（図示せず）、保存済み、送信済み、送信取消、編集中（図示せず）、未取込（図示せず）、修正依頼中（図示せず）などの会計データの進捗情報）、相手先情報１〜Ｎ（例えば、顧問先Ａや顧問先Ｃなどの顧問先情報、ＸさんやＹさんなどの顧問先担当者情報、顧問先が送信する際に付加したアプリ名やアプリバージョンなどのアプリ情報（図示せず）、などの送信元や受信データに関する情報）、自社情報１〜Ｎ（例えば、マシン１やマシン３などの作業ＰＣ情報、ＡさんやＣさんなどの作業者名、ＡグループやＣグループなどの作業グループ名（図示せず）、などの会計事務所内で会計データを取り扱う際に関連する情報）の項目が記録される。イベントログテーブル（図３−２）のデータ形式の値について、前述したアプリケーション情報テーブル（図３−１）と後述する業務進行テーブル（図３−３）の項目の値として記載されている内容とは異なるが、イベントログテーブル（図３−２）も含め、３つの図（テーブル）のデータ形式の記載内容は共通する。
なお、イベントログテーブルに記録される項目に関して、この記載に限定されるものではない。

図３−３は、業務進行テーブルであり、業務進行記録部２１９（図２−１）に記録される。 単純な操作で次の作業に移れるように支援するための情報であり、様々な業務におけるフローをまとめたテーブルである。
具体的には、業務の種類毎に管理番号である業務フローＩＤを割り振り、業務フローＩＤをキーとして、データ形式、ステップ１〜Ｎ（例えば、依頼受信、データ確認、データ取込、帳表作成・監査、申告書作成、電子申告所準備、提出、などの項目が記録される。 業務進行テーブル（図３−３）のデータ形式の値について、前述したアプリケーション情報テーブル（図３−１）とイベントログテーブル（図３−２）の項目の値として記載されている内容とは異なるが、業務進行テーブル（図３−３）も含め、３つの図（テーブル）のデータ形式の記載内容は共通する。 業務進行テーブル（図３−３）のステップ１〜Ｎの値について、前述したイベントログテーブル（図３−２）のデータ状況の値と共通する。

図５−１（統合画面（データ一覧表示））、図５−２（統合画面（詳細表示））は、実際の操作画面の表示例であるが、その記載に限定されるものではない。
図６は、本システムのフローチャートである。 会計事務所が顧問先からデータを受信してからの具体的な作業の流れに沿って、図６（Ｓ６−１の開始から）、図５−１、図５−２について、より詳細に説明する。

［サーバー装置］
顧問先端末１（図２−１）から会計事務所に送信されたデータは、サーバー装置２（図２−１）が会計事務所アプリケーション（図１−２の２５０）で受信する（図６のＳ６−２）。
会計事務所が受信するデータは、例えば、電子化されたレシートデータ、通帳データ、入出金明細データ、記帳データ、監査データ、会計データ（密な連動可能）、会計データ（連動が可能または連動できない他社データ）などがあげられるあるが、これらの記載に限定されるものではない。
顧問先から会計事務所へ送信されるデータは、顧問先毎に種類、形式などが異なる。 本システムに連動する顧問先アプリケーション（図１−２の１５０）を使用せず、汎用性を持ったメーラーや、送信するデータの専用アプリによるデータ送受信機能等で送信することもある。 その場合、会計事務所側では、顧問先と同一または互換性を持つアプリでデータを受信する必要があるが、本システムである会計事務所アプリ（図１−２の２５０）では、顧問先と同一または互換性を持つアプリと連動し、会計事務所アプリ（図１−２の２５０）が受信する。
なお、サーバー装置２（図２−１）と会計事務所端末３とを統合してもよく、その装置が顧問先端末１からデータを受信してもよい。

サーバー装置２（図２−１）が受信したデータは、受信した順に管理番号の会計データIDが割り振られ、一括管理され（図６のS６−３）、記憶部２０３（図２−１）のデータ記録部２１６やイベントログ記録部２１８などへ記録される（図６のS６−４）。

ここで、顧問先からデータを受信したことを、会計事務所の職員（先生や作業員）に対し、使用端末装置（会計事務所端末３）に対し、いつ、どの顧問先から、何のデータが届いたか等の簡易情報を、即時通知してもよい（図６に図示せず）。 なお、通知方法は、ポップアップやトースト通知等で画面にしたり、音や音声で通知したり、通信機能を使って別のモバイルデバイスへメール等で通知するなどの方法があるが、これに限らない。

また、受信したデータのアプリ名やデータ形式などの情報を元に、自動でデータの分析、チェックをしてもよい（図６のS６−５）。
具体的には、データの分析として、データの種類（分類）は何か（電子化されたレシートデータ、通帳データ、入出金明細データ、記帳データ、監査データ、会計データ（密な連動可能）、会計データ（連動が可能または連動できない他社データなど））、会計データの状態（作業内容）（新規受信、修正依頼中など）、重要度（優先度）の割り振り（詳細は後述）などを認識して、その分析結果をイベントログテーブルに記録（図６のＳ６−４）してもよいし、さらにそれらの情報を履歴（図５−２の５２７）で確認できるようにしてもよい。
また、データのチェックとして、受信したデータのデータ形式に適した１以上のデータチェック専用アプリを、作業員の操作なしで自動実行し、データが正常に読めるか、データをアプリに取り込む際に不足している情報や不備がないか、データ内の値に整合性が取れていない部分があるか（例えば、取引の税率が適切に軽減税率となっているかなどの会計処理の観点を含む）、取り込み済みのデータと重複していないか、ＡＩなどによる解析で、過去の摘要の傾向から軽減税率適用の可能性がある取引に対して、標準税率しか入力されていないかなどの適用税率のチェックなどの異常がないかなどを、自動チェックして、もしデータに異常があった場合は軽度エラーや重度エラー等のエラー情報を含め、チェック結果をイベントログテーブルに記録（図６のＳ６−４）してもよいし、さらにそれらの情報を履歴（図５−２の５２７）で確認できるようにしてもよい。なお、データ内の値に整合性が取れていない部分があるかなどの判定手法に関しては、様々な手法があるが、本発明の本質とは異なるため、詳細な説明は省略する。
また、データを取り扱うことができるかどうかのチェックとして、データを受信した際に、データ送受信部（図２−１の２１０）で分別したアプリ情報（データ生成時のアプリ名、アプリバージョンなど）をアプリケーション情報管理記録部（図２−１の２１７）に記録するが、そのアプリ情報と、会計事務所側のアプリ情報（取り扱うことができるシステム／アプリ）（記録先、記録部は図示せず）とをデータ異常判断部（図２−１の２１２）で比較してもよい。さらにデータ異常判断部２１２は、その結果をアプリケーション情報テーブル（図３−１）ないしイベントログテーブル（図３−２）に記録し、会計事務所側にアプリが存在しない場合（アプリ非互換）や、アプリは存在するが受信データ生成時のアプリバージョンの方が会計事務所側よりも新しい場合（旧バージョン）など、会計事務所側でデータを取り扱うことができない場合（非対応の場合）に、エラーとしてイベントログ記録部（図２−１の２１８）のイベントログテーブル（図３−２）へ、自端末への対応として「非対応」、非対応理由として例えば「旧バージョン」などと記録すると共に、会計事務所端末３（図２−１の４０１）へ通信部（図２−１の２０７、４０７）を介して通知し、データ異常表示部（図２−１の４１２）より、会計事務所の作業員などに対して警告表示してもよい。
なお、データ受信時に自動でデータの分析やチェックをする場合は、機械的な判断となるため、どうしても単純なデータ分析、チェックしかできない。 しかし、自動分析・チェックでエラーを検出した場合に、即時、別手法で画面にエラー通知し、作業員がすぐに気付き、顧問先へ問い合わせるなどの迅速な対応ができるようにしてもよい。

会計事務所の職員（先生や作業員）は、データ受信通知を受け（または知らずとも通常業務として）、本発明である会計処理システム（ポータルサイト）を手動で起動し、統合画面（詳細表示）（図５−２の５２０）が表示される（図６のＳ６−７およびＳ６−６）。
この統合画面（詳細表示）５２０には、受信したデータの、業務フロー上のどこまで進んでいるかなどの情報を含むイベントログ情報を元に、まだ会計データＤＢに取り込んでいない受信したデータのファイル名、受信日時などを一覧表示５２６する他、一覧表示されたデータを選択することでそのデータの顧問先情報５２２（例えば、商号コード、商号名、決算年月日、顧問先会社の担当者名、住所、どのような案件なのか、最初にデータを受信した日付などの情報）、ファイルの種類５２１（データ形式）、ファイルの状況５２３、次の作業を支援するための操作ボタンである処理５２５（作業関連の操作ボタン）、データ取込５２８（作業関連の操作ボタン）、エラー通知５２４（作業関連の操作ボタン）、一覧表示されたデータに関する履歴を表示するための履歴５２７（操作ボタン）、総合画面（詳細表示）５２０を終了させるためのキャンセル５２９（操作ボタン）を表示する（図６のＳ６−７およびＳ６−６）。また、エラーチェック等でエラーを検出したデータや期限間近なデータなど、注意すべきデータが存在する場合は、警告の表示を表示する（図示せず）。以上より、注目させたい会計データＤＢなどのデータ一覧や状況などの情報と、次の作業の入り口を集約した操作ボタンを１つの画面（図６のＳ６−７およびＳ６−６）で提供し、円滑な業務進行を支援する。
商号名は顧問先の企業名であり、商号コードは、会計事務所が顧問先を管理するために任意につける管理番号である。

なお、顧問先情報５２２の表示に関しては、本会計処理システムと連携している顧客管理システムなどから情報を取得して、より詳細な顧問先情報を表示してもよい。

この画面の他に、注意すべきデータの認知性を向上させるために、警告表示があるデータのみを一括表示する画面を別に用意してもよい（図示せず）。 この時、会計データＤＢへ取り込んでいないという条件をなくして一括表示するようにしてもよい。

この統合画面（詳細表示）５２０では、何通りもあるデータ処理の作業を、３つの作業（チェック 、編集、取込）に分類分けし、それぞれの分類（作業）に対して、開始するための操作ボタンを、処理ボタン５２５、エラー通知ボタン５２４、データ取込ボタン５２８と、１つずつ用意している。 その操作ボタンを作業の入り口として、操作対象のデータに対して、顧問先が送信する際に付加したデータの種類や状況などのデータに関するイベントログ情報を元に、データ処理に最適な１ないし複数のアプリを自動選択して起動するため、複雑な業務フローの入り口が簡素化され、作業者の知識レベル、熟練度等に関係なく、スムーズな作業開始を支援することができる。
具体的には、一覧表示された受信データ５２６の内、１つのデータ（例えば、伝票１のデータ形式のデータ）を選択し、操作ボタン（処理５２５・エラー通知５２４・取込５２８）を押下すると、データ状況判断部２１３（図２−１）が、選択されたデータの会計データＩＤより、イベントログテーブル（図３−２）のデータ形式とデータ状況の情報を取得する。 取得した情報のうち、データ形式を業務進行テーブルのキーとして照合して、データの業務フローを特定し、その業務フロー内のステップとデータ状況とが合致したステップを検出する（例えば、業務フローＩＤ１のステップ４：帳表作成）。 そして、その次のステップに記載された値（例えば、申告書作成）をキーとして、アプリケーション情報テーブル（図３−１）に記録されている起動トリガ（項目）（図３−１に図示せず）と合致したアプリケーションを起動すると共に、イベントログテーブル（図３−２）に、会計データＩＤをキーとして、アプリの起動トリガとなったキー（この場合、申告書作成）をデータ状況に記録する。 このようにすることで、操作ボタンを押下する度に、そのデータの作業を行う上で適切なアプリが起動される。
処理ボタン５２５、エラー通知ボタン５２４、データ取込ボタン５２８に対応するアプリの一例として、会計データ入力アプリ、事業概況説明書アプリ、減価償却アプリ、勘定科目内訳書アプリ、法人税申告書アプリなどがあるが、これらの記載に限定されるものではない。

操作ボタンの動作の具体例を挙げると、処理ボタン５２５をクリックすると、そのデータの業務フローに適したアプリ（例えば会計データ入力）が起動し、確認および編集をおこない、アプリにデータを取り込こみ、再び処理ボタン５２５が表示された画面に戻り、同じ処理ボタン５２５をクリックすると、次の業務に進められるデータになっているため、そのデータの業務フローに適したアプリ（例えば法人税申告書）が起動し、編集するといった流れで作業が進む。
また別の例を挙げると、処理ボタン５２５をクリックすると、そのデータの業務フローに適した複数のアプリ（例えば会計データ入力と法人税申告書）が同時に起動し、突き合わせチェックができる流れで作業が進む。
また別の例を挙げると、エラーが検出された受信データの場合、エラー通知ボタン５２４をクリックすると、そのデータに適したチェックアプリ（例えば法人税申告チェック）が起動し、人目でチェックできる流れで作業が進む。
また別の例を挙げると、受信したデータに適したチェックアプリを起動するかどうかを決定するチェックボックスにチェックを入れた状態で、処理ボタン５２５をクリックすると、そのデータの業務フローに適したアプリ（例えば法人税申告書）とチェックアプリ（例えば法人税申告チェック）が同時に起動し、編集（修正）とチェックを並列処理して効率的に作業が進む。
また別の例を挙げると、受信したデータを、データ取込ボタン５２８で、直接取り込む流れでも作業が進む。

実際の作業の順番を一例で上げ、全体のフローチャート（図６）の説明に戻り、Ｓ６−８以降を説明するが、作業の順番はこの記載に限定されるものではない。

まずは、会計データＤＢへ取り込む前に、受信したデータに不備がないかチェックしていないので、チェック対象データを選択した後、作業員がエラー通知ボタン５２４を押下する。
操作受付のステップＳ６−８は、データチェック作業（アプリ起動）のステップＳ６−１１に移り、チェックするために適したチェック用アプリ（例えば、会計ファイルのチェック、法人申告チェック、電子申告形式チェック、法人税申告書のチェック）を１ないし複数起動させる。
従来は、データの種類やデータの状況によって、使用するチェック用アプリの種類が異なり、また複数のチェック用アプリを使用してチェックする場合などもあり、それらを自ら判断し、手動で起動していたが、本統合画面ではエラー通知ボタン５２４（１種類のみ）を押下するという単純操作だけで、チェック対象データに関する情報（例えば、現状のデータの状況（新着）とデータ形式（ＣＳＶ形式）など）を、会計データＩＤをキーとして、イベントログ記録部（図２−１の２１８）に記録されているイベントログテーブル（図３−２）より取得し、チェック対象データをチェックするために必要なアプリを起動させる。
作業員は、起動したアプリでチェック対象データのチェックを終えると、統合画面（詳細表示）５２０へ画面が戻り、再び操作受付のステップＳ６−８に戻る。

なお、エラー通知ボタン５２４は、別作業でデータチェックをして、エラーのまま処理を終えたデータが存在した場合に表示するようにしてもよいし、データを受信した際に、自動でデータチェックをするようにした場合、目視確認が必要なエラーがあるデータが存在した場合に表示するようにしてもよい。
エラー通知ボタン５２４を押下することで、エラーがあるデータのみを一覧表示し（図示せず）、その中から選択されたデータのエラーの詳細を確認することができたり（図示せず）、修正することができたりしてもよい。
エラーに関して、会計処理または税務処理に必要な項目に異常があるデータをエラーとするが、そのエラーの一例として、会計データ関連（会計データ入力）では、バランスエラー（期首残高）、バランスエラー（開始残高：ｘｘ月）、諸口のバランスエラー（ＸＸ月）、科目未決定勘定エラー（ＸＸ月）などがあり、事業概況説明書関連では、電子申告データ形式チェックのエラーなどがあり、減価償却関連では、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあり、勘定科目内訳書関連では、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあり、法人税申告書関連では、確認が必要な別表や項目エラー、未選択の帳表エラー、未入力の帳表エラー、法人申告チェックリストで金額不一致の項目エラー、電子申告データ形式チェックのエラーなどがあるが、これらの記載に限定されるものではない。

データをチェックした結果、データに修正する必要があることがわかった作業員は、編集対象データを選択した後、処理ボタン５２５を押下する。
操作受付のステップＳ６−８は、データ編集作業（アプリ起動）のステップＳ６−９に移り、記憶部２０３のイベントログ記録部２１８にある、データを受信した際に取得したイベントログ情報（顧問先、業務フローの進捗、依頼内容、データ（ファイル）の種類、データを受信した際の自動チェックなど）を元に、編集対象データを編集するために適したアプリ（例えば、会計データ入力アプリ、法人申告アプリ、電子申告アプリ、法人税申告書アプリ、表計算アプリ、その他各種エラーチェック用アプリなど）を１ないし複数起動させる。 複数のアプリを起動する場合とは、異なるアプリでの編集画面を突き合わせてチェックしながら入力すると効率がよい場合や、編集用アプリとチェック用アプリと並行しながら編集を進めると効率がよい場合をなどである。 前述したエラー通知ボタンと同様に、従来は煩雑な自己判断、手動アプリ起動を必要としていたが、編集対象データに関する情報をイベントログテーブルより取得することで、自動でデータ編集作業に必要なアプリを起動させる。
作業員は、起動したアプリで編集対象データの編集を終えると、統合画面（詳細表示）５２０へ画面が戻り、再び操作受付のステップＳ６−８に戻る。

データの修正を終え、エラーや不足のないデータとなったため、作業員は、会計データＤＢなどへデータを取り込むため、取込対象データを選択した後、データ取込ボタン５２８を押下する。
操作受付のステップＳ６−８は、データ取込作業（アプリ起動）のステップＳ６−１０に移り、取込対象データを会計データＤＢなどへ取り込むために適したアプリ（例えば、会計データ入力アプリ、法人申告アプリ、電子申告アプリ、法人税申告書アプリなど）を起動させる。 前述したエラー通知ボタンと同様に、従来は煩雑な自己判断、手動アプリ起動を必要としていたが、取込対象データに関する情報をイベントログテーブルより取得することで、自動でデータ取込作業に適したアプリを起動させる。取り込むデータの一例として、画像化と共にデータ化した伝票（レシート）や通帳、自計化した顧問先で入力された入出金明細データや記帳データ、監査依頼と監査依頼に必要な資料、他のベンダのアプリで生成された会計データなどがある。
作業員は、起動したアプリで取込対象データの取り込みを終えると、統合画面（詳細表示）５２０へ画面が戻り、再び操作受付のステップＳ６−８に戻る。

作業員は、必要に応じて、統合画面（詳細表示）５２０から、ボタンやプルダウンメニュー（図５−２に図示せず）などによって、別の管理ソフト（管理システム）を起動したり、または切り替えられたり（統合画面を終了させて起動したり）できるようにしてもよい。
これは、熟練した作業員が、更に効率を上げるために、別の管理ソフトを起動する際に用いられる。
具体的には、本発明である会計処理システムは、データを一元管理するシステムであるため、複数の顧問先のデータを一元的に表示できる一方、顧問先毎の管理においては、情報が多いことから、顧客情報管理システム（Client File Manager）などの顧問先毎に管理できるシステムを使用した方が便利な時もあり、そのようなシステムへの切り替えをスムーズに行うための支援機能を提供する。
関連する別の管理ソフトとして、例えば、財務システム、税務システム、法人申告システムなどがあり、それらを連動・連携させて、管理ソフトの切り替えを行う。 さらにその連動・連携を活用し、業務フローを段階的に進めていく中で、その都度必要な書類を一括印刷する機能や、１つのデータを編集することでその他の書面（例えば税務代理書面など）も反映される機能、申告する際に必要な資料を収集して申告（例えば電子申告）をする機能を連動させてもよい。
作業員は、管理ソフトを切り替えるか起動するかを選択（図５−２に図示せず）し、プルダウンメニューなどで管理ソフトを選択する。
操作受付のステップＳ６−８は、別管理ソフト（管理ソフト起動）のステップＳ６−１２に移り、プルダウンメニューなどで選択された別管理ソフトを起動する。 そして、管理ソフトを起動するだけ（統合画面（詳細表示）を終了しない場合）であれば、ステップＳ６−１３の「終了しない」に進み、再び操作受付のステップＳ６−８に戻る。 管理ソフトを切り替える場合（統合画面（詳細表示）を終了する場合）は、ステップＳ６−１３の「終了する」に進み、統合画面（詳細表示）を終了させる（Ｓ６−１４）。
なお、管理ソフトの切り替え方法は、前述したプルダウンメニューに限定するものではなく、スワイプ等のジェスチャー操作やキーボードのファンクションキーの割り当てによる入力、音声入力などでもよいし、その記載に限定されるものではない。
なお、本システムにおいて、データの取り込みからデータのチェック、財務帳表の作成、電子申告までの一連の作業をスムーズに進められるように、管理ソフト（統合システム（例えば法人申告統合システムなど））の関連するアプリなど（例えば電子申告、個人申告、相続税等など）の機能を、さらに連携・連動させるような形で追加・拡張することができる。 この連携させる手法は、様々な手法があるが、本発明の本質とは異なるため、詳細な説明は省略する。

その他、作業員が、統合画面（詳細表示）５２０を終了させたい場合、キャンセルボタン５２９を押下する。 操作受付のステップＳ６−８は、キャンセル（画面表示終了）のステップＳ６−１５に移り、統合画面（詳細表示）５２０を終了させる（Ｓ６−１４）。
統合画面（詳細表示）５２０を終了させると、統合画面（データ一覧表示）（図５−１の５１０）が表示されるようにしてもよい。

以上の実際の作業の中で、どのようなアプリケーションで、データをどのように処理し、どのようなエラーがあったか、データのチェック結果、取り込み、入力、修正、監査結果、資料作成、顧問先への連絡などの５Ｗ１Ｈなどの条件を含む作業履歴情報を、ジョブ実行記録として、本会計処理システムでは、イベントログ記録部２１８（図２−１）のイベントログテーブル（図３−２）へ記録している。 このように、イベントログテーブル（図３−２）に記録することで、例えば、顧問先データ、監査依頼、アプリ起動記録、アプリ起動中操作記録、データ受信、チェック結果、チェック結果の通知、データ確認画面、共通のデータ選択画面、各アプリ（会計、法人申告、電子申告形式、法人税申告書等）のチェックなどのジョブ実行履歴で、統合画面（詳細表示）（図５−２の５２０）で表示し切れなかった有効な情報や、さらに過去のデータの受信または送信の履歴を、履歴ボタン（図５−２の５２７）（図６には図示せず）で表示することができるが、別の画面に表示してもよい。
また、業務進行テーブル（図３−３）を参照することで、一連の業務フローにおいて、データに対してどこまで業務が進んだか、という進捗状況も把握することができる。

以上、実際の作業の順番の一例から分かる通り、本統合画面（詳細表示）５２０によって、日常作業の中で、作業員が、データ受信やデータエラーなどに素早く気が付き、、チェック漏れを減少させる支援ができ、かつデータの取り込みやエラー確認の作業を開始する際の操作を単純化・統一化することで、会計事務所の業務負担の軽減と、円滑なワークフローの確立を実現するための支援ができる。

統合画面（詳細表示）５２０では、まだ会計データＤＢに取り込んでいないデータが表示対象であったのに対し、統合画面（データ一覧表示）５１０では、会計データＤＢに取り込み済みのデータを含め、まだアプリに取り込んでいない過去に受信したデータや、顧問先へ送信（返信）したデータなどを一覧で表示する（５１４）。
統合画面（データ一覧表示）５１０では、条件１（５１２）、条件２（５１３）、表示条件５１５によって設定された各表示条件に合致したデータを、一括表示（５１４）しており、その表示中のデータの一つを選択した際にその会社名５１１を表示するとともに、その会計データの作業を開始するための確定ボタン５１８や、その会社名５１１のやり取り履歴を表示するための会社履歴ボタン５１７を表示する。その他、統合画面（データ一覧表示）５１０に対する様々な設定をするための設定ボタン５１６や統合画面（データ一覧表示）５１０を終了させるためのキャンセルボタン５１９も表示する。
なお、確定ボタン５１８や、会社履歴ボタン５１７は、一括表示（５１４）されたデータを選択しないと効果を奏しないため、データが選択されていない場合は、操作無効なグレーアウト表示にして、データが選択された場合に、操作有効な表示に変わるような表示にしてもよい。

会社名５１１は、顧問先名（会社名）を表示するが、その他、顧問先の管理番号、顧問先の決算年月日、顧問先内の担当者、会計事務所内の作業員、顧問先の業種などがあってもよい。それらの情報は、データのイベントログ（図３−２）に記録されていてもよいし、顧客管理システムなどの別のシステムに記録されていて、連携・連動させて、情報を取得するようにしてもよい。
条件１（５１２）、条件２（５１３）は、一覧表示５１４の表示条件を指定するプルダウンメニューであるが、ラジオボタンなどの入力方法でもよいし、この記載に限定されるものではない。 ここでは、表示条件を簡単に設定できるインターフェースで、素早く条件に合致したデータのみを、一覧表示することができる。
表示設定ボタン５１５は、押下することで表示設定画面が別表示され、一覧表示５１４の詳細条件（商号コードの指定、対象期間、受信データのみ、送信データのみ、組込み済みデータを含めた全送受信データ、記帳や監査等の依頼内容別など）を指定したり、データに関する情報の要素を取捨選択したりして、表示する情報を細かく設定することができる。また、データを一覧表示する上で、新着情報やデータの種類、受信したデータの状況に応じた重要度、受信したデータを業務フローに沿って処理した後の重要度、処理期限までの残り日数による処理優先度、エラーがあるデータなどを、文字の色や太さ、アイコンなどで区別したり、点滅などのアニメーションで視覚的効果を付したり、表示する情報を絞ったり（表示を省略したり）、折り畳み表示（例えば、バーが表示されているところをクリックすると内容が表示され、再度バーをクリックすると内容がバーに折りたたまれるような表示の仕方）をするなどして、必要な情報が把握しやすいように表示をすることもできる。
例えば、会計データを入力する場合には、顧問先からのデータ受信の方を会計データのエラーより優先させて表示させることや、個々の申告書データにエラーがある場合には、申告書間のエラーチェックの結果をまだ表示させない（まだ省略する）ことやか、電子申告データを作成する場合には、各種エラー結果を強調することで、重要度に応じた表示をしてもよい。
なお、アイコン（新着情報アイコン、データ形式（種類）別アイコン、重要度別アイコン、処理優先度別アイコン、エラーアイコンなど）に操作ボタンの機能を付して、押下することで図５−２の処理ボタン５２５、エラー通知ボタン５２４、データ取込ボタン５２８と同様の動作となるようにしてもよいし、その他の操作となるように動作してもよい。なお、この記載に限定されるものではない。

この重要度は、データ記録部２１６に記録されている重要度設定テーブル（図示せず）によって定めており、データに紐づけられたイベントログテーブル（図３−２）に記録されている値（例えば、イベント内容、追加情報１、追加情報２、データ形式、自社情報２の値）に対して、それぞれに重要度の指数を割り振っている。 このデータ毎に割り振られる重要度の指数化は、データ重要度判定部２１４（図２−１）によって、データに対する操作が行われてイベントログテーブル（図３−２）に記録される際に都度実行される。
例えば、イベント内容の例えば、データ受信に３、帳表作成アプリ起動に１、帳表作成アプリ終了に２、簡易チェックに１、簡易チェックエラー検出に５など）、追加情報１の例えば、データの所有先を特定する情報に関する顧問先Ａに１０、顧問先Ｂに５など）、追加情報２の例えば、データの自身の異常状況に関する情報である受信ＯＫに１、受信ＮＧに１０、軽度エラーに１５、重度エラーに２０、正常終了に１、異常終了に３０など）、データ形式の例えば、会計データに１０、帳表に５、電子申告に２０、ＰＤＦに１、ＣＳＶ（他ベンダ）に３、ＣＳＶ（銀行明細）に２など）、自社情報２の例えば、作業員名であるＡさんに５、Ｂさんに２など）、と指数を割り振る。更に項目に対する重要度レベルを、例えば、イベント内容に５、追加情報１に３、追加情報２に１０、データ形式に１、追加情報２に１と割り振る。そして、最終的にデータの重要度の数値化を、例えば、データに関するすべての数値をイベント内容がデータ受信で５×３、追加情報１が顧問先Ａで３×１０、追加情報２が受信ＯＫで１×１０、データ形式が会計データで１×１０、自社情報２がＢさんで１×２とすると、そしてそれら重要度の指数は、その数値の合計、５×３＋３×１０＋１×１０＋１×１０＋１×２＝６７となる。この算出された重要度指数を元に、その他のデータと比較し、重要度の順番を決めていく。この重要度指数は、会計データＤＢへ記録してもよい。この重要度の数値化する手法や重要度の比較手法などは、その記載に限定されるものではない。

処理優先度は、会計データ（会計データＩＤ）に対して、顧問先から処理期限の要求がある場合はその日時を、顧問先から処理期限の要求がない場合は、後述する実施例４のスケジュール概念に基づく作業完了日時（予定日時）を、紐付けて、データ記録部２１６に記録される処理期限管理テーブル（図示せず）に記録されており、その他のデータと処理期限までの残り日数の少なさで比較して、少ない方から順に優先度を割り振ることができる。この手法は、その記載に限定されるものではない。

サーバー装置２から様々な情報を取得し、会計事務所端末３で統合画面（データ一覧表示）５１０や統合画面（詳細表示）５２０で情報を表示する際に、アクセス権で制御を掛けることもできる。具体的には、サーバー装置２が、取得しようとしている情報を取り扱うことができる作業員なのかを、会計事務所端末３の名前情報や、会計事務所端末３にログインしたユーザー情報などから判断して、取り扱うことを許可された作業員（または会計事務所端末３）にのみ、データの取り扱いを許可（送信、展開）する。このような（アクセス権を与える）セキュリティ管理機能は、本発明に入れるほか、別のシステムで用意して連動することで、様々な情報を、複雑なセキュリティ設定を行うことなく運用でき、機密保持も万全に利用できる。
また、上記セキュリティ管理機能において、作業員毎ではなく、複数の作業員を１グループとして、そのグループに対してアクセス権を与えたり、使用する１ないし複数の会計事務所端末３に対して（会計事務所端末３にログイン出来るユーザーに対して）アクセス権を与えたりすることができる。 なお、新たにグループへ追加された作業員も同グループのアクセス権を引き継ぐこともできる。

設定５１６（ボタン）（図５−１）は、押下することで統合画面（データ一覧表示）５１０とは異なる画面が表示され、統合画面（データ一覧表示）５１０ないし統合画面（詳細表示）（図５−２の５２０）の表示上のカスタマイズ設定をすることができる。 例えば、エラーアイコンの色変更や、特定の顧問先の受信通知に関しての表示有無や、色や文字の太さによる強調表示などを行えるが、これ以上の説明は、本発明の本質とは異なるため、省略する。
会社履歴ボタン５１７は、会社履歴等顧問先等の対応も含めた履歴が確認できる。
一覧表示（５１４）されたデータの中から選択された「受信データの送信元の会社」に関する、過去の受信または送信データ、作業履歴などを別画面にて表示するが、これ以上の説明は、本発明の本質とは異なるため、省略する。
確定（ボタン）５１８は、一覧表示５１４の中から選択したデータの次の作業への入口（作業を開始する操作ボタン）であるが、統合画面（詳細表示）５２０を表示させてもよい。

その他、前述した統合画面（詳細表示）５２０で管理ソフトを切り替えられる機能（図６のＳ６−１２）（図５−２に図示せず）を、統合画面（データ一覧表示）５１０にあってもよい（図５−１に図示せず）。

以上の２つの統合画面（図５−１、図５−２）の作業開始ボタン（５１８、５２５、５２４）や管理ソフトの切り替え（図示せず）により、財務系アプリや税務系アプリの間をまたがって作業ができ、この関係が図２−２となる。

図２−２は、申告書類を作成するまでのアプローチに必要な「財務５０１」や「税務５０２」、「電子申告５０７」をブロックとし、資料作成（５０３、５０４、５０８）やチェック、データ収集（５０５、５０６）などの作業が、財務と税務との間で相互に行き来する業務の関係を示す図である。
具体的には、電子申告業務の過程で、税務関連である法人税申告書、減価償却、内訳書のデータと、財務関連である会計データとを照合することで、金額の不一致等を突き合わせチェックが容易にできることや、必要に応じて修正する場合に、財務側や税務側のアプリを起動してデータの修正をすること、財務関連や税務関連の双方で必要なデータや資料等を収集することなどの、一連の処理を効率よく実行５００することができると、余力の創出５０９が可能となることを示す図である。
実際、会計事務所は、顧問先から受信した会計データから、財務関連の資料（例えば、監査報告や財務帳表など）や、税務関連の資料（例えば各種申告書など）を作成し、電子申告に必要な資料を用意する。 財務関連や税務関連の資料を作成する際は、それぞれの分野に様々なアプリがある。 財務システムまたは財務アプリと、税務システムまたは税務アプリは、別ベンダのもので構成されることが多く、そのため財務と税務の連携・連動ができないことがよくある。 実際の資料用意作業では、財務関連のアプリ同士を切り替えたり、税務関連のアプリ同士を切り替えたりするが、財務関連のアプリと税務関連のアプリを互いに切り替えたりすることも少なくない。
このような場面では、その都度、作業に適切なアプリを起動させる必要があるが、それにはそれなりの手間が掛かる。
本発明では、財務・税務のデータやアプリ、システムの連携・連動により、顧問先から受信した会計データを処理する実作業上で、財務と税務の切り替えを意識することなく自在に行き来でき、垣根を超えた突き付けチェックなども手際よく行え、また必要に応じて遡って作業し直すことも単純操作ででき、あたかも監査、帳表作成、決算・申告処理、電子申告までの会計事務所における一連の実務を、流れ作業のように処理できるように支援する会計処理システムを提供しており、電子申告に必要なデータを自動収集することができ、また手際よく申告手続きまででき、会計事務所の実務効率の総合的な向上により創出された余力を、新サービスや顧客開拓などへ注力することができる。
「財務と税務を自由に行き来」という表現に関してさらに説明すると、例えば法人申告統合システムのことを指しており、本発明の統合メニューから該当アプリ（法人申告統合システム）を起動できるため、従来、会計データ入力を行った後、法人申告統合システムを起動するために、会計データ入力のアプリを閉じ、法人申告統合システムを起動し、該当顧問先を選択肢、該当データを選択することで、やっと法人申告の編集が行えたという煩わしい手順が不要となり、「財務と税務を自由に行き来」できるような感覚で、仕訳入力〜申告書作成〜チェック〜電子申告までの作業を一筆書きのように行うことが出来るということを表現している。

（実施例４）
以下に実施例４を記載するが、この実施例４によって本発明は限定されるものではない。
受信したデータを処理（作業など）した後に、次の業務フローが人手を介さずとも機械的に処理できる場合、データを処理した後の状態変化をきっかけに、会計処理システムが次の業務フローに沿って、自動で処理を実行してもよい。
例えば、顧問先からの受信データを取り込んだ後、会計処理システムが会計データのチェックを自動で実行したり、ある顧問先の申告書を全て作成し、チェックし終わった後、会計処理システムが電子申告用のデータを自動生成したり、作成した資料のチェックが終わった後、会計事務所内の権限を持つ上司（先生）に承認を促したり、顧問先へ提出する資料に提出の許可が得られたら、自動で顧問先に資料を提出したりしてもよい。

（実施例５）
以下に実施例５を記載するが、この実施例５によって本発明は限定されるものではない。
本発明では、階層管理可能なカレンダーを提示、提供することができる。

この階層管理可能なカレンダーは、イベントログテーブル（図３−２）の情報を元に、カレンダーの表記をベースにして、スケジュール状況をビジュアル（視覚的）にまとめて、閲覧制限をかけて情報提供するもので、ユーザーが容易にスケジュールを把握できる様に、また作業漏れを無くす様に支援しながらも、限定したスケジュール閲覧によって情報漏れを抑えることができる機能である。なお、スケジュールの表記方法には、カレンダー表記の他、タイムスケジュール表記やグラフ表記、表による表記などでもよく、その表記は限定されない。同様に、階層管理可能なカレンダーや表形式などのそのフォーマットも制限されない。

階層管理とは、会計事務所内（先生、マネージャー、作業者など）の人員の責任レベルの度合いや担当割当などによる階層と同様に、情報の閲覧も階層的に許可／禁止を管理することである。
例えば、会計事務所の先生は全ての情報を閲覧できるが、作業員は担当顧問先しか閲覧ができない、数の作業員を１つにまとめたグループに対して閲覧を許可するなどの、人に対する閲覧制限の階層管理の方法がある。
また、人に対してではなく、装置に対して閲覧制限することもできる。 例えば、作業端末装置（例えば、会計事務所端末３（図２−１の４０１））の個体情報（ＩＰアドレスやＭＡＣアドレスなど）を元に、特定の作業端末装置に対する閲覧制限や、複数の作業端末装置をグループにまとめて閲覧制限する、装置に対する閲覧制限の階層管理の方法もある。
また、例えば、過去の担当顧問先情報は、担当期間の情報のみに限定して閲覧の許可を与える階層管理の方法もある。
また、例えば、ＡからＣまで、３つの会計事務所で構成された税理士法人に対しても、Ａ会計事務所内のみ閲覧許可、ＢとＣのみ閲覧許可など、事務所単位での階層管理の方法もある。
また、例えば、顧問先にも同様に階層管理可能なカレンダーを提供することも可能で、顧問先の社長は全て閲覧許可、顧問先担当者は処理を行ったデータに関連するスケジュールのみ閲覧許可、顧問先の本社（本店）は全て閲覧許可、支社（支店）は閲覧禁止など、人単位や組織単位での階層管理の方法もある。
なお、例に挙げた階層管理の方法に、その方法は制限されない。

階層管理可能なカレンダーの具体的な実施例として、図２−１のサーバー装置２では、本システムと連動した顧問先管理システムで、データ記録部２１６から顧問先の情報（顧問先ＩＤ、顧問先名、顧問先担当者、顧問先独自の休日、決算日など）を取得し、イベントログ記録部２１８からその顧問先に関する情報（データ受信日、データ形式）を取得し、取得したデータ形式と、業務進行テーブル（図３−３）のデータ形式とを照合する。

図３−３の業務進行テーブルは、データ記録部２１６に記録されており、そのテーブルに記録されているのは、様々な業務フローに関する情報である。 具体的には、データ形式毎に業務フローＩＤを割り振り、業務フローＩＤ毎に業務フローのステップ（工程）と、ステップ毎の工数が記録されている。
ステップには、例えば、ステップ１に依頼受信（データ受信）、ステップ２にデータ確認という、ステップ毎に作業概要が紐付けられた形で記録されており、作業概要はその他にも、データ取込、帳表作成、監査、申告書作成、電子申告準備、提出、申請などが記録されているが、これに限定されない。
ステップ毎の工数には、ステップに紐づけてそのステップにかかる工数が時間単位の数値で記録されているが、これに限定されない。

このテーブルは、基本的には事前に用意されているものだが、新たな業務フローをユーザーが追加設定することや、ベンダが定義ファイルを提供してそれを取り込むことで追加設定することも可能であり、自由に追加、削除することができる。 また、業務フロー毎のステップの変更、ステップ毎の工数の変更も、ユーザーによって修正ができる。 さらに、ステップ毎の工数の変更に関しては、実際に作業員が作業を行った際にその履歴がイベントログ記録部２１８に記録されるが、その情報を元に、ステップ毎の工数を、同業務進行テーブル内に複数回分記録し、平均化したものを新たなステップ毎の工数として更新することもできる。

取得したデータ形式と、業務進行テーブル（図３−３）のデータ形式とを照合して得られた業務フローＩＤ（業務フロー）を元に、業務進行テーブルのステップ１を、データ受信日として起点とし、ステップ２から業務フローの最終ステップＸまで、それぞれに割り当てられた工数（業務進行テーブル（図３−３）に存在）を、それぞれの間隔（期間）として、データ記録部２１６にある、スケジュールＤＢに記録される。

スケジュールＤＢに記録される情報は、顧問先の情報、会計事務所の情報、日付と関連付けられた業務フロー、カレンダー情報などがあるが、それらに限定されない。
具体的にスケジュールＤＢに記録される情報の例として、顧問先の情報には、顧問先管理システムから取得した、顧問先ＩＤ、顧問先名、顧問先担当者、顧問先独自の休日、決算日などがあり、会計事務所の情報には、顧問先管理システムから取得した、顧問先担当責任者、顧問先担当作業者のほか、本システム（イベントログ記録部２１８）から取得した、業務処理を完了させた作業員名、業務処理を完了させたステップ数、業務処理を完了させた日付や、本システム（設定管理テーブル群）から取得した階層管理レベル数、日付と関連付けられた業務フローには、業務進行テーブル（図３−３）から取得した、ステップ（業務概要）、ステップ数、ステップ数に対する工数、業務フローカレンダー情報には、既にスケジュールＤＢに記録されているほか、インターネット経由で更新された日付情報である、年月日、曜日、日本の祝日、が記録されているが、これらに限定されない。

本システムの設定管理テーブル群は、データ記録部２１６に記録されており、会計事務所内の先生および従業員全て（以下、所員）に対する所員ＩＤ、氏名、閲覧権限レベルの所員テーブルと、所員ＩＤに対して、担当顧問先ＩＤと担当期間（担当開始日と担当終了日）の組合わせと紐付けた顧問先担当テーブルと、所員ＩＤに対して、顧問先ＩＤ毎の閲覧許可／禁止フラグをまとめた顧問先別閲覧管理テーブルとを含む、複数のテーブルをまとめたものであり、その他、本システムの表示設定や条件設定などのテーブルも含まれるが、それらテーブルは、本システムではなく、連動する別のシステム（例えば、所員管理システムなど）にテーブルを持ってもよいし、これらに限定されない。

以上に述べた様々な情報をスケジュールＤＢより取得し、顧問先用のスケジュールを階層管理可能なカレンダーに、データ受信日から作業終了までに必要な日数分の営業日を帯状に塗布させて、途中の作業概要も帯上に示したもの顧問先端末１（図２−１）や会計事務所端末３（図２−１）に通信部２０７（図２−１）を介して提供し、出力部（図２−１の１０６ないし４０６）で表示することで、受信したデータに関するスケジュール兼業務フローが可視化できる。

その表示のフォーマットは、月単位の表示方法もあるが、その他、週単位、３日単位、１日単位と拡大表示する方法もあり、４半期単位、半年単位、１年単位と縮小表示する方法もあるが、これらに限定されない。

表示方法には、その他に、ある条件下において、順番を並べ替える（ソートする）表示方法もある。
例えば、１日単位での表示の中に、複数の顧問先のスケジュールがある場合、各顧問先の決算日の近い順に表示させることや、会計事務所内の担当者名の五十音順にその担当顧問先を順に表示させること、データにエラーや不備があると認識した日時順に表示させること、など様々な並べ替えができるが、これらに限定されない。

スケジュールの表示内容は、例えば、５Ｗ１Ｈに基づき、いつ、どこで、誰が、いくらで、何を、どうするなどの基本情報が表示される他、セキュリティレベル（どのレベルの人まで閲覧できるか）なども表示できるが、この例えによって表示できる内容は限定されない。
そして、本システム等を活用して、データに対する作業を実施したら、階層管理可能なカレンダーに、だれが、どのくらいの期間、どのデータを、どこまで作業したかなどを反映させ、作業進捗の可視化ができるが、この例えによって可視化できる内容は限定されない。

この階層管理可能なカレンダーに付加されたスケジュール情報の閲覧は、例えば、会計事務所の他、該当する顧問先へ、そのままのカレンダー形式や表形式などで閲覧できるようにしてもよいし、更に整理または絞った情報を表現してもよいが、この例えによって顧問先が閲覧可能な情報量は限定されない。

このカレンダーや表形式は閲覧の他、スケジュールの期限をアラート（表示、音、スマホ転送など）で、会計事務所内にお知らせしてもよい。このアラートも階層管理と連動させ、権限を持つ人にのみ、アラート通知させてもよい。

さらに、そのカレンダーで可視化された業務フローまたは作業進捗から、次の作業のために必要なアプリを起動させてもよい。業務フローや作業進捗は、円グラフや日めくりなど、様々な可視化方法があるので、ここでは言及しない。

（実施例６）
以下に実施例６を記載するが、この実施例６によって本発明は限定されるものではない。
以下の実施例６で記載されている業務処理手順は、作業手順と同一の意味を持つものであり、会計事務所の作業手順通りに円滑に進める支援をしているため、業務処理手順を実行（作業手順実行）する会計処理装置であって、具体的に作業手順実行装置や作業手順実行支援装置として読み替えることも可能である。
会計事務所端末３は制御部４０２と記憶部４０３と入力部４０４と出力部４０６と通信部４０７から構成される。実施例６は会計事務所端末３で説明して説明しているが、制御部と記憶部についてはサーバー装置２（制御部２０２と記憶部２０３）で行ってもよい。

アプリケーション情報テーブル（図３−１）は担当者が業務で使用するアプリケーション（以下アプリとする）とアプリで使用するデータを管理するテーブルであり、「処理ステップ」（図示せず）と「アプリ名」と「データ形式」と「必要データ」の項目からなる。「処理ステップ」は後述する業務進行テーブルのステップ（例えば、「データ取込」、「帳表作成」、「申告書作成」、「電子申告準備」等）に対応し、業務処理の処理手順と使用するアプリを対応付けている。「アプリ名」は業務で用いるアプリ名（例えば、会計データ入力、法人税申告書作成、減価償却入力、事業概況説明書作成、勘定科目内訳書作成、決算報告書作成、相続税申告書作成、電子申告システム等）を示し、「データ形式」はアプリが使用するデータの形式（例えば、会計データ、法人税申告書データ、減価償却データ、事業概況説明書データ、勘定科目内訳書データ、帳表データ、申告データ等）である。「必要データ」はアプリがデータ取込可能なデータの形式である。

業務進行テーブル（図３−３）は担当者の業務進捗を管理するテーブルであり、「業務フローＩＤ」と「担当者名（図示せず）」と「顧問先名（図示せず）」と「データ形式」と「ステップ１」から「ステップＮ」までの項目からなる。「業務フローＩＤ」は担当者が行う業務を識別するもので、「担当者名」は業務処理を行なう担当者の名前を示す。「顧問先名」は担当者が業務処理を行なう対象である顧問先の名前を示す。「データ形式」は顧問先から受信するデータの形式（例えば会計データや画像データ等）を示す。「ステップ１」から「ステップＮ」は担当者の業務処理の処理手順を示す。

ここで担当者Ａが業務の流れの例として電子申告処理について図４に基づき説明する。
管理テーブルとしてアプリケーション情報テーブル（図３−１）と業務進行テーブル（図３−３）と後述するイベントログテーブル（図３−２）の３つのテーブルからなり、記憶部４０３に記憶される。

図４のＳ１において担当者が会計事務所端末３で電子申告処理を行なう顧問先Ｂを選択すると、会計事務所端末３の制御部４０２が業務進行テーブルの項目「業務フローＩＤ」に電子申告業務を示す値「３」を、項目「担当者名」に「Ａ」の値を、項目「顧問先名」に「Ｂ」の値を、項目「ステップ１」から「ステップ８」に電子申告処理に必要な処理手順（項目「ステップ１」から順に「依頼受信」、「データ確認」、「データ取ｊ込」、「帳表作成」、「申告書作成」、「電子申告準備」、「署名付与」、「提出」の値）を設定する。制御部４０２は、業務進行テーブルの項目「ステップ１」の値である「依頼受信」を読み出し、顧問先から電子申告の依頼が来ているかをチェックする。

電子メール等で電子申告の依頼を受信していることを確認できたら、電子申告依頼の受信済の通知を表示する。担当者は表示された通知を確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことで依頼受信処理が終了する。

制御部４０２は、業務進行テーブルの項目「ステップ２」の値「データ確認」を読み出し、後述する基本情報（図示せず）を生成して表示する。基本情報は電子申告に必要な情報であり、「納税者」、「組織情報」、「決算日」、「税目」、「納税先」、「税理士名」の項目からなる。

具体的には制御部４０２が顧問先情報（図示せず）から顧問先Ｂの組織情報（法人か個人か）と決算日と納税先（税務署名）を読み出し、基本情報の項目「納税者（納税者の名前）」に「Ｂ」を、項目「組織情報」に「法人」を、「決算日」に「○○年３月３１日」を、「税目（申告する税対象）」に「法人税」を、「納税先」に「Ｄ税務署（ＵＲＬも含む）」を、「税理士名」に「Ｓ」を設定して、基本情報を生成する。

制御部４０２は生成した基本情報に不足（例えば、情報未記入等）や間違い（例えば、顧問先の住所と対応する税務署名が一致しない等）等のエラーがないかチェックし、エラーがなければそのまま表示し、エラーがあればその部分を強調表示等の担当者にわかりやすい形で表示する。担当者が基本情報を目視でチェックし、エラー等がないことを確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことでデータ確認処理が終了する。

制御部４０２は、業務進行テーブルの項目「ステップ３」の値「データ取込」を読み出し、さらに項目「データ形式」の値「会計データ」を読み出す。制御部４０２は顧問先Ｂから会計データを受信しているかをチェックし、電子メール等で会計データが受信していることを確認できたら（図４のＳ４−２）、「電会計データを受信している」との通知を表示する。担当者は表示された通知を確認したら、確認ボタン（図示せず）を押すと、制御部４０２はアプリケーション情報テーブルを参照して会計データ入力のアプリが起動する。

具体的には、確認ボタンが押されることで、制御部４０２はアプリケーション情報テーブルの項目「処理ステップ」の値が「データ取込」となる「アプリ名」と「データ形式」と「必要データ」を検索し、項目「アプリ名」の値である「会計データ入力」と項目「データ形式」の値である「会計データ」と項目「必要データ」の値である「会計データ」を取得する。項目「必要データ」の値が「会計データ」のため、「会計データ入力」のアプリを起動されたら、制御部４０２は顧問先から受信した会計データの取込処理を行なう。

取り込んだ会計データは記憶部４０３へ顧問先毎に分類して記憶する（Ｓ４−３）。データの整合性や作業内容等の状態等についてデータチェックを行い（Ｓ４−５）、取込処理の完了とデータチェックの結果の通知を表示する（Ｓ４−６）。担当者は表示された通知を確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことでデータ取込処理が終了する。

制御部４０２は、業務進行テーブルの項目「ステップ４」の値「帳表作成」を読み出し、アプリケーション情報テーブル（項目「アプリ名」は値「決算報告書作成」、項目「データ形式」は値「帳表データ」、項目「必要なデータ」は値「会計データ」）を参照し、「決算報告書作成」のアプリを起動する。「決算報告書作成」のアプリを起動されたら、制御部４０２は記憶部４０３に記憶した会計データを取り込むと、担当者は会計データを元に決算報告書である帳表データを生成する。

生成した帳表データが記憶部４０３に記憶されると、制御部４０２は決算報告書の作成完了の通知を表示する。担当者は表示された通知を確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことで帳表作成処理が終了する。

制御部４０２は、業務進行テーブルの項目「ステップ５」の値「申告書作成」を読み出し、アプリケーション情報テーブル（項目「アプリ名」は値「減価償却入力、事業概況説明書作成、勘定科目内訳書作成、法人税申告書作成」、項目「データ形式」は値「減価償却データ、事業概況説明書データ、勘定科目内訳書データ、法人税申告書データ」、項目「必要なデータ」は値「なし」）を参照し、「減価償却入力」と「事業概況説明書作成」と「勘定科目内訳書作成」と「法人税申告書作成」のアプリを起動する。

「減価償却入力」のアプリを起動されたら、担当者Aは減価償却データを生成する。生成した減価償却データが記憶部４０３に記憶されると、制御部４０２は減価償却データの作成完了の通知を表示する。なお、減価償却データは申告書に添付す明細資料（例えば控除証明書等）である。

「事業概況説明書作成」のアプリを起動されたら、担当者Aは事業概況説明書データを生成する。生成した事業概況説明書データが記憶部４０３に記憶されると、制御部４０２は事業概況説明書の作成完了の通知を表示する。なお、事業概況説明書データは申告書に添付する提出資料（例えば登記事項証明書や住民票等）である。

「勘定科目内訳書作成」のアプリを起動されたら、担当者Aは勘定科目内訳書データを生成する。生成した勘定科目内訳書データが記憶部４０３に記憶されると、制御部４０２は勘定科目内訳書の作成完了の通知を表示する。なお、勘定科目内訳書データは申告書に添付する計算書類（例えば勘定科目内訳書等の各種内訳書や決算報告書等）である。

「法人税申告書作成」のアプリを起動されたら、担当者Aは法人税申告書データを生成する。生成した法人税申告書データが記憶部４０３に記憶されると、制御部４０２は法人税申告書の作成完了の通知を表示する。担当者は表示された上記４つの通知を確認したら（Ｓ４−６）、４つの通知の確認ボタン（図示せず）を押す。制御部４０２が通知の確認ボタンが４つとも押されたことを検出することで申告書作成処理が終了する。

制御部４０２は、業務進行テーブルの項目「ステップ６」の値「電子申告準備」を読み出し、アプリケーション情報テーブル（項目「アプリ名」は値「電子申告システム」、項目「データ形式」は値「申告データ」、項目「必要なデータ」は値「法人税申告書データ、減価償却データ、事業概況説明書データ、勘定科目内訳書データ、帳表データ」）を参照し、「電子申告システム」のアプリを起動する。

「電子申告システム」のアプリを起動されたら、制御部４０２は記憶部４０３に記憶した法人税申告書データと減価償却データと事業概況説明書データ、と勘定科目内訳書データと帳表データを取り込むと、担当者は法人税申告書データと減価償却データと事業概況説明書データ、と勘定科目内訳書データと帳表データを元に電子申告用の申告データを生成する。

生成した申告データが記憶部４０３に記憶されると、制御部４０２は申告データの作成完了の通知を表示する。担当者は表示された通知を確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すと、制御部４０２は基本情報（項目「税理士名」）を参照して、承認用の端末に税理士へ申告データの署名依頼の通知を行なうことで電子申告準備処理が終了する。

承認用の端末で税理士が署名依頼の通知を確認したら、制御部４０２は、業務進行テーブルの項目「ステップ７」の値「署名付与」を読み出し、アプリケーション情報テーブル（項目「アプリ名」は値「電子署名」、項目「データ形式」は値「署名済申告データ」、項目「必要なデータ」は値「申告データ」）を参照し、「電子署名」のアプリを起動する。

「電子署名」のアプリを起動されたら、制御部４０２は記憶部４０３に記憶した申告データを取り込むと、税理士は申告データの内容を確認後、申告データに電子署名を行い、署名済申告データを生成する。署名済申告データが記憶部４０３に記憶されると、制御部４０２は署名済申告データの作成完了の通知を承認用の端末と担当者の端末に表示する。税理士は表示された通知を確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことで署名付与処理が終了する。

担当者が署名済申告データの作成完了の通知を確認したら、制御部４０２は業務進行テーブルの項目「ステップ８」の値「提出」を読み出し、アプリケーション情報テーブル（項目「アプリ名」は値「電子申告システム」、項目「データ形式」は値「署名済申告データ」、項目「必要なデータ」は値「署名済申告データ」）を参照し、「電子申告システム」のアプリを起動する。

「電子申告システム」のアプリを起動されたら、制御部４０２は記憶部４０３に記憶した署名済申告データを取り込むと、担当者は基本情報（項目「納税者」は値「Ｂ」、項目「組織情報」は値「法人」、「決算日」は値「○○年３月３１日」、「税目」は値「法人税」、「納税先」は値「Ｄ税務署（ＵＲＬを含む）」を、「税理士名」は値「Ｓ」）を参照して、署名済申告データに電子申告先情報（図示せず）を設定し、設定した電子申告先情報を表示する。

具体的には制御部４０２は電子申告先情報に「納税者」と「処理年」と「税目」と「納付先」と「税理士」の項目からなり、項目「納税者」に値「Ｂ」を、項目「処理年」に値「○○年」（「○○年３月３１日（決算日）」から生成）を、「税目」に値「法人税」を、「納税先」は値「Ｄ税務署（ＵＲＬを含む）」を設定する。担当者Aが表示された電子申告先情報をチェック後、納税先に署名済申告データを提出し、納付先からの受信通知を受信していることを確認できたら、受信通知の受信済の通知を表示する。担当者は表示された通知を確認し、提出完了していることを確認したら（Ｓ４−６）、確認ボタン（図示せず）を押すことで提出処理が終了する。

担当者Aに処理終了の通知を行っているが、担当者だけでなく、担当者の上司にも同時に通知してもよい。また、表示した通知を履歴として残し、後の工程（処理手順）で表示予定の通知や未確認の通知と一緒に工程順に並べて表示することで、アプリを起動しなくても通知履歴を確認するだけで現在の進捗状況を把握できる。具体的には、例えば工程が終了した通知をプログレスバーのように、処理の進行に合わせてバーが伸びるようにし、全ての工程が完了時にバーの長さが１００％になるようにする。最初に担当者名（Ａ）と対象と業務（電子申告業務）と進捗率（処理済の工程／全行程）と全ての工程の数だけ横長のバーをグレーアウト（無効化）の状態で表示しておき、１つの工程が終了（通知が表示）するたびにバーを伸ばしていく（有効化）ことで進捗状況をリアルタイムに視覚化することができる。
さらに、標準作業時間や実作業時間を表示してもよいし、月、週、日の予定作業量のバーを強調して実作業量と比較できるようにしてもよい。

また、各ステップで担当者のアプリの操作の履歴とデータの処理の履歴を取っておき、各ステップでの処理時間（図示せず）を履歴と一緒にログ情報としてイベントログテーブル（図３−２）に残す。イベントログテーブル（図３−２）は「年月日」と「開始時刻」（図示せず）と「終了時刻」（図示せず）と「イベント内容」と「処理結果」（図示せず）と「アプリ名」（図示せず）と「データ形式」（図示せず）と「データＩＤ」（図示せず）と「担当者名」（図示せず）と「業務ＩＤ」（図示せず）と「処理ステップ」（図示せず）と「処理時間」（図示せず）の項目からなる。

「年月日」と「開始時刻」と「終了時刻」は履歴の記録の開始日時と終了日時であり、「処理時間」が業務処理にかかった時間（処理時間は開始時間と終了時間から算出する）である。「イベント内容」は担当者のアプリの操作（例えば、顧問先Ｂの会社データ入力や顧問先Ｂの申告書データ作成の履歴であり、「処理結果」はデータの状態（アプリの処理結果）の履歴である。「処理ステップ」は担当者が履歴を取っている業務処理の処理手順であり、「アプリ名」は履歴を取っているアプリ名である。「データ形式」は履歴を取っているアプリが使用するデータの形式であり、「データＩＤ」は履歴を取っているアプリが処理しているデータを識別するものである。「業務フローＩＤ」は担当者が行う業務を識別するもので、「担当者名」は履歴を取っている業務処理を行なう担当者の名前を示す。

また、ＡＩ等の学習モデルである分類器を記憶する記憶部４０３にある学習モデル記憶部（図示せず）を用意し、進捗管理学習モデルを用いたＡＩによる学習処理によって行ってもよい。
例えば、進捗管理学習モデルがイベントログテーブル（図３−２）のログ情報を学習することで、各担当者のログ情報から最適な作業工数や作業の傾向（ミスしやすい作業やミスが多い作業等）を分析することで、担当者の作業工数の効率を高めることができる。

具体的には、制御部４０２は担当者の職位（例えば、ベテラン、中堅、新人等）毎の業務処理手順との実作業時間を分析することで、ベテランの業務処理手順と作業時間を元に業務処理手順の標準化を行なうことができる。つまり、業務処理手順（処理項目の実行順序）と各処理項目の実行履歴（作業時間を含む）の組み合わせからトータルでの業務処理手順の作業時間が短くなる最適な組み合わせ（最適な処理項目の実行順序と各処理項目の作業時間（標準作業時間）の組み合わせ）が最も作業時間短くなるので１顧問先当たりの業務処理手順のトータルの作業工数と各処理項目あたりの作業工数を算出できる。

また、標準作業時間に職位毎の熟練度係数（例えば、ベテランは０．８、中堅は１、新人は２）をかけることで、職位毎の標準作業時間（職位作業時間）を算出できるので、顧問先数と作業工数から必要な業務量を算出し、必要な業務量と担当者毎に担当者の力量に合わせた職位作業時間がスケジュール（表）に表示することができる。例えば、帳表作成の業務の標準作業時間が１．５時間とした場合に、担当者Aは中堅なので１．５時間、ベテランＳは１．２時間（１．５時間×０．８）、新人Ｔは３時間（１．５時間×２）が職位毎の職位作業時間となる。担当者Ａが昨日に帳表作成の業務に２時間かかっていることが履歴に残っているとすると、担当者Ａの上司は担当者Ａの業務の進捗が遅いことを客観的に把握できる。また、長期間各担当者の履歴を収集することで、得意な業務や苦手な業務等の担当者の傾向（得意な業務だと作業時間が短く、苦手な業務だと作業時間が長くなる）を上司が把握でき、担当者毎の指導に生かすことができるし、担当者毎の業務進捗の予定を可視化できる。

税理士等の上司は役職（例えば、先生（有資格者）、番頭（責任者）、主任、一般、アルバイト等）によって、スケジュールの閲覧権限を設定する事で、役職が閲覧権限のある先生や番頭等は全ての担当者の情報が表示され、スケジュールに表示された必要な業務量と各担当者の職位作業時間から必要な担当者の数を算出でき、各担当者に適切な量の業務を割り当てることができる。例えば、繁忙期であれば処理優先で、担当者に得意な業務を割り当てるのに対し、閑散期は担当者のスキルアップ優先で、担当者が苦手な業務や新しい業務を割り当てたりする等の事務所の状況に応じて担当者の業務をスケジュールできる。
また、役職が閲覧権限のない主任、一般、アルバイト等は自分の情報のみがスケジュールに表示される。

また、担当者がスケジュール表から月単位、週単位、日単位で最適な業務処理手順（作業手順）及び標準作業時間と実際の業務処理手順及び実作業時間を並べて表示に切り替えることで、担当者の進捗状況と作業効率を視覚化できる。また、担当者毎に時間がかかっている作業や間違った作業や効率の悪い作業等の問題のある作業を抽出する。例えば、担当者Ａが帳表作成業務が苦手な業務だった場合に、抽出された作業を分析することで手順のどこにつまずいているかの原因が入力が遅いためなのか、処理手順を理解していないからなのか等がわかるので、上司は具体的な改善策を担当者に指導することができる。

また、実際の業務処理手順で問題のある作業について強調したり、色を変えたりすることで、問題点を視覚化でき、さらに問題のある作業を選択することで、改善方法等（正しい手順やコツ等）を表示することで、担当者は自分で気づかない無駄な作業を客観的に把握でき、改善することができる。

また、担当者が繰り返し作業ミスを行っている部分やミスしやすい作業（分析結果から全体的にミスの多い作業を抽出）については予め改善方法をガイド表示することで、ミスを事前に防止するようにしてもよい。

また、問題のある作業や改善の数を毎日集計することで、担当者の仕事の取り組み姿勢を定量化でき、改善が少ない担当者には警告を表示することで、担当者の業務改善を促すことができる。

このように、実施例６で記載されている業務処理手順は、作業手順と同一の意味を持つものであり、会計事務所の作業手順通りに円滑に進める支援をしているため、業務処理手順を実行（作業手順実行）する会計処理装置であって、具体的に作業手順実行装置や作業手順実行支援装置として読み替えることも可能である。

本発明では、業務処理の処理手順をあらかじめ作業項目（業務処理）として設定する事で、作業項目の作業手順（業務処理の処理手順）を設定し終了時に通知する事で、業務を定型化することができる。また、業務処理の処理手順毎に担当者が意識せずに必要なアプリとデータを用意され、処理終了の通知を行なうことで、担当者がデータの転送や返却等の複雑な処理を意識せずにあたかも一筆書きのようにシステム化された進捗管理を行なうことができる。また、担当者の業務の作業を標準化することでき、改善状況も定量化できるので、スケジュールに合わせて最適な人数の担当者を割り当てができ、各担当者の進捗状況も一括で管理できる。

以上、本発明は、上述した実施例に限定されるものではなく、例えば、正常に動作ができる前提で上述したものであり、本来はイリーガルな動作をした時の対処方法も考慮すべきものだが、様々な手法で回避できるため、詳細な説明は省略する。また、実施例に記載した効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施例に記載したものに限定されない。なお、上述した実施例は、適宜組み合わせて用いることもできるが、詳細な説明は省略する。
また、顧問先から受信したデータや資料を活用することで、顧問先における実務の省力化・精度向上、緊密な連携が出来るようになるため、入力作業を大幅に削減し、監査以降のよりサービス付加の高い業務に注力できる。 以上のようなメリットを持つ会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供するという効果を有すため、会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法等として有用である。

以上のように、本発明に係る、会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法は、会計事務所の日常作業の中で、顧問先からの様々なデータに対して、素早く受信に気付けるようにすると共に、１つの管理画面からの操作で、データの取り込みやデータに不備がないかの確認が出来るように操作性を統一し、税務申告等までの作業を、一筆書きのような明確な作業ルーチンで提供しつつ、イベントや作業等の履歴も管理することができる。また、顧問先から受信したデータや資料を活用することで、顧問先における実務の省力化・精度向上、緊密な連携が出来るようになるため、入力作業を大幅に削減し、監査以降のよりサービス付加の高い業務に注力できる。 以上のようなメリットを持つ会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法を提供するという効果を有すため、会計処理システム、会計処理装置、会計処理プログラム及び会計処理方法等として有用である。

１０ 顧問先端末装置
２０ データセンター又は会計事務所のサーバー装置
２１ 会計事務所端末装置
１００ 顧問先
１０１ 顧問先端末全体の機能ブロック
１０２ 顧問先端末制御部
１０３ 顧問先端末記憶部
１０４ 顧問先端末入力部
１０５ 顧問先端末画像取込部
１０６ 顧問先端末出力部
１０７ 顧問先端末通信部
１１０ 顧問先端末データ送受信部
１１１ 顧問先端末データ記録部
１１２ 顧問先端末アプリ情報管理記録部
１１３ 顧問先端末イベントログ記録部
１５０ 顧問先アプリ
１５１ 顧問先作業端末
１５２ 他社製ソフトウェアCSVデータ
１５３ 領収書等の紙面
１５４ 通帳カード明細
１５５ 銀行カード/クレジットカード明細
１５６ その他のデータ
１５７ 記帳処理
１５８ 仕訳、元帳の表示
２００ 会計事務所
２０１ 会計事務所サーバー装置全体の機能ブロック
２０２ 会計事務所サーバー装置制御部
２０３ 会計事務所サーバー装置記憶部
２０４ 会計事務所サーバー装置入力部
２０５ 会計事務所サーバー装置画像取込部
２０６ 会計事務所サーバー装置出力部
２０７ 会計事務所サーバー装置通信部
２１０ 会計事務所サーバー装置データ送受信部
２１１ 会計事務所サーバー装置データ受信認識部
２１２ 会計事務所サーバー装置データ異常判断部
２１３ 会計事務所サーバー装置データ状況判断部
２１４ 会計事務所サーバー装置データ重要度判定部
２１５ 会計事務所サーバー装置データ受信通知部
２１６ 会計事務所サーバー装置データ記録部
２１７ 会計事務所サーバー装置アプリ情報管理記録部
２１８ 会計事務所サーバー装置イベントログ記録部
２１９ 会計事務所サーバー装置業務進行記録部
２５０ 会計事務所アプリ
２５１ 会計事務所作業端末
２５２ 顧問先データの取り込み処理
２５３ 会計事務所監査業務
２５４ 会計事務所財務帳表作成業務
２５５ 会計事務所電子申告業務
２５６ 会計事務所監査業務におけるデータチェック
２５７ 出力表示の統一
３００ インターネット
３０１ インターネット又はLAN
３５０ 顧問先アプリから会計事務所アプリへのインターネット通信
３５１ 会計事務所アプリから顧問先アプリへのインターネット通信
３５２ 会計事務所から顧問先へのインターネットによるメール、データ転送
４０１ 会計事務所端末全体の機能ブロック
４０２ 会計事務所端末制御部
４０３ 会計事務所端末記憶部
４０４ 会計事務所端末入力部
４０５ 会計事務所端末画像取込部
４０６ 会計事務所端末出力部
４１０ 会計事務所端末データ新着表示部
４１１ 会計事務所端末受信データ一括表示部
４１２ 会計事務所端末データ異常表示部
４１３ 会計事務所端末データ重要度表示部
４１４ 会計事務所端末データ状況表示部
４１５ 会計事務所端末データアイコン表示部
４１６ 会計事務所端末メイン画面選択
４１７ 会計事務所端末異常データ確認開始ボタン表示部
４１８ 会計事務所端末取込開始ボタン表示部
４１９ 会計事務所端末データ取り込み部
４２０ 会計事務所端末データ編集ボタン表示部
４２１ 会計事務所端末データ編集部
５００ 本発明の機能
５０１ 財務処理業務
５０２ 税務処理業務
５０３ 財務処理詳細説明（監査/帳表作成）
５０４ 税務処理詳細説明（申告書作成）
５０５ 財務データの流れ
５０６ 税務データの流れ
５０７ 電子申告処理
５０８ 電子申告処理詳細説明
５０９ 本発明の効果（余力の創出）
５１０ 統合画面（データ一覧表示）
５１１ データの会社名
５１２ データの表示条件設定１
５１３ データの表示条件設定２
５１４ データの一覧表示部
５１５ データの表示条件固定値設定ボタン
５１６ データの各種設定ボタン
５１７ データのイベント履歴表示ボタン
５１８ データの選択ボタン
５１９ 統合画面（データ一覧表示）の終了ボタン
５２０ 統合画面（詳細表示）
５２１ ファイル（データ）の種類
５２２ ファイル（データ）の顧問先情報
５２３ ファイル（データ）の状況
５２４ ファイル（データ）のエラー通知
５２５ ファイル（データ）の処理開始ボタン
５２６ ファイル（データ）の概要
５２７ ファイル（データ）のイベント履歴表示ボタン
５２８ ファイル（データ）の取込ボタン
５２９ 統合画面（詳細表示）の終了ボタン

Claims (4)

1. 税務申告を行なうためになされる一連の処理に対応する複数の作業項目を含む作業手順の順序に従って実行する会計処理装置において、
   証憑の電子データを参照して仕訳を入力する会計データを作成し、前記会計データと前記証憑の電子データとを関連付けする会計参照入力手段と、
   前記会計データを参照して帳表データを作成し、前記帳表データと前記会計データとを関連付けする帳表作成手段 と、
   前記会計データを参照して明細データを作成し、前記明細データと前記会計データとを関連付けする明細書作成手段と、
   前記帳表データと前記明細データとを参照して申告データを作成し、前記申告データと前記帳表データと前記明細データとを関連付けする申告書作成手段と、
   前記申告データに署名を付与する電子署名手段と、
   前記作業項目として前記会計参照入力手段、前記帳表作成手段、前記明細書作成手段、前記申告書作成手段又は前記電子署名手段のいずれかの処理を実行し、実行終了時に終了通知を発行する作業項目実行処理を行なう作業項目実行手段と、
   を備え、
   前記作業項目実行手段は、前記複数の作業項目に含まれる全ての作業手順が終了するまで前記終了通知を受け付けるたびに前記作業項目実行処理を繰り返すことを特徴とする会計処理装置。
2. 請求項１記載の会計処理装置において、
   前記作業手順に従って発行した作業項目毎の通知を作業手順の順序に並べて表示することで作業項目の進捗状況として表示する進捗状況管理手段を備えることを特徴とする会計処理装置。
3. 請求項２記載の会計処理装置において、
   前記作業項目毎の処理履歴を記録する履歴記録手段を備えることを特徴とする会計処理装置。
4. 請求項３記載の会計処理装置において、
   少なくとも前記進捗状況と前記処理履歴との組み合わせを学習した学習モデルと、
   前記進捗状況と前記処理履歴との組み合わせから最適な作業手順となる組み合わせを前記学習モデルが判定する作業手順判定手段と、
   を備えることを特徴とする会計処理装置。