NLCJ

Klopt. In principe is dit ook geen probleem, echter moet het zichtbare resultaat er ook zijn. Dan kan ik heel leuk achter de schermen met een maximaal aantal decimalen werken, maar dan krijgt de klant de factuur met zichtbaar ietwat andere waardes waarna het totaalplaatje niet meer klopt. Of mis ik hier iets? Mijn punt is dat er nagenoeg altijd een aantal scenario's zijn waarbij zo laat mogelijk afronden zorgt voor een incorrecte factuur. Dat het dan volgens de berekening achter de schermen wel klopt zal de belastingdienst niet veel boeien, gok ik. Die paar cent per kwartaal. :) Bedankt voor de tip. Zal het nog eens uitzoeken! EDIT: Overigens zie ik inmiddels bij een ander bedrijf dat zij ook alles inclusief BTW vermelden. Zie bijlage. EDIT2: Volgens mij zit er een bug in de forumsoftware bij gelijknamige plaatjes als bijlage. Plaatje aanklikken werkt wel.

Veel verschillende opinies zo te zien. ;D Dit werkt prima totdat ik een totaalbedrag heb van 23.85 EUR, waarna de verticale som wederom niet klopt. Exclusief BTW: 23.85 / 121 * 100 = 19.71 EUR. Prijs per stuk: 19.71 / 12 = 1.6425 EUR (afgerond op 3 decimalen dus 1.643 EUR) Prijs voor de regel: 1.643 * 12 = 19.716 EUR (afgerond dus 19.72 EUR) Dit is dus niet echt een optie meer aangezien de factuureisen anders zjin. Hetgeen dat erin zal resulteren dat de verticale som op een bepaald moment niet klopt. Als mijn initiele methode wettelijk toegestaan is dan prefereer ik die. Het gros van mijn afnemers zijn particulieren. Daarnaast wil ik uiteindelijk de BTW verleggen wanneer een bedrijf diensten bij mij afneemt. Zoals Ron al aangaf is het weliswaar lastiger voor bedrijven met hun boekhoudprogramma. Echter zal dit dus opgelost worden door de BTW te verleggen. Voor mijn eigen boekhouding maakt het ook niet uit aangezien ik geen bestaand programma gebruik maar deze zelf ontwikkeld heb. Die 6 cent die ik nu door afronding meer moet afdragen volgens mijn eigen berekening, daar lig ik niet wakker van. Dus dan resteert de vraag of deze methode toegestaan is...

Dit is dus exact mijn probleem, aangezien ik terugreken vanuit een prijs inclusief BTW. Mijn totaalprijs is 23.88 EUR. Pak hierover 21%; 4.14 EUR. Dit resulteert in een resterend bedrag van 19.74 EUR. 19.74 / 12 = 1.645 EUR. Wanneer ik dan als eenheidsprijs 1.65 of 1.64 opschrijf, dan klopt de rekensom per regel niet. En wanneer ik die rekensom wel laat kloppen, dan klopt de verticale som niet meer. Ik was onder de veronderstelling dat je de eenheidsprijs en totaalprijs per regel exclusief BTW moest vermelden. Helaas kan ik dit nergens concreet terugvinden, anders is dit inderdaad een makkelijke oplossing. EDIT: Hier staat 'de prijs per stuk of eenheid, exclusief btw'.

Over de afgelopen maanden heb ik mijn eigen facturatie systeem gemaakt waarin ik alles bijhoudt. Deze genereert en verstuurt ook automatisch facturen naar de klant. Echter doordat ik het zelf gemaakt heb, ben ik er niet zeker van of de manier waarop ik de BTW bereken wel correct is (de Belastingdienst via Twitter snapt mijn vraag niet). Volgens deze pagina van de belastingdienst zijn er twee methodes voor het afronden van een BTW bedrag; [*]U rondt af per geleverd goed of verrichte prestatie. [*]U rondt het totaalbedrag af. Mijn systeem bouwt een factuur op en rekent terug vanuit de prijs inclusief BTW (in verband met het leveren van diensten aan andere landen in Europa, welke dezelfde prijs inclusief BTW moeten hebben maar een ander BTW tarief hebben - MOSS regeling). In de bijlage heb ik een voorbeeld van mijn probleem toegevoegd, de eenheidsprijs bedraagt 1.99 EUR. Hierna berekent mijn systeem de prijs zonder BTW en de BTW; [*] Prijs exclusief BTW: 1.99 / 121 * 100 = 1.6446 EUR (afgerond 1.64 EUR) [*] BTW: 1.99 / 121 * 21 = 0.3453 EUR (afgerond 0.35 EUR) Momenteel rond ik de prijzen af voordat ik deze vermenigvuldig met het aantal stuks dat afgenomen wordt. Dit resulteert dus (zoals te zien in de bijlage) in een totaal BTW bedrag van 4.20 EUR, hetgeen dat uiteindelijk 21.3% is van het bedrag exclusief BTW. Concreet is mijn vraag dus of dit een correcte methode is, of moet ik het bijvoorbeeld eerst vermenigvuldigen met het aantal stuks voordat ik deze bij elkaar optel?