月末に発生しがちな業務システム上でのデータの不一致 【部門間の処理の基準やタイミングの違いが原因】

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

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

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

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

元帳(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のデータ修正は為替評価替もキャンセルした上で行なわないと修正分が月末評価額に反映されなくなるので、イレギュラーな修正処理の運用手順を明確にしておく必要があります。