Live data from Hacker News

Double Entry Accounting for Developers

django-hordak.readthedocs.io

71–80 of 237 posts

Re: Double Entry Accounting for Developers

#71
post #17

One of the best developer-oriented explanations of accounting I've read is "Accounting for Computer Scientists" by Martin Kleppmann.[0] He explains double-entry accounting visually in terms of graph theory. Even though I'm not very good at graph theory, I found the diagrams and explanations extremely intuitive. [0] https://martin.kleppmann.com/2011/03/07/accounting-for-compu...

Oooohhhhhhhh.

It just clicked for me what to "open an account" acually means. Literally adding a node to the DAG, or in the old school accounting world, creating a new page in the entry book.

Re: Double Entry Accounting for Developers

#72
post #63

Earlier quoted context omitted.

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

I suspect the misconception might be that you think individual accounts must balance (Or think that what I'm saying). Transactions always balance, companies always balance.

In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you.

You will have an account in your accounting of 'income' (it's usually called 'Revenue'). If you have even the slightest complexity in your business, you will have many income accounts. Some businesses will definitely track at the level of detail where they have accounts for each customer, so they can see who purchased how much.

Each transaction balances.

Each line in a transaction is associated with an account.

So if you have done 50 weekly transactions of:

Revenue>Consulting $1,000CR

Assets>Bank $1,000DB

Each one balances.

But in total you will have $50,000CR in Revenue>Consulting and $50,000DB in Assets>Bank, but your company will still balance.

If you pay yourself $45,000 in salary from that, let's say in one go at the end of the year (to save me typing) you would have a transaction:

Assets>Bank $45,000CR (it came from your bank account)

Expenses>Salary $45,000DB (it went to your salary)

So at the end, your accounts are:

Assets>Bank $5,000DB

Revenue>Consulting $50,000CR

Expenses>Salary $45,000DB

This still balances. Double accounting always balances companies and transactions.

Historically it balances credits and debits. All I'm saying is it makes more sense to think of debits as negative and credits as positive, and all the math becomes much much simpler. Which is how accounting software is written.

Re: Double Entry Accounting for Developers

#73
If we’re talking “accounting for developers”, I’d like to plug the FOSS accounting system we wrote which uses event orientation to model the entities that a business owner actually things of (invoices, wages, etc). Side effects like taxes and legally required artifacts can be generated by rules.

We’ve used it successfully for the last years to do our companies bookkeeping.

https://github.com/200ok-ch/easy

Re: Double Entry Accounting for Developers

#74

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…

#1 and 2 are generally correct. Personally, I would remove the quote "nothing about assets, liabilities or equity". Accounting is "all about" those accounts.

#3 couple edits: Change "the equity goes down by $1000" to "either equity or liabilities will increase by $1000". Equity will either remain the same or increase when a business obtains $1000 out of thin air.

Change "the loan account goes down by $1000" to "the loan account goes UP by $1000". Obtaining a loan will increase cash/increase liability accounts.

#4 is correct.

Re: Double Entry Accounting for Developers

#75
post #41

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?

Nothing, if you can convince the entire user base to do it at the same time. If you decide to unilaterally fix inconsistencies, you've just made it impossible to understand what anyone is saying without additional metadata saying which version you're using.

And if you start telling learners that your "fixed" version is all there is, hiding the actual standard that most of the world uses, you are basically lying to them and setting them up to fail.

Re: Double Entry Accounting for Developers

#76
post #72

Earlier quoted context omitted.

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

I suspect the misconception might be that you think individual accounts must balance (Or think that what I'm saying). Transactions always balance, companies always balance. In double entry accounting you track where money came from to you. You are right in not having to worry where they get their money from. But you do have to track how/why it came to you. You will have an account in your accounting of 'income' (it's…

Ah okay thanks a ton! I think that clears it up. So basically:

- The idea is that every source/destination ("node") of funds keeps their own account for every node they deal with. And every transaction ("directed edge") necessarily needs to be tracked by both accounts in an equal and opposite manner.

- This is mainly only useful for businesses, as they generally have multiple sources of income (and/or multiple creditors) and need to be able to explain/track them. (At least as far I can see, I don't really see much of a point in doing this for the average person.)

Re: Double Entry Accounting for Developers

#77
post #43

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?

Any sort of mid-to-large e-commerce company will have a large back-office ERP system (e.g. SAP, Oracle Financials, etc.) that needs to correctly account for data coming from the user-facing transactional systems (i.e. the website or mobile apps). How the transactional data from your runtime systems (usually stored in a relational DB) is accounted for in these ERP systems is tricky and can have big implications if not done correctly.

Re: Double Entry Accounting for Developers

#78

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…

This comment expressing confusion on this valiantly misguided OP seems like a good place to throw my standard explanation out into the aether to do neither readers nor myself any good.

A transaction has two polarities, because it represents a flow of value. The credit side is the source, the debit side is the sink/destination/whatever. Let's temporarily pretend that every transaction hits exactly two accounts for the moment (which is not true), to make it easier.

Let's say we have $1000 in Cash, which is an Asset, and we want to buy a Pizza, which is also an Asset, for $20. How does this look in accounting?

Cash provides the source side, and Pizza provides the sink. Cash is credited $20, and Pizza is debited $20. If we ran the balances now, Cash would come out to $980, and Pizza would come out to $20.

Let's unwind that transaction. We're a business; we don't trade cash for pizzas. We contract for delivery of pizzas with a pizza vendor, who invoices us.

So here we are, with $1000 in Cash and $0 worth of Pizza. The pizza delivery driver comes, and hands us a pizza and an invoice. We know we have to debit Pizza $20; what is the credit source for this debit? Well, the pizza vendor has actually extended us a loan worth $20, in a sense (this is called "trade credit"), and the offsetting entry is the fact that we owe the vendor $20, as memorialized in its invoice. This goes in a Liability account, usually called something like Accounts Payable.

Current balances (if we ran them - "running the balances" is thought of by accountants as a discrete operation, just FYI):

  Assets/Cash $1000
  Assets/Pizza $20
  Liabilities/Accounts Payable $20
Accountants think of accounts as being naturally debit-increased, like Assets, or naturally credit-increased, like Liabilities. I find it a bit misleading to try to think of these as positive or negative signs, as you might be inclined to at this point. It's just $20 - don't even think of it as cr $20, IMO. (dr and cr are the abbreviations for debit and credit.)

Let's just leave that on the books and eat the pizza. After eating the pizza, we no longer have $20 worth of pizza, so we have to credit Assets/Pizza $20. What do we debit to offset this - i.e., where did the pizza value flow to? In this case, it would be a Depreciation account (these are debit-increased) - something like Depreciation/Eaten Pizzas. So we have:

  Assets/Cash $1000
  Assets/Pizza $0
  Depreciation/Eaten Pizzas $20
  Liabilities/Accounts Payable $20
(a commenter below points out correctly that this would be an Expense, not a Depreciation, and I'm still in the edit window!)

Meanwhile, someone pays us on one of our invoices, which we had sent out earlier offscreen. When we delivered our fine $50 widget and invoiced the buyer, we entered that into our accounting system as a debit of $50 to Assets/Accounts Receivable, and a credit of $50 to Assets/Widgets. This part of the system looks like (we still have 9 widgets in stock):

  Assets/Cash $1000
  Assets/Widgets $450
  Assets/Accounts Receivable $50
But now that the invoice is paid, $50 of value flows from our receivables asset into our cash asset - i.e., we credit A. R. $50, and debit cash $50. Getting paid is nice.

  Assets/Cash $1050
  Assets/Widgets $450
  Assets/Accounts Receivable $0
After the customarily long delay, our accounts payable department has approved payment of the pizza invoice. Cash has to be credited, because cash is flowing out, and it's probably easy to guess the debit where it goes to - that's right, our Liabilities/Accounts Payable is finally cleared, because we don't owe the pizza vendor $20 anymore.

  Assets/Cash $1030
  Assets/Pizza $0
  Assets/Widgets $450
  Assets/Accounts Receivable $0
  Depreciation/Eaten Pizzas $20
  Liabilities/Accounts Payable $0
Hope that makes sense. It gets more complicated in real life. Accounting is nontrivial. If there are any accountants in the thread, maybe they can correct any errors I've made.

Re: Double Entry Accounting for Developers

#79
post #70

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

Equity accounts are confusing.

Re: Double Entry Accounting for Developers

#80
post #69

Earlier quoted context omitted.

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?

Unfortunately, I don't have a complete write up on the computer. I could take the time to write it (since I know how it works, and could write about it), although I do not want to do right now (but maybe later).
Post reply on HN