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

11–20 of 193 posts

Re: Accounting For Developers, Part I

#11

Post by stanski »

realityking wrote: post #8
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…

From my, very limited understanding, the big benefit is the representation of obligations and receivables. For example, if you take a bank loan of $1 you’d make an entry for your cash balance to be $1 and your obligations to your bank being $1. Your books are balanced. Now you use that $1 to buy a machine. $1 down from your cash, $1 up in your non-cash assets. For what if instead you pay someone for a service for $1?…

I'm incorporated in Canada and have done my own corporate taxes in the past.

There is no hope to get this done right unless you use double entry accounting as every dollar has to be accounted for. Unlike personal taxes, where you only declare your income and pay a tax on that, every dollar that enters or leaves the company, or becomes a different kind of asset (say computer hardware) has to be declared and everything has to balance at the end of year.

Re: Accounting For Developers, Part I

#12

Post by remram »

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…

This is a double-entry system. You are already doing it. Every transaction decreases an account and increases another.

Re: Accounting For Developers, Part I

#13

Post by Naga »

This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.

Re: Accounting For Developers, Part I

#14

Post by mytailorisrich »

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…

Liabilities (Edit: plus equity) must always equal assets. This is the basic accounting principle.

Double entry enforces this and also ensures that nothing is lost into thin air by requiring that debits and credits match.

So for instance, if you spend money to buy a new laptop that money hasn't disappeared into thin air, it has been used to buy a tangible asset so while your cash has decreased your tangible assets have increased by the same amount (double entry) and your accounts are still balanced.

Or, if you pay a bill then both your liabilities and your assets (double entry) have decreased by the same amount and, again, your accounts are still balanced.

That's how you keep track of this and ensure (well, at least it helps) that your financial situation is accurately recorded.

Re: Accounting For Developers, Part I

#15

Post by tbonesteaks »

Naga wrote: post #13

This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.

Any resources you would recommend to learn the basics and/or fundamentals of accounting and finance?

Re: Accounting For Developers, Part I

#16

Post by Naga »

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 not in quantity.

In reality, its very infrequent that transactions will only have one debit and one credit. 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. But was there sales tax on it? You might have actually collected $115 from them, in which case the entry is to "debit cash for $115, credit sales revenue for $100 and credit sales tax liability for $15". This impacts three different accounts, but really any transaction could impact n accounts. This both simplifies what you need to do to model it, but also acts as a shortcut to the user.

It also has the side effect of being a signal that the sales tax collected and the sales revenue are related. You could also record two separate transactions, one for $100 and one for $15, but the bank statement probably has $115 instead of $100, so how could you ever know what was what? As a former auditor, this is crucial to understanding how past transactions occurred and what they were for.

Re: Accounting For Developers, Part I

#18

Post by neffy »

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…

This is banking centric, but does have worked examples that may be useful.

https://arxiv.org/abs/1204.1583

Above and beyond other reasons, double entry book keeping has some very nice error detection properties (the original reason for its invention) that actually make it quite nice to use as a basis for this kind of software, as it provides a way to catch some bugs very quickly.

Re: Accounting For Developers, Part I

#19

Post by mmcdermott »

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…

In addition to the detail/rigor that most describe, double entry accounting acts as a checksum. If things don't balance there is a problem somewhere. It may or may not be malicious, but there is something wrong.

Re: Accounting For Developers, Part I

#20

Post by Naga »

tbonesteaks wrote: post #15
Naga wrote: post #13

This is a pretty good article about the basics! I'm a CPA who is now working in the tech space. I've helped work on some accounting software and other finance-type processes. I'm happy to answer any questions if anyone has them! Either here, or my email is in my profile.

Any resources you would recommend to learn the basics and/or fundamentals of accounting and finance?

Accounting is also a strange field because its a bunch of almost unrelated fields stuck together. Accounting covers financial accounting (dealing with recording transactions, representing reality, etc), tax, management and cost accounting (things like tracking performance, figuring out what the widget you produced actually costs you, once you've included the direct costs and an estimate of overhead) and a whole slew of other things like internal controls, governance questions (how do you align incentives in an organization?), etc. Picking up a textbook on financial accounting is probably a good starting place to get the basics of debits/credits, but from there it depends what your interests are.

For books on finance, I recommend Niall Ferguson's Ascent of Money as a pretty good introduction into the history of finance and how it all sortof fits together.

Post reply on HN