Faktura ustrukturyzowana FA(3): co zawiera i jakie wymagania techniczne musi spełnić

Faktura ustrukturyzowana to faktura w postaci pliku XML zgodnego ze strukturą logiczną opublikowaną przez Ministerstwo Finansów. W KSeF 2.0 obowiązuje wersja FA(3). Dla człowieka to nieczytelny plik, dla programu księgowego to dane, które da się zaksięgować bez przepisywania. Poniżej opisuję, z czego składa się taki plik i co KSeF sprawdza, zanim nada mu numer.

Sekcje faktury FA(3)

• Nagłówek: oznaczenie formularza i wersji struktury, data wytworzenia pliku, informacja o systemie, który go wytworzył.
• Podmiot1: sprzedawca, z NIP-em i adresem.
• Podmiot2: nabywca. Może być identyfikowany NIP-em, numerem VAT UE, numerem zagranicznym albo nie mieć identyfikatora (np. konsument).
• Podmiot3: inne podmioty związane z fakturą, np. odbiorca, faktor, dodatkowy nabywca albo pracownik (rola 11), opisany w tekście o fakturze imiennej.
• Fa: właściwa treść faktury: data wystawienia (P_1), numer (P_2), waluta, pozycje, kwoty netto, VAT i brutto, adnotacje, rodzaj faktury, płatność.
• Stopka i załącznik: informacje dodatkowe oraz opcjonalny załącznik ze złożonymi danymi, który wymaga zgody, jak opisałem w tekście o statusie 415.

Rodzaje faktur w FA(3)

Pole rodzaju faktury rozróżnia fakturę podstawową (VAT), korygującą (KOR), zaliczkową (ZAL), rozliczeniową (ROZ), uproszczoną (UPR) oraz korekty faktur zaliczkowych i rozliczeniowych. Rodzaj ma znaczenie także dla KSeF: razem z NIP-em sprzedawcy i numerem faktury tworzy klucz, po którym system wykrywa duplikaty (więcej w tekście o duplikacie faktury). Zasady korekt opisałem w tekście o korekcie faktury w KSeF.

Wymagania techniczne pliku według dokumentacji KSeF

• Poprawny XML 1.0 w kodowaniu UTF-8 bez znaku BOM.
• Zgodność ze schematem zadeklarowanym przy otwarciu sesji.
• Bez instrukcji przetwarzania XML i bez niezalecanych znaków Unicode z listy W3C.
• Do 1 MB bez załącznika i do 3 MB z załącznikiem.
• Data wystawienia (P_1) nie późniejsza niż data przyjęcia przez KSeF.
• Poprawna suma kontrolna NIP-ów podmiotów (sprawdzana na produkcji).

Znak BOM to trzy niewidoczne bajty na początku pliku, które dodają niektóre edytory i biblioteki. Plik wygląda poprawnie, a KSeF go odrzuca. To jeden z tych błędów, które szybciej znaleźć w kodzie integracji niż w treści faktury.

Skąd sklep bierze plik FA(3)

Sklep internetowy rzadko generuje XML sam. Zwykle dane zamówienia trafiają do programu fakturowego albo modułu KSeF, który buduje plik i go wysyła. Problem zaczyna się, gdy dane w sklepie nie pasują do struktury: brak podziału na adres i kod pocztowy, numer VAT UE wpisany ze spacjami, nazwy produktów z niedozwolonymi znakami. Takie faktury kończą jako błąd 450. Wygląd faktury dla klienta opisałem w tekście o wizualizacji z kodem QR.

Pola, które sprawiają najwięcej kłopotów

• Adres nabywcy: w sklepach często zapisany jednym polem tekstowym, a struktura oczekuje rozdzielonych danych.
• Kod kraju i numer VAT UE: muszą być spójne, a numer bez spacji.
• Jednostki miary: „szt.”, „kpl.”, „usł.” zapisane konsekwentnie, a nie raz tak, raz inaczej.
• Adnotacje: np. mechanizm podzielonej płatności czy zwolnienie z VAT, zaznaczane według rzeczywistej transakcji, a nie domyślnie w szablonie.

Źródło: weryfikacja faktury w dokumentacji KSeF 2.0 i struktura FA(3) publikowana przez Ministerstwo Finansów.