Weiger pdf als factuur: je mag de btw niet aftrekken

[jjdevries123]

Wij verhuren bouwgereedschappen. In 2006 ging onze grootste leverancier failliet en bij de belastingcontrole krijgen we te horen dat de facturen die we per e-mail ontvingen niet geldig zijn en dat we de btw niet terug mochten vragen. Nu moeten we alle btw terugbetalen die van onze leverancier hadden afgetrokken onder 'voorbelasting'. Volgens de inspecteur moet er een soort digitale handtekening onderstaan en volgens hem waren ze ook niet beveiligd (??).

 

Kan dit zomaar? Heeft iemand hier ervaring mee? De man die hier voor de controle was zegt dat 'de inspecteur' hierover beslist. Lopen wij nou de kans btw terug te moeten betalen ... dan hebben we een groot probleem!!

 

Jan-Jaap

[Maarten]

Dat geldt voor pdf facturen die je naar het buitenland stuurt of vanuit het buitenland ontvangt. Dat geld niet voor facturen binnen Nederland, volgens de belastingmedewerker die speciaal voor dat onderwerp naar een meeting bij onze klant was gekomen.

 

De hele situatie met digitale handtekeningen ligt vrij complex. De formele eis is dat er een geavanceerde digitale handtekening wordt gebruikt, zie http://www.belastingdienst.nl/zakelijk/elektronisch_factureren/elektronisch_factureren-08.html#P51_4670. Die geavanceerde digitale handtekening is niets anders dan een normale digitale handtekening, alleen dan met een certificaat wat ondertekend is door het stamcertificaat van de Staat der Nederlanden. Nu zijn die certificaten behoorlijk prijzig, naast dat dat stamcertificaat door geen enkele browser of reader standaard vertrouwd wordt.

 

Je hebt daarnaast ook nog speciale PDF certificaten, welke door Adobe vertrouwd worden. Nu is er geen enkel certificaat op de markt dat zowel door Adobe vertrouwd wordt als door de Staat der Nederlanden is ondertekend. Het probleem met PDF certificaten is daarnast nog eens dat ze erg prijzig zijn, en je meestal ook een maximaal aantal signing events hebt en ook nog maar eens door enkele partijen geleverd worden. Gelukkig gaat dit eind dit jaar door Adobe aangepast worden, maar momenteel is het een hoop gedoe om een echt PDF certficaat te krijgen.

 

Zelf adviseren wij mensen om facturen te ondertekenen met een e-mail certificaat. Deze zijn voor slechts enkele euro's en zelfs gratis te verkrijgen en worden door e-mail programma's zonder problemen herkend. PDF's kun je er ook mee signen, alleen Adobe Reader ondersteund deze niet standaard, je moet in Adobe instellen dat certificaten van Windows binnen Adobe vertrouwd mogen worden.

 

Ons advies aan klanten die digitale facturen versturen, is een e-mail certificaat aan te schaffen voor slechts enkele euro's en de public key van dit certificaat te publiceren op de website (en eventueel deponeren bij de Kamer van Koophandel). Het is dan altijd aan te tonen dat het certificaat authentiek is.

 

Er zijn overigens genoeg bedrijven die digitale facturen sturen zonder handtekening. Ze voldoen daarmee niet aan de regels, maar ik betwijfel of je als ontvanger dan risico loopt om BTW terug te moeten betalen. Mij lijkt dat erg sterk.

[Christine]

Wat veel mensen mbt email vergeten, is dat een email-bericht ook een heel pad bevat waarlangs het verzonden is.

In Outlook kun je dat zien door op een bericht te gaan staan, rechterknop indrukken en op Opties (onderaan) te drukken.

 

Dat is niet helemaal juist. Dat pad is wat het emailtje zegt dat het pad is. In een bona fide mailtje is het vaak juist, maar in een spam mailtje is het fake. Zelfs het afzeder adres hoeft niet het adres te zijn waarvanaf het mailtje verstuurd is. Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

 

 

 

[Maarten]

Dat is niet helemaal juist. Dat pad is wat het emailtje zegt dat het pad is. In een bona fide mailtje is het vaak juist, maar in een spam mailtje is het fake. Zelfs het afzeder adres hoeft niet het adres te zijn waarvanaf het mailtje verstuurd is. Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

Klopt, en daarnaast zie je niet aan de headers of het bericht onderweg ergens is aangepast. Met een digitale handtekening kun je dat wel zien.

[Henny van der Pluijm]

