Wyciągi MT940 w Rewizor, Subiekt i Rachmistrz nexo: dwa dopasowania i to, którego nikt nie sprawdza

Dwa dopasowania, nie jedno

To trzeci z rzędu tekst o wyciągach bankowych w polskich systemach. Najpierw było enova365, potem Comarch Optima, gdzie jedna opcja z listy potrafi po cichu rozliczyć nie tę fakturę. Linia nexo od InsERT-u zasługuje na osobny tekst, bo tu najciekawsza rzecz dzieje się zupełnie gdzie indziej.

Przy imporcie pliku MT940 nexo dopasowuje dwa razy. Najpierw ustala, od kogo jest pozycja, czyli do której karty kontrahenta należy płatnik. Potem ustala, za co jest wpłata, czyli który rozrachunek pokrywa. Kto narzeka na automatyczne rozliczanie, prawie zawsze mówi o drugim dopasowaniu. W biurach, które oglądałem, więcej zależy od pierwszego. I prawie nikt go nie mierzy.

Jeśli pierwsze dopasowanie się nie uda, drugie w ogóle się nie uruchomi. Pozycja wchodzi jako operacja bankowa bez kontrahenta i ktoś kojarzy ją ręcznie.

A jeśli pierwsze się uda, ale wskaże złego kontrahenta? Drugie przejdzie bez zarzutu. Na niewłaściwym kliencie.

Gdzie jest import

Rewizor nexo, Subiekt nexo i Rachmistrz nexo korzystają ze wspólnego modułu Bank, więc kroki są identyczne, niezależnie od tego, na którym programie pracuje klient. Według pomocy InsERT-u:

1. Otwieracie Bank, zakładkę Operacje bankowe.
2. W menu Bankowość elektroniczna wybieracie Pobierz z pliku → MT940.
3. Wybieracie parser z listy.
4. Wskazujecie plik w polu Plik z wyciągiem i ustawiacie Stronę kodową.
5. Importuj, potwierdzacie.

Program rozlicza potem automatycznie na podstawie trzech rzeczy: tytułu operacji, kwoty i daty. Czego nie sparuje, wchodzi jako nierozliczona operacja bankowa, a ktoś rozlicza ją ręcznie przez skojarzenie.

Plik to nie jedyna droga. Wersje Pro mają integrację z bankowością internetową dla listy banków, a narzędzia zewnętrzne, jak emSzmal, pobierają wyciągi ze stron banków do tego samego modułu. Do księgowości zwykle wystarcza plik. Tak jak w Optimie, godziny nie uciekają na samym imporcie.

Krok trzeci to prawdziwe ustawienie

W pomocy jest jedno zdanie, które można by wydrukować i powiesić nad biurkiem: program powiąże dane klientów tylko z parserów dedykowanych.

Na liście są parsery konkretnych banków i parsery bardziej ogólne. Każdy z nich przeczyta poprawny plik MT940. Różnica leży w tym, co dzieje się z danymi płatnika: nazwą, adresem i numerem rachunku, na których opiera się rozpoznawanie kontrahenta. Parser dedykowany wie, gdzie dany bank wkłada je w pole 86. Ogólny może tego nie wiedzieć. Wtedy te dane nie trafiają do pozycji w postaci, z której nexo potrafi skorzystać.

I nic Was przed tym nie ostrzega. Plik wczytuje się bez błędu, wszystkie operacje są na miejscu, tylko automatycznie rozlicza się ich wyraźnie mniej, niż powinno. Większość osób zrzuca to na tytuły przelewów od klientów. Czasem niesłusznie.

W biurze rachunkowym boli to bardziej niż w pojedynczej firmie. Parser wybiera się dla każdego klienta osobno, zwykle raz, często lata temu, i robi to ten, kto akurat zakładał rachunek w nexo. Klient zmienia bank, ktoś wybiera z listy coś, co czyta plik, i skuteczność dopasowania spada o jedną trzecią. Nikt nie łączy tych dwóch zdarzeń.

Do sprawdzenia: dla każdego klienta zapiszcie bank i używany parser. Klienci na parserze ogólnym, których bank ma parser dedykowany, idą do zmiany w pierwszej kolejności. Dla czterdziestu klientów to godzina pracy i zero kosztów.

Rozpoznawanie kontrahenta i zgadywanie jednym kliknięciem

Z właściwym parserem nexo próbuje rozpoznać kontrahenta po danych z wyciągu. Kiedy dane nie pasują dokładnie do karty (w pozycji jest „JAN KOWALSKI FHU”, na karcie „Firma Handlowo-Usługowa Jan Kowalski”), program pokazuje kandydatów ze współczynnikiem dopasowania i przycisk Najwyższy współczynnik dopasowania kontrahenta. Jedno kliknięcie przypisuje kandydata z najlepszym wynikiem.

Ten przycisk świetnie przyspiesza pracę. I właśnie tu zatwierdza się złego kontrahenta. Dwie firmy o podobnych nazwach, jednoosobowa działalność i spółka z o.o. tego samego właściciela, spółka matka i córka: najwyższy wynik zwykle jest trafny. Kiedy nie jest, rozliczenie przechodzi bez zarzutu na niewłaściwej karcie. Wpłata pokrywa fakturę kogoś, kto jej nie zapłacił, a faktura prawdziwego płatnika zostaje otwarta. Wychodzi to później, tak samo jak w Optimie: wezwaniem do zapłaty dla klienta, który zapłacił.

Najtańsza poprawka to ta sama, do której ciągle wracam: numer rachunku płatnika na karcie kontrahenta. To jedyne pole w pozycji wyciągu, które generuje sam bank, więc nikt się w nim nie pomyli. Karta z uzupełnionym numerem rachunku nie potrzebuje zgadywania po podobieństwie nazw. W bazach nexo, które widziałem, spora część kart ma to pole puste, bo kartę założono z faktury, a na fakturze numer rachunku klienta nie jest do niczego potrzebny.

Do sprawdzenia: zaimportujcie jeden miesiąc jednego klienta i policzcie dwie rzeczy: operacje, które weszły bez kontrahenta, i operacje, w których kontrahenta przypisał współczynnik, a nie dokładne dopasowanie. Tej drugiej liczby nikt nie śledzi, a właśnie tam siedzą niewidoczne błędy.

Co potrafi etap rozliczania, a czego nie

Kiedy kontrahent jest właściwy, rozliczanie po tytule, kwocie i dacie dobrze radzi sobie z pozycjami, dla których je zaprojektowano: jeden przelew, jedna faktura, numer w tytule. nexo ma też kilka przydatnych dodatków. W Subiekt nexo można powiązać dyspozycję bankową z zamówieniem do dostawcy i wyciąg rozliczy ją automatycznie. Podzielona płatność ma własny rodzaj operacji, więc część VAT nie jest wciskana w dopasowanie po jednej kwocie.

To, co zostaje po czystym imporcie, układa się w te same kupki, co w Optimie i enova365:

• Wygląda jak numer faktury, ale nie jest. „FV 412” bez roku, numer zamówienia klienta, inny separator.
• Jeden przelew za kilka faktur. Trzeba ustalić, które faktury składają się na kwotę. Zakres zawężają kontrahent i daty, ale ręcznie to i tak mordęga.
• Niedopłaty. Kilka złotych mniej: zaokrąglenie, prowizja banku czy spór? To najpierw pytanie o zasadę w biurze, a dopiero potem o dopasowanie.
• Pusty albo bezużyteczny tytuł. Telefon. Żaden model nie odtworzy informacji, której nikt nie zapisał.

Ogólną mechanikę uzgadniania wyciągów (kolejkę, próg pewności, MPP) opisałem w tekście o automatyzacji księgowania wyciągów.

Gdzie w nexo pasuje agent

Agent pracujący obok nexo czyta nierozliczone operacje i otwarte rozrachunki. W Rewizorze i Subiekcie robi to przez Sferę, programowalną warstwę, o której pisałem w tekście o integracji Rewizor nexo i w przewodniku po Sferze w Subiekt nexo. U klientów bez licencji Sfery pracuje na okresowym eksporcie. Dla każdej pozostałej pozycji układa kandydatów (numery faktur „prawie” pasujące, kombinacje kwot, to, jak dany kontrahent zwykle płaci) i odkłada do kolejki propozycję z uzasadnieniem. Księgowa ją zatwierdza albo odrzuca.

Jedno zadanie waży w nexo dużo więcej niż w pozostałych dwóch systemach i to ono jest tu najcenniejsze: sprawdzanie pierwszego dopasowania. Przy każdej operacji, w której kontrahenta przypisał współczynnik, a nie numer rachunku, agent sprawdza trzy rzeczy. Czy numer rozliczonej faktury występuje w tytule? Czy kwota pasuje do historii płatności tego kontrahenta? Czy inny kontrahent o podobnej nazwie nie ma otwartej należności dokładnie na tę kwotę? Wszystko, co budzi wątpliwości, trafia do kolejki przed zamknięciem miesiąca, a nie po wysłaniu wezwań.

Sam niczego nie rozlicza i nie rusza ustawień parserów ani kart. Zgłasza: „klient 17 jest na parserze ogólnym, 38% pozycji weszło bez kontrahenta”, a decyzję podejmuje człowiek. Jak podchodzę do takich wdrożeń, opisuję na stronie agenci AI dla firm.

Dwie liczby przed jakąkolwiek automatyzacją

Jeśli prowadzicie klientów w nexo, policzcie dwie rzeczy dla jednego klienta i jednego miesiąca:

1. Operacje zaimportowane bez kontrahenta i parser, którego ten klient używa.
2. Operacje przypisane przez współczynnik dopasowania i to, ile z nich, sprawdzonych ręcznie, trafiło do złego kontrahenta.

Pierwsza liczba mówi, ile tracicie, zanim rozliczanie w ogóle się zacznie. Druga mówi, ile rozliczeń w zamkniętych miesiącach jest po cichu błędnych. Z mojego doświadczenia pierwsza mocno spada po zmianie parsera i jednym popołudniu uzupełniania numerów rachunków, bez żadnej automatyzacji. Na drugiej agent zarabia na siebie.

Chcecie, żebym spojrzał na te liczby? Wyślijcie mi jeden zanonimizowany miesiąc, a powiem Wam, która z nich jest u Was prawdziwym problemem.