JP2020170479A - 会計処理システムおよびプログラム - Google Patents

Abstract

【課題】金融機関から提供される明細データを出納帳形式のソフトウェアに取り込むときに、毎回ユーザーが必要な項目の指定や定義を行うといった、多くの操作が発生するという問題がある。【解決手段】金融機関から提供される明細データを出納帳形式のソフトウェアに取り込むときに、より少ない操作で、取り込むデータの指定や定義にかかる操作を簡略化し、さらにデータの重複を低減することができ、取り込んだ明細データから仕訳の作成を簡単に行うことが可能となる。【選択図】 図３

Description

本発明は、会計事務所の顧問先企業などで、記帳ソフトを利用して、仕訳入力を行なう場合に用いられる会計処理システムにおいて、金融機関から提供される金融機関が管理する口座明細に関するデータ（以下口座明細データとする）を会計処理可能なデータへ取り込む技術に関する。

従来、公認会計士事務所や税理士事務所（以下単に「会計事務所」または「事務所」と称す。）では、顧問先から種々の形式で会計処理の元となるデータや原始証憑類を受け取って当該顧問先の会計処理を行っている。近年、パソコンの普及により、顧問先から会計事務所へ提出される基礎資料は電子媒体である場合が多くなっている。

顧問先から、会計事務所へ電子媒体（データ）として、基礎資料を提出する場合、一般的に顧問先側で出納帳形式のソフトウェアを使用して取引を入力し、データのままネットワークを介して会計事務所に送信するか、メモリカードなどの記憶媒体に格納して会計事務所に渡す方法がある。

このような出納帳形式のソフトウェアを使用する時、顧問先側では取引のある金融機関（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）から提供される口座明細データを取り込んで、会計処理可能なデータ形式に変換してから、会計事務所へ渡すことが、オンラインバンキングの普及に伴い多くなっている。

金融機関から提供される口座明細データを取り込んで、会計処理可能なデータ形式に変換するため、例えば、ウィザード形式により取り込むデータの指定や定義を行なう技術がある（例えば、特許文献１）。

また、オンラインバンキングと会計処理システムを組合せて、ネットワーク経由で金融機関からのデータを取込み、会計処理システムへ反映する技術がある（例えば、特許文献２）。

また、銀行口座の取引データを一定のフォーマットに変換して、さらに仕訳データに変換する会計データベースの技術がある（例えば、特許文献３）。

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

これまで、顧問先側で出納帳形式のソフトウェアを使用して、取引のある金融機関（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）から提供される口座明細データを、会計処理可能なデータとして取り込むとき、金融機関から提供される口座明細データの形式は金融機関毎に独自のフォーマット（項目名）を使用している場合が多く、以下のような手順を踏む必要があった。
手順（１）金融機関から口座明細データを入手する
手順（２）出納帳形式のソフトウェアで、口座明細データを読み込む
手順（３）出納帳形式のソフトウェアで、処理できるように、口座明細データの項目名毎に、取り込むデータの指定と定義をする
手順（４）指定したデータを、定義に基づいて出納帳形式のソフトウェアに変換して取り込む

金融機関から提供される口座明細データについては金融機関毎にデータのフォーマット（例えば、日付、摘要、預入、引出などの項目名の並び方や項目の種類）が異なるため、金融機関毎に、出納帳形式のソフトウェアにデータを取り込むときに、毎回ユーザーが必要な項目の指定と定義を行うといった、多くの操作が発生するという問題がある。
また口座明細データをＣＳＶ形式（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）やＸＭＬ形式（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のデータとして入手する際は、銀行毎にログインしてＣＳＶ形式のデータを入手する必要があり手間がかかるという問題がある。

金融機関毎にデータの項目（例えば、日付、摘要、預入、引出など）の並び方や項目の種類をフォーマット化して、変換用に事前に出納帳形式のソフトウェアに準備することも可能ではあるが、日本国内にある、全ての金融機関（都市銀行、地方銀行、信用金庫、農協やその他組織（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）などのフォーマットを調査して準備することは、メーカー側の作業負担が多くなることや、金融機関のフォーマット変更に随時対応しなければならない等の問題がある。

また、昨今では中小企業でもグローバル化が進んでいるため、海外からの物品購入やライセンス料の支払など、海外企業と取引のある企業においては、海外の銀行に口座を有して、送金や為替取引など円以外の通貨単位にて、やり取りすることもあるので、外国の銀行も含めると上述した金融機関毎のデータ項目をフォーマット化することは相当数となり現実的ではない。

また、顧問先側では、毎月などの単位で、前記手順（１）〜（４）を繰り返して、金融機関毎に異なるデータの並び方に注意しながら、取り込むデータの指定と定義をすることになるため、出納帳形式のソフトウェアの使用経験が浅い者や、簿記の知識などが不十分な者にとっては、取り込むデータを間違えてしまうという問題も発生する。

例えば、特許文献１のように、ウィザード形式により取り込むデータの指定や定義を行なうことも可能であるが、取込もうとするデータを一覧表示で確認しながら項目の定義や取込む項目の指定を行なうことができず、取込もうとするデータとは別枠のウィザード表示の中で、データの指定や定義を行なう関係で、間違いが生じやすいという問題がある。

また、前記手順（１）〜手順（４）の操作が減るわけではなく、逆に、操作に慣れている者にとっては操作の手間が増えるのみであり、多くの操作が発生するという問題がある。

また、金融機関からのデータ取込みに関しては、既に取込み済みとなったデータを、再度ユーザーが指定すれば重複して取り込みができてしまうため、二重処理の発生などの問題がある

例えば、特許文献２のように、オンラインバンキングと会計処理システムを組合せて、ネットワーク経由で金融機関からのデータを取込み、会計処理システムへ反映する仕組みついては、システム全体が複雑化し、各種の設定作業が煩雑となるため、高価なシステムになる、そのため小規模の企業などにおける経理用途には不向きであるという問題がある。

例えば、特許文献３のように、一定のフォーマットに変換する方法は、事前に日本国内にある、全ての金融機関（都市銀行、地方銀行、信用金庫、農協など）のフォーマットが統一されていないため、ソフトウェアを開発提供するメーカーが、事前に調査して準備しておかなくては対応ができないし、金融機関のフォーマットに変更があった場合は、逐次対応しなくてはならないという問題がある。

銀行口座の取引データと他のデータを連動して仕訳を作成することに主眼があり、銀行口座の取引データがどのような形式で、取り込みをどのように行なうかについては課題としてあげられておらず、金融機関からの口座明細データ（ＣＳＶ形式やＸＭＬ形式等のデータを手動で取込場合も含む）を取込む場合には利用できない技術であった。

例えば、特許文献４のように、ファームバンキングデータを利用して、取引データに自動割付して、実仕訳伝票データを作成する方法は、自動割付によって、間違った科目などが割り付けられた場合に間違いに気付きにくく、最終的に会計処理を行う会計事務所にとっては、逆に確認作業が複雑化するという問題がある。

また、入力は伝票で行ない、入力したデータがファームバンキングの実データと照合されて、仕訳伝票の発行や資金繰管理などが行える、高度に自動化されたシステムを提供するものであり、特許文献２と同様に、システム全体が複雑化し、各種の設定作業が煩雑となるため、高価なシステムになる、そのため小規模の企業などにおける経理用途には不向きであるという問題がある。

上記のような問題に鑑み、本発明は、会計事務所の顧問先企業などで、会計ソフトを利用して、記帳入力を行なう場合に、出納帳形式等のソフトウェアの一部を構成する機能として、あるいは出納帳形式等のソフトウェアに対するアドオン機能ないし独立のソフトウェア機能を構成する技術として、取引のある金融機関（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）から提供される口座明細データを会計処理可能なデータ形式に取り込む時、バックグラウンドのデータ管理と、画面表示や入力補助などのユーザーインターフェースとの連携により、取り込むデータの指定や定義にかかる操作を簡略化し、更にデータの重複を低減する技術を提供することを目的とする。

すなわち、銀行毎にフォーマットが異なり、各項目のデータの意味づけが曖昧で、きちんと項目の設定をしないとうまく取り込めない性質がある金融機関からの口座明細データの取込みのための工夫であって、そのために、過去の入力済みデータや設定情報を管理して行なうデータ管理と連携した、簡単に間違いなく設定して取込むためのデータベースを用意して、金融機関毎に変わる（動的な）設定内容を登録して利用できるようにすることを目的とする。

