【財務用語解説シリーズ】海外子会社の内部統制 Part2

海外子会社の内部統制 Part1(現状・内部統制の脆弱性・不正のトライアングル)>>

4. クラウドTMSによる不正対応

 

日本企業が近年海外進出を積極的に進めていることは改めて言うまでもありませんが、2015年時点で、日本企業の海外現地法人は29,000社超となり、10年前の1.4倍となっています。駐在員1人に対して、海外現法従業員数は109人となる計算です*。この拡大に比例して管理部門が増えていない、または今後増やせないのであれば、ITに頼らざるを得ません。それはクラウドTMSが有力な候補となります。

* 「海外進出企業総覧」(東洋経済新報社)の2016年版と2006年版から集計

 クラウドTMSを用いて以下のように内部統制の脆弱性を補ったうえで、不正の機会をなくす統制の仕掛けを構築して不正のトライアングルを破壊し、不正をなくすことを目指します。

4.1 内部統制の脆弱性を補う

内部統制の脆弱性それぞれに対しては、クラウドのTMSにより以下のようにカバーすることができます。

① ブラックボックス化

 TMSには全銀行口座が登録され、支払や財務取引の職務権限もすべて設定され、本社が全世界の子会社の口座や権限について完全に把握できます。そして銀行取引は1件ずつ、銀行通帳の1行の単位で、新興国も含めて前日までの取引がすべて本社で照会できます。

② 例外取引・例外フロー

 クラウドの柔軟性によって例外取引・例外フローも対応し、証跡を残すことができます。ワークフローは簡単な設定で定義できますので、例外取引があってもTMSの中で承認をとって取引させることができます。従来のソリューションのように、システム対応が間に合わないからオフラインで対応するということはなくなります。

③ 新規事業・M&A・ノンコア事業・異業種

 クラウド型TMSの特長の一つは短期間で導入できることと、一部の拠点、一部の銀行から始めるといったスモールスタートをしやすいということです。可視化だけであれば、1,2か月で可能です。この特長により、買収先をDAY1から可視化したり、内部統制プロセスが相対的に弱い拠点や事業にクラウドTMSを入れて可視化することが可能です。

④ 遠隔地・海外

 クラウドのTMSでは、全取引、全ルールが一つのデータベースに入ります。従来のソリューションのような、一旦子会社のシステムに入れてからエクスポートして、本社のシステムにインポートするのではありません。グローバルで最初から一つにデータベースに権限情報や取引データが入ります。したがって、距離や時差は関係ありません。子会社によるデータの改ざんリスクもありません。さらに異なるコード体系をマッピングする機能により、言語の問題も解決します。

⑤ 子会社、孫会社

 「④遠隔地・海外」と同じことが言えます。加えてクラウド型TMSでは本社は子会社や孫会社と同じ画面やレポートを共有し、自由に数分で画面の設定を変えたりできます。子会社と対話するときには、一緒に同じ画面を見ながらその場で相手の主張や理解度にあわせてグラフや表を変えたり、データを照会して、意思の疎通を確かなものにし、合意形成を図ることができます。

⑥ 心理的なプレッシャー・遠慮

 本社が随時子会社のデータを握ることができる点がクラウド型TMSの最も大きなメリットでしょう。今まではデータがないため子会社の主張に反論できなかったとしても、事前に証拠やデータを握って、反論させない、内部監査の往査の質を高めるといったことが期待できます。

 

4.2 不正のトライアングルを断ち切る

内部統制の仕掛けは、「予防的統制」と「発見的統制」と二つあります。

予防的統制: 「所定の内部統制からの逸脱を防止する統制活動」*。要するに業務が完了する前に実行される統制です。不正やミスを未然に防ぐことを意図しています。
発見的統制: 「当該逸脱を発見し修正する統制活動」*。要するに取引や業務が終わってから不正やミスを発見して対応します。事後の対応になりますから、迅速に発見できるようにすることが極めて重要です。

* 日本公認会計士協会 監査基準委員会報告書第20号(中間報告)(2002年)『統制リスクの評価』

 

クラウドTMSを使った予防的統制と発見的統制の仕組みはそれぞれ以下のようなものがあります。

対象 予防的統制 発見的統制
財務業務規程

業務権限の制限

・業務の制限

・データの制限

業務の固定

・業務テンプレート

・メニューマップ

・承認ルール

・ワークフロー

