Interpretacja indywidualna
Sygnatura: IPPP1/443-431/12-2/EK
Organ: Dyrektor Izby Skarbowej w Warszawie
Data wydania: 2012-07-17
Teza: Uznanie faktur przesyłanych w pliku w formie XML lub innym formacie tekstowym za faktury elektroniczne.
Słowa kluczowe: faktura; faktura-faktura elektroniczna
Przepisy: [VAT][WIS] Ustawa o podatku od towarów i usług-Dział XI-Rozdział 1-art. 108

INTERPRETACJA INDYWIDUALNA

Na podstawie art. 14b § 1 i § 6 ustawy z dnia 29 sierpnia 1997 r. Ordynacja podatkowa (t. j. Dz. U. z 2012 r. poz. 749) oraz § 7 rozporządzenia Ministra Finansów z dnia 20 czerwca 2007 r. w sprawie upoważnienia do wydawania interpretacji przepisów prawa podatkowego (Dz. U. z 2007 r. Nr 112, poz. 770 ze zm.) Dyrektor Izby Skarbowej w Warszawie działając w imieniu Ministra Finansów stwierdza, że stanowisko Spółki, przedstawione we wniosku z dnia 16.05.2012 r.(data wpływu 21.05.2012 r.), o udzielenie pisemnej interpretacji przepisów prawa podatkowego dotyczącej podatku od towarów i usług w zakresie uznania faktur przesyłanych w pliku w formacie XML lub innym formacie tekstowym za faktury elektroniczne (pytanie oznaczone we wniosku nr 1 )- **jest prawidłowe.**

UZASADNIENIE

W dniu 21.05.2012 r. wpłynął ww. wniosek o udzielenie pisemnej interpretacji przepisów prawa podatkowego w indywidualnej sprawie dotyczącej podatku od towarów i usług w zakresie uznania faktur przesyłanych w pliku w formacie XML lub innym formacie tekstowym za faktury elektroniczne (pytanie oznaczone we wniosku nr 1).

W przedmiotowym wniosku zostało przedstawione następujące zdarzenie przyszłe:

Spółka S.A. (dalej: „Spółka” lub „Wnioskodawca”) jest wykonawcą robót budowlanych w ramach realizacji różnych projektów budowlanych. W związku z przewidzianą przez przepisy prawa możliwością przesyłania faktur w formie elektronicznej Spółka rozważa wyrażenie akceptacji na otrzymywanie faktur zakupowych w formie elektronicznej zgodnie z § 3 rozporządzenia Ministra Finansów z dnia 17 grudnia 2010 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz.U. 10.249.1661) (dalej: „Rozporządzenie”). W związku z powyższym Wnioskodawca zamierza wprowadzić jednolite zasady postępowania z zakupowymi fakturami elektronicznymi, które co do zasady będą stosowane w stosunku do wszystkich kontrahentów Spółki, którzy wyrażą wolę wystawiania i przesyłania faktur w formie elektronicznej. Zasadnicze wątpliwości Spółki sprowadzają się do oceny czy przyjęta przez Spółkę procedura postępowania z zakupowymi fakturami elektronicznymi oraz stosowane rozwiązania informatyczne zapewniają autentyczność pochodzenia i integralność treści faktury w rozumieniu § 2 Rozporządzenia. Wnioskodawca rozważa wprowadzenie kilku wariantów postępowania z zakupowymi fakturami elektronicznymi, mianowicie:

Wariant nr 1:

Kontrahenci Spółki - za pośrednictwem sieci Internet - będą przesyłać faktury elektroniczne w formacie XML lub innym formacie tekstowym np. txt na Web-serwer stworzony i obsługiwany przez Wnioskodawcę (dalej: „Serwer”). Serwer będzie zabezpieczony protokołem SSL dostarczanym przez niezależny podmiot zewnętrzny, który posiada status urzędu zaufania - Certification Authority (CA) i jest profesjonalną firmą świadczącą usługi bezpiecznej wymiany i weryfikacji danych. Dostawca protokołu SSL będzie jednym z podmiotów wpisanych do rejestru kwalifikowanych podmiotów świadczących usługi certyfikacyjne, o którym mowa w art. 30 ust. 2 pkt 1 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym. Wnioskodawca wskazuje, że protokół SSL odpowiada za dwie kluczowe czynności: szyfruje dane pomiędzy warstwą transportu, a warstwą aplikacji TCP oraz autoryzuje tożsamość serwera względem klienta. Każdy kontrahent Spółki, który zgodzi się na przesyłanie faktur w drodze elektronicznej otrzyma od Spółki indywidualny login i hasło, które będzie używane do uwierzytelnionego logowania się na Serwer Spółki. Zatem za każdym razem, gdy kontrahent Spółki będzie chciał przesłać Wnioskodawcy fakturę elektroniczną będzie musiał zalogować się na Serwer Wnioskodawcy i umieścić tam wystawioną przez siebie fakturę. W ten sposób Spółka zapewni autentyczność pochodzenia faktury, gdyż będzie zawsze posiadała informację o tym od jakiego podmiotu pochodzą faktury umieszczone na Serwerze Spółki. Następnie Serwer będzie automatycznie generował informację do kontrahenta, który umieścił fakturę na Serwerze w formie wiadomości tekstowej SMS lub w formie wiadomości e-mail z prośbą o potwierdzenie danych zawartych w fakturze VAT umieszczonej na serwerze Wnioskodawcy. Informacja generowana przez Serwer będzie zawierała unikalne hasło jednorazowe. W celu potwierdzenia danych zawartych w fakturze VAT kontrahenci będą zobowiązani do wpisania otrzymanego hasła jednorazowego w systemie Serwera. Moment potwierdzenia danych hasłem jednorazowym będzie automatycznie zapisywany na Serwerze. Po potwierdzeniu przez kontrahentów Spółki prawidłowości danych zawartych w fakturze VAT, system Korab, będący systemem finansowo-księgowym używanym przez Spółkę (dalej: „System”) będzie automatycznie wprowadzał (zaczytywał) faktury do własnej bazy danych. Dopiero po potwierdzeniu przez kontrahenta danych zawartych w fakturze (przez wpisanie hasła jednorazowego) Wnioskodawca będzie miał możliwość zapoznania się z jej zawartością.

Brak potwierdzenia przez kontrahenta danych zawartych w fakturze umieszczonej na Serwerze będzie oznaczał, że faktura nie wpłynęła do Wnioskodawcy (tym samym nie rozpoczął się bieg terminu prawa do odliczenia VAT naliczonego). Procedura potwierdzania danych zawartych w fakturze przez kontrahentów Spółki ma na celu zapewnienie integralności danych zawartych w tej fakturze. W istocie chodzi o zapewnienie, że dane zawarte w pliku XML lub innym pliku tekstowym (np. txt) umieszczonym na Serwerze przez kontrahentów Spółki nie zostały zmodyfikowane przez jakikolwiek podmiot trzeci. Z kolei automatyzacja wprowadzania/zaczytywania danych przez System ma na celu przyspieszenie obsługi faktur oraz wyeliminowanie ryzyka błędu ludzkiego, które istnieje w przypadku ręcznego wprowadzania danych zawartych w fakturze do systemu finansowo-księgowego Spółki przez jej pracowników lub przez pracowników podmiotu, któremu Spółka zleca takie czynności. Spółka wskazuje, że ze względu na różne rozwiązania informatyczne stosowany przez jej kontrahentów obraz e-faktury znajdujący się w systemie Wnioskodawcy może różnić się szatą graficzną lub formatem od obrazów e-faktur znajdujących się u jej kontrahentów. Spółka zastrzega jednak, że zachowana zostanie integralność treści faktury. Dodatkowo Spółka wskazuje, że faktury będą przechowywane na Serwerze Spółki i archiwizowane zgodnie z Rozporządzeniem, w taki sposób, aby było możliwe odszukanie konkretnych danych przy zastosowaniu różnych kryteriów (okres rozliczeniowy, kontrahent itp.). Spółka zaznacza, że w tym wariancie nie planuje wykorzystywania ani bezpiecznego podpisu elektronicznego w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450, ze zm), weryfikowanego za pomocą ważnego kwalifikowanego certyfikatu, ani elektronicznej wymiany danyh (EDI) zgodnie z umową w sprawie europejskiego modelu wymiany danych elektronicznych.

Wariant nr 2:

Wariant nr 2 zawiera analogiczne rozwiązania jak wariant nr 1 z następującymi różnicami. Serwer nie będzie generował do kontrahentów Spółki, którzy umieścili fakturę na Serwerze informacji w formie wiadomości tekstowej SMS, a jedynie w formie wiadomości e-mail z prośbą o potwierdzenie danych zawartych w fakturze VAT umieszczonej na Serwerze Wnioskodawcy. Integralność danych zawartych w fakturze VAT zapewniona będzie przez stosowany przez Spółkę certyfikat autoryzacji polegający na generowaniu funkcji skrótu. Mechanizm polega na tym, że po umieszczeniu przez kontrahenta faktury na Serwerze Wnioskodawcy generowana będzie automatycznie wiadomość e-mail do upoważnionej osoby wskazanej przez kontrahenta zawierająca dane z funkcji skrótu (funkcja skrótu zapewnia integralność danych zawartych w pliku poprzez sprawdzenie czy nie została zmieniona treść danych w pliku). Jedyne co musi zrobić osoba autoryzująca faktury, którą wskazał kontrahent to kliknąć w zawarty w treści wiadomości e-mail linki i potwierdzić porównanie funkcji skrótu. Działanie to odbywać się będzie automatycznie bez dodatkowego logowania się czy wpisywania kodów PIN. Moment potwierdzenia porównania funkcji skrótu będzie automatycznie zapisywany na Serwerze. Jedynie te pliki, które zostaną potwierdzone przez kontrahenta w powyższy sposób będą mogły być zaczytane do systemu Serwera, co oznacza, że Wnioskodawca będzie mógł zapoznać się z ich treścią. Brak potwierdzenia przez kontrahenta porównania funkcji skrótu będzie oznaczał, że faktura nie wpłynęła do Wnioskodawcy (tym samym nie rozpoczął się bieg terminu prawa do odliczenia VAT naliczonego). Spółka podkreśla, że nie będzie miała możliwości zapoznania się z treścią faktury, która nie zostanie potwierdzona przez kontrahenta. Dostawcą rozwiązania umożliwiającego porównanie funkcji skrót będzie Wnioskodawca. Po zaczytaniu pliku XML do systemu Serwera będzie istniała możliwość wygenerowania podglądu e-faktury (np. w formacie PDF). Spółka wskazuje, że ze względu na różne rozwiązania informatyczne stosowane przez jej kontrahentów obraz e-faktury znajdujący się w systemie Wnioskodawcy może różnić się szatą graficzną lub formatem od obrazów e-faktur znajdujących się u jej kontrahentów. Spółka zastrzega jednak, że zachowana zostanie integralność treści faktury. Dodatkowo Spółka wskazuje, że faktury będą przechowywane na Serwerze Spółki i archiwizowane zgodnie z Rozporządzeniem, w taki sposób, aby było możliwe odszukanie konkretnych danych przy zastosowaniu różnych kryteriów (okres rozliczeniowy, kontrahent itp.). Wnioskodawca zaznacza, że w tym wariancie nie planuje wykorzystywania ani bezpiecznego podpisu elektronicznego w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450, z późn. zm.), weryfikowanego za pomocą ważnego kwalifikowanego certyfikatu, ani elektronicznej wymiany danych (EDI) zgodnie z umową w sprawie europejskiego modelu wymiany danych elektronicznych. Zdaniem Spółki oba rozwiązania spełniają wymagania, o których mowa w przepisach Rozporządzenia, gdyż zapewniają:

1.  Autentyczność pochodzenia faktury - serwer WWW zapewnia możliwość zakładania kont wyłącznie osobom upoważnionym przez kontrahenta, które będą się identyfikować poprzez unikalny login i hasło. Poprzez zaimplementowanie certyfikatu opartego o protokół SSL kontrahent będzie miał pewność, że Wnioskodawca jest podmiotem za który się podaje. Weryfikacji Wnioskodawcy dokona niezależny podmiot mający status urzędu zaufanego w zakresie wystawiania bezpiecznych certyfikatów szyfrujących dane.
2.  Integralność treści faktury - poprzez zapewnienie szyfrowanej transmisji danych z wykorzystaniem protokołu SSL i klucz szyfrującego o sile szyfrowania co najmniej 128 lub 256 bitów. Szyfrowanie transmisji wprowadza zabezpieczenie przed utratą integralności danych podczas przesyłania pliku, będącego fakturą z wykorzystaniem Internetu. Dodatkowa weryfikacja polegająca na wprowadzeniu porównania funkcji skrótu dostarcza potwierdzenia integralności pliku (danych, informacji) i świadczy o tym, że dane w samym pliku nie uległy zmianie od momentu umieszczenia ich na serwerze Wnioskodawcy. Kontrahent posiada wiadomość e-mail z zaszyfrowanym linkiem, po kliknięciu na który potwierdza i porównuje tożsamość (następuje to przez poprzez porównanie funkcji skrótu). Działanie takie chroni nie tylko samą treść dokumentu, ale dodatkowo wprowadza mechanizm potwierdzania momentu wpływu faktury. Dopiero bowiem w momencie, w którym kontrahent potwierdził porównanie funkcji skrótu przez kliknięcie w link zawarty w treści wiadomości e-mail Wnioskodawca uzyskuje możliwość zapoznania się z treścią faktury. Dla Wnioskodawcy jest to moment, w którym powstaje prawo do odliczenia VAT.

Należy zaznaczyć, że mechanizmy opisane w obu wariantach posiadają elementy potwierdzenia autentyczności podmiotów wobec siebie (Kontrahenci - konta dla użytkowników z indywidualnymi loginami i hasłami, Wnioskodawca - weryfikacja poprzez niezależną jednostkę urzędu zaufania i wykorzystanie protokołu SSL) tak ważne z punktu widzenia elektronicznej wymiany danych dla obu stron. Ponadto wprowadzony mechanizm integracji danych w momencie ich przesyłania (szyfrowanie transmisji poprzez protokół SSL) jak i w momencie ich przekazania do rozliczenia (generowanie funkcji skrótu) w systemie finansowo - księgowym Wnioskodawcy (system Korab) zapewnia brak możliwości utraty integralności informacji.

W związku z powyższym zadano następujące pytania:

1.  Czy pliki w formacie XML lub innym formacie tekstowym otrzymywane przez Spółkę stanowią faktury przesyłane w formie elektronicznej w rozumieniu art. 106 ust. 10 i 11 ustawy z dnia 11 marca 2004 r. o podatku od towarów i sług (Dz.U. Nr 54, poz. 535, ze zm.) oraz rozporządzenia Ministra Finansów z dnia 17 grudnia 2010 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu trybu udostępniania organowi podatkowemu lub organom kontroli skarbowej (Dz.U. 10.249.1661)?

W ocenie Wnioskodawcy pliki w formacie XML lub innym formacie tekstowym otrzymywane od Kontrahentów Spółki stanowią faktury przesyłane w formie elektronicznej w rozumieniu rozporządzenia Ministra Finansów z dnia 17 grudnia 2010 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz.U.10.249.1661).

Zgodnie z § 1 Rozporządzenia określa ono:

1.  sposób i warunki przesyłania faktur w formie elektronicznej;
2.  zasady przechowywania oraz tryb udostępniania organowi podatkowemu lub organowi kontroli skarbowej faktur przesyłanych drogą elektroniczną.

Z kolei na podstawie § 2 ust. 1 przez autentyczność pochodzenia faktury - rozumie się pewność co do tożsamości dokonującego dostawy towarów lub usługodawcy albo wystawcy faktury. Natomiast przez integralność treści faktury - rozumie się to, że w fakturze nie zmieniono danych, które powinna zawierać faktura.

Ponadto na podstawie § 3 ust. 1 faktury mogą być przesyłane, w tym udostępniane, w formie elektronicznej w dowolnym formacie elektronicznym, pod warunkiem uprzedniej akceptacji tego sposobu przesyłania faktur przez odbiorcę faktury, zwanej dalej „akceptacją”. Zgodnie z § 4 Rozporządzenia faktury mogą być przesyłane w formie elektronicznej od warunkiem zapewnienia autentyczności pochodzenia i integralności treści faktury.

Analiza powyższych przepisów prowadzi do wniosku, że dla ustawodawcy nie ma znaczenia format elektroniczny w jakim przesyłane, w tym udostępniane są faktury elektroniczne, co zostało wprost wyrażone w § 3 ust. 1 Rozporządzenia. Ustawodawca jednoznacznie wskazuje, że warunkiem przesyłania faktur w formie elektronicznej jest zapewnienie autentyczności pochodzenia i integralności treści faktury.

Z powyższego wynika, że konwersja formatu elektronicznego faktury (np. z formatu PDF na XML, czy XML na PDF) nie narusza ani integralności treści faktury, ani autentyczności jej pochodzenia. Systemy informatyczne nie ingerują bowiem w treść faktury, lecz zmieniają jedynie jej format elektroniczny, w celu umożliwienia przetworzenia zawartych w niej danych dla potrzeb systemów finansowo-księgowych. Jednocześnie systemy informatyczne zawierają rozwiązania, które zapewniają integralność treści faktury oraz autentyczność jej pochodzenia.

Podsumowując, w ocenie Spółki pliki w formacie XML lub innym formacie tekstowym otrzymywane od jej Kontrahentów stanowią faktury przesyłane w formie elektronicznej w rozumieniu rozporządzenia Ministra Finansów z dnia 17 grudnia 2010 r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz.U. 10.249.1661)

W świetle obowiązującego stanu prawnego stanowisko wnioskodawcy w sprawie oceny prawnej przedstawionego zdarzenia przyszłego uznaje się za prawidłowe.

Zgodnie z art. 106 ust. 1 ustawy z dnia 11 marca 2004 r. o podatku od towarów i usług (t.j. Dz. U. z 2012r., Nr 177, poz. 1054), podatnicy, o których mowa w art. 15, są obowiązani wystawić fakturę stwierdzającą w szczególności dokonanie sprzedaży, datę dokonania sprzedaży, cenę jednostkową bez podatku, podstawę opodatkowania, stawkę i kwotę podatku, kwotę należności oraz dane dotyczące podatnika i nabywcy, z zastrzeżeniem ust.1a, 2, 4 i 5 oraz art. 119 ust. 10 i art. 120 ust. 6.

Sposób i warunki przesyłania oraz przechowywania faktur w formie elektronicznej reguluje rozporządzenie Ministra Finansów z dnia 17 grudnia 2010r. w sprawie przesyłania faktur w formie elektronicznej, zasad ich przechowywania oraz trybu udostępniania organowi podatkowemu lub organowi kontroli skarbowej (Dz. U. Nr 249 poz. 1661) wydane na podstawie delegacji zawartej w art. 106 ust. 10 i 11 ustawy o VAT.

W myśl § 3 ust. 1 i ust. 2 ww. rozporządzenia, faktury mogą być przesyłane, w tym udostępniane, w formie elektronicznej w dowolnym formacie elektronicznym, pod warunkiem uprzedniej akceptacji tego sposobu przesyłania faktur przez odbiorcę faktury, zwanej dalej "akceptacją". Akceptacja albo jej cofnięcie może być wyrażona w formie pisemnej lub w formie elektronicznej.

Zgodnie z § 4 ww. rozporządzenia, faktury mogą być przesyłane w formie elektronicznej pod warunkiem zapewnienia autentyczności pochodzenia i integralności treści faktury.

Pojęcia: autentyczność pochodzenia faktury i integralność jej treści definiuje § 2 ust. 1 cyt. rozporządzenia. I tak przez :

1.  autentyczność pochodzenia faktury rozumie się pewność co do tożsamości dokonującego dostawy towarów lub usługodawcy albo wystawcy faktury;
2.  integralność treści faktury rozumie się, że w fakturze nie zmieniono danych, które powinna zawierać faktura.

Stosownie do § 2 ust. 2 cyt. rozporządzenia, autentyczność pochodzenia i integralność treści faktury są zachowane, w szczególności, w przypadku wykorzystania:

1.  bezpiecznego podpisu elektronicznego w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001r. o podpisie elektronicznym (Dz. U. nr 130, poz. 1450, z późn. zm.), weryfikowanego za pomocą ważnego kwalifikowanego certyfikatu, lub
2.  elektronicznej wymiany danych (EDI) zgodnie z umową w sprawie europejskiego modelu wymiany danych elektronicznych, jeżeli zawarta umowa, dotycząca tej wymiany, przewiduje stosowanie procedur gwarantujących autentyczność pochodzenia faktury i integralność jej danych.

Wymienione metody zapewnienia przedmiotowych cech faktur są tylko przykładowym wyliczeniem, co oznacza, że podatnik będzie mógł zastosować inne, dowolne środki zapewnienia autentyczności i integralności faktury, w tym m.in. przesyłania faktur w formie pliku PDF stanowiącego załącznik do e-maila skierowanego do odbiorcy faktury.

W świetle powyższego należy stwierdzić, iż za fakturę elektroniczną należy uznać taki dokument, co do którego zapewniona jest tożsamość wystawcy (sprzedawcy) oraz nienaruszalność treści oraz został przesłany drogą elektroniczną po uprzedniej akceptacji odbiorcy (nabywcy), co do takiej formy przesyłania faktur.

Z okoliczności przedstawionych przez Wnioskodawcę wynika, iż Wnioskodawca rozważa wyrażenie akceptacji na otrzymywanie faktur zakupowych w formie elektronicznej. Wnioskodawca rozważa wprowadzenie następujących wariantów postępowania z zakupowymi fakturami elektronicznymi. W wariancie nr 1 kontrahenci Spółki - za pośrednictwem sieci Internet - będą przesyłać faktury elektroniczne w formacie XML lub innym formacie tekstowym np. txt na Web-serwer stworzony i obsługiwany przez Wnioskodawcę (dalej: „Serwer”). Serwer będzie zabezpieczony protokołem SSL dostarczanym przez niezależny podmiot zewnętrzny, który posiada status urzędu zaufania - Certification Authority (CA) i jest profesjonalną firmą świadczącą usługi bezpiecznej wymiany i weryfikacji danych. Dostawca protokołu SSL będzie jednym z podmiotów wpisanych do rejestru kwalifikowanych podmiotów świadczących usługi certyfikacyjne, o którym mowa w art. 30 ust. 2 pkt 1 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym. Wnioskodawca wskazuje, że protokół SSL odpowiada za dwie kluczowe czynności: szyfruje dane pomiędzy warstwą transportu, a warstwą aplikacji TCP oraz autoryzuje tożsamość serwera względem klienta. Każdy kontrahent Spółki, który zgodzi się na przesyłanie faktur w drodze elektronicznej otrzyma od Spółki indywidualny login i hasło, które będzie używane do uwierzytelnionego logowania się na Serwer Spółki. Zatem za każdym razem, gdy kontrahent Spółki będzie chciał przesłać Wnioskodawcy fakturę elektroniczną będzie musiał zalogować się na Serwer Wnioskodawcy i umieścić tam wystawioną przez siebie fakturę. W ten sposób Spółka zapewni autentyczność pochodzenia faktury, gdyż będzie zawsze posiadała informację o tym od jakiego podmiotu pochodzą faktury umieszczone na Serwerze Spółki. Następnie Serwer będzie automatycznie generował informację do kontrahenta, który umieścił fakturę na Serwerze w formie wiadomości tekstowej SMS lub w formie wiadomości e-mail z prośbą o potwierdzenie danych zawartych w fakturze VAT umieszczonej na serwerze Wnioskodawcy. Informacja generowana przez Serwer będzie zawierała unikalne hasło jednorazowe. W celu potwierdzenia danych zawartych w fakturze VAT kontrahenci będą zobowiązani do wpisania otrzymanego hasła jednorazowego w systemie Serwera. Moment potwierdzenia danych hasłem jednorazowym będzie automatycznie zapisywany na Serwerze. Po potwierdzeniu przez kontrahentów Spółki prawidłowości danych zawartych w fakturze VAT, system Korab, będący systemem finansowo-księgowym używanym przez Spółkę (dalej: „System”) będzie automatycznie wprowadzał (zaczytywał) faktury do własnej bazy danych. Dopiero po potwierdzeniu przez kontrahenta danych zawartych w fakturze (przez wpisanie hasła jednorazowego) Wnioskodawca będzie miał możliwość zapoznania się z jej zawartością.

Brak potwierdzenia przez kontrahenta danych zawartych w fakturze umieszczonej na Serwerze będzie oznaczał, że faktura nie wpłynęła do Wnioskodawcy. Procedura potwierdzania danych zawartych w fakturze przez kontrahentów Spółki ma na celu zapewnienie integralności danych zawartych w tej fakturze. W istocie chodzi o zapewnienie, że dane zawarte w pliku XML lub innym pliku tekstowym (np. txt) umieszczonym na Serwerze przez kontrahentów Spółki nie zostały zmodyfikowane przez jakikolwiek podmiot trzeci. Wariant nr 2 zawiera analogiczne rozwiązania jak wariant nr 1 z następującymi różnicami. Serwer nie będzie generował do kontrahentów Spółki, którzy umieścili fakturę na Serwerze informacji w formie wiadomości tekstowej SMS, a jedynie w formie wiadomości e-mail z prośbą o potwierdzenie danych zawartych w fakturze VAT umieszczonej na Serwerze Wnioskodawcy. Integralność danych zawartych w fakturze VAT zapewniona będzie przez stosowany przez Spółkę certyfikat autoryzacji polegający na generowaniu funkcji skrótu. Mechanizm polega na tym, że po umieszczeniu przez kontrahenta faktury na Serwerze Wnioskodawcy generowana będzie automatycznie wiadomość e-mail do upoważnionej osoby wskazanej przez kontrahenta zawierająca dane z funkcji skrótu (funkcja skrótu zapewnia integralność danych zawartych w pliku poprzez sprawdzenie czy nie została zmieniona treść danych w pliku). Jedyne co musi zrobić osoba autoryzująca faktury, którą wskazał kontrahent to kliknąć w zawarty w treści wiadomości e-mail linki i potwierdzić porównanie funkcji skrótu. Działanie to odbywać się będzie automatycznie bez dodatkowego logowania się czy wpisywania kodów PIN. Moment potwierdzenia porównania funkcji skrótu będzie automatycznie zapisywany na Serwerze. Jedynie te pliki, które zostaną potwierdzone przez kontrahenta w powyższy sposób będą mogły być zaczytane do systemu Serwera, co oznacza, że Wnioskodawca będzie mógł zapoznać się z ich treścią. Brak potwierdzenia przez kontrahenta porównania funkcji skrótu będzie oznaczał, że faktura nie wpłynęła do Wnioskodawcy. Spółka podkreśla, że nie będzie miała możliwości zapoznania się z treścią faktury, która nie zostanie potwierdzona przez kontrahenta. Dostawcą rozwiązania umożliwiającego porównanie funkcji skrót będzie Wnioskodawca. Po zaczytaniu pliku XML do systemu Serwera będzie istniała możliwość wygenerowania podglądu e-faktury (np. w formacie PDF). Spółka wskazuje, iż zarówno w wariancie 1 jaki i wariancie 2, ze względu na różne rozwiązania informatyczne stosowane przez jej kontrahentów obraz e-faktury znajdujący się w systemie Wnioskodawcy może różnić się szatą graficzną lub formatem od obrazów e-faktur znajdujących się u jej kontrahentów. Spółka zastrzega jednak, że zachowana zostanie integralność treści faktury. Dodatkowo Spółka wskazuje, że faktury będą przechowywane na Serwerze Spółki i archiwizowane zgodnie z Rozporządzeniem, w taki sposób, aby było możliwe odszukanie konkretnych danych przy zastosowaniu różnych kryteriów (okres rozliczeniowy, kontrahent itp.). Spółka zaznacza, że w ww. wariantach nie planuje wykorzystywania ani bezpiecznego podpisu elektronicznego w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. Nr 130, poz. 1450, ze zm,4), weryfikowanego za pomocą ważnego kwalifikowanego certyfikatu, ani elektronicznej wymiany danyh (EDI) zgodnie z umową w sprawie europejskiego modelu wymiany danych elektronicznych. Zdaniem Spółki oba rozwiązania zapewniają autentyczność pochodzenia faktury oraz integralność treści faktury.

Mając na uwadze powołane przepisy prawa należy stwierdzić, że obecnie obowiązujące regulacje prawne dopuszczają możliwość przesyłania faktur elektronicznie, w postaci pliku XML lub w innym formacie testowym. Biorąc pod uwagę przedstawione zdarzenie przyszłe, stwierdzić zatem należy, iż otrzymywanie na serwer Spółki faktur w formie pliku XML bądź w innym formacie tekstowym, w sposób zapewniający autentyczność pochodzenia oraz integralność treści tych faktur, jak wskazuje Wnioskodawca, w sytuacji gdy Spółka wyraziła akceptację co do takiego sposobu przesyłania faktur, jest zgodne z przepisami ustawy o podatku od towarów i usług oraz rozporządzenia z dnia 17 grudnia 2010r. i równoważne w skutkach podatkowych z przesłaniem (otrzymaniem) faktury w formie papierowej.

Tym samym stanowisko Wnioskodawcy w powyższym zakresie należało uznać za prawidłowe.

Powyższe rozstrzygniecie wydano w oparciu o przedstawiony przez Wnioskodawcę opis zdarzenia przyszłego, w którym Spółka wskazała, że przyjęty przez Nią system otrzymywania faktur drogą elektroniczną pozwoli na spełnienie wymogów określonych w powołanych § 4 i § 6 ww. rozporządzenia Ministra Finansów z dnia 17 grudnia 2010r. Ocena kryteriów technicznych w zakresie zapewnienia integralności otrzymanych przez Spółkę faktur nie jest rolą tut. Organu. Powyższe znajduje potwierdzenie w orzeczeniu Wojewódzkiego Sądu Administracyjnego w Warszawie z dnia 7 kwietnia 2011r. sygn. akt III SA/Wa 1779/11.

Jednocześnie tut. Organ informuje, iż niniejsza interpretacja rozstrzyga w zakresie pytania nr 1 zawartego we wniosku, w zakresie pytania nr 2 i nr 3 zostały wydane odrębne roztrzygnięcia.

Interpretacja dotyczy zdarzenia przyszłego i stanu prawnego obowiązującego w dniu wydania interpretacji.

Stronie przysługuje prawo do wniesienia skargi na niniejszą interpretację przepisów prawa podatkowego z powodu jej niezgodności z prawem. Skargę wnosi się do Wojewódzkiego Sądu Administracyjnego w Warszawie, ul. Jasna 2/4, 00-013 Warszawa po uprzednim wezwaniu na piśmie organu, który wydał interpretację w terminie 14 dni od dnia, w którym skarżący dowiedział się lub mógł się dowiedzieć o jej wydaniu – do usunięcia naruszenia prawa (art. 52 § 3 ustawy z dnia 30 sierpnia 2002 r. Prawo o postępowaniu przed sądami administracyjnymi – t.j. Dz. U. z 2012 r. poz. 270). Skargę do WSA wnosi się (w dwóch egzemplarzach – art. 47 ww. ustawy) w terminie trzydziestu dni od dnia doręczenia odpowiedzi organu na wezwanie do usunięcia naruszenia prawa, a jeżeli organ nie udzielił odpowiedzi na wezwanie, w terminie sześćdziesięciu dni od dnia wniesienia tego wezwania (art. 53 § 2 ww. ustawy).

Skargę wnosi się za pośrednictwem organu, którego działanie lub bezczynność są przedmiotem skargi (art. 54 § 1 ww. ustawy) na adres: Izba Skarbowa w Warszawie Biuro Krajowej Informacji Podatkowej w Płocku, ul. 1-go Maja 10, 09-402 Płock.