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?

  • You do not necessarily need to have an account for each user - certainly, you would not have one account set up per transaction. The question is, what is the meaning of a "user" in your system, if they exist only to perform a single transaction, and then cannot be reused? It's definitely worth writing any accounting system according to normal double-entry accounting principles, but choosing how things are accounted for within the tenets of double entry, is not always straightforward. – Steve Sep 30 '20 at 13:23
  • The users in question are punters, who pay into the system so they have credit to spend at a later date. Because of a limitation in our payment provider and our intergration with it each time a user loads money into the system they create a new user entity with the payment provider. I'm wondering whether to mirror this structure, by creating an associated paying in account for each transaction, or whether to lump them all into a single "Cash In" account with a reference on the transaction back to the user & transaction at the payment provider for auditing purposes. – Greg B Sep 30 '20 at 13:32
  • That suggests to me that you are running an account per client. There may only be one payment in, but there will presumably be multiple payments out as they spend their credit? Also, how would a client see a consolidated account of all their deposits with you? Or can't they? – Steve Sep 30 '20 at 17:59

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.

  • 1
    This is liable to be somewhat confusing to the uninitiated, as the transaction list you give is not an explicit example of double entry. – Steve Sep 30 '20 at 17:55
  • Welcome to the community @Martin and thanks for the response. I was unaware of the notion of a ledger account. Having done two minutes of Googling, am I right in thinking the ledger accounts would totally replace my proposed schema? – Greg B Sep 30 '20 at 18:54
  • With double entry book-keeping the + side of the entry would go in one account and the - side would go in another. There is no reason why you cannot record both accounts in one record. In modern accounting systems you have one table that records the transactions, another table that records the details of the customer such as address etc, another table that records the details of suppliers and the final table to record details of the nominal balances. – Martin Creighan Oct 1 '20 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.