モニタリング(ホワイトボックス)

・取引

・ユーザー操作

・業務やマスターの追加・変更

CAAT(ブラックボックス)
財務取引実行プロセス

直接・自動化・統合支払機能

モニタリング

 

以下で、それぞれの内容を簡単に説明します。

 

4.2.1 予防的統制

(1)業務権限の制限

 ユーザー又はユーザーグループごとに利用できる機能とアクセスできるデータを制限します。これによって行える業務と参照できるデータを制限します。

① 業務の制限

 自分が行えない業務はその機能がメニューには表示されません。入力はできるが更新はできない等、メニューの機能ごとに権限を設定します。
 スプレッドシートでは、とてもここまで細かくコントロールはできません。

 

(図3)支払業務権限設定の例

支払業務権限設定の例

 

② データの制限

 他の子会社のデータなど、その担当者の管轄外のデータを見えないようにします。自分が参照できないデータは、最初から選択できませんし、全社共有の画面やレポートを開けても表示されません。 スプレッドシートでは、シートごとにパスワードを設けるか、シートを保存するフォルダを分ければデータの制限は可能ですが、実務上非常に煩雑になり、すぐに形骸化して守られなくなったりするものです。

 

(図4)データのアクセス制限の例。会社、口座といったデータのタイプと業務を組み合わせて、参照可否を設定

データのアクセス制限の例。会社、口座といったデータのタイプと業務を組み合わせて、参照可否を設定

 

(2)業務の固定

 業務をテンプレート化し、担当外や権限外の業務はそもそも担当者の画面に表示させないようにします。機能とデータの制限とくみあわせて、担当外や権限外の業務の実行を阻止します。さらにメニュー画面を標準化して、担当外の業務をさせず、オペレーションミスも起こさないようにします。そして承認ルールとワークフローを設定し、全世界の申請・承認内容を見えるようにして、かつ電子的に証跡を残します。

① 業務テンプレート

 業務テンプレートとは、入力・参照・更新業務を“固定”させ、必要最低限のデータ入力と操作だけで業務を完結できるようにすることです。

 照会業務を例にすると、一般的なシステムであれば、取引の種類、対象の会社や口座など、取引の内容を選択して照会します。これをあらかじめ設定して、担当者に条件を選択させず、「○○の照会」という具合に名前をつけて業務テンプレートとするものです。担当者が照会するときにはこのテンプレートを選択させて、他の照会をさせないようにします。もちろん、データ権限を適切に設定していれば、その担当者には見えないのですが、権限の設定漏れを防ぎ、他も見てみようという気持ちを起こさせないようにするのが狙いです。

 このテンプレートの作成、修正は数分でできますので、低頻度や例外的な取引などに臨機応変に対応できます。

(図5)照会業務のテンプレート化の例。ここでは承認待ちの支払一覧を照会するときの範囲を固定させています。振込種類、仕向銀行、口座、会社、金額等で細かく限定させることができます 

照会業務のテンプレート化の例。ここでは承認待ちの支払一覧を照会するときの範囲を固定させています。振込種類、仕向銀行、口座、会社、金額等で細かく限定させることができます。

 

② メニューマップ

 その担当者が行う業務だけを順番に行えるようにしたものです。業務のトップメニューに業務アイコンが並び、左から右に、又は上から下へ順番に実行していけばよいようになっていて、業務を標準化してミスを防止するとともに、管轄外の業務を行わせないようにする仕掛けです。

(図6)メニューマップの例。それぞれのアイコンには機能や業務テンプレートを割り当てることができますので、担当者ごとにメニューを変え、その担当者の業務に専念させます。

メニューマップの例。それぞれのアイコンには機能や業務テンプレートを割り当てることができますので、担当者ごとにメニューを変え、その担当者の業務に専念させます。
 

③ 承認ルール

 とくに横領が起こりうる支払業務については、承認のルールを設定します。一般的には仕入先への支払であれば、送金額がいくらまでは課長承認、いくらまでは部長承認、というように、支払の種類と支払額に応じたルールを設定します。クラウドの特長のひとつは、きめ細かく各担当者の支払業務を制限できることにあります。例えば支払であれば、支払の種類と金額に加えて、銀行や口座、支払元会社、その他の承認にかかるオプションを設定して、取引の内容に応じた権限設定を行うことができます。

(図7)承認ルールの例

