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.