Wyciągi bankowe w enova365 — o poziomie automatycznego rozliczania decydują Wasi klienci, nie system

Każda instalacja enova365, którą otwierałem, potrafi już zaimportować wyciąg bankowy. Moduł Ewidencji Środków Pieniężnych czyta MT940, powstaje raport bankowy, pozycje lądują tam, gdzie powinny. Nikt nie potrzebuje do tego konsultanta i nikt nie powinien za to brać pieniędzy.

Trzy godziny w poniedziałkowy poranek kosztuje księgową dopiero to, co dzieje się po wczytaniu pozycji: ustalenie, który rozrachunek zamyka każda z nich.

Zanim wydacie na ten problem pieniądze, jedna rzecz. Wasz sufit — udział pozycji, które kiedykolwiek da się dopasować bez człowieka — nie jest cechą enova365, Waszego biura ani żadnego agenta, którego mógłbym Wam zbudować. Jest cechą tego, co Wasi klienci wpisują w tytule przelewu.

Da się to zmierzyć w jedno popołudnie. Prawie wszyscy najpierw kupują, a mierzą potem.

Jak wyciąg trafia do systemu: trzy drogi, a zwykle właściwa jest ta nudna

Plik MT940. Eksportuje go każdy polski bank firmowy. Definicję formatu ustawia się raz na bank, wskazuje enova365 plik i raport bankowy się wypełnia. To rytm dnia następnego, czyli dokładnie to, czego potrzebuje księgowanie, i zupełnie nie to, czego potrzebuje decyzja o zapłacie dostawcy dziś po południu.

Dodatek bankowości elektronicznej. enova365 sprzedaje bezpośrednie połączenia z większymi polskimi bankami. Kosztuje kolejny moduł i likwiduje bieganie z plikami. Próg opłacalności to mniej więcej moment, w którym jedna osoba ściąga pliki z więcej niż trzech banków albo ktoś piętro wyżej chce widzieć stan gotówki w ciągu dnia.

Wpychanie pozycji z zewnątrz przez WebAPI. To potrzebne tylko wtedy, kiedy pieniądze przychodzą stamtąd, dokąd enova365 nie sięga — od operatora płatności, z platformy faktoringowej, z zagranicznego rachunku, z agregatora PSD2 obsługującego piętnaście kont naraz. Mechanika jest ta sama, którą opisałem w przewodniku po WebAPI, łącznie z kwestią licencji, która zatrzymuje więcej takich projektów niż jakikolwiek problem techniczny.

W większości biur pierwsza droga jest właściwa i taka zostaje. Rozwodzę się nad tym, bo rozmowy o automatyzacji zwykle zaczynają się od importu, a pieniądze leżą gdzie indziej.

Co enova365 robi już sama

Wbudowane automatyczne rozliczanie dopina zapis z wyciągu do rozrachunku wtedy, kiedy potrafi rozpoznać kontrahenta i znajduje dokładnie jednego kandydata pasującego kwotą. Jeśli definicja formatu wyciąga z opisu numer dokumentu, korzysta również z niego.

To działa. To nie jest wąskie gardło. Wąskim gardłem jest to, że mechanizm musi mieć pewność, a pewności ubywa błyskawicznie, im niżej wyciągu schodzicie.

Jedna rzecz w tym mechanizmie zasługuje na więcej uwagi, niż dostaje: numer rachunku płatnika to najbardziej wiarygodne pole w całej pozycji. Generuje je bank, nie wpisuje człowiek. Jeśli kartoteki kontrahentów mają uzupełnione numery rachunków, rozpoznanie kontrahenta dostajecie niemal za darmo.

W każdej instalacji, do której zaglądałem, spora część kartotek ma to pole puste — bo dopóki nikt nie próbował automatyzować rozliczeń, nikomu nie było potrzebne. Uzupełnienie ich to niewdzięczne klepanie danych — i przesuwa poziom dopasowania dalej niż jakikolwiek model, który mógłbym dołożyć na wierzch. Zróbcie to, zanim cokolwiek kupicie.

