Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accounting For Developers, Part I

moderntreasury.com

Post reply on HN
Print view View original

121–130 of 193 posts

Re: Accounting For Developers, Part I

#121

Post by jessaustin »

rahimnathwani wrote: post #101
onefuncman wrote: post #97

Earlier quoted context omitted.

> When an account is CREDITED, this always represents an increase in liabilities[0] (or equivalently, a decrease in assets). > When an account is DEBITED, this always represents an increase in assets (or equivalently, a decrease in liabilities). This is where you're wrong. You can credit and debit Accounts Payable and Accounts Receivable. If you credit AP, you're increasing liability, if you credit AR, you're increas…

"If you credit AP, you're increasing liability, if you credit AR, you're increasing assets." This is incorrect. If you credit AR, you're decreasing assets.[0] [0] https://www.freshbooks.com/hub/accounting/debit-and-credit#:... .

Your link shows that AR is a subaccount of Assets and AP is a subaccount of Liabilities, so credits to each have the opposite effect with respect to a balance sheet. GP has a different understanding of the "polarity" of debits and credits, but if anything this seems to support rather than undermine proposition "A" above?

Re: Accounting For Developers, Part I

#122

Post by fluoridation »

kojim wrote: post #116
fluoridation wrote: post #113

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.

>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).

Then you're arguing how the value should be displayed. There's no reason to prefer one sign or the other in the codebase, as long as it's always displayed correctly to the correct actors.

Re: Accounting For Developers, Part I

#123

Post by jimnotgym »

kojim wrote: post #83
EvanAnderson wrote: post #25

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…

> 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.

In computerised accounting it is completely normal to use negative numbers for credits and positive numbers for debits. That way a whole trial balance sums to zero. Very neat indeed.

What is missing above is the concept of accounts to put the balance in. For instance if I have a loan I put it in an account called 'loan', and list it on my balance sheet as a creditor. It will always have a negative balance. If it doesn't there is a problem.

Alice from above owes me 5 bucks so goes in the debtors (or receivables account).

I owe bob five bucks it goes into creditors (or payables)

One classic piece of error checking is to review debtors for credit balances. It means someone has overpaid, needs a refund or screwed up posting it.

Re: Accounting For Developers, Part I

#124

Post by rahimnathwani »

jessaustin wrote: post #121
rahimnathwani wrote: post #101

Earlier quoted context omitted.

"If you credit AP, you're increasing liability, if you credit AR, you're increasing assets." This is incorrect. If you credit AR, you're decreasing assets.[0] [0] https://www.freshbooks.com/hub/accounting/debit-and-credit#:... .

Your link shows that AR is a subaccount of Assets and AP is a subaccount of Liabilities, so credits to each have the opposite effect with respect to a balance sheet. GP has a different understanding of the "polarity" of debits and credits, but if anything this seems to support rather than undermine proposition "A" above?

"so credits to each do indeed have the opposite effect with respect to a balance sheet"

I think what you mean here is that a debit balance in an asset account is presented as a positive amount, whereas a debit balance in a liability account would show as a negative amount.

This is true, but that doesn't mean a credit has the opposite effect depending on whether it's applied to an asset or liability account. Consider that you have two different accounts with your bank:

- a current account (usually the bank owes you money, i.e. usually a credit balance from the bank's POV)

- a loan account (you bought a car on credit, and owe the bank money, i.e. a debit balance from bank's POV)

For the bank, the current account is a liability ($1,000) and the loan account is an asset ($25,000).

When you deliver a bag containing $5,000 to the bank, the bank will credit one of these two accounts. They'll either increase the current account to $6,000, or decrease the loan account to $19,000.

In either case, the credit has the same effect: your net debt to the bank is decreased by $5k.

Re: Accounting For Developers, Part I

#125

Post by jessaustin »

redandblack wrote: post #89
rahimnathwani wrote: post #56

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…

I prefer not to ascribe semantics to accounting credit/debit - only thing that matters is it is consistently applied and balances out. I think of this as being similar to primary key constraints - my rule is primary keys should not have a business meaning. I have walked into many situation where they would have implemented so - and usually will fail to convincing them otherwise.

...my rule is primary keys should not have a business meaning.

OMG I so agree with this. I worked at a company where we wasted so much time, and moved so much more slowly, just because some previous technical person hadn't completely thought through the implications of ever including primary keys on the GL feed. The whole time I was there I begged the accounting drones to forget about this concept, repeatedly enlisting the marketing department who claimed to believe that velocity was a good thing, but I too failed. Eventually I realized that if we didn't give them primary keys they would have to lay off multiple people whose only function was to look at primary keys. Instead I should have invested more effort in programmatically generating the database entries that drove this whole boondoggle.

Not the first, and also not the last, place I worked where the CFO could have been the least honest person in the building.

Re: Accounting For Developers, Part I

#126

Post by biznickman »

I cannot upvote this enough. I worked at a fintech company that was vehemently opposed to using double entry accounting and it created an incredible amount of inefficiencies and massive errors and expenses at the company. If you are dealing with money in any system and tracking it in a database, double-entry accounting is not an option.

Re: Accounting For Developers, Part I

#127

Post by yobbo »

kojim wrote: post #83
EvanAnderson wrote: post #25

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…

> Because of this, instead of counting money as positive or negative amounts, it uses the debits and credits.

That's not quite the point of double-entry. When one account is credited, at least one other account must be debited.

All debits and credits sum to zero, but the accounts will have positive or negative balance.

Re: Accounting For Developers, Part I

#128

Post by yobbo »

joshstrange wrote: post #5

Interesting, I'd heard of "double entry" before but I've never used it. I've written and maintain code that uses only 1 record per transaction and I'd love resources to look into that go into the "why" of double entry. For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row. For reloading the "fromUserId…

> For example my current "transactions" table has fromUserId and toUserId columns (1 user = 1 account) and so purchases/transfers/reloading your account all take just 1 row

This is what double-entry looks like in a database.

Ironically, single-entry would have one column, and two records for each transaction.

Re: Accounting For Developers, Part I

#129

Post by withinboredom »

kojim wrote: post #83
EvanAnderson wrote: post #25

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…

Uh. No. When I refund someone I issue a negative credit on my account. It isn’t a debit, strictly speaking.

Re: Accounting For Developers, Part I

#130

Post by rr888 »

alain94040 wrote: post #29
potamic wrote: 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…

Think of each transaction as a movement: it has a source and a destination. Therefore, you need to account for it in two places: where it came from, and where it went. Does that make more sense?

I think you can expand this explanation with database terminology.

In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit.

Now if you're doing accounts by hand you really need that single line transaction record.

Post reply on HN