会計システム

月末に発生しがちな業務システム上でのデータの不一致 【会計監査と業務監査】

2015/12/08

月末に発生しがちな業務システム上でのデータの不一致

インドネシアの日系製造業で、業務システムを運用する中で発生するデータの不一致(discrepancy)とは、債権債務残高とGL上での残高の不一致であったり、債権一覧と売上の不一致であったり、業務システムの機能間連携の問題であることがほとんどです。

部門間でデータの不一致が発生するケース

業務システムは会社の各部門担当者が、自分の業務に必要な機能だけを利用し、入力された情報が上流から下流にリレーされていくのですが、その過程で部門間でのデータの不一致が発生するケースがあります。

ただしデータの不一致はシステムの不具合から発生したものではなく、各部門ごとに入出力の仕方やタイミングが違うことによるケースがほとんどであり、解析していくとおおよそ以下のような原因に集約されます。

元帳(G/L)上の債権(A/R)債務(A/P)残高と年齢表(Aging Report)上の残高が異なる

理論上はG/Lで繰り越される月初A/R科目とA/P科目残高と、Aging Report上での前月末残高は一致するはずですが、実際は一致しないケースがほとんどです。

  1. A/PとA/RをG/Lから直接入力している
    ⇒値引きのためのデビットノート(Debit note)や値増しのためのクレジットノート(Credit note)の仕訳をG/L上で入力することで発生します。
  2. A/PとA/Rの仕訳生成が転記(Posting)前の承認時に行なわれる仕組みになっている。
    ⇒締め処理時にA/PとA/Rの承認済み未転記取引をチェックする必要があります。

複数部門にまたがるA/RとA/Pが発生しているとき

業務システムのデータの不一致は、A/PとA/R残高とG/L残高が合わないことで発覚することが多いのですが、合計金額自体が合わない場合と、合計金額は合っているものの取引先単位の集計金額が合わない場合があります。

A/PとA/Rを取引先ごとの金額を調整して合わせるには、資産の部門別振替と同じように、勘定科目を分割した上で、特定の月末時点にカットオフして相殺仕訳を作成します。

  • Dr. A/P(取引先コードA) 10    Cr. A/P(取引先コードM) 30
  • Dr. A/P(取引先コードB) 10
  • Dr. A/P(取引先コードC) 10

前受金が工事完成基準で処理される場合のA/Rと売上(Sales)の不一致

営業担当者であれば、当月のSalesがどのA/Rから発生しているか照合し、A/Rから受注に遡ることで、Salesがどの受注から発生したものか照合しようと考えるでしょうが、当然ながらG/L上に表示されるSales一覧は、該当月のA/R一覧と必ずしも一致しません。

営業担当者から報告される返品処理や値引処理は、Credit Noteで元データであるA/R情報から修正することができますが、外貨建てA/Rの為替差損益や税務差額の調整仕訳は、会計担当者が独自裁量でG/Lの振替伝票で行なうため、ここでA/R情報とG/L上のA/R科目残高の差異が生じます。

またサービスが工事完成基準で処理される場合、顧客から払い込まれる前受金はSales勘定ではなくDown Payment勘定で処理されており、これが翌月になってSales化する場合には、月ベースでSalesとA/Rを比較しても一致しません(A/R過多)。

  • 前受金受領時
    Dr. A/R 100 Cr. Down Payment 100
  • 工事完成時
    Dr. A/R 40 Cr. Sales 40
    Dr. Down Payment 100??Cr. Sales 100

締め処理後のデータ調整

月末に為替評価替処理を行ない、締処理まで実行した後に「このInvoice、支払い済みなのに入力し忘れてたー」というのはよくあることです。

この場合、締処理をキャンセルして為替評価替処理をキャンセルしてから、Invoiceの決済処理行い、改めて為替評価替して締処理を行なう必要があります。

この運用手順が明確でないために、為替評価替処理をキャンセルせずにInvoiceの修正を行なってしまうと、修正入力が為替評価替に反映されないことになります。

  1. 11月末のドルA/Rのルピアベース残高:100
  2. 11月末の為替評価替え後ルピアベース残高:110
  3. 本来なら100に対して修正をかけるべきところ110に対して修正をかけることになる。

締処理がズレ込みA/RとA/P決済処理をフライング入力

月末時点でのA/P残高を月末レートで再評価するのが為替評価替ですが、締処理は翌月までズレるのが普通なので、その間に消し込み処理を行なってしまうと、月末A/P残高が変わってしまいます。

  1. 11月末のルピアベース残高:100
  2. 12月1日の決済処理入力後残高:90
  3. 本来なら100に対して為替評価替えすべきところを90に対して行なうことになる。

考えられる対策

実現と未実現の勘定科目を分ける

為替差損益は決済時に、A/P発生時レートと決済時レートの差に基づく実現損益と月末評価替時の未実現損益の2種類ありますが、これらは勘定科目を分けておかないと為替差損益の原因となる取引をトレースバックする際に絞込みにくくなります。

  1. Forex Gain-Realized
  2. Forex Loss-Realized
  3. Forex Gain-Unrealized
  4. Forex Loss-Unrealized
会計システムで対応すべき機能通貨と表示通貨
会計システムで対応すべき機能通貨と表示通貨とは?【インドネシアの国内取引はルピアベースが原則】

会計業務の中では外貨から機能通貨、表示通貨という為替換算の流れがあり、その際に決済時の実現為替差損益(発生レートと決済日レートの差額)と月末の未実現為替差損益(資産負債項目を月末レート換算による差額)、そして機能通貨から表示通貨へ換算する際の差損益(資産負債項目は月末レート換算による差額)が発生します。

続きを見る

