Automatyczna faktura sprzedażowa w KSeF: 3 triggery (i jak spiąć to z CRM lub sklepem bez przepisywania)

Automatyzacja faktur sprzedażowych to nie to samo, co OCR kosztówek

Kiedy ktoś pisze do nas "chcemy zautomatyzować faktury", w dziewięciu na dziesięć przypadków ma na myśli faktury kosztowe: skan albo PDF od dostawcy trafia do systemu, OCR wyciąga kwoty, ktoś to zatwierdza. To dobrze opisany, popularny temat i mnóstwo narzędzi radzi sobie z nim nieźle. Problem w tym, że większość dostępnych w sieci poradników "automatyzacji faktur" właśnie o tym mówi, a to zupełnie inny proces niż automatyzacja faktur wychodzących, które firma sama wystawia klientowi.

Przy fakturze sprzedażowej nie odczytujemy niczego z dokumentu, bo dokumentu jeszcze nie ma. My go tworzymy, w odpowiedzi na konkretne zdarzenie w firmie: klient zaakceptował ofertę, zamówienie zostało opłacone, usługa się zakończyła. To oznacza, że architektura musi zaczynać się od triggera biznesowego, a nie od pliku wejściowego. I tu pojawia się różnica, która w praktyce decyduje o sukcesie wdrożenia: trzeba precyzyjnie zdefiniować, co dokładnie uruchamia wystawienie faktury i jakie dane w tym momencie są już kompletne, a jakich brakuje.

Skąd bierze się trigger do wystawienia faktury

W praktyce widzieliśmy trzy powtarzalne scenariusze, które pokrywają większość przypadków w małych i średnich firmach.

Potwierdzenie zamówienia w CRM lub sklepie

Sklep internetowy na Baselinkerze albo Allegro dostaje zamówienie, klient płaci, status zmienia się na "opłacone". To najbardziej oczywisty trigger, bo dane produktowe, ilości, ceny i dane nabywcy są już w systemie. Problem pojawia się przy rabatach ustalanych ręcznie przez handlowca, przy zamówieniach łączonych z kilku platform albo przy zwrotach częściowych, które trzeba obsłużyć korektą, a nie nową fakturą. Jeśli te wyjątki nie zostaną zaadresowane na starcie, automat wystawi fakturę niepoprawną i ktoś będzie ją ręcznie korygował, czyli dokładnie to, czego automatyzacja miała uniknąć.

Akceptacja oferty w systemie ofertowania lub CRM

W firmach usługowych i B2B trigger często wygląda inaczej: klient klika "akceptuję" pod ofertą w Pipedrive albo HubSpot, albo podpisuje dokument elektronicznie. Tu wyzwaniem nie jest brak danych, tylko ich rozproszenie: cena bywa negocjowana w mailu, zakres usługi opisany w załączniku, a warunki płatności ustalone telefonicznie i wpisane do notatki w CRM. Zanim zbudujemy automatyczne wystawianie faktur, trzeba najpierw ustandaryzować, gdzie te dane mają obowiązkowo trafiać, bo automat nie zgadnie tego, czego nikt nie zapisał w polu, które umie odczytać.

Zakończenie usługi lub etapu realizacji

Trzeci wariant to fakturowanie cykliczne albo etapowe: abonamenty, raty projektu, rozliczenie godzinowe po zamknięciu miesiąca. Tu trigger jest czasowy albo zależny od statusu zadania w systemie projektowym. To zwykle najprostszy przypadek do zautomatyzowania, bo dane są stabilne i powtarzalne, ale wymaga dobrego pilnowania kalendarza wystawiania i numeracji, żeby nie wystawić dwóch faktur za ten sam okres przy błędzie w harmonogramie.

Wymogi KSeF przy fakturach wystawianych automatycznie

Faktura wychodząca z automatu musi spełniać te same wymogi formalne co faktura wystawiona ręcznie, tyle że system musi je wymusić bez udziału człowieka, który normalnie "wyłapałby" błąd okiem. W praktyce oznacza to trzy rzeczy, na które zwracamy szczególną uwagę przy wdrożeniach.

Po pierwsze, struktura dokumentu musi być zgodna z aktualnym schematem FA(2), obowiązującym w Krajowym Systemie e-Faktur. To nie jest dowolny XML, tylko ściśle zdefiniowany format z konkretnymi polami obowiązkowymi, więc mapowanie danych z CRM czy sklepu na tę strukturę trzeba wykonać raz, dokładnie, i przetestować na rzeczywistych przypadkach brzegowych, nie tylko na "modelowym" zamówieniu z jednym produktem i pełnymi danymi klienta.

Po drugie, numeracja faktur musi być spójna i ciągła, zgodnie z przyjętym schematem numeracji w firmie, nawet jeśli faktury generują się z kilku źródeł jednocześnie: sklepu, CRM i panelu ofertowego. To miejsce, w którym integracje najczęściej się psują, bo dwa systemy próbują nadać ten sam numer albo numeracja się rozjeżdża po zmianie roku czy miesiąca. Rozwiązaniem, które sprawdza się w praktyce, jest scentralizowanie logiki numeracji w jednym miejscu, zwykle w systemie księgowym docelowym (Fakturownia, wFirma, Optima), a nie w każdym systemie źródłowym z osobna.

Po trzecie, po wysłaniu faktury do KSeF system musi odebrać i zapisać UPO (Urzędowe Poświadczenie Odbioru). Bez tego kroku nie mamy dowodu, że faktura faktycznie trafiła do systemu, a to potwierdzenie bywa potrzebne przy kontroli albo przy reklamacji klienta, który twierdzi, że dokumentu nie otrzymał. Automatyzacja bez obsługi UPO to automatyzacja tylko połowy procesu.

