BTW afronden op factuur

[NLCJ]

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?

[Ron van der Kolk]

Beste NLCJ,

 

Welkom op Higherlevel.

 

Ik weet niet of de Belastingdienst met "per geleverd goed" de afzonderlijke producten of de factuurregel bedoeld. Ik denk dat het ze worst zal wezen eigenlijk, als het maar ongeveer klopt, herleidbaar is en wordt afgedragen.

 

Wel drie andere overwegingen die ik er bij heb:

 

[*]Als zakelijke klant zou ik op het plaatje 21% over 19,68 verwachten, dus 4,13. Dat is ook wat mijn boekhoudpakket als suggestie zal geven. Een ander bedrag lijkt vreemd.

[*]Ik zou het lastig vinden als daar 4,20 staat in plaats van 4,13, want dan moet ik dat weer handmatig gaan invoeren. (Ik heb een leverancier waarvan de totale BTW op de factuur er ook steeds er naast zit, heel irritant).

[*]Als leverancier wordt het voor jou mogelijk ook lastiger om de uitgaande facturen goed in je boekhouding te krijgen, omdat je boekhoudpakket het mogelijk niet automatisch meer voor je uit kan rekenen.

 

 

[StevenK]

Je werkt met eenheidsprijzen inclusief BTW. Dan zou ik ervoor kiezen de BTW pas bij het factuurtotaal uit te splitsen en verder overal alleen de prijzen inclusief BTW vermelden. (en dan als laatste nog een check doen of het totaal incl. BTW nog hetzelfde is en anders het btwbedrag met een cent corrigeren)

 

Op die manier voorkom je namelijk verwarring.

[NLCJ]

[*]Als zakelijke klant zou ik op het plaatje 21% over 19,68 verwachten, dus 4,13. Dat is ook wat mijn boekhoudpakket als suggestie zal geven. Een ander bedrag lijkt vreemd.

[*]Ik zou het lastig vinden als daar 4,20 staat in plaats van 4,13, want dan moet ik dat weer handmatig gaan invoeren. (Ik heb een leverancier waarvan de totale BTW op de factuur er ook steeds er naast zit, heel irritant).

[*]Als leverancier wordt het voor jou mogelijk ook lastiger om de uitgaande facturen goed in je boekhouding te krijgen, omdat je boekhoudpakket het mogelijk niet automatisch meer voor je uit kan rekenen.

 

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.

 

 

Je werkt met eenheidsprijzen inclusief BTW. Dan zou ik ervoor kiezen de BTW pas bij het factuurtotaal uit te splitsen en verder overal alleen de prijzen inclusief BTW vermelden. (en dan als laatste nog een check doen of het totaal incl. BTW nog hetzelfde is en anders het btwbedrag met een cent corrigeren)

 

Op die manier voorkom je namelijk verwarring.

 

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'.

[RT....]

Kun je je 'per stuk'-prijzen niet laten zien met 3 cijfers achter de komma?

Dus 1,645 ipv 1,64?

[realist]

Vergelijk het maar met de bonnetjes in de supermarkt.

Ook zij werken met prijzen incl btw, zo staan ze in de winkel zelf, en in de folder, aangeprijsd.

Het zou erg veel overbodige info geven als van elk artikel de prijs excl, de btw, en de prijs inclop de bon verschijnt. Bovendien krijg je dan inderdaad afrondingsverschillen.

Daarom : een code aan elk product, en onderaan de bon de uitsplitsing naar btw-categorie, met daar wel (eenmalig) de totalen excl, de btw en de totalen incl btw.

 

 

edit: @ RT: dat maakt het wel een stukje nauwkeuriger, maar lost in de basis niks op.

[Roel J]

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'.

 

dat klopt ook maar er staat niet dat die eenheidsprijs afgerond op 2 cijfers achter de komma moet worden weergegeven, jij mag best op de regel 1,6446 vermelden als eenheidsprijs ex btw.

 

afronden doe je volgens normale boekhoudregels het liefst zo laat mogelijk juist om te voorkomen dat je door tussentijdse afrondingen grote afwijkingen ontstaan.

 

[RT....]

edit: @ RT: dat maakt het wel een stukje nauwkeuriger, maar lost in de basis niks op.

4 cijfers dan. ;)

 

[StevenK]

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'.

 

dat klopt ook maar er staat niet dat die eenheidsprijs afgerond op 2 cijfers achter de komma moet worden weergegeven, jij mag best op de regel 1,6446 vermelden als eenheidsprijs ex btw.

 