承認ルールの例
 

 現実には多様な取引がありますから、あまり細かくルールを設定すると、例外処理が増えて、却って統制がとれなくなるのではないかという懸念もあるかもしれません。クラウドのソリューションであれば、このような設定は数分でできますので、低頻度の取引でも容易にテンプレート化できます。また仮にテンプレート化しなくてもクラウドのTMSの中で支払の承認を行えば証跡が残りますので、数段のチェックポイントを設けることで統制を維持できます。

④ワークフロー

 最後に各ルールや権限をつなげてワークフローにします。たとえば支払権限を全世界で一覧にして確認することは大変有効でしょう。世界で何名の担当者がそれぞれいくらまでの支払承認権限があるのか一目瞭然です。同じような規模の会社でも支払権限者が多い会社と少ない会社があったりします。特定の口座、特定の送金目的の権限しかない人、国内送金・海外送金ともにすべての権限を持っている人は誰か、などを把握し、適正なのかどうか、ポリシーを再度見直した方がよいのか、などレビューしながら最終化します。

 このような職務権限のリストは、人事部門や監査部門などの関連部門と共有し、会社のグローバル・ポリシーからの逸脱がないかチェックすることも有効です。

(図8)支払権限者のリストの例

支払権限者のリストの例

そして承認ルールごとに、何段階の承認とし、それぞれをどのクラスの承認者に割り当てるか定義します。

(図9)承認レベル設定の例

承認レベル設定の例

(図10)承認レベルと承認者割り当ての例

承認レベルと承認者割り当ての例
 

(4)直接・自動化・統合支払機能

 財務取引の実行プロセスをクラウドのTMSによってシステム化して、統制が効くようにします。ポイントは3点あります。

① データソースから直接、生データを連携すること

 銀行取引明細であれば、銀行から直接TMSへデータを受信します。子会社のシステムは経由させません。子会社によるデータの加工を防ぐためです。

② 完全に自動化させること

 従来の支払関連システムの開発では、費用面等の事情もあり性善説に則って手作業の業務プロセスを残す場合も見られました。しかし、不正が相次ぐ現在ではその考えはもはや成り立ちません。完全な自動化をめざすべきです。

 多くの企業では、支払の申請から承認までのプロセスと、銀行へ送金指図を送るプロセスは分断されています。端的に言えば、大企業であっても、ERPで支払承認まで行い、そこから承認済み取引の支払ファイルをダウンロードして、銀行のインターネットバンキングやパソコンバンキング・ソフトに手でアップロードして送っている企業が大多数です。そして、支払ファイルはテキストファイルですので、誰でも容易に改竄できます。支払ファイルの送信承認者の横で送信者は改竄できます。電機メーカーB社の例では日本国内の社員が改竄を行いました。

③ 支払のプロセスを統合させること = STPをめざすこと

 STP(ストレート・スルー・プロセッシング)とは元は証券用語ですが、ここでは、支払の申請から最後の支払ファイルの銀行送信と仕訳記帳までを、人手を介さず、全て電子的に行うことを指しています。単に自動化するだけでなく、統合させることがポイントです。

 クラウドTMSを使って支払業務を自動化する場合、支払の申請から支払ファイルの銀行への送信までをTMSで行うこともできますが、ERPとTMSは別々に導入することが多いでしょう。それぞれ目的が違いますし、得手不得手があるからです。どちらにしてもポイントは、ERPとTMSとの間を人手を介さず完全自動連携とし、支払の申請状況と送信状況を一つの画面で確認できるようにし、支払ファイルを改竄できる余地をなくすことです。

 多くの場合、ERP側での支払承認者と、支払ファイルの送信承認者及び送信者は異なります。支払の承認者には、銀行へ送金指図を送るところは見えていません。支払承認者は、承認締日までに承認することしか意識がなく、誰からも指摘されない限り支払日に支払われているだろうと思い込んでいるにすぎません。これでは。承認した内容が変わっていないことを担保できません。支払ファイルの送信承認者にとっても承認した内容で銀行に指図しているかわかりません。

 銀行へ支払ファイルを送るプロセスは最も狙われやすいところで、企業から見ると最後の関門です。支払プロセスに携わる担当者も承認者も一つのプラットフォームで支払の状況と内容を確認できるようになっていることが極めて重要です。

 とくに自動化とSTP化の部分は、多くの企業においてシステム対応費用の観点で犠牲にされてきたところです。しかしクラウドTMSにより、その連携コストが著しく下がった今、その障害は取り除かれました。万が一、グループの社員に数億円を横領された場合、調査報告書に「送金指図は手作業で行っていて、その担当者が書き換えていました」と書けるでしょうか。

 