また、金融機関からの口座明細データを取込む際には、過去に取込み済みのデータと重複して取込むおそれがあるので、過去の入力済みデータや設定情報を管理して行なうデータ管理と連携したユーザーインターフェース（ＧＵＩ）を工夫することで、一取引単位や月単位の重複取込みや、意図しない金融機関の口座明細データの取込みや、項目の設定の間違いを効果的に排除し、簡単に間違いなく取り込めるようなシステムを提供することを目的とする。

また、取り込んだ口座明細データを共通明細データとして格納し、共通明細データから口座明細データと同等の内容をＣＳＶ形式等の出力データとして出力を行なうことで、別の会計ソフトに取り込めるようにしたり、複数の口座の口座明細データをまとめて出力する事ができるので、作業の効率化をはかることができる。

第１の発明は、金融機関サーバーが管理する口座明細データにアクセスするための認証情報を用いて、前記金融機関サーバーから前記口座明細データと前記金融機関の情報を含む履歴情報を取得する取込処理部と、前記取込処理部が取得した前記口座明細データと前記履歴情報から構成される共通明細データとして管理するデータ管理部と、前記共通明細データを格納する取込データ格納部と、を備え、前記取込処理部は取得した金融機関毎に一意となる口座明細データの項目が前記共通明細データの項目と一致する項目が存在するか判定を行い、存在する場合はそのまま前記口座明細データと前記履歴情報を前記共通明細データに取込み、存在しない場合は前記共通明細データの項目に前記口座明細データの項目を追加する登録処理を行ない、前記口座明細データと前記履歴情報を前記共通明細データに取込み、前記共通明細データの項目で前記口座明細データの項目と一致しない項目に特定識別子をデータとして設定する、情報処理装置である。
第２の発明は、前記取込処理部は取得した金融機関毎に一意となる口座明細データの項目が前記共通明細データの項目と一致する項目が存在する場合に、取得した前記金融機関の最新の前記共通明細データと口座明細データ及び前記履歴情報を比較し、比較結果が特定識別子以外のデータが一致するときは、口座明細データと前記履歴情報取込済みと判定して重複して取込むことを防止する、請求項１に記載の情報処理装置である。
第３の発明は、ユーザーの入力を受付ける入力部、指定した金融機関の口座明細データを含む出力データを格納する作成データ格納部と、を備え、前記入力部は、出力する金融機関の指定を受付け、前記データ管理部は前記共通明細データから前記入力部により指定された金融機関の共通明細データを抽出し、抽出した共通明細データからデータが特定識別子である前記共通明細データの項目を除外した前記共通明細データの項目のみのデータを前記出力データとして出力する、請求項１または２に記載の情報処理装置である。
第４の発明は、データ集約ルールをまとめた集約設定を格納する管理データ格納部と、を備え、前記データ管理部は前記登録処理の際に合わせて追加する前記口座明細データの項目の集約設定を行なう、請求項１または２に記載の情報処理装置。
第５の発明は、前記共通明細データを元に前記データ集約ルールを適用して作成した取引データを作成データ格納部に格納する、請求項４に記載の情報処理装置である。
第６の発明は、自動仕訳処理を行なう仕訳処理部と、を備え、前記仕訳処理部は前記取引データに対して自動仕訳処理を実行して作成した仕訳データを作成データ格納部に格納する、請求項５に記載の情報処理装置である。
第７の発明は、コンピュータを、請求項１から６のいずれか一項に記載の情報処理装置として機能させるためのプログラムである。

本発明では、ユーザー側では、出納帳形式のソフトウェアに金融機関からの口座明細データを加工等することなくそのまま取込こむことで、金融機関毎に異なるデータの並び方の違いを原因とする、口座明細データの取り込みミスや加工等のデータ処理の手間を省くことができ、口座明細データの重複登録も防止することができる。

また、ユーザーが手動で金融機関から提供される口座明細データを出納帳形式のソフトウェアにデータを取り込む場合は口座ごとに口座明細データを取り込む必要があったのに対し、一度口座明細データを取り込んでから複数の口座をまとめて口座明細データとしてＣＳＶ形式等のデータを出力することにより、随時、柔軟な対応が可能となり利便性が向上する。

また、出納帳形式のソフトウェアを開発提供するメーカーにおいては、全国にある金融機関毎のフォーマットを事前に調べて準備やフォーマット変更の対応などの作業負担が低減されシンプルなソフトウェアとすることで、手ごろな価格でユーザーへの提供が可能となる。

また、ユーザー側では、出納帳形式のソフトウェアに口座明細データをそのまま取込こみ、取り込んだ口座明細データを集約する際に金融機関毎に異なるデータの並び方の違いをデータの指定や定義を、データ管理と連携したＧＵＩを利用して簡略することで、簡単に仕訳に必要な情報（取引データ）を作成できる。

また、さらに過去の処理時に作成したルールに基づいて処理することで、顧問先において出納帳形式のソフトウェアの使用経験が浅い者や、簿記の知識などが不十分な者でも、より少ない操作で、会計処理可能なデータ形式へ取り込むことが可能となり、操作が簡略化され、仕訳を自動作成することができる。

ユーザー側で仕訳を自動作成することで、最終的な仕訳の確認作業を会計事務所へ任せることになるので、会計事務所側の判断で的確な仕訳が行なわれることになるので、会計事務所の確認作業が軽減される。

図１は、本発明にかかる会計処理システムの構成を示す図である。 図２−１は、本発明にかかる会計処理システムにおける端末のハードウェア構成を示す図である。 図２−２は、本発明にかかる会計処理システムにおける管理装置のハードウェア構成を示す図である。 図３は、本発明にかかる全体フローを示す図である。 図４−１は、口座連携設定を説明する図である。 図４−２は、金融機関設定を説明する図である。 図４−３−１は、口座１の口座明細データを説明する図である。 図４−３−２は、口座２の口座明細データを説明する図である。 図４−３−３は、口座３の口座明細データを説明する図である。 図４−４は、共通口座明細データを説明する図である。 図４−５は、明細区分設定を説明する図である。 図４−６は、明細集約設定を説明する図である。 図４−７は、項目設定画面を説明する図である。 図４−８は、取引データを説明する図である。 図５−１は、顧客（個人）情報照会のデータ構造を説明する図である。 図５−２は、顧客（法人）情報照会のデータ構造を説明する図である。 図５−３は、残高情報照会のデータ構造を説明する図である。 図５−４は、入出金明細情報照会のデータ構造を説明する図である。 図５−５は、振込入金明細情報照会のデータ構造を説明する図である。 図５−６は、総合振込依頼情報照会のデータ構造を説明する図である。 図５−７は、口座振替結果情報照会のデータ構造を説明する図である。 図５−８は、口座振替手数料情報照会のデータ構造を説明する図である。 図５−９は、給与・賞与振込依頼情報照会のデータ構造を説明する図である。 図５−１０は、口座振替依頼情報照会のデータ構造を説明する図である。 図５−１１は、振込振替依頼情報照会のデータ構造を説明する図である。

［１］全体概要
最初に図３を参照して、本発明の会計処理装置における情報や処理の流れの全体概要を説明する。

例えばある金融機関（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）からの口座明細データを処理する場合、顧問先等が端末１００において、ユーザーは先ず出納帳形式のソフトウェアを起動して（Ｓ３−１−１）、銀行明細取込（機能）を選択（実行）し（Ｓ３−１−２）、取得する期間と処理対象となる金融機関の金融機関名と（図４−２）と口座番号を指定して（Ｓ３−１−３）、取得する明細の種類（図４−７）を指定する（Ｓ３−１−４）。

指定した金融機関の金融機関名と口座番号と明細データの種類を元に、後述する口座連携設定（図４−１）に基づいて各金融機関のサーバー３００に接続し、認証処理を行い（Ｓ３−１−５）、各金融機関から選択された口座明細データ（図４−３−１〜図４−３−３）をインターネット等で入手して取得した口座明細データと履歴情報に金融機関の「金融機関ＩＤ」と「口座番号」と「区分」を追加した上で共通明細データ（図４−６）を作成する。

