|
売上(営業収益)の種類の把握とデータ投入経路の決定
|
◆製品あるいは仕入商品の販売に関する売上データの入力経路については、販売管理→AR→GLで議論の余地がない。しかし、以下のような売上データについては、どのモジュールからデータを投入するかの決め方によって業務フローが変わってくる。
・ 物販売上に付随する役務売上（据付料、輸送料など）
・ サービス売上その他（保守契約料、ロイヤリティー、修理料、コミッション売上）
◆物販に付随する役務売上は、物販部分と一緒の受注に含まれ、同じINVOICEに含めて請求することが多い。そのため、販売管理側でデータ投入されることになるのが普通。ただし、役務には出荷という行為がないので、売上を計上するタイミングをどうコントロールするか検討が必要となる。IFRSの収益認識基準との関係もクリアする必要がある。
◆相手先別の債権補助簿（得意先元帳）はARで管理するので、GLから直接営業収益を計上するのは極めて限られる。
◆売上の勘定科目が細分化されており、販売管理側から実績が連携されてくる売上についても科目を切り分ける必要がある場合は、その切り分けのロジックを確実に把握した上で業務フローとシステムの処理内容を確定する必要がある。
◆売上の粗利管理（売価と売上原価のヒモつけが必要）がどのレベルまで要求され、そのためにシステムが行うべきことを見定める必要がある。先に述べた物販売上に付随する役務売上やサービス系売上が難しくなることが多い。
|
|
売上減額データの種類の把握とデータ投入経路の決定
|
◆基本的にはプラスの入力をした入口と同じところからの投入になる。
◆減額データは投入経路だけでなく、投入の仕方についても検討が必要になる場合がある。たとえば、複数明細の物販売上に対し値引きが発生した場合、それをまとめて1行の明細として入力することを許すか、売上の明細単位に値引き額を分割して投入するルールにするかといったケースである。これらは利益管理のメッシュと精度をどう設定するかという問題になる。
◆契約に基づいた体系的な売上リベート（売上割戻）が存在する場合には、リベート金額を算出するための仕組みが別途必要になるケースが多い。その場合は、リベートデータを利益管理にどう連携するかがより重要になってくる。
◆売上減額の証憑名については、購入側が発行すればデビットメモ（デビットノート）、販売側が発行すればクレジットメモと呼ばれる。購入者は買掛金を管理しており総勘定元帳では買掛が増えると貸方に記載する。しかし、返品が発生すると借方に記載されるので、借方＝デビットでデビットメモとなる。販売者側は売掛金を管理しているので、返品は貸方記載になるので、貸方＝クレジットでクレジットメモとなる。
|
|
売上計上基準（出荷基準、検収基準）の確認
|
◆IFRSの収益認識対応を含めて、計上基準に応じたフローを検討しなければならない。
◆輸出がある場合は売上計上基準だけでなく特別な業務フローが必要になる。
|
|
顧客との消費税まるめ誤差の調整方法
|
◆消費税額は基本的にシステムで計算をする。そのため、システムが異なると端数の丸め処理で差が出ることを覚悟しなけれならない。その差異を調整する手順を検討しなければならない。
◆販売側と購入側が計算した消費税額に差がある場合、消費税額に対し補正処置が必要であるかどうかは、販売側と購買側が共通に認識している証憑にどちらの金額が記載されているかによる。購入者が大企業である場合、自社の検収額（消費税額も含め）を相手先に通知したうえで一方的に支払ってくるケースが多い。その場合、売上証憑であるの納品書も購入側が発行していることが多く、販売側の計上金額もその金額を合わせざるをえない。
◆中国ではINVOICE（発票）の発行が自社のシステムではできない。そのため、端数で差が出たときは証憑の税額を正とせざるをえないので、そのため端数処理に差が出る前提で業務フローを考える必要があった。
|
|
入金消込を行う部門の確認
|
◆システムで把握されている債権データの入金予定日が正しくメンテナンスされていない場合、および顧客の支払が個別の債権と対応していない場合（＝債権の明細を合計した請求額が100万であるにもかかわらず、個別の明細とは無関係に80万だけ支払うといったケース）、会計部門で消込を実施することは難しい。
◆そのような場合、会計部門は入金入力だけを行い、消込は売上を計上している営業部門で行うという業務分担も考えられる。
|
|
入金消込キーの確認
|
◆消込のキーとなるのは、以下のようなものが考えられる。
・顧客注文番号、INVOICE番号、自社の受注番号
◆上記の消込のキー情報（＝債権のキー情報）は基本的に販売モジュールで管理されるデータである。そのため、販売モジュールからARへのインタフェイスでそれらのデータが適切に連携される仕組みにしておかないと入金消込業務が成り立たなくなる。
|
|
顧客からの検収通知あるいは支払通知の取扱い
|
◆顧客が支払に際して、自社の検収明細（＝支払対象明細）を通知してくるケースがある。その場合その情報をどう扱うかについての業務フローが必要。
◆顧客側は基本的に通知した検収明細に従って支払を行うので、この情報を適切に扱えば、顧客側の債務と自社の債権の認識を一致させる業務フローを作ることができる。
|
|
債務との相殺があるかの確認
|
◆顧客との債権債務を互いに相殺することある場合には、特別なフローが必要となる。顧客に対し売上だけではなく、何らかの仕入や費用計上が発生していることが前提となる。相殺がよく見られる例としては以下のようなものがある。
・外注加工先に材料を有償支給している場合
・販売先に販売手数料を支払う場合
◆システム的な対応としては、相殺勘定で債権を消しこむ入金タイプを設定し、入金処理をすることが多い。この場合、債務側でも相殺勘定で支払うことになるので、相殺勘定の残高が残っていないかを確認する手順が必要となる。
|
|
前受金を請求するケースがあるかの確認
|
◆前受の承認→前受金請求→前受金入金→（売上）→前受金充当の業務フローを確定する必要がある。
|
|
残高確認業務に対するシステムサポートの要否
|
◆確認する側と確認される側の両方があるが、両方とも月末時点での残高とその明細の把握ができればよいということであれば、特別なシステムサポートは不要となる場合が多い。
|
|
与信管理業務への対応
|
◆与信管理の作業ボリュームが大きく、顧客の評価や与信限度額の設定および与信チェックをシステム的に処置する必要があるかどうかがポイント。
◆与信管理に必要な情報は、厳密に言えばARで管理する債権以外に販売管理側で把握されている受注残やAPやGLで管理されている債権債務も含まれる。それらを勘案した上で、与信限度額と突合し、その結果で受注の入力時や出荷時に警告を発することが必要となる。
|
|
得意先元帳の管理方法の確認
|
◆得意先元帳を紙の形で出力し保管しなければならないかを確認する必要がある。
◆必要な場合、システムが提供している機能の帳票でよいかどうかを確認する。保管する義務があるという場合、とにかく出力されておればよく体裁はあまり問題にならないことが多い。
|
|
業績管理へのデータ提供の必要性の確認
|
◆ARで管理しているデータから、部門別、業種別、セールスマン別等の業績管理へ提供しなければならないものが何であるかを確認する必要がある。
|