afronden doe je volgens normale boekhoudregels het liefst zo laat mogelijk juist om te voorkomen dat je door tussentijdse afrondingen grote afwijkingen ontstaan.

 

maar ook dan krijgt 'ie weer gezeur met klanten omdat op de factuur een afwijkend bedrag staat. Op de factuur horen gewoon de prijzen te staan die hij met zijn klant afspreekt. Is dat incl. btw, dan vermeldt hij incl btw bedragen.

[prinsrachid]

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'.

afronden doe je volgens normale boekhoudregels het liefst zo laat mogelijk juist om te voorkomen dat je door tussentijdse afrondingen grote afwijkingen ontstaan.

maar ook dan krijgt 'ie weer gezeur met klanten omdat op de factuur een afwijkend bedrag staat. Op de factuur horen gewoon de prijzen te staan die hij met zijn klant afspreekt. Is dat incl. btw, dan vermeldt hij incl btw bedragen.

Aan de andere kant: je kunt ook gewoon het bedrag exclusief btw natuurlijk ook op twee cijfers naar beneden afronden, als het echt niet anders kan. Dan loop je hooguit een cent mis.

 

Zo had ik ooit een mobiele abonnementje afgesloten dat "slechts 10 euro per maand!" zou kosten. Dat bedrag is alleen onmogelijk, als je én het bedrag ex btw én de btw afrondt op 2 cijfers. Dan wordt het of 9,99 euro of 10,01. Ik kreeg dan ook maandenlang facturen van ieder 9,99 euro. Volgens mij is het steeds gebruikelijker voor dergelijke bedrijven om alles inclusief btw te factureren en dan ergens onderaan een btw-berekening te tonen.

[Ward van der Put]

Vergelijk het maar met de bonnetjes in de supermarkt.

Ook zij werken met prijzen incl btw, zo staan ze in de winkel zelf, en in de folder, aangeprijsd.

Het zou erg veel overbodige info geven als van elk artikel de prijs excl, de btw, en de prijs inclop de bon verschijnt.

Je kunt het kasstelsel niet vergelijken met het factuurstelsel. Aan een factuur worden nu eenmaal uitgebreidere eisen gesteld dan aan een kassabon — waaronder de verplichting om de stuksprijs exclusief btw te vermelden.

 

Ik zou omwille van de klant beginnen bij het einde. De klant verwacht namelijk 12 × € 1,99 incl. btw = € 23,88 incl. btw te moeten betalen.

 

(€ 23,88 incl. btw ÷ 1,21) – € 23,88

= € 4,144462809917355371900826446281 btw

≈ € 4,14 btw

 

€ 23,88 incl. btw – € 4,14 btw

= € 19,74 excl. btw

 

€ 19,74 excl. btw ÷ 12 stuks

= € 1,645 per stuk excl. btw

 

Als je rekent met floats, krijg je altijd afrondingsverschillen. Bij een 64-bits processor minder snel dan bij een 32-bits architectuur, maar dat is technisch een voldongen feit.

[StevenK]

Bizar eigenlijk: bij consumenten ben je verplicht een prijs inclusief BTW overeen te komen, maar je bent evenzo verplicht op je factuur eenheidsprijzen exclusief BTW te vermelden, waardoor je een groot risico hebt op verschillen. #paarsekrokodil

 

[Easy does it]

Hallo,

 

Volgens mij stelt de fiscus juist 2 methodes voor om het probleem van niet kloppende tellingen op de factuur te vermijden.

Je rond af per regel en telt dan de afgeronde BTW bedragen op tot factuurtotaal.

Of je berekent op factuurtotaal de BTW en je rond dan af.

Het makkelijkste lijkt mij af te ronden op het niveau dat je het BTW bedrag weergeeft.

Of per regel of per factuur.

 

 

 

 

 

Bij het afronden mag u kiezen uit 2 methodes:

•U rondt af per geleverd goed of verrichte prestatie.

•U rondt het totaalbedrag af.

U mag niet beide methodes naast elkaar gebruiken. En u moet in uw keuze voor gebruik van een methode een vaste lijn volgen.

 

[NLCJ]

Veel verschillende opinies zo te zien. ;D

 

 

Ik zou omwille van de klant beginnen bij het einde. De klant verwacht namelijk 12 × € 1,99 incl. btw = € 23,88 incl. btw te moeten betalen.

 

(€ 23,88 incl. btw ÷ 1,21) – € 23,88

= € 4,144462809917355371900826446281 btw

