The historical significance of Double-Entry bookkeeping can not be understated. Prior to Leonardo "Fibonacci" Bonacci bringing it to Pisa from the Arabs in Algiers, North Africa, there was no concept of "budget" for most merchants, each transaction was a separate affair, and consequently, finance could not scale. There were several attempts at international lending, and it bankrupted the Bardi and Paruzzi companies who lent lots of money to King Edward III, who ended up defaulting on it. The Medici family succeeded where others failed, providing a level of service in banking previously unparalleled, thanks to being able to manage complex cash flows through Double-Entry bookkeeping. (Fibonacci also introduced the Hindu-Arabic numeral system at a time where most of Europe was using Roman Numerals for arithmetic). It made the Republican city states of northern Italy on par with the political power of noble families, and as other countries caught up with Florence, one could, for the first time, seek an education outside of the Church and in their own country.
Every programmer should be familiar with one descendant of double-entry bookkeeping: the integer. Though its binary representation may be more familiar, the formal mathematical construction of the integers consists of an equivalence class of pairs of natural numbers. In the Chinese "Nine Chapters on the Mathematical Art" they describe red and black counting rods denoting gains and losses, and the equivalence class being that taking away a red and black rod at the same time leaves the "total" or normalized form unchanged. Integers took a lot of time to be accepted in mathematical practice, but they were in use for far longer.
Thanks for sharing this; I doubt I will ever buy a book just to learn about double entry and Venice (despite I love historical books and I have a special interest for Venice).
Would you mind sharing a brief summary of what the book says?
> Though its binary representation may be more familiar, the formal mathematical construction of the integers consists of an equivalence class of pairs of natural numbers.
That's an elegant construction. It's interesting how different number sets can derived from pairs of a "smaller" set, equivalence classes, or both.
integers: equivalence classes of pairs of naturals
rationals: equivalence classes of pairs of integers
reals: equivalence classes of Cauchy series on rationals
complex numbers: pairs of reals
It's quite thought provoking to arrive at the construction of complex numbers just by counting apples.
James Burke's The Day the Universe Changed (both the TV series and accompanying book) have more to say about Fibonacci, specifically in the chapter Point of View.
Intresting facts:
1. Fibonacci didn't invent the series named after him. He was merely copying it from the Indians he came in contact. He himself admitted this
2. Hindu arabic numerals are just Hindu numerals. Arabs didn't add anything. Roman numerals reached the world due to Beitish but they aren't called British-Roman numerals.
Yeah, many hindu digits are ostensibly by inspection the origin of the Latin digits we use today in the west, while the Persians and Arabs adapted the system to their own writing (which you can also tell by looking at the actual arabic digit system which has different glyphs but orders the numbers the same way the Hindus did — so numbers are written little endian in Arabic but spoken big endian like everyone else). They are quite reasonably referred to as hindu-arabic simply because the Islamic scholars introduced them to Europe.
Likewise we ought to refer to most of Greek philosophy, poetry, and literature as “Greek-Arabic” as without the Islamic scholars who preserved it very little would have survived.
Not doubting these points, but you should always cite peer-reviewed or otherwise verified sources. It makes all the difference between a fact and an opinion. This is especially true when contradicting a widely held belief. Without a verifiable source, these are just "interesting hypotheses".
1. Please read "Liber Abaci". It is right there in the prologue section. Hard to find a free copy of this link hence posting a link to tweet[1] with screenshot of the relevent page. You can also cross verify with Italian version on archive.org[2]
2. Same story repeat itself with Indian numbers and algorithms.[3][4]
Can anyone explain why 'income' is negative and 'expenses' are positive?
It seems to me like it should be the other way around.
All I can think of is to ensure that
sum (expenses) + sum (income) = delta(sum(assets) + sum(liabilities))
Over any given interval of time. But really, adding a single minus sign in the above equation would make the rest of the story so much more intuitive to beginners. I wonder if this is just an ossified bad choice, or if I am missing something.
I took accounting in high school, and then again in college for my minor in management.
I learned that in basic book-keeping on paper, the key really was just "classification"; that is, understanding what category an account was in (not immediately obvious for things like depreciation/amortization, etc). That determined the perspective from which things are seen, and so debit/credits became clear. However this method turned out to be really unwieldy to program on a computer (I even tried to build a double-entry book-keeping spreadsheet on Excel but failed). The author's method is far preferable and far more programmable -- I wish I had this insight in college.
At the basic levels, book-keeping is about a couple of things:
1) Recording transactions in a "journal"
2) Posting from said journal to "accounts" (Dt/Cr) = i.e. double entry accounting
3) Doing reconciliations (e.g. bank reconciliation) to make your accounts consistent with some third-party
4) Doing cash flow analysis
5) Preparing Income Statements and Balance Sheets, which is used to analyze a company's cumulative/current position.
Most accounting courses cover these steps (called "book-keeping") but real "accounting" is more than this: it's about getting insights from these numbers, by calculating useful ratios, KPIs etc.
The real insight from accounting is being able to deduce a company's strategy from their financial statements. Apparently this is one of the things Harvard Business School teaches in their MBA program that few schools do.
Also, if you read lots of SEC 10-k filings (like Warren Buffet does), the claim is that one should be able to put together a story of what a company is doing by looking at how it's managing its money, what it is investing in, and so on.
Yeah, you have to shift your mind a little and think in terms of the flow of money. Income is money flowing from "the world" to your assets. In order for your assets to be positive, the income must be negative. Expense is the exact opposite; it's money leaving your assets to go to "the world".
Basically, think of the left side of your equation (expenses + income) as "not yours".
> Can anyone explain why 'income' is negative and 'expenses' are positive? It seems to me like it should be the other way around.
This is something which trips a lot of folks up, but it has a very simple explanation: in double-entry accounting money always flows from one account to another, e.g. from income to a bank account, or from the bank account to an expense. The income account is always negative because money is almost always leaving it, and the expense account is always positive because money is almost always entering it (I wrote ‘almost always’ in both instances because one might need to repay erroneous income or one might get a refund from an expense).
The system would still work if everyone decided to switch signs like you said. But it would be confusing without standardization, so we've all agreed that Debits are positive and Credits are negative.
Plus, switching signs doesn't make it any easier to understand as a whole. A simple example: You're Blockbuster and a customer gives you $5 to rent a video.
Cash +$5
Income -$5
If we switched the signs, now our Income would be easier to understand (changed to a positive number), but Cash would be negative (and more confusing - why would it be negative when we received cash?)
If you credit your bank account do you have more money or less?
Financial Income is in a denomination that is not yours. When you receive more of the denomination you are receiving more of somebody else’s liability to you.
If you like this you will also like beancount[1] and fava [2]. The author of beancount initially started using ledger-cli and than to have a better adherence to accounting developed beancount in Python. Beancount has similar file format as ledger-cli with few modifications and can attach documents and metadata to entries. Also web interface fava provides a beautiful interface to it.
One of the main troubles I have with beancount/fava is their multiple currency behaviour. If I made some income in some foreign currency in say 1995, the amount would be shown to me as converted to my base currency at today's exchange rate, not at the rate that was in 1995 when the transaction actually happened. That makes sense for assets and liabilities, but not for incomes and expenses. The software fundamentally lacks an ability to make this distinction between these two different sets of accounts in this dimension.
I mean when using the price system which the author recommends for multi-currency transactions. What you say is possible when using the cost system, but leads to a lot of other complications as it means maintaining an inventory/lots for these transactions, and the documentation also suggests not taking that route.
I'm not entirely sure what you mean by "the amount would be shown" but if you want to know an amount when the transaction actually happened all you need to do is call the API beancount.core.inventory.Inventory.reduce(position, currency, price_map, date) and pass in the date you want.
Though I agree with your complaint that beancount surfaces it in inconsistent ways. If I change today's exchange rate for USD/GBP then many parts of beancount will then (incorrectly) change my income for the year 2015.
But that is really a bug that could be fixed (using the API I just highlighted) rather than some fundamental problem. And surely on hackernews one should hack on software and improve it.
When I comb through financial statements (for fun, but not much profit yet) I always feel like I'm analyzing stack traces. How I wish there was a gdb/rr/Valgrind or similar debug framework for financial accounting statements.
EDIT: Spreadsheet software helps a lot, but that's about the same as being given a hex editor. Necessary, but oh so tedious.
I have been taught accounting along with micro/macro economics and bunch of other useful financial topics at equivalent of high school and I am really happy that I did even if I did not appreciate it at the time and went for completely different studies and job (studied theoretical mathematics, working as a software developer).
What I have noticed is that people who don't have any accounting background tend to think single entry when they look at their accounts and this frequently prevents them from understanding what is actually happening.
>"Income numbers are negative, and Expenses numbers are positive. So if you earned more than you spent (a good outcome), the final sum of Income + Expenses balances will be a negative number"
This is kind of counter intuitive. You would think of income as being positive and expenses being negative. This is why accounting trips me up.
The problem is that you're thinking of "income" as "the amount of money I received". That would, of course, always be a positive number. Income accounts actually represent the source of income, such as a customer or employer; you received money from somewhere, and so the balance of that source has decreased, while your own assets have increased. Expenses are just the opposite: a negative entry in your asset account, counterbalanced by a positive entry in the expense account representing the recipient of the money. Your loss is their gain. You could flip it around but then your own asset accounts would have negative balances. Or you could do what some accounting systems do and selectively negate the balances for credits and debits depending on the type of account, but that's just confusing all around.
Every programmer should be familiar with one descendant of double-entry bookkeeping: the integer. Though its binary representation may be more familiar, the formal mathematical construction of the integers consists of an equivalence class of pairs of natural numbers. In the Chinese "Nine Chapters on the Mathematical Art" they describe red and black counting rods denoting gains and losses, and the equivalence class being that taking away a red and black rod at the same time leaves the "total" or normalized form unchanged. Integers took a lot of time to be accepted in mathematical practice, but they were in use for far longer.