Dlaczego Twój ERP generuje faktury, a nie dowody
Oprogramowanie ERP i księgowe znakomicie wykonuje zadanie, do którego zostało zaprojektowane: przetwarza transakcje na dużą skalę, egzekwuje przepływy akceptacji i wytwarza ustrukturyzowane dane wyjściowe, z których mogą korzystać inne systemy. W ten sposób codziennie powstają miliony faktur bez żadnych incydentów.
Istnieje jednak osobne zadanie, do którego oprogramowanie ERP nigdy nie było projektowane, a to rozróżnienie ma znaczenie, gdy organ podatkowy, sąd lub organ regulacyjny zadaje trudniejsze pytanie niż „pokaż mi fakturę”.
Pytanie, na które większość oprogramowania nie potrafi odpowiedzieć
Gdy rutynowa faktura jest kwestionowana, przedstawienie pliku PDF zwykle wystarcza. Nabywca ją rozpoznaje, sprzedawca ją potwierdza i sprawa jest zamknięta. Pod ten przepływ pracy optymalizowane jest oprogramowanie ERP.
Trudniejsze pytanie wygląda tak: „Udowodnij, że ta faktura istniała dokładnie w tej formie w tym dniu, że od tego czasu nie została zmieniona i że osoba, która twierdzi, że ją wysłała, rzeczywiście wysłała ją przez Twój system”.
To nie jest pytanie o dokument. To pytanie o dowód. A dowody mają inne wymagania niż dokumenty.
Dokument to zapis transakcji. Dowód to weryfikowalny zapis, który wytrzyma niezależną kontrolę, w tym kontrolę ze strony kogoś, kto aktywnie próbuje go podważyć.
Co zapewnia oprogramowanie ERP
Aby precyzyjnie opisać lukę, warto jasno określić, co oprogramowanie ERP robi dobrze.
Większość nowoczesnych systemów ERP zapewnia:
Ustrukturyzowane dane faktur. Faktury są przechowywane w bazie danych z jasnymi relacjami między nabywcami, sprzedawcami, pozycjami, sumami i datami. Dzięki temu można je przeszukiwać, audytować przez własny interfejs ERP i eksportować w standardowych formatach, takich jak UBL lub CII XML.
Logi akceptacji i audytu. Większość systemów ERP rejestruje, kto co zatwierdził i kiedy. Te logi są przydatne przy przeglądach kontroli wewnętrznej i mogą wykazać, że przestrzegano właściwego procesu.
Zgodność formatu. Dla danych wyjściowych Factur-X, ZUGFeRD, XRechnung i Peppol nowoczesne oprogramowanie ERP generuje XML, który przechodzi walidację względem odpowiedniego schematu. Spełnia to wymóg formatu wynikający z unijnych obowiązków e-fakturowania.
Eksport i przenośność. Faktury można zazwyczaj eksportować zbiorczo, jako XML, PDF lub w obu formatach. Pokrywa to przypadek użycia związany z przenoszalnością danych.
Nic z tego nie jest trywialne. Zgodność formatu to prawdziwy problem inżynieryjny, w którego rozwiązanie dostawcy ERP włożyli znaczny wysiłek. Nie chodzi o to, że oprogramowanie ERP jest wadliwe. Chodzi o to, że zgodność formatu jest konieczna, ale niewystarczająca jako dowód prawny.
Czego oprogramowanie ERP nie zapewnia
Luka pojawia się, gdy prosisz o niezależną weryfikację trzech rzeczy, których często wymagają postępowania prawne.
Dowód istnienia w określonym czasie. Znacznik czasu przechowywany w Twoim własnym systemie jest tak wiarygodny, jak ten system. Jeśli kontrolujesz system, przeciwnik może argumentować, że znacznik czasu również był pod Twoją kontrolą. Znacznik czasu RFC 3161 od niezależnego urzędu znacznikowania czasu (Time Stamping Authority) jest kryptograficznie podpisany przez stronę trzecią i nie można go sfałszować wstecznie bez unieważnienia podpisu. Większość systemów ERP nie wystawia ani nie przechowuje znaczników czasu RFC 3161.
Dowód integralności od tego czasu. Plik PDF lub XML przechowywany w bazie danych można zmodyfikować. Rekord w bazie danych można zaktualizować. Bez niezależnie zapisanego skrótu (hash commitment), czyli kryptograficznego odcisku utworzonego w chwili powstania dokumentu i przechowywanego gdzieś poza Twoją kontrolą, nie możesz udowodnić, że dokument nie został od tego czasu zmieniony. Większość systemów ERP nie tworzy ani nie przechowuje kryptograficznie zapisanych skrótów powiązanych z ich rekordami.
Niezależny łańcuch dowodowy. Wiedza o tym, że dokument istnieje dziś w określonym stanie, to coś innego niż wiedza o tym, jak do tego stanu doszedł. Łańcuch dowodowy rejestruje każde działanie wykonane na dokumencie (kto miał do niego dostęp, co zrobiono i w jakiej kolejności) w dzienniku odpornym na manipulacje. To standard w postępowaniach prawnych i regulacyjnych, ale zazwyczaj nie w ten sposób implementuje się logi audytowe ERP.
Kiedy ma to znaczenie w praktyce
Luka między dokumentem a dowodem nie jest kwestią akademicką. Oto konteksty, w których wychodzi na jaw.
Postępowania organów podatkowych. W kilku jurysdykcjach UE organy podatkowe mają prawo żądać, aby firmy wykazały integralność swojej dokumentacji faktur elektronicznych. Firma, która potrafi przedstawić faktury, ale nie potrafi wykazać, że nie zostały one zmienione od wystawienia, jest w słabszej pozycji niż firma, która może przedstawić wraz z fakturą kryptograficzny dowód integralności.
Spory handlowe. Gdy nabywca kwestionuje fakturę, twierdząc, że została zmodyfikowana po fakcie albo że kwoty nie zgadzają się z ustaleniami, sprzedawca musi wykazać, że dokument jest autentyczny i niezmieniony. Znacznik czasu RFC 3161 i łańcuch skrótów pozwalają to wykazać. PDF z systemu ERP bez niezależnej weryfikacji na to nie pozwala.
Audyty regulacyjne w usługach finansowych. Firmy podlegające MiFID II, Solvency II lub równoważnym ramom regulacyjnym muszą prowadzić dokumentację w sposób wykazujący jej integralność i autentyczność. Konkretne wymagania się różnią, ale ogólne oczekiwanie jest takie, że dokumentacji nie można zmienić bez wykrycia. To wyżej zawieszona poprzeczka niż typowe przechowywanie w ERP.
Spory umowne przy długich okresach przechowywania. Wymogi dotyczące przechowywania faktur w UE wahają się od 7 lat (powszechny standard dla faktur VAT) do 20 lat dla niektórych dokumentów sektora publicznego na mocy prawa holenderskiego. W ciągu 7 lat wiele może się zmienić: system ERP może zostać wymieniony, baza danych przeniesiona, a pliki PDF ponownie wyeksportowane. Bez znacznika czasu i łańcucha skrótów zakotwiczonych w chwili utworzenia udowodnienie, że faktura sprzed 7 lat nie została zmodyfikowana, staje się trudne.
Błędne przekonanie o zgodności formatu
Powszechne jest założenie, że jeśli faktura jest zgodna z Factur-X lub Peppol, jest dopuszczalna jako dowód prawny. Zgodność formatu oznacza, że faktura przechodzi walidację względem schematu i zawiera wymagane pola. Nie mówi nic o tym, kiedy dokument utworzono, czy został zmodyfikowany ani czy zapis można niezależnie zweryfikować.
Factur-X to format pliku. RFC 3161 to protokół dowodowy. Działają na różnych warstwach stosu zgodności i jeden nie zastępuje drugiego.
Posłużmy się analogią ze świata fizycznego: dokument poświadczony notarialnie i dokument wydrukowany to w obu przypadkach dokumenty. Poświadczenie notarialne dodaje warstwę niezależnej weryfikacji: zaufana strona trzecia poświadcza, kiedy i przez kogo dokument został podpisany. Zgodność formatu jest bliższa drukowaniu niż poświadczeniu notarialnemu.
Czego naprawdę wymaga warstwa dowodowa
Wytworzenie weryfikowalnego dowodu dla dokumentu cyfrowego wymaga co najmniej trzech rzeczy.
Zaufany znacznik czasu. Znacznik czasu RFC 3161 od urzędu znacznikowania czasu (Time Stamping Authority, TSA) zapewnia kryptograficzny dowód istnienia w określonym momencie. TSA jest niezależną stroną, której podpis każdy może zweryfikować za pomocą standardowych narzędzi. Znacznika czasu nie można sfałszować po fakcie bez unieważnienia łańcucha podpisów.
Zapisany skrót (hash commitment). Zanim dokument otrzyma znacznik czasu, z jego treści obliczany jest skrót. SealDoc oblicza zarówno skrót SHA-256, który żądanie RFC 3161 przekazuje do poświadczenia urzędowi znacznikowania czasu, jak i skrót SHA-384, który identyfikuje rekord w rejestrze dowodowym. Skrót jest odciskiem treści. Jeśli po obliczeniu skrótu zmieni się choćby jeden bajt dokumentu, odcisk przestaje pasować. Skrót jest przechowywany niezależnie od dokumentu, dzięki czemu dokument i odcisk można w dowolnym momencie w przyszłości porównać ze sobą.
Zapis łańcucha dowodowego. Każde działanie wykonane na dokumencie po jego utworzeniu (dostęp, konwersja, archiwizacja, pobranie) jest rejestrowane wraz z tożsamością wykonawcy, znacznikiem czasu i adresem IP w dzienniku audytowym odpornym na manipulacje.
Razem te trzy elementy odpowiadają na pytania, które zadaje się w postępowaniach prawnych: czy ten dokument istniał w tej formie w tym czasie, czy od tamtej pory został zmieniony i kto się nim zajmował.
Praktyczne pytanie
Pytanie to ma największe znaczenie w następujących okolicznościach: branże regulowane, transakcje o wysokiej wartości, długie okresy przechowywania, kwestionowane faktury lub każdy kontekst, w którym przeciwnik może mieć motywację, by podważyć integralność Twojej dokumentacji.
W tych przypadkach luka między „mamy fakturę” a „możemy udowodnić, że faktura jest autentyczna” jest realna i sama zgodność formatu jej nie zamyka.
Najbardziej praktycznym podejściem jest wbudowanie warstwy dowodowej w momencie tworzenia dokumentu, a nie wstecznie. Znacznik czasu RFC 3161 i łańcuch skrótów dodane w chwili generowania nic nie kosztują w czasie audytu. Dodanie ich wstecznie albo próba dowodzenia, że istniejąca dokumentacja wystarcza bez nich, jest trudniejsze.
SealDoc dodaje warstwę dowodową do każdego dokumentu przetwarzanego w potoku: znacznik czasu RFC 3161, którego domyślnie żąda od niezależnego unijnego urzędu znacznikowania czasu, łańcuch dowodowy SHA-256 obejmujący etapy przetwarzania, rejestr dowodowy SHA-384 obejmujący rekord oraz, na żądanie, Legal Evidence Pack łączący oba w jedno archiwum gotowe do audytu.