Rejestr umów w urzędzie — Excel, system lokalny czy integracja z CRU?

Wdrożenie CRU JSFP zmienia sposób myślenia o rejestrze umów w jednostkach sektora finansów publicznych. Dotychczas w wielu urzędach, jednostkach budżetowych, instytucjach kultury, uczelniach i innych organizacjach publicznych rejestr umów był prowadzony w Excelu, prostym arkuszu, systemie obiegu dokumentów albo w kilku rozproszonych miejscach jednocześnie.

Przy obowiązkach związanych z CRU JSFP takie podejście może szybko okazać się niewystarczające. Problem nie polega tylko na tym, że trzeba przekazać dane do systemu centralnego. Problem polega na tym, że dane muszą być kompletne, aktualne, zatwierdzone, możliwe do skontrolowania i później aktualizowane po zmianach umowy.

Dlatego pytanie nie brzmi wyłącznie:

w czym prowadzić rejestr umów?

Lepsze pytanie brzmi:

jaki model pracy pozwoli jednostce bezpiecznie kwalifikować umowy, przygotowywać dane, kontrolować terminy, ograniczać jawność i aktualizować informacje w CRU JSFP?

Najkrótsza odpowiedź

Przepisy o CRU JSFP nie narzucają jednostce jednego lokalnego narzędzia do prowadzenia rejestru umów. Jednostka może korzystać z Excela, systemu lokalnego, systemu finansowo-księgowego, EZD, dedykowanej ewidencji umów albo integracji przez API.

Nie każdy model daje jednak ten sam poziom kontroli.

W praktyce:

• Excel może być rozwiązaniem przejściowym dla bardzo małej jednostki albo narzędziem pomocniczym na etapie inwentaryzacji danych,
• system lokalny jest najczęściej najlepszym modelem docelowym dla jednostek, które chcą kontrolować proces, role, akceptację, historię zmian i raportowanie,
• integracja z CRU JSFP przez API ma sens wtedy, gdy jednostka ma już uporządkowane dane i stabilny proces źródłowy.

Najczęściej najlepszym rozwiązaniem nie jest wybór „Excel albo API”, lecz model etapowy:

Co przepisy naprawdę wymagają?

Przepisy dotyczące CRU JSFP wymagają, aby jednostka była zdolna do udostępniania i aktualizacji informacji o umowach w Centralnym Rejestrze Umów JSFP.

Obowiązek dotyczy informacji o umowie zawartej przez jednostkę sektora finansów publicznych albo na jej rzecz, jeżeli umowa spełnia warunki określone w przepisach. W CRU JSFP udostępnia się między innymi numer umowy, datę zawarcia, okres obowiązywania, oznaczenie stron, przedmiot umowy, wartość, informację o finansowaniu ze środków europejskich, status, dane dotyczące wyłączeń jawności oraz podstawę aktualizacji.

Informacje trzeba udostępniać i aktualizować bez zbędnej zwłoki, nie później niż w terminie 30 dni od dnia zawarcia umowy albo od dnia zaistnienia zmiany informacji o umowie.

Przepisy nie wskazują jednak, że jednostka musi prowadzić lokalny rejestr umów w konkretnym narzędziu. Nie ma obowiązku korzystania z Excela, konkretnego systemu obiegu dokumentów, systemu finansowo-księgowego ani dedykowanego systemu do ewidencji umów.

To oznacza, że wybór modelu lokalnego jest decyzją organizacyjną i techniczną jednostki.

Ale uwaga: brak narzuconego narzędzia nie oznacza braku odpowiedzialności. Jednostka nadal musi mieć proces, który pozwala terminowo, poprawnie i bezpiecznie przygotować dane do CRU JSFP.

Dlaczego zwykły rejestr umów przestaje wystarczać?

Tradycyjny rejestr umów często służył głównie do zapisania podstawowych informacji:

• numeru umowy,
• kontrahenta,
• daty,
• wartości,
• komórki organizacyjnej,
• krótkiego opisu,
• miejsca przechowywania dokumentu.

Przy CRU JSFP to za mało.

Nowy proces wymaga dodatkowo ustalenia:

• czy umowa podlega publikacji,
• czy umowa stanowi zamówienie w rozumieniu Pzp,
• czy nie zachodzi ustawowe wyłączenie,
• czy część informacji wymaga ograniczenia jawności,
• kto zatwierdził dane,
• jaka wartość ma zostać przekazana do CRU JSFP,
• czy wartość uwzględnia opcje i wznowienia,
• czy umowa jest finansowana ze środków europejskich,
• jaki jest status publikacji,
• czy termin 30 dni jest zagrożony,
• czy aneks wymaga aktualizacji danych,
• kto i kiedy zmienił dane,
• czy publikacja została wykonana,
• czy system centralny zwrócił błąd.

To już nie jest tylko ewidencja. To proces zarządzania informacją o umowie.

Model 1: Excel jako rozwiązanie przejściowe

Excel może być przydatny, ale trzeba uczciwie określić jego rolę.

Arkusz kalkulacyjny może pomóc w szybkim uporządkowaniu danych, przygotowaniu inwentaryzacji umów, sprawdzeniu braków, stworzeniu listy kontrolnej albo zbudowaniu pierwszego rejestru roboczego.

Excel może mieć sens, gdy jednostka:

• ma bardzo mało umów,
• ma prostą strukturę organizacyjną,
• ma jeden punkt odpowiedzialności za umowy,
• nie potrzebuje rozbudowanej ścieżki akceptacji,
• nie pracuje równolegle na wielu wersjach danych,
• traktuje arkusz jako rozwiązanie przejściowe,
• nie planuje od razu integracji przez API.

W małej jednostce Excel może więc być pierwszym krokiem. Może pomóc zobaczyć, jakie dane są dostępne, czego brakuje i jakie przypadki będą problematyczne.

Ryzyka Excela

Problem zaczyna się wtedy, gdy Excel staje się docelowym rejestrem dla jednostki, która ma większy wolumen umów, wiele komórek organizacyjnych i potrzebę kontroli procesu.

Najczęstsze ryzyka Excela to:

• wiele wersji tego samego pliku,
• brak dobrej historii zmian,
• trudna kontrola uprawnień,
• brak rozliczalności działań użytkowników,
• brak ścieżki akceptacji,
• brak statusów publikacji,
• brak kontroli terminu 30 dni,
• trudna obsługa aneksów i korekt,
• ryzyko przypadkowego nadpisania danych,
• brak automatycznej walidacji wymaganych pól,
• trudna kontrola wyłączeń jawności,
• brak powiązania z dokumentami źródłowymi,
• słabe raportowanie dla kierownictwa,
• brak dobrej obsługi błędów,
• brak naturalnej integracji z CRU JSFP.

Excel nie jest zły sam w sobie. Problem polega na tym, że Excel nie pilnuje procesu. A przy CRU JSFP proces będzie ważniejszy niż sam wykaz umów.

Kiedy Excel może jeszcze wystarczyć?

Excel może być wystarczający, jeżeli jednostka ma niewielką liczbę umów i bardzo prosty obieg decyzyjny.

Przykładowo może się sprawdzić, gdy:

• umowy są zawierane sporadycznie,
• jedna komórka centralnie prowadzi wszystkie sprawy,
• nie ma wielu użytkowników,
• nie ma rozbudowanego obiegu akceptacji,
• liczba aktualizacji po aneksach jest niewielka,
• jednostka nie planuje automatyzacji,
• kierownictwo akceptuje ograniczenia tego modelu.

Nawet wtedy warto stosować arkusz według ustalonego wzoru, z jasnymi kolumnami, kontrolą wersji, kopią bezpieczeństwa i opisem odpowiedzialności.

Excel bez procedury to nie rejestr umów. To lista, która może się szybko rozjechać.