(5)モニタリング

 仕掛けに完璧はありませんから、日々の取引実行状況のモニタリングは欠かせません。

クラウドのTMSでは、全世界の財務データ全件が最新の状態で1つのデータベースで共有されているがゆえに、新興国も含めたモニタリングを行えます。

 グローバル各社の資金移動や外部への振込のステータスについての全体を見て、必要に応じて当該会社に問い合わせて確認します。本社では全世界の支払の一覧を見ただけでは、その支払の是非はわからないことが多いでしょう。しかし、疑問に思った取引についてメールで問い合わせるだけでも、子会社にとっては大きな牽制になります。

(図11)支払状況のサマリーの例

下図は振込のステータス(承認待ち、修正中等)と送金元の子会社別のサマリーを示しています(表中の数字は、振込件数とその振込合計金額です)。必要があれば数字をダブルクリックするとドリルダウンして1件ずつの支払内容を照会できます。

この他にも、銀行別、口座別、日付別、通貨別などでも見て、異常なものがないか等モニタリングします。

支払状況のサマリーの例

サマリー画面ではなく、個々の送金指図を一覧にして見る方が有効な時もあるでしょう。各振込の相手方、日付、金額、処理状況等を見ながら、必要に応じでダブルクリックして個々の振込内容を参照して確認します。

(図12)支払取引を一覧した例。色(緑、赤等)がステータスを示しています。

支払取引を一覧した例。色(緑、赤等)がステータスを示しています。

4.2.2.     発見的統制

 事後に発見する方法としては、取引や入出金のデータをモニタリングすることが出発点になります。しかし、これでは想定外の取引で不正を実行されたときには気づきにくいという難点があります。そこでデータをブラックボックスとして見ることも必要になります。それがCAATと呼ばれる方法です。モニタリングというホワイトボックスアプローチと、CAATというブラックボックスアプローチの組み合わせで、不正を検知するのがよいと思われます。

(1)モニタリング(ホワイトボックスアプローチ)

 ダッシュボートから毎日、異常と思われる取引を見つけて調査したり、担当者に照会する方法です。商流や取引の実際を理解している担当者が、時系列や横串の比較と自分の経験や知識に照らし合わせて不審な取引に着目するものです。毎日のように本社から取引に関する問い合わせを受けている外資系企業の日本法人の財務担当者は、不正をする気にはならないと言っているそうです。

① 取引

 銀行の実際の入出金や財務取引をモニタリングします。たとえば不正の手口で多い架空売上を想定すると、売上がたち(入金予定がたち)、しかし入金がないというものについては、TMS上では、銀行の入金取引と消し込まれていない入金予定を抽出すると、そのような不正の取引も引っかかってきます。銀行取引実績は毎日更新されるので、内部監査、往査のサイクルに関係なく、随時子会社に照会して牽制を効かせることができます。

(図13)未収売掛金を一覧にした例。海外子会社の入金が遅れている売掛金を入金予定日ごとに一覧表示させたものです。必要があれば、各明細をドリルダウンすると明細の内容を確認できます。

未収売掛金を一覧にした例。海外子会社の入金が遅れている売掛金を入金予定日ごとに一覧表示させたものです。必要があれば、各明細をドリルダウンすると明細の内容を確認できます。

(図14)財務取引の更新履歴をモニタリングする例。ある借入契約のデータの作成、変更の履歴を一覧にしました。個別の財務取引について、いつ誰が入力して、いつ誰がどの項目をどのように変更していったかの履歴がわかります。

財務取引の更新履歴をモニタリングする例。ある借入契約のデータの作成、変更の履歴を一覧にしました。個別の財務取引について、いつ誰が入力して、いつ誰がどの項目をどのように変更していったかの履歴がわかります。

② ユーザー操作

 ユーザーの操作もモニタリング対象です。深夜や休日の操作に気を付けたりします。また権限の設定漏れもあるかもしれません。時間帯や操作内容等をモニターします。

(図15)全ユーザーが行った処理を一覧にした例。処理時間も表示されています。

ここでは、仕訳データを作ったり、振込データを作成してダウンロードしたことなどが確認できます。

