Hacker Newsnew | past | comments | ask | show | jobs | submit | LeanOnSheena's commentslogin

CPA here again, You're poking and some very interesting concepts! There is a lot to explore. Some thoughts:

- Yes money is in many ways best thought of as an abstraction. A socially agreed upon store of value that is easily exchangeable for other things of value. There is a tension (and a spectrum) between commodities that have use value and money commodities that have exchange value. In nascent market economies, commodities with use value can emerge as money commodities through consensus, that is, they emerge as socially agreed upon exchange value commodities. Think cigarettes in prison or precious metals like gold. Money commodities emerge naturally once there is enough stable volume of market activity which ensures liquidity. It's all contingent on constant market activity to keep it liquid as well as a sustained social consensus that is represents a store of exchange value. This is a lot of what Marx's Das Capital explores.

- Things like vehicle depreciation are not just so the books "work" nor is the intent for it to perfectly represent how an asset depreciates. Consider a milk delivery business. I buy a delivery vehicle year 1 for $40,000 and I expect it to last me 10 years approximately. Let's say I earn $10,000 a year for the delivery business and I pay a driver $7,000 a year to deliver milk using my delivery vehicle. If i don't include depreciation of the delivery vehicle my net income is $3,000 annually or 30%. Pretty darn good! However, we know the vehicle asset was used in service of earning all that revenue, so we should include something to ensure all revenues are netted against all known expenses whether they are wages or capital assets deployed in service of earning said revenues. Otherwise we have an incomplete picture of the business performance in our annual income statement. If I include $4,000 of annual depreciation on the vehicle suddenly I am no longer profitable to the tune of $1,000 a year. This is the matching principle. Profitability needs to ensure all revenues netted against all expenses associated with earning those revenues regardless of cash flow timing.

- But your point stands... The specific amount of depreciation annually is made up mostly, maybe the asset depreciates slower or faster. But there is enormous value in a rule consistently applied. Let's say you're an expert in delivery trucks and you know that the asset will last 20 years not 10... You could purchase the business at a cheap valuation because on paper it loses money annually, but you know the depreciation should only really be 2,000 and therefore the business is actually profitable all other things being equal. You leverage a widely recognized and understood standard applied very consistently as being imperfect, and you use that as a stepping stone to back into what you believe is the true value. This is where things like EBITDA come from that start with GAAP measures and back into what are believed to be better representations of business value, but it hinges on widely understood accounting standards being applied very consistently to create financial information that can be modified for other uses.


Yeah CPA here. On the day you take out the loan you're not in debt 110, you are in debt 100; you would accrue interest expense over the term of the loan. What if the lender called the loan day 2 for some reason? You wouldn't pay 110, probably just 100 plus one day of interest. Goes back to fundamental definitions of financial statement elements. Liabilities are present obligations.

Anyways, recognizing the interest over time would debit an expense account and credit some liability account... Could be the same account as the loan or could be an interest payable account, doesn't really matter in the context of the example.

Also you would not be "in debit"; the liability is on the credit side of your balance sheet.


You failed to check the terms of my loan and assumed it was on an interest basis. I literally told you I borrowed 100 and promised to pay 110. I also failed to note a term and you also assumed there was one. I do mention interest later on so that's a fair assumption, if misguided.

I might be guilty of abusing an industry term or two 8)


You said interest. It's right there. In practice all loans have interest. No matter what you call it, it's interest as the word is understood in finance.


He's explaining the time value of money but uses an example that accrues interest before any time has passed?


He's explaining a bond, ie. it's a promise that you'll get back X+Y in Z years if you give up X now.


The bank of England has some incredible articles that explain this that have been circulated on HN before. Really fantastic reading for those wanting to understand the mechanics.

https://www.bankofengland.co.uk/quarterly-bulletin/2014/q1/m...


Yes, at the time of the initial transaction the borrower would not have a liability on their balance sheet that included the interest due.

Over the course of the borrowing period the borrower would accrue interest expense commensurate with the passage of time that would increase the borrowers total liabilities. The author misunderstands the fundamental accounting definitions of liabilities (and also assets). Liabilities (under US GAAP but same core idea under IFRS) are present obligations. At the initial time of borrowing the borrower does not have a present obligation to pay interest on the liability. Similarly, an asset is a present right, and at the time of initial borrowing the lender is not owed the interest.

It's not the worst thing I've read, the author has clearly spent time learning things in good faith. That said, there are lots of indicators the author is not an expert in accounting / finance.


Most of the really stupid stuff written is written in good faith. It's not an excuse. There are many good books written about the financial system, accounting, etc. Rather than writing just another (incorrect) blog post, why not point to the good sources of information?


I didn't say it was an excuse. There is value in articles that correctly synthesize fundamental concepts in ways that bring in new learners who are curious and open to learning. There are things the author gets right, even if they are a bit facile.


