見出し画像

為替換算調整勘定は貸借差額ではない!【クラウド連結会計こだわり仕様シリーズ】

こんにちは!「マネーフォワード クラウド連結会計(以降“クラウド連結会計”)」のプロダクトマネージャーをしている、HORI です。

こだわり仕様シリーズ第11回

クラウド連結会計のこだわりシリーズ、11回目に突中します。前回は英語対応リリースに合わせて「グローバル化」の話題について解説しましたが、今回は海外子会社の財務諸表を扱う際に避けては通れない「外貨換算」について解説します。(今回は連結プロフェッショナル向けのマニアックな内容です。最後までたどり着く方は猛者です)


グループ子会社の通貨と小数点桁数

グループ子会社が海外の場合、現地での通貨(厳密には機能通貨の判定が必要ですが、そこは説明を割愛します)を登録します。この際、通貨だけではなく「小数点桁数」の確認を行うところもポイントになります。

世界にはドルやユーロのように小数点2桁を当たり前のように使う国と、円のように整数しか扱わない国が混在していますので、グループ会社からの報告に小数点桁数が必要かどうかは会社ごとに判断しておく必要があります。

グループ会社の報告通貨と小数点桁数を登録

選択できる通貨コードはISO4217の3桁通貨コードを利用していますので、ほとんどのケースの通貨に対応可能ですし、通貨コードを自分で考える必要もありません。

なお、小数点桁数を把握して必要な桁数までの四捨五入処理をしておかないと、見かけ上の数とデータベース上の数値が乖離する可能性があることへのケアという意味でも実はこの小数点桁数はシステム上でも重要な役割を果たしています(この点に関しては別の記事「3.8-3.7=0.1ではない?小数点との付き合い方」で説明してますので、気になる方はそちらをご覧ください)。

為替レートの登録

連結決算において、在外子会社の報告は報告通貨で行われますので、連結通貨(親会社通貨が円ではないケースもあるので、連結通貨としています)への換算を行う際には換算レートの登録が必要となります。

BS科目は決算日レート、PL科目は期中平均レートでの換算が必要なので、それぞれの登録が必要というところは一般的な連結決算システムと同じようなマスタ画面構成なのですが、クラウド連結会計は「通貨ごと」に換算レートを登録するのではなく「会社ごと」に換算レートを登録するという点が特徴的になっています。

単純に考えると、「同一通貨を使う会社が複数ある場合、通貨ごとに換算レートを登録するほうがラクなのでは?」となるのですが、実はここに一つ落とし穴があります。それは「子会社の決算日が同じとは限らない」という点です。連結の会計基準では3ヵ月を超えない範囲で子会社の決算日ズレがあることを許容しています。そのため、子会社の決算日が揃っていない可能性もあり、同じUSD子会社であっても決算日が違う子会社が混在する可能性があります。

通貨マスタで独自の通貨を登録することができれば、USD2とかの通貨を作ってしまえばいいのですが、通貨マスタをISOの3桁コードで縛っているため、そういう工夫もできません。

そのため、同じUSD子会社で決算日が違う子会社を連結しないといけないケースが発生した場合、通貨ごとの換算レート登録では「詰み」になってしまうリスクがあります。

クラウド連結会計は随所でこういった「業務上の詰み」のパターンが発生しないように工夫している関係上、「会社ごと」にレートを登録するようにしています。

会社毎に出しつつ、外貨の会社を上に出すことで登録動作でのスクロールは最小化

換算処理はリアルタイム

過去の多くの連結決算システムでは、ほとんどのケースで、データ登録時には換算せずに、親会社の方が「連結決算処理」を実行したタイミングで報告通貨から連結通貨への換算を実行していました。

このため、データを登録した直後やレートを登録した直後では「あれ、数値が変わってない?」という状態となっていて、数値の整合性の把握や、リアルタイムでの経営成績の把握に支障をきたしていました。子会社側と親会社側でどちらかの更新タスクが漏れると最新化できないのです。海外子会社は時差もありますので、海外子会社も含めた換算データを最新に保つのが困難な仕様だと言えます。

クラウド連結会計ではこの点を改善するために「子会社のデータをアップロードないし登録したタイミング」で常に換算をするようにしています。データを登録したタイミングで常に換算前金額と換算後金額をつくるので、「親会社の換算処理」を待たずに、換算結果が見れるようになっています。

