Istota interpretacji:

1. Czy podany wyżej sposób tworzenia pliku faktury z systemu ERP firmy z wykorzystaniem programu tworzącego format EDIFACT faktury do pliku i wysłanie takiego pliku poprzez aplikacje Ecod Connectorm, a następnie jego archiwizacja w systemie serwerowym firmy będzie zgodne z wymogiem zachowania autentyczności i integralności w wymianie EDI faktur elektronicznych? 2. Dodatkowo czy sposób przechowywania w lokalnym systemie plików z uwzględnieniem ustawienia odpowiednich uprawnień zarówno dla samych plików faktur jak i możliwości uruchomienia programu autorskiego jaki programu Ecod Connector spełnią wymagania co do procesu archiwizacji i dostępu do tych dokumentów zgodnie z rozporządzeniem Ministra Finansów z dnia 14 lipca 2005 r.?

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

Firma sprzedaje swoje wyroby sieci R. Firma jest płatnikiem podatku VAT. Sieć R pragnie wymieniać faktury drogą elektroniczną w formie komunikacji EDI. Operatorem pośredniczącym jest firma C S.A.. Generalnie wyglądałoby to tak: w systemie firmy wystawiana byłaby faktura, która następnie byłaby kodowana przy użyciu programu autorskiego, do formatu EDIFACT (format używany w elektronicznej wymianie dokumentacji EDI).

Proces tworzenia pliku EDIFACT faktury z danych z systemu ERP firmy odbywałby się w sposób automatyczny tzn. wykonywałby to program autorski pobierający dane z baz programu ERP firmy. Plik taki byłby przesyłany następnie do firmy Cprzy użyciu programu Ecod Connector — to jest program firmy C, którego zadaniem byłoby przesłanie dokumentów z systemu plików firmy do systemu firmy C i dalej do systemu firmy R. Tak więc zarówno w przypadku pliku źródła powstającego w firmie dostawcy jak i dokumentu wysłanego do sieci R mamy ten sam format i de facto jest to ten sam plik faktury.

W systemie Ecod Connector widoczne byłyby statusy dotyczące poprawności przesyłu dokumentu faktury, to znaczy kiedy został on przesłany i czy dotarł do systemu odbiorcy czyli systemu sieci Real oraz czy był poprawny co do formatu EDIFACT stosowanego w EDI łącznie, z datami wystąpienia tych zdarzeń.

Dokumenty te przechowywane byłyby na serwerze firmy w katalogach zabezpieczonych, do których dostęp mieliby użytkownicy poprzez login i hasło.

Zmiana plików EDIFACT faktur byłaby niemożliwa, gwarantowałyby to odpowiednie serwerowe uprawnienia. Aplikacja Ecod Connector oprócz wglądu w status dotyczący przesłanego dokumentu pozwalałaby taki plik dokumentu faktury w formacie EDIFACT wyświetlić na ekran monitora i wydrukować. Oczywiście dostęp do programu byłby zabezpieczony hasłem i loginem i tylko w ten sposób można byłoby taki program uruchomić. Nie byłoby możliwości dostępu zdalnego do tego programu, w sensie dostępu przez sieć Internet.

Zabezpieczeniami pliku faktury przechowywanego na serwerze firmy byłyby uprawnienia nadawane wybranym użytkownikom, jednak bez możliwości zmian w już utworzonych i przesłanych plikach EDIFACT faktur.

Pliki EDIFACT wysłanych faktur byłyby codziennie archiwizowane na nośnikach strimerowych czyli taśmowych i przechowywane w bezpiecznym sejfie.

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

1. Czy podany wyżej sposób tworzenia pliku faktury z systemu ERP firmy z wykorzystaniem programu tworzącego format EDIFACT faktury do pliku i wysłanie takiego pliku poprzez aplikacje Ecod Connectorm, a następnie jego archiwizacja w systemie serwerowym firmy będzie zgodne z wymogiem zachowania autentyczności i integralności w wymianie EDI faktur elektronicznych...
2. Dodatkowo czy sposób przechowywania w lokalnym systemie plików z uwzględnieniem ustawienia odpowiednich uprawnień zarówno dla samych plików faktur jak i możliwości uruchomienia programu autorskiego jaki programu Ecod Connector spełnią wymagania co do procesu archiwizacji i dostępu do tych dokumentów zgodnie z rozporządzeniem Ministra Finansów z dnia 14 lipca 2005 r....

