Po co komu węzeł WarunkiTransakcji? - 3 rzeczy, których nie znajdziesz w podstawowych polach
Tekst opracowany z wykorzystaniem sztucznej inteligencji. Zasady i ograniczenia
Węzeł WarunkiTransakcji pojawił się w schemacie FA(3), który zacznie obowiązywać od 1 lutego 2026 r., jako odpowiedź na potrzeby zaawansowanego obrotu gospodarczego. Wielu użytkowników KSeF 2.0 błędnie zakłada, że skoro pole jest opcjonalne z punktu widzenia przepisów podatkowych, to jego wypełnienie nie niesie za sobą istotnych korzyści operacyjnych. W praktyce gospodarczej brak precyzyjnych danych w tym węźle często kończy się blokadą płatności lub odmową przyjęcia towaru przez centra logistyczne, które operują na sztywnych protokołach przyjęć zewnętrznych.
Brak kodu zamówienia i warunków dostawy sprawia, że faktury są odrzucane przez duże sieci handlowe, które wymagają pełnej automatyzacji procesu uzgadniania dokumentów (tzw. 3-way match). Zgodnie z art. 106k § 2 pkt 4 rozporządzenia w sprawie JPK_VAT, podatnik ma prawo zamieszczać na fakturze informacje dodatkowe, które doprecyzowują treść transakcji. Wprowadzenie tych danych do węzła WarunkiTransakcji pozwala na zachowanie strukturalnej czystości pliku XML, co jest kluczowe dla systemów typu Business Intelligence analizujących przepływy towarowe.
Podmioty powiązane są obowiązane ustalać ceny transferowe na warunkach, które ustaliłyby między sobą podmioty niepowiązane, a precyzyjne określenie warunków dostawy w fakturze ustrukturyzowanej stanowi istotny element dokumentacyjny. Węzeł ten pozwala na uniknięcie sporów z organami podatkowymi, które mogą określić dochód lub stratę pomijając powiązania i na poziomie cen rynkowych, jeśli warunki transakcji są niejasne. Dlatego też przedsiębiorcy powinni zmapować swój proces handlowy i oznaczyć, które dane klient wymaga poza standardem KSeF, a następnie zaimplementować je w dedykowanym węźle, zamiast stosować pola własne, które mogą nie przejść walidacji biznesowej po stronie odbiorcy.
- Incoterms - tag <KodWarunku> służy do określenia międzynarodowych reguł handlowych (np. FCA, EXW, DDP), co definiuje moment przejścia ryzyka i kosztów transportu.
- Termin płatności skontowej - tag <TerminPłatności> umożliwia precyzyjne wskazanie daty, do której nabywca może skorzystać z obniżki ceny w zamian za wcześniejszą zapłatę.
- Numer projektu unijnego - tag <NumerProjektu> jest niezbędny przy rozliczaniu dotacji, gdzie każda faktura musi być bezpośrednio przypisana do konkretnej umowy o dofinansowanie.
Jak waliduje się węzeł WarunkiTransakcji - 30 reguł, które KSeF sprawdza po cichu
System KSeF nie odrzuci faktury ustrukturyzowanej tylko dlatego, że węzeł WarunkiTransakcji pozostał niewypełniony, gdyż technicznie są to pola fakultatywne. Jednak w momencie, gdy podatnik zdecyduje się na ich użycie, system uruchamia rygorystyczny proces weryfikacji zgodności z dokumentacją techniczną schemy FA(3). Przykładowy komunikat błędu: „XML-012: niepoprawna wartość elementu KodWarunku” pojawia się najczęściej, gdy użytkownik wpisze własne oznaczenie zamiast kodu zgodnego ze słownikiem Incoterms 2020 lub normą ISO.
Krajowy System e-Faktur sprawdza około 30 reguł walidacyjnych dotyczących wyłącznie tego węzła, dbając o spójność logiczną dokumentu. Mechanizm walidacji działa w sekwencji: błąd w formacie danych powoduje odrzucenie całego pliku XML, co skutkuje brakiem nadania numeru KSeF i w konsekwencji uznaniem faktury za niewprowadzoną do obrotu prawnego. Organ podatkowy ma prawo do weryfikacji, czy zasady te są zachowane, a błędy w polach takich jak NumerProjektu mogą prowadzić do trudności w identyfikacji płatności przez administrację publiczną.
Podatnicy powinni mieć na uwadze, że maksymalna długość pola NumerProjektu to 40 znaków, a każda próba wpisania dłuższego ciągu znaków zakończy się błędem krytycznym struktury. Format daty w węźle WarunkiTransakcji musi być bezwzględnie zgodny ze standardem ISO 8601 (YYYY-MM-DD), a dopuszczalny zakres dat zdarzenia mieści się w przedziale od 1990-01-01 do 2050-01-01. Przed wysyłką dokumentu do środowiska produkcyjnego zaleca się uruchomienie lokalnego validatora XSD, co pozwoli uniknąć negatywnej weryfikacji przez bramkę MF.
| Pole XML | Dozwolona wartość | Przykład błędu | Źródło |
|---|---|---|---|
| KodWarunku | FCA, CPT, DAP, EXW | Dostawa_Kurier | Słownik Incoterms 2020 |
| TerminPłatności | Format YYYY-MM-DD | 15.03.2026 | ISO 8601 |
| NumerProjektu | Alfanumeryczny (max 40) | Tekst powyżej 40 znaków | Załącznik 2 MF (15 XII 2025) |
| KodWaluty | 3 litery (ISO 4217) | PLN_NOWY | ISO 4217 |
Konfiguracja w ERP - gdzie kliknąć, żeby dane trafiły do WarunkiTransakcji, a nie do pola własnego
Większość błędów wdrożeniowych wynika z błędnego mapowania danych, gdzie istotne informacje handlowe trafiają do sekcji PolaWlasne zamiast do dedykowanego węzła WarunkiTransakcji. Różnica jest zasadnicza: pola własne nie są walidowane przez KSeF i zazwyczaj służą jedynie do wizualizacji na wydruku PDF, podczas gdy dane w WarunkiTransakcji są przetwarzane maszynowo przez systemy księgowe nabywcy. Prawidłowa ścieżka w strukturze XML dla tych danych to /Faktura/Fa/WarunkiTransakcji/KodWarunku, podczas gdy pola ignorowane przez automatyzację znajdują się pod adresem /Faktura/Fa/PolaWlasne.
W systemie Symfonia Handel obsługa węzła WarunkiTransakcji jest dostępna od wersji 2025.3. Aby poprawnie skonfigurować wysyłkę, należy przejść do sekcji: Menu KSeF → Ustawienia pól → sekcja Warunki handlowe → zaznacz KodWarunku i TerminPłatności → zapisz jako szablon. Dzięki temu przy każdej wystawianej fakturze system automatycznie pobierze dane z kartoteki kontrahenta lub zlecenia i umieści je w odpowiednim tagu XML, co eliminuje ryzyko pomyłek ręcznych i zapewnia zgodność z FA(3).
Użytkownicy systemu myERP powinni postępować analogicznie, korzystając z modułu integracyjnego. Należy wybrać ścieżkę: Konfiguracja → Integracje → KSeF 2.0 → Mapowanie → przeciągnij wartość z pola custom do WarunkiTransakcji. Kluczowe jest przetestowanie konfiguracji na fakturze testowej w środowisku UAT KSeF przed 1 lutego 2026 r., aby upewnić się, że mapowanie działa poprawnie. Zapisanie szablonu dla każdego kluczowego odbiorcy znacznie przyspieszy proces fakturowania i zminimalizuje ryzyko odrzucenia dokumentu przez systemy zewnętrzne.
Faktura ustrukturyzowana przyjmuje format pliku XML i posiada przydzielony numer KSeF, co odróżnia ją od tradycyjnych dokumentów elektronicznych. Wykorzystanie wdrożenia KSeF do uproszczenia i ustandaryzowania procesów w firmie pozwala na znaczną redukcję kosztów operacyjnych związanych z obiegiem dokumentów.
FAQ - co jeszcze można, a czego absolutnie nie wolno wpisywać w WarunkiTransakcji
Czy mogę w węźle WarunkiTransakcji wpisać imię i nazwisko kierowcy?
Czy wolno stosować polskie znaki diakrytyczne w kodach warunków?
Czy mogę dodać więcej niż 5 zestawów warunków do jednej faktury?
Czy wolno tam wpisać numer konta bankowego?
Czy mogę użyć tego węzła do faktur B2C?
Redakcja · wszystkie artykuły