34 comments

[ 2.9 ms ] story [ 63.1 ms ] thread
Ah. Personal finance. I thought this was finance the industry.
Business finance, actually. Not many individuals generate P&Ls, balance sheets or cashflow reports (though in principle nothings stops this from happening).
The article is about corporate finance, I don't know about you but I'm not disciplined enough to maintain income statements, balance sheets and cash flow statements for my personal life.
overkill, too.
Right. After all how relevant are questions like "how much did I spend to earn my wages" in personal finance? I am guessing one could get some benefit from asking these questions, but not at all sure that most people would care enough outside of a business setting.
That's funny, I misread it as "Finance for <i>Greeks</i> -- which might also be a useful, if short[1], article.

[1] In entirety: "See Iceland".

Currently though the Greeks have crazy* auditing rules regarding VAT, and while this doesn't necessarily hit the finance reports, it is extremely important to be aware of if setting up a finance solution for a business in Greece.....

* As in all invoices are printed on government-issued, numbered sheets of paper and you must track the paper invoice to the sheet you purchased from the tax office, and the same goes with packing slips which are called "transit vouchers"

So I don't think it would be a short article at all.....

No, No, No, No, No.

Assets = Liabilities + Share holder's equity

That is true from an accounting standpoint but does not tell you what a business is worth.

Here are the 2 easiest approaches for "non finance people"

1) Value at a future date of selling the business divided by perceived risk.

Steps: A) figure out what the perceived absolute maximum value your business is worth in 5 years. B) determine the perceived percentage chance of that happening C) multiple by that percentage. D) discount by risk free rate (this will be over many, many people's heads, but it is the risk free rate because the "risk" is built in to the percentage) E) that is the max value.

* Improve the perceived future value or the perceived percentage chance of success or decrease the estimated risk free rate and you will increase your current value dramatically.

2) Use an NPV model to determine the value of your business. This is not a good way to go for VC funding

> Company valuation is a complex subject that I won't attempt to cover here. Suffice it to say that the information on the balance sheet is an important part of determining the value of a company, but it is only a small part.
The article was about basic accounting principles, not enterprise valuation.

Its unlikely that anyone who was reading that article to learn about the basics of accounting would be able to gain anything at all from your comment.

But one issue is that very often times you do value intangibles on the balance sheet, so it is a fair criticism.
accounting and finance are not the same subject matter, finance is more about valuation, accounting is the input that helps determine it. The author is clearly wrong in his/her approach.

See http://pages.stern.nyu.edu/~adamodar/ Buy that guys book, read it, and you will be much better off.

I like the way I got down voted on this one. I'm going to make a post about stupid down votes. This one by far is the best.
Your comment got down voted because your tone was arrogant & you didn't actually add anything to the discussion.

Here is an example (my own) of how to make a comment about business minutia on HN.

http://news.ycombinator.com/item?id=2863071

Don't write like you are some sort of genius because you know more about accounting/finance/ops/whatever than people on a forum which is predominantly engineers. ("No, no, no, no.")

Your point is noted. I didn't want to come off as arrogant and it is understandable why it was downvoted based on that.

I added a framework for valuation and accounting which is a much more accurate than what was written in the article and in a fraction of the space.

The point I am making is very valid and extremely important for people to read after reading that article which is completely wrong in almost all ways.

I'd write it again anytime and gladly be downvoted in the off chance one person reads it and is saved from making huge errors later. (I will skip the "no, no, no" part and adjust tone to keep from seeming arrogant.)

If you're more interested in _personal_ finance for geeks, the manual for Ledger (http://ledger-cli.org/) has some great information in a geek friendly way.
As both a tech and finance geek, one thing that drives me crazy is when someone uses the phrase "I made $X" to describe top-line revenue and NOT their profits. This occurs really frequently due to either people not being informed, or because they are trying to make their company sound as large and successful as possible.
For ISVs it properly doesn't matter much. They usually have rather few expenses.
0_0

High salaries, marketing costs, for SaaS companies infrastructure? ISV is not necessarily 'long guy working out of his attic' - that model is only sustainable for a small subsets of software.

Is it better or worse when they include expenses but don't amortize capital ones?
Here are a few books I recommend and have read:

Finance and accounting for non-financial managers. A great intro for beginners.

http://www.amazon.com/Essentials-Finance-Accounting-Nonfinan...

A first year accounting textbook like:

http://www.amazon.com/Accounting-Principles-Jerry-J-Weygandt...

