Obowiązek zgłaszania umów do Centralnego Rejestru Umów (CRU) prowadzonego przez Ministerstwo Finansów wchodzi w życie 1 lipca 2026 roku. Każda jednostka sektora finansów publicznych (JSFP) — szpital, urząd, szkoła, uczelnia, instytucja kultury — będzie zobowiązana raportować zawierane umowy w terminie 30 dni od ich podpisania.

Wbrew pozorom to nie jest „prosty formularz". Po stronie zamawiającego kryje się kilkadziesiąt pól, z których każde ma konkretne wymagania walidacyjne API MF. Pomyłka w jednym z nich może oznaczać odrzucenie zgłoszenia i konieczność ponownej wysyłki, a w przypadku przekroczenia 30-dniowego terminu — naruszenie egzekwowalnego obowiązku, za które odpowiada kierownik jednostki.

Poniżej praktyczna lista 10 najczęstszych błędów, które obserwujemy w testach z jednostkami pilotażowymi — z konkretnymi sposobami jak ich uniknąć.

1. Niepoprawny NIP kontrahenta

Najczęstszy problem techniczny. API MF waliduje NIP po stronie systemu i odrzuca zgłoszenia z błędnym kodem kontrolnym, ale bardziej zdradliwa jest sytuacja, gdy NIP jest formalnie poprawny, ale przypisany do innego podmiotu — wpisany ręcznie z błędem w jednej cyfrze.

Jak uniknąć:

Weryfikuj NIP w białej liście podatników VAT (wykaz podatników) przed wprowadzeniem do systemu.
Nie kopiuj NIP-u z umów PDF — często skanery OCR mylą 0 z O i 1 z l.
Stosuj walidację cyfry kontrolnej NIP zawsze na poziomie formularza wprowadzania.

Dobre systemy do CRU (jak moduł CRU w Medulis) sprawdzają NIP w czasie rzeczywistym przy wprowadzaniu — błąd nie ma szansy dotrzeć do API MF.

2. Nieprawidłowy typ umowy / przedmiot umowy

API CRU MF wymaga klasyfikacji umowy według enumerowanej listy typów (np. dostawa, usługa, robota budowlana). Wybranie błędnego typu nie zawsze powoduje odrzucenie zgłoszenia — ale stwarza ryzyko niezgodności statystycznej widocznej podczas kontroli. Pamiętaj, że do CRU trafiają wyłącznie umowy będące zamówieniem w rozumieniu art. 7 pkt 32 Pzp — które dokładnie, wyjaśniamy w artykule Centralny Rejestr Umów — jakie umowy zgłaszać?.

Jak uniknąć:

Zapoznaj się z aktualną klasyfikacją typów umów w instrukcji technicznej MF (publikowanej osobno dla każdej wersji API).
Dla umów mieszanych (np. dostawa sprzętu + montaż + przegląd) zastosuj zasadę dominującego świadczenia — typ wybierany według wartości udziału.

3. Błędne daty: zawarcia umowy vs obowiązywania

Wiele jednostek myli datę zawarcia umowy (kiedy została podpisana przez obie strony) z datą rozpoczęcia obowiązywania umowy (od kiedy strony są nią związane prawnie). Te daty często się różnią — np. umowa podpisana 25 czerwca, obowiązuje od 1 lipca.

Z perspektywy CRU MF kluczowa jest data zawarcia — to od niej liczone jest 30 dni ustawowego terminu na zgłoszenie.

Jak uniknąć:

Zawsze wprowadzaj datę najpóźniejszego podpisu (gdy umowę podpisywano w różnych dniach).
Daty obowiązywania i zakończenia umowy to osobne pola — uzupełnij je równolegle, nie zamiennie.

4. Nieprawidłowy organ założycielski / klasyfikacja JSFP

CRU MF wymaga określenia statusu podmiotu zamawiającego zgodnie z art. 9 ustawy o finansach publicznych. Pomyłka tutaj generuje błąd przy walidacji po stronie MF, ponieważ system łączy zgłoszenie z bazą JSFP prowadzoną przez urząd skarbowy.

Jak uniknąć:

Jednostka raz na zawsze powinna mieć utrwaloną klasyfikację w systemie wewnętrznym (np. „jednostka budżetowa", „SPZOZ", „samorządowy zakład budżetowy").
Jeśli klasyfikacja się zmienia (rzadko, np. przy reorganizacji), aktualizuj ją przed pierwszym zgłoszeniem w nowym roku obrachunkowym.

5. Pominięcie zmiany (aneksu) umowy

Najpoważniejszy ze strategicznego punktu widzenia. Aneks również podlega zgłoszeniu w terminie 30 dni od podpisania, jeżeli zmienia istotne elementy umowy (wartość, termin realizacji, strony, przedmiot). W praktyce wiele jednostek zgłasza tylko umowę pierwotną i pomija aneksy — co jest naruszeniem obowiązku.

Jak uniknąć:

Aneks należy traktować jako odrębne zgłoszenie w CRU, połączone z umową bazową przez numer systemowy (zwracany przez API MF po pierwszym zgłoszeniu).
W systemie ewidencji umów ustaw automatyczne przypomnienia dla każdego aneksu — 30-dniowy termin liczy się od daty aneksu, nie od daty umowy bazowej.

6. Przekroczenie 30-dniowego terminu

Pozornie najłatwiejsze do uniknięcia, w praktyce najczęstsza przyczyna problemów. Sekcja ZP czy księgowość zbiera umowy „na kupkę" i wysyła raz w tygodniu lub raz na dwa tygodnie — co bywa za późno dla umów podpisanych pod koniec poprzedniego okresu.

Konsekwencje: choć ustawa o CRU JSFP nie przewiduje odrębnej sankcji karnej (odpowiedzialność karną z pierwotnego rejestru umów wykreślono), spóźnione lub pominięte zgłoszenie to naruszenie egzekwowalnego obowiązku, które wyjdzie na jaw przy kontroli — a odpowiada za nie kierownik jednostki.

Jak uniknąć:

Każda umowa powinna trafiać do systemu ewidencji w dniu podpisania, nie tygodniami później.
System powinien automatycznie liczyć dni pozostałe do końca terminu — i wysyłać alerty na 14, 7, 3 i 1 dzień przed upływem (tak działa moduł CRU w Medulis).

7. Niezgodność wartości umowy z dokumentem źródłowym

CRU MF zapisuje wartość umowy netto i brutto. Częsty błąd: wpisanie wartości szacunkowej z postępowania PZP (która mogła być inna niż finalnie wynegocjowana), zamiast wartości z podpisanej umowy.

Jak uniknąć:

Wartości w CRU muszą zgadzać się z treścią umowy — to ten dokument jest źródłowy, nie szacunek z postępowania.
Dla umów ramowych (gdzie wartość finalna zależy od zamówień szczegółowych) zgłaszaj wartość maksymalną przewidywaną w umowie — z odpowiednią adnotacją.

8. Brak załączników wymaganych przez API MF

Dla niektórych typów umów (np. powyżej określonego progu, umowy z podmiotem zagranicznym) MF może wymagać dodatkowych załączników w określonych formatach. Próba zgłoszenia bez wymaganego załącznika kończy się odrzuceniem na poziomie walidacji.

Jak uniknąć:

Sprawdź w aktualnej dokumentacji API MF które typy umów wymagają załączników.
W systemie ewidencji umów oznacz pola „wymagany załącznik" — i blokuj zatwierdzenie zgłoszenia bez kompletu dokumentów.

9. Wielokrotne zgłoszenia tej samej umowy

Dotyczy zwłaszcza dużych jednostek z kilkoma osobami obsługującymi CRU — ta sama umowa wprowadzana niezależnie przez sekcję ZP i sekcję ekonomiczną. CRU MF nie deduplikuje automatycznie — każde zgłoszenie otrzymuje osobny numer systemowy.

Jak uniknąć:

W jednostce wyznacz jeden punkt wprowadzenia umowy do CRU (jedna osoba lub jedna sekcja).
Każda umowa po zgłoszeniu powinna otrzymać status „zarejestrowana w CRU" widoczny dla wszystkich pracowników mających dostęp do ewidencji.

10. Brak archiwizacji potwierdzenia z API MF

Po pomyślnym zgłoszeniu API MF zwraca numer systemowy umowy w CRU. Ten numer jest dowodem dochowania obowiązku — jego brak (np. po awarii systemu) oznacza, że w przypadku kontroli nie udowodnisz, że zgłoszenie się powiodło.

Jak uniknąć:

Zawsze archiwizuj odpowiedź API wraz z numerem systemowym i znacznikiem czasu.
System ewidencji powinien przechowywać pełną historię operacji — kto, kiedy, z jakim wynikiem (audytowalny rejestr).

Podsumowanie: lista kontrolna przed wysyłką

Zanim klikniesz „Wyślij do CRU MF", sprawdź szybko:

✅ NIP kontrahenta zweryfikowany w wykazie podatników VAT
✅ Typ umowy zgodny z aktualną klasyfikacją MF
✅ Data zawarcia (najpóźniejszego podpisu), nie data obowiązywania
✅ Klasyfikacja JSFP zgodna z bazą MF
✅ Aneksy zgłoszone osobno
✅ Termin 30 dni od daty zawarcia — niezależnie liczony dla każdego dokumentu
✅ Wartości netto i brutto zgodne z umową
✅ Komplet załączników wymaganych dla danego typu umowy
✅ Pojedyncze zgłoszenie (brak duplikatów)
✅ Archiwizacja numeru systemowego po wysyłce

Jak Medulis chroni przed wszystkimi 10 błędami

Moduł CRU w systemie Medulis został zaprojektowany tak, aby żaden z powyższych błędów nie miał szansy dotrzeć do API MF. Walidacja danych odbywa się przed wysyłką, w czasie rzeczywistym przy wprowadzaniu do formularza. Aneksy są automatycznie łączone z umową bazową przez numer systemowy. 30-dniowy termin jest pilnowany przez harmonogram alertów (14, 7, 3, 1 dzień przed). Każda operacja jest zapisywana w audytowalnym rejestrze z numerem MF.

Zapraszamy do zapoznania się z modułem CRU oraz do złożenia wniosku o dostęp do wersji demonstracyjnej — pokażemy cały proces na realnym przykładzie i odpowiemy na pytania dotyczące Państwa konkretnej jednostki.