なお、従来型の換算仕様の場合、「換算レートを変更した後に換算処理の再実行が漏れる」という事故を起こすことが多かったので、「換算レートを変更した後には必ず換算処理の再実行を走らせる」という仕様にして、換算処理の実行漏れも防いでいます。

常に最新の換算結果が保たれます

換算修正の登録

連結決算においてはBSは決算日レート(CR)、PLは期中平均レート(AR)という処理の例外として、取得日レート(HR)での換算が必要なケースがあります。

この処理を基準ベースで確認してみると、外貨建取引等会計処理基準における規定

「親会社による株式の取得時における資本に属する項目については、株式取得時の為替相場による円換算額を付する」

という文言に辿り着きます。この文言、よーく読んで頂きたいのですが、「差額を登録しなさい」とは書いていません。「親会社側での金額に合わせなさい」という規定になっています。

クラウド連結会計では、この会計基準通りの処理が直感的にできるような換算修正画面を準備しています(登録した金額で外貨金額を上書きする仕様です)。

また、取得日レートでの換算は翌期以降に引き継いでいく必要がありますが、開始処理でHR科目の換算修正を引き継いでいくため、一度登録すれば翌期以降でのデータ登録は不要になります。

追加取得でも柔軟に対応可能

為替換算調整勘定の計算ロジック

多くの連結決算担当者が苦しむ「為替換算調整勘定」の計算ですが、クラウド連結会計においては、自動で計算してくれます。実はこの計算ロジック、かなり工夫しています(特許申請済)。

今までの連結会計システムは「BSの各科目の換算後金額の貸借差額」で出すシステムが多いのですが、この計算方法の場合、「換算前金額に貸借差額があった場合、貸借差額相当が為替換算調整勘定に混ざりこむ」という事象が発生します。

この事象のタチが悪いところは、為替換算調整勘定の計算を間違える、ということにとどまらず、「換算前で貸借差額があるのに、換算後で貸借差額がなくなったように見える」という点にあります。(その結果、必要な修正を見逃してしまうことも)

クラウド連結会計では、この問題を回避するため、計算方法を工夫することで「為替換算調整勘定と貸借差額が混ざらない」ようにしています。

Excelで計算すると膨大な計算式が必要

計算式の詳細は割愛しますが、会計基準に記載されている文言「換算によって生じた換算差額については、為替換算調整勘定として貸借対照表の資本の部に記載する」という処理を忠実に表現した処理になっています。
(むしろ、貸借差額を全て為替換算調整勘定にする処理は会計基準を逸脱していると思います。「換算差額」と「貸借差額」を混同していると思われます)

損益計算書の換算修正

損益計算書の換算修正は発生頻度は多くはないのですが、会計基準に以下の記載があるため、対処は必要になります。

「親会社との取引による収益及び費用の換算については、親会社が換算に用いる為替相場による。この場合に生じる差額は当期の為替差損益として処理する」

この処理のポイントは実は「損益の差額から為替差損益=利益は一切動かない」という点になります。そのため、損益計算書の換算修正は当期純利益や為替換算調整勘定には影響しません。あくまでも換算修正した損益勘定と為替差損ないし為替差益勘定との入り繰りになります。

換算による端数の処理方法

ここまで読んでいただけた読者(多分1パーセントに満たないと想定しています)には、「換算処理へのこだわり」を理解していただけているかと思いますが、実はこのこだわりを貫き通すためには以下の処理が大前提になっています。

  • 科目単位での四捨五入を行う

  • 端数差を無理矢理に特定の勘定科目に寄せるような処理はしない

実はこのこだわりの結果、以下の事象が発生する可能性があります。
「外貨ベースでの当期純利益をダイレクトに換算した結果と端数差が出る」

ダイレクトに検証する際には上記のような計算をする方もいるとは思うのですが、各科目であるべき数値を突き詰めているが故に利益の計算式を外貨ベース優先とするか、換算後数値での利益計算式を優先とするかの差額が発生してしまうのです。
この現象を極力少なくするために、クラウド連結会計では有効桁数への丸め処理を四捨五入に統一しています(切り上げや切り捨てだと端数差の積み上げが一方向に偏り差額が大きくなりやすいため)。

最後に

いかがでしたでしょうか?
この記事では外貨換算に焦点を絞って記載しましたが、『マネーフォワード クラウド連結会計』にはまだまだ魅力的な機能がたくさんあります。
お客様の課題に合わせた豊富な導入支援プラン等もございますので、気になった方は下記のリンクよりお問合せをお願いいたします。


この記事が気に入ったらサポートをしてみませんか?