Większość polskich MŚP traktuje wyciąg bankowy jak pocztówkę z lat 90-tych: ściągamy plik z bankowości, klikamy „importuj" w ERP, potem księgowa ręcznie dopina płatności do faktur. Tymczasem od 2019 roku każdy większy polski bank udostępnia API, które robi to za nas — wystarczy je tylko podpiąć.
Robimy te integracje regularnie i wzór jest powtarzalny. Firma ma trzy konta w dwóch bankach, dwie waluty, ERP (najczęściej Comarch Optima albo enova365) i jedną osobę w księgowości, która co poniedziałek rano spędza dwie godziny na imporcie i dopinaniu wyciągów. Co tydzień, przez cały rok. To setki godzin pracy, której nikt nie chciałby robić, gdyby miał wybór.
U jednego z naszych klientów — 25-osobowej hurtowni części samochodowych — księgowa traciła 8 godzin tygodniowo na ręczny import wyciągów z trzech banków (mBank, Santander, ING) do Comarch Optimy i matchowanie ich z fakturami sprzedażowymi. Po integracji przez API plus regułowy matching po tytułach przelewów i kwotach: 30 minut tygodniowo na ręczne sprawdzenie wyjątków. Reszta dzieje się sama, w nocy. Zwrot z inwestycji — niespełna cztery miesiące.
Co naprawdę kosztuje ręczna obróbka wyciągów
Łatwo niedoszacować skalę problemu. Wydaje się, że „te 15 minut dziennie" to nic. Policz to inaczej — na rok.
Standardowa hurtownia z dwoma kontami złotówkowymi i jednym walutowym to typowo 50–80 transakcji dziennie. Księgowa otwiera bankowość, pobiera MT940 albo CSV, wchodzi do ERP, klika „importuj", wybiera plik, czeka, sprawdza co się wczytało, dopina płatności do faktur — najczęściej po kwocie i fragmencie nazwy kontrahenta. Czasem trzeba ręcznie poprawić bo bank wpisał kontrahenta w innym formacie niż jest w kartotece. Tygodniowo 5–10 godzin pracy w dobrym tygodniu. W złym — dwa razy tyle, bo trzeba szukać, dlaczego klient zapłacił 4 873 zł zamiast 4 873,15 zł.
Do tego dochodzi koszt opóźnień. Sprzedawcy nie widzą w ERP, czy faktura jest zapłacona, więc dzwonią do księgowości. Klienci dostają monity, mimo że zapłacili w piątek po południu — bo wyciąg „zostanie zaksięgowany w poniedziałek". Drobiazgi, ale w sumie kosztują wiarygodność i czas.
Co umie dziś polski bank, a co Twój ERP
Polska bankowość jest tu nadspodziewanie dobrze przygotowana. Wszystkie banki obsługujące klientów biznesowych — mBank, ING, Santander, Pekao, PKO BP, Millennium, Alior, BNP Paribas — wystawiają API zgodne z PSD2 (AIS), które pozwala pobierać salda i wyciągi w sposób programowy. Część banków oferuje też API dedykowane dla księgowości, z bogatszymi danymi (mBank CompanyNet API, ING Business API, Santander mojeID Business).
Po drugiej stronie — Twój ERP. Tu sytuacja zależy od systemu:
- Comarch Optima ma wbudowany moduł „Comarch ERP Optima Wirtualne Konto" oraz integracje przez Comarch Bank Connect dla wybranych banków. Działa, ale nie wszystkie banki są wspierane out-of-the-box.
- enova365 ma moduł „Pulpit Bankowy" i wsparcie dla bankowości elektronicznej w standardach Webservice/Multicash.
- Subiekt GT/nexo czyta MT940 i pliki CSV, ale natywnej integracji API nie ma — trzeba pośrednika.
- Microsoft Dynamics 365 BC / NAV — ma konektory bankowe, ale dla polskich banków często wymaga dedykowanego rozwiązania.
W praktyce: nawet jeśli Twój ERP „nie ma integracji z bankiem X", zwykle da się ją zrobić middlewarem — małą usługą, która łączy API banku z API ERP. To dosłownie kilkaset linii kodu w .NET albo w Pythonie. Nie projekt na pół roku.
Matching płatności — tu jest cała robota
Samo ściąganie wyciągów to 20% problemu. Reszta to dopasowanie wpłaty do faktury. Brzmi prosto: jest kwota, jest tytuł, jest kontrahent. W rzeczywistości — bywa różnie.
Typowe wyzwania:
- Klient płaci za dwie faktury jednym przelewem (z opisem typu „FV 123, 124").
- Klient płaci kwotę pomniejszoną o reklamację, której nie zgłosił przez system.
- W tytule jest „zapłata za fakturę 12/06/2025" — nie wiadomo czy to numer, czy data.
- Płatność przychodzi z konta osoby fizycznej (małżonek, księgowa zewnętrzna), nie z konta firmy z kartoteki.
- Klient płaci za fakturę z poprzedniego roku, po której zmienił się NIP.
W praktyce sensowny matching opiera się na warstwowych regułach: najpierw szukamy idealnego dopasowania (numer faktury w tytule + kwota się zgadza), potem fuzzy matching (numer faktury jest, ale kwota się różni o mniej niż 1 zł — pewnie zaokrąglenie), potem dopasowanie po samym numerze, potem ręczne sprawdzenie reszty. Dobrze skonfigurowany system łapie automatycznie 85–95% płatności. Resztą zajmuje się człowiek — i to jest OK, bo to są właśnie te przypadki, w których trzeba pomyśleć.
Plan wdrożenia w 4 krokach
Tak typowo wygląda taki projekt u 20–50-osobowego klienta. Realne 6–8 tygodni od decyzji do produkcji.
- Tydzień 1–2: audyt i decyzje. Spisanie listy kont bankowych, walut, typowych scenariuszy płatności, ERP-a i jego wersji. Decyzja: integracja natywna ERP-a czy middleware. Wybór banku, z którego zaczynamy (najlepiej tego z największym ruchem — szybciej zobaczysz korzyść).
- Tydzień 3–4: dostęp do API banku i piaskownica. Tu zwykle jest najwięcej formalności — banki wymagają umów, certyfikatów eIDAS dla PSD2, czasem wizyty w oddziale. Warto to zacząć od razu, równolegle do prac developerskich.
- Tydzień 5–6: implementacja i testy. Połączenie API banku z ERP-em, konfiguracja reguł matchingu, podpięcie kartoteki kontrahentów. Na tym etapie pojawiają się najciekawsze odkrycia — np. że 200 kontrahentów w kartotece ma NIP zapisany ze spacjami, a 80 nie ma go wcale.
- Tydzień 7–8: równoległy run i przejęcie. Przez dwa tygodnie ręczny import działa dalej, a integracja jedzie obok. Codziennie porównujesz wyniki. Po dwóch tygodniach, kiedy wszystko się zgadza, wyłączasz import ręczny.
Najczęstsze błędy
Trzy rzeczy, które zwykle bolą najbardziej:
- Brak monitoringu integracji. Jeśli middleware przestaje działać o 3:00 w nocy, nikt o tym nie wie aż do poniedziałku rano. Konieczny prosty alerting (mail/Slack) na błędy autoryzacji w banku i na brak wyciągów dłużej niż 24 godziny.
- Brzydka kartoteka kontrahentów. Wracamy do punktu wyjścia z naszego ulubionego wątku — bez czystych danych każda integracja jest tylko głośniejszym chaosem. Warto najpierw posprzątać NIP-y, nazwy i numery rachunków bankowych w kartotece.
- Zbyt agresywny auto-matching. Pokusa, żeby „zaksięgować wszystko automatycznie", jest duża. Ale jeśli system pomyli dwóch klientów o podobnych nazwach, rozplątywanie tego zajmie więcej czasu niż zaoszczędziła automatyka. Lepiej zostawić wątpliwe przypadki do ręcznego sprawdzenia.
Co dalej
Integracja banku z ERP-em to jeden z tych projektów, gdzie ROI łatwo policzyć i łatwo pokazać. Godzina pracy księgowej kosztuje kilkadziesiąt złotych, a typowo odzyskasz 5–10 godzin tygodniowo. W skali roku to kilkanaście tysięcy złotych mniej kosztu i — co ważniejsze — księgowa, która ma czas na rzeczy, które naprawdę wymagają człowieka.
Jeśli zastanawiasz się, czy w Twojej konfiguracji ERP + banki taki projekt ma sens, najszybciej dowiesz się tego z półgodzinnej rozmowy. Bez prezentacji, bez slajdów — pytania, na które trzeba sobie odpowiedzieć, są przewidywalne.
Nie potrzebujesz hurtowni danych, żeby przestać przepisywać wyciągi z bankowości do ERP-a. Potrzebujesz API i kilkudziesięciu godzin pracy.