Koniec miesiąca. Wyciąg bankowy w jednej karcie przeglądarki, lista otwartych faktur w drugiej. Ktoś siada i zaczyna szukać: ten przelew 3 900 zł od "ABC SP Z OO" - to faktura numer 09/2026 czy ta z poprzedniego miesiąca? A tamten na 7 800 zł z opisem "faktury sierpien" - może dwie po 3 900 razem?
Gdy coś zostanie źle odhaczone, idzie ponaglenie do klienta, który dawno już zapłacił. Niekomfortowa rozmowa, często przeprosiny, zawsze stracony czas.
Ten workflow n8n eliminuje tę część pracy. Tę, która jest pewna. Co niejednoznaczne, ląduje w kolejce przeglądu zamiast w zgadywance.
Jak silnik dopasowań podejmuje decyzje
Workflow ma dwa wejścia. Pierwsze to webhook: biuro przesyła sparsowany wyciąg bankowy jako JSON przez żądanie POST. Drugie to wbudowany symulator z gotowym zestawem danych testowych, który pozwala uruchomić cały przepływ bez podpinania czegokolwiek do produkcji.
Zanim cokolwiek się zapisze, system sprawdza token uwierzytelniający w nagłówku żądania. Zły token albo brak tokenu daje odpowiedź 401 i zero efektów ubocznych: żadnych zapisanych wierszy, żadnych powiadomień. Nawet jeśli serwer nie ma skonfigurowanego tokenu, przepływ blokuje się w tym miejscu.
Po uwierzytelnieniu payload jest normalizowany. Silnik dostaje wiersze bankowe, listę otwartych faktur, opcjonalne aliasy płatnika i tolerancję kwotową w groszach. Domyślnie tolerancja wynosi zero.
Dopasowanie jest deterministyczne i nie używa sztucznej inteligencji. To pojedynczy węzeł kodu z jawną logiką: normalizacja ciągów tekstowych, arytmetyka kwot, klucze SHA-256. Ta sama transakcja zawsze da ten sam wynik. Każda decyzja trafia do pola evidence_json z zapisanym uzasadnieniem - widać, dlaczego silnik wybrał co wybrał.
Silnik szuka dopasowania na trzy sposoby. Numer faktury w tytule przelewu. Dokładna kwota pasująca do jednej otwartej faktury. Dokładna suma kilku faktur jednocześnie. Tylko te ścieżki prowadzą do pewnego dopasowania i emisji sygnału "zapłacone".
Kiedy żadna nie pasuje - ta sama kwota pasuje do dwóch różnych faktur, płatnik jest nieznany, wiersz jest uszkodzony - przelew trafia do kolejki przeglądu. Razem z nim lądują faktury-kandydaci i powód wstrzymania. Człowiek patrzy i decyduje.
Czego silnik nie robi automatycznie
Częściowa wpłata nie zamyka faktury. Jest zapisana jako matched_partial, ale sygnał "zapłacone" nie wychodzi. Windykacja dalej działa, dopóki ktoś po stronie biura nie zdecyduje, co z tym fantem zrobić.
Nadpłata trafia do kolejki z kodem overpayment_requires_policy. Workflow nie zna polityki biura, więc zostawia tę decyzję ludziom.
Import tego samego wyciągu po raz drugi nie tworzy duplikatów. Każda transakcja bankowa dostaje stabilny klucz hashowany na podstawie danych z banku, nie identyfikatora wykonania. System sprawdza historię przed każdym zapisem. Nachodzące na siebie eksporty z banku to normalna sytuacja i workflow ją obsługuje bez ręcznego sprzątania.
Sygnał "zapłacone" to wiersz w tabeli danych, nie akcja. Workflow nigdy sam nie pisze do klienta. Sygnał jest kontraktem dla osobnego systemu: workflow windykacyjny z pierwszego posta tej serii może go stamtąd pobrać i wstrzymać wysyłkę kolejnych przypomnień. Te dwa workflow łączą się przez tabelę, bez zależności w kodzie.
Na koniec każdego importu sześć tabel danych jest odczytywanych z powrotem. Sprawdzane są dokładne liczby wierszy i klucze. Dopiero po tym kroku wysyłana jest notyfikacja mailowa i odpowiedź webhooka zostaje zwolniona. Jeśli cokolwiek się nie zgadza, workflow nie udaje, że się powiodło.
Co jest w repozytorium
Szablon jest dostępny bezpłatnie:
https://github.com/kuliberdalabs/n8n-sme-workflows/tree/main/workflows/06-bank-reconciliation
To jeden z ośmiu szablonów w repozytorium n8n-sme-workflows. Cały katalog ma 14 pozycji, 8 leży w otwartym repozytorium.
Przed wdrożeniem na produkcji warto uruchomić wbudowany symulator. Przechodzi przez cały przepływ na fikcyjnych danych, bez podłączania banku. Widać jak działa kolejka przeglądu, jak wyglądają zapisane alokacje, jak reaguje weryfikacja, gdy liczba wierszy się nie zgadza. Dopiero potem warto przyłożyć małą próbkę prawdziwych danych.
Granice szablonu:
Brak konektora bankowego i parsera CSV. Szablon oczekuje już sparsowanego JSON z wierszami transakcji. Zamiana eksportu z konkretnego banku na ten format to osobny krok i każdy bank ma inną strukturę pliku: inny układ dat i inne kodowanie kwot.
Polityki częściowych wpłat, nadpłat i zaokrągleń nie są wbudowane. Każde biuro ma tu własne zasady i wbudowanie jednej z nich skrzywdziłoby pozostałe.
Sześć zapisów do tabel danych nie jest jedną transakcją bazodanową. Przerwanie w połowie może zostawić niekompletny zestaw wierszy dla danego wykonania. Workflow sygnalizuje błąd i nie emituje sukcesu, ale operator może potrzebować ręcznie sprawdzić te wiersze przed ponownym uruchomieniem.
Jednoczesne importy tego samego wyciągu mogą się ścigać. Zabezpieczenie przez klucze hashowane i historię nie jest blokadą atomową - przy bardzo szybkich, równoległych importach zduplikowanie jest możliwe.
Kiedy szablon nie wystarcza
Przed uruchomieniem na żywym wyciągu trzeba rozwiązać trzy rzeczy.
Mapowanie formatu bankowego. Każdy bank eksportuje dane inaczej: CSV z siedmioma kolumnami albo XML z zupełnie innym układem. Parser specyficzny dla twojego banku to praca per instytucja i nie ma jednego rozwiązania dla wszystkich.
Polityki wpłat. Kto w biurze decyduje o nadpłacie? Jakie zaokrąglenie traktujesz jako dopasowanie, a jakie jako niezgodność? Te reguły muszą być opisane i wdrożone, zanim silnik trafi na prawdziwe przelewy.
Spięcie z windykacją. Sygnał "zapłacone" czeka w tabeli. Żeby zatrzymał wysyłkę przypomnień, potrzebuje workflow po stronie konsumenta, który go stamtąd pobierze.
Jeśli masz te rzeczy gotowe i wiesz, jak zmapować swój format bankowy, wdrożenie sprowadza się do konfiguracji i testowania symulatorem. Jeśli nie masz albo wolisz to zrobić pewnie od razu, mam kartę z zakresem gotowej implementacji: /automatyzacje/uzgadnianie-przelewow. Możemy też zacząć od bezpłatnej diagnozy procesów: /kontakt.
Widełki i składniki wyceny takiego wdrożenia rozpisuję we wpisie /blog/ile-kosztuje-automatyzacja-procesow.