Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaCodzienna reguła wskazuje, gdzie skonto się opłaca, a gdzie wystarczy zapłacić w terminie
Skonto brane wtedy, gdy przewyższa koszt pieniądza
Robot codziennie czyta pozycje otwarte, stosuje regułę uzgodnioną przez CFO i skarbnika i proponuje przebieg płatności wraz z uzasadnieniem każdej pozycji.
Streszczenie dla zarządu
Dostawcy oferują skonto. To kalendarz płatności decyduje, czy Państwo je biorą.
Budujemy silnik terminów płatności, który uruchamia się każdego ranka na danych SAP i na prognozie treasury w takiej formie, w jakiej dziś istnieje.
Okna skonta są dotrzymywane, bo datę płatności wyznacza termin skonta, a nie kalendarz.
propozycja płatności w SAP S/4HANA; korekty danych podstawowych dostawców w SAP; model semantyczny Power BI
Problem biznesowy
Zarządzanie gotówką
O terminach płatności decydują trzy osoby o trzech różnych perspektywach i bez wspólnej reguły. Zobowiązania widzą terminy wymagalności i nacisk dostawców. Treasury widzi saldo bankowe i prognozę. Zakupy wynegocjowały warunki i nikomu nie powiedziały, że skonto w ogóle istnieje.
Konkretem stają się dane podstawowe dostawców. Warunki płatności bywają w nich błędne, rzadko zawierają skonto i nigdy nie są porównywane z tym, co widnieje na fakturze. Skonto jest więc łapane wtedy, gdy faktura przypadkiem zostanie zaakceptowana wcześniej, a w pozostałych przypadkach przepada domyślnie. Płatności po terminie powstają z odwrotnego powodu: faktura zablokowana lub zawieruszona do czasu po dacie wymagalności, a potem regulowana z odsetkami, opłatą albo rozmową, która kosztuje relację.
Nawyk trzyma się mocno, bo przebieg płatności jest rutyną, a nie decyzją. Nikt nie wytwarza jednej liczby, która by go zmieniła: skonto oferowane w tym miesiącu, skonto wzięte i różnica między nimi. Bez tej liczby nie ma czego wpisać do porządku obrad, więc przebieg dalej wychodzi w czwartek, a okna skonta dalej zamykają się w środę.
Jak to wygląda dzisiaj
Taki kształt spotykamy w większości firm z tygodniowym przebiegiem, niezależnie od ERP.
- SystemTygodniowy przebieg jest zaplanowany, a zobowiązania wybierają wszystko wymagalne przed kolejnym
- CzłowiekEskalacje dostawców dopisuje się do listy ręcznie, po telefonach i ponaglających mailach
- OczekiwanieSkarbnik widzi sumę rano w dniu przebiegu i odracza pozycje względem salda bankowego
- Ryzyko błęduSkonto jest zauważane tylko tam, gdzie warunek przypadkiem jest poprawny w danych podstawowych
- SystemPlik płatności zostaje zwolniony; część pozycji idzie wcześniej bez skonta, część po terminie
- CzłowiekOdsetki i opłaty za zwłokę przychodzą jako obciążenia od dostawcy i są księgowane bez pytania dlaczego
- Ryzyko błęduWarunki skonta wydrukowane na fakturze nigdy nie wracają do danych podstawowych dostawcy
- CzłowiekRaport na koniec miesiąca pokazuje rotację zobowiązań i milczy o skoncie
Dlaczego obecny proces kosztuje więcej, niż widać
Za każdym wyjątkiem stoi godzina, której nikt nie zapisał.
- 2% skonta za zapłatę dwadzieścia dni wcześniej obejmuje 5,48% roku, więc w ujęciu rocznym jest wielokrotnie wyższe niż przyjęty tu koszt pieniądza 4,5%. Zespoły finansowe wiedzą to w teorii i tracą przy każdym przebiegu, bo nic w tygodniowej rutynie tego nie sprawdza.
- Opłaty za zwłokę pojedynczo są drobne i księgowane jako obciążenia dostawcy, a nie jako koszt procesu, więc nikt ich nie sumuje.
- Zapłata przed terminem bez skonta to darmowy kredyt dla dostawcy; zapłata po terminie zużywa relację, która wraca jako twardsze warunki przy kolejnych negocjacjach. Żadne z tego nie pojawia się w raportach.
- Treasury utrzymuje bufor wymierzony pod niepewność, a nie pod plan, bo plan przychodzi rano w dniu przebiegu.
- Rozjazd danych podstawowych narasta. Jeden źle wprowadzony warunek płatności pozostaje błędny na każdej kolejnej fakturze tego dostawcy, a nikt nie ma w kalendarzu sprawdzania tego.
Koszt zaniechania
Nie cały pierwszy wiersz da się odzyskać i sprawa jest mocniejsza, gdy powiedzieć to wprost. Reguła kwalifikuje mniej więcej dziewięć dziesiątych tego, co jest oferowane, a przesunięcie 11 880 000 € wydatków o dwadzieścia dni wcześniej kosztuje 29 300 € gotówki. Zostaje z tego około 237 600 € skonta plus opłaty, rozproszone po dziewięciuset dostawcach, i właśnie dlatego żaden raport nigdy tego nie pokazał.
Pod spodem poruszają się stopy procentowe. W ostatnich latach dwukrotnie zmieniły właściwą odpowiedź, a kalendarze płatności nie ruszyły się razem z nimi. Firma, która zostawia to bez zmian, albo przepłaca za pieniądz, albo zostawia skonto nieodebrane, zależnie od roku. Tymczasem dane podstawowe rozjeżdżają się dalej, a zakupy dalej negocjują skonto, którego finanse nie biorą, co jest słabą pozycją przed kolejnym odnowieniem.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Dystrybutor elektroniki użytkowej działający w Niemczech, Austrii i Szwajcarii; około 180 000 000 € rocznie przez zobowiązania handlowe do mniej więcej 900 dostawców w SAP S/4HANA, tygodniowy przebieg płatności, dwuosobowe treasury.
Około 1 300 otwartych pozycji dostawców miesięcznie trafia do przebiegu. Około 12% wydatków, 21 600 000 € rocznie, przypada na dostawców oferujących skonto, najczęściej 2% za płatność w dziesięć dni przy terminie trzydziestu dni.
Zobowiązania wybierają pozycje wymagalne, ręcznie dopisują eskalacje, a skarbnik rano w dniu przebiegu porównuje sumę z saldem bankowym. Skonto jest łapane tam, gdzie warunek w SAP jest poprawny, czyli w mniejszości przypadków.
Nikt nie zestawia terminu skonta z kalendarzem przebiegów ani warunków z faktury z danymi podstawowymi. Sześć minut przeglądu i przekładania na pozycję nie kupuje odpowiedzi na żadne z tych pytań.
Robot codziennie rano czyta pozycje otwarte, warunki, terminy, blokady i status akceptacji, a warunki z faktury porównuje z danymi podstawowymi. Następnie stosuje regułę uzgodnioną przez CFO i skarbnika i proponuje przebieg w Microsoft Teams z uzasadnieniem każdej pozycji. Treasury akceptuje lub koryguje; robot przygotowuje propozycję płatności w SAP.
Z 432 000 € skonta oferowanego rocznie brane jest dziś 151 200 €; reguła kwalifikuje około 90%, czyli 388 800 €, co daje wzrost o 237 600 €. Wcześniejsza o dwadzieścia dni zapłata 11 880 000 € wydatków kosztuje 29 300 € przy koszcie pieniądza 4,5%, a 16 800 € opłat za zwłokę znika. Wartość netto w modelu to około 225 000 € rocznie na podanych udziałach, czyli arytmetyka, a nie wynik u klienta.
Proponowane rozwiązanie
Budujemy silnik terminów płatności, który uruchamia się każdego ranka na danych SAP i na prognozie treasury w takiej formie, w jakiej dziś istnieje. Robot czyta otwarte pozycje dostawców wraz z warunkami, terminami skonta, blokadami i statusem akceptacji, a następnie porównuje warunki wydrukowane na fakturze z warunkami w danych podstawowych. Gdy się różnią, zakłada zadanie korekty danych podstawowych, zamiast po cichu pominąć skonto. Warunek staje się wtedy poprawny w SAP i pozostaje poprawny na każdej kolejnej fakturze tego dostawcy.
Sama decyzja jest zapisaną regułą, a nie modelem. Bierz skonto, gdy jego wartość w ujęciu rocznym przewyższa koszt pieniądza; w przeciwnym razie płać w terminie wymagalności, nigdy później i nigdy wcześniej bez powodu. Gdy gotówki brakuje, obowiązuje kolejność priorytetów ustalona przez skarbnika: pozycje ustawowe i powiązane z płacami, kary, skonto według wartości, dostawcy strategiczni, reszta. Każde odroczenie zostaje w przebiegu z powodem, co czyni je możliwym do obrony wobec dostawcy i wobec audytora.
Treasury widzi efekt tam, gdzie i tak pracuje. Proponowany przebieg przychodzi jako zadanie Action Center w Microsoft Teams z sumą, datami waluty, wziętym skontem, pozycjami odroczonymi i uzasadnieniem każdego wyjątku. Skarbnik akceptuje lub koryguje, robot przygotowuje propozycję płatności w SAP, a zwolnienie zostaje dokładnie tam, gdzie jest dziś. Power BI prowadzi bieżący obraz: skonto oferowane, wzięte i utracone, opłaty za zwłokę, rotacja zobowiązań i zapotrzebowanie na gotówkę na najbliższe tygodnie.
Warunki płatności, pozycje otwarte i propozycja płatności w SAP; harmonogramy UiPath Orchestrator, assety na parametry reguły, magazyn poświadczeń i ślad audytowy; zadania UiPath Action Center wykonywane wewnątrz Microsoft Teams; model semantyczny, subskrypcje i alerty danych w Power BI
Porównanie warunków i zakładane przez nie zadanie korekty danych podstawowych; zestaw reguł terminowych z kolejnością priorytetów i ograniczeniami gotówkowymi; złożenie propozycji z uzasadnieniem każdej pozycji; model Power BI dla skonta, opłat, rotacji zobowiązań i tygodniowego zapotrzebowania na gotówkę
Pozycje otwarte, warunki, blokady i przygotowanie propozycji płatności w SAP S/4HANA przez UiPath SAP activities (BAPI i OData); skoroszyt prognozy treasury przez konektor UiPath Integration Service dla Microsoft OneDrive & SharePoint
Jak działa proces zautomatyzowany
- AutomatyzacjaKażdego ranka robot czyta z SAP otwarte pozycje dostawców wraz z warunkami, terminami, blokadami i statusem akceptacji
- AutomatyzacjaWarunki z faktury są porównywane z danymi podstawowymi; różnica zakłada zadanie korekty, zamiast zniknąć
- SystemReguła decyduje o każdej pozycji: płać do daty skonta, gdy skonto w ujęciu rocznym przewyższa koszt pieniądza, w przeciwnym razie w terminie wymagalności i nigdy po nim
- AutomatyzacjaPrzy ograniczeniu gotówki obowiązuje kolejność priorytetów skarbnika, a każde odroczenie jest wypisane wraz z powodem
- CzłowiekPropozycja trafia do treasury jako zadanie Action Center w Microsoft Teams: suma, daty, wzięte skonto, pozycje odroczone, uzasadnienie wyjątków
- AutomatyzacjaPo akceptacji robot przygotowuje propozycję płatności w SAP; samo zwolnienie zostaje w treasury pod dotychczasową kontrolą dwuosobową
- AutomatyzacjaPower BI aktualizuje skonto oferowane, wzięte i utracone, opłaty za zwłokę, rotację zobowiązań i przyszłe zapotrzebowanie na gotówkę
Model pracy z człowiekiem w pętli
Automatyzacja obsługuje
- Codzienne odczytywanie pozycji otwartych, warunków, terminów, blokad i statusu akceptacji
- Porównywanie warunków z faktury z danymi podstawowymi i zakładanie wynikających z tego korekt
- Stosowanie reguły skonto kontra koszt pieniądza oraz kolejności priorytetów do każdej pozycji
- Złożenie propozycji z uzasadnieniem i przygotowanie propozycji SAP po akceptacji
Ludzie decydują
- O samej regule: stawce kosztu pieniądza, progu skonta i kolejności priorytetów
- O akceptacji każdego przebiegu i o tym, które pozycje odroczyć przy braku gotówki
- O rozmowach z dostawcami na temat warunków, eskalacji i spornych opłat
- Czy korekta danych podstawowych zgłoszona przez robota jest słuszna, zanim zmieni się rekord dostawcy
Przed i po
Systemy i integracje
Tam, gdzie wystarczy reguła, nie używamy modelu. Tam, gdzie potrzebny jest osąd, decyduje człowiek.
Wejścia
- otwarte pozycje dostawców i warunki płatności w SAP
- dane podstawowe dostawców
- skoroszyt prognozy treasury na SharePoint
- noty odsetkowe i opłat od dostawców
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Systemy docelowe
- propozycja płatności w SAP S/4HANA
- korekty danych podstawowych dostawców w SAP
- model semantyczny Power BI
Punkty styku z ludźmi: propozycja przebiegu jako zadanie Action Center w Microsoft Teams; korekty danych podstawowych; kwartalny przegląd reguły
Wykorzystane technologie
codzienne odczyty i wykonanie reguły; harmonogramy, assety z parametrami reguły, magazyn poświadczeń, ślad audytowy
Apozycje otwarte, warunki płatności, blokady i przygotowanie propozycji płatności
Apropozycja przebiegu jako zadanie, które skarbnik wykonuje wewnątrz Microsoft Teams, z zapisem decyzji
Amiejsce, gdzie treasury akceptuje, koryguje, pyta o odroczenie i czyta zapotrzebowanie na gotówkę
Aczyta skoroszyt prognozy treasury tam, gdzie dziś się znajduje
Askonto oferowane, wzięte i utracone, opłaty za zwłokę, rotacja zobowiązań, przyszłe zapotrzebowanie na gotówkę
Anasz projekt, uzgodniony z CFO i skarbnikiem, wersjonowany jako assety Orchestratora
CIlustracyjny model ekonomiczny
Zacznijcie od kwestionowania założeń.
Kalkulator na pozycję potrafi wycenić pracę biurową i nic więcej, więc to właśnie ona jest tu wyceniona. Chodzi o 1 300 pozycji otwartych miesięcznie przeglądanych, kwestionowanych i przekładanych ręcznie przed czterema tygodniowymi przebiegami, po sześć minut na pozycję. Czas jest uśredniony między zobowiązaniami a treasury, przy 48 € pełnego kosztu godziny na tym rynku. Pula skonta jest większą liczbą i jest wymodelowana z udziałów podanych w sekcji 05: 432 000 € oferowane rocznie, 151 200 € brane dziś, 237 600 € do odzyskania przy 29 300 € kosztu pieniądza. Niczego poniżej nie zmierzono u klienta.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Okna skonta są dotrzymywane, bo datę płatności wyznacza termin skonta, a nie kalendarz
- Odsetki i opłaty za zwłokę znikają, bo nic nie jest płacone po terminie bez świadomego odroczenia
- Treasury każdego ranka widzi zapotrzebowanie na gotówkę na najbliższe tygodnie, więc bufor wymierza się pod plan
- Warunki płatności w danych podstawowych stają się poprawne w miarę ujawniania różnic, co naprawia każdą kolejną fakturę tego dostawcy
- Kończy się darmowy kredyt dla dostawców: wcześniejsza zapłata następuje tam, gdzie coś przynosi, i nigdzie indziej
- Kierownik zobowiązań przestaje bronić listy, a zaczyna pracować na wyjątkach, które ujawnia reguła
Perspektywa zarządcza
- Liczba, której nie było, staje się comiesięcznym raportem: skonto oferowane, wzięte i utracone, w podziale na dostawców i jednostki
- Rotacja zobowiązań staje się zarządzanym efektem zapisanej reguły, a nie przypadkiem harmonogramu przebiegów
- Zmiana polityki, gdy zmieniają się stopy, jest zmianą parametru z akceptacją za nią, a nie projektem
- Każde odroczenie zostawia powód, który można pokazać dostawcy, audytorowi albo zarządowi
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Gdzie leżą dane i kto je widzi.
- Robot proponuje i przygotowuje. Nigdy nie zwalnia: zwolnienie zostaje w treasury pod kontrolą dwuosobową, która już działa w SAP i w banku
- Każda propozycja, akceptacja, korekta i odroczenie trafiają do rekordu Action Center z użytkownikiem, znacznikiem czasu i powodem, czyli z tym, o co pyta audytor, gdy dostawca dostał zapłatę po terminie
- Parametry reguły, w tym stawka kosztu pieniądza i kolejność priorytetów, są trzymane jako assety Orchestratora z historią zmian; zmiana jednego wymaga akceptacji skarbnika, a nie popołudnia programisty
- Konto serwisowe SAP jest ograniczone do odczytów zobowiązań i przygotowania propozycji, a jego sekret trzymany w zewnętrznym magazynie poświadczeń, na przykład Azure Key Vault; żadne poświadczenia osób nie są udostępniane robotowi
- Dane bankowe pozostają poza tym procesem, który odwołuje się do dostawców i pozycji otwartych, nigdy do numerów rachunków; przetwarzanie działa w regionie EU UiPath Automation Cloud i wewnątrz Państwa tenanta Microsoft 365
Dlaczego teraz
Stopy procentowe ruszyły w ostatnich latach na tyle, że dwukrotnie zmieniły właściwą odpowiedź, a większość kalendarzy płatności ustawiono, gdy była inna
Wszystko, czego potrzebuje reguła, siedzi już w SAP i w prognozie treasury. Brakuje czegoś, co czyta to każdego ranka, a nie raz w tygodniu, podczas gdy modelowe 280 800 € okien skonta zamyka się w równym tempie
Akceptacja treasury nie potrzebuje już spotkania ani skrzynki: zadanie wykonane w Microsoft Teams niesie sumę, odroczenia i uzasadnienie
Istotne role kierownicze
Utracone skonto przestaje być niewidoczne i staje się raportowaną liczbą, z kosztem pieniądza podanym obok
Zapotrzebowanie na gotówkę jest znane z kilkudniowym wyprzedzeniem, a każdy przebieg przychodzi już ukształtowany uzgodnioną regułą, więc akceptacja jest przeglądem, a nie śledztwem
Lista płatności przestaje być sporem, a dane podstawowe dostawców stają się poprawne przy okazji
Częste pytania i zastrzeżenia
Reguła bierze skonto tylko wtedy, gdy przewyższa Państwa własny koszt pieniądza, a ograniczenia gotówkowe działają w ustalonej przez Państwa kolejności priorytetów. Odroczenia stają się decyzjami z powodem, a nie domyślnym wynikiem zajętego czwartku.
Liczy, gdy warunek jest utrzymany w danych podstawowych. Odkrycie zwykle pokazuje, że wielu nie ma, a tygodniowy harmonogram przebiegów i tak ignoruje terminy skonta.
I nie decyduje. Proponuje z dołączonym uzasadnieniem, treasury akceptuje każdy przebieg tak jak dziś, a zwolnienie zostaje pod tą samą kontrolą dwuosobową.
Kiedy to nie jest właściwe rozwiązanie
- Niewielu Państwa dostawców oferuje skonto, a opłaty za zwłokę są rzadkie, więc reguła nie ma na czym działać; odkrycie powie to, zanim ktokolwiek cokolwiek zbuduje
- System zarządzania płynnością już optymalizuje terminy płatności względem prognozy i jest używany przy każdym przebiegu
- Gotówki jest tak mało, że każda płatność jest odraczana niezależnie od skonta; najpierw trzeba rozwiązać problem płynności
Pytanie na najbliższe posiedzenie
Zakupy wynegocjowały w tym roku warunki skonta warte sześciocyfrową kwotę: czy ktokolwiek potrafi powiedzieć, ile z tego finanse rzeczywiście wzięły, i przedstawić dowody do piątku?
Podejście wdrożeniowe
Zaczynamy od jednego wycinka procesu i rozszerzamy dopiero po dowodzie.
Dostarczamy
- Porównanie z odkrycia: dwanaście miesięcy warunków z faktur wobec danych podstawowych, czyli skonto oferowane, wzięte i utracone oraz zapłacone opłaty za zwłokę
- Zestaw reguł terminowych i kolejność priorytetów, spisane i uzgodnione z CFO i skarbnikiem
- Codzienne odczyty pozycji otwartych, warunków, blokad i statusu akceptacji oraz zadanie korekty tam, gdzie faktura i dane podstawowe się rozchodzą
- Złożenie propozycji z uzasadnieniem każdej pozycji, dostarczane jako zadanie Action Center w Microsoft Teams
- Przygotowanie propozycji płatności w SAP, przetestowane na przeszłych przebiegach, zanim dotknie żywego
- Model Power BI dla skonta, opłat, rotacji zobowiązań i tygodniowego zapotrzebowania na gotówkę
- Praca w trybie cienia, a następnie przekazanie z runbookiem i stałym przeglądem reguły
Potrzebujemy od Państwa
- Dwunastu miesięcy zapłaconych pozycji z warunkami płatności, warunkami skonta i faktycznymi datami zapłaty
- Skarbnika, który jest właścicielem reguły, oraz wskazanego właściciela procesu po stronie zobowiązań do korekt danych podstawowych
- Konta serwisowego SAP do odczytów zobowiązań i przygotowania propozycji, w testach i na produkcji
- Prognozy treasury w takiej formie, w jakiej dziś istnieje, włącznie ze skoroszytem Excel
Etapy
Odkrycie
Porównanie warunków z faktur z danymi podstawowymi, ilościowe ujęcie skonta oferowanego, wziętego i utraconego, zliczenie opłat za zwłokę
Projekt reguły
Stawka kosztu pieniądza, próg skonta, kolejność priorytetów przy ograniczeniu gotówki, dopuszczalne powody odroczenia
Budowa
Codzienne odczyty i porównania, złożenie propozycji, przygotowanie w SAP, zadanie w Teams, dashboard
Tryb cienia
Silnik proponuje, treasury porównuje z tym, co zrobiłoby samo, reguła jest korygowana
Uruchomienie
Propozycja staje się listą roboczą, akceptowaną w Teams, pod nadzorem przez pierwsze przebiegi
Przegląd stawek
Stały przegląd stawki kosztu pieniądza, kolejności priorytetów i dostawców, u których warunki się rozjeżdżają
Szybki efekt. O nakładzie decyduje liczba jednostek i walut objętych przebiegiem, wiarygodność warunków płatności w danych podstawowych oraz to, czy prognoza treasury istnieje w formie czytelnej dla robota.
Skonto, które wygasło w środę, jest warte więcej niż tydzień, po którym je zauważono.
Prosimy o dwanaście miesięcy zapłaconych pozycji z warunkami płatności i datami zapłaty. Odsyłamy skonto oferowane, wzięte i utracone oraz opłaty za zwłokę jako punkt odniesienia, z którym można polemizować.
Poproś o bazową analizę skontaTen sam problem ma zwykle sąsiedni proces
Koniec z ręcznym składaniem dziennej gotówki z czterech portali bankowych; przychodzi za późno i nikt jej nie ufa.
Zobacz rozwiązanie Inne rozwiązaniaFaktury odczytane, zadekretowane i skierowane automatycznieKtoś wciąż przepisuje PDF do ERP, zgaduje centrum kosztów i goni akceptującego.
Zobacz rozwiązanie Inne rozwiązaniaRozbieżności ceny i ilości rozwiązane tego samego dniaOdblokowanie pod presją przelewów staje się ceną kolejnego kwartału, choć nikt jej nie negocjował.
Zobacz rozwiązanie Inne rozwiązaniaWyciągi dostawców uzgadniane w dniu otrzymaniaDostawcy co miesiąc piszą, ile ich zdaniem im się należy. Większości tych pism nikt nie czyta.
Zobacz rozwiązanie Case studySpór fakturowy bez eskalacjiSporna faktura to nie jedna czynność, tylko śledztwo: zamówienie, dostawa, umowa, korespondencja.
Zobacz case study Case studyAutomatyczna obsługa zapytań P2PKopie faktur, statusy i zestawienia dostarczane natychmiast, przez całą dobę.
Zobacz case studyBranże, w których wdrażamy to najczęściejProdukcja i przemysłHandel i e‑commerceUsługi i ITCentra usług wspólnych