Model 2: system lokalny jako model docelowy

Dla większości jednostek bardziej bezpiecznym modelem będzie lokalny system do ewidencji umów.

System lokalny nie musi od razu oznaczać pełnej integracji z CRU JSFP. Jego podstawową rolą jest uporządkowanie danych i procesu wewnątrz jednostki.

Dobry lokalny rejestr umów powinien wspierać:

• kwalifikację umowy do CRU JSFP,
• oznaczenie umów wyłączonych,
• ocenę ograniczeń jawności,
• przygotowanie danych wymaganych do publikacji,
• ustalanie wartości umowy,
• obsługę umów w walutach obcych,
• obsługę opcji, wznowień i umów bezterminowych,
• statusy pracy nad umową,
• akceptację danych przed publikacją,
• historię zmian,
• role i uprawnienia,
• rejestr aneksów,
• obsługę wypowiedzeń, rozwiązania umowy, cesji i korekt,
• monitoring terminu 30 dni,
• raportowanie dla kierownictwa,
• przygotowanie do późniejszej integracji przez API.

System lokalny daje coś, czego Excel zwykle nie zapewnia: kontrolę nad cyklem życia umowy.

Co powinien mieć dobry system lokalny?

Dobry system lokalny nie powinien być tylko elektroniczną tabelą. Powinien wspierać realny proces pracy.

1. Jeden rejestr umów

Jedno miejsce, w którym jednostka widzi umowy, aneksy, statusy, historię i dane potrzebne do CRU JSFP.

2. Role i uprawnienia

Inne prawa powinien mieć użytkownik wprowadzający dane, inne osoba weryfikująca, inne publikująca, a inne administrator.

3. Workflow akceptacji

Dane do CRU JSFP powinny przejść przez etap przygotowania, weryfikacji i zatwierdzenia.

4. Historia zmian

System powinien pokazywać, kto zmienił dane, kiedy, co zmienił i dlaczego.

5. Kontrola terminów

Jednostka powinna widzieć umowy zbliżające się do terminu publikacji albo aktualizacji.

6. Obsługa wyłączeń jawności

System powinien pozwalać zapisać podstawę prawną nieudostępnienia informacji oraz osobę albo organ dokonujący wyłączenia.

7. Raportowanie

Kierownictwo powinno widzieć zaległości, ryzyka, umowy oczekujące, błędy i statusy publikacji.

8. Przygotowanie do API

Nawet jeżeli jednostka zaczyna bez integracji, system powinien umożliwiać uporządkowanie danych w sposób, który później pozwoli na automatyzację.

Model 3: integracja z CRU JSFP przez API

Integracja przez API jest najbardziej zaawansowanym modelem pracy. Pozwala ograniczyć ręczne przepisywanie danych do systemu centralnego i zautomatyzować część procesu publikacji oraz aktualizacji informacji o umowach.

To rozwiązanie ma największy sens wtedy, gdy jednostka:

• ma większy wolumen umów,
• ma uporządkowany lokalny rejestr,
• ma stabilne źródła danych,
• ma jasny workflow akceptacji,
• ma dobrą jakość danych,
• potrafi obsłużyć błędy integracji,
• chce ograniczyć ręczne wpisywanie danych,
• chce raportować statusy publikacji,
• chce zautomatyzować aktualizacje po zmianach.

API nie powinno być jednak traktowane jako lek na chaos organizacyjny.

Jeżeli dane źródłowe są błędne, niekompletne albo niezatwierdzone, integracja tylko szybciej przekaże błędne dane do systemu centralnego.

API nie zastępuje procesu

To bardzo ważne: integracja z CRU JSFP nie rozwiązuje problemów merytorycznych.

API nie zdecyduje za jednostkę:

• czy umowa podlega publikacji,
• czy zachodzi ustawowe wyłączenie,
• czy dane pole powinno być jawne,
• czy wartość została policzona prawidłowo,
• czy uwzględniono opcje i wznowienia,
• czy zastosowano właściwy kurs waluty,
• czy aneks wymaga aktualizacji,
• czy dane zostały zatwierdzone przez właściwą osobę.

API jest kanałem technicznym. Proces kwalifikacji, weryfikacji i odpowiedzialności musi powstać po stronie jednostki.

Dlatego najlepsza kolejność to:

Porównanie modeli

Excel

Kiedy ma sens?

Excel może mieć sens jako rozwiązanie przejściowe, narzędzie inwentaryzacyjne albo model dla bardzo małej jednostki z niewielką liczbą umów.

Zalety:

• szybki start,
• niski koszt wejścia,
• łatwe przygotowanie pierwszej listy umów,
• możliwość szybkiego wykrycia braków w danych,
• prostota dla użytkowników.

Ryzyka:

• wiele wersji pliku,
• brak pełnej historii zmian,
• słaba kontrola uprawnień,
• brak workflow,
• brak dobrej kontroli terminu 30 dni,
• trudne raportowanie,
• duże ryzyko błędów przy wielu użytkownikach,
• brak naturalnej integracji z CRU JSFP.

System lokalny

Kiedy ma sens?

System lokalny ma sens dla większości urzędów, uczelni, instytucji kultury, jednostek budżetowych, szpitali publicznych i większych organizacji publicznych.

Zalety:

• jeden rejestr umów,
• role i uprawnienia,
• historia zmian,
• statusy,
• workflow akceptacji,
• kontrola terminów,
• obsługa aneksów i aktualizacji,
• dokumentowanie wyłączeń jawności,
• raportowanie dla kierownictwa,
• przygotowanie do API.

Ryzyka:

• wymaga wdrożenia,
• wymaga właściciela procesu,
• wymaga uporządkowania danych,
• wymaga przeszkolenia użytkowników,
• wymaga utrzymania i aktualizacji procedury.

Integracja z CRU JSFP

Kiedy ma sens?

Integracja ma sens wtedy, gdy jednostka ma stabilny lokalny rejestr, dobre dane i większy wolumen umów albo aktualizacji.

Zalety:

• ograniczenie ręcznego przepisywania danych,
• automatyzacja publikacji i aktualizacji,
• możliwość obsługi większej liczby umów,
• statusy wysyłek,
• obsługa błędów technicznych,
• większa skalowalność procesu.

Ryzyka:

• automatyzuje także błędy, jeżeli dane źródłowe są złe,
• wymaga mapowania pól,
• wymaga obsługi błędów API,
• wymaga testów,
• wymaga utrzymania zgodności z dokumentacją API,
• wymaga dobrego procesu akceptacji przed wysyłką.

Jak wybrać właściwy model?

Wybór modelu powinien zależeć od kilku kryteriów, a nie tylko od budżetu albo przyzwyczajenia do dotychczasowego narzędzia.

Jednostka powinna ocenić:

• liczbę umów rocznie,
• liczbę aneksów i aktualizacji,
• liczbę komórek organizacyjnych zawierających umowy,
• liczbę osób pracujących na danych,
• poziom rozproszenia danych,
• potrzebę akceptacji przed publikacją,
• ryzyko ograniczeń jawności,
• potrzebę raportowania dla kierownictwa,
• gotowość do pracy przez API,
• wymagania bezpieczeństwa,
• dostępne zasoby kadrowe,
• oczekiwany poziom automatyzacji.

Im większa jednostka, im więcej komórek organizacyjnych i im większy wolumen umów, tym szybciej Excel przestaje być bezpiecznym modelem docelowym.

Prosty model decyzyjny

Można przyjąć następującą logikę:

Mała jednostka, niewiele umów, jeden punkt odpowiedzialności

Excel może wystarczyć jako rozwiązanie przejściowe, pod warunkiem że jednostka ma jasną procedurę, kontrolę wersji i odpowiedzialność za dane.

