Accounting Errors, The Trial Balance, And System Design

Bookkeeping using hardback books is simple, but also very error-prone. Errors can range from misdescribing a transaction to incorrectly calculated numbers.

No one would argue that accoutning is one of those industries where it felt natural for computers to completely revolutionize the process.

The trial balance

Using a physical book for accounting involved you manually totaling your DEBITS and CREDITS to confirm that the double-entry system still held true.

Today, wtih computerized accounting, this tally happens automatically as journal entries are made. The system countinously checks that, at any given point, the total DEBITS equal the totasl CREDITS.

This alone eliminates an entire class of errors that affect the trial balance.

Errors that don't affect the trial balance

So here is the question:

Is it possible to eliminate, or at least reduce errors that don't affect the trial balance using system design, just like double-entry validation catches debit/credit imbalances?

Who is to say the bookkeper didn't intend to credit the expense account?Maybe there was a rebate. Maybe it really was an adjustment. From the system's point of view, we can't know for sure.

Given this context-heavy nature, the best we can do is learn what looks normal and prompt the user when a transaction falls outside that norm.

For example crediting an expense account is unsual. A second confirmation, approval, or warning prompt can help ensure the user actually meant to record the transaction that way.

Let's now look at some errors that don't affect the trial balance and the patterns we could track to flag them.

Error of duplication

Duplicate entries are far more likely to be accidental than intentional.In most cases, there is no reason to repeat a transaction when it could have been recorded once.

A simple check would be to search for transaction from , say, the last 2-7 days that closely match the newly entered one. The description could be exculded from the compraison, since the original entry may have been described differently.

If matching transactions are found, the system raises a warning and leaves the final decision to the user.

Error of reversal

Did we debit cash and crddit expenses?

A flag can be raised whenever the usual direction of transactions between two accounts is reversed compared to historical patterns.

Errors of principle, commision, and original entry

This is where things get harder.

How do we know the bookkeeper meant to debit motor expenses and not motor vehicles, since both normally have a debit balance?
How do we know Esi was meant to be credited instead of John?
And the system certainly can't pre-empt a completely missing transaction.

The first two are heavily context-depedent. The last one can, at best, rely on invoices, payables , and receivables to predict what should exist.

For now, I will leave these three alone.

A catch-all pattern

Instead of relying only on specialized pattern checks, what if we adopted a more general approach?

We could generate a checksum hash based on all journal entry parameters, excluding the amount and possible the date, to see whether the hash matches any existing transactions.

A combination of date and description could still be used specifically for doublication checks.

Conclusion

How paintful errors really are depends on the nature and structure of the business. Major errors are usually detected and corrected, while minor ones may go unnoticed but also don't materially affect the accounts.

That suggests the marginal benefit of heavy validation. This makes implementation choices expecially important.

Also, running these vlidations later, once enough data exists for patterns to emerge, may be more effective. At that point , truly exceptional entries stand out more clearly.

This kind of analysis could run as part of an audit before preparing financial statements. Warnings are generated, reviewed, and either followed up on or confirmed as acceptable patterns.

Thats all from my thoughts diary.

EDDYMENS