[joyinsky]

Basically the problem here is that the author didn't care even a little to understand why accounting is done with a double entry system.

Basically what he was trying to do here was a expense and income administrator with tags. That it's just a part of what bookkeeping and accounting is.

Nice try. But you can't replace what works and what has been done for reliability and confidence since 1400 at least by the masters of trade.

[sly010]

> You can't replace what works and what has been done for reliability and confidence since 1400 at least by the masters of trade.

I am not sure that is true. Isn't the world full of examples of quite the opposite? Especially because it's 1400 years old an because it was created for pen an paper work. We have computers now.

e.g. It used to be that companies have a handful of yearly profit/loss accounts and every year they "close the books" by transferring all balance to first profit/loss accounts then to equity. The financial year then starts with 0 profit an 0 loss. Afaik nobody does this anymore. Today you just keep all accounts running (don't "close them) and you generate repots by selecting a date range and let the computer calculate profits and losses for that range.

Besides, most commercial software already hides debit and credit from you. I would risk that most accountant don't know their debits and credits, it's just one of those things you learn at accounting school before you start working in the industry.

I agree one should not write an accounting system without understanding the full details and history of the domain, but I disagree that 1400 year history proves anything. In fact even after reading through the Pacioli Group article I still don't see the advantages. It's only advantage is that it makes it harder to make a mistake on paper.

[bokstavkjeks]

>I would risk that most accountant don't know their debits and credits

I've worked in accounting and this is just not true. The ledger is stated in debit/credit and all transactions are done in debit/credit. Even if modern accounting software can automate some of it it still requires the accountant to verify the transaction. Hell, most accountants I know even draw up good ol' T-accounts on paper every once in a while to understand the larger and more complex transactions. I'd think you'd be hard pressed to find an accountant that doesn't know their debit and credit. An accountant that doesn't know their debits and credits is like a software developer that only knows Scratch.

Most commercial software doesn't hide debit/credit, and if it does, you should run away as fast as you can. How do you produce the required documentation for your auditor if the software hides debit and credit?

EDIT: To continue a bit.

>It used to be that companies have a handful of yearly profit/loss accounts and every year they "close the books" by transferring all balance to first profit/loss accounts then to equity. The financial year then starts with 0 profit an 0 loss. Afaik nobody does this anymore. Today you just keep all accounts running (don't "close them) and you generate repots by selecting a date range and let the computer calculate profits and losses for that range.

All companies still do this. It's part of the closing entries at the end of the FY. It's not just that the FY starts with 0 profit and 0 loss, but that that is the entire point of the financial statements. A company has three financial statements: the balance sheet, the income statement, and the cash flow statement. For this example, only the income statement and the balance sheet are relevant.

The balance sheet can be seen as a snapshot of a company. It shows what the company owns (assets) divided into short- and long-term assets, as well as how they paid for it (liabilities and equity). The concepts that it balances assets + liabilities + equity = 0 (debit is positive and credit is negative) is the foundation for the balance. The income statement shows a company's results over a given time frame, usually a year. You can consider the balance sheet permanent and the income statement temporary. Consider a company with the following results per 31.12:

    assets: $10.000 (d)
    liabilities: $7 500 (c)    
    equity: $500 (c)
    net revenue: $5.000 (c)
    costs: $3.000 (d)
    profit/loss: $2.000 (c)

It's clear that the entire ledger balances per 31.12 as the sum of debit is equal to the sum of credit accounts. We also see that the company owns $10.000 worth of assets which is mainly paid for through debt, and that they have a profit of $2.000 since the profit is credit. As the income statement is supposed to reflect the performance over a given period and the balance is supposed to balance, the solution is to transfer the profit to equity to record the profit in the (permanent) balance sheet and reset the (temporary) income statement so that they can record their next fiscal year. To do this they record debit profit/loss $2.000 and credit equity $2.000.

It's also not just a matter of recording the entry, which is fairly easy on modern accounting systems, but as it involves the distribution of profit (and touching equity for that matter) it typically needs the signature of the board.

I was an external auditor and when we did the closing entries for our clients we would require the CEO's or chairman's signature on a printed version of the final entries.

> I agree one should not write an accounting system without understanding the full details and history of the domain, but I disagree that 1400 year history proves anything.

Accounting isn't just a field that has had 1400 years to develop methods to solve the problem in the domain. It's a field that has had 1400 years to build regulations and exceptions. It's also a field which requires a lot of individual judgement. Take, for example, VAT. Here in Norway, the actual VAT law text is about 10% of the text in the handy VAT exceptions and judgement calls book we had in the office.

Writing accounting software that is actually useful for an extended period of time is incredibly difficult due to how accounting laws change all the time. Double the effort if you want the software to make tax returns as well. The company that developed the software we used had personal relations with almost all of their customers and would ask for feedback all the time. They probably shipped three versions during the busy season I was there.

I'm admittedly a fan of double-entry bookkeeping as it's conceptually easy (once learned) to map out complex transactions on a piece of paper.

99% of accounting is bog-standard, but that last 1% is complex as all hell. It can't really be ignored either as it can end up costing you or your client a significant amount of money, or even jail time.

I can't really state specifics, but I had a client whose bookkeeper failed to stay up to date on a very specific subset of a rather specific law which ended up costing the client millions in extra taxes. To put it in perspective, they suddenly had back-taxes for more than their company made in a year in revenues. This change was so specific that there wouldn't have been any consequences if they had done it a few weeks earlier. I'm rambling a bit here, but the point is, if you want to write a new type of accounting software, be really sure you know what you're doing.

[sly010]

Plaintext accounting systems (albeit not the one posted) have a model of a ledger transaction that is basically a list of "postings". Each posting is something moving from or moving to an account. In any transaction you can have many postings with negative or positive values, but the total negatives and positives has to balance. Some software restricts you to predefine accounts to be sub accounts of equity, asset or liability but for the most part there are no other restrictions, it's very flexible, you can set up whatever system you want.

E.g. ( from ledger cli documentation )

   2004/09/29  Circuit City
    Assets:Reimbursements:Company XYZ         $100.00
    Liabilities:MasterCard                   $-100.00
    Company XYZ:Expenses:Computer:Software    $100.00
    Company XYZ:Accounts Payable:Your Name   $-100.00

What I genuinely don't understand is how is this not equivalent to:

   2004/09/29  Circuit City                      DEBITS    CREDITS
    Assets:Reimbursements:Company XYZ         $100.00
    Liabilities:MasterCard                              $100.00
    Company XYZ:Expenses:Computer:Software    $100.00
    Company XYZ:Accounts Payable:Your Name              $100.00

My understanding is that as long as you don't use negative numbers the two forms have the same expressiveness.

Please note that I am only challenging the method of encoding, not the rest of accounting. How you set up and manage a chart of accounts and how you take real world transactions and code them into your system IS very important and I very much acknowledge 1400 years of evolution on that front.

This topic genuinely interests me and I have questions. If you don't mind please drop me an email (it's in my profile) I have a few questions.

p.s. Accounting standards vary. I work with startups in the US (little to no standards).

[bokstavkjeks]

Oh, I get what you mean now. A system like you show is essentially debits/credits, yes. For a lot of the smaller accounting systems, they actually print the GL in the format you show where negative numbers are equivalent to credit and positive to debit. As long as you use the same accounts it should be equivalent.

>p.s. Accounting standards vary. I work with startups in the US (little to no standards).

That's true. Here in Norway, all financial statements are publicly available regardless of company size, so they have to adhere to NGAAP (or IFRS if they're big enough).

[perfunctory]

> the author didn't care even a little to understand why accounting is done with a double entry system

I don't know where you got this idea from. I got an impression the author knows a few things about accounting.