Deze Releasenote bevat een aanpassing voor een probleem welke mogelijk onoplosbaar is. Het betreft een situatie waarbij er BTW berekend wordt in Vreemde Valuta (iets wat normaliter nooit aan de orde is !).
Neem als uitgangspunt dat we een bedrijf hebben welke in Nederland geregistreerd is, dan zullen we 'de euro' als bedrijfsvaluta hebben, en zullen we eigenlijk alleen maar fakturen in EUR ontvangen waarop we BTW journaliseren. Stel dat we een Faktuur uit Amerika ontvangen waarop 'Sales Tax' in rekening is gebracht, dan boeken we dit niet als BTW (simpelweg omdat het geen BTW is) maar zullen dit op een andere rekening boeken (desnoods kosten).
Nu hebben we echter een bedrijf in Turkije...
In Turkije wordt met Valutakode TRY (Turkse Lire) gewerkt. In Turkije kennen ze geen BTW, maar daar kan een levering worden belast met KDV. Ervanuitgaande dat deze KDV gewoon een toeslag is op het faktuurbedrag (net als onze btw) zou je dit als zodanig kunnen inrichten. Een Leverancier stuurt ons een Faktuur van TRY 66.61 en hierop wordt een bedrag van TRY 11.99 aan KDV in rekening gebracht. Geen probleem, immers, net als dat dat dit EUR bedragen zouden zijn geweest kunnen we dit netjes journaliseren. 66,61 op de ene rekening, 11.99 op een andere rekening, en 78,60 als totaal aan de Crediteur over te maken.
Maar... In plaats van dat het Turkse Bedrijf in de bedrijfsvaluta in dat land geregistreerd is, is het Turkse Bedrijf opgezet in EUR. En nu gaan we een Faktuur boeken in een Valutakode <> EUR (en daarmee een Vreemde Valuta).
De TRY 11.99 zal (bij een koers van 0,33) uitkomen op een bedrag van EUR 3,9567. En, ervanutigaande dat we niet journaliseren in meer dan 2 decimalen, zal dit moeten leiden tot een BTW bedrag van EUR 3,96. EUR 3,96 teruggerekend tegen de koers 0,33 leidt echter tot een Turkse Lire bedrag van TRY 12,00 (en resulteert in 1 cent verschil t.o.v. de EUR 11,99).
Dit soort problemen zijn redelijk onoplosbaar, en treden op zodra je van twee valuta's vindt dat ze 'de bedrijfsvaluta' zijn, maar elkaar toch kunnen uitsluiten.
Laten we nog eens terugkeren naar het guldens tijdperk, en als voorbeeld nemen dat we op enig moment een Ingekomen Faktuur hebben ontvangen van NLG 0,12 welk bedrag op 6 verschillende kostenrekeningen geboekt moest worden (6 x NLG 0,02). In guldens ziet de journaalpost eruit als:
Kosten A NLG 0,02
Kosten B NLG 0,02
Kosten C NLG 0,02
Kosten D NLG 0,02
Kosten E NLG 0,02
Kosten F NLG 0,02
Aan Crediteur NLG 0,12
En nu gaan we over naar de euro. Alle bedragen moeten nu in EUR komen te staan. Ook in EUR zullen we gewoon in 2 decimalen journaliseren. De 6 afzonderlijke posten betreffen bedragen niet bij de verplichte koers van 2,20371 niet 100% kunnen worden omgerekend naar euros; afgerond is iedere post EUR 0,01 en dus hebben we nu 6 posten x EUR 0,01 = EUR 0,06.
Aan de Crediteurenzijde is er NLG 0,12 geboekt, wat afgerond EUR 0,05 wordt. Resultaat? 1 cent verschil.
Nu waren dit "eenmalige" konversies, en sinds de overgang naar de euro treedt dit niet meer op. Einde jaar 1 keer rechttrekken, en klaar. Door nu echter in een land waar de TRY de basis valuta is, de EUR als bedrijfsvaluta op te nemen, kreeren we alsnog weer dit soort situaties.
Overigens gaat er op dit moment financieel niets fout bij de journalisering van TRY 66,61 en TRY 11,99 aan KDV, hooguit gaf de terugkoppeling naar de subadministratie een btw aan van 12,00. Dit laatste is nu aangepast (door niet af te ronden), waarmee overigens niet gezegd is dat dit nu niet elders tot afrondingsverschillen zal kunnen leiden.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| ADBOBO | Omschrijving (nog) niet bekend | 21-01-2015 | 15-07-2015 |
| ADFITV | Boeken Ingekomen Fakturen | 07-05-2015 | 15-07-2015 |
