Month End Closing

There seem to be a lot more ways to make errors in a computerized accounting system than in a manual one. There are bugs in programs, people often enter data when they really don't know what they are doing, and there is often so much data to enter that it is hard to check it for accuracy. This implies that it is more important to be able to back out or correct computerized transactions than paper ones.

Another problem with computerized systems is that the rules for processing transactions are often built into programs. This makes it hard to change the rules, because you might have to process transactions under both the old and new rules. Even when the rules for processing transactions are stored in a database, the rules might not be time-dependent. For example, an employee's salary might be a number rather than a function from time to numbers, so if you process an old transaction you'll always use the current salary.

Accounting systems are often built out of several separately developed modules, but data has to flow from one to the other. This is usually done by having one produce transactions that feed into the other.

Finally, transactions accumulate quickly and take up a lot of space. Periodically they must be purged.

Therefore, finalize all transactions at a month end closing. If accounts are out of balance then the transactions can be adjusted to fix the problems. Once month end closing is over, transactions cannot be changed, but they can be changed beforehand. All transactions within a month use the same rules, but a new month can bring new versions of programs. Month end closing will cause each subsystem to create the transactions that flow into the next subsystem. Finally, month end closing is a good time to purge old transactions, because that is the time that the accounts information for a particular month becomes immutable.

Note that the pattern is the same whether you are closing monthly, weekly, quarterly, or yearly. Many businesses have both a MonthEndClosing and a year-end closing.

I first learned about MonthEndClosing when I worked on the RATEX system at the Cornell Campus Bookstore. Every night the computer would down-load sales transactions from the cash registers, and would use this information to update the sales system, the inventory system, the accounts receivable system, and the textbook and tradebook systems. The sales system kept detailed day-by-day accounts, but the rest of the systems just kept data on a month-by-month basis. MonthEndClosing would make the current month's data be the previous month's data and would clear out the current month's data. All of these subsystems would have their data posted to the general ledger, which only kept data on a month-by-month basis.

MonthEndClosing was the only time when data from all the different subsystems was compared. If the total sales in the inventory system didn't match up with the total sales in the sales system then something was wrong.

The business manager was tearing his hair out at the end of every month, because it often took several days to get finished with MonthEndClosing, and the accounting system wouldn't work to its full capacity until it was over. The main problem was that errors would accumulate until the end of the month, and they were not visible until MonthEndClosing would occur and the system would try to balance the accounts. I spent a lot of time trying to eliminate errors in the system so that MonthEndClosing would run more smoothly.

Some companies make MonthEndClosing run smoother, but I think that most do not. It often takes several days to carry out, because a lot of problems with the data only become apparent at month end closing. In the simplest form, BusinessTransactions cannot be processed until MonthEndClosing has finished, so there is a lot of pressure to finish it. More sophisticated accounting systems (most of them) will let you start work on the next month while you try to finish up the last. This relieves the pressure on the people closing the month, unless it takes more than a month to finish! However, it makes it easy to draw out MonthEndClosing, making it even harder to get timely data.

-- RalphJohnson

Transactions take up a lot of space (therefore) they must be purged.

Why? Surely StorageIsCheap enough these days? Or is performance degradation due to file size the issue? Can't the file be indexed to alleviate that?

Not the original author, but PatrickLogan responds... Transactions can take up too much space in a SourceSystem not designed to hold a lot of history. The typical response is to archive them as needed for legal purposes and transform them into a StarSchema for analysis in a DataWarehouse.

And why exactly must month ends be closed? Certainly once a year end has been finished, you'll want to close it to prevent transactions from still being posted to it but I'm just not as fussy about month ends. Also, a closed year end should also be able to be re-opened because if somebody discovers a material accounting error, or an accounting policy is changed, then retroactive adjustments may be made. -- MarkTilley

Monthly or weekly closings can be important because a closing is the only time that all data from all systems get reconciled, so it is the only time that anyone "trusts" the reports, and the only time that inconsistencies will be noticed. -- KrisJohnson

Ensuring that the A/R, A/P subledgers always reconcile to the G/L should be a non-issue. A properly designed system will never let them get out of balance. Maybe I'm too focused on my own area as an accountant, but what else needs reconciling? If people don't "trust" reports, maybe there are other issues to be addressed in IS and Accounting. (Not trusting a report is not trusting it's designer/preparer.) -- mt