MPP w KSeF: jak uniknąć odrzutu faktury z zał. 15 (i jak wbudować tę regułę w automatyzację faktur)

Z naszego doświadczenia wdrożeniowego wynika jedna rzecz: firmy, które automatyzują fakturowanie, prawie nigdy nie zaczynają od pytania o split payment. Skupiają się na integracji z ERP, mapowaniu pól klienta, generowaniu PDF i wysyłce do KSeF. Logika MPP wpada do backlogu jako „coś do dopisania później”. Problem w tym, że „później” zwykle oznacza po pierwszym odrzucie albo, co gorsza, po pierwszej fakturze, która przeszła przez KSeF bez adnotacji, mimo że powinna ją mieć. To nie jest błąd techniczny, który widać od razu. To błąd, który wychodzi przy kontroli.

Dlatego ten tekst nie jest kolejnym przypomnieniem, czym jest mechanizm podzielonej płatności. Zakładamy, że to wiesz. Chcemy pokazać, gdzie konkretnie automatyzacja faktur najczęściej pomija tę regułę i jak ją wbudować w proces, zamiast dokładać ją jako łatkę.

Dlaczego split payment wywraca scenariusze automatyzacji

Obowiązkowy split payment dotyczy faktur B2B o wartości brutto przekraczającej 15 000 zł, które dokumentują dostawę towarów lub usług wymienionych w załączniku nr 15 do ustawy o VAT. Jeśli te dwa warunki są spełnione, faktura musi zawierać wyrazy „mechanizm podzielonej płatności”, a nabywca musi zapłacić w split payment. To jest prosta reguła na papierze. W praktyce automatyzacji rozpada się na trzy pytania, które trzeba zadać programistycznie, a nie „z głowy”: czy przekroczono próg kwotowy, czy pozycja na fakturze jest towarem lub usługą z załącznika 15, i czy transakcja jest między podatnikami (nie dotyczy sprzedaży do konsumenta).

Większość gotowych scenariuszy, które widzieliśmy, radzi sobie z pierwszym pytaniem, bo to jest proste porównanie liczby. Rozkłada się na drugim. Rozpoznanie, że dana pozycja z systemu ERP albo z arkusza zamówień odpowiada kodowi PKWiU lub CN z załącznika 15, wymaga mapowania, które rzadko istnieje gotowe w integracji faktur. Nikt go nie dostarcza „z pudełka”, bo wymaga znajomości asortymentu konkretnej firmy, a nie tylko znajomości API KSeF.

Co faktycznie trzeba wykryć: załącznik nr 15 w praktyce

Załącznik nr 15 to lista kilkudziesięciu pozycji towarów i usług, które wcześniej (do 2019 roku) były objęte odwrotnym obciążeniem albo odpowiedzialnością solidarną. Zamiast powtarzać tu całą listę z ustawy, warto spojrzeć na kategorie, które najczęściej pojawiają się w realnych procesach fakturowania i które automatyzacje przeoczają:

• wyroby stalowe, złom, metale szlachetne i nieszlachetne (w tym złoto i srebro w określonych formach),
• paliwa, oleje opałowe i smarowe,
• części i akcesoria do pojazdów samochodowych,
• wybrana elektronika: procesory, telefony, konsole do gier, dyski, tablety (dla części pozycji liczy się także jednorodność dostawy w ramach jednej umowy),
• usługi budowlane wymienione w załączniku,
• odpady, złom i surowce wtórne,
• folia typu stretch.

To, co łączy te kategorie, to fakt, że w firmie handlowej czy produkcyjnej rzadko stanowią one 100% asortymentu. Zwykle jest to jedna linia produktowa wśród wielu innych, na przykład dystrybutor elektroniki, który sprzedaje też akcesoria niepodlegające MPP, albo warsztat, który wystawia fakturę za części zamienne razem z usługą serwisową. To właśnie ta mieszanka pozycji na jednej fakturze jest miejscem, gdzie automatyzacja musi podjąć decyzję per pozycja, nie per cała faktura.

Próg 15 000 zł liczy się od całej faktury, nie od pojedynczej pozycji

