Save content
Have you found this content useful? Use the button above to save it to your profile.
AIA

Are we ready for electronic cashbooks?

by
30th Sep 2010
Save content
Have you found this content useful? Use the button above to save it to your profile.

A recent exchange in AccountingWEB.co.uk’s Cloud computing discussion group triggered an exploration of something that has been lurking just beyond accountancy’s horizon in recent years – the potential for companies to base their books on automated bank statement feeds.

For years, AccountingWEB.co.uk consultant editor David Carter has argued that the electronic cashbook is logical, labour-saving approach that make life easier for small companies and their advisers.

The latest episode in the bank statement bookkeeping debate started when KashFlow said it was working on a module to speed up bulk data entry for its online bookkeeping application.

This approach brought a retort from rival Xero’s UK managing director Gary Turner: “Our instinctive expectations are informed by a software design workflow that involves paper, documents and manual entry.”

Instead of manually keying hundreds of transactions into an application, Turner argued that bulk imports of electronic bank statement could eradicate a raft of pointless, paper-bound accounting processes.

“Many small businesses rack up large numbers of direct debit, cash and credit card expenses in a month where the paperwork appears long after the funds have left the bank account. This throws accurate visibility of cashflow a real curveball, so actually driving the business off the bank statement is probably more sensible for smaller businesses too,” Turner said.

Xero now supports a large number of users in Australia, New Zealand and the UK who run their businesses off bank feed data capture, he said. They automatically suck in daily bank transaction data and then backfill the coded transactions (automatically in some cases for repeat transactions) directly into their source ledgers.

“Backfilling ledger transactions from the bank statement doesn't mean the transactions are filed with the banking transaction date; the statement data is merely a method of capturing and loading large amounts of provisional (not committed) data into the system without manual keying,” he explained. “The accounting process of reconciling each transaction will determine which date is chosen to record an invoice payment, receipt or other accounting transaction against.”

As a side benefit to eliminating manual data entry, Turner argued that tightly connecting actual cash transaction data to the accounting system “provides small businesses with better monthly management accounts”. Management accounts based only upon invoiced transactions reflects the financial situation that might exist, while basing accounts on cash that’s held in the bank will be much closer to reality.

For Twinfield, UK country manager Mark Davies joined in the discussion by adding that even without relying purely on bank transaction data, it is now possible to eliminate paper documentation from the accounting process. His Dutch counterparts already work with accounting practices that automate more than 80% of their invoice processing by using scanning and OCR.  The system then prepares invoices for approval and payment automatically using the same  business rules that would previously have applied to paper invoices raised manually. Twinfield is working on bringing the same facilities to its UK customers.

“One day we will see most systems exchanging XML-type records and paper based documents will become ancient history.  That may be a way off yet, but the ability to automate is already proven,” Davies said.

Paul Scholes posted a sceptic’s view of the electronic cashbook approach. “My first practical problem is that it makes people lazy,” he wrote. “They are not forced to match payment with paperwork.”  Losing this control causes problems such as bills being paid twice and confusion with a series of identical payments whether “the April payment was for the March bill (which was missing) or the April one”.

From the management accounts perspective, Scholes could see problens with period end creditors and accruals. “Without a log of the expense/supplier invoices received, and with even a small number of supplier accounts, it is more difficult under a cash-based system to identify unpaid amounts and their nominal allocation,” he pointed out.

“The lack of documentation - electronic or paper - to back up online purchases is, in most instances, down to laziness ie the purchaser not pestering the supplier for an invoice as soon as the goods or services are paid for.  I've seen clients throw away hundreds of pounds of VAT claims because they think the order can be used as an invoice.”

However, Scholes acknowledged it was “daft” for a human to key in data one end to generate an invoice for dispatch only to have the same data re-keyed at the other end by another human.  His suggestion was closer to the Twinfield model, but would depend on developing a national or international bar coding standard so that all the standard data fields a purchaser would need - name, date, invoice number, product description, amounts – could be captured. Then only the internal stock and nominal codes would need to be allocated by the receiver.

