• Rafał Sebastian

Automatyzacja płatności dla łańcucha podwykonawców

Poniższy wpis powstał na bazie projektu Transfer Tree [T2], który nie wszedł w fazę realizacji. Autorami projektu są: Rafał Bałdys Rembowski, dr. Marcin Orecki oraz Tomasz Kowalewski i nie łączy już ich umowa NDA, choć łączy ich wola współpracy przy tym projekcie.


Opis problemu

Wymyślony wiele lat temu mechanizm zabezpieczenia podwykonawców (PW), który wymaga, żeby generalny wykonawca (GW) najpierw skredytował roboty, rozwiązał kilka palących problemów, ale stworzył też wiele nowych.

W skrócie, polega on na tym, że wykonawca występując o płatność musi udowodnić, że wcześniej rozliczył się ze swoimi podwykonawcami. W praktyce oznacza to skredytowanie inwestycji mniej więcej na kwartał do przodu, bo taki jest cykl realizacji płatności w robotach budowlanych.

To bardzo nieszczęśliwe rozwiązanie, które skodyfikowano także w prawie zamówień publicznych (art. 437 p.1 u.4), choć było to zupełnie niepotrzebne. Dziś przepis może blokować innowacje i możliwości, jakie stwarza dyrektywa PSD2.

Po co stworzono ten system?

System stworzono po to, żeby zmusić GW do płacenia podwykonawcom za wykonane roboty, bo jakieś 10 lat temu rynek zmagał się z powszechnym zjawiskiem niepłacenia PW przez GW. Wybrano ekstremalne rozwiązanie, żeby z jednej strony uszczelnić ten system, ale z drugiej, żeby był prosty w stosowaniu. Niestety system ma też wady:

  1. Ogranicza płynność wykonawców;

  2. Zamraża miliardy PLN w skali kraju, przez co Wykonawcy mają ograniczone możliwości angażowania się w nowe zadania,

  3. Pośrednio podnosi to koszty inwestycji;

  4. Utrudnia małym podmiotom (głównie PW) rozwój i objęcie roli GW (utrwalanie podziału).

  5. Daje możliwość szantażowania GW przez PW

  6. Nie sprawdza się przy dynamicznych zmianach cen materiałów.

  7. Zwiększa koszty transakcyjne procesów.

Co pomysłodawca chciał osiągnąć.

Tak naprawdę ustawodawca chciał osiągnąć to, żeby wszystkie podmioty na kontrakcie działające jako podwykonawcy otrzymały płatność za wystawione faktury w terminie maksymalnie 30 dni.


Tego niestety nie da się obecnie osiągnąć, bo zatwierdzenie przejściowego świadectwa płatności (PŚP), które poprzedza wystawienie faktury przez GW to prawdziwa mitręga i najmniej efektywny element procesu realizacji inwestycji. Jego największą wadą jest brak możliwości przewidzenia daty jego akceptacji przez inwestora. W efekcie czas pomiędzy wystawieniem PŚP, a otrzymaniem płatności to min. 2 miesiące, a w praktyce 3 miesiące. To z kolei jest konsekwencją powszechnie stosowanych w umowach publicznych zapisów, że czas na zatwierdzenie PŚP liczony jest od nowa, kiedy zmawiający odmówi jego akceptacji. Nie jest więc rzadkością, że wykonawca otrzymuje płatność po 5 miesiącach od sporządzenia PŚP.

Wydaje się wręcz niewiarygodne, że w czasach, kiedy drony półautomatycznie liczą masy ziemne, zdolność gwarancyjną szacują narzędzia wykorzystujące sztuczną inteligencję, a radę budowy można przeprowadzić online (choć niechętnie), przejściowe świadectwo płatności, to znana od blisko 30 lat tabela w Excelu drukowana, kreślona i stemplowana. A to dopiero połowa drogi. Bo dalej są faktury, JPK i złożony system wykonania samej płatności, etc, etc.


To wcale nie musi i nie powinno tak wyglądać.


Technologia i prawo dają dziś możliwości rezygnacji z tych archaicznych rozwiązań i znaczącą poprawę całego systemu prowadzenia rozliczeń na kontrakcie. To oczywiście nie oznacza, że można zastosować jedno narzędzie, które rozwiąże wszystkie problemy. System to wypadkowa stosowania narzędzi i procedur, które wynikają z prawa i praktyki. Zmiana systemu wymaga więc zastosowania nie tylko nowych narzędzi, ale też zmianę procedur oraz zmianę prawa zamówień publicznych w tym zakresie.


Transfer Tree [T2]


Dwa lata temu powstał projekt, którego autorzy postawili sobie za cel stworzenie kompletnego systemu realizacji płatności, który eliminował potrzebę przedpłacania za roboty dla podwykonawców i kredytowania robót oraz konieczność potwierdzania dokonania płatności na rzecz poszczególnych podwykonawców. Ponieważ do realizacji projektu nie udało się zachęcić inwestorów dziś pomysł ten i główne założenia udostępniamy w domenie publicznej w nadziei, że znajdzie się chętny – najlepiej państwowe instytucje, które ten projekt mogłyby zrealizować.


