Is it possible to show the transaction id (ie the database unique key that I can see in the link when I press the cr or dr amount) in the report?
It would make possible the auditing of report without the software and it would make the report compliant to the European law.
I don’t see the purpose of displaying a 32-character hexadecimal key. How would an auditor use the key? I also doubt whether any European country’s law mentions a hexadecimal key, so what requirement would be fulfilled?
They ask for an unique association between the transactions
You did not address my question. What, exactly, would the auditor do with the key? How does a key from the database provide a “unique association between transactions?” Between which transactions? The report is a list; it does not make associations.
the italian law states this rules for the general ledger transaction report:
all the pages must be numbered
must be stored within three months from the deadline for the presentation of the annual income declaration
it must have tax stamps on the pages
all the transactions have to show:
a) date (OK)
b) description (OK)
c) amount (OK)
d) account code and description (OK… I put the account code in the description since it is alphanumeric)
e) clear unique identification of the transcation (MISSING)
Thanks to the last integration by @lubos we now have numbers on each pages. What is still missing is a unique key that can help any auditor from the official paper to reconstruct the transaction.
Here is a simple example:
I register a payment. I will have at a certain point of the general ledger transaction with date 12/7/2018 reduction of my bank account of 20.000 euro and a deduction of my debits with Mr. @lubos of 20.000 euros. In the actual report the is no way to associate this two lines if not by date (I’m talking about the paper report which will be in the hands of the auditor). Think about 150.000 lines, the only thing that you can do is to cross check the date and the amount, but it’s not an acceptable and error proof method.
However if I “click” on these two lines I always get to the correct bank transaction. How? Because the program has an unique id for bank transaction, for example 48b436d5-1874-4670-8c2f-ce2d2f50259b. I know that there are different modules that maybe can have the same id (bank transaction, journal entries and so on) but this would be easily solved with a prefix in the key (bt-48b436d5-1874-4670-8c2f-ce2d2f50259b).
If I add this key in the paper report in a new column I will have to advantages:
- first of all I will be in line with the law that asks me an unique id that associate the transactions
- if I export in excel the report I will be able to do a lot of analysis, for example to filter with pivot table the report in order to re-classificate it by transactions and not by account
Since it’s only a problem to implement an extra column in the report I think that it’s a few minutes implementation that would help everyone a lot. Maybe there can be a flag in the report settings to show this field or not.
Thank you for the explanation. What I did not understand before was that you are trying to allow an auditor to work from a paper report. In my experience, auditors (meaning accountants who are reviewing your records to provide an opinion on their accuracy) always want to delve into the actual electronic records. Tax authorities, on the other hand, generally have specific questions, and you are usually better off not to allow them access to your records, but to produce only the specific documentation required to answer their question. I suppose things could be different in Italy. (In ways besides having better food.)
Yes. Keep in mind that this solution will help also an auditor with the excel format to do his checks.
Can we put this in the ideas?
The latest version (18.7.30) will show reference number and transaction type on general ledger transactions report.
But… I still think this shouldn’t be a report but a spreadsheet export. To me report is something which summarizes entered data… something compact which can be printed.
General Ledger Transactions report can span many many pages and is never practical to print.
This is a somewhat limiting perspective as reports can be both itemisation and summary.
For example - to reconcile a particular account requires an itemisation report of the accounts contents.
For an accounting software to maintain integrity it should create reports internally of it self, kicking data out to a spreadsheet doesn’t maintain that integrity as the data is open to manipulation.
Also, reports can be combination of both itemisation and summary, take an accounts receivable account report, it itemises the customers but summarises their activity.
@lubos instead, having 1 type of report which you may have conflicted opinion, made available for two, one is for presentation another is for audit (internal review).
Just for a reminder every type of audience, have different priorities and capability to process the information. With limitation of how much information can be fit in A4 size paper.