作成した共通明細データと一致する登録済みのデータがないか検索し、一致する共通明細データがあるときは、一致する共通明細データを除いた共通明細データ（取得した共通明細データのうち検索でヒットしなかった共通明細データ）を装置内部の記憶領域または、外部記憶装置にある共通明細ＤＢ（図示せず）に登録する（Ｓ３−１−６）。

顧問先が自計化している場合（Ｓ３−１−７：Ｙｅｓ）は、そのまま仕訳を作成するので、仕訳を作成するための集計期間を設定する（Ｓ３−１−９）。
設定した集計期間の共通明細データを抽出し、明細集約設定（図４−６）に基づき集約処理を行い、取引データ（図４−８）を作成して、装置内部の記憶領域または、外部記憶装置にある取引ＤＢ（図示せず）に登録する（Ｓ３−１−１０）。

Ｓ３−１−１０で作成した取引データに対して自動仕訳処理を実行し仕訳データを作成し、装置内部の記憶領域または、外部記憶装置にある仕訳ＤＢ（図示せず）に登録する（Ｓ３−１−１１）。なお、取引データを会計事務所等にある管理装置２００に送信し、管理装置２００で仕訳を作成してもよい。

顧問先が自計化していない場合し（Ｓ３−１−７：Ｎｏ）は、共通明細データから出力データ（図示せず）を作成する（Ｓ３−１−８）。作成した出力データを会計事務所等にある管理装置２００に送信し、管理装置２００で出力データを取り込み、仕訳データを作成する。なお、出力データは汎用的な形式のデータであるＣＳＶ形式やＸＭＬ形式等を指す。

［２］詳細について
図１は、システム構成を簡略化して示した図であり、ここでは、顧問先等にある（会計処理）端末１００と会計事務所等にある管理装置２００と金融機関のサーバー３００がインターネットなどのネットワークを介して接続されている例を示すものである。

図２−１は、（会計処理）端末１００のハードウェア構成をブロック単位で、示した図であり、大きな単位で、入力部１１０、表示部１２０、制御部１３０、記憶部１４０、通信部１５０から構成される。

図２−２は、管理装置２００のハードウェア構成をブロック単位で、示した図であり、大きな単位で、入力部２１０、表示部２２０、制御部２３０、記憶部２４０、通信部１５０から構成される。

入力部１１０又は２１０は、ユーザーからの一次的な操作を、制御部へ伝える手段であり、一般的にはキーボード、マウス等が該当し、タッチパネルなどであっても良い。

表示部１２０又は２２０はＬＣＤやＣＲＴ等である。また、通信部１５０又は２５０はＬＡＮアダプタなどが該当し、ローカルにてネットワーク接続されたサーバーや、インターネット接続するための機能であり、出力データや取引データを管理装置に送信する。

制御部１３０又は、ＣＰＵと記憶部１４０にロードされたプログラムによって端末装置内の制御をおこなう機能部であり、各種の制御をユーザーの操作に基づいた操作により、データの読出し、保存、変換や共通明細データを集約して取引データの作成などを行なうデータ管理部１３１、取引データに対して自動仕訳処理を行なう仕訳処理部１３２、金融機関から口座明細データと履歴情報を取り込んで共通明細データを作成する取込処理部１３３を有する。

制御部２３０は、ＣＰＵと記憶部２４０にロードされたプログラムによって端末装置内の制御をおこなう機能部であり、各種の制御をユーザーの操作に基づいた操作により、データの読出し、保存、データの取り込みや変換などを行なうデータ管理部２３１、取引データに対して仕訳処理を行なう仕訳処理部２３２、を有する。 各部の働き（機能）の詳細については後述する。

記憶部１４０は、ハードディスクやＳＳＤなどの記憶装置が該当し、データ管理や設定等を格納する管理データ格納部１４１、金融機関から取得した口座明細データや共通明細データを格納する明細ＤＢ（図示せず）のある取込データ格納部１４３、口座明細データを出納帳形式等のデータに変換した出力データを登録する出力ＤＢ（図示せず）や共通明細データを集約した取引データを登録する取引ＤＢ（図示せず）や取引データから作成した仕訳データ登録する仕訳ＤＢ（図示せず）を格納する作成データ格納部１４２を有する。

また、記憶部２４０は、ハードディスクやＳＳＤなどの記憶装置が該当し、データ管理や設定等を格納する管理データ格納部２４１、作成した仕訳データ登録する仕訳ＤＢ（図示せず）を格納する作成データ格納部２４２と、端末から受信した出力データや取引データや仕訳データを格納する受付データ格納部２４３を有する。

受付データ格納部に端末からの仕訳データを格納した場合は、仕訳データの確認をした上で、作成データ格納部１４２にある仕訳ＤＢ（図示せず）に登録される。なお、記憶部に格納されるデータ、データやテーブルについては後述する。 ここでは、（会計処理）端末はスタンドアローンPCとしたが、クラウドサービスを利用して、記憶部を外部ストレージ（サーバーを含む）等へ設けて、シンクライアントとして、タブレット端末などを利用しても良い。

図４−１は顧問先等が管理する複数の金融機関に関する口座情報と認証に必要な情報をまとめた口座連携設定で、「金融機関ＩＤ」と「口座番号」と「口座名」と「預金種類」と「ユーザーＩＤ」と「パスワード」等の項目からなり、管理データ格納部１４１に格納される。金融機関ＩＤは後述する金融機関設定（図４−２）で設定される。口座番号は銀行等の金融機関に開設している口座の番号であり、口座名は口座の名義である。

また、預金種類は普通（預金）や定期（預金）や当座（預金）等の預金の種類である。また、ユーザーＩＤとパスワードは金融機関のサーバーに接続する際の認証に使用される。なお、ユーザーＩＤとパスワードは口座連携設定画面のみで設定可能である。口座番号と口座名と預金種類は後述する金融機関設定画面でも使用される。

図４−２は銀行等の金融機関（証券会社や保険会社やクレジットカード会社等のノンバンクを含む）の設定をまとめた金融機関設定（図４−２）で、「金融機関ＩＤ」と「金融機関名」の項目からなり、管理データ格納部１４１に格納される。金融機関名とは後述する金融機関設定画面でも使用される。

図４−３−１から図４−３−３は各金融機関から取得する口座明細データであり、各金融機関で口座明細データのデータフォーマット形式（口座明細データの項目）が異なる。例えば、図４−３−１はＡ銀行の○○支店の普通預金の口座番号２５８４６３３（口座１）の口座明細データであり、図４−３−２はＡ銀行の○○支店の普通預金の口座番号２５８４６３８（口座２）の口座明細データでいずれも「照会番号」、「取引日」、「摘要」、「お支払金額」、「お預り金額」、「残高」の項目からなり、履歴情報と一緒に取込データ格納部１４３に格納される。

また、図４−３−３はＢ銀行○△支店の普通預金の口座番号１２３４６６７（口座３）の口座明細データで「取引日」、「取引内容」、「お引き出し」、「お預入れ」の項目からなり、履歴情報と一緒に取込データ格納部１４３に格納される。

図４−４は金融機関の口座明細データと履歴情報を取り込んで端末に保存したデータである共通明細データである。共通明細データは口座明細データ部分と履歴情報部分と独自部分の３つのデータ構成からなる。

端末に取り込んだ口座明細データの項目（口座明細データ部分）と金融機関のサーバー３００から取得した履歴情報である「金融機関ＩＤ」と「口座番号」と「区分」と「明細取得日」（図示せず）と「取得日残高」（図示せず）の項目（履歴情報部分）と「明細ＩＤ」、「出力フラグ」（図示せず）の項目（独自部分）を追加して共通明細データを作成し、取込データ格納部１４３にある共通明細ＤＢ（図示せず）に保存される。

共通明細データは取り込んだ口座明細データと履歴情報をそれぞれ口座明細データ部分と履歴情報部分にそのまま取り込むことで、口座明細データの取込時の項目の設定の間違いや変換ミス等を防止することができる。

