Live data from Hacker News

Accounting For Developers, Part I

moderntreasury.com

111–120 of 193 posts

Re: Accounting For Developers, Part I

#111

Earlier quoted context omitted.

> "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholde…

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_m... and it described income as being negative and expense as being positive, it broke my brain a little bit.

An income is something you owe to your shareholders. So if you think of what you own as (+) and what you owe as (-), which is how debut/credit is conventionally shortcut, an income is a negative number.

Re: Accounting For Developers, Part I

#112

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a…

What is super powerful about thinking of income as a credit account?

Re: Accounting For Developers, Part I

#113
post #83

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a…

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 ab…

>Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5?

That wouldn't make sense. Alice sent Bob $5, so now Alice's balance would be $5 and Bob's would be -$5? The amounts should display their balances within the app, and Alice and Bob should have their own personal balances which are independent of the app's. Before the transaction, both Alice and Bob were at $0 on their personal balances and afterwards they were still at $0, since neither of them had more dollar bills on their persons. The difference between their personal balances and their balances in the app is the value you're alluding to. $0-(-$5) for Alice and $0-$5 for Bob. This difference could be interpreted as the amount that each owes to the app (positive for Alice because she owes and negative for Bob because he is owed).

Re: Accounting For Developers, Part I

#114
post #58

Can someone help with a few ideas on this topic? I've been volunteered to be the treasurer at my building home owner's association, and trying to keep accounts for the whole building on a single excel sheet is a shitshow. So obviously I'm building a SaaS that will handle all the accounts for every HOA in the whole world and become a trillion dollar product. But I need to figure out which accounts are debit normal and…

I would recommend getting comfortable with some basic double-entry accounting software like GNUcash [1]. I found that extremely helpful in learning how to reason about these things, as well as grasp the purpose of different types of accounts (asset vs A/R vs income etc). They also have pretty good docs and tutorials as I recall.

Also then it'll quickly show you where the existing software falls flat (and it does) in terms of scriptability, scaling, etc.

[1] https://www.gnucash.org/

Re: Accounting For Developers, Part I

#115
Some practical cases where you really need such a system:

A customer pays one product with two different sources of payment (gift card + visa, or one half with cash and the other with card)

You want to verify if the balance in the cash register, or on the credit card account are correct.

You already received money from a customer, but it will take some time until you can create the invoice (for example you want to print the serial number on it, and don’t know it yet), but for legal reasons you are not allowed to change an invoice later. So you have to record a payment without having an invoice yet.

Re: Accounting For Developers, Part I

#116
post #83

Earlier quoted context omitted.

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 ab…

>Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5? That wouldn't make sense. Alice sent Bob $5, so now Alice's balance would be $5 and Bob's would be -$5? The amounts should display their balances within the app, and Alice and Bob should have their own personal balances which are independent of the app's. Before the transaction, both Alice and Bob were at $0 on their personal balance…

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

#117
post #68
post #64

Earlier quoted context omitted.

If you're serious about building a SaaS tool (and I encourage it!), make sure to find someone with an accounting background to help you / advise you. Maybe they can be a good co-founder. (I've been working on a SaaS in the accountancy space for 6 years and our two co-founders are an accountant and a software engineer. It's a good match)

This is currently just a side project, but yeah, if I have more than 10 buildings using it I'll probably take it seriously and bring in an (accountant cofounder).

Just chiming in - I'm an engineer who is also a CPA :). I'd be happy to attempt to answer any questions you might have. It's been a few years since I was accounting professionally, but maybe I can still be helpful.

Re: Accounting For Developers, Part I

#118
I had a pleasure to dive deep into this topic and we built a double-entry bookkeeping system from scratch in a heavily regulated industry that tracked debt consolidation for thousands of customers with payouts to thousands of creditors.

I think this is one of the most proudest things I was ever was involved in architecting, designing and building. I left before it got to prod, but from people still there, I've been told it's been working flawlessly!

Re: Accounting For Developers, Part I

#119
post #27

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. a…

Easy: double entry is append only database (immutable data). To compute account value you sum() over all transactions. Each transaction is required to sum to zero (credits=debits), so the sum over all transactions is also zero (balanced). You store the history of transactions.

If you instead update account values in place (stored as sums) then you can't check your accounts are balanced (missing money bad)

Re: Accounting For Developers, Part I

#120
post #116

Earlier quoted context omitted.

>Wouldn’t it be more logical to show Alice’s balance as $5 and Bob’s balance as -$5? That wouldn't make sense. Alice sent Bob $5, so now Alice's balance would be $5 and Bob's would be -$5? The amounts should display their balances within the app, and Alice and Bob should have their own personal balances which are independent of the app's. Before the transaction, both Alice and Bob were at $0 on their personal balance…

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.

This little comment chain has done more for my understanding of accounting than at least 3 hours of reading online and trying to have my accounting friends explain it.
Post reply on HN