ココナラ会計システムの話
株式会社ココナラ DevOps開発グループ/業務システム開発チーム所属のもりしたです。
今回はわたしのチームが主に担当している会計システムについてご紹介したいと思います。
会計システムって？
ココナラにおける会計システムは大きく３つの役割を持っています。
- お金の動きを記録する
- 集計情報を提供する
- 正確性を担保する
ココナラスキルマーケットでの取引ごとに発生するお金の動きを会計観点で記録し、さらに取引単位（※）で記録したお金の動きを月単位で集計します。
記録および集計された会計情報は経理担当が行う月次決算の業務にて正しいことを検証します。
前者の２つはシステムが自動的に行いますが、３つ目は経理担当が利用する仕組みの提供となります。
なお、ここでの取引は "購入者がサービスを購入し、購入者と出品者がやりとりを行い、出品者が納品する" といった一連の取引を指しています。
３つの役割の詳細は後ほどご紹介します。
※ 実際にはユーザー単位で記録するケースもあります
システム概要
こちらがざっくりとしたシステム概要となります。
サービス購入を起点とした例としての概要です。点線は手動でのオペレーションが発生している箇所です。
会計システムはスキルマーケットに関わる処理を行うサービス群とは切り離された独立したサービスとして稼働しています。
図では大きく表現していますが、実際は小さいサービスです。
内部からのリクエストを受けるAPIエンドポイントをいくつか提供していますが、大部分はスケジューリングで定期的に動くバッチ処理です。
余談☕
この記事では詳細を割愛しますが、会計システムは次のアーキテクチャを採用しています。
- 会計システムのサービスは AWS Fargate にてサーバーレスコンテナで稼働
- バッチ処理は Amazon EventBridge スケジューラを利用して、スケジューリング実行
会計システムがやっていること
会計システムって？で挙げた３つの役割をご紹介します。
お金の動きを記録する📝
会計システムの１つ目の役割はお金の動きを記録することです。
こちらは業務システムチームという仕事を紹介したいでも触れた内容となります。
ココナラで発生するお金の動きを会計イベントという単位に分解し、会計イベントごとに仕訳情報を記録します。
会計システムはPULL型の仕組みで動きます。
スキルマーケットにてサービスを購入した際の決済情報などが記録されているDB（以降、ココナラDB）を定期的に参照して情報を取得し、取得した情報を整形して会計イベントとして会計DBに記録します。
会計イベントごと複式簿記の形式にて仕訳情報を生成し、同じく会計DBに記録します。
具体例
"500円のサービスをユーザーが購入し、購入代金がココナラに入金されるまで"を例として会計システムに記録される情報を追ってみます。
- サービス基本料金: ¥500.0
- サービス手数料: ¥28.0
会計イベントが発生
- ユーザーがサービスを購入し、出品者と購入者間でやりとりを行うトークルーム画面がオープンする
サービス購入内容を確認 - トークルームオープン後、出品者からの役務提供（＝納品）が完了してトークルームがクローズする
トークルームクローズ - サービスの購入代金が決済代行会社を介してココナラに入金される
会計イベントごとに仕訳情報を記録する
| 会計イベント | 借方科目 | 金額 | 貸方科目 | 金額 | イベント日時 |
|---|---|---|---|---|---|
| オープン | 仮売掛金 | ¥528.0 | 仮売上 | ¥528.0 | 2024-06-11 10:00:00 |
| クローズ | 仮売上 | ¥528.0 | 売上 | ¥138.0 | 2024-06-18 15:00:00 |
| クローズ | - | - | 預り金 | ¥390.0 | 2024-06-18 15:00:00 |
| 入金 | 現金 | ¥528.0 | 仮売掛金 | ¥528.0 | 2024-06-31 00:00:00 |
※ 実際には会計イベントと仕訳情報は別テーブルで情報を管理しています
- トークルームオープンの時点では役務提供は完了していないため、仮売上として記録する
- 役務提供の完了によりトークルームがクローズしたため、仮売上を売上に振り替え
- 入金により仮売掛金はなくなり、現金が増加する
このように会計システムでは会計イベントという単位で仕訳情報を記録することでお金の動きが追えるようになっています。
集計情報を提供する📊
会計システムの２つ目の役割はお金の動きを集計し、集計した会計情報を経理担当に提供することです。具体的には下記に記載する２つの形式で集計情報を提供します。
- 会計レポート
- 決済代行会社ごとの集計データ
画面イメージ
集計情報を参照する画面のイメージです。社内の管理システムより閲覧することができます。
会計レポート
決済代行会社ごとの集計データ
- 会計レポートは役務完了、入金といった会計イベント単位で集計する
- 決済代行会社ごとの集計データは会計レポートをさらに決済代行会社の単位でより細かく分解して集計する
基本はお金の動きを記録するで記録した仕訳情報を集計するのみですが、例えば入金イベントでは集計時に次のような組み替えを行います。
- トークルームがクローズする前に入金が確認できた取引の場合
┗ 勘定科目「売掛金」を「前受金」に組み替え
基本としてトークルームは最大120日オープンできるため、購入代金は役務提供が完了する前にココナラに入金される場合があります。その場合、購入代金を先に受け取る形となるため、入金された金額は「前受金」として扱います。
集計情報はさらに整形を行い、帳簿として会計ソフトに取り込みを行います。
正確性を担保する🚔
最後の３つ目の役割は会計情報の正確性を担保することです。
会計情報は決算短信、決算説明資料などにて開示するため、正しいものである必要があります。
正確性の担保は月次決算のタイミングで行います。
会計DBとココナラDBに格納されたデータを比較して検証します。比較の結果、差異を発見した場合、経理担当は原因を特定し、適切に会計処理を行います。
システムとしては、経理担当が利用する仕組みとして下記の２つを提供します。
- ムーブメント
- 決済照合
ムーブメント
ムーブメント（英語：movement）はココナラでの主要な勘定科目である売掛金、前受金、預り金などについて、残高検証を行う仕組みです。月毎に残高の推移を検証するため、ムーブメントという名前となっています。
この図は売掛金・前受金ムーブメントのイメージです。
会計システムが記録した帳簿に相当する会計DBのデータと帳簿の元となったココナラDBのデータを比較して金額が一致することを検証します。
この図に登場する決済代行会社については会計DBに格納されたデータを利用して比較を実現しています。事前に決済代行会社のシステムに記録された入金データをココナラの会計DBに取り込み、このデータをムーブメントで利用しています。
残高検証は下記に記載する推移と理論値を比較して行います。
- 推移：会計DBに計上している金額を推移と呼んでいる
- 理論値：ココナラDBに記録された決済情報などを元に作成した "こういう状態となっているはず" という金額を理論値と呼んでいる
入金の仕訳情報は決済代行会社が元データとなるため、ココナラDBには入金に関する情報がありません。理論値は想定で作ります。
突合する推移と理論値のデータを収集し、最後に取引単位（預り金はユーザー単位）で金額を比較。差異があれば検証結果のテーブルに出力します。
ムーブメント結果テーブルのイメージ
| 対象年月 | 取引ID | 推移金額 | 理論値金額 | 差異 |
|---|---|---|---|---|
| 2024年5月 | 11111111 | ¥0 | ¥1,000 | ¥1,000 |
| 2024年5月 | 22222222 | ¥2,000 | ¥0 | ¥2,000 |
| 2024年5月 | 33333333 | ¥4,000 | ¥1,000 | ¥3,000 |
例） サービス購入代金の支払い完了日「2024/6/1」の取引を検証する場合
2024/6/1 に支払い完了したのであれば、 2024/6/末 に入金される想定 ← これが理論値となる
- 実際の入金情報が含まれる推移と比較した結果、想定どおりに入金があれば、検証OK
- 入金の事実なし、もしくは想定とは異なる日付で入金される場合は、差異が発生。検証NG
- 検証NGとなった場合、経理担当は差異の発生原因を特定します
差異が発生するケース
次のような月を跨ぐ時間帯で決済が行われた場合には稀に差異が発生します。
※この例によるユーザー影響はありません
- 2024-05-31 23:55：ユーザーがコンビニにてサービス購入代金をお支払い
- 2024-05-31 23:55：決済代行会社にて決済情報を記録
- 2024-06-01 00:01：ココナラにて決済代行会社が決済完了となったことを受け、トークルームをオープンする
ココナラで決済完了と認識した日付と決済代行会社の決済日時でズレが発生し、想定する入金日が変わってしまうことによってムーブメントで差異が発生します。
決済照合
決済代行会社とココナラ間で入金および返金の金額が一致していることを検証するのが決済照合です。ムーブメントが売掛金などの勘定科目の視点で正確性を検証しているのに対して、決済照合は入金・返金という現金に着目した検証を行います。
事前に決済代行会社の入金データ（返金も含まれる）はココナラの会計DBに取り込むため、ムーブメントと同じくココナラDBと会計DBのデータを利用して比較を実現しています。
決済照合は決済代行会社に記録された入金額とココナラが期待する入金額が一致しない場合に差異として照合結果を記録し、経理担当に通知します。
差異が発生するケース
発生しうるケースとしては、一部入金・超過入金があります。
サービス購入時の支払い方法として銀行振込が選択された場合、ユーザーはご自身で金額を指定して振込を行います。
このとき、実際の購入金額と異なる金額を振り込むことができるため、少なければ一部入金、多ければ超過入金が発生します。
さいごに
これまでご紹介した会計システムですが、まだまだ改善の余地があります。
例えば、正確性を担保するであげたムーブメントですが、ココナラの会計システムと会計ソフト間では手動で残高検証を行っており、自動化は残高検証全体のうちの半分ほどしかできていません。
そのほかにも決済代行会社からの入金データの取り込みなど手動での運用が多くあります。
トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。
（引用元：SRE の原則に沿ったトイルの洗い出しとトラッキング）
Googleが提唱するトイルの定義は SRE (Site Reliability Engineering) の文脈で語られていますが、会計システムを利用する経理・会計業務のような非エンジニアが行う業務にもあてはまる部分があります。
同じ繰り返しを行う手作業は自動化して業務負荷を減らすため、日々小さいものから改善を進めています。
このような改善を一緒にやってみたいと少しでも興味を持っていただけましたら、以下のカジュアル面談応募フォームからご連絡をいただけますと幸いです！
エンジニアの募集求人については下記のリンクからご確認ください。
Discussion