Automatyczne fakturowanie w n8n po opłaceniu zamówienia

To automatyzacja, którą budujemy najczęściej, i ta, która najbardziej zaskakuje klientów, bo pracy, którą zastępuje, nie widać, dopóki się jej nie policzy. Ktoś co rano otwiera panel sklepu, przegląda opłacone zamówienia i przepisuje je do systemu fakturowego. Przy dwóch minutach na zamówienie dwadzieścia zamówień to czterdzieści minut. Dzieje się to każdego dnia roboczego, to najnudniejsze zajęcie w całym zespole, a błędów jest tyle, ile można się spodziewać po czterdziestu minutach przepisywania liczb.

O tym, czy ten workflow pomaga, czy szkodzi, decydują dwie rzeczy i żadną z nich nie jest integracja z API. Pierwsza to sprawdzenie płatności: dokument wystawiony przy płatności autoryzowanej, ale jeszcze niepobranej, wymaga korekty, a korekty kosztują więcej, niż automatyzacja zaoszczędziła. Druga to idempotentność. Nadawcy webhooków ponawiają wysyłkę po przekroczeniu limitu czasu, a workflow, który wystawia fakturę przy każdym dostarczeniu zdarzenia, a nie raz na zamówienie, będzie po cichu dublował dokumenty, dopóki ktoś nie zauważy tego przy zamknięciu miesiąca. Każde z tych zabezpieczeń to jeden node. Nie ma w nich nic efektownego, ale bez nich workflow narobi bałaganu. O wyborze platformy pisaliśmy w Make vs n8n vs Zapier, a szersze wdrożenia opisuje strona automatyzacji procesów.

KSeF: faktury w Krajowym Systemie e-Faktur

Od 2026 roku faktury między firmami wystawia się w Polsce w KSeF, czyli Krajowym Systemie e-Faktur Ministerstwa Finansów. Faktura ma postać pliku XML według wzoru FA(3), a system nadaje jej numer KSeF. Terminy według oficjalnego serwisu KSeF:

• 1 lutego 2026: obowiązek wystawiania faktur w KSeF dla firm, których sprzedaż w 2024 roku przekroczyła 200 mln zł (z VAT), oraz obowiązek odbierania faktur w KSeF dla wszystkich;
• 1 kwietnia 2026: obowiązek wystawiania dla pozostałych firm;
• do 31 grudnia 2026: poza KSeF mogą jeszcze fakturować firmy, których sprzedaż udokumentowana fakturami nie przekracza 10 000 zł brutto miesięcznie; do tej daty można też wystawiać faktury z kas rejestrujących;
• 1 stycznia 2027: KSeF obejmuje także najmniejsze firmy i zaczynają obowiązywać kary za błędy w KSeF, odroczone do tej daty.

Faktury dla konsumentów można wystawiać w KSeF, ale nie trzeba. Sklep, który sprzedaje głównie osobom prywatnym, wysyła więc przez system przede wszystkim faktury do zamówień firmowych, z NIP-em nabywcy.

W tym workflow KSeF nie zmienia łańcucha nodów, tylko krok wystawienia. Node HTTP Request wysyła fakturę do API Fakturowni z parametrem gov_save_and_send, a Fakturownia, po autoryzacji KSeF w jej ustawieniach, przekazuje dokument do systemu. Faktura jest wystawiona w dniu przesłania do KSeF, ale numer KSeF (gov_id) nie wraca od razu: API odpowiada najpierw statusem processing, a numer pojawia się po przetworzeniu. Dlatego zapisujemy go w zamówieniu w drugim, krótkim workflow, który odbiera webhook Fakturowni wysyłany po nadaniu numeru. Statusy błędów, takie jak send_error czy duplicate_error, trafiają do tego samego Error Triggera co pozostałe awarie. Przed uruchomieniem produkcyjnym warto przetestować całość w trybie DEMO Fakturowni, który łączy się z przedprodukcyjnym środowiskiem KSeF.

Przy KSeF oba opisane wyżej zabezpieczenia ważą jeszcze więcej. Faktury przyjętej przez system nie da się już edytować ani usunąć, zostaje tylko korekta. KSeF nie sprawdza też danych kontrahenta: fakturę z błędnym NIP-em przyjmie, a naprawa oznacza korektę do zera i nową fakturę dla właściwego nabywcy. Gdy faktura nie trafi do KSeF od razu, na przykład przez brak połączenia, przepisy dopuszczają tryb offline24: dokument dosyła się do systemu najpóźniej następnego dnia roboczego po wystawieniu. Fakturownia oznacza takie faktury statusem offline, więc warto kierować je do tego samego powiadomienia co błędy, żeby ktoś dopilnował terminu.