Kun je mij uitleggen hoe ik die headers kan veranderen zonder daarvoor eerst een speciaal programma te bouwen?

 

Want het gaat er bij authenticate niet om dat het 100 procent waterdicht is. Dat is niets. Handtekeningen zijn ook te vervalsen. Het gaat er om dat de kans dat een bericht vervalst is klein genoeg is om door een instantie of door de rechter als authentiek bericht geaccepteerd te worden.

 

Voor iemand die diep in de software zit, is misschien alles in een bericht te veranderen. Maar we praten hier over regulier emailgebruik. Net als we bij het versturen van papieren facturen praten over ondernemers die hun handtekening zetten en niet over vervalsers die valse handtekening zetten.

 

 

 

Wat veel mensen mbt email vergeten, is dat een email-bericht ook een heel pad bevat waarlangs het verzonden is.

In Outlook kun je dat zien door op een bericht te gaan staan, rechterknop indrukken en op Opties (onderaan) te drukken.

 

Dat is niet helemaal juist. Dat pad is wat het emailtje zegt dat het pad is. In een bona fide mailtje is het vaak juist, maar in een spam mailtje is het fake. Zelfs het afzeder adres hoeft niet het adres te zijn waarvanaf het mailtje verstuurd is. Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

 

 

 

[Maarten]

Kun je mij uitleggen hoe ik die headers kan veranderen zonder daarvoor eerst een speciaal programma te bouwen?

 

Eerste hit op Google: http://www.cert.org/tech_tips/email_spoofing.html

 

Want het gaat er bij authenticate niet om dat het 100 procent waterdicht is. Dat is niets. Handtekeningen zijn ook te vervalsen.

 

Geen enkel systeem is waterdicht. Maar er zit een groot gat tussen e-mail headers en digitale handtekeningen. Zie digitale handtekening als een goed slot op de deur, en e-mail headers als het ontbreken van muren.

 

[Henny van der Pluijm]

Dat is niet helemaal juist. Dat pad is wat het emailtje zegt dat het pad is. In een bona fide mailtje is het vaak juist, maar in een spam mailtje is het fake. Zelfs het afzeder adres hoeft niet het adres te zijn waarvanaf het mailtje verstuurd is. Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

Klopt, en daarnaast zie je niet aan de headers of het bericht onderweg ergens is aangepast. Met een digitale handtekening kun je dat wel zien.

 

Waarom zou een provider een bericht gaan aanpassen onderweg?

 

 

[Hans van den Bergh]

Ik krijg digitale facturen van Reeleezee en Casema met BTW. Moet ik die nu gaan weigeren?

Nee, natuurlijk niet. Deze hele discussie slaat echt als een tang op een varken. Eén of andere Nitwit van de belastingdienst kent het begrip PDF niet en jaagt de TS de stuipen op het lijf. Een factuur maak je aan op basis van de afspraken over prestatie en tegenprestatie. Er ligt dus een overeenkomst aan ten grondslag. En de wederzijdse boekhoudingen maken e.e.a. verifeerbaar.

 

Geen paniek, ik krijg zoveel facturen in PDF, ik maak ze zelf ook in PDF aan. Ik werk tegenwoordig met Reeleezee, en ik print ze pas uit als ik ze echt nodig heb. Het lijkt een beetje op dat verhaal van die agent die een TomTom gebruiker bekeurde, je hebt te maken met een duidelijk incompetent figuur.

 

Succès en groet,

 

Hans

[Maarten]

Waarom zou een provider een bericht gaan aanpassen onderweg?

 

Internet bestaat niet alleen uit grote internetproviders die simpel informatie doorgeven. Internet bestaat onder meer uit een groot aantal servers welke gehacked kunnen worden. Misbruik is op veel manieren mogelijk, maar dat lijkt mij hier offtopic.

[Henny van der Pluijm]

Deze "eerste hit op Google" is een tekstje over email spoofing waar in de verste verte niet in staat hoe je zoiets kan doen.

 

Daarnaast staat er een reclametekstje over PGP, wat leuke reclame is voor de email signature lobby.

 

Het onderschrijft alleen maar mijn stelling dat het verre van eenvoudig is om alle pad-informatie in een email te veranderen.

Ik heb het dus niet over de afzender, de cc en de body, want dat kan de afzender makkelijk vanuit een programma doen dat dat automatisch aanmaakt.

 

Het gaat mij er om dat er in een binnengekomen email een heel pad in staat, inclusief IP-nummers en codes.

