There appears to be two schools of thought or philosophies around how accounting systems should be setup and run in practice.   These two schools are organized around these different approaches:

• Batch-based entry
• Real-time entry

Batch-based Entry and Review

In my career as an Accountant and Systems Implementer, most complex and older accounting systems have been organized with independent subledgers and a general ledger.  The subledgers, typically invoices & receivables and vouchers & payables, are independent entities that can be summarized and eventually posted to the general ledger.  These types of systems generally have a mechanism to batch data entry work so that it can be reviewed before it is committed through a posting process to its subledger.

With these types of systems, you can organize a “command & control” accounting department.  In this configuration, the Controller can review their staff’s entry work before it is posted as final to the ledger.    The accounting systems generally have software-based review programs that can check a batch for errors prior to it being posted.  This gives staff a chance to fix the batch before it is posted.   The idea is that once something is posted, there is no mechanism to make changes.   Hence “posting” means no turning back.  Any change to a transaction requires a modifying entry that typically will reverse the original entry and then post the desired entry.  Another technique is to create delta or modifying entries; the most common being credit or demo memorandums to the entry in question.

In my assessment, this style of processing is setup to handle accounting concerns from this perspective:

1. Accuracy is of utmost importance.
2. Work should be mechanized and controls must be in place to ensure accuracy.
3. Once we commit, we can’t go back.  The record can never be changed.
4. Serving accountability requirements, audit of what is going on is extremely important.

From a historical perspective, the original computerized accounting systems where likely designed this way for two reasons:

1. Before computers, processing large volumes of accounting data was very cumbersome.  Practices had to be developed to make the process more efficient.  Batching like-kind work offered the possibility to build control checks prior to ledger posting to ensure accuracy.   Staff could operate like efficient machines performing like-kind repetitive entry tasks.  Of course, if we had to recalculate, it was expensive and to be avoided.
2. Early computer database structures, if they could be called that, were file systems and lacked relational integrity.  Nothing but your own program ensured that data in one file related perfectly to data in another file.  File-based systems lacked good multi-user access and concurrency issues had to be handled.  This wasn’t much of a problem at the time however.   File-based systems mimicked the real-world paper-based file and ledger organizing concepts and as such, it was logical to build applications that worked similar to the existing practices and tradition of that era.  File based systems allowed for a batch of work to be created by a single operator without concerns for concurrency.  Information in these batches could be summarized into information to be placed in other files.  Finally those files could be summarized to the general ledger (which of course, lives in its own file).

Real-time Entry and Review

In contrast, a real-time entry system is considered loose to its batch-based alternative.  In this type of system, every transaction is affecting the entire system as information is posted.  The need to post information to the general ledger when working in a subledger goes away.  Hence, the general ledger is always “up to date”.    For example, when creating a customer invoice, the income statement will immediately show the revenue credit, the balance sheet will immediately show the accounts receivable debit.   This also means all other information is updated as well.  Using the same example, a customer’s total balance due is up to date — everything is current.  In theory, there should never be a case where the accounts receivable aging does not tie out to its respective general ledger account (naturally, there may be issues where manual journal entries throw things off).

Posting in this environment means to commit the transaction and affect everything.   Depending on the system, there may be ways to save transactional entries as “drafts” prior to posting.  Some systems will offer a mechanism to allow you to see the impact to general ledger and other information prior to posting.  Still others offer no pre-commitment preview facilities.

In this environment, when you want to make a change to a transaction also depends on the way the system has been designed.  Some systems force you to create reversing entries.  Other systems allow you to modify the original transaction directly;  just fix or change the transaction and the peripheral information will change along with it — the mistake transaction may disappear altogether.     Some though will track that it changed but not do it through traditional debit and credit mechanisms.

In my assessment, this style of processing is setup to handle accounting concerns from this perspective:

1. Information can be entered haphazardly; meaning, you don’t need to organize it before it is entered.
2. Timely and rapid data entry.
3. Minimized processing complexity.

Until the advent of modern computerized database systems that support strong relational integrity and multi-user concurrency requirements, it was nearly impossible to work in this fashion.  While it may now be technically possible to process information real-time (and only if the accounting system was designed to do so), it may not mean that you want to.

In a subsequent article, I will discuss the strengths and weaknesses of each approach including what types of mechanisms you may want to have in place to produce reliable information.

Get Help to Select an Accounting System

If you are looking for help selecting an accounting system, contact us.

Marty Zigman

Holding all three official certifications, Marty is regarded as the top NetSuite expert and leads a team of senior professionals at Prolecto Resources, Inc. He is a former Deloitte & Touche CPA and has held CTO roles. For over 30 years, Marty has produced leadership in ERP, CRM and eCommerce business systems. Contact Marty to set up a conversation.

More Posts - Website - Twitter - Facebook - LinkedIn - YouTube