Format FA(3) - struktura e-faktury w KSeF krok po kroku

Czym jest format FA(3)

Format FA(3) to ustrukturyzowany wzór e-faktury, w którym każdy dokument trafia do Krajowego Systemu e-Faktur jako plik XML o ściśle określonej budowie. Zamiast dowolnego PDF-a czy skanu faktura ma tu jedną, narzuconą strukturę logiczną opublikowaną przez Ministerstwo Finansów. To właśnie ta struktura decyduje o tym, czy dokument zostanie przyjęty, czy odrzucony.

W praktyce oznacza to zmianę sposobu myślenia o fakturze. Nie liczy się już tylko to, co widać na wydruku, lecz to, czy dane są ułożone w odpowiednich sekcjach i polach. System sprawdza dokument automatycznie względem wzoru i nie zostawia miejsca na improwizację. Jeśli pole jest w złym miejscu, ma zły format albo go brakuje, faktura nie przejdzie.

FA(3) to kolejna wersja tego wzoru. Wcześniejsze, czyli FA(1) i FA(2), działały na tej samej zasadzie, a każda aktualizacja porządkowała pola i dodawała nowe elementy. Jeśli dopiero wchodzisz w temat e-faktur, zacznij od ogólnego wprowadzenia w artykule o KSeF i e-fakturach w e-commerce, a potem wróć tu po szczegóły samej struktury.

To praktyczny przewodnik, a nie porada podatkowa ani prawna. Zakres obowiązkowych pól faktury i zasady jej wystawiania reguluje ustawa o VAT oraz rozporządzenia Ministerstwa Finansów, a konkretne wątpliwości warto skonsultować z księgowym lub doradcą podatkowym i sprawdzić aktualne przepisy, bo bywają zmieniane.

Z jakich sekcji składa się e-faktura FA(3)

Schema FA(3) dzieli fakturę na kilka logicznych bloków. Nie musisz znać ich na pamięć, ale warto rozumieć, co gdzie się znajduje, bo dzięki temu łatwiej zidentyfikować, której części dotyczy błąd walidacji.

Najważniejsze sekcje struktury to:

• Nagłówek - informacje techniczne o samym dokumencie, między innymi kod i wersja wzoru oraz data wytworzenia.
• Dane sprzedawcy (Podmiot1) - NIP, nazwa i adres wystawcy faktury.
• Dane nabywcy (Podmiot2) - identyfikacja kupującego, w tym NIP lub jego brak przy sprzedaży konsumenckiej oraz adres.
• Dane faktury (Fa) - numer dokumentu, daty, waluta, pozycje, stawki i podsumowanie kwotowe.
• Pozycje faktury (FaWiersz) - poszczególne towary lub usługi z opisem, ilością, ceną, stawką i wartością.
• Podsumowanie i adnotacje - wartości zbiorcze netto, VAT i brutto oraz oznaczenia procedur szczególnych.

Każda z tych sekcji ma własny zestaw pól, a część z nich jest powiązana zależnościami. Na przykład wybór określonej procedury w adnotacjach może wymusić obecność dodatkowych pól w innej części dokumentu. To jeden z powodów, dla których ręczne składanie XML jest ryzykowne, a budowę pliku lepiej zostawić oprogramowaniu.

Warto też pamiętać, że struktura FA(3) jest wspólna dla wszystkich rodzajów faktur. Ten sam wzór obsługuje fakturę zwykłą, zaliczkową, korygującą czy uproszczoną, a różnice wynikają z wypełnienia odpowiednich pól i oznaczeń, a nie z osobnych formatów.

Pola obowiązkowe, warunkowe i opcjonalne

W schemie FA(3) pola dzielą się na kilka kategorii i to rozróżnienie jest kluczowe przy diagnozowaniu odrzuceń. Część pól jest wymagana zawsze, część tylko w określonych sytuacjach, a część jest całkowicie opcjonalna.

Trzon pól obowiązkowych pokrywa się z tym, co i tak musi znaleźć się na każdej fakturze VAT. Jeśli chcesz mieć pewność, że masz komplet danych, sprawdź zestawienie w artykule o tym, co musi zawierać faktura VAT. To dobra baza, bo dane wymagane przez przepisy są jednocześnie polami wymaganymi przez schemę.

