2024/12/22

PaymentPlatformにおける仕訳IDを活用した会計プロセスの最適化

Author:: FujishiroKengo

, 2024/12/22

こんにちは。メルペイ MoMの@abcdefujiです。
この記事は、Merpay & Mercoin Advent Calendar 2024 の記事です。

はじめに

私たちPaymentPlatformは、メルカリグループ内のさまざまな価値循環、すなわち決済、返金、送金、入出金、精算などを実現しているチームです。現在、以下の図のように多様なサービスを支えています。

今回、PaymentPlatformがどのようにして各サービス毎の取引を識別し、会計システムと連携しているかについてお話ししたいと思います。また、本記事を作成するにあたり、AccountingチームのKENTYさんに多大なサポートをいただきました。

概要 – 会計ついて

そもそも会計とは何のために行うのかを簡単に説明したいと思います。今回は財務会計に関して説明します。
財務会計は、企業の財務状況や経営成績を外部の利害関係者（株主、投資家、債権者、規制当局など）に報告するための会計手法です。主に、財務諸表を作成し、一定の会計基準に基づいてデータを整理・報告します。財務会計の主な成果物は、以下の3つの財務諸表です。

貸借対照表（バランスシート）：特定の時点における企業の資産、負債、資本の構成を示すものです。資産は企業が所有するもの、負債は企業が負っている債務、資本は自己資本を表します。
損益計算書（インカムステートメント）：一定期間における企業の収益と費用を記録し、最終的な利益または損失を示します。売上高、営業利益、税引前利益、当期純利益などが含まれます。
キャッシュフロー計算書：企業の現金の流出入を記録するもので、営業活動、投資活動、財務活動の各セクションに分かれています。これにより、現金の流れが明確になります。

つまり、システムからデータを集約し上記財務三表を作成するプロセスが必要になります。

しかしながら、データを集約させるだけでは実現することはできません。財務三表を実現するためにはデータを仕訳の形式に変換する必要があります。

複式簿記と仕訳

仕訳の形式に変換するために複式簿記の知識が必要になります。複式簿記とは、すべての取引を二重に記録する方法で、資産と負債、収益と費用の関係を明確にします。これにより、取引の正確性が高まり、財務諸表が信頼性を持つようになります。

仕訳

仕訳は、企業の日々の取引を会計上の勘定科目に振り分ける作業です。取引が行われる際には、「借方」と「貸方」に分けて記録します。

借方（Dr.）：資産の増加、負債の減少、費用の発生を記録します。
貸方（Cr.）：資産の減少、負債の増加、収益の発生を記録します。

例えば、商品を10,000円で販売した場合の仕分けは以下のようになります。

借方：現金 10,000円（資産が増加）
貸方：売上 10,000円（収益が増加）

このように、各取引について対応する借方と貸方を設定することで、常に帳簿が総合的にバランスを保たれる仕組みが整います。これが複式簿記の基本的な考え方です。

勘定科目

企業や組織が財務活動を記録するために使用するカテゴリや項目のことを指します。これらは通常、貸借対照表や損益計算書といった財務諸表に表示されます。勘定科目は、それぞれの取引やイベントを記録し分類するための基本単位であり、以下のようなものが含まれます。

資産：現金、預金、受取手形、売掛金、在庫など
負債：買掛金、借入金、支払手形、未払費用など
資本（純資産）：資本金、資本剰余金、利益剰余金など
収益：売上、受取利息など
費用：仕入原価、給料、広告宣伝費、租税公課など

上記勘定科目に従いデータを会計システムに蓄積されることが望まれます。

会計システムとPaymentPlatformの接続方法について

実際のシステムと会計システムの連携について具体的に説明します。以下のような決済シーケンスを想定します。

お客さまが購入処理を実行します。
次に、メルペイが決済リクエストを処理し、お客さまの残高を減少させます。
同時に、加盟店の売上が増加します。
最後に、PaymentPlatformから会計システムにデータを連携します。

上記の流れで、決済データが会計システムに連携されています。このように、決済データを会計システムに連携しています。

単一のユースケースから複数のユースケースへ

では、PaymentPlatformが支えるユースケースが拡張し、さまざまなサービスで同じAPIが利用される状況になった場合、どのように取引を分類し、会計の観点から仕訳を行うことができるでしょうか。たとえば、メルカリグループ内の事業Aのサービスと事業Bのサービスから同じ決済APIが利用された場合であっても、商流やユーザーストーリーが異なる場合には、会計の観点からどのように取引を特定すべきでしょうか。