全ユーザーが行った処理を一覧にした例。処理時間も表示されています。ここでは、仕訳データを作ったり、振込データを作成してダウンロードしたことなどが確認できます。

③ 業務やマスターの追加・変更

 業務のテンプレートが変更されたり、ERPには登録されていない勘定科目や取引先を追加するなどコードやマスターテーブルが変更された時、その日時、担当者名などを一覧できます。

(図16)業務テンプレートやコードに対する監査証跡を表示した例。上段が、業務テンプレートの変更(業務の変更)、下段が、コードの変更(マスターテーブルの変更)を示しています。

業務テンプレートやコードに対する監査証跡を表示した例。上段が、業務テンプレートの変更(業務の変更)、下段が、コードの変更(マスターテーブルの変更)を示しています。

(2)CAAT(ブラックボックスアプローチ)

 CAATとは、Computer Assisted Audit Techniquesの略で、コンピュータ利用監査技法と訳されます。取引の生データ全件を対象に、一般的な不正のシナリオ、仮説をもとに統計的に分析して、異常値や非定型的なデータを抽出して精査し、必要な監査手続きを実行するものです。

 データの抽出には仮説やシナリオが必要になりますが、その企業固有の業務や規定の観点よりはむしろ、一般的な観点から抽出、分析を試みるものです。例えば、「取引日は決済日と同じか前の日付である」とか、「通常時間外の取り消し行為は怪しい」、「月初1日の口座間の振替はカイティング(口座間の資金移動によって預金残高の不足を取り繕い、残高証明書の整合をとる行為)の可能性がある」、「承認が必要な金額をやや下回る金額には不正取引が紛れていることが多い」などというものです。

 また統計的に、散布図を作って異常と思われる取引を抽出したり、偽りの数字を見破る方法としてベンフォード分析を用いたりします。ベンフォード分析とは、自然界にある大量のランダムなデータは、最初の桁には1が最も現れ、次の桁にはある頻度で2が最もよく現れるというように、一定の数字の出現頻度があるというものです。この法則と実際のデータを比べて、異常なパターンがないか探してみるという方法です。

 CAATを行うには、CAAT専用ツールもありますが、スプレッドシートでも行えます。

従来のチェックに比べて、全件検査ができ、本社でいつでもチェックすることができるという点がポイントです。

 

 モニタリングにしろ、CAATにしろ、「異常」とされたデータはあくまで、「正常」からはずれているということを語っているだけで、不正であるかどうかは、確認や調査が必要ですが、重要なのは、早期に発見することと、この活動を通じて現場に「見られている」という意識を植え付け牽制していくことです。

 

5. まとめ -リスク最前線に立つ財務部門

 一般的に、財務部門は企業の組織の中では、営業部門がフロントとして顧客の最前線に立ち、その後ろにサービス部門(ミドルオフィス)、その後ろにバックオフィスとあり、財務部門はバックオフィスになり、最も顧客から遠いところに位置付けられます。しかし、本項で見たように、現在の企業は、一歩間違うと企業を瓦解させかねない不正リスクに直面しています。このリスクに相対する財務部門も、フロントで不正から企業を守っていると言えます。一部の先進的な企業では、このような考え方に立ち、財務部門を営業部門と並びフロントに立つ部門と位置づけ、不正に正面から立ち向かっています。

 とはいえ、やみくもに財務部門のリソースを増やすことはできません。むしろ現行体制のまま、買収等により急拡大する事業をカバーしていくことが求められています。そうであるならば、ITの力を借りるほかはなく、内部統制の脆弱性を補いうるクラウドTMSを活用して、海外子会社の統制を強化してことが、現実的な解かと思われます。

 クラウドTMSは極めて有効なツールですが、一般に一つの指標や方法で全てに対応できるものがないように、不正についても複数の方法を組み合わせてモニタリングすることが肝要です。例えば異常値がないとしても、少額の不正を継続的に積み重ねている場合は異常値とみなせるほど乖離しないためわかりません。モニタリングされていることを知っている不正実行者は、異常値が出ないように不正を実行するでしょう。「同じ方が却って怪しい」という不正の専門家もいます。モニタリングを複数の視点や方法で改善しながら継続的に地道に実行していくことが、不正リスク対応の近道ではないでしょうか。

 

海外子会社の内部統制 Part1(現状・内部統制の脆弱性・不正のトライアングル)>>