Przejdź do treści

Automatyzacja obiegu faktur: mniej przepisywania, pełna kontrola decyzji

Jak zaprojektować obieg faktury od wpływu do zatwierdzenia: odczyt, duplikaty, role, wyjątki i testy. Praktyczna checklista bez obietnic samodzielnych płatności.

Automatyzacja obiegu faktur powinna przenosić dane i pilnować statusów, a nie zastępować uprawnienia do decyzji. Odczyt dokumentu, kontrola, akceptacja i wykonanie płatności to osobne etapy. Brak danych lub wątpliwość zatrzymują sprawę i trafiają do wskazanej osoby.

Przepływ dokumentu przez kontrolę danych, decyzję człowieka i wynik procesu
Schemat procesu, nie potwierdzenie aktywnej integracji. Zakres dostępu i działań ustala właściciel procesu.
Dokument nie jest jeszcze zgodą na płatność
  1. 01Wpływ dokumentu
  2. 02Odczyt i walidacja
  3. 03Kontrola duplikatu
  4. 04Akceptacja osoby
  5. 05Przekazanie i historia

Potwierdzenie odczytu nie oznacza zatwierdzenia kosztu, zaksięgowania dokumentu ani wykonania przelewu.

Najpierw ustal, co ma się wydarzyć po wpływie faktury

Faktura może przyjść do skrzynki, folderu lub przez połączony system. Zanim wybierzesz narzędzie, zapisz początek i koniec procesu: dokument otrzymany, dane sprawdzone, decyzja zatwierdzona, dokument przekazany. Samo zapisanie załącznika nie kończy obsługi.

Microsoft opisuje przepływy zatwierdzania dokumentów, w tym faktur, z decyzją osoby akceptującej i aktualizacją statusu. To przykład mechanizmu, nie dowód, że Twoje środowisko ma już połączenia i uprawnienia. Własny proces potrzebuje odpowiedzialności za każdy etap i ustalonego wyniku odbioru.

Źródła: Microsoft: tworzenie i testowanie przepływu akceptacji

Odczytuj pola, ale nie traktuj ich jak pewnika

Sprawdź kontrahenta, numer dokumentu, daty, kwoty, walutę i zgodność sum. Zachowaj oryginał i możliwość pokazania, skąd odczytano pole. Nieczytelny skan albo niezgodne kwoty powinny mieć status wymagający sprawdzenia, a nie zostać cicho poprawione przez model.

Przykład syntetyczny: dokument wskazuje 1 000 zł netto, 230 zł VAT i 1 220 zł brutto. Suma netto i VAT wynosi 1 230 zł, więc występuje różnica 10 zł. Nie rozstrzygamy tutaj poprawności podatku ani przyczyny różnicy. Kontrola arytmetyczna ma zatrzymać sprawę i wskazać problem człowiekowi.

Ta sama faktura może pojawić się drugi raz

Plik o innej nazwie może zawierać ten sam dokument, a skan tej samej faktury może mieć inną sumę pliku. Sama nazwa lub hash załącznika nie wystarczą do kontroli biznesowej. Projektowo warto zestawić identyfikator wystawcy, numer dokumentu i inne uzgodnione pola, a niejednoznaczny przypadek skierować do sprawdzenia.

Korekta nie jest po prostu duplikatem pierwotnej faktury. Zachowaj relację dokumentów i osobną historię. Ponowienie przetwarzania tej samej sprawy po awarii powinno wrócić do istniejącego identyfikatora operacji, zamiast tworzyć drugą decyzję lub dyspozycję. To wymaganie odbiorowe procesu, nie automatyczna właściwość każdego narzędzia.

Kto sprawdza, kto zatwierdza, a kto wykonuje?

Rozdziel sprawdzenie danych od decyzji o koszcie i od wykonania płatności. W małej firmie niektóre role może pełnić ta sama osoba, lecz statusy i dowody nadal powinny być osobne. Kwota, rodzaj zakupu lub jednostka organizacyjna mogą kierować sprawę do różnych uprawnionych osób.

Zatwierdzenie powinno odnosić się do konkretnej wersji danych. Zmiana rachunku, kwoty lub kontrahenta po decyzji wymaga ponownego sprawdzenia zgodnie z regułami firmy. Dokument może zawierać opis i polecenia; jego treść nie nadaje aplikacji uprawnień ani nie upoważnia do wysyłki czy płatności.

Kto sprawdza, kto zatwierdza, a kto wykonuje?
EtapWynikCo pozostaje osobną decyzją
OdczytPola i oryginał dokumentuCzy dane są poprawne
KontrolaSprawdzone sumy i wyjątkiCzy koszt jest zasadny
AkceptacjaOsoba, wersja, czas i decyzjaCzy wykonać płatność
PrzekazaniePotwierdzony odbiór w systemieKsięgowanie i przelew

Awaria nie może wyglądać jak sukces

Dokumentacja Power Automate opisuje osobne ścieżki dla błędu, przekroczenia czasu i ponowienia. W projekcie firmy przełóż to na czytelny status: oczekuje, trwa, wymaga sprawdzenia, zakończono lub nie udało się. Odbiorca powinien widzieć, który etap rzeczywiście się zakończył.

Przy timeout po wysłaniu nie zakładaj, że system docelowy niczego nie otrzymał. Sprawdź potwierdzenie po identyfikatorze operacji przed ponowieniem skutku. Ustal właściciela kolejki błędów, termin reakcji i możliwość ręcznej obsługi. Zapisuj identyfikatory i przyczyny, lecz nie kopiuj całych poufnych dokumentów do każdego logu.

Źródła: Microsoft: obsługa błędów i polityka ponowień

Sześć prób przed uruchomieniem na realnych dokumentach

Przeprowadź pilot na uzgodnionym zbiorze syntetycznym lub odpowiednio dopuszczonym do przetwarzania. Mierz czas całej obsługi, łącznie z kontrolą i poprawkami. Liczba odczytanych faktur nie mówi jeszcze, ile spraw zakończono poprawnie.

W iPro podział na dokumenty, jakość danych i kolejne specjalizacje pomaga oddzielić odpowiedzialność. Prezentacja DEMO nie uruchamia księgowania ani przelewów. Przed wdrożeniem Data Strategy ustala połączenia, zakres praw i kryteria odbioru; automatyzacja nie zastępuje obowiązujących zasad księgowych lub podatkowych.

  • Dokument poprawny dociera do właściwej osoby.
  • Niezgodna suma i brak pola zatrzymują sprawę.
  • Drugi wpływ dokumentu nie tworzy drugiej płatności.
  • Użytkownik bez praw nie widzi cudzego dokumentu.
  • Zmiana danych po akceptacji wraca do kontroli.
  • Awaria i ponowienie pozostawiają jeden sprawdzalny wynik.

Podobny problem w Twojej firmie?

Opisz obecny sposób pracy i oczekiwany wynik. Dane poufne oraz dokumenty omówimy osobno.

Porozmawiajmy o procesie