Najwięcej problemów sprawiają pola warunkowe. Przy sprzedaży B2B konieczny jest poprawny NIP nabywcy, przy sprzedaży zagranicznej kod kraju, a przy procedurach szczególnych odpowiednie oznaczenia. Brak takiego pola w sytuacji, gdy schema go wymaga, kończy się odrzuceniem, mimo że z perspektywy zwykłego użytkownika faktura wygląda kompletnie.

Jak przygotować dane zamówień pod format FA(3)

W e-commerce dane do faktury nie powstają ręcznie, lecz przychodzą z zamówień składanych na sklepie i w serwisach marketplace. Każda platforma przekazuje je w swoim formacie, więc realnym wyzwaniem jest nie tyle sam XML, ile czyste i kompletne dane wejściowe. Jeśli zadbasz o ich jakość, zgodność ze strukturą FA(3) staje się formalnością po stronie systemu fakturowego.

Na co zwrócić uwagę w danych zamówień:

1. NIP nabywcy - przy fakturach B2B musi być poprawny i aktywny. Numer z literówką albo nieaktywny zostanie odrzucony przez system fakturowy jeszcze przed wysyłką do KSeF.
2. Pełny adres - ulica, kod pocztowy, miejscowość i kraj. Brak elementu adresu blokuje wygenerowanie dokumentu.
3. Stawka VAT - każda pozycja musi mieć stawkę zgodną z dozwolonym słownikiem. Niepoprawna lub nieprzypisana stawka to częsta przyczyna błędu.
4. Waluta i kwoty - waluta musi pochodzić z dozwolonej listy kodów, a kwoty netto, VAT i brutto muszą być spójne.
5. Rodzaj faktury - rozróżnienie sprzedaży B2B od B2C decyduje, które pola warunkowe są wymagane.

Dobra praktyka to walidacja danych zamówienia jeszcze przed wysłaniem do systemu fakturowego, a nie dopiero w momencie, gdy KSeF zwróci błąd. Wychwycenie błędnego NIP czy brakującego adresu na wcześniejszym etapie oszczędza czasu i zmniejsza liczbę dokumentów wymagających ręcznej naprawy. Pomaga w tym także zrozumienie, jak działa numer KSeF i uwierzytelnianie, czyli co dzieje się z fakturą po jej przyjęciu.

Tu wchodzi rola integracji. NavyFlame zbiera zamówienia z wielu kanałów, ujednolica dane nabywcy i pozycji, a następnie przekazuje je do zautomatyzowanego fakturowania. Sam plik w strukturze FA(3) i wysyłkę do KSeF realizuje połączony system fakturowy, a Ty dostarczasz tylko poprawne dane. Dzięki temu nie składasz XML ręcznie i nie martwisz się o kolejne wersje wzoru.

Najczęstsze błędy walidacji i jak ich uniknąć

Odrzucenie faktury przez KSeF nie oznacza zwykle, że dokument jest merytorycznie zły. Znacznie częściej chodzi o drobną niezgodność ze strukturą, którą łatwo przeoczyć, a która wystarcza, żeby system odmówił przyjęcia pliku.

Najczęstsze przyczyny błędów walidacji to:

• Zła wersja schemy - dokument zbudowany według nieaktualnego wzoru. Rozwiązaniem jest pilnowanie, by system fakturowy korzystał z obowiązującej wersji.
• Brak pola warunkowego - na przykład brak NIP nabywcy przy fakturze B2B albo brak kodu kraju przy sprzedaży zagranicznej.
• Niepoprawny format daty lub liczby - data zapisana w innym formacie niż wymaga schema, kwota z błędnym separatorem.
• Wartość spoza słownika - kod kraju, kod waluty albo stawka VAT, których schema nie akceptuje.
• Niespójne kwoty - suma pozycji nie zgadza się z podsumowaniem netto, VAT lub brutto.

Najskuteczniejszym zabezpieczeniem jest walidacja po stronie systemu fakturowego przed wysłaniem dokumentu, połączona z czystymi danymi wejściowymi. Gdy dane zamówienia są kompletne, a oprogramowanie buduje XML zgodnie z aktualnym wzorem, większość tych błędów po prostu nie ma jak się pojawić.

Warto też mieć mechanizm na sytuacje, w których mimo wszystko coś nie przejdzie. W automatycznym fakturowaniu nieudane dokumenty nie giną - trafiają do kolejki błędów z opisem przyczyny, więc po naprawie danych można ponowić wysyłkę bez przepisywania wszystkiego od nowa. To zamienia odrzucenia z formatu FA(3) z poważnego problemu w drobną, kontrolowaną poprawkę.

Najczesciej zadawane pytania