Dat is alleen aan de kant van de ontvanger te vervalsen, niet aan de kant van de afzender. En zelfs aan de kant van de ontvanger is dat een klus waarvan 99,99 procent geen idee heeft hoe dat moet. Een handtekening vervalsen is makkelijker.

 

Dan nog zou het in een rechtzaak naast de gegevens van de provider gelegd kunnen worden om te checken of paden en codes kloppen, zelfs buiten de tijd dat de provider de email wettelijk verplicht had moeten bewaren.

 

Received: from hpsmtp-eml02.kpnxchange.com ([10.94.77.136]) by CPEXBE-EML21.kpnsp.local with Microsoft SMTPSVC(6.0.3790.1830);

    Tue, 16 Sep 2008 23:50:26 +0200

Received: from lb01.kingsquare.nl ([87.233.149.194]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959);

    Tue, 16 Sep 2008 23:50:26 +0200

Received: from SwiftUser (fs1 [87.233.149.197])

   by lb01.kingsquare.nl (Postfix) with ESMTP id DAAA84343E0

   for ; Tue, 16 Sep 2008 23:50:25 +0200 (CEST)

To: H. van der Pluijm

From: Platform Zelfstandige Ondernemers (PZO)

Reply-To: xxxxaat@xxx.nl

Subject: PZO Nieuwsspecial: Prinsjesdag 2008: Zorgen over koopkracht z

elfstandigen

Date: Tue, 16 Sep 2008 23:49:44 +0200

X-Mailer: Swift 3.1.0_4

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="_=_swift-110173344148d029ff48d673.82684298_=_"

Content-Transfer-Encoding: 7bit

Message-Id: <20080916215025.DAAA84343E0@lb01.xxxx.nl>

Return-Path: xxxx@xxx.nl

X-OriginalArrivalTime: 16 Sep 2008 21:50:26.0787 (UTC) FILETIME=[3AAB9330:01C91846]

 

 

 

Kun je mij uitleggen hoe ik die headers kan veranderen zonder daarvoor eerst een speciaal programma te bouwen?

 

Eerste hit op Google: http://www.cert.org/tech_tips/email_spoofing.html

 

Want het gaat er bij authenticate niet om dat het 100 procent waterdicht is. Dat is niets. Handtekeningen zijn ook te vervalsen.

 

Geen enkel systeem is waterdicht. Maar er zit een groot gat tussen e-mail headers en digitale handtekeningen. Zie digitale handtekening als een goed slot op de deur, en e-mail headers als het ontbreken van muren.

 

 

[Maarten]

Het gaat mij er om dat er in een binnengekomen email een heel pad in staat, inclusief IP-nummers en codes.

Dat is alleen aan de kant van de ontvanger te vervalsen, niet aan de kant van de afzender. En zelfs aan de kant van de ontvanger is dat een klus waarvan 99,99 procent geen idee heeft hoe dat moet. Een handtekening vervalsen is makkelijker.

 

Er zit geen enkele controle op de headers. Elke mailserver die mail ontvangt voegt gewoon zijn eigen header toe en controleert niet de eerder toegevoegde headers. De 99,99 % slaat nergens op, iedereen met een beetje technische kennis kan headers vervalsen. Dat jij niet weet hoe het moet, betekend niet dat anderen het ook niet weten.

 

En internet providers die mail verplicht moeten bewaren? Sorry?

[willemj]

Er ligt dus een overeenkomst aan ten grondslag. En de wederzijdse boekhoudingen maken e.e.a. verifeerbaar.

 

In de originele vraag gaat het om een leverancier die failliet is. Even aangenomen dat het faillisement afgerond is is de administratie dan uberhaupt nog te achterhalen?

[Henny van der Pluijm]

Je komt steeds met informatie die op geen enkele manier de vraag beantwoordt hoe een zender of ontvanger het pad van een email kunnen veranderen. Dat is waar ik mee kwam.

 

Als het er om gaat om de authenticiteit van een mailtje te controleren, is dat waar het om gaat.

 

Spam uitgezonderd, maar daar hebben we het hier niet over.

 

 

Het gaat mij er om dat er in een binnengekomen email een heel pad in staat, inclusief IP-nummers en codes.

Dat is alleen aan de kant van de ontvanger te vervalsen, niet aan de kant van de afzender. En zelfs aan de kant van de ontvanger is dat een klus waarvan 99,99 procent geen idee heeft hoe dat moet. Een handtekening vervalsen is makkelijker.

 