Zdaniem Wnioskodawcy, zgodnie z rozporządzeniem z 14 lipca 2005 r. w sprawie wystawiania oraz przesyłania faktur w formie elektronicznej, a także przechowywania oraz udostępniania organowi podatkowemu lub organowi kontroli skarbowej tych faktur, przedstawiony sposób generowania, przesyłania, a następnie archiwizowania wysłanych faktur, spełni wymagania ww. rozporządzenia.

Firmy pośredniczące w komunikacji EDI każą sobie płacić ok. 1200 zł. na miesiąc za archiwizacje faktur elektronicznych. Przy uwzględnieniu rocznych umów firmy, przy ewentualnym nie podpisaniu umowy na kolejne lata i tak firma musiałaby przechowywać wystawione faktury przez okres 5 lat, ponosząc koszty archiwizacji. Aby uniezależnić się od pośrednika Spółka pragnie częściowo, wykorzystać swoje systemy i oprogramowanie aby taki proces komunikacji EDI przeprowadzić.

Tworząc plik faktury zgodny z formatem EDIFACT następnie wysyłając ten plik przy użyciu aplikacji Ecod Connectop firmy C do systemu odbiorcy i archiwizując w serwerowym systemie plików. Program Ecod Connector byłby wykorzystany także jako program dostępu do informacji na temat przetworzenia danego pliku faktury tzn. jego statusu dodarcia do systemu odbiorcy jak i możliwości podglądu zawartości pliku faktury z możliwością jego wydruku. W programie widoczne byłyby daty wysłania dokumentu oraz jego odbioru przez system odbiorcy.

Pliki faktur wysłane tym programem byłyby przechowywane w systemie plików serwera i odpowiednio zabezpieczone przed możliwością ich zmian (uprawnienia tylko do odczytu, hasła i loginy dostępu do folderu z plikami faktur dla użytkowników). Pliki te byłyby codziennie archiwizowane w napędzie taśmowymi i przechowywane w bezpiecznym sejfie.

Zakładając zastosowanie serwerowych mechanizmów uprawnień dostępu zarówno do programu Ecod Connector jak i samych plików faktur, oraz podpisując umowę z firmą C gwarantującą zapewnienie zgodnej z rozporządzeniem technologii przesyłu danych, firma uważa, iż spełniony zostanie wymóg autentyczności i integralności danych przesłanych w pliku faktury. Ze względu na sposób tworzenia jak i transmisji pliku EDIFACT faktury, z użyciem jedynie programów, brak jest tutaj czynnika ludzkiego, pliki tworzyłby system na podstawie wprowadzonych do niego danych sprzedażowych przy wystawianiu w systemie ERP faktury.

Oprogramowanie również takie pliki wysyłałoby i przechowywało z uwzględnieniem możliwości zabezpieczenia dostępu poprzez login i hasło, bez możliwości zmian w plikach już przesyłanych.

Firma uważa, iż taki mechanizm zapewni zgodność z rozporządzeniem Ministra z dnia 14 lipca 2005 r., pozwoli na zachowanie autentyczności, integralności oraz wymóg archiwizacji takich dokumentów z możliwością dostępu do nich poprzez udzielenie uprawnień, oraz ich wydruku.

Dokumenty byłyby dostępne do wglądu dla uprawnionych użytkowników i przechowywane w serwerowym systemie plików firmy. Dostęp do plików przesłanych, byłby możliwy jedynie w siedzibie firmy lub poprzez przekazanie nośników z plikami faktur, w przypadku kontroli skarbowej lub innej kontroli finansowej. Oczywiście za odpowiednim potwierdzeniem ich poboru.

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

Zgodnie z § 2 rozporządzenia Ministra Finansów z dnia 14 lipca 2005 r. w sprawie wystawiania oraz przesyłania faktur w formie elektronicznej, a także przechowywania oraz udostępniania organowi podatkowemu lub organowi kontroli skarbowej tych faktur (Dz. U. Nr 133 poz. 1119), faktury wystawiane w formie elektronicznej przesyła się, w tym udostępnia, w tej formie odbiorcy oraz przechowuje się w tej formie przy zastosowaniu elektronicznych urządzeń do przetwarzania (łącznie z cyfrową kompresją) i przechowywania danych, z wykorzystaniem technik teletransmisji przewodowej, radiowej, technologii optycznych lub innych elektromagnetycznych środków.