Having put the counter-argument, he then admitted to a private suspicion that he was not seeing the wood for the trees. Perhaps “I too have suffered indoctrination,” he said.

Where do you stand and what evidence do you have to support the suggestions put forward by Xero and Twinfield? Join the electronic cashbook debate by posting your comments below.

Tags:

Replies (7)

Please login or register to join the discussion.

By RogerNeale
30th Sep 2010 12:24

Pegasus Opera

A good number of years ago, I care not to remember how many, Pegasus Opera had a really good electronic cashbook that was really easy to use.  The problem was that people were reluctant to take it up and many banks didn't support it.  As a consequence, when Pegasus released Opera II, the electronic cashbook was dropped.

With the movement forward in the use of xml and other automated technology I can see that it might not be long before there is an interest in the "new" option.

It certainly made life easier when it came to doing the bank reconcilliation but, as with manual reconcilliations, it couldn't automatically cope with the odd occassion when someone took cheque/cash receipts to the bank on two seperate days but only posted them onto the software with one date, or vice-versa.  I can only assume that, with the wide use of BACS/electronic transfer, this problem will reduce to the point that it won't really be a problem.

If other people start doing it, I hope Pegasus will bring back the electronic cashbook and make more training work for us to charge for but lessen the chance of human error.

Thanks (0)
avatar
By redsq01
30th Sep 2010 12:44

Electronic Cashbooks

Works perfectly well in Australia and New Zealand so why wouldn't it work here !!

Thanks (0)
avatar
By JOHNMCDERMOTT
30th Sep 2010 14:00

Electronic cash Book

I believe that the electronic cashbook would be a good idea, subject to applying the same rigourous controls to the system that pertain in the manual system; i.e reconciliation.

Banks have been known to make errors, and when they do, they can be collossal.

 

Thanks (0)
avatar
By chatman
30th Sep 2010 17:13

Get the description right

I think it is important to describe it as what it really is, as we already have electronic cash books. What this article talks about is using the bank statement as a prime entry source, which is a completely different thing. Calling it an electronic cash book makes it sound far more innocuous than it really is, and gives no idea of the risks it brings.

Having said that, I would love to be able to import my bank statements, either into a bank rec function or directly into a suspense account, for subsequent analysis.

Thanks (0)
avatar
By philipdc
01st Oct 2010 12:13

Its not about whether it works or not

The big questisn is do the users WANT it?

In the TurboCASH Accounting project, We have these facilities available for sometime now, the users seem reluctant to take it up. I think what happens is that inside the industry we see this as a great new innovation - but it can simply be  tehnology for technology's sake.  Unbeleivably the users seem happy to plod on they way they are.

 

Kinda of like paying software licences. While free and open source accounting software exists, an industry has been built around selling software. What else would most integrators do if they did not sell software licences. Similarly what else would bookkeers do if they did not capture transactions. Ridiculous isn't it?

 

-- "No one possesses the less because everyone possesses the whole of it. He who receives an idea from me receives it without lessening me, as he who lights his candle at mine receives light without darkening me" - Thomas Jefferson

Thanks (0)
avatar
By mikewhit
03rd Oct 2010 08:44

How does this differ

from importing the OFX file from your online banking - OK, it's not a 'continuous feed'

Thanks (0)
avatar
By redsq01
03rd Oct 2010 14:02

Users don't want it because they just don't care !!

This type of solution does not solve a problem for the client it solves a problem for the provider of the service to the client as the client does not have the necessary motivation or knowledge to make an informed decision about the issue. For most clients bookkeeping/accounting is a right royal pain in the neck with which they would prefer minimum engagement.

By using this technology with re-organised business processes a bookkeeper/accountant can provide a better service (due to more accurate and timely information) at better price to the client at much higher margins for the provider.

The losers - drudgery !!

If you want to know ask me !! 

 

Thanks (0)