Er zit geen enkele controle op de headers. Elke mailserver die mail ontvangt voegt gewoon zijn eigen header toe en controleert niet de eerder toegevoegde headers. De 99,99 % slaat nergens op, iedereen met een beetje technische kennis kan headers vervalsen.

 

Dat lijkt me een overbodige sneer. Ik heb je al gevraagd hoe dat dan moet, maar ik krijg geen antwoord.

 

Doe nog eens een poging.

 

Dat jij niet weet hoe het moet, betekend niet dat anderen het ook niet weten.

 

En internet providers die mail verplicht moeten bewaren? Sorry?

[Maarten]

Je komt steeds met informatie die op geen enkele manier de vraag beantwoordt hoe een zender of ontvanger het pad van een email kunnen veranderen. Dat is waar ik mee kwam.

 

Als het er om gaat om de authenticiteit van een mailtje te controleren, is dat waar het om gaat.

 

Ik kan hier een e-mail samenstellen met alle headers die ik zelf wil. Als ik dat mailtje vervolgens handmatig aanbied aan jou mailserver, voegt jou mailserver enkel nog zijn eigen header toe. Je kunt aan die laatste header wel zien welk IP-adres ik vandaan heb gemailed, maar dit voorbeeld is dan ook de meest basale manier om misbruik mee te plegen.

 

Als ontvanger kun je alles in een e-mail wijzigen wat je wil. Het zijn gewoon bestandjes die gewijzigd kunnen worden.

[Henny van der Pluijm]

Ik denk dat je het nu precies goed voorstelt, want dit kan ik dus ook en dat had ik al gezegd.

 

Maar wat jij en ik niet kunnen is de header van de mailserver zelf toevoegen. DAT is de pad-informatie waar ik het steeds over heb.

 

 

Je komt steeds met informatie die op geen enkele manier de vraag beantwoordt hoe een zender of ontvanger het pad van een email kunnen veranderen. Dat is waar ik mee kwam.

 

Als het er om gaat om de authenticiteit van een mailtje te controleren, is dat waar het om gaat.

 

Ik kan hier een e-mail samenstellen met alle headers die ik zelf wil. Als ik dat mailtje vervolgens handmatig aanbied aan jou mailserver, voegt jou mailserver enkel nog zijn eigen header toe. Je kunt aan die laatste header wel zien welk IP-adres ik vandaan heb gemailed, maar dit voorbeeld is dan ook de meest basale manier om misbruik mee te plegen.

[Hans van den Bergh]

Er ligt dus een overeenkomst aan ten grondslag. En de wederzijdse boekhoudingen maken e.e.a. verifeerbaar.

In de originele vraag gaat het om een leverancier die failliet is. Even aangenomen dat het faillisement afgerond is is de administratie dan uberhaupt nog te achterhalen?

Ontslaat faillisement van bewaarplicht?

 

Succès en groet,

 

Hans

[Maarten]

Maar wat jij en ik niet kunnen is de header van de mailserver zelf toevoegen. DAT is de pad-informatie waar ik het steeds over heb.

 

Je kan niets met de header van de allerlaatste mailservers, welke van degene die er voor liggen. Dat beweerde Christine ook zeer duidelijk:

 

Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

Ik begrijp dat je nu toegeeft dat ze gelijk had?

[Christine]

Kun je mij uitleggen hoe ik die headers kan veranderen zonder daarvoor eerst een speciaal programma te bouwen?

 

Als je wilt mail ik je een programmaatje waarmee je niet alleen de body maar ook de complete headers zelf kan intypen.

 

Verder kun je een mailtje maken, dan saven in b.v. mbx formaat, en dan kun je het editen met een gewone text editor, en daarna alsnog versturen. In outlook of windows mail is dat lastig omdat die obscure mailformaten gebruiken, maar in alle andere mailprogramma's moet hett wel kunnen.

[Christine]

Maar we dwalen behoorlijk af. Ik kan je ook een digitaal ondertekend en encrypt mailtje sturen in pdf formaat? Geheel gratis en voor niets? Heb ik wel je mobiele telefoonnummer nodig, voor de key.

 

 

 

 

[Henny van der Pluijm]

Maarten,

 

Volgens mij hebben zowel Christine als jij vanaf het begin niets anders beweerd dan ik zelf in mijn eerste post deed. Daarom vind ik het ook een vrij vruchteloze discussie.

 