Stosownie do treści § 4 cytowanego rozporządzenia, faktury mogą być wystawiane, przesyłane i przechowywane w formie elektronicznej, pod warunkiem że autentyczność ich pochodzenia i integralność ich treści będą zagwarantowane:

• bezpiecznym podpisem elektronicznym 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), weryfikowanym za pomocą ważnego kwalifikowanego certyfikatu, lub
• poprzez wymianę danych elektronicznych (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ść danych.

Natomiast w myśl § 6 ust. 5 ww. rozporządzenia, faktury przesłane w formie elektronicznej powinny być przechowywane przez ich wystawcę oraz odbiorcę w formie elektronicznej w formacie, w którym zostały przesłane, w sposób gwarantujący autentyczność ich pochodzenia i integralność ich treści, jak również ich czytelność przez cały okres ich przechowywania.

Stosownie do § 6 ust. 6 rozporządzenia, dane gwarantujące autentyczność pochodzenia i integralność treści każdej faktury przesłanej w formie elektronicznej powinny być przechowywane i udostępniane organom podatkowym i organom kontroli skarbowej na zasadach ustalonych dla tych faktur.

Z powyższego wynika, że rozporządzenie wprowadza jako dozwoloną formę fakturowania elektronicznego poza bezpiecznym podpisem elektronicznym także wymianę danych elektronicznych (EDI). Elektroniczna wymiana danych (z ang. EDI - Electronic Data Interchange) została określona w rozporządzeniu jedynie poprzez odniesienie do umowy w sprawie europejskiego modelu wymiany danych elektronicznych. Umowa ta została opisana w art. 1 zaleceń Komisji Europejskiej z dnia 19 października 1994 r. nr 1994/820/WE odnoszących się do aspektów prawnych elektronicznej wymiany danych (Dz. Urz. UE L 338 z 28.12.1994). Zgodnie z definicją zawartą w omawianych zaleceniach Komisji Europejskiej, EDI powinna być rozumiana jako elektroniczna wymiana danych handlowych i administracyjnych, sformatowanych według uzgodnionych wcześniej standardów pomiędzy różnymi systemami informatycznymi. Wiadomość przesłana w formacie EDI składa się z odpowiednio zestandaryzowanych komunikatów przygotowanych w czytelnym dla systemu informatycznego formacie, które mogą być automatycznie i jednoznacznie przetwarzane. Kontrahenci mający zamiar korzystać z tej formy przesyłania danych mają obowiązek zawrzeć dwustronną umowę regulującą wymianę danych elektronicznych. Zgodnie z par. 4 pkt 2 rozporządzenia w sprawie faktur elektronicznych, zawarta pomiędzy kontrahentami umowa dotycząca elektronicznej wymiany danych (w formie EDI) powinna zawierać zapisy przewidujące stosowanie procedur, które będą gwarantowały autentyczność pochodzenia faktury i integralność danych w niej zawartych. Zagwarantowanie autentyczności pochodzenia oznacza natomiast możliwość jednoznacznej identyfikacji nadawcy wiadomości, tj. wystawcy faktury. Z kolei procedury zapewniające integralność danych zapewniają, że faktura przesłana drogą elektroniczną dotarła do adresata kompletna i w niezmienionej formie. Biorąc pod uwagę zawarte w Rozporządzeniu w sprawie faktur elektronicznych odesłanie do zaleceń Komisji Europejskiej należy przyjąć, że system spełniający wymogi EDI powinien zapewniać także rekomendowane przez Komisję Europejską standardy. Zgodnie z postulatami Komisji Europejskiej, w przypadku przesyłania wiadomości w systemie zgodnym z założeniami EDI, zaangażowane strony powinny zagwarantować przestrzeganie procedur między innymi w zakresie bezpieczeństwa. Oznacza to wprowadzenie procedur weryfikacji pochodzenia i integralności wiadomości EDI. Dodatkowo odbiorca takiej wiadomości ma obowiązek poinformowania (w czasie określonym w umowie) nadawcy o jakichkolwiek zaistniałych nieprawidłowościach. Zalecenia Komisji Europejskiej nakładają także obowiązek zapewnienia przynajmniej takiego poziomu poufności, jaki jest przyjęty w odniesieniu do dokumentów wystawianych w formie papierowej. Zgodnie z zaleceniami, umowa powinna ponadto określać zakres odpowiedzialności każdej ze stron i sposób rozwiązywania ewentualnych sporów.

Umowa, na podstawie której partnerzy handlowi wprowadzą między sobą elektroniczną wymianę danych, musi zawierać tzw. załącznik techniczny (Technical Anneks), który powinien określać m.in. ustalone standardy formatowania danych, używany sprzęt, środki komunikacji oraz procedury przeprowadzania testów próbnych w celu monitorowania i ustalenia specyfikacji i wymogów technicznych.

Zalecenia Komisji Europejskiej w znacznej części pozostawiają stronom umowy pewną swobodę w określaniu poszczególnych zapisów umowy. Jednakże wspomniana umowa pomiędzy kontrahentami powinna zawierać zapisy określające, oprócz powyższych wymogów wprost wskazanych w rozporządzeniu, także zalecenia rekomendowane przez Komisję Europejską.

Z przedstawionego we wniosku zdarzenia przyszłego wynika, że Wnioskodawca zamierza stać się uczestnikiem systemu, który pozwoli na wystawianie, przesyłanie i przechowywanie faktur poprzez wymianę danych elektronicznych (EDI). Zarówno plik źródła powstającego w Firmie dostawcy jak i dokument wysyłany do sieci Real będzie posiadał ten sam format używany w elektronicznej dokumentacji EDI, zmiana pliku nie będzie możliwa, niemożliwe będzie również dokonanie zmian w utworzonych i przesłanych już plikach faktur. Możliwe będzie jedynie wyświetlanie i wydrukowanie faktury przez uprawnione osoby. Ponadto pliki wysyłanych faktur byłyby codziennie archiwizowane na nośnikach strimerowych czyli taśmowych i przechowywane w bezpiecznym sejfie. Operator pośredniczący tj. Firma Comarch S.A. będzie przekazywać dane elektroniczne w formie komunikacji EDI. Pomiędzy Wnioskodawcą a firmą pośredniczącą zostanie podpisana umowa gwarantująca zapewnienie zgodnej z rozporządzeniem technologii przesyłu danych.

Reasumując należy uznać, iż o ile opisane procedury przesyłania, wystawiania i przechowywania faktur w przedstawionym zdarzeniu przyszłym, zawarte będą w umowie i zapewnią autentyczność i integralność faktur, to spełnione będą wymogi zawarte w § 4 pkt 2 cytowanego wyżej rozporządzenia. Podkreśla się, że procedury gwarantujące zachowanie wymogów przepisów prawa podatkowego winny wynikać z zawartej umowy o świadczenie usług EDI.

Ponadto zaznacza się, iż techniczne rozwiązania gwarantujące spełnienie wymogów autentyczności pochodzenia faktury i integralności danych nie były przedmiotem oceny tut. organu, bowiem postępowanie w sprawie interpretacji indywidualnej stosownie do treści art. 14b § 1 Ordynacji podatkowej ogranicza się jedynie do interpretacji przepisów prawa podatkowego. Przepisy te - jak wskazano wyżej - nie określają konkretnych wymogów technicznych w przedmiotowym zakresie, tak więc każde rozwiązanie techniczne, o ile zagwarantuje spełnienie wymogów prawa podatkowego będzie prawidłowe. Wskazuje się także, że organ przy wydawaniu interpretacji nie dysponuje odpowiednimi narzędziami, określonymi w Dziale IV Ordynacji podatkowej umożliwiającymi przeprowadzenie postępowania w trakcie którego mógłby pozyskać wiedzę specjalistyczną.

W konsekwencji stanowisko Wnioskodawcy należało uznać za prawidłowe, o ile opisane procedury przesyłania faktur w przedstawionym zdarzeniu przyszłym, zawarte będą w umowie i zapewnią autentyczność i integralność faktur.

Interpretacja dotyczy zdarzenia przyszłego przedstawionego przez Wnioskodawcę 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 - Dz. U. Nr 153, poz. 1270 ze zm.). 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 Maja 10, 09-402 Płock.