口座明細データは金融機関毎に口座明細データのデータフォーマット形式（口座明細データの項目）が異なるため、共通明細データの口座明細データ部分のうち、取り込み対象でない金融機関の口座明細データの項目については口座明細データでないデータであることを特定する識別子「ＮＯＮＥ」を値として保存することで、各金融機関の口座明細データのデータフォーマット形式を金融機関毎に管理できるので、共通明細データから識別子「ＮＯＮＥ」のデータを除外したデータを出力データとすることで各金融機関の口座明細データを出力することができる。

「明細ＩＤ」は連番で発行されるユニークな数字であり、「区分」は後述する明細区分設定で設定される口座明細データの種類であり、「金融機関ＩＤ」は金融機関設定で設定される金融機関であり、「口座番号」は取得する口座明細データの口座番号である。「出力フラグ」（図示せず）は出力データを作成したかを示すフラグ（ＯＮ（出力データを作成済）が「１」、ＯＦＦ（出力データを未作成）が「０」）で、共通明細データが重複して出力されるのを防止するために利用される。

「明細取得日」（図示せず）は金融機関のサーバー３００から口座明細データを取得した日であり、「取得日残高」（図示せず）は金融機関のサーバー３００から口座明細データを取得した日の現在の残高である。なお、必要に応じて「預金種類」、「口座名」等も追加してもよい。

具体的には、端末にＡ銀行の普通預金の口座明細データが取り込まれた状態で、新たにＢ銀行の普通預金の口座明細データを取り込んだ場合を説明する。現在の共通明細データは「明細ＩＤ」、「区分」、「金融機関ＩＤ」、「口座番号」、「照会番号」、「取引日」、「摘要」、「お支払金額」、「お預り金額」の項目からなり、Ａ銀行の普通預金の口座明細データの項目に「明細ＩＤ」、「区分」、「金融機関ＩＤ」、「口座番号」、「出力フラグ」（図示せず）の項目が追加されている。

次に、Ｂ銀行の普通預金の口座明細データを取り込んだ際に、口座明細データの項目が共通明細データと一致する項目と一致する項目があるか検索し、一致する項目（項目１）についてはその項目をそのまま利用し、一致しない項目のうち既存の共通明細データの項目に存在しない項目（項目２）については、共通明細データの新しい項目として追加し、一致しない項目のうち既存の共通明細データの項目に既に存在する項目（項目３）については、その項目をそのまま利用する。

本実施例では、項目１に該当するのは「取引日」の項目のみであり、項目２に該当するのは「取引内容」、「お引き出し」、「お預入れ」の項目であり、項目３に該当するのは「摘要」、「お支払金額」、「お預り金額」、「残高」の項目である。なお、項目２の新しい項目の追加方法については後述する。

図４−５は金融機関で実行する処理内容と取得する口座明細データの種類を設定する明細区分設定で、「区分」と「口座明細データの種類」と「処理内容」の項目からなる。「区分」は取得する「口座明細データの種類」と金融機関で実行する「処理内容」の関連付けを行い、口座明細データの種類を設定するための明細区分設定画面（図示せず）で取得したい「口座明細データの種類」を選択すると、関連付けられた区分が設定される。なお、明細区分設定は金融機関のサーバー３００にも設定情報として保存されている。

図４−６は後述する集約ルールの設定である明細集約設定で、「集約元」と「集約先」の項目からなる。「集約元」は共通明細データの項目が設定され、「集約先」は取引データの項目名が設定される。具体的には、集約元が取引日、年月日等の日付に関するデータである場合は集約先を日付にすることで、日付の項目にデータを集約することができる。

図４−７は項目２（口座明細データの項目が共通明細データと一致しない項目のうち既存の共通明細データの項目に存在しない項目）を設定するための項目設定画面であり、項目設定画面で設定を行なうことで、共通明細データの項目名（図４―４）と明細集約設定（図４−６）を追加する項目毎に設定する。

具体的には、項目設定画面で追加する項目として項目名称１の集約元に「取引内容」、「お引き出し」、「お預入れ」の項目が表示され、集約先に「摘要」、「引出」、「預入」、「残高」等を設定することで、集約元の異なる項目名で同じ内容のデータを集約先の項目に集約（集約ルールの適用）することができるので、各金融機関の口座明細データの項目名の違いを吸収できる。

図４−８は共通明細データに集約ルールを適用して作成する取引データで、取引データは口座明細データ共通部分をと履歴情報部分と独自部分の３つのデータ構成からなる。

集約ルールは各金融機関の口座明細データの項目名を共通のデータ内容の項目名に集約するための設定である。集約ルールは共通明細データから取引データを作成するために用いられる。

集約ルールを適用する処理として３つあり、口座明細データ部分（共通明細データ）から口座明細データ共通部分（取引データ）を作成する処理（集約処理）と履歴情報部分の作成処理と項目名「残高」が口座明細データに存在しない場合に「残高」の金額を算出する処理（算出処理）がある。

履歴情報部分の作成処理は取引データの履歴情報部分に共通明細データの履歴情報部分のデータをそのまま保存する。

集約処理は、共通明細データの項目名である「集約元」と取引データの項目名である「集約先」の対応関係を設定する（明細）集約設定を参照して、共通明細データの口座明細データ部分の金融機関毎の独自の項目名である「集約元」を共通のデータ内容（「日付」、「摘要」、「引出」、「預入」等）の項目名である「集約先」に集約した口座明細データの集約データを作成し、作成した集約データを取引データの口座明細データ共通部分のデータとして保存される。

共通明細データの項目名「残高」の値として、「ＮＯＮＥ」と「ＮＵＬＬ」と「（残高金額）」の３種類が考えられる。値が「（残高金額）」の場合は、共通明細データ項目名「残高」の値を取引データの項目名「残高」として保存する。

値が「ＮＯＮＥ」と「ＮＵＬＬ」の場合（算出処理）は、金融機関毎の共通明細データを抽出した上で、「取得日残高」から抽出した共通明細データの「引出」に該当する項目（以下「口座明細引出」とする）と「預入」に該当する項目（以下「口座明細預入」とする）を加減算することで取引データの項目名「残高」を算出する。

抽出した共通明細データが複数ある場合は、抽出した共通明細データの数から処理対象の共通明細データの数を引いた数（算出処理が未処理の抽出済みの共通明細データの数）だけ「口座明細引出」と「口座明細預入」の加減算処理を繰り返す。

共通明細データの口座明細データ部分の「日付」に該当する項目（以下「口座明細日付」とする）と履歴情報の項目名「明細取得日」（図示せず）と項目名「取得日残高」（図示せず）を取得し、「口座明細日付」と「明細取得日」の値を比較する。

「口座明細日付」と「明細取得日」の比較結果が口座明細日付の方が明細取得日より前の日付（口座明細日付＜明細取得日）の場合と口座明細日付の方が明細取得日より後の日付（口座明細日付＞明細取得日）の場合の２種類が考えられる。

「口座明細日付＜明細取得日」の場合は「残高」＝「取得日残高」＋「口座明細引出」−「口座明細預入」の式で残高金額を算出することができる。

「口座明細日付＞明細取得日」の場合は「残高」＝「取得日残高」＋「口座明細預入」−「口座明細引出」の式で残高金額を算出することができる。

値が「ＮＯＮＥ」と「ＮＵＬＬ」の場合（算出処理）は上記の式で算出した残高金額を取引データの項目名「残高」として保存する。

取引データは「日付」、「摘要」、「引出」、「預入」、「残高」の項目名（口座明細データ共通部分）と「金融機関ＩＤ」、「口座番号」、「明細取得日」（図示せず）、「取得日残高」（図示せず）の項目名（履歴情報部分）と「取引ＩＤ」、「備考」（図示せず）の項目名（独自部分）からなる。取引データは自動仕訳処理をする際に使用される。

「取引ＩＤ」は連番で発行されるユニークな数字であり、「日付」は取引日等の口座の日付に関するデータであり、「摘要」は取引内容等の口座での取引に関するデータであり、「引出」は引き出し等の口座からの出金に関するデータであり、「預入」は預入れ等の口座への入金に関するデータであり、「残高」は口座の残高に関するデータである。

「明細取得日」（図示せず）は金融機関のサーバー３００から口座明細データを取得した日であり、「取得日残高」（図示せず）は金融機関のサーバー３００から口座明細データを取得した日の現在の残高である。「備考」（図示せず）は口座明細データの種類等の「摘要」を補足する情報で仕訳データを作成するときに利用される。

