ITシステム設計者が経理を知っているとみんなが幸せになる②
今回はクレジット決済について整理してみたいと思います。
今回の説明は粗いですが、大局の説明になりますのでご容赦ください。
仕組みは大きく２つ
クレジットカード決済では大きく２つの仕組みがあります
債権買取型
決済代行型
この２つの仕組みは経理処理にとって大きな違いがあります。
債権買取型
お客さんが決済が完了した時点で、その売り上げは販売者側に移転します。
お客さんの決済処理が完了した時点で、販売者が債権、お客さんが債務を持ちます。
決済事業者が販売者から債権を買い取ります
決済会社は販売者に買い取った債権の金額を支払います（実際には手数料を引いた金額を入金します）
決済会社がお客さんから入金（お客さんの債務弁済）を受けます
販売者から見た場合のメリットは、お客さんの支払いが滞ったとしても確実に売り上げ入金を得られるということになります。
googleのPLAYストアや、一部のクレジットカード決済などがこのタイプとなります。次に説明する決済代行型でのリスクを販売者が負わなくて済む仕組みです。
決済代行型（回収代行型）
お客さんが決済を完了しても、実際の入金は確定しません
お客さんの決済処理が完了した時点で、販売者が債権、お客さんが債務を持ちます
決済会社がお客さんから入金（お客さんの債務弁済の代理受領）を受けます
決済会社は販売者に代理受領した債務弁済金額を支払います（実際には手数料を引いた金額を入金します）
決済会社は決済の代行（回収の代行）を行うのみで、販売者への入金はお客さんからの入金後となります。この場合、例えばクレジットカード決済でお客さんの口座からの引落が出来ない場合には、販売者への入金が発生しません。
appleのappleストアや、携帯キャリア課金（docomo、au）、一部クレジットカード決済がこのタイプとなります。
経理の観点での流れ
経理処理では以下の流れでお金の管理を行います。
売買契約の成立（お客さんが購入意思を示し、購入が合意）
売買契約に従い商品の発送 ⇒ 売掛状態
お客さんからの入金を受領 ⇒ 売掛解消（取引完了）
経理としてはお客さんからの代金が会社口座に移転した段階で取引が完了したと見なします。商品の発送から入金完了までの間は売掛という状態になり、その状態での未回収の代金を売掛金として処理します。
この売掛金という勘定科目は企業の事業・経営状態を表す貸借対照表によく表示される項目です。
売掛金は、販売したが代金をまだ受け取っていない金額になります（その対になるのが買掛金です。商品を購入受領したがまだ代金を支払っていないもの。月末払いとか翌月払いなどが例となります）
そのため、経理は以下の2種の数字を求めて来ます。
成立した売買の金額
未回収の売上金
上場企業であれば3か月ごとで短信として貸借対照表を作成・公表が必要ですし、非上場の企業であれば決算期（年に1度）には必要になります。
ITシステムとしては、これらの数字は必ず保持しておきたいですね。
売上金の未回収
さて、通常であれば販売の当月もしくは翌月に販売代金が回収出来るというのが想定されるとは思いますが、状況によっては
翌々月以降の回収
お客さんが支払わずに逃げる
のケースが想定されます。約束された期限までに支払われない場合、別の経理処理が発生することになります。この期限は企業ごと事業ごとで個別に設定されます（企業の会計士と調整）が、期限を過ぎた場合には損益計算書にて貸倒損失という別の勘定科目で処理をすることになります。
この貸倒損失がどれくらい発生するかを事業計画で予測しますが、その予測額を貸倒引当金として予算化し、貸倒損失が発生した場合にはその引当金から減算していくことになります。
回収期間は決済会社ごとであらかじめ決められます。例えばある決済会社の場合、3か月分まで未回収分を追跡しますがそれ以降は回収不可能として回収を断念したり、別の決済会社は1年間は未回収分を追跡するなど、決済会社により異なります（この期間は決済会社との契約書に通常は記載されます）
販売企業にて決められた期間内に代金回収が出来ない場合には貸倒損失として計上され引当金から減算して決算しますが、それ以降（決算が閉まった後）に回収できた場合には、雑収入として計上する場合が一般的となり、経理上は異なる勘定科目で処理されます。
ITシステムとしての準備
経理処理では回収期間や決算時期により勘定科目の使い分けが異なるというのは理解できると思いますが、経理に対して数字を提供するITシステムはどんなデータを持っておけば良いでしょうか。
実はそれほど複雑ではありません。保持しておくデータは
取引の成立日（一般的にはお客さんが購入をクリックし、決済会社の承認が完了した日）
取引に紐づいた販売代金の回収額と回収日
の2つのみです。ただ実際の設計で考慮するのが一つ目と二つ目を取引ごとで連携出来るデータとして保持できるかとなります。
通常の決済会社のシステムを利用する場合、決済ごとでのユニークな番号が発番され（もしくは販売会社の取引番号を受け入れることが出来）、その管理番号にて回収の情報を取得することが出来ますが、一部の決済会社ではその処理が出来ないものがあります。
appleストアなどが代表例となります。この場合には経理と事前に調整を行い、（取引と代金回収が一意には連携出来ないので）見なし連携という手段をとるなどの事前設計が必要となります（見なし連携の方法は決済会社から提示を受ける管理情報に依存しますので、個別設計となります）
おわりに
商品販売などの取引の場合、特に決済のイレギュラー処理を事前にどこまで考慮しておくかが、イケてる設計かどうかになります。
代金回収が遅れる場合、また代金が未払いのままで終わる場合など、取引の後続になる社内業務（今回の場合は経理）の処理を理解することで、想定されるイレギュラーを設計に盛り込むことが出来るようになります。
社内の他部署からもイケてる判定をもらい、幸せなエンジニアライフを過ごしましょう。