I am an auditor, so on my part, I am not so “happy” to see only the reports. Of course, it would be possible to check the data through these reports, however having concecutive journal entries (including all debits/credits of all accounting facts) is one of the main points of focus in Internal Audit.
Our auditors require the general ledger transactions report and the bank statements rather than a journal entries report with bank statements.
1 Like
I would suggest enabling Bank and Cash accounts in Payment and Receipt which will solve the current issue for ever. it could result in removing Transfer Between Accounts Tab but it will give more options for the user.
1 Like
This is an acceptable way to audit an organisation but not a complete one. If an auditor wants to also audit the supporting documentation (easily), this would be feasible through comparing journal entries (meaning, per date accounting records) with general ledger.
Sure, the auditors also want asset reports, etc. But for track and tracing they use the GL transactions and statements. The evidence if uploaded in Manager can be accessed by clinking on the credit/debit amounts in the GL Transactions report which will give a view of such transaction and if you attached, receipts, etc they can open these too.
For organisations which request full internal audit, tracking GL transactions is a huge work.
On my part, as auditor, as the rest auditors of IIA do, I request the supporting documentation (for a full audit) per date - therefore, the entities maintain their records in chronological order to check the respective journal entries and their documents in this order.
Tracking GL transactions is efficient for sample auditing only.
@evans, although I completely agree with your request but I still don’t believe that it’s related to this topic
Please see this topic
I think this is more like what you propose here.
1 Like
@evans, you can actually do what you describe in Manager. You need to abandon use of cash and bank accounts and set up your own ordinary accounts in the chart of accounts to represent those. Then, you will be able to make journal entries involving those self-established accounts. The shortcomings are that you give up Bank Account Summaries, Receipts, Payments, Inter Account Transfers, Bank Reconciliations, etc. You would lose the ability to track deposit and withdrawal clearance status. You would also sacrifice almost all user permission granularity.
You would be reverting to very crude accounting practices where everything is entered by journal entry. Most people gave that up decades ago with the introduction of computer-based systems. And you would face the problem that everyone who touched the accounting system would need to become expert at determining which accounts to debit and which to credit.
All that just so you can have all transactions numbered in a single sequence rather than having sequences for separate transaction types? To me, that seems a very poor tradeoff.
1 Like
This is what I cope with now.
I absolutely agree with you. However, as I said, acting as an auditor, I am confronted with entities that a different (maybe poor) style of accounting may be used…
Basically, you are asking that most features added to the program over the years for the convenience of users be bypassed. If that is what you want, you should reconsider your selection of Manager as your software. The program’s development has followed a certain philosophy, which may not be appropriate for all users.
I wrote about a similar situation just a few days ago: GST inclusive profit and loss - #15 by Tut. I reproduce the relevant portion here:
…it seems legitimate to consider a professional’s duty to educate management personnel on the real meaning and proper interpretation of standard financial statements. Blind acquiescence to unjustified requests merely to perpetuate longstanding distortions of accounting practices isn’t a valid reason to incorporate improper procedures into a publicly distributed program.
In that case, clients were demanding distortion or violation of fundamental accounting principles. In your case, your clients are not requesting distortion of those principles so much as regression from modern practices. When daily journal entries were entered by hand, there was a reason for a single, common sequence. That reason no longer makes sense.
1 Like
It is possible to produce a journal style report by using Custom Reports. I use a report with these parameters:
.
The concept of transaction modules for similar transactions was/is/can be used in hand written accounting. Examples: Sales Journals and Purchases Journals
1 Like
@evans, it is also worth noting that every transaction in Manager has a date. So regardless of reference number sequencing, you can always determine chronological order, at least to the day, though not within a day.
1 Like
I fully agree with you.
Concerning the examples of Payments and Receipts we mentioned before:
technically, I could use them to meet the requirements of my businesses if the (bank) account (paid from/to) will be illustrated in the final document.
What I mean:
The result of a payment is now like this:
However, when we created/edited this payment, we had already made an entry for the bank account:
To conclude, if bank account is printed in Payments / Receipts, it will be perfect for me, meeting finally the initial requirements which drove me to start this topic.
I will initiate a new topic if necessary.
This subject has been discussed countless times on the forum. The reason bank and cash accounts are not shown is that your customer or supplier (if you use a payment form as an advice accompanying your payment) has no business knowing which accounts you use. The Paid from/Received in accounts can, however, be displayed in the tab listings. Isn’t that enough for an auditor?
For me the keyword here is “if” (if you use a payment form as an advice accompanying your payment). For example, there may be a case of external audit where the auditors want to see printed documents (payment vouchers) regardless of their access (or not) to the accounting software (in our case, to check information through tab listings).
Considering this subject has been discussed countless times on the forum, why not to give the user the ability to choose whether account appears in Payments and Receipts (for example, by using a check box)?
In my opinion and experience, auditors want to examine the actual recordkeeping method used by a business. A self-generated payment/receipt form can be easily faked. So it is virtually worthless for audit purposes. Granted, computerized records can be faked, too. But they can also be checked for internal consistency and correspondence with independent documentation.
Recently, a court required a company to send the signed payment voucher (in a case of a trial between supplier-customer parties).
The judge (at least in my country, until today) will not check the accounting application (he has already asked for a certificate from the auditor of the company as well), but he also asked to see a tangible document signed by the accounting office of the company (just for the court paper book - case file).
Obviously this can be faked, but the company would not risk sending a forged document to court.
Anyway, in any case, I believe that an option for the users to be able to choose to have the bank account displayed in Payments/Receipts could be at their discretion (why not to be flexible - will this option be against the philosophy of the software?).
Signed by whom? And what if the payment had been electronic, with no signed document? Besides, your internal record of the payment is not primary evidence to begin with, regardless of whether it shows the bank account the payment supposedly came from. The best legal evidence of the payment is the cheque or bank statement. A signature on an internal document is only evidence of the supplier’s acknowledgement of that piece of paper, not evidence that the payment came from any particular bank account.
Umm…I’ve taken part in many court cases and usually they’re not picky about the specific type of evidence with regards to proof of payments, unless of course, they’re trying to establish liability to whoever authorized the payment.
In your case, the signed payment voucher is supplemental to the bank evidence – statement, advise, confirmation or otherwise which are the main evidence. This means that simply sharing the bank reference and amount would be enough for court admission.
2 Likes
I agree. But lets think out of the box.
We are talking about payments and receipts involving cash and cash equivalents.
So, there may not be a bank reference in any case.
We may have a cash transaction or a check.
In any case, I strongly support the solution of providing flexibility to the user to display (or not) this information (paid from/to) in the final document of Payment/Receipt based on his needs.