News for hackers. Stuff that matters.

kojim

Re:Accounting for Developers, Part II on Friday August 26, 2022 @03:34PM (#32611785)
Do you mean for card payments, like the card network and authorization flow? I found this article really good from the systems design side although you might have to be a subscriber: https://newsletter.pragmaticengineer.com/p/payments-system
Re:Accounting for Developers, Part II on Wednesday August 24, 2022 @01:23PM (#32582692)
That's a cool idea. Any other deep-dive guides on fintech/payments that would be helpful for readers here? We're always looking for new topics to write about.
Re:Accounting For Developers, Part I on Wednesday August 17, 2022 @02:01PM (#32499658)
I agree that from a developer's perspective and certainly in the frontend it doesn't make sense to show a positive user balance as negative. But to a finance team, cash on your company's books (debits) needs to have the opposite polarity of money that your users hold (credits). My underlying point is that it's really hard to make that the case without using the credits and debits language.
Re:Accounting For Developers, Part I on Wednesday August 17, 2022 @01:40PM (#32499426)
Oh completely. The "agreeing on what's left or right" in every context is the tough part, and already a solved problem with debits and credits.
Re:Accounting For Developers, Part I on Wednesday August 17, 2022 @12:59PM (#32498866)
Debits and credits is the only way to give your team a common, consistent "language" for dealing with money, and being able to speak this language as a dev gives you superpowers.

Accounting was invented before negative numbers. Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits. Instead of subtracting funds from one account and adding them to another, we talk about crediting one account and debiting another.

But it’s the 21st century and we have negative numbers now - why not just use positive and negative numbers? Using positive and negative numbers gets ambiguous.

If your app lets Alice sends Bob $5, we remove $5 from Alice’s account and add $5 to Bob’s account. So it seems fair to say that if both user accounts started at $0, Alice’s balance is -$5, and Bob’s balance is $5. Let's represent it that way in your DB.

Your CFO would disagree. From your company’s perspective, what these balances mean is that Alice owes you $5, and the company owes Bob $5. In other words, if the company went out of business tomorrow, you'd have to go out to collect $5 from Alice so that you could give Bob the $5 he rightfully thinks he’s holding inside of your app. Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?

It gets even more confusing if your software deals with financial instruments like loans, investments, or invoices. Dealing with every balance in your application as a simple positive or negative number gets really confusing, and will cause both ledgering issues and communication breakdowns between your eng and financial teams.