Średnia jednostka, kilka komórek, potrzeba kontroli terminów i akceptacji

Lepszym rozwiązaniem będzie lokalny system ewidencji umów z rolami, historią zmian, statusami i raportami.

Duża jednostka, wiele umów, wiele aktualizacji, potrzeba automatyzacji

Najlepszy będzie lokalny system jako źródło danych oraz integracja z CRU JSFP przez API.

Jednostka z chaosem w danych

Nie powinna zaczynać od API. Najpierw powinna uporządkować lokalny rejestr, źródła danych, właścicieli pól i procedurę akceptacji.

Model etapowy — najbezpieczniejsze podejście

W wielu jednostkach najlepszym rozwiązaniem będzie wdrożenie etapowe.

Etap 1: inwentaryzacja danych

Jednostka ustala, gdzie są dane o umowach, jakie pola są dostępne, czego brakuje i które komórki organizacyjne odpowiadają za poszczególne informacje.

Etap 2: uporządkowanie lokalnego rejestru

Powstaje jedno miejsce pracy z umowami, statusami, aneksami, wartościami, kwalifikacją do CRU JSFP i historią zmian.

Etap 3: wdrożenie workflow

Dane przechodzą przez przygotowanie, weryfikację, akceptację i publikację.

Etap 4: raportowanie i monitoring

Jednostka widzi terminy, zaległości, przypadki wątpliwe, błędy i umowy wymagające aktualizacji.

Etap 5: integracja z CRU JSFP

Dopiero gdy dane i proces są stabilne, można ograniczać ręczne przepisywanie danych przez API.

Taki model zmniejsza ryzyko, że jednostka zintegruje z CRU JSFP nieuporządkowany proces.

Co powinien widzieć kierownik jednostki?

Kierownictwo nie powinno musieć sprawdzać pojedynczo każdego rekordu w rejestrze. Powinno mieć dostęp do raportów pokazujących ryzyka i statusy procesu.

Przydatne raporty to między innymi:

• umowy oczekujące na kwalifikację,
• umowy zakwalifikowane do CRU JSFP,
• umowy wyłączone ustawowo,
• umowy wymagające oceny jawności,
• umowy oczekujące na uzupełnienie danych,
• umowy oczekujące na akceptację,
• umowy oczekujące na publikację,
• umowy opublikowane,
• umowy zbliżające się do terminu 30 dni,
• umowy po terminie,
• umowy wymagające aktualizacji po aneksie,
• błędy publikacji,
• umowy bez kompletnej wartości,
• umowy bez przypisanej odpowiedzialności.

To właśnie raportowanie często pokazuje różnicę między zwykłym arkuszem a systemem wspierającym zarządzanie obowiązkiem CRU JSFP.

Najczęstsze błędy przy wyborze modelu

Najczęstsze błędy jednostek to:

• pozostawienie Excela jako docelowego rozwiązania bez oceny ryzyk,
• rozpoczęcie od integracji API bez uporządkowania danych,
• brak właściciela procesu,
• brak jednej ewidencji umów,
• brak historii zmian,
• brak akceptacji przed publikacją,
• brak kontroli terminu 30 dni,
• brak procedury aktualizacji po aneksie,
• brak reguły dla wyłączeń jawności,
• brak raportowania dla kierownictwa,
• zbyt szerokie uprawnienia użytkowników,
• brak testów przed startem publikacji,
• brak planu rozwoju od modelu ręcznego do bardziej zautomatyzowanego.

W praktyce największym ryzykiem nie jest sam wybór narzędzia. Największym ryzykiem jest brak procesu.

Checklista wyboru modelu rejestru umów

Przed decyzją warto odpowiedzieć na kilka pytań:

• Ile umów rocznie zawiera jednostka?
• Ile komórek organizacyjnych uczestniczy w zawieraniu umów?
• Czy dane o umowach są w jednym miejscu?
• Czy istnieje jeden właściciel procesu?
• Czy jednostka ma procedurę kwalifikacji umów do CRU JSFP?
• Czy jednostka ma procedurę ograniczeń jawności?
• Czy system lub arkusz pokazuje termin 30 dni?
• Czy można sprawdzić historię zmian?
• Czy wiadomo, kto zatwierdził dane?
• Czy obsługiwane są aneksy, wypowiedzenia, cesje i korekty?
• Czy kierownictwo ma raport o ryzykach i zaległościach?
• Czy dane nadają się do przekazania przez API?
• Czy jednostka potrafi obsłużyć błąd publikacji?
• Czy obecny model będzie działał przy większej liczbie umów?

Jeżeli większość odpowiedzi jest niejasna, jednostka powinna zacząć od uporządkowania procesu, a nie od wyboru samego narzędzia.

Rekomendacja wdrożeniowa

Najbezpieczniejszy model dla większości jednostek to lokalny rejestr umów jako uporządkowane źródło danych oraz możliwość integracji z CRU JSFP na kolejnym etapie.

Excel może być pomocny na początku, ale nie powinien być docelową odpowiedzią dla średniej albo dużej jednostki, która chce kontrolować terminy, historię zmian, odpowiedzialność, akceptację i raportowanie.

Integracja przez API może znacząco ograniczyć ręczną pracę, ale powinna zostać wdrożona dopiero wtedy, gdy lokalne dane i proces są stabilne.

Praktyczna rekomendacja wygląda więc tak:

• Excel — jako etap przejściowy albo narzędzie inwentaryzacyjne,
• system lokalny — jako centrum zarządzania umowami i danymi do CRU JSFP,
• API — jako etap automatyzacji po uporządkowaniu procesu.

Taka ścieżka pozwala uniknąć dwóch skrajności: ręcznego chaosu w arkuszach oraz zbyt szybkiej automatyzacji nieuporządkowanych danych.

Podsumowanie

CRU JSFP nie wymusza jednego lokalnego narzędzia do prowadzenia rejestru umów. Wymusza natomiast zdolność do przygotowania, publikacji i aktualizacji poprawnych informacji o umowach.

Excel może pomóc na początku, ale ma ograniczenia w zakresie historii zmian, uprawnień, workflow, raportowania i kontroli terminów.

System lokalny pozwala uporządkować proces, dane, role, akceptację, historię zmian i raportowanie.

Integracja przez API ma sens wtedy, gdy jednostka ma już dobre dane i chce ograniczyć ręczne przepisywanie informacji do CRU JSFP.

Najważniejsza zasada jest prosta:

Źródła i podstawy prawne

Materiał został przygotowany na podstawie aktualnie dostępnych informacji publicznych dotyczących Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych oraz przepisów regulujących obowiązek udostępniania i aktualizacji informacji o umowach.

Najważniejsze źródła:

• 1. Ustawa z dnia 27 sierpnia 2009 r. o finansach publicznych — w zakresie zasady jawności gospodarowania środkami publicznymi oraz przepisów dotyczących Centralnego Rejestru Umów JSFP.
• 2. Ustawa z dnia 4 grudnia 2025 r. zmieniająca ustawę o zmianie ustawy – Kodeks karny oraz niektórych innych ustaw oraz o zmianie niektórych innych ustaw, Dz.U. 2025 poz. 1844.
• 3. Rozporządzenie Ministra Finansów i Gospodarki z dnia 30 marca 2026 r. w sprawie Centralnego Rejestru Umów Jednostek Sektora Finansów Publicznych, Dz.U. 2026 poz. 440.
• 4. Dokumentacja integracyjna CRU API publikowana przez Ministerstwo Finansów — w zakresie technicznego zasilania systemu centralnego danymi z innych systemów teleinformatycznych.
• 5. Ustawa z dnia 11 września 2019 r. — Prawo zamówień publicznych — w zakresie oceny, czy dana umowa stanowi zamówienie w rozumieniu przepisów Pzp.