Wizualizacja e-faktury KSeF jest ważnym punktem styku między danymi strukturalnymi, codzienną obsługą dokumentów i identyfikacją firmy. Nie ma jednego obowiązkowego wzoru graficznego, dlatego przedsiębiorstwo lub integrator może opracować własny projekt faktury PDF. Swoboda projektowa nie oznacza jednak dowolności w zakresie danych. Wizualizacja pozostaje pochodną pliku XML przyjętego przez KSeF i nie może zawierać informacji z nim sprzecznych.
Dobrze zaplanowany dokument powinien łączyć logiczny układ, czytelność na ekranie i wydruku, właściwe oznaczenie kodów QR oraz konsekwentne wykorzystanie marki. Logo i dane kontaktowe mogą wzmacniać identyfikację wizualną dokumentu, ale nie zastępują informacji przekazywanych strukturalnie. Dlatego projektowanie warto rozpocząć od mapy danych i procesu integracji, a dopiero później przejść do kompozycji, typografii i elementów brandingu.
Wizualizacja e-faktury w KSeF — dokument cyfrowy, nie tylko PDF
KSeF operuje fakturą ustrukturyzowaną przekazywaną jako plik XML. To właśnie ten plik jest przyjmowany i weryfikowany w systemie. PDF, ekranowa reprezentacja dokumentu lub wydruk pełnią natomiast funkcję wizualizacji, która ułatwia człowiekowi odczyt, przekazanie albo wykorzystanie faktury poza systemem. Nabywca może pobrać lub wydrukować fakturę, a pobrane i wydrukowane dokumenty są opatrywane kodem oraz numerem KSeF.
XML, wizualizacja i wydruk — trzy różne warstwy dokumentu
Rozróżnienie tych warstw ma znaczenie organizacyjne. XML jest nośnikiem danych strukturalnych, wizualizacja przedstawia je w uporządkowanej formie, a wydruk jest kolejnym sposobem użycia tej reprezentacji. KSeF nie narzuca jednego układu graficznego, lecz wymaga zachowania spójności z zaakceptowanym XML, logicznego układu danych i braku sprzeczności. Atrakcyjny PDF nie zapewnia samodzielnie zgodności podatkowej ani poprawności procesu fakturowania.
Zasada nadrzędna: zgodność wizualizacji z plikiem XML
Najważniejszą zasadą projektu jest podporządkowanie warstwy graficznej danym strukturalnym. Wizualizacja e-faktury powinna odzwierciedlać zaakceptowany plik XML. Nie może zmieniać numeru dokumentu, danych stron transakcji, pozycji, kwot, podatku ani warunków płatności. Jeżeli PDF pokazuje inną informację niż XML, problem nie jest wyłącznie estetyczny. Może dotyczyć weryfikacji dokumentu, obsługi płatności i późniejszej pracy systemów odbiorcy.
Mapa danych przed projektem graficznym
Przed przygotowaniem układu należy określić, jakie dane mają być prezentowane i z jakich elementów XML pochodzą. W praktyce oznacza to porównanie zakresu danych źródłowych z planowaną strukturą PDF. Warto objąć mapą dane stron transakcji, identyfikację dokumentu, daty, pozycje, stawki, kwoty, podatek, płatność oraz informacje dodatkowe istotne dla odbiorcy. Struktura FA(3) pozwala przekazywać dodatkowe informacje między innymi przez elementy DodatkowyOpis, Platnosc, Rozliczenie i WarunkiTransakcji. Taka mapa ogranicza ryzyko, że projektant potraktuje PDF jako niezależny dokument.
Jak uporządkować dane na czytelnej wizualizacji
Czytelność warto budować przez logiczną hierarchię informacji, a nie przez dekoracyjność. Wizualizacja powinna być zrozumiała dla stron transakcji, księgowości i osób korzystających z dokumentu na ekranie lub w formie wydruku. Źródła nie definiują jednego kompletnego szablonu PDF ani uniwersalnych zasad typografii, kolorystyki, siatki czy minimalnego rozmiaru logo. Są to decyzje projektowe, które należy oceniać w odniesieniu do funkcji dokumentu.
Zakres informacji ważnych dla stron transakcji
Podstawą układu są dane wystawcy i nabywcy, identyfikacja dokumentu, daty, pozycje, stawki, kwoty, podatek oraz informacje dotyczące płatności. Jeżeli odbiorca potrzebuje dodatkowych informacji transakcyjnych, powinny one mieć odpowiednik w strukturze XML, jeśli mają być wykorzystywane przez jego system. Dotyczy to w szczególności warunków płatności i rachunku bankowego. PDF może prezentować te dane, lecz nie powinien być ich jedynym nośnikiem.
Czytelność bez deklarowania nieistniejących standardów
Praktycznym celem jest wyraźne grupowanie informacji i konsekwentne prowadzenie odbiorcy przez dokument. Należy ocenić projekt na ekranie, w pliku PDF i po wydruku, a także sprawdzić różne warianty dokumentu, w tym scenariusze online i offline. Nie należy jednak przedstawiać konkretnego układu, koloru, wielkości elementu ani rozwiązania typograficznego jako formalnego wymogu KSeF, jeżeli nie wynika to z dokumentacji.
Branding dokumentu: logo, kontakt i identyfikacja wizualna
Dokument cyfrowy może być częścią systemu identyfikacji wizualnej firmy. Logo i dane kontaktowe mogą zostać umieszczone w wizualizacji jako elementy dodatkowe. Pozwalają zachować rozpoznawalność marki i uporządkować kontakt z wystawcą, ale z perspektywy systemowej nie stanowią danych faktury. Nie zastępują więc danych strukturalnych i nie powinny konkurować z numerem dokumentu, kwotami, płatnością ani informacjami potrzebnymi do weryfikacji.
Marka jako warstwa dodatkowa, nie strukturalna
Najbezpieczniej rozdzielić w szablonie warstwę funkcjonalną od warstwy marki. Pierwsza odpowiada za prezentację danych transakcyjnych, druga za logo, kontakt i konsekwencję wizualną. Elementy dekoracyjne nie powinny zasłaniać, deformować ani osłabiać odczytu informacji. Branding dokumentu ma wspierać użyteczność i rozpoznawalność, a nie zastępować dane przekazywane w XML.
Kody QR i numer KSeF — element funkcjonalny wizualizacji
Kod QR nie jest ozdobą. Służy między innymi do weryfikacji, czy faktura znajduje się w KSeF, oraz do uzyskania dostępu do dokumentu. W wariancie offline drugi kod służy do weryfikacji tożsamości wystawcy. Dlatego miejsce kodu powinno być zaplanowane w szablonie już na etapie projektu, a nie dodawane przypadkowo po wygenerowaniu dokumentu.
Stałe miejsce i właściwe oznaczenie
Dla wizualizacji faktury wystawionej online przewidziany jest jeden kod QR, pod którym powinno znaleźć się oznaczenie w postaci numeru KSeF faktury. Dla faktury wystawionej offline przewidziane są dwa kody QR, z oznaczeniami „OFFLINE” i „CERTYFIKAT”. Kod powinien być nanoszony bezpośrednio na wizualizację wraz z właściwym numerem albo napisem. Nie należy go przycinać, deformować, zasłaniać ani stylizować bez testów technicznych i zgodności z dokumentacją. Kontrola powinna obejmować wygenerowany PDF oraz wydruk.
Dane strukturalne a automatyzacja księgowania
Automatyzacja księgowania zależy przede wszystkim od jakości danych strukturalnych i konfiguracji systemów, a nie od atrakcyjności PDF. Jeżeli warunki płatności, rachunek bankowy lub dodatkowe informacje transakcyjne zostaną umieszczone wyłącznie w wizualizacji, odbiorca może nie mieć możliwości zapisania ich w uporządkowanej formie. Może to wymagać ręcznego przepisywania i ograniczać wykorzystanie danych przez oprogramowanie finansowo-księgowe.
Co powinno pozostać w XML
Informacje przeznaczone do dalszego przetwarzania powinny być przekazywane strukturalnie, jeżeli mają znaczenie dla odbiorcy. PDF powinien je odzwierciedlać, lecz nie może być jedynym miejscem ich przechowywania. Problemy przypisywane wizualizacji mogą powstawać wcześniej: w zakresie danych XML, walidacji albo integracji systemu fakturowego. Dlatego projekt powinien być konsultowany z osobami odpowiedzialnymi za markę, księgowość, podatki i integrację. Skuteczność automatyzacji zależy także od konfiguracji systemu odbiorcy i jego reguł importu, więc nie można jej przedstawiać jako gwarantowanego rezultatu.
Checklista wdrożenia szablonu e-faktury
Wdrożenie wizualizacji powinno być procesem kontrolowanym, a nie wyłącznie akceptacją projektu graficznego. Obejmuje dane, generowanie dokumentu, kody QR i scenariusze jego użycia. Szczególne znaczenie ma fakt, że KSeF weryfikuje zgodność XML z właściwą strukturą logiczną. Dla faktury ustrukturyzowanej wskazywana jest struktura FA(3), a brak wymaganych pól może skutkować odrzuceniem pliku i brakiem nadania numeru KSeF.
Kontrola zgodności danych i wariantu dokumentu
- Zweryfikuj XML względem właściwej struktury FA(3) i sprawdź obecność danych wymaganych przez proces.
- Porównaj XML i PDF w zakresie numerów, stron transakcji, pozycji, kwot, płatności i informacji dodatkowych.
- Sprawdź wariant online albo offline oraz właściwą liczbę i oznaczenie kodów QR.
- Przetestuj dokument po wygenerowaniu PDF i po wydruku, w tym działanie kodów QR.
- Uzyskaj akceptację osób odpowiedzialnych za markę, księgowość, podatki i integrację systemową.
Najczęstsze klasy ryzyka
Najpoważniejszym ryzykiem jest sprzeczność XML i PDF: inna kwota, numer, informacja o kontrahencie, zakres pozycji albo warunki płatności. Kolejnym problemem jest przenoszenie danych istotnych dla księgowości wyłącznie do warstwy wizualnej. Automatyzację może również ograniczyć brak, błędne oznaczenie lub uszkodzenie kodu QR. Odrębną klasę ryzyka stanowią błędy w XML, które mogą doprowadzić do odrzucenia pliku przez KSeF. Nie istnieje jednak jeden uniwersalny katalog ograniczeń dla wszystkich programów księgowych, integratorów i systemów OCR, dlatego testy należy odnieść do konkretnego procesu.
Dobra wizualizacja e-faktury KSeF zaczyna się od danych strukturalnych i uzgodnienia procesu, a dopiero potem obejmuje układ, identyfikację marki oraz przygotowanie PDF. Czytelność dokumentu, logo, kontakt i kody QR powinny współistnieć bez zastępowania XML. Kluczowe jest również sprawdzenie dokumentu na ekranie i wydruku oraz wspólna akceptacja obszarów projektowych, księgowych, podatkowych i integracyjnych. Umów konsultację z BrandingHouse, aby stworzyć spójny wizerunek marki i materiały dopasowane do celów Twojej firmy.