You might be right. It's also possible you are wrong though. Some things have a lot of moving pieces and if one piece is off the entire thing is wrong - so you have to commit to getting a grounding that is quite thorough to have any understanding at all. I'd argue accounting is one such subject, finance is one, the legal system is one, software engineering is debatable, math isn't one.


I am a CPA by training originally, but have spent most of my time in operational finance roles for PE-backed technology companies. While my work is all finance and accounting related, I mostly work with SQL and Python day to day creating internal applications for things like ARR etc.

I agree completely on your "thorough grounding" comment. I spend a lot of time explaining to finance people how tools like python, SQL, AWS stuff can be leveraged in simple ways for analytical purposes, and I spend a lot of time explaining to technology people what all the finance and accounting stuff is really about. In both cases my experience is it always comes back to explaining fundamental ideas or concepts over and over, but applying them to different situations and contexts (I do so much more confidently when explaining accounting and finance stuff since I have deeper education & experience there).

A lot of times these fundamental ideas and concepts can be explained very simply and intuitively using toy examples. the problem is it can take years and years to build up enough experience to really separate the signal from the noise and see clearly what is truly fundamental (yes that's where formal education is helpful but it can be hard to really grok absent experience imo... In the same way learning a programming language can be easier if you just try to build something).

A deep understanding of fundamental concepts is what allows you to pick apart very complex and novel problems into it's component parts. A deep understanding of fundamental concepts is one of the things that separates professionals from non-professionals in my opinion.


That sounds like it would make one hell of a tech talk. I have a gut feeling many readers (especially lurkers) of this very thread would gladly watch the recording.

Common and/or various ways the two groups misunderstand each other, and how you help them to anchor to the underlying base concepts? Yes please. For example, we know that interest accrues over time, but we still use shorthand for the annual interest as a step function because it makes intuitively more sense.


There isn't a short cut. You just have to understand both topics.


Going in without understanding the underlying basic concepts is, just... well let's just say I completely agree with your comment!


Rather than leaving some oblique references to "many good books", why not provide the actual references?


Because not everyone can read the source. Hence might be better to say let us have better summary or take, not just post to the source guy.


You're correct on all points. Some additional refining points regarding accounting concepts:

- General legers are formed by way of transactions recorded as journal entries. Journal entries are where two or more accounts from the general ledger are debited & credited such that total debits equals total credits. For example, a sale will involve a journal entry which debits cash or accounts receivable, and credits revenue.

- The concept of the debits always needing to equal credits is the most important and fundamental control in accounting. It's is the core idea around which all of double entry bookkeeping is built.

- temporally ordered Journal entries are what form a log from which a general ledger can be derived. That log of journal entries is append-only and immutable. If you make an mistake with a journal entry, you typically don't delete it, you just make another adjusting (i.e. correcting) entry.

Having a traditional background in accounting as a CPA, as a programmer I have written systems that are built around a log of temporally ordered transactions that can be used to construct state across time. To my colleagues that didn't have that background they found it interesting but very strange as an idea (led to a lot of really interesting discussions!). It was totally strange to me that they found it odd because it was the most comfortable & natural way for me to think about many problems.


Hi rendaw, I made an account just to reply to you because I think your questions are excellent ones.

I am a CPA by background. While much of my professional work today involves programming and working with data, I continue to work primarily in accounting and finance contexts because it is the type of work that I find most interesting.

I don't have a ton of time right now but let me at least answer your first question "what are you trying to solve by doing accounting?". At its core double-entry accounting is a control system (e.g. safeguarding the resources / assets of a corporation by tracking their use). The most important control is that debits must always equal credits. You might understand that in the context of a balance sheet, however it's important to recognize that double-entry accounting systems record business events by way of journal entries. A valid journal entry must include two or more accounts where the sum of debited amounts always equals the sum of credited amounts (if you want to understand why that is a rule I can talk about that in another post). It is a simple & rigid rule, however it still affords enormous flexibility in terms of being able to precisely express business events.

All financial statements are derivative of a series of time ordered journal entries. This series of entries is known as the general journal (not the general ledger which is more often talked about). The general journal is basically just a log of business events. Business events recorded in the form of journal entries are discretely understandable, although you often need the context of other entries to be sure about what's actually occuring.

It's also very important to recognize that this log of journal entries is append-only and immutable. If a mistake is made you never go back a delete an old journal entry, you just make a new one to correct it (sometimes called an adjusting entry). This preserves the ability to review journal entries and intuitively understand what a business is doing over time.

For example, when a company makes a sale you might see a journal entry where accounts receivable is debited and the sales account is credited. A week later you might see a journal entry where cash is debited and accounts receivable is credited, reflecting that the amount for the sale made a week earlier was collected.

This concept of an immutable time-ordered log of events is / was a powerful and useful idea for some obvious and not so obvious reasons that I could talk about for days.

I believe this blog post is also valuable to read and it specifically mentions accounting data structures (I believe it is fairly well known) https://engineering.linkedin.com/distributed-systems/log-wha...

Can talk more later if anyone is interested.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: