We are being progressively moved towards digital banking. Cheques are almost gone, but at least you could include payment details on the cheque stubs. If there was an enquiry about the nature of a payment the details were easily findable. Today, with digital payments a few of the banks provide fields for useful information. However, some of this is not retained by the bank and when a bookkeeper starts asking about the nature of the transaction, the digital information is grossly lacking. Every few months I receive from our bookkeeper, a printout of digital transactions, requesting what the transactions were for so they can be posted to the appropriate accounts.
I spoke to a casual friend who worked for years for one of the âbig fourâ. All that needs to be done is for the banks to provide a field in which this information can be entered and later retrieved. His response was: âWhy should the bank manage your bookkeeping issues. Keep the information somewhere else.â
Having also raised the issue with the Manager of our local branch of a smaller bank, she told me that this was a commonly raised issue by customers but no one further up the line seemed interested in addressing the problem.
Memory storage is cheap today. The banks already have 95% of the problem sorted because they already hold the information on all transactions. The programming to add and store an extra field is negligible.
Obviously, the banks have minimal interest in providing âcustomer serviceâ these days.
Receipts show the transaction details. You do keep receipts to show to your bookkeeper so they can assign into the correct accounts do you not?
As for fields provided by banks, no way of doing that for terminal transactions. Yes for money transfers, but the banks are wary of passing on some of those to be placed on statements. Hereâs your payment for the month you *@$&.
A credit/debit card receipt contains limited information and canât be used for bookkeeping/tax purposes. Such receipts are issued by the merchantâs payment system to show payment has been made, when it was paid and itâs amount (e.g. it is a printout from a EFTPOS console). It may also contain basic information about who the payment was to.
Tax invoices have specific information that needs to be presented and are those used for bookkeeping/tax purposes. They are issued by the merchant.
To keep bookkeepers/accountants happy, they need tax invoices.
It is worth noting some businesses also issue tax invoices which also contain credit/debit card receipt as one document.
For banks to retain all transaction information, including that which would be presented on a tax invoice would have major privacy concerns. While it might make bookkeeping easier, the ramifications could be enormous⊠as the banks would have specific details of our lives and it is likely the ATO, government agencies, insurers etc would be interested in such information.
I purchased a pocket sized PDA in 2002. A Toshiba product. It was subsequently replaced with a Dell version some years later. I set up a simple spreadsheet and used it to produce a listing of every personal business transaction complete with a reference for purpose, recorded as they happened. The accountant was happy to accept the summary, and the paper receipts went to a pocket folder loose by quarter just in case.
It removed the need for the accountant to ask or guess the purpose of a receipt as related to tax law. It also simplified the quarterly BAS statement by allowing the data to be read directly by a PC and sorted/totalled accordingly. These days a Smartphone can do the same including any number of Apps or extensions of accounting packages.
Does one really need an accountant?
Some would suggest the banks already know too much!
The CBA was providing a limited categorisation in the on-line transaction list. You could designate the transaction as Insurance, Bills, Wages, etc. There was facility to enlarge or change the designations. This generated a graph, pie chart, figures to see how you were going.
I tried it, I remember it was withdrawn for a short period and I think it is still going. Easy to use; it automatically assigns the payee to the account, so it works for Suncorp (Insurance) but not Council (Rates, Dog rego, Mulch, festival) which have to be manually re-assigned. Doesnât help you if you bought tyres from Tyres R Us, but debited by Aardvark P/L.
My system - get an invoice or docket from all transactions (or jot it in a notebook eg cash at market stalls). Mark it with the purpose (account eg Dozer, Welding) and input that into my bookkeeping. I use GNU Cash - it is open source - free (although I give them a donation) - as easy or as complicated as you need. Regularly reconcile your bank statements, print and write clarifications eg Aardvark = âTyres R Usâ. I also file according to account - pull the Dozer file and have all dockets, invoices etc. I pull a report for my tax accountant from GNU Cash, and thatâs sufficient for her.
Unless youâve done software engineering for a large organisation then you may not appreciate the full amount of effort that goes into what seems like even a trivial change.
There are actually two parts to what you are raising viz. payments and receipts.
If you are only interested in payments then the task is slightly easier - because it involves only one bank (yours).
Supposing that the bank does not provide the requested functionality, people I know use differing strategies:
Just keep a piece of paper onto which you write the date, amount and payment description. Any queries from your bookkeeper can be answered using said piece of paper. OR
Maintain a spreadsheet with those same details. An advantage with this approach is that you can then also balance your account (i.e. confirm that nothing has been omitted - the balance from the spreadsheet matches the balance gleaned from the bank). OR
Wait until the printed bank statement arrives and then write on the statement whatever annotations you need in order to answer queries from your bookkeeper. (This assumes that you can at least remember the details between the date of the transaction and the date of the statement.) OR
Periodically download transactions in a computer readable format, then edit in the annotations on the computer. (For example, the internet banking for one of my banks allows me to download transactions as CSV or in a format suitable for import into a range of bookkeeping software. CSV is obviously the simplest here and then this really becomes the same as the second option except that the information is downloaded, not typed in.) As with the previous strategy, you need to remember the details for a period of time, but here you get to determine what that period of time is.
It is true that disk storage is cheap today but then how many billions of transactions do Australians do each year. The cost could add up which therefore leads to the obvious question: how many dollars per month (presumed to be modest) would you be willing to devote to having this functionality? If you put a value of $0 on it then that would not help to convince a bank that it is worth doing.
Obviously none of this works directly if the transaction is not done via a bank transfer. Cash is king.
Well indeed but I suppose the assumption is that if you choose to use this functionality, you accept that the additional transaction details will be available to all and sundry (for marketing purposes, for law enforcement purposes, for research purposes, for policy purposes, âŠ).
OR just get into the discipline of getting a receipt for EVERY payment. And keeping that receipt. If it is a receipt that details the purchase, good. If it is simply a transaction copy that doesnât detail the purchase, then get a pen and write down the detail on the receipt. IE, lunch at cafe. Or chemist. Or meat at butcher.
Then put the receipt into an out tray. You can keep some order in receipts by clipping all for each week together with a bulldog clip.
I do that even though I use a home accounting system to track, categorise, and reconcile all transactions. No matter whether it is card payment, bill payment using Bpay or transfer, or just cash.
Having a banking system provide a description field for transactions is utterly useless if there is no practical way to enter the text at transaction time. Tap and go? No. Eftpos terminal? No. Bpay? No.
The disk storage is easy part. What will be expensive will be the integration and sending of data from a businessâ point of sale system to the bank, so that the bank can attach such data to the payment.
Currently both systems arenât linked and would require sharing of data from 100s of different formats to formats that can be read and stored by the financial institution.
It would also require a change to the way the payment transaction is processed and what data is collected and transmitted.
While it sounds easy, it would be a monster exercise and costs would be passed onto every consumer.
Keeping tax invoices (even photographing them and storing on a phone) for each purchase would be far simpler and more robust.
The above responses I believe to have mossed the point. I am referring to payments of accounts where the Tax Invoice is sent electronically and the payment is made as. bank transfer. At the time of doing the bank transfer you are required to fill out several fields, e.g., Payees name, BSB, account number, amount of payment and there is usually a field for payment details such as an invoice number or what the payment is for. Hence the data is already being picked up by the banks. All they need to do is insert one extra field, which a few banks already do, in which you can explain what the payment is for, and then keep that field for subsequent access. Where it already exists it is passed to the payee and then deleted from the banks memory bank.
I am not asking that new databases need to be designed. It requires that one extra field be added and kept.
Perish the thought that banks provided a service of convenience for their customers from which they generate billions of dollars a year in fees.
Actually I think thereâs some lack of transparency from the banks as to exactly what does happen with the data.
When I pay someone, the internet banking web site solicits (I think) 3 fields - but really I donât know whether those fields are going to be kept at my end (payer) and/or sent to the payee. The fields have different length restrictions. The fields may or may not have different character subset restrictions.
At least one of those fields is quite long, so provided that it is kept at my end and provided that I donât care whether it is seen by the payee (i.e. not confidential) ⊠that should be good enough to contain whatever annotation you want.
I donât understand. If you are paying an account using money transfer, pay anyone, you already have the details of what you are paying for.
Do you not keep a record of what you are paying for?
There are two optional fields you can put entries into. First is a reference field of around 32 chars, and second a description field of around 240 chars.But that is sent to the money receiver to help them understand what the money received was for.
You already know what the money payment was for. Unless of course you throw away accounts and bills as soon as they are paid and then have forgotten what the payment was for later down the track.
You do. But your bookkeeper doesnât when looking through your bank statements - unless the information is recorded and then printed on the bank statement.
That â240 charâ field looks adequate for just about anything - but is it stored by your bank? is it printed on the statement? is it shown online when transactions are listed?
Not sure if this is related (I think it is) but apologies if it is a tangent. To me, the biggest problem is not which information is collected in the three fields, but what the bank chooses from that information to show on statements.
I changed banks about two years ago and am very happyâŠexcept for the fact that the new bank wastes nearly all the description space on statements and online with details about the method of payment (Bpay, Transfer etc) including the account numbers that were transferred to or from. For the customer, all that information is apparent by the account you are viewing. What the customer needs in that description space is WHO the payment was made to and the reason, which they entered when they made the payment. Once the space is filled with unnecessary technical detail, you may be left with half a word to try to use to identify the transaction.
In essence, they use the wrong information field when describing the transaction, so it is no wonder that an accountant cannot decipher the details.
There are a variety of simple systems that can be used to store the types of information previously included on cheque butts. Finding one that suit you will be better for your blood pressure compared to demanding that a bank does something to solve your problem for you.
A very easy method is to record the details that would have been included on a cheque butt, and more if it suits, in a spreadsheet that can be forwarded to your bookkeeper.
From my experience, providing a bookkeeper with minimal information is inviting errors. Assumptions, which wonât always be correct, are made when full details arenât provided. If you are registered for GST, the bookkeeper should ideally have access to the associated tax invoices to ensure that amounts are correctly classified.
Any bookkeeper doing the job properly will need to do that. Especially with double entry bookkeeping.
An example. You may buy a basket of goods from, say, JbHiFi. It is paid for in a single payment. Some DVDs, not tax deductible. A laptop, maybe tax deductible, depending on usage. But would need to be claimed using depreciation over a few years. And probably classed as an asset. A cable, and some USB sticks. Again, maybe tax deductible, but no depreciation if each item is under, say $300.
How is oneâs bank going to keep that information in a 240 character description field? Should one expect that a bank should keep attachments of documents on every payment a customer makes, just because that customer doesnât keep receipts?
Iâve also found that when using my tablet or mobile phone to pay a bill the ability to take a screen shot of the result is prohibited. I try to pay mostly using my laptop where I can make use of the screenshot facility but where some banks allow an e-mailed result others donât have that option and neither do they allow a screenshot. Stymied whichever way you try.
Itâs a slight tangent to the current topic.
Not being able to take a screen shot or save a copy of an online transaction would be frustrating. Are you able to offer further advice on which bank/s, the device in use and whether it is the banks App or web page login that is not delivering for you? There may be others in the community that know why it is so for your bank and how to get around the problem.
Iâve not come across it with our Bank or Credit Union. Taking a screen shot on the tablet has always worked. When logged into banking there is also always an option to print or save a copy of the transaction/receipt. One can also look up when logged in previous transactions, the details entered and print or save a copy. Some devices/OS offer a âPrint to PDFâ option. When paying bills using the service providers site the options typically include an email option for a receipt. Iâve not come across a site that blocks screen shots. I typically take one to be sure I have a record, just in case!
Ok - it was mostly Westpac and Ubank as they are the two banks I regularly used. However - Iâve given feedback to both over the past few months and just now when I tried I could screenshot on both bank sites. I use a Samsung Galaxy Tab S6 or my Samsung Galaxy A32 mobile both of which have had major upgrades in the past couple of weeks so I donât know whether it was due to my feedback or the upgrades but screenshots are now successful. Iâd given up trying and was just using my laptop so was unaware of changes.
