Struktura FA(3) – co zawiera i czego nie zawiera

Czym jest schemat FA(3)

FA(3) to oficjalna struktura logiczna faktury ustrukturyzowanej dla KSeF. To właśnie ona określa, jak ma wyglądać plik XML faktury, żeby system mógł go przyjąć.

W praktyce FA(3) definiuje m.in.:

• jakie elementy są obowiązkowe,
• jakie elementy są opcjonalne albo fakultatywne,
• jaki jest format danych,
• jakie wartości są dopuszczalne w poszczególnych polach.

Jeżeli plik XML nie jest zgodny z wymaganym schematem, KSeF go nie przyjmie.

W starszych materiałach można jeszcze spotkać odniesienia do FA(2). Natomiast dla docelowego KSeF 2.0 i okresu obligatoryjnego punktem odniesienia jest FA(3).

Główne sekcje FA(3)

Struktura dokumentu

Główna struktura FA(3) składa się z ośmiu elementów:

Faktura
├── Naglowek           (dane techniczne dokumentu)
├── Podmiot1           (sprzedawca) - obowiązkowy
├── Podmiot2           (nabywca) - obowiązkowy
├── Podmiot3           (inny podmiot) - fakultatywny
├── PodmiotUpowazniony (podmiot upoważniony) - opcjonalny
├── Fa                 (treść faktury) - obowiązkowy
├── Stopka             (pozostałe dane) - fakultatywna
└── Zalacznik          (załącznik do faktury) - fakultatywny

Najważniejsze z punktu widzenia zwykłej faktury są cztery elementy obowiązkowe:

• Naglowek
• Podmiot1
• Podmiot2
• Fa

Sekcja Naglowek – dane techniczne

Naglowek nie opisuje samej transakcji. Zawiera dane techniczne pliku XML.

Najważniejsze pola

Co warto wiedzieć

• DataWytworzeniaFa dotyczy utworzenia pliku XML, a niekoniecznie daty wystawienia faktury.
• Ta data może być inna niż data z pola P_1.
• W praktyce zapisuje się ją z oznaczeniem czasu, np. Z dla UTC.

Czego NIE zawiera Naglowek

Naglowek nie zawiera np.:

• historii zmian dokumentu,
• danych osoby, która fizycznie kliknęła „wyślij”,
• informacji, skąd geograficznie wysłano plik.

Sekcja Podmiot1 – sprzedawca

Podmiot1 opisuje sprzedawcę. To element obowiązkowy.

W FA(3) polem kluczowym dla Podmiot1 jest NIP. Bez niego wystawienie faktury w KSeF co do zasady nie będzie możliwe.

Przykład uproszczony

<Podmiot1>
  <DaneIdentyfikacyjne>
    <NIP>1111111111</NIP> <!-- przykład fikcyjny -->
    <Nazwa>Przykładowa Spółka z o.o.</Nazwa>
  </DaneIdentyfikacyjne>
  <Adres>
    <KodKraju>PL</KodKraju>
    <AdresL1>ul. Przykładowa 1, 00-001 Warszawa</AdresL1>
  </Adres>
</Podmiot1>

Typowe pola

Czego NIE zawiera Podmiot1

Sam schemat nie potwierdza np.:

• czy sprzedawca jest aktywnym podatnikiem VAT,
• czy firma faktycznie prowadzi działalność,
• czy rachunek do zapłaty należy do sprzedawcy,
• czy nazwa i adres są zgodne z danymi z rejestrów.

To trzeba sprawdzać poza samym schematem, np. w rejestrach publicznych i własnych procedurach.

Sekcja Podmiot2 – nabywca

Podmiot2 opisuje nabywcę. To także element obowiązkowy.

Nie warto upraszczać tej sekcji do jednego schematu typu „zawsze NIP + nazwa + adres”, bo FA(3) przewiduje kilka wariantów.

Najczęstsze warianty

Ważna praktyczna uwaga

Jeżeli nabywca ma polski NIP, to dla udostępnienia faktury temu nabywcy znaczenie ma wskazanie go właśnie w polu NIP, a nie w polach NrVatUE lub NrID.

Czego NIE robi Podmiot2

Sama obecność danych nabywcy w XML nie oznacza jeszcze, że:

• to właściwy kontrahent,
• transakcja była uzgodniona,
• osoba po stronie firmy rzeczywiście coś zamówiła.

To już obszar kontroli biznesowej, a nie samego schematu.

