＿お恥ずかしい限りですが、筆者はマネーフォワードMEのヘビーユーザーを名乗りながら、これまで家計簿アプリとしての基本事項をまるで押さえておりませんでした（恥）。今回の記事で取り返します（前回の記事はこちら）。
１．マネーフォワードMEの口座種別
＿前々回の記事で、マネーフォワードMEには
- ユーザーがデータを手入力する口座
- 金融機関連携機能によりデータを得る口座
＿の全く異なる口座がある、と申し上げました。前者については、↓の画面例のように、（連携機能）未対応の手入力用資産として設定します。
＿↑の画面で設定できる口座種別は、↓の表の「手元の現金・資産」列に△が入っている口座です。マネーフォワードMEは、この口座種別に基づいて、ホーム画面左ペインの連携金融機関の並び順を決めています。
＿「金融機関連携機能によりデータを得る口座」については、↑の表の「登録済み金融機関」の列に〇が入っている口座が該当し、金融機関との連携を設定すれば自動的に口座として登録されます。
２．マネーフォワードMEの資産・負債の種別
＿マネーフォワードMEは、少々困ったことに 口座・資産・負債 といった用語の使い方がサイト内で統一されておらず、かなり判りにくい状況になっておりますが…動作としては、例えば銀行口座と連携した際に、口座に付帯する「普通預金」「定期預金」「外貨預金」等の資産を紐づけ、それぞれの残高を資産額として計上する、という具合になります。ホーム画面中央ペインの資産額推移のグラフは、この資産種別に基づいて色分けされています。
＿手入力した口座に手入力で資産を紐づける場合は、ホーム画面＞資産＞資産内訳画面の【手入力で資産を追加】ボタンを叩き、↓のダイアログで設定します。「金融機関連携機能によりデータを得る口座」の場合、その口座に紐づいている資産は、マネーフォワードMEが自動的に種別を設定します。
＿↑の画面のドロップダウンリストに出現する資産の種別と細目を一覧にすると↓のようにやたら沢山あることが判ります。このように、マネーフォワードMEは本来はかなり資産管理に寄せた設計になっているのです。
＿資産と同様に、負債にも以下のような種類があります。
３．マネーフォワードMEの取引種別
＿一方で、マネーフォワードMEの取引種別はシンプルに「収入」・「支出」・「振替」の３つだけです。うきうき家計簿のように「振替に７つも種類がある」という厄介な設計ではないものの、入力作業には下記のように強い制約を課しています。
- ユーザーがデータを手入力する口座
- 収入→手入力可能
- 支出→手入力可能
- 振替→「ユーザーがデータを手入力する口座」同士であれば手入力可能
- 金融機関連携機能によりデータを得る口座
- 収入→手入力不可
- 支出→手入力不可
- 振替→金融機関サイトから取得された取引を振替に変更することのみ可能。振替の相手先は「ユーザーがデータを手入力する口座」にすることもできる（その場合は相手の口座の残高に影響を与える）
＿↓の画面は、振替取引を手入力しているダイアログの例です。振替元としてドロップダウンリストに表示されているのは「ユーザーがデータを手入力する口座」に限定されていることが判ります。振替元として示される選択肢も同様になります。
４．マネーフォワードMEの振替取引に関する特異な動作について
＿↑の画像に奇異な文言があります。
＿…へ？ 振替取引って振替元と振替先の両方を指定するのがフツーじゃないの？ と思われるのが当然でしょう。少なくとも、これまで当Blogでご紹介してきた家計簿アプリのうち、Moneytreeを除いては皆そのようになっています。ところがマネーフォワードMEは「振替元あるいは振替先のどちらかが未指定」という奇怪な振替取引を記帳できるのです。そして、このことがマネーフォワードMEの振る舞いを大きく特徴づけています。少々ややこしい話になりますので、例を挙げて解説します。
（１）クレジットカードから電子マネーへのチャージ
＿クレジットカードAで電子マネーBへ7月12日に9,500円のチャージを行った、という事例で考えます。ユーザーはA・B両方ともマネーフォワードMEと連携させている前提です。この場合、7月12日以降に、金融機関連携機能によって
- イ：電子マネーBに7/12に9,500円の収入があった
- ロ：クレジットカードAで7/12に9,500円の支出があった
という取引データを取得することになります。そして、マネーフォワードMEはイとロの組み合わせの取引データを過去に処理したことがあれば、学習機能によって、この2つの取引を
- ハ：クレジットカードAで電子マネーBへ7月12日に9,500円の振替取引が発生した
＿と1つの取引へ自動的に変換します。ところが、学習機能が中途半端に作動した場合、イの収入、ロの支出の取引を、
- イ’：電子マネーBに7/12に振替元不明の9,500円の振替収入があった
- ロ’：クレジットカードAで7/12に振替先不明の9,500円の振替支出があった
＿と変換してしまうことがあるのです。また、学習機能が作動しなかった場合でも、ユーザーが上記のイ・ロの取引をイ’・ロ’のように修正できます。そして、さらに
- イ’’：電子マネーBに、7/12にクレジットカードAから9,500円の振替収入があった
- ロ’’：クレジットカードAから、7/12に電子マネーBへ9,500円の振替支出があった
＿と、二つの取引をそれぞれ完全な形の振替取引に修正することもできます（片方を削除することはできません。ルールを忘れないように！ マネーフォワードMEでは金融機関連携機能で得た取引データは削除できません）。イ’’とロ’’はお金の動きは同じなので取引がダブってしまうのですが…イ・ロ、イ'・ロ’、イ’’・ロ’’、ハのいずれの形にしていてもA・Bの残高には影響を与えません。
（２）クレジットカードによる通販サイトへの支払い
＿今度は、クレジットカードAで通販サイトCへ7月5日に28,000円の支払いを行った、という取引の場合です。もちろん、A・C共にマネーフォワードMEと連携させているものとします。このケースでは、マネーフォワードMEにはAのサイトから
- クレジットカードAから7/5に28,000円の支出があった
という情報が入るわけですが、その逆、つまり通販サイトCにクレジットカードAからの支払いがあった、という情報はCからはやってきません。マネーフォワードMEは、通販サイトCから売り上げ（ユーザーによる買い物）に関する情報は取得しますが、その支払いに関する情報は取得しないからです。
＿そして、この取引は、学習機能やユーザーの修正により、
- クレジットカードAから通販サイトCへ7月5日に28,000円の振替取引を行った
＿と変更することができます。変更しなくても支障ありません。どちらにしてもA・Cの残高には影響がありませんから…。このケースの類例としては「クレジットカード利用額の銀行口座からの引落し」が挙げられます。
（３）銀行口座から財布（現金管理）への預金引き出し
＿「7月4日に銀行口座Dから20,000円引き出して財布Eに入れた」という取引を例にします。銀行DはマネーフォワードMEと連携しているものとします。
＿この取引はユーザーが手入力できず、7/4に銀行口座Dから20,000円の支出があった、という取引データがマネーフォワードMEに取り込まれた後、銀行口座D→財布Eへの振替である、というデータに修正しなければなりません。それで初めて財布Eの残高が20,000円増加します。
＿このように、手入力用の口座が絡んだ振替取引だけは、ユーザーがしっかり修正入力をしなければなりません。財布Eへの20,000円の入金を「収入」と記帳すると、Eの残高は正しくとも、家計全体の収入額を誤って認識することになります。
マネーフォワードMEの神髄は振替取引のいい加減な取り扱いにある
＿このように、マネーフォワードMEは振替取引をあまり厳密に処理しません。これは、「金融機関連携機能によりデータを得る口座」では、残高情報は金融機関サイトから得た金額が絶対であり、一つ一つの取引が振替であろうとなかろうと、その口座の残高には影響を与えないように仕組まれているからです。
＿そのため、振替取引の振替元・振替先の片方さえ確定していれば、口座の残高推移と取引履歴に矛盾は生じないわけです。後は、月間の収入額・支出額の計算に含めるかどうかを「計算対象」のフラグで指定すれば、月間収支の認識にも誤りは生じません。振替取引を正しく記帳しない場合は複式簿記として正確に記帳できていないことになりますが、残高と収支の認識さえ正しければ資産管理にも家計管理にも一応支障はありませんからね。
＿ただし、マネーフォワードMEはこのような「振替取引であることさえ判れば相手先なんかどうでもいいや」という特異な動作方針が、大きな問題を発生させます。画面上で振替元・振替先両方が指定されている振替取引であっても、ダウンロードすると、振替取引の相手先の口座名が入ってこないというクズ仕様になっているのです。今後の記事で解説しますが、MFFマクロの開発の際にはこの仕様への対応に手間と時間を浪費させられました。
