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

71–80 of 193 posts

Re: Accounting For Developers, Part I

#71

Post by datavirtue »

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…

You just look silly trying to build financial software without understanding and implementing double-entry or ledgers. You have to know when to employ debit and credit nomenclature and be able to easily explain the reactions in the system...or you look silly. Sort of like when accountants start talking about databases and APIs without proper training.

I have had to train developers on the simple concept of a ledger, which totally baffled them. It is event sourcing. You write, never update. If you want to offset a previous transaction you just record a new one. Want to know the account balance, just add up every amount within the range of entries you care about.

Once they grasped that they were wanting to use the terms debit and credit in that context. Not cool. If you are tracking single accounts you only need negative and positive amounts. If the account/ledger is not offsetting another debit/credit there is no need to introduce that concept and complicate things. If you do, the finance team is going to wonder what other accounts you are offsetting. If the answer is none, brows wrinkle and confusion sets in.

And ffs don't ever send them a spreadsheet or report with currency symbols in it. Major peave.

Accountants have been using event sourcing (immutable ledgers) for hundreds of years. Powerful.

Every complex finance problem I have run into in software dev was easily and elegantly solved with immutable records.

Re: Accounting For Developers, Part I

#72

Post by rahimnathwani »

sudhirj wrote: post #65
rahimnathwani wrote: post #63

Earlier quoted context omitted.

Maintenance invoice issued: DR accounts receivable CR income Maintenance paid DR bank account CR accounts receivable Each apartment is part of accounts receivable. Normally accounts receivable has a DR balance (because apartment owners pay you AFTER you invoice them, so they are usually DEBTors).

> Each apartment is part of accounts receivable. Like a sub-account? This is probably the mindfuck part. So every apartment owner who opens up their statement is seeing a filtered balance?

You could implement it as either a subaccount per customer (in which case the balance is just the sum of all txns in that account) or have 'apartment' as another dimension (field) you store (optionally) for each transaction.

Either way you can get a sum of all txns that have hit that apartment's AR account.

Re: Accounting For Developers, Part I

#73

Post by Max-q »

rahimnathwani wrote: post #56
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…

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

> This seems incorrect to me.

That’s because the system is not built by programmers. Some accounts (that’s accounting accounts, not bank accounts) are positive for you and some are negative. You need to know what kind of account it is to know if debit is good or bad for you.

Re: Accounting For Developers, Part I

#74

Post by rahimnathwani »

Max-q wrote: post #73
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…

> This seems incorrect to me. That’s because the system is not built by programmers. Some accounts (that’s accounting accounts, not bank accounts) are positive for you and some are negative. You need to know what kind of account it is to know if debit is good or bad for you.

"That’s because the system is not built by programmers."

That's definitely not the reason I consider GP's comment incorrect.

(I'm a qualified accountant.)

Re: Accounting For Developers, Part I

#75

Post by sudhirj »

rahimnathwani wrote: post #72
sudhirj wrote: post #65

Earlier quoted context omitted.

> Each apartment is part of accounts receivable. Like a sub-account? This is probably the mindfuck part. So every apartment owner who opens up their statement is seeing a filtered balance?

You could implement it as either a subaccount per customer (in which case the balance is just the sum of all txns in that account) or have 'apartment' as another dimension (field) you store (optionally) for each transaction. Either way you can get a sum of all txns that have hit that apartment's AR account.

Thanks, let me think about this. This feels counterintuitive to me, and increases complexity a bit.

Re: Accounting For Developers, Part I

#76

Post by fuckstick »

rahimnathwani wrote: post #56
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…

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

> 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 are fundamentally abstract - such that when they have no essential features above their effect on the account.

I mean did you bother to read the clarifying following sentence before you selectively quoted?

Re: Accounting For Developers, Part I

#77

Post by rahimnathwani »

EvanAnderson wrote: post #70
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…

> > Without the context of the specific accounts being debited or credited the terms themselves mean nothing." > This seems incorrect to me. You can't derive the change in assests, liabilities, or equity without know which accounts are being debited and credited. The terms "debit" and "credit" themselves don't tell you anything by themselves. Without the context of accounts the terms are meaningless. I think programm…

"When you know they type of account being debited or credited you can reason about how it affects the balance of the account and the managerial context of the transaction"

This is true, but it doesn't negate my point (that debit and credit have meaning independent of the type of account).

I know this because I have used the principle many times in practice, to define charts of accounts, to define rules for posting different types of transactions etc.

Re: Accounting For Developers, Part I

#78

Post by tenacious_tuna »

Naga wrote: post #16
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…

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.

Re: Accounting For Developers, Part I

#79

Post by EvanAnderson »

rahimnathwani wrote: post #77
EvanAnderson wrote: post #70

Earlier quoted context omitted.

> > Without the context of the specific accounts being debited or credited the terms themselves mean nothing." > This seems incorrect to me. You can't derive the change in assests, liabilities, or equity without know which accounts are being debited and credited. The terms "debit" and "credit" themselves don't tell you anything by themselves. Without the context of accounts the terms are meaningless. I think programm…

"When you know they type of account being debited or credited you can reason about how it affects the balance of the account and the managerial context of the transaction" This is true, but it doesn't negate my point (that debit and credit have meaning independent of the type of account). I know this because I have used the principle many times in practice, to define charts of accounts, to define rules for posting di…

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 explaining what the managerial result of that entry is. That's an unanswerable question w/o more context. That's my point.

Post reply on HN