Sekcja Fa – treść faktury

Fa to najważniejsza część całego dokumentu. Tu znajdują się dane handlowe, podatkowe i rozliczeniowe.

Wybrane pola często spotykane na zwykłych fakturach

Pola kwotowe – przykład poglądowy

<P_13_1>10000.00</P_13_1> <!-- netto dla 23% -->
<P_13_2>5000.00</P_13_2>  <!-- netto dla 8% -->
<P_13_3>2000.00</P_13_3>  <!-- netto dla 5% -->
<P_13_4>1000.00</P_13_4>  <!-- netto dla 0% -->
<P_13_6>500.00</P_13_6>   <!-- netto ZW -->
<P_13_7>300.00</P_13_7>   <!-- netto NP -->

<P_14_1>2300.00</P_14_1>  <!-- VAT 23% -->
<P_14_2>400.00</P_14_2>   <!-- VAT 8% -->
<P_14_3>100.00</P_14_3>   <!-- VAT 5% -->
<P_14_4>0.00</P_14_4>     <!-- VAT 0% -->

<P_15>21600.00</P_15>     <!-- kwota należności ogółem -->

O czym trzeba pamiętać

Schemat mówi, jakie pola istnieją i w jakim formacie mają być zapisane, ale to nie jest to samo co pełna kontrola sensu biznesowego dokumentu.

Na przykład:

• poprawny format kwoty nie oznacza jeszcze, że kwota jest uzasadniona,
• poprawny numer faktury nie oznacza jeszcze, że transakcja była realna,
• poprawnie wpisana waluta nie oznacza jeszcze, że ceny są zgodne z ustaleniami.

Sekcja FaWiersz – pozycje faktury

To właśnie tutaj opisuje się towary lub usługi.

Uproszczony przykład

<FaWiersz>
  <NrWierszaFa>1</NrWierszaFa>
  <P_7>Usługa projektowa</P_7>
  <P_8A>godz.</P_8A>
  <P_8B>100</P_8B>
  <P_9A>100.00</P_9A>
  <P_11>10000.00</P_11>
  <P_12>23</P_12>
</FaWiersz>

Wybrane pola

Ważne zastrzeżenie

W FA(3) nie wszystkie pola pozycji są „sztywno obowiązkowe” w każdej sytuacji. Część z nich zależy od rodzaju faktury i podstawy prawnej.

Dlatego bezpieczniej myśleć tak:

• są pola, które na zwykłej fakturze sprzedażowej pojawiają się prawie zawsze,
• ale są też wyjątki, np. dla faktur uproszczonych, procedur marży albo niektórych korekt.

Z tego powodu nie warto budować własnego walidatora wyłącznie na prostym założeniu „to pole zawsze musi być”.

Sekcja Platnosc

Sekcja Platnosc jest przydatna, ale nie zawsze musi wystąpić.

Może zawierać np.:

• termin płatności,
• formę płatności,
• rachunek bankowy,
• informacje o płatnościach częściowych.

Przykład uproszczony

<Platnosc>
  <TerminPlatnosci>
    <Termin>2026-04-15</Termin>
  </TerminPlatnosci>
  <FormaPlatnosci>6</FormaPlatnosci>
  <RachunekBankowy>
    <NrRB>PL00FIKCYJNYRACHUNEK000000000000</NrRB>
  </RachunekBankowy>
</Platnosc>

Formy płatności

W polu FormaPlatnosci używa się kodów od 1 do 7.

Ważna uwaga o rachunku bankowym

Jeżeli podatnik wypełnia element RachunekBankowy, to musi podać wymagane pole NrRB.

Ale sam fakt, że rachunek pojawił się w XML, nie oznacza jeszcze, że:

• rachunek należy do sprzedawcy,
• rachunek jest poprawny z punktu widzenia białej listy VAT,
• płatność na ten rachunek jest bezpieczna.

To trzeba sprawdzić osobno.

Sekcja Adnotacje

Adnotacje obejmują różne oznaczenia szczególne, np.:

• P_16 – metoda kasowa,
• P_17 – samofakturowanie,
• P_18 – odwrotne obciążenie,
• P_18A – mechanizm podzielonej płatności,
• pola dotyczące zwolnień i procedur szczególnych.

Przykład poglądowy

<Adnotacje>
  <P_16>2</P_16>
  <P_17>2</P_17>
  <P_18>2</P_18>
  <P_18A>2</P_18A>
  <Zwolnienie>
    <P_19N>1</P_19N>
  </Zwolnienie>
