Automatyczne uzgadnianie płatności: wdrożenie w 2 tygodnie (i ile to realnie oszczędza godzin księgowej miesięcznie)

Gdy klient pyta nas, od czego zacząć automatyzację w firmie, prawie nigdy nie odpowiadam „od chatbota” ani „od generowania treści marketingowych”. Najpierw sprawdzam, czy ktoś w firmie codziennie albo co tydzień robi coś, co polega na porównywaniu dwóch list: przelewów z banku i faktur w systemie. Jeśli tak, to tam jest pierwsza automatyzacja do wdrożenia, bo zwrot z inwestycji widać już po pierwszym miesiącu, a proces jest na tyle prosty, że nie trzeba go „uczyć” miesiącami.

Dlaczego reconciliation to dobry pierwszy projekt, a nie ciekawostka

W małych firmach księgowość rzadko ma dedykowany dział do uzgadniania płatności. Zwykle robi to jedna osoba, ręcznie, otwierając wyciąg bankowy w jednym oknie i listę faktur w drugim. Sprawdza kwotę, sprawdza tytuł przelewu, czasem szuka po NIP-ie, bo klient zapłacił z innego konta niż firmowe. Przy kilkudziesięciu przelewach miesięcznie to zajęcie na kilka godzin, przy kilkuset (typowa mała hurtownia albo firma usługowa z wieloma stałymi klientami) potrafi zjeść cały dzień pracy w miesiącu, rozłożony na kawałki między inne obowiązki.

To, co czyni ten proces idealnym kandydatem do automatyzacji, to jego powtarzalność i jasność reguł. Reconciliation nie wymaga kreatywności ani oceny kontekstu biznesowego. Wymaga cierpliwości i precyzji, czyli dokładnie tego, w czym maszyna jest lepsza od człowieka. Nie trzeba tu trenować modelu językowego ani budować skomplikowanego agenta AI, wystarczy dobrze zaprojektowany workflow z regułami dopasowania i miejscem na wyjątki.

Co się dzieje bez automatyzacji: uzgadnianie krok po kroku

Typowy scenariusz w firmie handlowej albo usługowej wygląda tak: księgowa loguje się do bankowości internetowej, eksportuje wyciąg (albo po prostu przegląda historię operacji), a potem otwiera system księgowy, np. wFirma, Fakturownię czy Optimę, i zaczyna szukać, której fakturze odpowiada dany przelew. Problem zaczyna się tam, gdzie tytuł przelewu nie jest oczywisty: klient wpisał numer zamówienia zamiast numer faktury, zapłacił zbiorczo za trzy faktury jedną kwotą, albo przelał kwotę pomniejszoną o rabat, którego nikt jeszcze nie wprowadził do systemu.

Każdy taki przypadek wymaga ręcznego śledztwa. Dobra księgowa robi to sprawnie, ale sprawność nie zmienia faktu, że jest to praca odtwórcza, podatna na pomyłki pod koniec dnia, i że zabiera czas, który mógłby pójść na coś, czego automat nie zrobi, czyli analizę zaległości, kontakt z klientem w sprawie przeterminowanej płatności albo przygotowanie danych do rozliczeń podatkowych.

Jak to wygląda z automatyzacją: dopasowanie przelewów do faktur

Schemat, który sprawdza się w praktyce, jest zaskakująco prosty w opisie, choć wymaga precyzyjnego dopięcia reguł. Automat (najczęściej budowany w n8n lub Make) co jakiś czas, np. co godzinę albo raz dziennie, pobiera listę nowych operacji bankowych i listę nierozliczonych faktur z systemu księgowego. Następnie próbuje dopasować każdy przelew do faktury, sprawdzając kolejno kilka sygnałów: kwotę, numer faktury w tytule, NIP nadawcy, a przy braku jednoznacznego dopasowania również datę wystawienia i zbliżoną kwotę z tolerancją na drobne różnice (np. koszty przewalutowania albo zaokrąglenia groszowe).

Integracje bankowe: PSD2, open banking i polskie systemy księgowe

Tu trzeba być uczciwym: dostęp do danych bankowych w Polsce nie zawsze jest tak prosty, jak w krajach z dłuższą historią open bankingu. Dyrektywa PSD2 formalnie otworzyła banki na integracje przez API, ale w praktyce jakość i stabilność tych API bywa różna między bankami, a część integracji odbywa się przez pośredników (agregatorów bankowych), którzy ujednolicają dostęp do wielu banków jednym połączeniem. Systemy księgowe popularne w małych firmach, czyli Optima, wFirma czy Fakturownia, w różnym stopniu oferują gotowe wtyczki bankowe: część ma natywne integracje z wybranymi bankami, część wymaga ręcznego importu wyciągu w formacie MT940 albo CSV, który następnie automat przetwarza.

W praktyce oznacza to, że projekt reconciliation zaczyna się od małego rekonesansu: sprawdzamy, czy bank klienta ma stabilne API, czy trzeba iść przez agregatora, czy może prościej i taniej będzie ustawić automatyczny, codzienny eksport wyciągu i wgrywanie go do workflow. To nie jest efektowna część projektu, ale to ona decyduje, czy wdrożenie zajmie tydzień czy miesiąc.