≈ € 4,14 btw

 

€ 23,88 incl. btw – € 4,14 btw

= € 19,74 excl. btw

 

€ 19,74 excl. btw ÷ 12 stuks

= € 1,645 per stuk excl. btw

 

Als je rekent met floats, krijg je altijd afrondingsverschillen. Bij een 64-bits processor minder snel dan bij een 32-bits architectuur, maar dat is technisch een voldongen feit.

 

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)

 

maar ook dan krijgt 'ie weer gezeur met klanten omdat op de factuur een afwijkend bedrag staat. Op de factuur horen gewoon de prijzen te staan die hij met zijn klant afspreekt. Is dat incl. btw, dan vermeldt hij incl btw bedragen.

Dit is dus niet echt een optie meer aangezien de factuureisen anders zjin.

 

Aan de andere kant: je kunt ook gewoon het bedrag exclusief btw natuurlijk ook op twee cijfers naar beneden afronden, als het echt niet anders kan. Dan loop je hooguit een cent mis.

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...

 

[Ward van der Put]

Je moet afstappen van de idee dat afrondingsverschillen niet kloppen; die kloppen juist wél, want daarom zijn het verschillen.

 

Het enige dat je kunt doen, en dat redelijkerwijs van je verlangd kan worden, is dat je de verschillen zo klein mogelijk houdt. Dat doe je door zo min mogelijk af te ronden en door zo lang mogelijk met zo lang mogelijke getallen te rekenen. (Dat de weergave van een getal afwijkt van het getal waarmee je rekent, hoef ik iemand die zelf software bouwt niet uit te leggen, gok ik.)

 

En als je alles op de cent nauwkeurig kloppend hebt, moet je nog fijn even een ander afrondingsverschil wegwerken: je doet aangifte in hele euro's, waarbij je in je voordeel mag afronden. Maar gelukkig zit het anderzijds daarom soms mee en verdwijnen je eigen afrondingsverschillen als sneeuw voor de zon.

 

Het verleggen van btw zou ik trouwens nog eens even nalezen. Je maakt mogelijk een beginnersfout die ik beginners wel vaker zie maken: je kunt niet automatisch alle btw verleggen naar klanten met een btw-nummer.

 

 

[NLCJ]

Je moet afstappen van de idee dat afrondingsverschillen niet kloppen; die kloppen juist wél, want daarom zijn het verschillen.

 

Het enige dat je kunt doen, en dat redelijkerwijs van je verlangd kan worden, is dat je de verschillen zo klein mogelijk houdt. Dat doe je door zo min mogelijk af te ronden en door zo lang mogelijk met zo lang mogelijke getallen te rekenen. (Dat de weergave van een getal afwijkt van het getal waarmee je rekent, hoef ik iemand die zelf software bouwt niet uit te leggen, gok ik.)

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.

 

En als je alles op de cent nauwkeurig kloppend hebt, moet je nog fijn even een ander afrondingsverschil wegwerken: je doet aangifte in hele euro's, waarbij je in je voordeel mag afronden. Maar gelukkig zit het anderzijds daarom soms mee en verdwijnen je eigen afrondingsverschillen als sneeuw voor de zon.

Die paar cent per kwartaal. :)

Het verleggen van btw zou ik trouwens nog eens even nalezen. Je maakt mogelijk een beginnersfout die ik beginners wel vaker zie maken: je kunt niet automatisch alle btw verleggen naar klanten met een btw-nummer.

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.

[StevenK]

Ik zou toch echt alles inclusief BTW vermelden en alleen onderaan de BTW uitsplitsen. Je bent tenslotte ook verplicht naar consumenten prijzen inclusief BTW te hanteren. Dat is de enige manier waarop je het voor de klant duidelijk houdt.

 

[Ward van der Put]

[...] maar dan krijgt de klant de factuur met zichtbaar ietwat andere waardes waarna het totaalplaatje niet meer klopt. Of mis ik hier iets?

Een consument kijkt vooral naar het totaalplaatje. Nauwelijks naar het totaalbedrag exclusief btw. En al helemaal niet naar de inclusief-en-exclusief-btw-opbouw van afzonderlijke factuurregels.

 

Daarom is de psychologische prijsstelling die @prinsrachid zijdelings aanstipt een interessant fenomeen: € 9,99 lijkt een bedrag van een andere orde dan € 10,01.

 

Meer in het algemeen doet het er niet toe. Als je consumenten belooft dat het "alles bij elkaar" € 9,99 is, dan is het dus niet € 10,01.