How to implement schema for double entry bookkeeping with many incoming transactions?

Question

I'm building a walled-garden e-commerce system where many users will add funds to the system. They can then spend these funds with merchants, who can then cash them out from their virtual account to real money in their bank account.

Due to implementaion details with our payment provider, every time a user pays in they create a new unique user entity within the payment provider.

When a purchase is made, funds are transferred from these users' accounts into the merchant's account (one per merchant, merchant's are fully qualified citizens with our payment provider).

The merchants can then cash out, where funds will be transferred out of our system and into their highstreet bank account.

The questions I'm asking myself are how do I structure those P&L accounts for the payments into the system and the payments out of the system? What I've read about double entry book keeping suggests that each cateogry should be represented by an account, so one for payments in, and one for merchant withdrawals, but I'm wondering if this is potentially due to the historically paper based nature of accounting or if it's just not necessary to have any finer detail.

The developer in me wants each payment to come in from it's own account, which would obviously create many (thousands) of accounts with only a single transaction.

The developer in me also wants each merchant to have their own Withdrawal P&L account (with 10s or 100s of transactions).

Obviously I could do it with one P&L for all payments in and one P&L for all withdrawals, and filter and group by the merchants account IDs to find, say the total withdrawal for merchant #1234.

I'm torn, is there a usual (standard, accpeted) way of doing this? Is the granularity worth the overhead?

Answer 1

P&L suggest profit and loss. This is not what you are doing. You need a ledger account for each depositor and a bank ledger to hold the money. The easiest way is to just record the transactions as they happen. e.g.

Type  Bank   Ledger   Extra Ref   Date        Ref    Details                     Amount

"BR", 4800, "CUS001", null,     30/09/2020, "RefNo", "Payment received",         100.00
"BP", 4800, "CUS001", "SUP001", 01/10/2020, "RefNo", "Payment to supplier name",  50.00

BR is a bank receipt. BP is a bank payment. 4800 is the bank account code etc.

The double entry is still there - the first line is DR the bank account, Credit the Customer. the second line is CR the bank account, Debit the Customer

You could add extra columns to record payment provider transactions IDs.