Reguły dopasowania: kwota, tytuł, NIP, tolerancja

Sama logika dopasowania to zwykle kilka warstw reguł ułożonych od najbardziej pewnej do najmniej pewnej. Pierwsza warstwa: dokładna kwota i numer faktury w tytule przelewu, dopasowanie automatyczne bez pytania nikogo. Druga warstwa: dokładna kwota i NIP nadawcy zgodny z kontrahentem przypisanym do faktury, przy braku numeru w tytule. Trzecia warstwa: kwota zbliżona (tolerancja rzędu kilku, kilkunastu złotych) i ten sam kontrahent, z automatycznym oznaczeniem „do potwierdzenia” zamiast pełnego zamknięcia. Im wyżej w tej hierarchii, tym większa pewność automatycznego zamknięcia bez udziału człowieka.

Gdzie automat się zatrzymuje i oddaje decyzję człowiekowi

Nie ma sensu udawać, że automat rozwiąże 100% przypadków. Uczciwie mówimy klientom, że dobrze zaprojektowany workflow zamyka automatycznie większość standardowych płatności, ale zawsze zostaje margines przypadków, w których lepiej, żeby decyzję podjął człowiek. Płatność zbiorcza za pięć faktur jedną kwotą, korekta faktury po fakcie, przelew od kontrahenta, który zmienił nazwę firmy i NIP w systemie jeszcze nie zaktualizowano, zwrot środków od klienta, przedpłata na poczet przyszłej faktury, która jeszcze nie istnieje w systemie. To wszystko są sytuacje, w których automat powinien nie zgadywać, tylko oznaczyć transakcję jako wymagającą przeglądu i skierować ją na jedną, wspólną listę wyjątków.

To jest ważny element projektowania takiego workflow: automat robi swoją część, ale zostawia jasny ślad tam, gdzie się zatrzymał, zamiast próbować dopasować przelew „na siłę” z niepewną regułą. Lepiej mieć piętnaście transakcji dziennie do ręcznego sprawdzenia niż jedną błędnie rozliczoną fakturę, która zaburzy saldo klienta i wygeneruje niepotrzebny telefon z reklamacją.

Ile to kosztuje i jak szybko się zwraca

To jest ta część, w której reconciliation wygrywa z bardziej ambitnymi projektami AI. Wdrożenie tego typu workflow w n8n albo Make, razem z konfiguracją integracji bankowej i podłączeniem do systemu księgowego, to zwykle kilka do kilkunastu dni roboczych pracy wdrożeniowej, nie miesiące. Koszt utrzymania jest niski, bo cała logika opiera się na jasnych regułach, a nie na modelach, które trzeba stale douczać czy monitorować pod kątem „halucynacji”.

Zwrot z inwestycji liczymy najprościej jak się da: ile godzin miesięcznie księgowa albo osoba odpowiedzialna za rozliczenia poświęcała na ręczne uzgadnianie, i o ile ten czas spada po wdrożeniu. W firmach, z którymi pracowaliśmy nad podobnymi procesami, praca, która wcześniej zajmowała kilka godzin tygodniowo, po wdrożeniu automatycznego dopasowania skraca się do krótkiego, codziennego przeglądu listy wyjątków, czyli kilkunastu minut zamiast godzin. To nie jest liczba efektowna do prezentacji zarządowi w formie procentowego wzrostu „efektywności”, ale to jest liczba, którą księgowa faktycznie odczuwa w swoim kalendarzu.

Jak wdrożyć to w małej firmie: praktyczne kroki

Zanim w ogóle usiądziemy do budowy workflow, sprawdzamy trzy rzeczy: jaki bank obsługuje firma i czy ma sensowne API albo dostępny eksport wyciągu, jaki system księgowy jest w użyciu i czy ma API lub przynajmniej import/eksport w standardowym formacie, oraz jak wyglądają typowe tytuły przelewów od klientów firmy (na tej podstawie budujemy pierwszą wersję reguł dopasowania). Dopiero po tym etapie ma sens projektowanie samego workflow.

Sam proces wdrożenia rozkładamy zwykle na kilka etapów: najpierw uruchamiamy wersję, która tylko proponuje dopasowania i nic nie zamyka automatycznie, żeby zespół księgowy mógł przez tydzień czy dwa zweryfikować trafność reguł. Dopiero gdy widzimy, że dopasowania w oczywistych przypadkach są poprawne w niemal 100%, włączamy automatyczne zamykanie dla tej pewnej warstwy reguł, zostawiając niepewne przypadki na liście wyjątków. To podejście, świadomie ostrożne, minimalizuje ryzyko, że automat „zamknie” coś błędnie i nikt tego nie zauważy przez miesiąc.

Jeśli firma korzysta z biura rachunkowego zamiast wewnętrznej księgowości, ten sam schemat da się wdrożyć po stronie biura, obsługując od razu kilku klientów podobnymi regułami z drobnymi modyfikacjami per klient. To temat, który szerzej opisujemy przy okazji automatyzacji biura rachunkowego, bo skala tam działa na korzyść automatyzacji jeszcze mocniej niż w pojedynczej firmie.