メルペイでは、この問題を解決する手段として仕訳IDを用意しています。

お客さまがメルペイでコード決済を実行します。
メルペイは決済リクエストを仕訳IDとともに処理し、お客さまの残高を減少させます。
加盟店の売上は増加させる。
PaymentPlatformから会計システムに対して仕訳IDを用いてデータを連携します。

このように、仕訳IDを上位から下位まで一貫して伝搬させ、会計システムにデータを届けています。これにより、複数のユースケースにおいても、会計の観点から決済データの正確な識別が可能となります。

開発プロセス

私たちの開発プロセスは、会計との密接な連携を重視しています。

開発の初期段階で事業の商流やユーザーストーリーを確認し、そこからお金の動きがどのように発生するかを分析します。この段階で、エンジニア、PdM（プロダクトマネージャー）、および経理の三者間で共通の認識を確立します。
その後、経理によって適切な仕訳IDの設計が行われ、発行された仕訳IDがエンジニアに提供されます。
最後に、エンジニアがその仕訳IDを会計システムまで正確に伝搬させるという流れになっています。

このプロセスでは、経理とエンジニアがお互いに歩み寄ることで、システム観点と会計観点の両方において最適な解決策を目指しています。

実現できた事

複雑なクエリからの解放

仕訳IDを活用することで、複雑な会計クエリからの脱却を実現しました。データを単一のシステムに集約し、仕訳単位での集計が容易になったため、関連システムからの複雑なクエリに頼ることなく、効率的な集計が可能になりました。また、会計システムにデータを集約してイミュータブルな状態で管理することで、冪等性が担保され、後日同じ手法で集計を行っても一貫した結果を得ることができます。

密な開発体制

体制としては、エンジニアが会計ドメインを理解しようとし、経理がエンジニアリングを理解しようとする歩み寄りの姿勢が育まれています。新しいユースケースが登場すると、必ずエンジニアから会計上の整理が正確であるかの確認が行われ、会計ドメインを意識しながら開発が進められています。

コスト削減

さらに、会計システム連携の共通化により、プロダクト開発コストの削減も達成しています。PaymentPlatformを利用することで、仕訳IDを介して会計システムまで一貫して連携できるため、新規事業や既存システムの拡張において、会計システムとの連携をプラットフォームとして取り込むことが可能です。

課題 / 今後に関して

仕訳IDの管理コストに関して、メルカリグループの事業拡大に伴い、PaymentPlatformがサポートするユースケースが大幅に増加しました。そのため、仕訳IDの増加に伴い現行の設計方針を維持できるか、あるいは将来的に維持が難しくなる可能性もあるため、継続的な検討が必要です。システム面でも、増加した仕訳IDに対してアドホックに対応したケースが負債として残っており、これを解消していくことが求められています。

開発プロセスにおいて、現状では会計要件を無視して開発を進めることは難しい状況です。さらに迅速な開発体験を実現するために、会計要件を気にせずに済む開発手法を模索しています。例えば、新規事業や既存の拡張から会計要件に落とし込み、仕訳を決定するまでのプロセスを簡略化したり、ある程度サービス側で整理した要件を出すフレームワークがあると効果的です。

オンボーディングのコストが高い点については、開発プロセスで会計ドメインに関するコミュニケーションが避けられません。特に新しいメンバーにとっては、会計システムと仕訳IDの設計を理解するまでのハードルが高い状況です。このため、キャッチアップのためのドキュメントを整備し、開発プロセスの簡略化を目指しています。

最後に、すべてのケースがPlatformとして吸収できるわけではありません。PaymentPlatformがカバーできるケースとカバーできないケースが存在し、事業やサービスによっては特殊なユースケースがあり、PaymentPlatformを経由せずに会計システムに連携している場合もあります。今後、PaymentPlatformのガバナンスを整理し、どこまでを吸収し、どこを対象外とするかを明確に管理する必要があります。

以上のような課題がある一方で、私たちはさらなる便利なPaymentPlatformの実現を目指し、日々精進を続けていきます。最後までお読みいただきありがとうございました。

参考資料

次の記事は iwataさんです。引き続きお楽しみください。