明細区分設定（図４−５）で設定している口座明細データの種類のデータ構造（項目名を含む）の一例を図５−１から図５−１２に示す。各口座明細データのフォーマット構造は金融機関に照会する項目をまとめたものであり、金融機関毎に異なっているため、Ａ銀行の口座明細データの種類のデータ構造を例に説明する。

顧客（個人）情報データのデータ構造（図５−１）は「顧客コード」、「支店名」、「口座数」、「預金種類」、「口座番号」、「口座名」、「振込依頼先」等の項目名からなり、ユーザーが個人の場合でＡ銀行へ顧客（個人）情報照会により取得するユーザーの顧客（個人）情報データの内容（ユーザーがＡ銀行で持っている口座情報等）である。なお、顧客コード等のデータ構造の項目名（照会項目）はＡ銀行が管理しているデータの項目名である。

顧客（法人）情報データのデータ構造（図５−２）は「顧客コード」、「承認者」、「承認金額」、「依頼者」、「取引限度額」、「手数料（負担区分）」等の項目名からなり、ユーザーが法人の場合でＡ銀行へ顧客（法人）情報照会により取得するユーザーの顧客（法人）情報データの内容（ユーザーがＡ銀行で持っている手数料や承認等に関する口座情報等）である。

残高情報データのデータ構造（図５−３）は「顧客コード」、「支店名」、「口座数」、「預金種類」、「口座番号」、「照会日時」、「照会日」、「照会時刻」、「残高（現在）」、「残高（支払可能額）」、「残高（前月末）」、「残高（前日）」、「通貨種類」等の項目名からなり、Ａ銀行へ残高情報照会により取得するユーザーの残高情報データの内容である。

入出金明細データのデータ構造（図５−４）は「顧客コード」、「金融機関名」、「支店名」、「口座数」、「預金種類」、「口座番号」、「照会日」、「照会時刻」、「照会情報結果」、「明細情報件数」、「摘要」、「取引日」、「取引額」、「お支払金額」、「お預り金額」、「残高」、「残高（取引前）」等の項目名からなり、Ａ銀行へ入出金明細情報照会により取得するユーザーの入出金明細データの内容である。

入出金明細データの項目「摘要」、「取引日」、「取引額」、「お支払金額」、「お預り金額」、「残高」については、口座明細データとして取得される（図４−３−１、図４−３−２）。また、入出金明細データの項目名「顧客コード」、「金融機関名」、「支店名」、「口座数」、「預金種類」、「口座番号」、「照会日」、「照会時刻」、「照会情報結果」、「明細情報件数」、「残高（取引前）」は履歴情報として取得され、項目名「金融機関名」、「支店名」のデータから金融機関設定を参照して「金融機関ＩＤ」を取得し、「照会日」のデータを「明細取得日」（図示せず）として取得し、「残高（取引前）」のデータを「取得日残高」（図示せず）として取得し、共通明細データの履歴情報部分のデータを作成する。説明では履歴情報の一部しか使用していないが、口座数や預金種類等の履歴情報も履歴情報部分に含まれていてもよい。なお、入出金明細データ以外の口座明細データの場合も同様の方法で履歴情報部分のデータを作成する。

振込入金明細データのデータ構造（図５−５）は「顧客コード」、「金融機関名」、「支店名」、「口座数」、「預金種類」、「口座番号」、「照会日」、「照会時刻」、「照会情報結果」、「明細情報件数」、「取引日」、「振込依頼先」、「振込額」、「通貨種類」等の項目名からなり、Ａ銀行へ振込入金明細情報照会により取得するユーザーの振込入金明細データの内容である。

総合振込依頼情報データのデータ構造（図５−６）は「顧客コード」、「金融機関名」、「支店名」、「預金種類」、「口座番号」、「指定振込日」、「手数料（負担区分）」、「受取人」、「明細情報番号」、「取引コード」、「取引コード」、「取引内容」、「承認期限」、「振込額」、「振込額合計」、「手数料」、「手数料合計」等の項目名からなり、Ａ銀行へ総合振込依頼情報照会により取得するユーザーの総合振込依頼情報データの内容である。

口座振替結果情報データのデータ構造（図５−７）は「顧客コード」、「支店名」、「預金種類」、「対象期間（開始）」、「対象期間（終了）」、「照会情報結果」、「委託者」、「通貨種類」、「引落日」、「指定振込日」、「依頼数」、「手数料合計」、「手数料明細」、「合計数」、「合計額」、「振替済数」、「振替済額」、「振替不能数」、「振替不能額」等の項目名からなり、Ａ銀行へ口座振替結果情報照会により取得するユーザーの口座振替結果情報データの内容である。

口座振替手数料情報データのデータ構造（図５−８）は「顧客コード」、「支店名」、「預金種類」、「対象期間（開始）」、「対象期間（終了）」、「照会情報結果」、「委託者」、「通貨種類」、「依頼数」、「手数料合計」、「手数料明細」等の項目名からなり、Ａ銀行へ口座振替手数料情報照会により取得するユーザーの口座振替手数料情報データの内容である。

給与・賞与振込依頼情報データのデータ構造（図５−９）は「顧客コード」、「金融機関名」、「支店名」、「預金種類」、「口座番号」、「指定振込日」、「手数料（負担区分）」、「依頼者」、「受取人」、「明細情報番号」、「取引コード」、「取引内容」、「振込額」、「振込額合計」、「手数料」、「手数料合計」、「社員コード」、「部門コード」等の項目名からなり、Ａ銀行へ給与・賞与振込依頼情報照会により取得するユーザーの給与・賞与振込依頼情報データの内容である。

口座振替依頼情報データのデータ構造（図５−１０）は「顧客コード」、「金融機関名」、「支店名」、「預金種類」、「口座番号」、「引落日」、「手数料（負担区分）」、「受取人」、「明細情報番号」、「取引コード」、「取引内容」、「承認期限」、「引落額」、「引落額合計」、「手数料」、「手数料合計」等の項目名からなり、Ａ銀行へ口座振替依頼情報照会により取得するユーザーの給与・賞与振込依頼情報データの内容である。

振込振替依頼情報データのデータ構造（図５−１１）は「顧客コード」、「金融機関名」、「支店名」、「預金種類」、「口座番号」、「指定振込日」、「手数料（負担区分）」、「受取人」、「明細情報番号」、「取引コード」、「取引内容」、「承認期限」、「支払額」、「手数料」等の項目名からなり、Ａ銀行へ振込振替依頼情報照会により取得するユーザーの振込振替依頼情報データの内容である。

ここから、図３−１のフローチャートを利用して、処理全体について説明を行うが、処理中に利用されるデータテーブルや操作画面の表示などについても適宜、説明を加えながら進めることとする。

（会計処理）端末にて、ユーザーは出納帳形式のソフトウェアを起動して、預金出納帳のメニューを選択する（Ｓ３−１−１）。

預金出納帳のメニューを選択した後、銀行明細取込をクリックする（Ｓ３−１−２）。

次に期間設定画面（図示せず）が表示され、取得する対象期間として「２０１８年１２月１日〜２０１８年１２月３１日」を期間設定画面から指定し、口座連携設定（図４−１）と金融機関設定（図４−２）を元に金融機関設定画面（図示せず）が表示される。

取得対象となる金融機関として金融機関名「Ａ銀行」と「○○支店」と預金種類「普通預金」と口座番号「２５８４６３３」を画面から指定する（Ｓ３−１−３）。なお、期間設定画面や金融機関設定画面等を含む各種の設定画面についてはスクリーンスクレイピング等の技術で作成してブラウザ上で表示する形にしてもよい。

次に、明細区分設定（図４−７）を元に明細区分設定画面（図示せず）が表示され、取得する口座明細データの種類として「入出金明細データ」を指定する（Ｓ３−１−４）。明細区分設定画面で入出金明細データを指定した場合は、区分「１」が設定される。

なお、取り込むデータを年月日単位で指定するためのユーザーインターフェースを介して、処理対象年月を決定する。なお、この対象年月日は出納帳形式等（預金出納帳）のソフトウェアの機能として構成されていても良い。
また、指定する期間は年月日を例に説明しているが、年月までの指定でもよい。また、取得する金融機関は複数指定してもよいし、口座番号も複数指定してもよい。

