財務会計/支払条件
債権/債務について、支払基準日をベースにした支払期日を求めるための項目。
概要 †
名称は「支払」条件だが、債務についてだけでなく債権の回収条件も包含し、大きくは基準日・締め日・サイト・支払方法(回収方法)の4つの要素で構成される。
基準日は転記日付と伝票日付のいずれかであるか、締め日は単に20日締めであれば20など日にちをDDの形で入力し、サイトはそこからの日数となる。
実務における支払条件 †
よくあるものを挙げていく。
電信為替送金 †
電信送金、電信振込などと呼び、買い手が売り手の指定銀行に電信で振り込む。 Telegraphic Transfer Remittance、T/T Remittanceなどと表記する。 T/T Remittance in Advance paymentといって、前受金請求をしたりもする。
送金手数料・経由銀行手数料・口座振替手数料等が発生するため、売主と買主のどちらが負担になるかは重要な決めとなる。
L/C †
買い手の代金決済を銀行が保証する書類で、Letter of Creditと表記する。 詳細は、信用状参照のこと。
D/P †
Documents against Paymentと表記する、手形決済で信用状がないもの。 決済方法の流れはL/Cと一緒だが、銀行は買い手の代金決済について何ら保証も義務も負わない。
サイトが無く、引き受け時に引き落としがある。
D/A †
Documents against Acceptanceと表記する、手形決済で信用状がないもの。 決済方法の流れはL/Cと一緒だが、銀行は買い手の代金決済について何ら保証も義務も負わない。
こちらはサイトがあり、決済が遅れると金利負担がある。
つまり、得意先決済の遅れに対するリスクを自社が持つことになるため信用していないと無理なわけだが、インドや中国などではT/Tは為替が厳しくて使えないケースもあること、またリスクを銀行が持つL/Cよりもハードルが低いために利用されるという側面がある。
SAPにおける支払条件 †
SAPでの、支払条件もろもろについて。
マスタとの関連 †
伝票入力時に提案するため、得意先マスタの会社ビューおよび販売ビュー、仕入先マスタの会社ビューおよび購買ビューに保持する。
ロジ側では販売ビューおよび購買ビュー、会計側ではそれぞれの会社ビューが読み込まれる。
粒度について †
なお、私見だが、定義するにあたってはテキストにB/L DateだとかDelivery Dateなどの「基準系」は含めない方が良いと考える。 理由は、SAPにとっては入力者が転記日付や伝票日付といった値の誘導元あるいは支払基準日や有効日日付といった直接指定する項目に何を入力するかという違いしか無いにもかかわらず、内容が重複したコードが山積するためである。 そうなってしまうと、検索ヘルプを使っても入力者が混乱してしまうし、販売側での現金値引ソリューションをはじめとした支払条件のコードそのものが機能に登場する場合、あるいはレポーティングの切り口となる場合に、覿面に煩雑になってしまう。 外部帳票への出しっぷりという話であれば、見栄えの問題もあるが、コメントなりフリーテキストに入れるのが吉かと思う。
統制について †
ある顧客で、「マスタから提案された支払条件以外使うのはダメ。統制上の問題がある」というReqirementがあり、経理のおばちゃんが煩く口にしていた。
はっきりいってそれは拡大解釈しすぎである。 言わんとしていることはわかる。会社同士の契約であれば、基本的にはBaseのtermがあるので、それが変わることはあまりなく、変更するとしたら取引先に便宜を図ったりしているに違いない!とでも言いたいのだろう。 例えば自社の経費支払いであれば、支払い条件に差をつける理由はない。
しかし、営業活動(本業)においては必ずしもそうではなく、担当していた商社ではtradeごとにいくつかの支払条件を使い分けていたのだが、単にそういった相手先あるいは商いであればokだし、そうでなければNG*1という話であり、半分定型のような商いをする相手先か否かという観点が抜けていたのだ。 支払条件のコード自体の粒度にもよるが、履歴も残るし後々トレースすることもできるため、極端に言えば、別にどうだっていいのだ。 早期に支払う代わりに安くしてもらったり、入金がずいぶんと先になる代わりに有利な条件での商いができることもある。
もちろん、資金繰りの予測などの観点から言えば統一されているに越したことはないけれど、あまり統制やコントロールという言葉に振り回されないようにしたい。
コメントはありません。 Comments/財務会計/支払条件