You are modeling the state of a business. The business buys and sell things, and has to keep track of how much it owes, how much others owe it, how much business it has done, and how much money it is making and can expect to make.
Whether you are using a computer or doing everything by hand, there are some patterns that you will probably follow. (Well, maybe not. You could pay your workers each day, count inventory periodically and reorder when something was low, and find out how much money you had by asking your bank. But most people follow these patterns.)
You will
record all changes to the state of the business with Business Transactions,
model the state of the business with Business Accounts,
structure transactions with Composite Transactions,
fix mistakes not by backing out your transactions and redoing them, but by Adjusting Transactions, and
catch and resolve errors by Month End Closing.
I believe this is an accurate description of the patterns used in systems based on transactions and accounts. However, I think life can be better. Month End Closing is the real problem, though business people have lived with it so long that they often think it is inevitable. It is a pattern that resolves many forces, so it is hard to change.
To replace Month End Closing with another pattern, you have to figure out another way to resolve the forces. You can eliminate the need to change software only on the end of a month by using Explicit Business Rules. Making the business rules explicit means that it is easy to add them one by one, and does not require major changes in software. You can make them valid only for certain periods of time, so it is easy to add rules that take effect in the future and to test them now by using test transactions with future dates.
You can eliminate the need to fix bad transactions by continuously making the checks that would be performed at Month End Closing, so errors are corrected when they occur instead of piling up at the end of the month. If you represent business rules explicitly, the system can check the rules automatically as well as use them to process transactions.
Another reason for representing your business rules explicitly is that you can keep track of how they change over time, and can process (or undo) a transaction based on rules in effect at the time that the transaction took place, not at the time that the transaction was processed by the computer. This means that you don't have to process transactions in any particular order, but can process them whenever all the data is available.
Month end closing will become simpler and easier. This will also result in designing our systems at a higher level, just the like GUI builders and DBMSs let us design our systems at a higher level.
The big question is "how do you represent the business rules in a transaction processing system?" Business rules of a business transaction processing system fall into several categories:
rules for posting transactions and updating accounts, which can be divided into rules for figuring out what accounts a transaction should be posted to, and functions for calculating the value of an attribute from the transactions posted to its account,
rules for creating new transactions
rules for creating new accounts.
Recall that the attributes of an account are functions of the transactions that have been posted to that account. When an account stores its attributes locally, they are cached results of these functions. For example, "sales year-to-date" on an inventory account is the sum of the "amount" field on all sales transactions posted to the account that year. You could encode this rule in the program that posts a sales transaction to an inventory account, as well as in a program that backs it out (if there is one) and the programs that post other kinds of transactions to the inventory account and so must avoid this field. But the system will be easier to understand if you define the meaning of this attribute only once, in terms of the transactions.
Accounts (see st-www.cs.uiuc.edu 
) is a system I've been building based on these principles.
----
Personally I have never liked month end closing. I think there are better ways to approach the problem(s)
You have to report accounting information, say at year end, and not change the data after the fact.
The data does change after the fact. You might find missing transactions from the previous period and you have to record them. However recording these violates 1.
This can be resolved by being specific about dates. Notice date, when you notice the information is one date. Effective date, the true date of the transaction is another.
Now you can record data in arrears for a previous period. You can extract the original report by using the notice date as a query. You can extract transactions that are adjustments to the previous period by using effective and notice date.
In practice, you would warn on back valued transactions being posted.
Please post comments here, or mailto:johnson@cs.uiuc.edu.
See original on c2.com