銀行データ（図４−２）を参照して指定した金融機関の金融機関名とから口座連携設定（図４−１）を参照して口座番号と区分とに基づいて各金融機関のサーバー３００に接続し、認証処理を行い、各金融機関からインターネット等で入手する口座明細データ取得処理を行なう（Ｓ３−１−５）。取得した口座明細データに金融機関の金融機関ＩＤと預金種類と口座番号と区分を追加した上で共通明細データ（図４−６）を作成する。

具体的には、金融機関名「Ａ銀行」、「○○支店」、預金種類「普通預金」、口座番号「２５８４６３３」、区分「１」の情報を元に、ユーザーＩＤ「Ｕ０００００２」とパスワード「******」で認証処理により金融機関（Ａ銀行）のサーバーに接続して、区分「１」に該当する入出金明細に関する照会処理を行ない、預金種類「普通預金」、口座番号「２５８４６３３」の入出金明細データである口座明細データ１（照会番号「１４１１３０００１」、取引日「２０１８/１２/２」、摘要「現金入金」、お支払金額「ＮＵＬＬ」、お預り金額「５３，０００」、残高「３５０，０００」）、口座明細データ２（照会番号「１４１２０５０１２」、取引日「２０１８/１２/２５」、摘要「ローン返済」、お支払金額「１２０，０００」、お預り金額「ＮＵＬＬ」、残高「２３０，０００」）を取得する。なお、「ＮＵＬＬ」はデータが設定されていないことを示す。

また、認証処理について実施例ではパスワード認証で説明したが、ケルベロス認証方式、リバースプロキシ方式、エージェント方式、フェデレーション方式等を利用したシングルサインオン処理やサーバー型、クライアント型、ハイブリッド型等のアカウントアグリゲーション処理で行ってもよい。

また、端末で取得した口座明細データ１と口座明細データ２を取り込み、口座明細データ１と共通明細データの項目名を抽出し、抽出した口座明細データ１の項目名と抽出した共通明細データの項目名を比較し、一致するものがあるか判定する。

口座明細データ１と共通明細データの項目名が全て一致する場合（ケース１）についての共通明細データへの口座明細データ取込方法を説明する。なお、共通明細データの項目名が「照会番号」、「年月日」、「取引日」、「摘要」、「お支払金額」、「お預り金額」、「残高」、「明細取得日」（図示せず）、「取得日残高」（図示せず）とする。

口座明細データ１と一致する共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）がある場合は、既に取り込み済みのため、口座明細データ１は取り込まないことで、口座明細データ１の重複取込を防止することができる。

次に、口座明細データ２についても口座明細データ２のデータと一致する共通明細データがあるかを検索する。口座明細データ２と一致する共通明細データがない場合は、取り込みがまだのため、口座明細データ２を取り込んで、共通明細データ（明細ＩＤが「Ｍ０００７」のデータ）として保存する。

具体的には口座明細データ２を取り込むための共通明細データを新規作成し、項目名「明細ＩＤ」に発行したユニークな数字である「Ｍ０００７」の値を保存し、項目名「区分」、「金融機関ＩＤ」、「口座番号」に口座明細データ取得処理（Ｓ３−１−５）で使用した「１」、「Ｂ０００３」、「２５８４６３３」の値を保存する。口座明細データ取得処理（Ｓ３−１−５）で口座明細データとして取得した取得日と取得日の残高を共通明細データ（明細ＩＤ「Ｍ０００７」のデータ）の項目名「明細取得日」（図示せず）の値「２０１８/１２/３１」、「取得日残高」（図示せず）の値「２３０，０００」として保存する。

次に、口座明細データ２の項目名と一致する共通明細データ（明細ＩＤが「Ｍ０００７」のデータ）の項目名「照会番号」に対して「１４１２０５０１２」の値を共通明細ＤＢ（図示せず）に保存する。同様に口座明細データ２の項目名と一致する共通明細データ（明細ＩＤが「Ｍ０００７」のデータ）の項目名「取引日」、「摘要」、「お支払金額」、「お預り金額」、「残高」に対してそれぞれ「２０１８/１２/２５」、「ローン返済」、「１２０，０００」、「ＮＵＬＬ」、「２３０，０００」の値を共通明細ＤＢ保存する。口座明細データ２の項目名と一致しない共通明細データ（明細ＩＤが「Ｍ０００７」のデータ）の項目名「年月日」に対しては口座明細データでないデータであることを特定する識別子として「ＮＯＮＥ」の値を共通明細ＤＢ保存する。

口座明細データ１と共通明細データの項目名が一部一致又は全て一致しない場合（ケース２）についての共通明細データへの口座明細データ取込方法を説明する。なお、共通明細データの項目名が「照会番号」、「取引日」、「年月日」、「取引内容」、「お引き出し」、「お預入れ」、「残高」、「明細取得日」（図示せず）、「取得日残高」（図示せず）とする。

口座明細データ１と共通明細データの項目名が一致しないものがある場合は、はじめて取り込みを行なう口座明細データなので、共通明細データの項目名と一致しない口座明細データ１の項目名「摘要」、「お支払金額」、「お預入れ」を抽出し、項目設定画面（図４−７）を表示する。

項目設定画面の項目名称１の集約元に「摘要」、項目名称２の集約元に「お支払金額」、項目名称３の集約元に「お預入れ」が設定されているので、項目名称１の集約先に「２．摘要」、項目名称２の集約先に「３．引出」、項目名称３の集約先に「４．預入」をそれぞれ選択して登録ボタンを押すことで、項目名の設定がされる。

項目設定画面で項目名の設定することで、明細集約設定（図４−６）で今回登録された項目名「摘要」、「お支払金額」、「お預入れ」の集約元と集約先の設定と共通明細データの項目名に「摘要」、「お支払金額」、「お預入れ」が追加され、既存の共通明細データの項目名「摘要」、「お支払金額」、「お預入れ」にそれぞれ「ＮＯＮＥ」の値が追加されて、共通明細データが更新される。

作成した共通明細データと一致する登録済みのデータがないか検索し、一致する共通明細データがあるときは、一致する共通明細データを除いた共通明細データ（取得した共通明細データのうち検索でヒットしなかった共通明細データ）を装置内部の記憶領域または、外部記憶装置にある共通明細ＤＢ（図示せず）に登録する（Ｓ３−１−６）。

次に口座明細データ１を取り込んで、共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）として保存する。具体的には口座明細データ１を取り込むための共通明細データを新規作成し、項目名「明細ＩＤ」に発行したユニークな数字である「Ｍ０００２」の値を共通明細ＤＢに保存し、項目名「区分」、「金融機関ＩＤ」、「口座番号」に口座明細データ取得処理（Ｓ３−１−５）で使用した「１」、「Ｂ０００３」、「２５８４６３３」の値を共通明細ＤＢに保存する。

口座明細データ取得処理（Ｓ３−１−５）で口座明細データとして取得した取得日と取得日の残高を共通明細データ（明細ＩＤ「Ｍ０００２」のデータ）の項目名「明細取得日」（図示せず）の値「２０１８/１２/３１」、「取得日残高」（図示せず）の値「２３０，０００」として保存する。

次に、口座明細データ１の項目名と一致する共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）の項目名「照会番号」に対して「１４１１３０００１」の値を共通明細ＤＢに保存する。同様に口座明細データ２の項目名と一致する共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）の項目名「取引日」、「残高」に対してそれぞれ「２０１８/１２/２」、「３５０，０００」の値を共通明細ＤＢ保存する。

新たに共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）に追加した項目名「摘要」、「お支払金額」、「お預入れ」に対して、「現金入金」、「ＮＵＬＬ」、「５３，０００」の値を共通明細ＤＢ保存する。また、口座明細データ２の項目名と一致しない共通明細データ（明細ＩＤが「Ｍ０００２」のデータ）の項目名、「年月日」、「取引内容」、「お引き出し」、「お預入れ」に対してはそれぞれ「ＮＯＮＥ」の値を共通明細ＤＢ保存する。

