Accounting for Developers
docs.google.com
docs.google.com
Yin: Cash Account
Yang: Salary Account
(amount: $salary)
Yin: Dinner Expense
Yang: Cash Account
(amount: $bill_amount)
Yin: The Bank Account
Yang: Salary Account
Yin: Cash Account
Yang: The Creditor Friend
Now replace Yin with Debit and Yang with Credit, and that's mostly it.
Look at this poster's history. He's got a track record of thoughtful contributions -- this post is no deviation. Just because you don't understand what he's saying doesn't make his comment incorrect or irrelevant.
The analogy is used to show how both debit and credit have a dual and interconnected relationship than the more simplistic notion of being opposites.
If anyone is interested in this way of looking at bookkeeping, here is a lengthier explanation with examples: https://github.com/jasim/bookkeeping
We'll read that document and incorporate the ideas where they're helpful.
Thanks!
For example, if you earn money (get revenue) this is something that you would typically consider 'positive', however revenue is a credit account and so the earning of revenue is actually a credit.
A simple trick is to recognize that balance sheet accounts have signs that align with our intuitive understanding of positive and negative, whereas income statement accounts are flipped. To grok why that is gets a little more tricky and the linked article seems to give a great basis for understanding that.
Source: I'm a Canadian CPA, CA (and CBV) and soon-to-be software engineer. I think this helps understand both perspectives.
We agree 100% as discussed in the docs.
We also believe that classifying expenses as debit-normal on the income statements, thereby obscuring their contra-income status is part of the puzzle.
For me, what made this less tricky, was thinking in terms of flows and their accumulation. A debit entry is a flow of value into an account, a credit entry is a flow of value out of an account (a debit or credit balance is simply an accumulation of those flows.)
It boils down to only one principle: "Every transaction must balance". This is similar to the base natural law of energy conservation. There's no free money. Money going to one account has to come from somewhere.
The rest is convention, what we call income/revenue, expense, liability and equity, and how to structure our accounts and reports. It's all nicely explained in http://ledger-cli.org/3.0/doc/ledger3.html
Give ledger-cli a try. It has superb manual, and after reading it I stopped being cofused by bookkeeping terminology used elsewhere.
"Every transaction must balance" is a succinct explanation, but it is unfortunately even one more level abstract for someone not exposed to the very idea of book-keeping. The hope is that showing a few entries without being muddled in what is debit and what is credit territory, and how they relate to each other will trigger the aha moment a little sooner.
That said, this is very dangerous knowledge; once bookkeeping makes sense like this you will constantly have to resist the urge to yell at people who claim "expenditure X really shouldn't count because it has benefit Y", which is a disturbingly common belief among otherwise smart people.
On paper there were many employees that made more annually than the CEO.
For what it's worth, I never once payed a late fee. I'd pay the original amount no matter how late and never heard a word from the receiving end's AR department.
But, a little information can definitely be dangerous. It can be a huge time sink to "restate" the books to suit someone's vision and at worst it allows people to misrepresent the information.
I think of them as distinct and separate concepts:
bookkeeping: the recordkeeping of transactions. The "data entry". You can have lower wage data entry clerks tearing open envelopes to type in data from vendors' invoices and recording deposits of checks from customers. At this layer, the data needs to be recorded correctly.
accounting: literally the management of "accounts". This is a position of education (CPAs). Their value-added thinking happens above the layer of bookkeeping. They use professional judgement to set up a "chart of accounts" ... what kind of buckets to keep track of various money, how many buckets, etc. They are in charge of "closing the books" each month and preparing financial reports.
Yes, sometimes the activities blend into each other. Some bookkeepers do higher level "accounting" activities and some Certified Public Accountants also do grunt work of "bookkeeping" but they're still separate cognitive activities.
Lastly, there's finance. The finance layer sits above accounting and bookkeeping. Finance management (CFO, treasurer, etc) focuses on strategy of money. Should the company lease or buy the building, the tax implications of foreign earnings, stock buybacks, etc. The accountants & bookkeepers can report exactly how much money is sitting in the bank but they are not the ones who decide what the best strategy is for it.
It's the small businesses where "bookkeeping" and "accounting" are synonymous (e.g. using Intuit QuickBooks). In those mom & pop shops, the "finance" strategy is handled by the owner(s) of the company.
I was emphasizing the different "cognitive activity" of each instead of job titles. As for workers' positions/roles, that's more fluid.
For example, in the small company[1], the "bookkeeper" is also doing the "accounting tasks".
In this other larger company[2], the "bookkeeper" is more of a data-entry person and reports to the CPA.
[1] http://jobview.monster.com/Bookkeeper-Job-Palm-Bay-FL-US-151...
[2] http://jobview.monster.com/Bookkeeper-Logistics-Firm-Job-New...
I have wondered the difference, because I had two friends who had vastly different incomes, but were doing essentially the same work.
My first friend(former girlfriend in college) became a CPA, and was working for a small VC.(when I knew her I don't think they were calling themselfs venture capitalists? They were just small cap investment firms--basically a rich guy who invested in small business.) Well, since she was a CPA she had no problems in obtains jobs, and salary was not an issue. I guess she was a good accountant?
My other friend who dropped out of school, and didn't get his bachelor's degree went into bookkeeping. He took a tremendous amount of business and accounting courses at various community colleges. He wanted to get his CPA, but didn't have the auditing experience(not required anymore in CA), and didn't have a bachelors degree. He did some amazing things for just a bookkeeper. He was highly instrumental in making the owner of a small local bike manufacturer a multimillionaire. He was always working, but never got close to the salry of the CPA. I recall him saying he coukd pass all four sections of the CPA exam, but couldn't get his license because he lacked the education/auditing requirement.
I have thought about the two over the years; and without a doubt If I needed an accountant, I would hire my friend without the CPA license. Why, because I know what he did professionally. I still think about that deal he put together. I know we need a CPA licensing system, but don't discount the bookkeeper with the spectacular work history?
My point is get that CPA if you can afford it? I'm pretty sure the bachelor's degree can be in any major. You need certain amount of accounting courses, and a one year of experience working under any CPA, at any company.
(What I find troubling in CA is under Brown--it appears Lobbiests got their mits on Gov. brown and made it harder to gain entrance into certain professions. I'm not sure if easier, or harder to become a licensed CPA before Brown? I do know he caved into the Realeste brokers lobby. It is harder to become a real estate broker under Gov. brown. When Gov. Scheartzenegger was hit by the Reators lobby he said, 'I'm sorry. I don't want to make the broker's license more difficult to obtain. You haven't presented one instance where the old system failed?' He vetoed the bill.
That day, I went from a militant, strict Democratic to someone who didn't care which party you were affiliated with.)
I've conducted training sessions in accounting (for people whose day job is something else) at several tech firms. Two things I've found drive the points home are:
- having to make a series of debit/credit transactions (from a supplied description of stuff that has happened)
- having to work out what certain items on a balance sheet or income statement mean
It's hard to appreciate the beauty of the accounting equation until you see how the balance sheet, income statement, and cash flow statement are related.
We worked very hard to explain it in a way developers would appreciate.
A bookkeeper will record transactions in designated accounts using the process that has been indicated for that type of transaction. However, the bookkeeper will not be evaluating the revenue recognition process to establish when it is reasonable to record revenue (versus deferred revenue, a liability) as a transaction relates to the standards in effect. It is also likely that the bookkeeper will not be responsible for making calls as to whether certain situations should be recorded as contingent liabilities or simple F/S note disclosures or for things like testing intangible assets for impairment.
For a typical tech startup, there are probably fewer situations that give rise to the need for an accountant than bigger, more complex entities. That being said, I suspect that many start-ups with complex cap tables are not reporting in full GAAP / IFRS conformity simply because this is likely not something required by the users of their F/S.
Many people ask us if we're GAAP compliant, and all the rest.
We just say "we are if you make the right entries!" :-)
GNUCash's (which I use for my personal accounts) guide is unhelpfully down right now, but you can find it here:
http://www.gnucash.org/docs/v2.4/C/gnucash-guide/
I also found Accounting Demystified very useful:
http://www.amazon.co.uk/Accounts-Demystified-Astonishingly-S...
Debits and credits are the foundation on which all of accounting is built. I don't see why you would start anywhere else.
Do you know or believe it to be higher than most other classes?
Thanks for the links, I'll take a look!
We hear about coding being the "new literacy". I am sceptical, but if coding is the "new literacy" then basic accounting knowledge is equally important, in my opinion.
Cannot imagine a more valuable high school class than basic accounting.
I guess you'd agree with us that building any software that handles money should, by definition, use accounting to do so?
'debit' means 'left', 'credit' means 'right'
Then, you just make sure that SUM('left') == SUM('right').
Until you're used to these two words and they speak for themselves, assigning any other meaning tends to lead to more confusion than anything else.
Finally in grad school I got it - left and right - and accounting has never been a problem again.
This seems like a bad legacy passed down unwittingly. I am not trained in accounting, but been keeping my books for several years now. I have written a ledger-cli clone and have been using it for the last three years for both personal and company accounts. Using signed numbers works perfectly fine during book keeping. I use the Debit/Credit lingo only when I need to show reports to the pesky accountants. (Fortunately, my main accountant doesn't bother me with formalities).
> Luca Pacioli, often referred to as "The Father of Accounting," wrote, printed and distributed the first complete description of double-entry accounting in 1494.
From http://en.wikipedia.org/wiki/Negative_number#History :
> In 1545, Cardano in his Ars Magna did not allow negative numbers in his consideration of cubic equations, so he had to treat, for example, x^3 + ax = b separately from x^3 = ax + b (with a,b > 0 in both cases). In all, Cardano was driven to the study of thirteen different types of cubic equations, each expressed purely in terms of positive numbers.
> In A.D. 1759, Francis Maseres, an English mathematician, wrote that negative numbers "darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple".
Visually, it's much easier to distinguish between a debit and a credit if they are in different columns. A tiny little minus sign won't do it. Of course, you could use color, but, that's not always printable. Parenthesis are OK, but, it makes sanity checks in your head difficult. Of course you could do this transformation a report if you wanted, but really, how often does that happen?
Logically, these are actually very different activities. When you debit an asset account, it's representing a kind-of-activity that happens (retained value accumulating). Once you view credit/debit as just plus/minus, you're tempted to neglect the other dimensions of the interaction. To a beginner, debit/credit affect on asset/liability/expense/income accounts seem like an unnecessary distiction, however, the interactions are inverted in their affect. Is minus good or bad? It completely depends upon your perspective.
Redundancy is a feature not a defect; it's a checksum. There's always a tendency to simplify the model and elminate the balancing interaction and check. This is possible, of course, and it does simplify the recordkeeping. However, it means that logical classification errors are harder to discover. When (perhaps big) money is at stake, why take the risk? By having 2 complementary transitions in a more complex space, you cause the person making the entry to think... and that's very useful (even if it's tedious or exhausting).
Pratically, you have convention/tradition. You're making a choice to use plus/minus for credit/debit is one of the distinctions, you could just have easily use it for asset/liability or income/expense. Why favor credit/debit? While this may not be the best way to solve these concerns, the approach is the incumbant -- most financial people expect this kind of problem to be this way, regardless of the extra complexity involved. Tradition here reduces communication overhead.
Even so, the rules arn't passed down unwittingly, they form an approach known to work. I think each generation is welcome to challenge (and they often do challenge) tradition, however, new approaches need significant justification.
The answer is that people intuitively understand what an asset, liability, income and expense is. People don't understand what a debit and credit is. If I deposit money in to my bank, should the 'bank account' in my accounting system be credited or debited? Most people would (incorrectly) say 'credited'.
Sure, transactions are pairs (or balanced sets) of entries. Entries however, are exactly plus/minus movements along a single line in a single account. Sign (+/-) reflects that much better than debit/credit labeling does.
> There's always a tendency to simplify the model and elminate the balancing interaction and check.
Using +/- in place of credit/debit does not eliminate the balancing interaction. In fact, it makes exactly what is done in the balancing interaction more explicit.
> You're making a choice to use plus/minus for credit/debit is one of the distinctions, you could just have easily use it for asset/liability or income/expense. Why favor credit/debit?
Because income, expense, asset, and liability, are all kinds of accounts, and credit and debit are not, they are descriptors of whether an entry (or balance) is a flow (or accumulation of flow) of value into (debit) or out of (credit) an account.
The legacy descends from the fact that accounting was created before negative numbers were in widespread use in Europe.
However, the columnar separation, dual accumulation, and industrial permanence suggest that it's more of a vocabulary issue than technical deficit.
Yes, accounting is that old, with the core absolutely unchanged.
Fundamentally this book is about the application of abstract algebra to the analysis of accounting systems.
Add in APL or J (or Haskell if you must) by way of "Algebra: An Algorithmic Treatment" (http://www.amazon.com/Algebra-algorithmic-treatment-Kenneth-...), and you build a quite rigorous proof-based accounting system.
Would be beautiful to have a provably correct implementation, perhaps v4!
But, I do thinking that financials are something that each person should learn a bit more about. I find it too common that people aren't spending enough time to understand what their financials are trying to tell them. For example, they're generate awesome revenues, but failing to convert it into cash fast enough to meet their debts (statement of cash flows).
Always a fan of everyone gaining financial literacy =).
Looking at the comments on that website, it has even developed a sort of fanboyism. But IIRC, it led to some "interesting" insights when it was first discussed on HN, like "sales are liabilities".
I find the alleged impenetrability of basic accounting to be rather baffling in general.
Sales (Incomes) are clearly equity, with Expenses being contra-equity. Not sure how anyone could come to any other conclusion, but I'll read the article and it'll probably become clear. :-)
Credit is the source while debit is the destination.
Using the source and destination keywords has the advantage of not implying the actual operation to be performed. For eg. credit results in an 'add' operation on an expense account while a 'subtract' operation on an asset account.
http://www.amazon.com/Financial-Intelligence-Entrepreneurs-R...
So far is the only book I know that explains why and not just what.
The thing is, since as early as the 1960s, there has been discussion and publications about event-driven accounting architecture. Pretty crazy, right?
Alas, considering IFRS and GAAP span the world's modern economies, it may be safe to assume that hell will freeze over before any viable accounting alternative to double-entry bookkeeping supplants it.
APAC is really churning. Japan GAAP takes more hints from US GAAP, but many Japanese companies have opted for IFRS. Australia GAAP has some very strange principles, especially around equity compensation, but is beginning to align with IFRS. China, well, I don't really know, but I'm definitely on the lookout for it...
I think it's one of the most interesting of uninteresting things.
No need to summarize monthly what can be detailed continuously!
It's an interesting move to make the docs all google docs, but for readability it really is quite nice!
Your homepage talks about great handling of micro-transactions but I can't find ANYTHING about it in the docs. Can you point me to something?
We never intend to be competitive with the product layers you've described.
We've deliberately built Subledger to enable other developers to build focused custom accounting applications above us. :-)
We believe it's time to move beyond one-size-fits-all approach to accounting! :-)
To me, accounting is a data model gone wrong. Redundancy, race conditions, unclear semantics, too generic...
I've tried countless times to make sense of it (the latest being today when I read the post with great hope), but I always came to the same conclusion: there must be a better way.
Yet I know the value of the model as a log to record transactions.
We're all confronted to accounting (when we read our bank ledger)... Ask the public, and they'll tell you it's good if there's more money in the credit column than the debit column. This "common wisdom" is false in accounting. What's a debit card? a credit card? What's an account? Isn't it a container for money? not for accountants.
Accounting turns many concepts upside down... and I always fail to bend my mind enough to grasp it.
I admire accountants for succeeding where I fail so miserably, but they're also responsible for the problem. There must be a better way... I was so bad in accounting at school...
Accounting invented these terms, but the public has one sided view of it.
That's because the public is used to hearing the terms used by entities who are using them in the accounting sense, but where the member of the public in question is external to the entity whose accounting the term refers to.
So credit -- and outward flow of value -- sounds good, because when the public hears it from another company, its usually because they are the sink to which value is flowing (and debit -- an inward flow -- sounds bad, because the member of the public hearing an external entity use the term is usually the source from whom the value is flowing.)
Of course, neither is intrinsically good or bad, they are good or bad relative to a particular actor based on whether the account they refer to is internal or external to the actor. Debit is just inward flow of value to an account, credit is outward flow of value from an account.
> What's an account? Isn't it a container for money?
That's not a bad approximation; a better approximation would be "a named accumulation of flows of value".
> Accounting turns many concepts upside down... and I always fail to bend my mind enough to grasp it.
Interestingly, all the concepts you list that the public perceives in a way which you seem to think conflict with the accounting view actually reflect limited subsets of the accounting view from a narrow perspective, which are subsumed within the more general view of accounting.
Accounting doesn't turn them upside down, it just broadens them.
It still puzzles me a great deal!
> To me, accounting is a data model gone wrong. Redundancy, race conditions, unclear semantics, too generic...
I felt this once (though don't see the race conditions) but I now know there is no redundancy, the semantics are very good, and the genericity is a gigantic benefit.
http://davids-book-reviews.blogspot.it/2012/12/double-entry-...
John and at appreciate all the discussion and feedback.
We're absolutely delighted to have struck a chord with developers, the intended audience of this piece, and with accountants, who have managed and passed down this technology for 700 years.
We're working through the backlog of comments and will reply where we feel we can add some value.
I'm not sure why you feel the document targets developers specifically. I didn't see any text that's a unique bridge to a developer's perspective.
For example, a text for "developers" might include examples of video game "tokens" or multi-player "weapons" that can be traded. You'd outline a rudimentary outline of what data structure to keep track of the source and destination of where the tokens went.
Or an example would be bitcoin money being subtracted and added to various accounts. Since many developers know bitcoin, maybe map bitcoin ledger concept to accounting concepts. Or explain how they are radically different.
Your current document is a generic introduction and one can search & replace "for developers" to "for biologists" and nothing else would have to change.
Your point is excellent and we'll steer toward developers in the future.
Also, it's by-developer, for-developer, so there's a developer's perspective as well. :-)
I admit the title isn't absolutely fascist, racist, or sexist, but it is some kind of ist, and it is annoying. Maybe accountants, with self congratulatory pride in their profession, feel the urge to divide the world up into neat little categories?
Finally, while I'm delighted that you agree the title isn't absolutely fascist (which you never claimed in the original post and suggest in your response it to be partially), racist or sexist, I'm entirely baffled as to why you felt compelled to post a comment stating it in absolute terms in the first place.
I'm just asking myself why not write about accounting, and let the reader decide what group he or she belongs to. The answer is clearly something like, we need a good title.