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

61–70 of 237 posts

Re: Double Entry Accounting for Developers

#61

Post by dopeboy »

et-al wrote: post #43
hn_throwaway_99 wrote: post #29

Note to people looking for job security: there is a HUGE need for developers who understand finance. The fundamental problem is that most finance people can't speak the language of software development (the biggest problem I've seen is that finance people tend to be very poor at writing out a spec of what the software should do - they're much better at looking at a set of examples and then telling you if the calculat…

Aside from the obvious PayPal, SQ, and Stripe, would you (and other folks) please share some companies one should look into?

Big banks. I used to work at Morgan Stanley - they value this intersection a lot.

In my group, there were business analysts and developers. Guess who got more comp and recognition within the company? And there were a select few who could do both - they were intensely valued.

It's good career advice especially if you're working in a capacity where engineering is supporting a business, rather than the business itself.

Re: Double Entry Accounting for Developers

#62

Post by mumblemumble »

jamesmackennon wrote: post #58
mumblemumble wrote: post #7

One thing I really appreciate about YNAB is that they ditched the obscure words with murky Latin roots and rules to memorize about flipping signs and whatnot, and just used the words "inflow" and "outflow". They don't mean anything different in this context than "debit" and "credit." But still, somehow, when you use the traditional words, the topic seems to be as difficult to explain as monads, while with the YNAB te…

...but sometimes things aren't inflows or outflows. Depreciation is neither, yet it's (almost) fundamental to accounting.

Depreciation is also neither a credit nor a debit.

Doesn't one normally handle depreciation by creating an expense account called "depreciation", and recording the depreciation as a debit in the asset account and a credit in the depreciation account?

And couldn't one just as easily word that as, "We track the depreciation by creating an account for it, and recording a flow of money into it from the asset's account?"

Re: Double Entry Accounting for Developers

#63

Post by sago »

mehrdadn wrote: post #54
sago wrote: post #52

Earlier quoted context omitted.

Debit is where you put money. Credit is where it came from. I am not inventing this. Money in your bank is debit in _your_ accounting. You are very welcome to treat it as positive and add. As long as you keep track of where every positive number is a credit or a debit, and you learn all the rules about which accounts to add and which ones need taking away. Or you can just treat credits as positive numbers and debits…

I think you're confused on what I'm confused about. The positive or negative sign isn't the issue. You could flip all the signs and I'd still have the same problem. > Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative. But that is literally what I'm talking about. Whether the sign is positive or negative isn't the issue. It just makes no sense for this to be a…

I see, sorry. Thanks for clarifying your question.

Transactions always balance. Money always comes from somewhere, and it always goes to somewhere. Total debit always equals total credit.

In a double entry accounting system you have to say where that $200 came from.

Did it come from a sale (you sold your work, an item), a loan you took, someone you loaned money yourself, or an investment in your company.

In double accounting it always balances.

Here I am talking debit and credit because this is nothing to do with my point about positivity or negativity. This is how double entry bookkeeping works.

If you make all the numbers positive, then the total credit has to equate ('balance') with the total debit.

So treating debit as negative and credit as positive, means 'balancing' is just summing to 0.

Before double entry bookkeeping was invented in the Renaissance, single entry accounting just kept separate lists for all things. This works for basic tracking of money. For individuals particularly. But has massive weaknesses for tracking where money is coming from how it moves around, and making sure there aren't errors. Money doesn't come out of the blue. Which is why it is the business standard. And the legal requirement in most of the world. One of the most amazing and significant human innovations, IMO.

The credit and debit/what to add/what to subtract rules are only because double entry accounting was invented before use of negative numbers (they were only a weird mathematical curiosity at the time).

So I am not reinventing anything.

Re: Double Entry Accounting for Developers

#64

Post by bdowling »

gowld wrote: post #41
bdowling wrote: post #20

Earlier quoted context omitted.

> I mean, this is just....wrong. It's beyond wrong. The developer here is redefining established accounting terms because he doesn't like their inconsistencies.

> It's beyond wrong. How so? > The developer here is redefining established accounting terms because he doesn't like their inconsistencies. Yes. What's wrong with fixing inconsistencies? Established accounting terms are from 500 years ago when people had trouble with subtraction.

> What's wrong with fixing inconsistencies?

In general, nothing. It's just not the software developer's job. If the accounting profession decided to change certain terms to fix inconsistencies, that would be fine.

Re: Double Entry Accounting for Developers

#65

Post by mehrdadn »

sago wrote: post #63
mehrdadn wrote: post #54

