Połączenie listy wizyt z wyciągiem bankowym wygląda jak proste wyszukanie nazwiska. W rzeczywistych danych płatność może jednak przyjść z konta innej osoby, jeden przelew może obejmować kilka wizyt, tytuł może być niepełny, a część klientów płaci gotówką. Dlatego bezpieczny system nie powinien automatycznie uznawać każdego podobnego rekordu za poprawne dopasowanie.
W realizacji Blisko Siebie zbudowałem lokalną aplikację, która importuje wizyty i wyciągi CSV, XML oraz XLSX, normalizuje dane, blokuje duplikaty, proponuje dopasowania i pozostawia niejasne przypadki do decyzji pracownika. Walidacja objęła 352 rekordy wizyt i 226 transakcji z kilku wyciągów.
Dlaczego samo nazwisko nie wystarcza
Nazwisko jest tylko jednym sygnałem. Może występować u kilku osób, być zapisane z literówką albo nie pojawić się w tytule przelewu w ogóle. Czasem klient płaci z konta partnera, rodzica lub firmy.
Jeśli system tworzy dopasowanie wyłącznie na podstawie imienia lub fragmentu tekstu, może oznaczyć jako opłaconą niewłaściwą wizytę. Taki błąd jest gorszy od pozostawienia rekordu do sprawdzenia, ponieważ ukrywa zaległość pod pozornie poprawnym statusem.
W Blisko Siebie system nie tworzył kandydatów na podstawie samego imienia. Brał pod uwagę kombinację nazw, dat, kwot i opisu płatności.
Krok 1: zachowaj surowe dane
Import powinien przechowywać oryginalny rekord razem ze źródłem. Dzięki temu można później sprawdzić, z którego pliku pochodziła transakcja, jak wyglądał jej tytuł i które pole zostało znormalizowane.
Nadpisanie oryginalnych wartości utrudnia wyjaśnienie błędu. Lepszy układ to:
- surowy rekord ze źródła;
- znormalizowana reprezentacja używana do porównania;
- wynik dopasowania;
- historia ręcznej decyzji.
Krok 2: nadaj rekordom stabilne identyfikatory
Ten sam wyciąg może zostać zaimportowany ponownie. Pliki z różnych rachunków mogą też zawierać transakcje wyglądające podobnie.
System powinien rozpoznawać rekord po stabilnym identyfikatorze źródłowym albo po kontrolowanym zestawie pól. Nie wystarczy sprawdzić, czy zgadza się kwota i data — dwie prawdziwe płatności mogą mieć takie same wartości.
W walidacji Blisko Siebie system nie przypisał automatycznie tego samego identyfikatora transakcji do kilku wizyt. Zasada była prosta: jedna transakcja może zostać automatycznie przypisana najwyżej do jednej wizyty.
Krok 3: normalizuj, ale nie zgub kontekstu
Normalizacja ułatwia porównanie danych zapisanych w różny sposób. Może obejmować:
- wielkość liter i polskie znaki;
- dodatkowe spacje oraz znaki interpunkcyjne;
- format daty i kwoty;
- kolejność imienia i nazwiska;
- typ źródła i rachunek, z którego pochodzi rekord.
Nie należy jednak sprowadzać całego rekordu do jednego ciągu tekstu. Kwota, data, osoba, opis i źródło mają różne znaczenie i powinny pozostać oddzielnymi sygnałami.
Krok 4: oceniaj kandydatów według jawnych reguł
Zamiast odpowiedzi „pasuje albo nie pasuje” system może policzyć wynik kandydata. Poszczególne sygnały mają różną wagę:
- zgodność pełnego nazwiska jest mocniejsza niż zgodność samego imienia;
- dokładna kwota jest ważna, ale nie rozstrzyga płatności zbiorczej;
- data przelewu powinna mieścić się w rozsądnym przedziale względem wizyty;
- dodatkowy opis może wzmacniać albo osłabiać kandydata;
- wykorzystana wcześniej transakcja nie powinna wracać jako wolny kandydat.
Reguły deterministyczne mają ważną zaletę: da się wyjaśnić, dlaczego system zaproponował dane dopasowanie. W tym projekcie dane pozostały lokalnie i nie były przekazywane do zewnętrznego modelu AI.
Krok 5: oddziel dopasowanie pewne od prawdopodobnego
Nie każdy wynik powinien przechodzić automatycznie. Potrzebne są przynajmniej trzy stany:
- dopasowanie spełniające ustalone warunki;
- kandydat prawdopodobny, wymagający sprawdzenia;
- brak wiarygodnego kandydata.
Pracownik powinien widzieć nie tylko status, ale również kontekst: wizytę, proponowaną transakcję, kwotę, datę, opis oraz powód wyniku. Dzięki temu nie odtwarza całego porównania od początku.
Krok 6: obsłuż płatności zbiorcze i gotówkę osobno
Płatność zbiorcza łamie zasadę prostego dopasowania jednej kwoty do jednej wizyty. Może obejmować kilka terminów albo kilka osób. Dlatego wymaga oddzielnej ścieżki i świadomego podziału.
Gotówka również nie powinna być udawana jako transakcja bankowa. Potrzebuje własnego źródła, osoby rejestrującej i historii zmiany.
Próba wciśnięcia wszystkich przypadków w jedną automatyczną regułę zwiększa liczbę pozornie zamkniętych, ale błędnych rozliczeń.
Krok 7: raportuj wyjątki, a nie tylko sukcesy
Dobry dashboard pokazuje:
- wizyty oznaczone jako zapłacone;
- brak płatności;
- prawdopodobne dopasowania;
- otwarte zaległości;
- przypadki wymagające sprawdzenia;
- źródło i historię decyzji.
Raport końcowy powinien dać się zweryfikować. W Blisko Siebie aplikacja przygotowuje również treść przypomnienia, ale nie wysyła jej automatycznie. Decyzja o kontakcie pozostaje po stronie pracownika.
Co dała walidacja
Reprezentatywna walidacja objęła 352 wizyty i 226 transakcji. System nie używał automatycznie tego samego identyfikatora transakcji przy kilku wizytach i nie tworzył kandydatów na podstawie samego imienia.
W tym konkretnym procesie rozwiązanie szacunkowo ograniczyło ręczną identyfikację niezapłaconych wizyt o około 90%. To szacunek dotyczący tej realizacji, a nie gwarancja wyniku dla innej firmy. Najważniejsza zmiana polegała na tym, że człowiek sprawdza wyjątki zamiast porównywać każdy rekord od początku.
Pełny ekran i opis zakresu znajdują się w realizacji Blisko Siebie. Jeśli w Twojej firmie podobne dane są porównywane ręcznie, zobacz integracje i automatyzacje albo opisz przykładowy przypadek.