Start · Rozwiązania · Finanse i księgowość · Skonto brane wtedy, gdy przewyższa koszt pieniądza
Rozwiązanie · Finanse i księgowośćCodzienna 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 z niego korzystają Państwo.
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 Państwa 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, więc skonto nie przepada po cichu. 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. Skonto jest brane, gdy jego wartość w ujęciu rocznym przewyższa koszt pieniądza; w przeciwnym razie faktura jest płacona 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 po automatyzacji
- 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łatność 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 współpracy człowieka z automatyzacją
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
CJak to wdrażamy
Od opisu do działającego procesu
To rozwiązanie wdrażamy w ramach usługi automatyzacji procesów: najpierw mierzymy proces na danych firmy, potem budujemy, testujemy i utrzymujemy roboty. Integrację z SAP prowadzi nasz zespół SAP.
Ilustracyjny model ekonomiczny
Proszę zacząć 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.
Policzmy to na Państwa danych
Szacunek ilustracyjny na podstawie Państwa 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ądu
- 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
skonto oferowane, wzięte i utracone · zapłacone odsetki i opłaty za zwłokę · rotacja zobowiązań · trafność tygodniowego zapotrzebowania na gotówkę
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
Role zarządcze, których to dotyczy
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
Dzienną gotówkę składa się ręcznie z czterech portali bankowych; zestawienie przychodzi za późno i nikt mu nie ufa.
Zobacz rozwiązanie Finanse i księgowośćFaktury odczytane, zadekretowane i skierowane automatycznieKtoś wciąż przepisuje PDF do ERP, zgaduje centrum kosztów i goni akceptującego.
Zobacz rozwiązanie Finanse i księgowośćRozbieżności ceny i ilości rozwiązane tego samego dniaRozbieżność zaakceptowana pod presją przelewów staje się ceną kolejnego kwartału, choć nikt jej nie negocjował.
Zobacz rozwiązanie Finanse i księgowośćWycią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 ScenariuszSpór fakturowy bez eskalacjiSporna faktura oznacza śledztwo: zamówienie, dostawa, umowa, korespondencja.
Zobacz scenariusz RealizacjaAutomatyczna obsługa zapytań P2PKopie faktur, statusy i zestawienia dostarczane natychmiast, przez całą dobę.
Zobacz realizację