Najważniejsze na dziś: przepisy o CRU JSFP nie narzucają jednego modelu technicznego lokalnego rejestru umów. W praktyce pytanie brzmi nie „co jest zgodne z ustawą?”, ale który model pozwoli wykonać obowiązek bez chaosu organizacyjnego, opóźnień i utraty kontroli nad danymi.
Co przepisy naprawdę wymagają
Przepisy o CRU JSFP nie narzucają jednostce jednego modelu technicznego prowadzenia lokalnego rejestru umów. Nie wskazują, że jednostka musi korzystać z Excela, systemu obiegu dokumentów, systemu finansowo-księgowego albo dedykowanego systemu do ewidencji umów.
Wymagają natomiast, aby jednostka była zdolna do udostępniania i aktualizacji informacji o umowach w Centralnym Rejestrze Umów JSFP.
Rozporządzenie z dnia 30 marca 2026 r. przewiduje dwa podstawowe sposoby pracy z systemem centralnym: pracę użytkowników przez konta w systemie CRU JSFP oraz zasilanie systemu centralnego danymi z innych systemów teleinformatycznych przez API.
Excel jako rozwiązanie przejściowe
Excel może wystarczyć jako rozwiązanie przejściowe tylko w bardzo małej jednostce i tylko wtedy, gdy liczba umów jest niewielka, proces jest scentralizowany, a jedna komórka faktycznie odpowiada za całość przygotowania, weryfikacji i publikacji danych.
Arkusz kalkulacyjny może pomóc w uporządkowaniu danych: numerów umów, dat, stron, wartości, statusów i podstawowych informacji o publikacji. Dobrze sprawdza się jako roboczy bufor albo narzędzie inwentaryzacyjne na etapie przygotowania jednostki do CRU JSFP.
Problem zaczyna się wtedy, gdy Excel staje się docelowym rejestrem. Arkusz słabo radzi sobie z historią zmian, uprawnieniami, rozliczalnością operacji, zatwierdzaniem danych, kontrolą terminów, ograniczeniami jawności i pracą wielu osób jednocześnie.
System lokalny jako model docelowy dla większości jednostek
System lokalny jest zwykle lepszym wyborem, gdy jednostka ma większy wolumen umów, kilka komórek merytorycznych, potrzebę akceptacji danych, historię operacji, obieg dokumentów, kontrolę terminów oraz konieczność rozdzielenia ról.
Dobrze zaprojektowany system lokalny pozwala przygotować dane o umowie jeszcze przed publikacją w CRU JSFP. Może wspierać kwalifikację umowy, ustalanie wartości, oznaczanie statusu, obsługę aneksów, wypowiedzeń, cesji i korekt błędów oraz wyłączeń jawności.
- jeden rejestr umów zamiast wielu arkuszy,
- historię zmian i rozliczalność użytkowników,
- statusy pracy nad umową,
- kontrolę terminu publikacji i aktualizacji,
- obsługę aneksów, wypowiedzeń, cesji i korekt,
- ścieżkę akceptacji danych przed publikacją,
- kontrolę wyłączeń jawności,
- raportowanie dla kierownictwa,
- możliwość późniejszej integracji z CRU JSFP.
Integracja z CRU JSFP
Integracja z CRU JSFP jest najbardziej sensowna wtedy, gdy jednostka ma już uporządkowany lokalny rejestr umów, system ERP, system obiegu dokumentów albo inne źródło danych, z którego można wiarygodnie przekazywać informacje do systemu centralnego.
Podstawę techniczną daje § 12 rozporządzenia, który przewiduje, że system CRU JSFP może być zasilany danymi z innych systemów teleinformatycznych za pomocą interfejsu programistycznego aplikacji udostępnionego w BIP Ministerstwa Finansów.
Ważne zastrzeżenie: integracja nie rozwiązuje problemów merytorycznych. Jeżeli jednostka źle kwalifikuje umowy, nie ma spójnej reguły ustalania wartości, nie kontroluje statusów albo nie ma procedury ograniczeń jawności, API tylko przyspieszy przekazywanie błędnych danych.
Porównanie modeli
Excel
Kiedy ma sens: bardzo mała jednostka, niewielka liczba umów, rozwiązanie przejściowe.
Zalety: szybki start, niski koszt, łatwe porządkowanie danych.
Ryzyka: brak dobrej historii zmian, słaba kontrola uprawnień, ryzyko wielu wersji pliku, brak workflow.
System lokalny
Kiedy ma sens: większość urzędów i większych JSFP.
Zalety: kontrola procesu, role, statusy, historia zmian, raporty, obsługa akceptacji.
Ryzyka: wymaga wdrożenia, konfiguracji i odpowiedzialnego właściciela procesu.
Integracja z CRU JSFP
Kiedy ma sens: jednostka z uporządkowanymi danymi i większym wolumenem umów.
Zalety: brak ręcznego przepisywania, większa automatyzacja, lepsza skalowalność.
Ryzyka: automatyzuje również błędy, jeżeli proces źródłowy jest zły.
Jak wybrać właściwy model
Excel może być wystarczający, jeżeli jednostka ma niewiele umów, jeden punkt odpowiedzialności i prostą strukturę organizacyjną. Trzeba jednak uczciwie powiedzieć: to raczej rozwiązanie przejściowe, a nie docelowy model zarządzania obowiązkiem CRU JSFP.
System lokalny jest najlepszym wyborem dla większości urzędów, uczelni, instytucji kultury, jednostek budżetowych i większych organizacji publicznych. Pozwala uporządkować dane, proces, odpowiedzialność, historię zmian i raportowanie.
Integracja z CRU JSFP jest najlepsza wtedy, gdy jednostka nie chce przepisywać danych ręcznie i ma już uporządkowany system źródłowy. Najczęściej jednak nie warto wybierać między systemem lokalnym a integracją. Najlepszy model to połączenie obu podejść: system lokalny porządkuje dane i workflow, a integracja eliminuje ręczne przepisywanie do CRU JSFP.
Rekomendacja wdrożeniowa
Rekomendacja jest prosta: Excel może być narzędziem pomocniczym, ale nie powinien być docelową odpowiedzią dla średniej albo dużej jednostki, która chce utrzymać jawność, historię zmian, kontrolę terminów i odpowiedzialność operacyjną.
- lokalny rejestr umów jako źródło uporządkowanych danych,
- jasno opisany workflow kwalifikacji, weryfikacji i akceptacji,
- historia zmian i rozliczalność użytkowników,
- kontrola wyłączeń jawności,
- monitoring terminów publikacji i aktualizacji,
- raportowanie dla kierownictwa,
- możliwość integracji z CRU JSFP przez API.
Najczęściej największym ryzykiem nie jest sam wybór narzędzia, ale brak procesu. Jeżeli jednostka nie wie, kto kwalifikuje umowę, kto ustala wartość, kto zatwierdza ograniczenie jawności i kto odpowiada za aktualizację danych, żaden arkusz ani żadna integracja nie rozwiąże problemu.
Źródła
- Art. 34a ustawy o finansach publicznych — obowiązek udostępniania i aktualizacji informacji o umowach.
- Art. 34b ustawy o finansach publicznych — system teleinformatyczny CRU JSFP, konta, odpowiedzialność za dane i dostęp publiczny.
- § 4–10 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — uwierzytelnianie, konta i role użytkowników.
- § 12 rozporządzenia Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. — możliwość zasilania CRU JSFP danymi z innych systemów teleinformatycznych przez API.
- Komunikat Ministerstwa Finansów z 10 marca 2026 r. o udostępnieniu środowiska testowego systemu CRU JSFP.
- Komunikat Ministerstwa Finansów z 11 marca 2026 r. o udostępnieniu API do systemu CRU JSFP.