Then either buy a book on QuickBooks or put yourself on a course. QuickBooks is the best accounting software for startups by far. Only dive into QB once you have a good grasp of accounting principles because it abstracts away the basic accounting equation and double entry system and will give you a false sense of security.

Then to get a solid grasp of finance and how investors focusing on fundamentals view your business, read Security Analysis by Graham and Dodd. The '09 edition has some wonderful additions and updates from the finance gods.

The financial statements of public companies are available at sites like ycharts.com and I recommend reading them and testing your knowledge by spotting things like dips in net income with no corresponding dip in revenue and figuring out why.

What I've described above is about 2000 pages of reading. But slowly work through it and you will come out the other side empowered.

Anyone checked out the Kindle version of the first book? Things with lots of tables and charts often don't work out quite so well on the Kindle...
I found this to be a very useful, extremely basic (read oversimplistic) account. However, it would be very helpful to start out with single entry vs double entry and accrual vs cash basis (which makes the income statement vs statement of cash flows make a lot more sense).

Of course some fundamental ideas (debits vs credits) are complicated enough to explain that most who try are just confused and confuse the reader.

Disclaimer: I write accounting software (LedgerSMB) so pretty sure I am a geek who has a decent working knowledge of finances or maybe even a accounting geek.

Surely what the world needs is finance for _Greeks_ no?
From the article:

> Your version of Linux is essentially the same as mine. If you try to charge too much of a premium, I will undercut you on price, [...]. Open source companies tend to operate at lower gross margins. That doesn't mean that open source can never work as a business model. However, no matter what anybody says, if two companies have the same risks and operational costs, the low-margin company is a lot harder to manage than the high-margin company.

I get the impression that the author is somewhat stuck into the common thinking of software only as a product. The statement above is true if you try to sell licenses. However, there are lots of more clever Open Source business models out there.

For instance, you could treat software as an infrastructure like a street or a computer network. You get paid on improving parts of it and/or providing services around it.

Of course, software is neither a product that is first designed and then mass-produced in factories, nor is it a street on which regular roadworks are necessary. However, treating it as the latter seems to be more suitable for Open Source software.

The fact that the article is from 2003 may have something to do with it, since SaaS wasn't as big then as it is now.
There seems to be a misunderstanding. I wasn't talking about software as a service, I was talking about service around software (e.g. guarantee that it works, provide a hotline for all kinds of issues, which might include fixing bugs etc).

In constrast, SaaS is usually quite the contrary of Open Source. You do not only pay per license, but for usage time and/or the amount of data. You don't see the source, you can't make any modification, you don't have any direct access to the machine, and you are (usually) stuck to a single vendor. All of this could be fixed, of course, but as of now, the economy model around SaaS is more an aggravation of the proprietary model, and nowhere similar to Open Source business models.

Right, and then you end up in the situation he described 3 paragraphs earlier:

"In contrast, custom software development or consulting has a lower margin, because programmer time is included as cost of revenues. For every hour of time we charge, we have to pay an hour's wage to the developer who performed the work."

So still in a low gross margin position, where the only way to scale the business is to sell more programmer-hours.

This is true for the custom development, but an Open Source business model is usually more. For instance, selling quality guarantees and providing hotlines can scale much better. That way, you invest a fixed amount of work in thorough testing, and sell this on every support contract. Also, investing programmer-hours in fixing bugs ensures you won't have to hire more hotline people to tell customers how to work around those bugs.
That's just wishful thinking. Who sells 'quality guarantees'? It's always packaged as 'support', which boils down to support personnel man hours. So still pay for worked hours.

If you fix bugs you need to contribute back to the trunk, at which point anybody can use them without paying for the dev time. Paying devs to work on such a project is useful mostly as a marketing tactic, and to develop in-house expertise on the tech.

Let's face it, all open source business models boil down to repackaged and rephrased consultancy work, which scales by making more paid hours. It's as simple as that.

I'm going to nitpick a bit and say this article would be better titled, "Accounting for Geeks". Over simplified, finance is more forward looking, while accounting is a reflection or recording of what has happened in the past. Income Statements, Balance Sheets, and Cash Flow Statement are accounting instruments.

To be fair, the article talks about funding, which is finance, but brushes over the differences between debt and equity finance and doesn't provide the tools to evaluate when, what, and how to finance.

Tech start ups are probably in a, take what you can get, position for funding. Still, having an understanding of finance could help with evaluating things like convertible notes which start as debt and can optionally convert to equity.