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

91–100 of 193 posts

Re: Accounting For Developers, Part I

#91

Post by tunesmith »

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…

For those who use single-entry systems, if you've ever had to "split" a transaction into multiple categories, you're halfway to understanding double-entry. Especially if your "split" has both income and expense categories. For instance, if you want to accurate categorize your paycheck, some of the categories will be income like "gross salary", and some will be expense like FICA and tax. The trick is that all those amounts, positive and negative, need to add up to the net deposit that hit your bank account. Whereas in double-entry accounting, the combined debits and credits need to add up to zero.

Re: Accounting For Developers, Part I

#92

Post by vineyardmike »

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…

You may not need double entry if you’re just tracking your personal checking account to see if you can pay your bill… but it still may help.

You answered your own questions though. It’s useful for error tracking and consistency. As a simple example to explain how it can help from a consistency perspective - think about a tool like Mint or Personal Capital or Nerd Wallet. They let you sign into your bank account and use a GUI to track all of your transactions. Ignore any privacy concerns. If you have 5 credit cards (because points), 2 checking accounts (you+spouse), a savings account, brokerage, mortgage, etc - there’s a lot of room for money to jump between accounts. Now imagine that you don’t include your mortgage account in the app. Whenever you pay money… it looks like your net worth is decreasing. In these apps, it might show up as a “purchase”. But you’re actually getting richer (by paying off debt and gaining house equity). If you include the mortgage account, you get to bring “the other side” into scope - boom - you now have an accurate view of the world when you didn’t before. That’s kinda sorta ish comparable the value of double entry. One side doesn’t tell the whole story, but always tracking both sides does.

Of course, the error-correcting part comes when there was a mistake or a correction that needs to be added. (Mortgage lended says balance is wrong?Here’s the sum of all transaction from checking acct to mortgage!). If double entry, both sides of a single tx have to match, and you don’t track the balance, you derive the balance from the sum of all transactions. So you theoretically can’t get a case where one ledger (eg mortgage) doesn’t match the other (eg checking). Helps a lot more when you’re a multinational bank with $1T and 50 million customer accounts.

Another example is a cash registers in stores. There’s a much higher chance the balance of cash is wrong (more room for human error). Being able to compute the balance over time based on the transaction history is useful for determining register 5 keeps losing money. Every change in cash balance should match another transaction so the total value of business’s money doesn’t change. Or just confirming that once you bring the cash to the bank there will be enough balance to pay a loan.

Does this directly impact you on a day to day basis? Maybe no. But I hope that’s a super simple illustration of why it’s conceptually useful and what “error tracking and consistency” means.

Re: Accounting For Developers, Part I

#93

Post by rahimnathwani »

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.

> I prefer not to ascribe semantics to accounting credit/debit

I think most people agree with you. They prefer to memorize some rules, or just look them up. Personally, I find having a simple principle helps me reason about new situations (new transaction types).

Re: Accounting For Developers, Part I

#94

Post by rahimnathwani »

tunesmith wrote: post #86
fuckstick wrote: post #76

Earlier quoted context omitted.

> Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns. Taking this as sympathetically as possible - which is tough - because do you really think the person you are replying to on this forum with the given response does not understand principles in the abstract?? This really is quite condescending. The entire point of a statement like this is that debit and credit…

That seems uncharitable - the person you're replying to is saying that debit/credit are more than fundamentally abstract, and that they have conceptual meaning consistent across all accounts.

"they have conceptual meaning consistent across all accounts"

I like this phrasing. I wish I had used it!

Re: Accounting For Developers, Part I

#95

Post by projektfu »

tenacious_tuna wrote: post #78
Naga wrote: post #16

Earlier quoted context omitted.

One of the big advantages of double-entry accounting is that it lets you model pretty complicated events in a simple way. I think its a common misconception that transactions have two sides to them, debits and credits. It probably comes from the name, and that most simple examples only have one two sides. Really, its at least two sides. The important characteristic is that the debits must equal the credits, in value…

> Lets say you sell a service to someone, a year of service for $100. This sounds simple, debit cash for $100 and credit sales revenue for $100 I'm confused, this seems like you would credit both cash and sales revenue $100... since you'd have received $100 from whomever bought your service, so youd have $100 more cash, and for tax accounting, you'd have sold $100 worth of stuff as well.

In the double-entry model, things follow the accounting identity:

Assets = Liabilities + Equity

and its more dynamic corollary since Equity = Capital + Income - Expenses, simplified to keep everything positive:

Assets + Expenses = Liabilities + Equity + Income

Assets and Expenses are considered to have a debit balance and the other three have a credit balance. Debit represents money "owed to" the business and credit represents money "owed by" the business. People get hung up on these terms because they think of credits as good things when their checking account gets credited and debits as bad things. But that terminology is because the bank has exactly the opposite relationship. Your checking account is their liability (and your mortgage is their asset).

Thus, when you are paid $100 by bank transfer for a service, you credit "Sales" by $100 and debit "Checking" by $100 as well.

In the accrual method, you might prefer to credit "Sales" by $8.33 and "Prepaid Sales" (a liability) by $92.67, and debit Checking by $100. Then each month you would debit "Prepaid Sales" by $100/12 and credit "Sales" the same amount. This would keep you from having weird ups and downs when looking at monthly income statements. It gets tedious to do by hand, but computers make it easy when they do it right.

Re: Accounting For Developers, Part I

#96

Post by whatshisface »

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…

That's like choosing whether +x is a rightward or leftward facing coordinate axis. You can still use negative numbers, but you have to indicate whether positive means left or right. See also: positive and negative longitudes vs. east or west longitudes.

Re: Accounting For Developers, Part I

#97

Post by onefuncman »

rahimnathwani wrote: post #88
EvanAnderson wrote: post #79

Earlier quoted context omitted.

I think we're talking past each other but I'm not sure how to rectify. Given a debit of $500 and two matching credits of $250 how is the owner's equity position affected? A programmer, unfamiliar with accounting, might think that "debit" and "credit" carry enough meaning in this context to answer the question. You and I know that without knowing what account types are being debited and credited we have no way of expl…

"I think we're talking past each other but I'm not sure how to rectify." Let me give it one last try :) You're claiming the truth of two propositions: A) Without the context of the specific accounts being debited or credited the terms [debit and credit] themselves mean nothing. B) Without the context of the specific accounts being debited or credited we have no way of explaining what the managerial result of that ent…

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

Re: Accounting For Developers, Part I

#98

Post by mguerville »

Great article by a company that's honestly been great to work with, I think it's interesting that they write such an entry level piece when their solution is enterprise grade but it shows their dedication to educating not just the users and stakeholders of the end product but also the implementers, which very few software companies do.

Re: Accounting For Developers, Part I

#99

Post by onefuncman »

tunesmith wrote: post #86
fuckstick wrote: post #76

Earlier quoted context omitted.

> Debits/credits concepts can exist (and we can operate on them) without the existence of left/right columns. Taking this as sympathetically as possible - which is tough - because do you really think the person you are replying to on this forum with the given response does not understand principles in the abstract?? This really is quite condescending. The entire point of a statement like this is that debit and credit…

That seems uncharitable - the person you're replying to is saying that debit/credit are more than fundamentally abstract, and that they have conceptual meaning consistent across all accounts.

> conceptual meaning consistent across all accounts.

Except programmers quite often get the conceptual meaning wrong and incorrectly generalize further. Credit and debit just mean increase or decrease in account balance. You cannot know how it affects liabilities or assets without knowing what type of account is being modified.

Re: Accounting For Developers, Part I

#100

Post by projektfu »

retetr wrote: post #32

Can someone explain. From their definition it looks like the credits and debits column in their example transaction table is flipped e.g. the first "debit" to the cash (debit normal) account increases the value, while the "credit" to the equity (credit normal) account also increases the value. (edited for spelling)

See my other comment here: https://news.ycombinator.com/item?id=32499123
Post reply on HN