Główne założenia projektu Transfer Tree.


Rozwiązanie oparte jest na dyrektywie PSD2 i technologii rozproszonego rejestru, czyli tzw. blockchain i smart contract, choć nie jest to warunek konieczny.


System opiera się na połączeniu warunków kontraktu z narzędziami do rejestracji podwykonawców (na danym kontrakcie) oraz realizacji płatności. Każdy kontrakt budowlany wymagałby zawarcie równoległego „smart kontraktu” służącego do rejestracji podwykonawców i akceptacji i zatwierdzania płatności oraz oddzielnej aplikacji obsługiwanej przez podmiot uprawniony podmiot do przeprowadzania operacji bankowych (tzw. PISP wg. Dyrektywy PSD2 ang. Payment Initiation Service Providers). Po zatwierdzeniu danego podwykonawcy staje się on jednocześnie stroną „smart kontraktu” w strukturze drzewa podwykonawców. Po wystawieniu faktury dany podwykonawca rejestruje swoją płatność w „smart kontrakcie”, tak jak pozostali wykonawcy, usługodawcy i dostawcy oraz definiuje (poprzez PISP) swoją płatność na rzecz kolejnego podwykonawcy, który funkcjonuje jako podwykonawca zatwierdzony przez inwestora.

Mechanizm zaprojektowany jest w taki sposób, że płatność na rzecz PW dokonuje się automatycznie bez możliwości ingerencji w dokonane już zlecenie, przy czym środki przepływające w tym strumieniu są niejako znaczone identyfikatorem całej operacji.

Dla uproszenia tego opisu przyjmujmy, że na tym etapie nie dochodzi do sporów dot. danej płatności np. co do zakresu lub wysokości faktury.

Jeżeli wszystkie węzły tego drzewa utworzonego przez samrt contract, czyli wszyscy podwykonawcy potwierdziliby zasadność swoich płatności oraz zdefiniowali przelewy na rzecz podwykonawców, wówczas Inwestor posiadający najwyższy przywilej w takim systemie płatności może zrealizować płatność na rzecz GW mając absolutną pewność, że wszyscy podwykonawcy zostaną opłaceni zgodnie ze zdefiniowanymi przelewami.

Strony smart contractu (wszyscy PW) nie widzą wartości swoich umów ani przelewów, widzą tylko wartości pomiędzy podmiotami, które zawarły ze sobą umowę podwykonawczą.

Zgodnie ze zdefiniowanymi planami przelewów instytucja PISP (inicjator operacji płatniczej) dokonuje operacji uznania i obciążenia poszczególnych PW w drzewie płatności.

W przypadku PW, których konta są zajęte lub są obciążone innymi tytułami, wó

wczas informacje te – dzięki usługom dostarczanym przez PISP są uwzględniane natychmiastowo i strony mogą opracować odpowiednie scenariusze działań jeszcze przed upływem terminu płatności.



Oczywiście wcześniej dokonane płatności identyfikują się w systemie jako już zrealizowane. Jeżeli przerwa nastąpiła np. na poziomie pomiędzy PW 3 i 4 rzędu np. (tj. drugi zapłacił trzeciemu, ale ten już nie zapłacił kolejnemu / kolejnym), wówczas inwestor i GW mogą szybciej podejmować działania zmierzające do uruchomienia płatności bezpośrednich.


Zalety systemu:

  • Automatyczna rejestracja i ewidencja aktualnej listy podwykonawców

  • Bieżący dostęp inwestora i GW do aktualnego stanu płatności (wykonane / niewykonane)

  • Weryfikacja blokad na koncie w strukturze podwykonawców w czasie rzeczywistym

  • Realizacja wszystkich płatności w drzewie podwykonawców zrealizowana natychmiastowo po realizacji płatności na rzecz GW

  • Obniżenie kosztów transakcyjnych procesów realizacji inwestycji.

  • GW uwolnić zamrożone środki konieczne w dotychczasowym modelu


System nie dzieli płatności należnej GW na wszystkich podwykonawców zgodnie w wysokościami faktur, tj. nie realizuje płatności bezpośredniej. Dzięki operatorowi PISP kwota należna GW wypłacana jest jemu na konto, a następnie realizowane są płatności na rzecz PW pierwszego rzędu, następnie operator PISP realizuje płatności z kont PW drugiego rzędu i tak dalej – wszystko zgodnie z zasadami rachunkowości.

Technologicznie i prawnie nie ma przeszkód, żeby zrealizować ten projekt. Z uwagi jednak na wykorzystanie narzędzi elektronicznych płatności związanych z dyrektywą PSD2 powiązanej z mechanizmem płatności na rzecz podwykonawców konieczne jest uwzględnienie tego mechanizmu w warunkach kontraktu łączącego strony oraz wyjęcie z prawa zamówień publicznych zapisów.



Rafał Bałdys Rembowski



80 wyświetleń7 komentarzy

Powiązane posty

Zobacz wszystkie