Jak to spina się technicznie: architektura integracji

W większości wdrożeń, które robiliśmy, układ wygląda podobnie: system źródłowy (CRM, sklep, panel ofertowy) jest miejscem, gdzie powstaje trigger i podstawowe dane transakcji. System księgowy (Fakturownia, wFirma, czasem Optima) jest miejscem, gdzie faktura faktycznie powstaje, dostaje numer i trafia do KSeF. Między nimi musi być warstwa integracyjna, która pilnuje mapowania pól, kolejności zdarzeń i obsługi błędów.

Nie polecamy podejścia, w którym każdy system źródłowy wysyła dane bezpośrednio do KSeF z osobną logiką numeracji i osobną obsługą błędów. To wygląda na prostsze na starcie, ale przy drugim źródle danych (na przykład sklep plus CRM równolegle) kończy się konfliktami numeracji i podwójnym fakturowaniem tego samego zdarzenia. Lepiej sprawdza się model z jednym "centrum fakturowania", do którego wpadają zdarzenia z różnych źródeł, a stamtąd, po walidacji, faktura leci dalej do KSeF.

Warto też rozdzielić dwa etapy: przygotowanie danych do faktury (produkt, cena, NIP, adres, warunki płatności) od samego aktu wysyłki do KSeF. Pierwszy etap to zwykle miejsce, gdzie trzeba dopisać reguły biznesowe: jak liczyć rabaty, jak obsłużyć fakturę zaliczkową, co zrobić z zamówieniem bez NIP-u. Drugi etap, techniczny, jest w miarę stabilny raz zbudowany i rzadko wymaga zmian. Więcej o samej logice przetwarzania dokumentów i integracji z systemami księgowymi piszemy przy okazji tematu automatyzacji faktur, choć tam skupiamy się głównie na stronie kosztowej, a nie sprzedażowej.

Gdzie automat kończy się, a zaczyna człowiek

Dobrze zaprojektowana automatyzacja fakturowania sprzedażowego potrafi wystawić i wysłać do KSeF większość faktur bez żadnego udziału człowieka, w naszych wdrożeniach to zwykle zdecydowana większość standardowych transakcji. Ale są sytuacje, w których świadomie zostawiamy decyzję po stronie człowieka, bo automatyzowanie ich na siłę tworzy więcej problemów niż rozwiązuje.

Przykład: zamówienie z niekompletnymi danymi nabywcy, na przykład brak NIP-u przy fakturze na firmę. Automat nie powinien zgadywać ani wysyłać faktury z pustym polem, tylko wstrzymać dokument i wygenerować powiadomienie do osoby odpowiedzialnej za uzupełnienie danych. Podobnie przy dużych rabatach nietypowych dla danego klienta albo przy fakturach korygujących, które w praktyce prawie zawsze wymagają decyzji człowieka, bo wiążą się z ustaleniami, których nie ma w żadnym systemie źródłowym.

Sensowna zasada, którą stosujemy przy projektowaniu takich systemów: automat obsługuje przypadek standardowy, a każdy przypadek, który nie mieści się w zdefiniowanych regułach, trafia do kolejki wyjątków z jasnym opisem, co konkretnie budzi wątpliwość. To znacznie lepsze niż próba przewidzenia wszystkich możliwych scenariuszy z góry, bo takich prób i tak nigdy nie da się dokończyć, a każda kolejna reguła zwiększa ryzyko błędu w regule poprzedniej.

Od czego zacząć, jeśli dziś faktury wystawia człowiek

Zanim ktokolwiek zacznie pisać integrację, warto spisać, ile razy w tygodniu i w jakich sytuacjach faktura powstaje ręcznie, oraz ile z tych sytuacji da się opisać jako jasną regułę: "jeśli zamówienie ma status X i kwota jest Y, wystaw fakturę o parametrach Z". Firmy, z którymi pracujemy, zwykle odkrywają, że 60-70% ich faktur sprzedażowych to właśnie takie proste, powtarzalne przypadki, a reszta to wyjątki wymagające ludzkiej decyzji. To bardzo dobry punkt startowy: zautomatyzować najpierw tę powtarzalną większość, zostawiając wyjątki człowiekowi, zamiast czekać, aż uda się zaprojektować system obsługujący 100% przypadków od razu.

Jeśli firma prowadzi księgowość we własnym zakresie albo współpracuje z biurem rachunkowym, dobrze jest ustalić z góry, kto odpowiada za nadzór nad numeracją i kto reaguje na błędy zwracane przez KSeF, zanim system pójdzie w produkcję. Temat integracji procesów sprzedażowych z pracą księgowości szerzej opisujemy przy okazji automatyzacji biura rachunkowego, bo w wielu firmach to właśnie biuro rachunkowe jest ostatecznym odbiorcą i kontrolerem tego procesu.

Typowe błędy przy wdrożeniu

Najczęstszy błąd, jaki widzimy, to budowanie integracji od strony technicznej, zanim ktokolwiek usiądzie i spisze reguły biznesowe. Druga firma buduje ładne API między CRM a systemem księgowym, a potem odkrywa, że handlowcy w połowie przypadków wpisują ceny "z głowy" w polu notatki, którego integracja w ogóle nie czyta. Trzeci częsty problem to brak planu na dzień, w którym KSeF odrzuci fakturę, na przykład z powodu błędnego NIP-u kontrahenta: bez zaprojektowanej ścieżki obsługi błędu faktura po prostu "znika" w logu, a klient nigdy jej nie dostaje, dopóki ktoś przypadkiem nie zauważy braku płatności.