Earlier quoted context omitted.

I think you're confused on what I'm confused about. The positive or negative sign isn't the issue. You could flip all the signs and I'd still have the same problem. > Literally the only 'weirdness' is that money you have put somewhere for future use (like a bank) is negative. But that is literally what I'm talking about. Whether the sign is positive or negative isn't the issue. It just makes no sense for this to be a…

I see, sorry. Thanks for clarifying your question. Transactions always balance. Money always comes from somewhere, and it always goes to somewhere. Total debit always equals total credit. In a double entry accounting system you have to say where that $200 came from. Did it come from a sale (you sold your work, an item), a loan you took, someone you loaned money yourself, or an investment in your company. In double ac…

I still don't get it, sorry. So I worked and earned $200 for my work. It (obviously) came from somewhere—that "somewhere" being the pocket of the dude that paid me. But why is that relevant here? Am I not doing accounting properly until I start tracking what's in others' pockets'? I need to make an "account" for that dude and write down a debit of $200 for him just because he gave me $200 and the sum just has to be $0, or else some catastrophe happens? Isn't that nonsensical?

Re: Double Entry Accounting for Developers

#66

Post by stilley2 »

dragonsh wrote: post #57

Please take a look at document [1] by author of beancount regarding how to do double entry accounting, including introduction to single entry bookkeeping. So far I find this is the best resource for developers to learn about accounting along with illustrations. Debit and Credits are introduced later once the basics are explained in details grounded in accounting principles in play for thousands of years. [1] https://…

Thanks, this was very helpful.

Re: Double Entry Accounting for Developers

#67

Post by kazinator »

That's the silly, confusing view of accounting.

Here is the smart view:

1. The sum of all accounts is zero: that's the fundamental equation. Nothing about assets, liabilities or equity.

2. A transaction updates at least two accounts, by applying deltas to them. The sum of the deltas is a transaction zero. Because of that (1) continues to hold.

3. Accounts which represent outside interests in the business run negative: these include loans and owner's equity. For instance, if the business somehow makes $1000 out of thin air, its cash account goes up by $1000. At the same time, because the owner has interest in the business, the equity goes down by $1000. Equity is like a loan that the business owes to the owner. Or, if the business gets a loan for $1000, the cash goes up; but the loan account goes down by $1000. Other accounts are what the business has, and run positive, like expenses, cash and assets. E.g. if a routine $50 expense is covered, cash goes down by $50, expenses goes up by $50.

4. Expensese are periodically reconciled (e.g. end of year): they cancel out equity. If there is -$1500 equity, and $500 expenses: poof: expenses are blasted to zero, and equity goes to $-1000. (Of course, expenses are also, separately of this, used for claiming tax deductions and whatnot.)

That's it; no confusing debit/credit nonsense, with an increase in such and such account being a debit, but an increase in another kind being a credit. That system is deliberately twisted so that people of typical intelligence need to rely on expensive accountants.

Re: Double Entry Accounting for Developers

#68

Post by ron22 »

Below are some really great free video courses to learn accounting fundamentals from Johnson County Community College.

intro to financial accounting

https://www.youtube.com/watch?v=ZkZ6Q67Q15E&list=PL259DBFA47...

intro to managerial accounting

https://www.youtube.com/watch?v=2cC9SZ3RC8Y&list=PLHhe-2tIHR...

Re: Double Entry Accounting for Developers

#69

Post by zjs »

zzo38computer wrote: post #48
4silvertooth wrote: post #39

Earlier quoted context omitted.

Can you elaborate more on your invention, and how matrix maths work with that equation?

BAL stands for "balance", and FSV stands for "financial state vector". Let's say that you have a transaction T, where $500.00 is debited to one account and credited to another account; in mathematical notation, this can be written as: T = I + |A>$500 - |B>$500 or: T = I + |A>$500 + |B>$500 depending on what basis you are working with (since you can just define |B> to point in the opposite direction if you want a diff…

Do you have a more complete write up of matrix accounting anywhere?

Re: Double Entry Accounting for Developers

#70

Post by jlj »

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…

I learned from my accounting 101 professor, "debits on the left, credits on the right."

Then later after learning about natural account balances, it all made sense. If an account has a debit balance, a debit increases the balance and a credit decreases it. An asset or expense account has a debit balance.

Credit balance is just the opposite. Liabilities, revenue, accounts. Credit is an increase, debit decrease. (I think equity too but I always have to look it up. Rarely work with equity accounts in my day to day)

Post reply on HN