</Adnotacje>

Te pola mają znaczenie podatkowe, ale nadal nie rozwiązują same z siebie problemu bezpieczeństwa faktury.

Czego NIE ZAWIERA schemat FA(3)

To bardzo ważne: nawet poprawna faktura FA(3) może nadal budzić ryzyko biznesowe.

Dane, których zwykle brakuje albo nie są wystandaryzowane w sposób wystarczający

Co FA(3) rzeczywiście daje

FA(3) pomaga sprawdzić przede wszystkim, czy dokument jest przygotowany w poprawnej strukturze.

W praktyce oznacza to, że można zweryfikować m.in.:

1. czy XML ma prawidłową budowę,
2. czy wymagane elementy schematu występują,
3. czy wartości mają dopuszczalny format,
4. czy dokument odpowiada właściwej strukturze logicznej.

Czego FA(3) nie gwarantuje

Sam schemat FA(3) nie gwarantuje, że:

1. transakcja naprawdę miała miejsce,
2. towar został dostarczony,
3. usługa została wykonana,
4. rachunek bankowy jest bezpieczny do zapłaty,
5. kontrahent jest wiarygodny,
6. faktura odpowiada temu, co zostało uzgodnione handlowo.

Ważne rozróżnienie: schemat a pełna kontrola

Warto odróżnić dwie rzeczy:

• zgodność ze schematem FA(3),
• pełną kontrolę biznesową i antyfraudową.

To nie jest to samo.

Nawet jeśli plik przejdzie walidację techniczną, nadal warto sprawdzić po swojej stronie np.:

• zgodność z zamówieniem,
• zgodność z umową,
• sensowność kwot,
• rachunek bankowy,
• historię kontrahenta,
• nietypowe wzorce zachowania.

Gdzie najczęściej powstają luki bezpieczeństwa

1. Brak powiązania z zamówieniem

Faktura może być technicznie poprawna, ale w firmie może nie być żadnego zamówienia, które ją uzasadnia.

2. Ogólnikowy opis pozycji

Opis typu Usługi, Obsługa, Prace dodatkowe może przejść technicznie, ale niewiele mówi z perspektywy kontroli.

3. Brak weryfikacji rachunku

Sam fakt wpisania rachunku do XML nie potwierdza, że to właściwy rachunek do płatności.

4. Brak oceny kontekstu biznesowego

Schemat nie wie, czy:

• kontrahent jest nowy,
• kwota odbiega od historii,
• faktura przyszła o nietypowej porze,
• opis nie pasuje do profilu działalności.

To już obszar analizy ryzyka.

Powiązane artykuły

• Jak czytać XML faktury z KSeF – praktyczne parsowanie
• Jak działa walidacja techniczna faktury w KSeF – proces walidacji
• Co KSeF sprawdza, a czego nie sprawdza – zakres kontroli

FAQ

Czy FA(3) to oficjalna, aktualna struktura dla KSeF 2.0?

Tak. To docelowa struktura logiczna opublikowana przez Ministerstwo Finansów dla KSeF 2.0.

Czy numer KSeF jest elementem faktury FA(3)?

Nie. Numer KSeF jest nadawany przez system po przyjęciu faktury i nie stanowi pola samego pliku XML faktury.

Czy mogę dodać własne pola do XML faktury?

Nie w głównej strukturze FA(3). To schemat zamknięty. Możesz jedynie korzystać z przewidzianych przez niego pól.

Czy rachunek bankowy jest obowiązkowy?

Nie zawsze. To zależy od tego, jak faktura została wystawiona i jakie informacje podatnik chce lub musi podać. Jeżeli jednak wypełniasz element RachunekBankowy, to musisz podać wymagane pola tego elementu.

Czy poprawna faktura FA(3) jest automatycznie „bezpieczna”?

Nie. Poprawność techniczna to nie to samo co bezpieczeństwo biznesowe. Dlatego poza walidacją KSeF warto stosować dodatkową kontrolę kontrahenta, rachunku i samej transakcji.

Gdzie znaleźć aktualną dokumentację?

Najlepiej korzystać z oficjalnych materiałów Ministerstwa Finansów: strony KSeF, sekcji „Pliki do pobrania KSeF 2.0”, broszury informacyjnej FA(3) oraz publikacji w CRD.

Treść ma charakter informacyjny i edukacyjny. Nie stanowi porady prawnej ani podatkowej.