Mijn bericht was bedoeld voor degenen die denken dat email alleen maar een emailadres, een stuktje teskt en een subject is.

 

Er zit veel meer in en een deel daarvan is afkomstig van de providers. Dus niet door de verzender te vervalsen. Gewoon een kwestie van logisch nadenken.

 

 

Maar wat jij en ik niet kunnen is de header van de mailserver zelf toevoegen. DAT is de pad-informatie waar ik het steeds over heb.

 

Je kan niets met de header van de allerlaatste mailservers, welke van degene die er voor liggen. Dat beweerde Christine ook zeer duidelijk:

 

Alle headers in het mailtje zijn vrij te veranderen door de afzender, dus op die headers kun je nooit vertrouwen. Wel op de headers die b.v. jouw mailserver of jouw provider erbij zet.

 

Ik begrijp dat je nu toegeeft dat ze gelijk had?

[Henny van der Pluijm]

Christine, dat soort dingen heb ik zelf ook gemaakt.

 

Dat is mijn punt helemaal niet.

 

Kun je mij uitleggen hoe ik die headers kan veranderen zonder daarvoor eerst een speciaal programma te bouwen?

 

Als je wilt mail ik je een programmaatje waarmee je niet alleen de body maar ook de complete headers zelf kan intypen.

 

Verder kun je een mailtje maken, dan saven in b.v. mbx formaat, en dan kun je het editen met een gewone text editor, en daarna alsnog versturen. In outlook of windows mail is dat lastig omdat die obscure mailformaten gebruiken, maar in alle andere mailprogramma's moet hett wel kunnen.

[LittleBit]

@Jan Jaap de Vries

 

Vervelend,

De formele eisen wijken idd af van wat je hier en daar aan gedrag ziet,.

Lijkt me dus een vraagje voor onze staatssecretaris van financien/belastingen.

Die zit momenteel in Kiev, Oekraïne voor een belastingverdrag.

Maar wellicht heeft hij tijd voor een messie.

Z'n antwoord zal ik hier plaatsen.

 

[Joost Rietveld]

Hoe is dit topic zo ver off topic geraakt? Andere lounge wellicht ???

[LittleBit]

@Jan Jaap de Vries

Lijkt me dus een vraagje voor onze staatssecretaris van financien/belastingen.

 

En die antwoord:

> Hi Ad,

> Ik heb een tijdje geleden bij de Belastingdienst uitgezet om wat te doen aan electronisch factureren,

> veel is nu al mogelijk (!) maar er zijn nog vaak onduidelijkheden of onbekendheid met de mogelijkheden.

> We zijn dus nu aan het werken om duidelijkheid te scheppen, incl. het nog verder gaande gebruik van bijv UBL

> waardoor je niet alleen electronisch factureert maar ook de verwerking bij de ontvangende partij

> geheel automatisch kan geschieden.

> Groetjes Jan Kees de Jager

 

[Christine]

Als standaard voor de uitwisseling van bedrijfsinformatie is gekozen voor XBRL

 

Er lopen twee discussies door elkaar. Je hebt enerzijds elektronisch factureren als het uitwisselen van factuur-informatie tussen systemen zodat facturen automatisch verwerkt worden, en anderzijds de geldigheid van een elektronische factuur door b.v. een elektronische handtekening. Die twee dingen kunnen los staan van elkaar. Je kunt facturen in XML uitwisselen zonder elektronische handtekening, en je kunt facturen elektronisch ondertekenen zonder dat ze automatisch verwerkt kunnen worden. In het eerste geval moet je er alsnog een papieren factuur overheen sturen, in het andere geval moet je de factuur alsnog overtypen in je eigen boekhouding. Alleen als een xml bericht ook op valide wijze is ondertekend, past het samen.

 

[Joost Diepenmaat2]

Als standaard voor de uitwisseling van bedrijfsinformatie is gekozen voor XBRL

 

Toch moet ook niet de verwarring ontstaan dat XBRL de standaard voor digitale facturatie zal worden. De staatssecretaris heeft onlangs gekozen om met UBL 2.0 van start te gaan. Gelukkig maar, gezien de potentie die deze standaard absoluut heeft wat betreft volwassenheid. XBRL kent veel toepassingen in de fiscale hoek, echter biedt UBL 2.0 ook ondersteuning voor zogenaamde sourcing (inkoop organisaties) en fulfilment processen. Daarnaast is het internationaal opgezet en meet het zich aan de regelgeving van Europa.