システム上は為替差損益仕訳が決済で発生したものか、為替評価替で発生したものかの区別はつきますが、一般会計上では勘定科目や取引先でしかフィルターできないのが普通ですので、科目自体を上記のように分割するほうがいいです。

イレギュラー処理の運用手順の明確化

締処理後のA/RとA/Pのデータ修正は為替評価替もキャンセルした上で行なわないと修正分が月末評価額に反映されなくなるので、イレギュラーな修正処理の運用手順を明確にしておく必要があります。

外部監査人による会計監査

一般的に監査と言えば会計監査法人による会計監査を意味することが多いですが、この法定監査を義務付けられているのは会社法で規定されている大会社のみです。

ただこの大会社の定義が「資本金5億円以上または負債200億円以上の会社」というもので、会社の成長に伴って監査義務対象に入ったり、衰退にともなって対象からはみ出ることになります。

非公開会社であっても会計監査人(監査法人や公認会計士)の監査を受けなければならない(会社法328条)という法律がある以上、対象となる大会社が法定監査を行なわなければ法律違反で罰金の対象となりますが、現実にはグレーな運用になっていると思います。

インドネシアの場合、外国資本会社(PMA)はすべて大企業扱いされますので、日本では中小企業に該当する場合でも、PMAである限り外部監査を受ける義務が生じます。

ピータードラッガー的に言うと企業は社会の公器であるとはいえ、財務諸表の悪化は銀行審査や株価といった金融要素や入札条件等の営業要素に影響を及ぼすため「如何にブラックボックス化するか」「如何にキレイに見せるか」という、グレーゾーン周辺で無理に無理を重ねて財務諸表を作成する習慣出来上がり、たまたま東芝問題みたい表面化したときには不適切会計と言うこれまたグレーな言葉が生まれたのだと思います。

外部業務監査と内部監査

本来監査とは外部監査人による会計監査を指すことが多いのですが、JSOX(2006年に成立した金融商品取引法の中の内部統制に関するルール)制定以来、内部統制による社内コンプライアンスの遵守を評価する業務監査も社会的に重要視されています。

業務監査とは企業の会計業務以外の業務活動(購買・生産・物流・販売など)、および組織・制度などに対する監査ですが、直接的であれ間接的であれ、最終的には財務諸表の適正性の保証による株主保護に結びつきます。

  1. 会計外部監査:直接的に財務諸表の健全性を保証する。
  2. 業務外部監査:ISOやJSOXに照らして内部統制による社内法令の遵守が適切であることを保証する。
  3. 内部監査:ISOやJSOXに照らして内部統制による社内法令の遵守が適切であることを保証する。

また業務がシステム化された現在では内部統制の評価にIT統制が必須であり、インドネシアでも業務監査の際にERPシステムについて質問を受けるポイントは以下の3つに絞られます。

  1. 承認フローが適正かどうか
  2. システムへのアクセス権限が適正に設定されているかどうか
  3. オペレーションマニュアル、運用マニュアル等のドキュメントの有無

インドネシアの会計コンサルタント会社の仕事

インドネシアの日系製造業では会計コンサルタント会社と記帳代行契約や会計アドバイザー契約を結んでいるところが非常に多いため、会計システムを導入する際には必然的に月末の締め処理後に出力する財務諸表が正しいかどうかは会計コンサルタント会社が作成する財務諸表と照合します。

また会計システム利用開始(インドネシアではよくGO LIVEという言葉が使われる)の際に必要になる期首残高は、会計コンサルタント会社が作成する試算表(Trial Balance)に基づいてシステムにインポートまたは振替伝票で入力します。

インドネシアの会計コンサルタント会社は規模の大小はあれ、業務内容としては以下のように大別されます。

  1. 外部監査(会計監査・業務監査)
  2. 会計記帳代行・給与計算代行
  3. 税務サポート(PPH、PPN、関税など)
  4. ビザ・会社設立支援

日系企業にとって一番馴染み深いのが通称JAC(Japan Asia Consultant)さんですが、僕もここの代表の方の著作3冊(会社経営・税務・会計)は座右の書として常にデスクの上に積んでいます。なんせ自宅のデスクは小さいもので・・・。

会計システム導入時に必要になる会計コンサルタント会社のデータ

会計コンサルタント会社と契約している客先に会計システムを導入する際に必ず発生する問題がありますが、僕はこれを3つのアンマッチと勝手に呼んでいます。

  1. 期首残高のアンマッチ:提出後に手元データを修正するとこうなる。
  2. 勘定科目のアンマッチ:月中のデータ入力時にオペレータを悩ませる。
  3. 期首残高が揃うタイミングのアンマッチ:システム導入スケジュールに影響する。

会計コンサルタント会社にデータを提出した後に、社内で迷子Invoiceが発覚する場合、会計コンサルタント会社に対してデータの修正依頼が間に合わずに、社内のInvoiceベースの債権債務残高と会計コンサルタント会社から送られてくるGLの債権債務科目残高が合わなくなり、原因究明に時間がかかります。

また会計コンサルタント会社はインドネシアの会社法に照らして正しい財務諸表を作成することが任務ですので、多くのクライアントを抱える以上、管理負荷を抑えるためにはなるだけ共通の勘定科目を使用するほうがいいわけで、これは仕方のないことだと思います。

ただし手元の勘定科目とのマッピングで不十分である場合、会計入力担当者がグレーな取引をどの勘定に入れたらいいのか分からなくなり、月末に科目別残高の照合が出来なくなり、必然的に締め処理も出来なくなります。

そして前月の締め処理後の確定データが届くのが早くても翌月の20日前後になるため、システム導入プロジェクトを作成する管理者のスケジュール管理が難しくなります。

© 2021 バテラハイシステム Powered by STINGER