Dutch VAT report

I use the latest version (19.6.78) and e “BTW 21% EU en BTW 21% nonEU” calculates the VAT amount with wrong decimals. see sample.
In april all was fine even without the deciamls but now …

4 Prestaties vanuit het buitenland aan u verricht
4a Leveringen/diensten uit landen buiten de EU € 115,72 € 2430,12 should be € 24,30
4b Leveringen/diensten uit landen binnen de EU € 149,97 € 3149,37 should be € 31,50

or no decimals Tax department doesnot need decimals

Please have a look at this.

Kind regards
TonV

I updated form the localizatins the newest Concept BTW aangifte enad installed according the instructions.
No solution , it still shows the decimals and the wrong EU amounts.

Kind regards
TonV

This has been put into the bugs category by the developer.

Could you download the latest version (19.7.7) and import the latest localization from https://www.manager.io/localizations/nl ?

This should fix the calculation issue.

@Lubos, unfortunately this does not solve the problems with the report. There is a warning at the top of the report stating that “liquid error, the number of parameters donot match”. There are still decimals in all the figures. The calculation of EU VAT is wrong and does not apply with Dutch fiscal rules.@hennie. of course i can send a sample. kind regards

@lubos, i installed version 19.7.10 and the error message is gone but all figures still show decimals. Fortunatyely theEU VAT calculation is correct again but also show decimals. This is a lot better but …kind regards

@lubos Thank you for adding the check on updates, very well doen and quickly adjusted
The report hasnot been updated and the decimals are still there? I reckon that this is a matter of rounding in the report. Can i adjust the report myself to fix this (possibly as a custom report?) for example to get the report from an older version of manager. any suggestion? kind regards

Download the localisation .json file, edit it, then import it.

@Patch
What do you mean by “edit it”. What should be edited?

IThe .json localisation file is a text file, open it with a text editor and change it to what you want it to be. You can then import it into your Manager business and test it produces the results you want.

When you have corrected it’s problems then everything one can benefit from your work.

The bottom HTML section is not as easy to read as the prior presentation in the localisation section however the the top calculation section is relatively easy to read.

Hopefully it will make sense to you as that way the Duch are likely to get a better localisation and in the longer term localisation by local users is exactly what needs to be done. Clearly there is no way Lubos can generate or maintain localisation for over 200 countries.

For the localisation transformation to work, the untransformed report needs to be correct, which maybe why Lubos called it the same problem.

I definitely disagree with what you wrote.
I am a financial controller and a user of Manager and I expect the software to work the way it should work. I am not a programmer and I don’t want it to be or to be pushed into that role.
You can’t expect from users that they take over the work a developer should do.
To say it very rude, that is his problem, regardless the fact whether it is just for one country or over 200 countries. If you make it user friendly for instance by parameters then it is up to the user how he wants the software to work.
It is a standard Dutch report, according to the EU-rules so the software should be able to cope with the requirements. It is not a custom report.
And suppose I modify the localization file, how can other Dutch users benefit from the modified file as this file is stored on my laptop? And the next question is: how do users address the mistake I made?

If I might make a comment, I had a look at using the Dutch VAT report as a base for creating an Irish VAT report. I’m not an accountant but have worked in installing, configuring and supporting financial systems and also have a good practical knowledge of analysis and programming.I also have experience of working in Ireland, Uk and France.

My impression is that EU VAT reporting is quite similar but not identical across the EU. Of particular difficulty is the recording and reporting of intra-EU purchases and sales where you are expected to account for notional VAT charges on invoices.
A lot of smaller businesses in Ireland, even in today’s EU would not have a lot of sich transactions and so the current VAT reports will cover most of their needs.
It is true that corrections carried out by journal entries are problematic but many small businesses wouldnt be that fussed about details like that - it would be a distraction to their main goals.

I am not sure how to continue - do I forge on and try to create a complicated report system which most Irish users will simply ignore or use incorrectly in any case…

The mechanics of VAT are in almost every country in the EU basically the same.
The tax-return forms differ per country as well as the VAT-rates.

When we have Intra-community transactions (goods or services) most of the EU countries want to know the value of the transactions and the corresponding VAT for their internal financial (VAT) position.
Additional detailed information is in most cases required by the local tax-authority.
When you have only inland sales and purchases, it is not that complicated.
When a report is incorrectly used, that is always the responsibility of the user, but when a report shows figures, these figures need to be correct.

Fortunatly it is not hard to edit the custom report.
I made a new version that rounds everything down in your advantage and get rids of the decimals. You can download it here if you like:

Hi Daniel,

Thanks for this reply, but the problem with the standard report as provided by the developer is, that the way the VAT is calculated, is wrong. See and read the topics Why do the costs on a journal entry show in the net sales column? and VAT Declaration for NL not populating correctly

As long as it is not a custom report, I think it is the developers responsibility to take care that the report is correct. Custom reports however are a different kind of report and there it is the users responsibility for what they create.

These bugs need to be fixed by us at the website level. It’s not something end-users are expected to be modifying and fixing. Mostly because:

  1. When you click Check of updates button, it will override your changes with whatever is in global localization database.
  2. You can turn off Check for updates button (by removing “Source” attribute from JSON file) but then you can’t benefit from the future improvements.

As for the rounding, there is now new version of the report. It’s basically exactly what @Daniel_Peppelenbos has done except I’ve used round filter instead of floor filter. I assume figures should be rounded up or down based on decimal being 5 or higher. Floor filter will always round down.

Thanks Lubos!
Could you change it to floor again? See the following remark from our Dutch Tax Agency:

Rounding off amounts
You should round off all amounts to the nearest euro, in your advantage. A minus (-) should be placed before the
amount if you mean to fill in a negative amount.

In our advantage, means paying less tax, so rounding down (floor).

Source: https://download.belastingdienst.nl/belastingdienst/docs/toelichting_bij_dig_aangifte_omzetbelasting_ob0731t91fd.pdf

Sorry for the trouble and our weird Dutch rules :wink:

Alright. I’ve changed that to floor now.

1 Like

5b should be ‘ceil’ i.s.o. ‘floor’. :wink:

In the end it really doesn’t matter too much as you’ll have to book the difference as income or expense.