FA(3) – zmiana strukturalna, nie kosmetyczna

Wcześniejsze wersje schemy FA koncentrowały się na podstawowych elementach faktury: danych sprzedawcy i nabywcy, pozycjach, stawkach VAT oraz podsumowaniach. FA(3) rozwija ten model, doprecyzowując warunki występowania poszczególnych pól, relacje między sekcjami oraz sposób prezentacji informacji o korektach, zaliczkach czy mechanizmach szczególnych.

Kluczową zmianą jest większa liczba walidacji kontekstowych. Oznacza to, że poprawność jednego pola może zależeć od wartości innego. W praktyce system musi nie tylko generować poprawny technicznie plik, lecz również uwzględniać scenariusz podatkowy. To istotne zwłaszcza dla firm korzystających z rozbudowanych procesów sprzedażowych, zintegrowanych z KSeF oraz modułami takimi jak aplikacja do faktur.

Więcej danych szczegółowych – mniej miejsca na uproszczenia

FA(3) rozszerza zakres informacji, które mogą, a w niektórych przypadkach muszą, znaleźć się w strukturze. Dotyczy to między innymi bardziej szczegółowego opisu pozycji, danych dotyczących płatności czy oznaczeń specyficznych dla określonych typów transakcji. Wcześniej część tych informacji funkcjonowała wyłącznie w warstwie wizualnej dokumentu PDF. Obecnie muszą być one prawidłowo odwzorowane w strukturze logicznej.

Dla księgowości oznacza to konieczność weryfikacji, czy dane wprowadzane przez użytkowników są kompletne i zgodne z wymaganiami schemy. Dla IT – konieczność przeglądu mapowania pól pomiędzy bazą danych a strukturą XML. Błędy w tym obszarze nie zawsze będą widoczne na pierwszy rzut oka, lecz mogą skutkować odrzuceniem dokumentu przez system.

Korekty i dokumenty powiązane – większa precyzja zależności

FA(3) wprowadza bardziej jednoznaczne zasady prezentowania faktur korygujących oraz dokumentów powiązanych. Wcześniejsze podejście pozwalało na pewien zakres interpretacji co do sposobu wykazywania różnic. Obecnie struktura wymaga spójnego wskazania danych dokumentu pierwotnego oraz precyzyjnego określenia wartości przed i po korekcie.

Działy księgowe powinny przeanalizować, czy stosowana logika wyliczania różnic jest zgodna z wymaganiami nowej schemy. W systemach oferujących pełną księgowość online oznacza to również testy scenariuszy obejmujących korekty częściowe, zbiorcze oraz walutowe.

Warunki występowania pól – nowy poziom walidacji

Jednym z istotnych elementów FA(3) są bardziej restrykcyjne warunki występowania pól. Oznacza to, że niektóre sekcje muszą być obecne wyłącznie w określonych sytuacjach, a ich brak lub nadmiar skutkuje błędem walidacyjnym. Dotyczy to m.in. transakcji szczególnych, sprzedaży zagranicznej czy mechanizmów takich jak odwrotne obciążenie.

Z perspektywy IT kluczowe jest zbudowanie testów automatycznych, które obejmą różne warianty dokumentów. Z perspektywy księgowości – weryfikacja, czy pracownicy rozumieją, kiedy dana informacja jest wymagana. Integracja z modułami takimi jak asystent finansowy może pomóc w bieżącej kontroli spójności danych.

Mapowanie danych – obszar o podwyższonym ryzyku

Przejście na FA(3) wymaga ponownego przeanalizowania mapowania danych z systemów ERP, CRM lub dedykowanych aplikacji sprzedażowych. Niewielkie różnice w nazewnictwie lub strukturze pól mogą prowadzić do niezgodności. Szczególnie istotne jest sprawdzenie, czy wszystkie wymagane elementy mają swoje źródło w bazie danych i czy nie są generowane jedynie na potrzeby warstwy wizualnej.

Firmy korzystające z rozbudowanych integracji, opisanych w sekcji integracje, powinny przeprowadzić testy end-to-end, obejmujące cały cykl: wystawienie faktury, przesłanie do KSeF, odbiór statusu oraz archiwizację.

Numeracja, identyfikatory i spójność raportowa

FA(3) nie zmienia samej idei numeracji faktur, lecz wymaga większej konsekwencji w zakresie identyfikatorów dokumentów i powiązań między nimi. W środowiskach, gdzie funkcjonuje własna numeracja faktur, należy sprawdzić, czy generowane numery są prawidłowo przekazywane do struktury oraz czy nie dochodzi do rozbieżności między numerem wewnętrznym a identyfikatorem systemowym.

Dla księgowości istotne jest również porównanie danych z faktur ustrukturyzowanych z ewidencjami VAT i raportami finansowymi. Zmiana schemy może ujawnić wcześniejsze uproszczenia, które nie były widoczne w poprzednich wersjach.

Co powinna sprawdzić księgowość

Działy księgowe powinny rozpocząć od analizy scenariuszy sprzedażowych występujących w firmie. Należy zidentyfikować wszystkie typy transakcji, w tym zaliczki, korekty, sprzedaż zagraniczną czy świadczenia kompleksowe, a następnie przetestować je w nowej strukturze. Ważne jest również przeszkolenie zespołu w zakresie nowych wymagań, tak aby dane były wprowadzane w sposób zgodny z logiką FA(3).

W przypadku podmiotów korzystających z wyspecjalizowanych modeli, takich jak księgowość dla startupów czy księgowość dla JDG, szczególną uwagę należy zwrócić na procesy automatyczne i faktury cykliczne.

Co powinna sprawdzić IT

Dział IT powinien przeprowadzić przegląd schemy XSD, zaktualizować walidatory oraz zapewnić zgodność środowisk testowych i produkcyjnych. Konieczne jest także sprawdzenie obsługi komunikatów zwrotnych z systemu oraz poprawności archiwizacji dokumentów.

W praktyce oznacza to analizę logów, testy obciążeniowe oraz weryfikację obsługi błędów. Wdrożenie FA(3) nie kończy się na aktualizacji pliku konfiguracyjnego – wymaga ono całościowego podejścia do integracji z księgowością online i systemami finansowymi.

Podsumowanie – FA(3) jako test dojrzałości procesów

FA(3) wprowadza większą precyzję, a tym samym mniejszą tolerancję na nieścisłości. To dobra wiadomość z perspektywy transparentności systemu podatkowego, lecz wyzwanie dla organizacji, które dotychczas opierały się na uproszczeniach. Zmiana schemy powinna być impulsem do przeglądu procesów, mapowania danych i komunikacji między księgowością a IT.

Firmy, które potraktują FA(3) jako element szerszej transformacji cyfrowej, zyskają większą kontrolę nad obiegiem dokumentów i jakością danych. W przeciwnym razie nowa struktura logiczna stanie się źródłem błędów, które trudno będzie wyjaśnić dopiero na etapie kontroli podatkowej.