That’s good to hear.
I’ve been using the same iPad since 2018 without issue with screen shots on any site. Similar for the Windows laptop. For the ANZ, and several others, we’ve always been able to print, print to pdf or save a copy when logged in without any need to take a screenshot. It’s open to wonder if there is something different with certain banks etc mobile device Apps that cause issues as you have described.
It may have been a permission choice for the particular app, an upgrade to software may have reset the choice to standard choices e.g. to allow screenshots if that is the standard choice.
Some people when setting up apps choose more severe permissions than the standard. As an example, I often stop apps from being able to save screenshots to the photo album because the need is purely to send in a message as a one off. If I need to save it for permanent storage, I have to change the app permissions for that use then reapply the more stringent choice.
2 Likes
I find with PayID there is much more space to record details about the transaction.
The limitation is the reluctance of people to register for PayID, which is superior to the BSB/Account EFT process, as it displays the account name for verification prior to completing the transaction.
And groups and companies can register their ABN for receiving payments by PayID. (I had to explain that to my local CBA branch manager! 
)
7 Likes
Blockquote
Hmm. I’ve heard that before …
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.
Perhaps, so. However, in my bank’s case I have a field with an 18-character limit for my description i.e the description that appears on my statement. Surely, it would not be too difficult to increase this limit to say ~30 characters. Obviously, I don’t need enough space to write an essay next to each transaction, but a bit extra would make a significant difference.
1 Like
Welcome to the Community @physioz
It is trivial to make the entry window larger but that entry window ‘connects’ to a database of some kind that often has character limits in its fields so the entire database need to be rebuilt to accommodate it. That is rarely trivial. What else depends on that field in the database? Usually something that also needs synchronised upgrading.
Rigid database designs are sometimes done in the name of simplicity, sometimes for performance reasons, and other times for reliability/accuracy/recovery. Extensibility for what the developers (or initial management) sees as theoretical for the future is not always included in the specification.
3 Likes
Fair enough Phil - but if the banks are not willing to put in a bit of effort to give customers what they want, perhaps they might get left behind by more nimble operators and/or emerging technologies.
The point being made is that what might appear to be a small trivial IT change is not necessarily so.
In addition, you might find the banks ‘train’ customers to want what they prefer to offer (or not offer). Their customers continue to seem disinclined to vote with their feet.
Well … straight off the bat … if this field is one that is transmitted between banks then “difficult” doesn’t even begin to describe it since the change has to be accepted by a critical mass of banks and with a coordinated implementation plan, interface testing between banks before implementation … in addition to things like an internal testing plan and an internal implementation plan.
A change to the database may require an outage in order to change the schema, which would then form part of the internal implementation plan. Different companies will have different rules about when outages are even allowed.
As @PhilT says, many IT systems will use a multi-tier architecture, and a field length change may affect multiple tiers. (Example tiers: presentation, application, database.)
Worse still, many companies these days will offer the same functionality via more than one interface (e.g. web site v. app) and so a field length change may affect multiple interfaces, and additional coordination is almost certain to be required.
Large companies that need to sustain a zillion queries per second may also be using a Content Distribution Network (CDN), which may add an additional layer to all of this.
If the bank’s codebase is of some vintage it may even have code that would be vulnerable to a buffer overflow exploit / Denial of Service attack if the length of a field is increased in one place but some other place in the code has a buffer that is allocated to the original size. So that then triggers the need for a code security review as part of the internal implementation plan. The last thing you want to do is introduce a serious bug just because someone is trying to use internet banking in lieu of bookkeeping software!
Yes. I happened to have a bill to pay (payment to BSB/account number, not BPAY and not PayID) just now so …
the bank that I was using to pay that bill offers three fields
- Reference (max length 35)
- Message (max length 280)
- Payer’s name (max length 16)
The reference is intended to be an invoice number or an order number but obviously that is in no way enforced.
The user interface does not make clear, for each field, whether the field will be
- stored locally, and/or
- transmitted to the payee (i.e. interbank)
I wouldn’t normally fill in all three fields but for this payment I chose to do so and gave each field a unique value.
After paying the bill, only the Reference and Message were shown in the transaction as displayed to me via the web site. I then tried to download recent transactions to CSV but that defeated me because it didn’t show today’s transactions. So I’ll have to comment further on that later on.
The bank doesn’t care what you do with the 240 characters and you could actually do quite a lot with 240 characters. The problem would be that no human will reliably be able to encode information into 240 characters (nor the bookkeeper decode it). So you would probably want software to handle that … in which case the whole problem goes away.
For security and other reasons, any given field may have a character subset restriction and that may impact on how you might use the 240 character field.
This is specified in Australian payment systems, and is common to all financial institutions. While Appendix C of the latest BECS Procedures appears to have been removed from publication in more recent versions of the document, this version states on page C1.4 (81) that the Lodgement Reference contains 18 characters and is part of the transfer file that is produced. Changing the size of the field means changing it in systems all over Australia, or doing some ‘special case’ mess in one system. Either option would undoubtedly be frowned upon by APRA as involving enormous risk to the banking system for minimal benefit.
Be of good cheer - Australia is in the process of implementing a New Payments Platform (NPP) as of 2018. There is a roadmap showing what has happened so far, and what is intended in the future. Of course, as with anything new adoption takes time, but you will be able to get a lot more information about transactions in the future.
The NPP is open source, and so a lot of entities are building their own implementations. Osko comes from BPAY, and gives you 280 characters to use as you wish.
5 Likes
That will be great, but I won’t hold my breath!
I don’t need anywhere near 240 characters 
but a few more than 18 will be "perfect!
If you are using a bookkeeper I assume that most of your expenses are business related. There will never be enough space on a bank statement to properly identify a transaction which would be the purpose of the payment, eg account dated ## & the correct payee. For all bank transfers I keep a pdf copy of the tax invoice on my computer under the tax year & expense category plus a pdf copy of the payment advice. The pdf file name is the payee name, purpose, amount & date. In addition I use QuickBooks for business accounting which my accountant has access to. When I enter any payment or receipt I can upload a copy of the tax invoice which my accountant can view.
I believe that you will save on your bookkeepers fees if you take on more of the record keeping yourself.
2 Likes
Are you trying to reconcile payments made in your account and would find it easier if you could place a notation on your payment so that they are displayed on your statement?
I could see why adding a note on a (EFT) transaction if a business had a large number of payments of the same amount on the same day, which some business may do if they are ordering regularly from the same supplier for the same items. Our own business we are fortunate that the value of purchases are more or less unique, and along with payment dates are enough to be used for reconciliation purposes.
I could see where there could be some value to have a notation to allow reconciliation of accounts to confirm that payment have been made, when there are a large number of payment of the same amount at the same time (e.g. day).
Alternatively, when making EFT payments banks provide payment receipt references. An option may be to write these references on each of the tax invoices which have been paid which does two things. The first it shows you visually on the tax invoice the payment has been made (or can to provide the payee with this reference) and secondly, if you need to confirm the payment has been made, it should be able to be searched using this reference number.
Just to update this … all three free-text fields that I filled in when I made a payment yesterday are present in the CSV file that I downloaded today.
So, as far as meeting @pekay’s requirement, that seems fairly solid.
I can have the discipline to fill in those fields always. Then every whatever accounting period I can download the CSV file and send it to my bookkeeper.
The outstanding questions would seem to be:
- which fields are transmitted to the payee? - since you should at least think about confidentiality (just because you are sharing the info with your bookkeeper doesn’t necessarily mean you want to share with the payee) - however it seems unlikely this will be a major issue
- are there any unpleasant character subset restrictions? (I am near certain that there are restrictions but I don’t have the details) - again this doesn’t seem as if this would be a major issue
- what about other payment options? - I’m testing payment to BSB/account number and that worked well. Does PayID work differently? BPAY appears to work differently. Is that going to be a problem?
That is all very nice. But does it solve the original poster’s issue?
How to communicate the purpose of a payment to a bookkeeper tracking money inflows and outflows and properly assign to the correct accounts. Very important in double entry bookkeeping where everything must balance.
How do you put comments into these fields when there is no option to do so? Eftpos for instance.
How do you describe split transactions that involve multiple expense accounts? If you worked out a consistent scheme for that you probably wouldn’t need a bookkeeper at all. You could do it yourself and save one expense.
How do you deal with direct debit payments? Whatever may show up in the description on a bank statement is not set by you.
How do you deal with CSV files? The only structure to them is that the various fields are separated by a comma. Or possibly something else. One has to know what each field is, and every organization will be different.
1 Like
MYOB, Quickbooks, Quicken, etc or something simpler. I’ve used MYOB and Quicken, and something else (a spreadsheet).
For consumers running a business, or self employed, or with complex tax matters, there are multiple solutions. Having spent some time self employed and running a business or two an observation is not all accountants/accounting firms are created equal. Consider their return/profit is proportional to how much time and effort they need to put in. Lazy tax excepted, IE going to the same business regardless of the cost each year. The more you can do yourself the less it should cost. The more you can do and hold close, the easier it is to go to someone else.
For everyone else, some further advice?
1 Like
I thoroughly agree and wish more people even knew of the existence of PayID, It’s so much easier to give someone an email address as your payee details rather than BSB/Account and as you say when making a payment to someone via PayID you get immediate confirmation of the recipient rather than hoping the BSB/Account is correct. Possibly a good one for Choice to publicise as the banks don’t seem too good at it and it is definitely in the consumer’s interest…
1 Like
We, the people, can do something.
The banking system is ready. They are all set up for the NPP.
My new tax year resolution is to NOT pay any company, or anyone, using Pay Anyone. If they want to be paid via an invoice or bill, then send me the Bpay, or PayID detail.
No more bsb/account stuff.
2 Likes
umm - PayID in theory sounds more reliable.
… BUT, it has been hacked - twice in 2019 alone…
and, PayID’s are FAULTY in Concept because they are NOT linked to your TFN _ Tax File Number … and, only sometimes to an ABN -Business Number.
therefore, what is the point IF 'the Cash Economy" is not eliminated ??
hi Pekay,
it is YOUR RESPONSIBILTY to keep Invoices for EACH and EVERY Business transaction payment.
… Under Tax-Law, you are required to keep a copy of each and every Invoice that you pay.
Pekay, you state that you receive an ‘electronic copy of the Invoice’ that you pay.
… are you saving this as a ‘pdf-file"? - it makes keeping your "accounts’ easier.
it sounds like - you should CHANGE Bookkeepers.
. the bookkeeper should be - (1) MATCHING your Payments to an " Invoice that has been paid" - this can only be done IF the Invoice is sighted by the Bookkeeper.
- (2) after sighting the Invoice, the Bookkeeper MUST ALLOCATE it to the CORRECT “Cost Category” - this can ONLY be done IF the Invoice has been sighted…
… it is YOUR RESPONSIBITY to ensure that this happens.
Downloading of Bank transactions over the last 20 years has made the “matching” process a lot faster and easier.
it is NOT the Bank’s role to provide ‘a Bookkeeping service’ - that is your responsibility/ bookkeeper’s / Accountant’s job - the Bank provides a “Payment system” with a limited field data-text identification.
and, PRIVACY these days is a REAL Issue which should NOT be compromised by giving too much data to the Banks.
For clarity what is today’s norm is not necessarily tomorrow’s, nor the way it should be. As society, technology, and importantly laws evolve there is no reason that suggestions for improvement are ever out of place.
Whether any one individual supports those suggestions is another issue.
It is also the case individuals and businesses have differing needs - eg most ‘average individuals’ should not need book keepers to keep track of their wages, donations, interst and dividend income and the few tax related expenses they incur. The ATO already has most of it and prefills the lodgement requiring only an accuracy check - usually noticing something still missing.
Whether banks should then cater for the more complex needs of businesses, that would also cater for individuals having complex needs, would add complexity and thus cost to the payments system - that would shift costs onto banks that would then ‘adjust’ their own fees. Yet the cashless economy is rife with surcharges just for paying and it appears society is accepting of that. How would ‘another step’ go?
As was pointed out previously any change would be non-trivial to implement as well as transition to so whether and how it could come to be would be left for government and countless technical committees to agree.
A parallel question might be whether it should be our responsibility to file taxes, or since the ATO has our information already should they just send us an annual bill?
My point here is not to go further OT but to indicate the OP understands whose responsibility ‘accounting’ is and observed ‘the cheque stub is an artefact of bygone days, why not provide the facility in the banking system?’
2 Likes
