Pomiędzy fakturą a zapłatą do kontrahenta jest sporo elementów, które nie muszą zachowywać się standardowo. Są one dodatkowo narażone na ryzyka oszustwa i kradzieży

Odseparuj fakturę od płatności z nią związanych

Procesowy charakter tworzenia, weryfikacji i akceptacji płatności pozwala logicznie odseparować płatność od obiegu faktury. Oznacza to, że możesz obsłużyć obieg i księgowanie faktury od początku do końca, jednocześnie zostawiając sobie przestrzeń i pełną kontrolę nad płatnościami. A tutaj mamy do czynienia z takimi zdarzeniami jak:

Wstrzymanie płatności.
Płatność faktury w częściach.
Kompensata.
Odrzucenie płatności (np. z powodu zamknięcia rachunku bankowego przez dostawcę).
Zajęcia komornicze wymuszające podział płatności na dwa osobne rachunku, do dwóch osobnych podmiotów.
Podział płatności walutowych od krajowych dostawców na część walutową dla należności netto i część PLN dla VAT.

Wszystkie powyższe sytuacje pozostają widoczne w systemie i pod pełną kontrolą, podczas gdy faktura dotycząca tych płatności jest już dawno zaksięgowana.W przypadku gdy faktura jest uznana w pełni i płacona jednorazowo, system generuje płatność automatycznie. Jednak gdy dzieje się coś nietypowego, co wyłącza płatność automatyczną, wtedy płatność częściowa lub wznowiona wymaga odpowiedniej ścieżki akceptacyjnej.

Kontroluj komu tak naprawdę płacisz

Znane są przypadki naprawdę dużych firm (zbrojeniowych, lotniczych), które zapłaciły (z rozpędu) za podrobione faktury od swoich dostawców. Problem polega na tym, że faktury nie były wystawione przez dostawców, a rachunki bankowe, na które realizowano przelewy, nie należało do dostawców, a do oszustów. Pomijamy przy tym fakt, że do każdej faktury powinien istnieć dokument źródłowy (zamówienie, umowa). Można jednak się łatwo zabezpieczyć przed takimi praktykami. Wystarczy wprowadzić procedury monitorowania zgodności rachunków bankowych. Polegają one w skrócie na tym, że płacimy wyłącznie na rachunki, które zostały przez nas wewnętrznie zweryfikowane i zaakceptowane. Gdy na fakturze pojawia się rachunek bankowy spoza tej grupy, nie możemy na niego ot tak zapłacić. Rachunek musi przejść stosowny proces akceptacyjny, którego immanentną częścią jest weryfikacja tego rachunku z dostawcą.

Niech płatności nietypowe wymagają dodatkowej akceptacji

Automatyzacja jest dobra, gdy dotyczy zdarzeń powtarzalnych i zweryfikowanych. Jednak gdy automatyzujemy obsługę wyjątków, to konsekwencje mogą być groźne i wykorzystane przez osoby o nie do końca krystalicznych intencjach. Np, rachunek dostawcy zostanie podmieniony przy realizacji płatności na inny, przez nieuczciwego użytkownika. Dlatego sprawdzajmy dostawców przy ich wprowadzaniu, sprawdzajmy rachunki bankowe, gdy pojawiają się po raz pierwszy. Robiąc to proceduralnie (procesowo, obowiązkowo), podnosimy jakość i bezpieczeństwo naszych procesów zakupowych, unikając poważnych kłopotów i strat.Jeśli zatem nie ma powodu, by wstrzymywać płatność, a faktura została sparowana z dokumentem źródłowym, kwota się zgadza, mamy akceptację merytoryczną i formalno rachunkową, a płatność jest realizowana na rachunek, który faktycznie należy do dostawcy (bo to już raz sprawdzono) to możemy płacić bez przeszkód. Jeśli jednak płatność była wstrzymana, nie ma zamówienia, ani umowy, które ktoś zatwierdzał, albo płatność ma dotyczyć nowego rachunku — nie akceptujemy płatności z automatu, niech ktoś jeszcze na to zerknie i zaakceptuje taką płatność.

Poniżej przykładowy ideogram płatności automatycznych.

Doskonała kontrola nad płatnościami na poziomie paczki bankowej

Płatności gotowe do realizacji mogą grupowane po dowolnych parametrach (wartość, waluta, konto płatnika, termin płatności) w celu utworzenia z nich paczek bankowych. Jeszcze na poziomie paczki bankowej możesz łatwo przeglądać, z czego wynika dana płatność, czy istnieją jakiekolwiek elementy obniżające pewność co do niej (płatność wznowiona, nietypowy obieg faktury lub płatności, itp.), czy można połączyć płatności do jednego dostawcy.

Ogranicz kontrolę w ramach limitów płatności

Zależnie od specyfiki danej organizacji mamy do czynienie z mniejszą lub większa powtarzalnością określonych płatności.Zamiast kontrolować każdy proces płatności możesz utworzyć “strefy ograniczonego ryzyka”, w ramach których wymogi akceptacyjne są zmniejszone, jednak poziom bezpieczeństwa nadal jest akceptowalny.

Kontynuowanie danego rodzaju płatności wymaga odnowienia budżetu, co oznacza kolejną (kwotową, hurtową) akceptację ze strony menedżera.

W ten sposób możemy ograniczyć ilość akceptacji wykonywanych przez decydentów / menedżerów, zwiększając ich efektywność, przy marginalnym zmniejszeniu bezpieczeństwa transakcji. Transakcje nadal wymagają weryfikacji i akceptacji minimum dwóch osób, jednak menedżerowie nie muszą akceptować każdej z osobna.

Nie pozwól by ktoś zmienił dane Twoich przelewów w drodze do banku

Komunikacja elektroniczna z bankiem może być realizowana na różne sposoby i to w obu kierunkach. Możemy korzystać z gotowej usługi oferowanej przez bank, a cześć banków oferuje dodatkowo mechanizmy integracji (Web Services) oraz API do swoich systemów, zapewniające możliwość bezpiecznego zlecania przelewów, czy pobierania danych o stanie rachunków.Obecnie polski sektor bankowy stara się umacniać innowacyjność finansową w Polsce, wspierając standardy otwartej bankowości (tzw. PolishAPI). Zdefiniowany został interfejs elektronicznego dostępu (wystandaryzowany mechanizm dostępu, niezależny od banku) na potrzeby usług świadczonych przez strony trzecie, w oparciu o dostęp do rachunków płatniczych. Stanowi to kluczowy element usług wprowadzanych przez znowelizowaną dyrektywę w sprawie usługach płatniczych w ramach rynku wewnętrznego UE, czyli PSD2.W DYSANT współpracujemy z poszczególnymi bankami, aby implementować w naszych rozwiązaniach, bezpieczne i zatwierdzone przez banki mechanizmy integracji, które najlepiej służą użytkownikom naszych systemów.

Paczka bankowa z przelewami jest przesyłana przez internet do banku. Jest wtedy narażona na ryzyko modyfikacji, chyba, że będziemy ją przesyłać bezpiecznym i szyfrowanym kanałem uniemożliwiającym modyfikację jej zawartości

Możesz elastycznie wspierać politykę płatności w swojej organizacji

Systemy ERP oraz systemy bankowości elektronicznej nie kojarzą się z elastycznością. Dlatego też trudno tam zastosować typowy dla Twojej organizacji algorytm uprawnień dostępu i akceptacji płatności. Kto może, a kto nie może akceptować płatności do realizacji, które płatności wymagają dwóch potwierdzeń, a co w przypadku konieczności modyfikacji danych do płatności, czy audyt akceptuje przesyłanie plików csv z płatnościami do banku przez niezabezpieczone łącze, kto może wczytać pliki płatności do bankowości elektronicznej? Te i wiele innych wątpliwości i scenariuszy napotykają na bariery technologiczne i kosztowe.Na szczęście moduł DYSANT Płatności pozwala sprawnie i elastycznie zarządzać modelem uprawnień do tworzenia i edycji płatności, procesami generowania i akceptacji płatności, generowania i weryfikacji paczek bankowych oraz zabezpieczonego, szyfrowanego eksportu danych do systemów homebankingu.