Jeżeli Twoi użytkownicy żądają faktur elektronicznych, Twój produkt musi spełniać cztery wymagania: tworzyć faktury zgodne z europejską normą EN 16931, dostarczać je za pośrednictwem sieci, z której korzystają kupujący (w Europie głównie Peppol), weryfikować dokumenty przed wysłaniem i, w razie potrzeby, akceptować faktury. Pytanie nie brzmi „czy”, ale „jak”: w Estonii obowiązuje norma EN 16931 od 1 lipca 2025 r. podstawowy format faktury elektronicznej a zarejestrowani kupujący mogą żądać e-faktur – Twoi użytkownicy już dziś odczuwają presję. Istnieją dwie opcje: zbudować własny certyfikowany punkt dostępu lub korzystać z istniejącego za pośrednictwem własnego API.
Co tak naprawdę oznacza „zbuduj to sam”?
Uzyskanie certyfikowanego punktu dostępu to projekt zgodności, a nie zadanie programistyczne: członkostwo w OpenPeppol, certyfikacja, uruchomienie infrastruktury komunikacyjnej AS4, usługi SMP do zarządzania uczestnikami oraz śledzenie aktualizacji regulaminu w całym cyklu wydawniczym sieci. To właściwa ścieżka, jeśli infrastruktura e-fakturowania JEST Twoim produktem. Jeśli e-fakturowanie jest jedną z wielu funkcji Twojego produktu, zapłacisz za tę ścieżkę w kwartałach czasu rozwoju przed pierwszym osiągnięciem wartości dla klienta.
Co oznacza „gotowy do użycia API”?
Projekt integracji: Twoja aplikacja wysyła dane rozliczeniowe do certyfikowanego API dostawcy, otrzymuje synchroniczną walidację ze zrozumiałymi błędami, statusy dostarczenia za pomocą webhooków i zarządzanie uczestnikami w ramach operacji API. Za akredytację, transport i aktualizacje reguł odpowiada dostawca. Harmonogram wygląda zupełnie inaczej: dzięki udokumentowanemu API, pierwszy dokument testowy w ciągu jednego dnia roboczego Realistyczny, zazwyczaj trafia do produkcji w ciągu kilku tygodni. Szczegóły techniczne (formaty, warstwy walidacji, statusy) opisaliśmy w przewodnikach dla programistów. wysyłanie e-faktur przez API I O tworzeniu faktury UBL.
Jak podjąć decyzję? Trzy pytania
Po pierwsze: czy e-fakturowanie jest rdzeniem, czy wsparciem Twojego produktu? Rdzeń uzasadnia swoją infrastrukturę, wsparcie nie. Po drugie: ile rynków musisz objąć? Każdy kraj wprowadza nowe zasady – e-fakturowanie B2B zmienia się na Łotwie obowiązkowe w 2028 r., Państwo litewskie otrzymuje faktury za pośrednictwem Peppola, a dostawca API zajmuje się tą dokumentacją za Ciebie. Po trzecie: kto odpowiada w nocy? Punkt dostępu to infrastruktura, której awaria zatrzyma przepływ pieniędzy do Twoich użytkowników; zastanów się szczerze, czy chcesz, żeby działał.
Lista kontrolna wyboru dostawcy
Certyfikowany status punktu dostępu. Synchroniczna walidacja z błędami strukturalnymi. Sandboxing z oddzielnymi kluczami. Webhooki podpisane i idempotentne. Rejestracja i migracja uczestników za pośrednictwem API, a nie biletów. Oraz dokumentacja, po którą Twój programista nie musi dzwonić do pomocy technicznej: ta ostatnia najdokładniej przewiduje jakość współpracy.
Często zadawane pytania
Czy SaaS musi tworzyć własny punkt dostępu do e-faktur?
Nie. Konsumpcja API przez certyfikowany punkt dostępu obejmuje formatowanie, walidację, dostawę i akceptację — akredytacja i transport pozostają w gestii dostawcy. Płacisz za własną infrastrukturę tylko wtedy, gdy e-fakturowanie jest podstawą produktu.
Ile czasu zajmuje dodanie e-faktur do SaaS?
Oparte na API: pierwszy dokument testowy w ciągu jednego dnia roboczego jest realistyczny dla udokumentowanego rozwiązania, produkcja w ciągu kilku tygodni. Budowa własnego punktu dostępu to projekt zgodności na kwartały.
Jakie są techniczne wymagania zgodności?
Dokumenty zgodne z normą EN 16931, dostawa do sieci nabywcy (za pośrednictwem certyfikowanego punktu dostępu Peppol), walidacja przed wysyłką i rejestracja SMP w celu odbioru.
Na co zwrócić uwagę przy wyborze dostawcy API?
Certyfikowany status AP, walidacja synchroniczna, sandboxing, podpisane webhooki, zarządzanie uczestnikami za pośrednictwem interfejsu API i jakość dokumentacji.