I hope this question isn't too broad. In the future I may need to add some accounting and financial-tracking systems to some applications (mostly web-based applications, but my questions pertains to desktop apps as well).
Now, creating a simple record of financial transactions is theoretically easy. One database table with a few columns could do the job. Even MS Access, Excel, or even just a plain ASCII text file could be used to store transaction dates, account IDs, and dollar amounts. However, I feel that even a frequently backed-up SQL table with transactional integrity might not be robust enough for serious financial tracking.
I hear terms like "double-entry accounting", and I get the feeling that most financial tracking apps (for example, Mint.com, or GnuCash) have a much more complicated data structure or process in place to make double-sure that everything adds up perfectly, exactly as it should, and that no data is ever lost or corrupted.
My question is: When designing an app to track financial transactions, what special design considerations should be made? It seems like there could be so many potential issues... issues with rounding precision, parity checks, some kind of audit process, special backups, security/encryption, extra ways to protect data in the case of a crash mid data-entry.... I don't really know what I should be asking specifically, but I get the feeling that the programming industry has a set of best practices I know nothing about. What are they?
It looks like I opened a bigger can of worms than I expected. To clarify, I'm thinking specifically of two types of apps:
- "Check registry"-type apps like GnuCash or Quicken that maintain a record of an individuals transactions for their own use.
- Apps that track invoicing/credit/or "points" for vendors and customers that deal with a company.
I probably will not be doing any direct banking or (AFAIK) anything that has a ton of finance-related government regulations attached to it.