Cała gra toczy się o pole tytułu

Oto audyt. Wyeksportujcie miesiąc przychodzących pozycji z wyciągów i rozłóżcie je na cztery kubełki:

1. Zawiera numer faktury, który istnieje w księgach. Czytelny, poprawny, jednoznaczny.
2. Zawiera coś w kształcie numeru, ale nie ten. Stary numer, własne zamówienie klienta, „FV 12” bez roku, numer z ukośnikiem tam, gdzie Wy macie myślnik.
3. Zawiera słowo, nie odniesienie. „faktura”, „płatność”, „za towar”, „przelew”.
4. Puste albo imię i nazwisko.

Rozkład, który widuję: kubełek 1 to 55-80% w biurach, których klienci są firmami fakturującymi z terminem płatności, i spada poniżej 40% u każdego, kto obsługuje detal albo wielu drobnych płatników. Różnica między dwoma klientami w jednym biurze bywa większa niż różnica między dwoma systemami ERP.

Teraz przyłóżcie te kubełki do tego, co już macie. Kubełek 1 to zadanie enova365 i system prawdopodobnie robi z niego większość. Kubełek 4 to telefon i telefonem zostanie — żaden model nie odtworzy informacji, której nikt nigdy nie zapisał.

Kubełki 2 i 3 to właściwy teren. Nie są nierozwiązywalne. Wymagają uszeregowania kandydatów według dopasowania i decyzji, gdzie postawić próg pewności — a to jest dokładnie ten rodzaj pracy, z którym silnik reguł radzi sobie źle, a dobrze zakrojony agent dobrze.

Z czego wychodzi uczciwa arytmetyka zamiast obietnicy. Jeśli kubełek 1 to 78%, a enova365 rozlicza sama 70%, to nad tym zostaje jakieś dwadzieścia punktów, z których realnie weźmiecie dwanaście do piętnastu. W zapracowanym biurze to godzina dziennie. To nie jest „rozliczanie jest już automatyczne”, a kto mówi inaczej, ten nie zaglądał do Waszych wyciągów.

Podzielona płatność: jedyne miejsce, w którym ustawodawca dał Wam czyste dane

Przelew w MPP niesie komunikat o narzuconej strukturze — kwota VAT, NIP płatnika, numer faktury i tekst dowolny, każde w osobnym, oznaczonym polu, w tym samym opisie, który wszyscy inni wypełniają prozą.

Pomyślcie, co to znaczy. Przepis, na który księgowi narzekają najgłośniej, jest jedynym miejscem w polskim systemie płatności, gdzie odniesienie do faktury standaryzuje ustawa. Jeśli istotna część Waszych wpływów idzie przez split payment, część problemu dopasowania macie już rozwiązaną — i większość wdrożeń w ogóle tego nie tyka. Pozycja MPP jest w nich traktowana jako przypadek kłopotliwy: dwie kwoty, jedna faktura. Zamiast jako najlepiej ustrukturyzowany rekord na całym wyciągu.

Ogólną mechanikę netto, VAT i brutto na dwóch rachunkach opisałem w tekście o automatyzacji księgowania wyciągów. To, co jest specyficzne dla enova365, jest węższe i łatwe do przeoczenia: definicja formatu bankowego musi wyciągnąć te podpola do czegoś, co widzi mechanizm dopasowania. Domyślnie cały ten ustrukturyzowany ciąg przychodzi bardzo często jako jedna bryła tekstu opisu. Technicznie zaimportowany. Praktycznie niewidoczny.

Pozycje, które nigdy się nie dopasują, według tego, czy automatyzacja pomaga

Jeden przelew na jedenaście faktur. Rozwiązywalne — to problem podzbioru ograniczony kontrahentem i oknem dat. Warto zautomatyzować wcześnie, bo to jednocześnie przypadek, który ludzie znoszą najgorzej.

Płatności częściowe i niedopłaty. Rozwiązywalne mechanicznie, zablokowane na polityce. Jaka wielkość niedopłaty jest różnicą zaokrągleniową, a jaka sporem? Złotówka? Pół procenta? Prawie żadne biuro nie ma tego spisanego, dopóki ktoś nie zapyta, a nie da się zautomatyzować reguły, która jeszcze nie istnieje.

Kompensaty. Klient zapłacił mniej, bo potrącił własną fakturę. Nic w pozycji bankowej tego nie mówi. Agent potrafi zauważyć, że niedopłata równa się otwartemu zobowiązaniu wobec tego samego podmiotu — i to jest naprawdę użyteczny sygnał, którego dziś nikt nie produkuje. Zaksięgować kompensaty nie może, bo kompensata jest porozumieniem dwóch stron, a nie obserwacją arytmetyczną.

Opłaty bankowe, odsetki, różnice kursowe. Mechaniczne, masowe, nudne — i automatyzują się bez ryzyka. Często najlepsza pierwsza wygrana i jednocześnie ta, która nigdy nie trafia do oferty, bo nie brzmi efektownie.

Klient opłacił nie tę fakturę. Tego nie naprawi żaden system. Ktoś podnosi słuchawkę.

Duplikat, którego nie zauważycie

enova365 numeruje zaimportowane wyciągi i odmówi przyjęcia oczywiście powtórzonego raportu. Nie ochroni Was natomiast przed wyciągiem śróddziennym.

Kilka banków pozwala pobrać wyciąg z bieżącego dnia przed zamknięciem, a po zamknięciu wystawia właściwy. Oba pliki są prawidłowe. Drugi zawiera pierwszy. Zaimportujcie oba i po cichu podwoiliście pozycje z całego dnia.

W odróżnieniu od zdublowanej faktury zdublowany zapis bankowy niczego nie wywraca. Coś rozlicza. Wychodzi pięć tygodni później jako klient, który wygląda na nadpłaconego, i wtedy nikt już nie pamięta, którego ranka ktoś złapał wcześniejszy plik. Do ksiąg importujcie wyłącznie wyciągi z zamknięcia dnia; jeśli potrzebujecie danych śróddziennych, trzymajcie je w raporcie kasowym poza księgami. Brzmi zbyt oczywiście, żeby to pisać, a widziałem to dwa razy.

Od czego zacząć

Zróbcie audyt pola tytułu, zanim porozmawiacie z jakimkolwiek dostawcą, mną włącznie. Jeden miesiąc, cztery kubełki, popołudnie czyjejś pracy.

Jeśli kubełek 1 przekracza 75%, a numery rachunków w kartotekach są uzupełnione, Wasze rozliczanie jest już blisko tego, na co pozwala mechanika, a budżet na automatyzację powinien pójść gdzie indziej — najpewniej na stronę wczytywania dokumentów albo na kontrole statusów KSeF, które opisałem wczoraj. Jak to wygląda całościowo po stronie usług, pokazuję tutaj: integracja enova365 z AI.

Jeśli kubełki 2 i 3 to razem więcej niż jedna czwarta pozycji, macie realny projekt o mierzalnym rozmiarze. Budujcie go w trybie tylko do odczytu: proponuje rozliczenia do kolejki, człowiek zatwierdza. Nic nie księguje się samo. To trzyma całość po bezpiecznej stronie granicy, którą opisałem w tekście o tym, kto podpisuje, gdy agent się pomyli, i zamienia pierwszy miesiąc w pomiar Waszego prawdziwego poziomu dopasowania zamiast w akt wiary.

I jedna liczba na koniec, kiedy to już działa. Metryka warta pilnowania to nie poziom dopasowania. To udział gotówki z miesiąca rozliczonej do 10. — to samo pytanie o rozkład w czasie, które decyduje, czy zamknięcie miesiąca jest kumulacją, czy rutyną.

Chcecie wiedzieć, do których kubełków trafiają Wasze wyciągi? Napiszcie do mnie — przyślijcie jeden zanonimizowany miesiąc, a powiem Wam, gdzie jest sufit, zanim ktokolwiek cokolwiek zbuduje. Pół godziny, bez opłat.