>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.