Częsty błąd w logice, którą widzieliśmy zaimplementowaną, to sprawdzanie progu 15 000 zł dla konkretnej pozycji z załącznika 15, a nie dla sumy brutto całego dokumentu. Przepis mówi o kwocie należności ogółem na fakturze. Jeśli faktura na 20 000 zł brutto zawiera towar z załącznika 15 za 2 000 zł i inne towary za 18 000 zł, obowiązek MPP i adnotacji nadal powstaje, bo liczy się suma całej faktury, a nie wartość samej „wrażliwej” pozycji.

Jak to wygląda w strukturze FA(2) i FA(3) w KSeF

Sama adnotacja tekstowa „mechanizm podzielonej płatności” na wydruku faktury to tylko połowa historii. W strukturze logicznej, którą faktura przyjmuje w KSeF, informacja o MPP musi być też oznaczona jako pole w XML, nie tylko jako tekst widoczny dla człowieka. W strukturze FA(2), a analogicznie w FA(3) używanej w obowiązkowym KSeF, znacznik ten jest osobnym polem w sekcji dotyczącej adnotacji faktury (powiązanym z polem P_18 wskazującym, że do faktury ma zastosowanie mechanizm podzielonej płatności). To oznacza, że sama wartość pozycji na fakturze nie wystarczy, system musi aktywnie ustawić ten znacznik, kiedy warunki są spełnione, i równie aktywnie go nie ustawiać, kiedy nie są, bo błędne oznaczenie w drugą stronę też jest błędem.

Dla zespołów, które budują integrację samodzielnie albo przez narzędzia typu n8n i Make, to jest moment, w którym łatwo przeoczyć różnicę między „wygenerować PDF z dopiskiem” a „ustawić właściwy węzeł w strukturze XML”. Mapowanie pola w strukturze FA musi być efektem tej samej reguły biznesowej, która decyduje o dopisku na fakturze. Jeśli te dwie rzeczy są rozdzielone w kodzie integracji, prędzej czy później rozjedą się w praktyce, bo ktoś zmieni jedną logikę i zapomni o drugiej.

Gdzie konkretnie pękają gotowe scenariusze automatyzacji

Typowy obrazek, jaki widujemy przy wdrożeniach: firma handlowa, która sprzedaje elektronikę i akcesoria, uruchamia automatyzację wystawiania i wysyłki faktur do KSeF oparta na integracji z systemem magazynowym. Scenariusz w n8n albo Make bierze dane z zamówienia, generuje fakturę w strukturze FA, wysyła ją do KSeF i archiwizuje numer referencyjny. Działa świetnie przez pierwsze tygodnie, bo większość zamówień to drobne kwoty poniżej progu albo towary spoza załącznika 15.

Problem wychodzi, kiedy pojawia się większe zamówienie na sprzęt elektroniczny objęty załącznikiem, powyżej 15 000 zł brutto, dla klienta firmowego. Scenariusz wystawia fakturę bez adnotacji MPP, bo nikt nie dodał reguły sprawdzającej kod towaru względem listy z załącznika. Faktura trafia do KSeF, system przyjmuje ją technicznie (walidacja KSeF sprawdza poprawność struktury XML, nie ocenia merytorycznie, czy adnotacja powinna się znaleźć), i dopiero księgowa albo kontrola podatkowa wyłapuje brak oznaczenia. W tym momencie mówimy już nie o błędzie w arkuszu kalkulacyjnym, a o ryzyku dodatkowego zobowiązania VAT.

Ten scenariusz nie jest wyjątkiem. To jest dokładnie ten typ błędu, który pojawia się w większości wdrożeń automatyzacji automatyzacji faktur, jeśli reguła MPP nie jest zaprojektowana jako osobny, testowany krok procesu, a nie dopisek do szablonu dokumentu.

Jak wbudować regułę MPP w proces, zanim stanie się problemem

Podejście, które się u nas sprawdza, to rozbicie logiki na konkretne, testowalne kroki, zamiast jednej dużej funkcji „sprawdź MPP”. W praktyce wygląda to tak:

1. Utrzymujemy osobną tabelę mapującą kody towarów/usług (najczęściej kod PKWiU albo wewnętrzny kod magazynowy) na flagę „podlega załącznikowi 15”. Ta tabela jest własnością klienta, aktualizowana ręcznie przy zmianie asortymentu, nie wyliczana automatycznie z opisu produktu.
2. Reguła sprawdzająca próg liczy sumę brutto całej faktury, nie pojedynczej pozycji, i uwzględnia tylko transakcje B2B (sprawdzenie, że nabywca ma NIP i status podatnika VAT czynnego, najlepiej z weryfikacją w Białej Liście).
3. Jeśli oba warunki są spełnione, proces ustawia jednocześnie dwie rzeczy: tekst adnotacji na wydruku faktury i odpowiedni znacznik w strukturze FA wysyłanej do KSeF. Jedna reguła, dwa miejsca, żeby się nie rozjechały.
4. Przypadki graniczne (niejednoznaczny kod towaru, mieszana faktura z kilkoma pozycjami z różnych kategorii, korekta do faktury, która miała MPP) są oznaczane jako „do potwierdzenia” i trafiają do kolejki do przeglądu przez człowieka, zamiast zostać automatycznie zatwierdzone.
5. Test regresyjny na zestawie przykładowych faktur (z i bez MPP, na granicy progu, z pozycjami mieszanymi) uruchamiany przy każdej zmianie scenariusza, nie tylko przy pierwszym wdrożeniu.

To wymaga więcej pracy na starcie niż „podłącz fakturę do KSeF i gotowe”. Ale koszt tej pracy jest nieporównywalny z kosztem dodatkowego zobowiązania podatkowego albo czasu, jaki biuro rachunkowe traci na ręczne przeglądanie faktur po fakcie. Jeśli firma wystawia dziesiątki faktur dziennie i choćby kilka procent z nich dotyka załącznika 15, to jest dokładnie ten typ miejsca, gdzie szukalibyśmy pierwszej poprawki w istniejącej automatyzacji, zanim dodamy kolejne funkcje.

Co grozi za brak adnotacji MPP

Konsekwencje nie są symboliczne. Jeśli wystawca nie oznaczy faktury adnotacją „mechanizm podzielonej płatności”, mimo że był do tego zobowiązany, naczelnik urzędu skarbowego lub naczelnik urzędu celno-skarbowego może nałożyć na niego dodatkowe zobowiązanie podatkowe w wysokości 30% kwoty podatku przypadającej na towary lub usługi z załącznika 15 wykazane na tej fakturze. Osobna sankcja, również w wysokości 30%, dotyczy nabywcy, który mimo obowiązku nie zapłacił w split payment. To są dwie niezależne ścieżki ryzyka: jedna dla sprzedawcy wystawiającego dokument, druga dla nabywcy realizującego płatność.

Do tego dochodzi odpowiedzialność z Kodeksu karnego skarbowego dla osoby fizycznie odpowiedzialnej za prawidłowość rozliczeń, zwykle głównej księgowej albo osoby zarządzającej finansami, jeśli nieprawidłowości mają charakter powtarzalny i wynikają z zaniechania, a nie jednorazowego błędu. W praktyce to oznacza, że błąd w automatyzacji, który wygląda jak drobna usterka integracji, przy kontroli zamienia się w postępowanie dotyczące konkretnej osoby, nie tylko w korektę deklaracji.

Warto też pamiętać, że KSeF sam z siebie nie jest filtrem merytorycznym dla tej reguły. Walidacja struktury XML sprawdza, czy dokument jest poprawnie zbudowany, nie ocenia, czy adnotacja powinna się tam znaleźć z perspektywy przepisów o VAT. To znaczy, że błędna faktura bez MPP może zostać przyjęta przez system bez żadnego komunikatu ostrzegawczego, co daje złudne poczucie, że wszystko jest w porządku.

Gdzie to się łączy z resztą automatyzacji księgowości

Reguła MPP rzadko żyje w izolacji. Jeśli firma korzysta z automatyzacji procesów w biurze rachunkowym, to ta sama tabela mapująca kody towarów na załącznik 15 powinna być współdzielona między modułem wystawiania faktur sprzedażowych i modułem księgowania faktur kosztowych, bo po stronie zakupowej trzeba równie rzetelnie wychwycić, czy otrzymana faktura powinna mieć adnotację i czy płatność trzeba zrealizować w podzielonej płatności. Rozdzielenie tych dwóch logik na dwa niezależne, niekomunikujące się ze sobą skrypty to prosty sposób na to, żeby jedna strona procesu działała poprawnie, a druga nie, mimo że dotyczą tego samego przepisu.