Accounting Software Design Patterns

Question

Are there any good resources (books, authoritative guides, etc.) for design patterns or other best practices for software that includes financial accounting features?

Specifically, where is good information about handling issues like the following:

• Internal representations of money quantities
• Internal representations of accounts, journals, and other records
• Reconciling inconsistencies (either automatically or via user action)
• Handling ends of accounting periods (daily, weekly, monthly)
• Designing UIs and printed financial reports that make sense to businesspeople

---

Note: "Authoritative" or otherwise widely-accepted information is what we're looking for here. Otherwise, this just turns into a big list of anecdotes of all the things people have tried, which makes the "answers" very subjective.

Answer 1

Martin Fowler's Analysis Patterns covers some of those topics.

Answer 2

FOR UI / REPORTING: Look into Crystal Reports and Business Objects. Both are used at my place of employment in the Investment Accounting department.

We use other stuff for the internals here (JD Edwards) but I can't really go into much detail other than 'yeah, it does that'

Answer 3

A while ago when I was assigned to work on such a system, I found this link in the Martin Fowler website:

Martin Fowler - Accounting Patterns

It contais some patterns for accounting software, such as accounting entries, transactions and adjustments. The architecture he describes is based on events. Never read it entirely, as the system I work on was already in the middle of its development stage and I couldn't change the design.

Hope it helps.

Answer 4

I can Recommend Patterns of Enterprise Application Architecture and Analysis Patterns, Reusable Object Models both by Martin Fowler they give software architectural patterns to common problems.

Answer 5

For dealing with currencies, remember that you need to always remember not just what currency the amount was entered in, but also what time it was entered, and what the rate of each currency was at that time. Also, accountants are not forgiving when it comes to "inaccuracies" in amounts. If an amount is entered, you have to store it as it was entered, and not convert it first, because afterwards you won't be able to guarantee that you can get back the entered amount just like it was entered.

These may sound like obvious things, but people do sin against them in the real world.

Answer 6

I would have the following structural classes:

1. Account - Represents a financial account. eg. Cash, Sale, Expense;
2. Category - The category where the Account belongs to. eg. Asset, Expenses, Revenues;
3. Mutation - Represents a financial entry of an account.
4. Transaction - Contains a collection of mutations.
5. Money - A composite class using Currency object and storing amount as long integer;

When I approached the design initially I kept thinking about Decorator and Builder Patterns. Tax calculation can use the Strategy Pattern. Observer Pattern can be used to veto Transaction.