このように、金融機関から取得した口座明細データをそのまま共通明細データに取り込むことができるので、取り込む際に項目名を変更したり、口座明細データを加工したり変換する等の処理を行なう必要がないので、口座明細データの取り込みミスや加工処理によるデータの誤り等を防止することができる。また、口座明細データをそのまま取り込むので、一致する共通明細データを確認するだけで、既に取り込み済みかどうかのチェックが簡単にできる。

ここまで、出納帳形式のソフトウェアに金融機関から提供される口座明細データを取り込むまでを説明した。顧問先が自計化している場合（Ｓ３−１−７：Ｙｅｓ）は、後述する手順に従って、仕訳データを作成する（Ｓ３−１−９〜Ｓ３−１−１１）。

顧問先が自計化している場合（Ｓ３−１−７：Ｙｅｓ）に仕訳を作成する手順について説明する。まずは、仕訳を作成するための集計期間を設定する（Ｓ３−１−９）。なお、集計期間は、年月日で指定してもよいし、１か月単位である年月で指定してもよい。

出納帳形式のソフトウェアの取り込まれた口座明細データは金融機関から提供される口座明細データのままなので、金融機関毎に口座明細データが異なっているので、日付、摘要、金額等の共通のデータ内容を集約しないと仕訳を作成することができない。

そこで、各金融機関の口座明細データに集約ルールを適用して仕訳を作成する取引データを作成する。

具体的には、指定した集計期間の共通明細データ（図４−４）を抽出し、明細集約設定（図４−６）を参照して共通のデータ内容ごとに集約ルールの適用を行い、取引データ（図４−８）を作成して、装置内部の記憶領域または、外部記憶装置にある取引ＤＢ（図示せず）に登録する（Ｓ３−１−１０）。

集計期間を「２０１８年１２月１日〜２０１８年１２月３１日」の期間で指定した場合を例に説明する。共通明細データから「２０１８年１２月１日〜２０１８年１２月３１日」の期間で抽出した共通明細データ（明細ＩＤ「Ｍ０００１」〜「Ｍ０００７」のデータ）を元に明細集約設定（図４−６）を参照して、取引データ（取引ＩＤ「Ｔ０００１」〜「Ｔ０００７」のデータ）を作成する。

抽出した共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）に対応する取引データ（取引ＩＤ「Ｔ０００１」のデータ）を新規作成し、項目名「取引ＩＤ」に発行したユニークな数字である「Ｔ０００１」の値を保存する。また、取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「区分」の値として共通明細データ（明細ＩＤ「Ｍ０００１」の項目名「区分」の値「１」を保存する。

取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「金融機関ＩＤ」の値として共通明細データ（明細ＩＤ「Ｍ０００１」の項目名「金融機関ＩＤ」の値「Ｂ０００３」の値を保存する。共通明細データ（明細ＩＤ「Ｍ０００１」の項目名「口座番号」の値「１２３４６６７」の値を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「口座番号」の値として保存する。

次に共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「取引日」の値「ＮＯＮＥ」と項目名「年月日」の値「２０１８/１２/１」と２つあるが、項目名「取引日」の値が「ＮＯＮＥ」の場合は何も処理はしない。項目名「年月日」の値「２０１８/１２/１」は「ＮＯＮＥ」以外の値であるため、項目名「年月日」の値「２０１８/１２/１」を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「日付」の値として保存する。

次に共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「摘要」の値「ＮＯＮＥ」と項目名「取引内容」の値「現金入金」と２つあるが、項目名「摘要」の値が「ＮＯＮＥ」の場合は何も処理はしない。項目名「取引内容」の値「現金入金」は「ＮＯＮＥ」以外の値であるため、項目名「取引内容」の値「現金入金」を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「摘要」の値として保存する。

次に共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「お支払金額」の値「ＮＯＮＥ」と項目名「お引き出し」の値「ＮＵＬＬ」と２つあるが、項目名「お支払金額」の値が「ＮＯＮＥ」の場合は何も処理はしない。項目名「お引き出し」の値「ＮＵＬＬ」は「ＮＯＮＥ」以外の値であるため、項目名「お引き出し」の値「ＮＵＬＬ」を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「引出」の値として保存する。

次に共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「お預り金額」の値「ＮＯＮＥ」となっているが、項目名「お預入れ」の値「５０，０００」と２つあるが、項目名「お預り金額」の値が「ＮＯＮＥ」の場合は何も処理はしない。項目名「お預入れ」の値「５０，０００」は「ＮＯＮＥ」以外の値であるため、項目名「取引内容」の値「５０，０００」を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「預入」の値として保存する。

取引データの項目名「残高」については、他の項目名と処理が異なるため、詳しく説明する。共通明細データの項目名「残高」の値として、「ＮＯＮＥ」と「ＮＵＬＬ」と「（残高金額）」の３種類が考えられる。「（残高金額）」の場合、例えば共通明細データの項目名「残高」が「２３０，０００」の値のときは、共通明細データの項目名「残高」の値である「２３０，０００」を取引データの項目名「残高」として保存する。

次に、「ＮＯＮＥ」と「ＮＵＬＬ」の場合は、「明細取得日」（図示せず）と「取得日残高」（図示せず）の値を元に「残高」の値を算出する。
具体的には共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「残高」の値「ＮＯＮＥ」となっているので、共通明細データの項目名「年月日」の値「２０１８/１２/１」、項目名「口座番号」の値「１２３４６６７」、項目名項目名「明細取得日」（図示せず）の値「２０１８/１２/２０」、「取得日残高」（図示せず）の値「１５０，７５０」を取得する。

年月日「２０１８/１２/１」と明細取得日「２０１８/１２/２０」の期間で
口座番号「１２３４６６７」と一致する共通明細データを抽出する。
抽出した共通明細データ（（明細ＩＤ「Ｍ０００１」と「Ｍ０００３」と「Ｍ０００５」のデータ））のうち、共通明細データ（明細ＩＤ「Ｍ０００３」と「Ｍ０００５」のデータ）の項目名「お預入れ」（「預入」に該当する項目）の値「２００，０００」と項目名「お引き出し」（「引出」に該当する項目）の値「ＮＵＬＬ」を読み出す。

年月日「２０１８/１２/１」の方が明細取得日「２０１８/１２/２０」より前（年月日＜明細取得日）なので、残高算出の式（「残高」＝「取得日残高」＋「引出」−「預入」）で算出する。「引出」又は「預入」の値が「ＮＵＬＬ」の場合は計算処理をスキップして処理する。

よって、算出する「残高」は残高算出の式（「残高」（取引ＩＤ「Ｍ０００１」）＝「取得日残高」（明細ＩＤ「Ｍ０００１」）＋「お引き出し」（明細ＩＤ「Ｍ０００３」と明細ＩＤ「Ｍ０００５」）−「お預入れ」（明細ＩＤ「Ｍ０００３」と明細ＩＤ「Ｍ０００５」）＝「１５０，７５０」＋「ＮＵＬＬ」＋「９９，２５０」−「２００，０００」−「ＮＵＬＬ」＝「５０，０００」）より「５０，０００」となるので、算出した「残高」の値「５０，０００」を取引データの項目名「残高」として保存する。

次に共通明細データ（明細ＩＤ「Ｍ０００１」のデータ）の項目名「区分」の値「１」から明細区分設定（図４−５）を参照して口座明細データの種類の値「入出金明細データ」を取得し、取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「備考」（図示せず）の値として「入出金明細データ」を保存する。

次に共通明細データの項目名「明細取得日」（図示せず）の値「２０１８/１２/２０」、「取得日残高」（図示せず）の値「１５０，７５０」を取引データ（取引ＩＤ「Ｔ０００１」のデータ）の項目名「明細取得日」（図示せず）、「取得日残高」（図示せず）それぞれの値として保存する。

同様に、取引データ（取引ＩＤ「Ｔ０００２」〜「Ｔ０００７」のデータ）についても、共通明細データ（明細ＩＤ「Ｍ０００２」〜「Ｍ０００７」のデータ）を元に段落００７１から段落００７１の処理を行うことで作成する。なお、通信部１５０は取引データを会計事務所等にある管理装置２００に送信し、管理装置２００で仕訳を作成してもよい。

