Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TX Direction differentiation and Export to CSV #208

Open
tobiasnunes opened this issue Jan 28, 2019 · 0 comments
Open

TX Direction differentiation and Export to CSV #208

tobiasnunes opened this issue Jan 28, 2019 · 0 comments

Comments

@tobiasnunes
Copy link

In Agama you can see the incoming and outgoing transactions. These are called "In" and "Out". There are also "self" transactions. You can export these transactions as a CSV file. If a wallet user spends his complete KMD inventory, then according to the mathematical rules inputs and outputs together should result in zero.

The balance display in AGAMA then (as for now) actually shows zero. And that is correct. But if you look at the CSV file and subtract all outputs from all inputs, in some cases a large positive sum remains. This sum does not exist on the wallet. The user has actually output everything. Nevertheless technical inputs appear in the table and also in the transaction list of AGAMA which are not actual inputs.

Most people make their tax declaration for the last year at the beginning of the new year. Of course, everyone is responsible for writing everything down correctly. However, the blockchain is intended to make it easier for people to understand things better and not to have to write down every transaction manually.

Therefore it would be of great advantage, if purely technical transactions, which do not represent any real input mathematically and fiscally, are also marked as such in AGAMA and in the CSV Report. Otherwise, the user runs the risk of paying large sums of tax for receipts never received. In the near future the tax office will certainly not look at every single transaction in the Blockexplorer and analyse it precisely in order to judge it. The taxpayer finally submits the reports and the tax is calculated from this. So it should be as correct as technically possible.

With Agama we can be a pioneer in the field of collected transaction output, which drives adaptation and enables tax software vendors to correctly process AGAMA's CSV files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants