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

Double Entry Accounting for Developers

django-hordak.readthedocs.io

Post reply on HN
Print view View original

231–237 of 237 posts

Re: Double Entry Accounting for Developers

#231

Post by quickthrower2 »

hn_throwaway_99 wrote: post #225
quickthrower2 wrote: post #97

Earlier quoted context omitted.

I'm not so sure. I reckon you just hire the people who know a lot about finance in to a Business Analysis role and you're OK. You don't need single brains that know everything, just people working well in a team.

Completely disagree. I'm not saying the dev needs to know everything about finance, but they need to know the nuts and bolts and how things that finance people care about translate down into software. Most importantly, they need to be well versed in the language of finance so they can have intelligent conversations with the finance people. Just sticking another "Business Analysis" person in the mix just means there a…

We are probably both right - and the difference is in the size of company. For a start up you probably don't want a BA. Well you do, but as a role not a title. That person you call "developer" is really a hydra with many hats.

For a bigger company, the BA path (or SME - Subject Matter Expert, might be a better term) is like bringing in a expert in the team on finance. No different to bringing in a MongoDB tuning expert, or a React expert. Yes the developers need to learn some MongoDB/React/Finance etc, but the expert is worth having.

And having the expert reduces your need for unicorn people, the 10xers etc, and you can hire regular coders who are keen to learn a bit of subject matter (they should always be!) and the smart thing to do is send them on a course (rarely see this done in the real world - the normal approach is to let them introduce a bunch of bugs, get heat from QA and learn that way).

Re: Double Entry Accounting for Developers

#232

Post by kazinator »

kgwgk wrote: post #227
kazinator wrote: post #226

Earlier quoted context omitted.

Ah, but the simple matter of fiddling with the sign has ramifications. You end up with people having to cram mnemonics into their heads like DEAD CLIC, and PEARL. On top of that, there are awkward limitations like a transaction having to work with exactly two accounts, one of which is debited and one of which is credited. The actual numeric deltas applied to the two accounts by the debit/credit can be any of the four…

> (the company wins a lottery draw) The correct transaction is "+1000 cash, -1000 equity" In the end it will come to that (when the books are closed) but to be able to generate correct income statements you may need to create some kind of income account for that gain. > (It's sort of as if the owners actually got the money, and loaned it to the business). But it's not really the same thing.

> you may need to create some kind of income account for that gain

Right; and that's exactly what I describe in the last paragraph.

Re: Double Entry Accounting for Developers

#233

Post by wrycoder »

sago wrote: post #206
wrycoder wrote: post #193

Earlier quoted context omitted.

For one example, read the docs for Beancount, which is mentioned above. Signed values are the way to go!

> Signed values are the way to go! 100% agree! > For one example, read the docs for Beancount, which is mentioned above. Do you have other examples too? You are dead right with this one. It is the opposite way to the way the systems I'm familiar with did it. Debit is positive, And credit negative. Thanks so much for the link. I'm still not sure what I would concede that it is conventional ;) But my assumption it was…

When you first open a business, you put in capital - owner's equity. So the cash account (an asset) increases, and the equity account (a liability) also increases.

In a computerized system, one of these accounts carries a negative balance, the other a positive balance. A choice has to be made - but it's not a matter of good or bad.

There are several implementations of the Ledger system. The transaction registers and GL are human-readable. I looked at Ledger, and assets were positive.

I looked in the code for the GNUCash engine, but there are so many features that I didn't manage to get to the bottom of it w/o spending too much time on it :-)

I do recollect working with low level GC transaction data years ago, and I think I would remember if the assets were negative.

There are a couple of Wikipedia pages with links to FOSS accounting systems.

Re: Double Entry Accounting for Developers

#234

Post by junkrat002 »

Hamuko wrote: post #104
junkrat002 wrote: post #102

Earlier quoted context omitted.

Ex-finance SWE here. I closed the article after that part. If you don't understand accounting and read this, you'll only be more confused when you learn how accounting actually works. For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.

> For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA. Surely there's a big difference between earning a CPA and just knowing the basics of accounting. I had a summer job helping out with entry in a family member's small accounting firm. I don't think that double entry accounting is that crazy of a concept that it cannot be grasped by someone…

Yes I agree, a vast difference between basic accounting and a CPA. I am not a CPA, but I do understand accounting.

That doesn't change the fact that I'd be wary of any accountant writing a blog post on how to write good quality code for production. Are there accountants out there who can do a good job of that? Absolutely. Are there many more accountants who would do a poor job of that? My guess is also yes.

Re: Double Entry Accounting for Developers

#235

Post by junkrat002 »

rbg246 wrote: post #139
junkrat002 wrote: post #102

Earlier quoted context omitted.

Ex-finance SWE here. I closed the article after that part. If you don't understand accounting and read this, you'll only be more confused when you learn how accounting actually works. For the most part, devs in general should not be teaching accounting. There's a reason that it is so challenging to earn a CPA.

It's not that hard to qualify, it's the equivalent of three years software engineering experience with some side study. It's more a case of someone who has one year of writing JavaScript shouldn't be writing on the theory of software development.

I agree with your statements. If someone has spent three years studying accounting, I would certainly expect that he or she is able to blog coherently about double entry accounting.

Re: Double Entry Accounting for Developers

#236

Post by adamcharnock »

goat_whisperer wrote: post #59
adamcharnock wrote: post #31

Oh wow, I posted this earlier and assumed it hadn't been picked up. From people's comments here it sounds like I may have missed the mark on some of this. Pull requests always gratefully received. None the less, the result has been some software which seems to have worked well for those that have used it. I certainly haven't received any angry issues. I'll link to this thread from that page.

Hey! Hope any criticism didn’t come off too harsh. I appreciate the effort that went into this! I checked out the GitHub repo. I’m a CPA who’s getting into web development and has some Django experience. Would definitely be interested in contributing.

Hey! Only just see this comment, no worries at all. I can take it all in my stride :-)

I think Hordak could really do with a version 2 anyway. There are a number of issues open which I think would make for a big improvement, but would also result in breaking changes. I'm not precious about the codebase either, it hasn't been a priority for me for a while and it would be great to see it given some love (especially from someone with a better knowledge of accounting than I!)

Definitely get in touch if you are interested in being involved. I'd be happy to add you as a maintainer after a pull request or two.

Re: Double Entry Accounting for Developers

#237

Post by t-vi »

goat_whisperer wrote: post #4

From the site: "I found the core explanation of double entry accounting to be confusing. After some time I distilled it down to the following: "Debits decrease the value of an account. Always. [1] Credits increase the value of an account. Always. [1] "[1] (1, 2) This is absolutely not what accountancy teaches. You’ll quickly see that there is a lot of wrangling over what account types get increased/decreased with a d…

Well, if you want to define accounting in an alternate universe, you can define it that way. However, if you want to describe accounting as it is done, it is utterly wrong. Doing this will bite you once you read other sources on accounting, talk to accountants, the tax office, etc.

From my experience, if you're doing accounting beyond a hobby, you likely want to follow whatever GAAP (generally accepted accounting practices), and likely need to consult references for how specific cases are represented. If you then don't use the same language and conventions as everyone else, it's just even more of a pain than it is.

My experience here is that I was with a large audit company, albeit as an actuary rather than an accountant. I did have the opportunity to dig quite deep accounting records of insurance companies there. Now I own an incorporated company and do my own accounting and taxes (with GnuCash for accounting, even if I hand-rolled reporting for XBRL export and all).

Post reply on HN