Ｓ３−１−１０で作成した取引データ（図４−８）に対して自動仕訳処理を実行し仕訳データを作成し、装置内部の記憶領域（作成データ格納部１４２）または、外部記憶装置にある仕訳ＤＢ（図示せず）に登録する（Ｓ３−１−１１）。端末１００は取引データの項目名「摘要」と「備考」を参照して公知の任意の自動仕訳技術を用いて自動仕訳処理を実行してもよい。例えば、過去の仕訳内容を利用したものや辞書を用いたものや推論又はルールベースの自動仕訳技術を用いて、自動仕訳処理を実行してもよい。

また、顧問先が自計化していない場合（Ｓ３−１−７：Ｎｏ）は、共通明細データから出力データ（ＣＳＶやＸＭＬ等）を作成する（Ｓ３−１−８）。例えば、同じ金融機関でユーザーが仕事と家庭で別に口座を開設している場合や家族が従業員で別々に口座を開設している場合に、まとめて口座明細データを出力できれば、会計事務所等にある管理装置２００に出力データを送付するだけ済む。そのため、口座毎の口座明細データを出力して送付しなくて済むので、口座明細データの送付し忘れや誤送付等を防止することができる。

具体的には、預金出納帳のメニューを選択した後、銀行明細出力をクリックすることで、銀行明細出力が表示され（図示せず）、出力する「金融機関名」、「」、「口座番号」（指定しなくてもよい）、「口座明細データの種類」、「対象期間」のいくつかの条件を指定する。なお、対象期間は、年月日で指定してもよいし、１か月単位である年月で指定してもよい。

例えば、金融機関名「Ａ銀行」、「○○支店」、明細データの種類「入出金明細データ」、対象期間「２０１８年１２月」とした場合は、金融機関ＩＤ「Ｂ０００３」、区分「１」と出力フラグ「０」を条件として一致する共通明細データから「２０１８年１２月１日〜２０１８年１２月３１日」の期間の共通明細データ（明細ＩＤ「Ｍ０００２」、「Ｍ０００４」、「Ｍ０００６」及び「Ｍ０００７」のデータ）を抽出する。

抽出した共通明細データ（明細ＩＤ「Ｍ０００２」、「Ｍ０００４」、「Ｍ０００６」及び「Ｍ０００７」のデータ）から値が「ＮＯＮＥ」となっている「年月日」、「取引内容」、「お引き出し」、「お預入れ」の項目名を削除することで、指定した金融機関（Ａ銀行）の口座明細データのフォーマットのままとして出力データをＣＳＶ形式で出力する。

次に、抽出した共通明細データ（明細ＩＤ「Ｍ０００２」、「Ｍ０００４」、「Ｍ０００６」及び「Ｍ０００７」のデータ）の「出力フラグ」の値を「０」から「１」に変更し、共通明細データを更新する。

通信部１５０は作成した出力データを会計事務所等にある管理装置２００に送信し、管理装置２００で出力データを取り込み（データ管理部２３１で実行し取込データ格納部２４３に保存）、仕訳データを作成したりする（仕訳処理部２３２で実行し作成データ格納部２４２に保存）ので、出力データを出力する段階で、出力済みの出力データを排除することができるので、管理装置２００で出力データを重複して取り込むのを防止できる。

管理装置２００は取り込んだ出力データからＳ３−１−１０と同様の方法又は公知の任意の技術を利用して取引データを作成してもよい。

次に管理装置２００は出力データを取り込んだ場合は、仕訳処理部２３２が作成した取引データに対して自動仕訳処理を実行し仕訳データを作成し、装置内部の記憶領域（作成データ格納部２４２）または、外部記憶装置にある仕訳ＤＢ（図示せず）に登録する。管理装置２００は取引データの項目名「摘要」と「備考」を参照して公知の任意の自動仕訳技術を用いて自動仕訳処理を実行してもよい。例えば、過去の仕訳内容を利用したものや辞書を用いたものや推論又はルールベースの自動仕訳技術を用いて、自動仕訳処理を実行してもよい

また、管理装置２００は取引データを取り込んだ場合は、仕訳処理部２３２が取り込んだ取引データに対して自動仕訳処理を実行し仕訳データを作成し、装置内部の記憶領域（作成データ格納部２４２）または、外部記憶装置にある仕訳ＤＢ（図示せず）に登録する。管理装置２００は取引データの項目名「摘要」と「備考」を参照して公知の任意の自動仕訳技術を用いて自動仕訳処理を実行してもよい。例えば、過去の仕訳内容を利用したものや辞書を用いたものや推論又はルールベースの自動仕訳技術を用いて、自動仕訳処理を実行してもよい。

以上、本発明の実施例について詳細に説明したが、本発明の技術的範囲は上記の実施形態ないし実施例に限定されるものではなく、本発明は添付の特許請求の範囲を逸脱することなく様々な変形例、変更例として実現することができる。このような変形例、変更例はすべて本発明の技術的範囲に属すると解されるべきである。

本発明は、顧問先での会計処理だけでなく、会計事務所とその顧問先との間で執り行われる会計処理にも利用することができる。

１００ 端末
１１０ 入力部
１２０ 表示部
１３０ 制御部
１３１ データ管理部
１３２ 仕訳処理部
１３３ 取込処理部
１４０ 記憶部
１４１ 管理データ格納部
１４２ 作成データ格納部
１４３ 取込データ格納部
１５０ 通信部
２００ 管理装置
２１０ 入力部
２２０ 表示部
２３０ 制御部
２３１ データ管理部
２３２ 仕訳処理部
２４０ 記憶部
２４１ 管理データ格納部
２４２ 作成データ格納部
２４３ 取込データ格納部
２５０ 通信部
３００ 金融機関のサーバー

Claims (7)

1. 金融機関サーバーが管理する口座明細データにアクセスするための認証情報を用いて、前記金融機関サーバーから前記口座明細データと前記金融機関の情報を含む履歴情報を取得する取込処理部と、
   前記取込処理部が取得した前記口座明細データと前記履歴情報から構成される共通明細データとして管理するデータ管理部と、
   前記共通明細データを格納する取込データ格納部と、
   を備え、
   前記取込処理部は取得した金融機関毎に一意となる口座明細データの項目が前記共通明細データの項目と一致する項目が存在するか判定を行い、
   存在する場合はそのまま前記口座明細データと前記履歴情報を前記共通明細データに取込み、
   存在しない場合は前記共通明細データの項目に前記口座明細データの項目を追加する登録処理を行ない、前記口座明細データと前記履歴情報を前記共通明細データに取込み、
   前記共通明細データの項目で前記口座明細データの項目と一致しない項目に特定識別子をデータとして設定する、
   情報処理装置。
2. 前記取込処理部は取得した金融機関毎に一意となる口座明細データの項目が前記共通明細データの項目と一致する項目が存在する場合に、
   取得した前記金融機関の最新の前記共通明細データと口座明細データ及び前記履歴情報を比較し、比較結果が特定識別子以外のデータが一致するときは、
   口座明細データと前記履歴情報取込済みと判定して重複して取込むことを防止する、
   請求項１に記載の情報処理装置。
3. ユーザーの入力を受付ける入力部、
   指定した金融機関の口座明細データを含む出力データを格納する作成データ格納部と、
   を備え、
   前記入力部は、出力する金融機関の指定を受付け、
   前記データ管理部は前記共通明細データから前記入力部により指定された金融機関の共通明細データを抽出し、抽出した共通明細データからデータが特定識別子である前記共通明細データの項目を除外した前記共通明細データの項目のみのデータを前記出力データとして出力する、
   請求項１または２に記載の情報処理装置。
4. 集約ルールをを格納する管理データ格納部と、
   を備え、
   前記データ管理部は前記登録処理の際に合わせて追加する前記共通明細データの項目の集約ルールの設定を行なう、
   請求項１または２に記載の情報処理装置。
5. 前記共通明細データを元に前記データ集約ルールを適用して作成した取引データを作成データ格納部に格納する、
   請求項４に記載の情報処理装置。
6. 自動仕訳処理を行なう仕訳処理部と、
   を備え、
   前記仕訳処理部は前記取引データに対して自動仕訳処理を実行して作成した仕訳データを作成データ格納部に格納する、
   請求項５に記載の情報処理装置。
7. コンピュータを、請求項１から６のいずれか一項に記載の情報処理装置として機能させるためのプログラム。