Oprogramowanie do e-fakturowania dla europejskiej firmy musi dobrze robić siedem rzeczy: generować właściwy format ustrukturyzowany dla każdego kraju, walidować go przed wystawieniem faktury, przenosić go kanałem, którego używa dany kraj, odczytywać przychodzące faktury ustrukturyzowane, przechowywać oryginał ustrukturyzowany przez okres przechowywania, rozstrzygać o traktowaniu VAT na podstawie faktów transakcji i udostępniać to wszystko innym systemom przez API. Żaden pojedynczy produkt nie robi wszystkich siedmiu rzeczy w każdym kraju bez ograniczeń; użyteczne pytanie brzmi, jakie to ograniczenia i czy dostawca je nazywa.
Generowanie formatu: jedna faktura, cztery narodowe dialekty
Oprogramowanie musi wytwarzać dokładnie ten format, którego oczekuje każdy obowiązek — XRechnung lub ZUGFeRD dla Niemiec, Factur-X dla Francji, Peppol BIS Billing 3.0 dla Belgii, FA(3) dla Polski — z tych samych danych faktury, bez edytowania XML przez użytkownika.
Trzy z czterech to profile EN 16931, europejskiej normy semantycznej, której części 1 i 2 Komisja udostępnia nieodpłatnie za pośrednictwem krajowych organów normalizacyjnych; czwarty, polski FA(3), jest własnym schematem krajowym. „Obsługuje EN 16931” jest więc warunkiem koniecznym, ale niewystarczającym. Proszę pytać konkretnie:
- Które składnie dla Niemiec — XRechnung w UBL, w CII czy obie? ZUGFeRD w których profilach (FAQ BMF wyłącza MINIMUM i BASIC-WL z definicji e-faktury)?
- Czy francuski plik wyjściowy osadza XML CII w PDF/A-3 (Factur-X), tak aby ten sam plik służył ludziom i maszynom?
- Czy belgijski plik wyjściowy to UBL Peppol BIS Billing 3.0, który sieć waliduje, czy ogólny UBL, który odbierający punkt dostępowy może odrzucić?
- Która wersja FA dla Polski — FA(3) jest bieżącym schematem — i czy oprogramowanie potrafi także wyrenderować wizualizację z numerem KSeF i kodem QR, których Ministerstwo wymaga, gdy faktura jest używana poza systemem?
- Czy format jest wybierany automatycznie na podstawie kraju firmy wystawiającej, czy użytkownik musi go wybrać?
Przewodnik po formatach przypisuje każdy format do kraju i obowiązku.
Walidacja przed wystawieniem, nie po odrzuceniu
Faktura ustrukturyzowana, która nie spełnia krajowych reguł biznesowych, nie jest e-fakturą w rozumieniu danego obowiązku; oprogramowanie powinno stosować te reguły przed nadaniem numeru, a nie dowiadywać się o błędzie z odrzuconej transmisji.
Walidacja ma warstwy: schemat XML, reguły Schematron EN 16931, krajowe reguły CIUS (reguły KoSIT dla XRechnung, reguły Peppol BIS dla Belgii, schemat FA(3) dla Polski) oraz kontrole krzyżowe, takie jak arytmetyka sum i rozbicia VAT. Proszę zapytać, które warstwy działają, czy zestawy reguł są w bieżących wersjach (wydanie normy z 2026 r. uruchamia migrację, a KoSIT i OpenPeppol publikują wydania według własnych harmonogramów) i czy nieudana walidacja blokuje wystawienie, czy tylko ostrzega. Bezpłatna kontrola online, która waliduje plik względem reguł danego kraju, jest uczciwym sposobem sprawdzenia deklaracji dostawcy — zob. walidator e-faktur.
Transport: część, która najbardziej różni się między krajami
Niemcy nie narzucają kanału, Belgia narzuca Peppol, Francja narzuca zarejestrowane platformy, Polska narzuca swój system państwowy; oprogramowanie obejmujące wszystkie cztery kraje albo integruje każdy kanał, albo wskazuje, który przekazuje dostawcy.
| Kraj | Wymagany kanał | O co zapytać dostawcę |
|---|---|---|
| Niemcy | Brak — FAQ BMF dopuszcza e-mail, interfejsy, portale, nośniki fizyczne | Czy plik ustrukturyzowany można dołączyć do e-maila z fakturą lub pobrać? Czy opcjonalnie może iść przez Peppol do zarejestrowanego odbiorcy, a z Leitweg-ID do nabywcy publicznego? |
| Belgia | Peppol, domyślnie | Który akredytowany punkt dostępowy przenosi ruch? Czy dostawca sam jest punktem dostępowym, czy łączy się przez taki punkt? Jak rejestrowany jest identyfikator Peppol firmy i jakie typy dokumentów są dla niego publikowane? |
| Francja | Plateforme agréée po każdej stronie | Czy dostawca jest zarejestrowany jako PA przez DGFiP, czy przesyła przez zarejestrowaną PA? DGFiP stwierdza, że niezarejestrowane rozwiązanie „ne sera donc pas autorisé à transmettre les factures électroniques aux plateformes des clients”. Czy połączenie jest dziś gotowe produkcyjnie? |
| Polska | KSeF | Czy integracja była używana z produkcyjnym KSeF, czy tylko ze środowiskiem testowym? Czy obsługuje uwierzytelnianie, sesje, UPO, tryby offline i wizualizację z kodem QR? |
Proszę być precyzyjnym co do słów. „Peppol-ready” może oznaczać akredytowany punkt dostępowy, połączenie przez taki punkt albo jedynie możliwość eksportu pliku BIS. „KSeF-ready” może oznaczać użycie produkcyjne albo moduł przetestowany wyłącznie w środowisku testowym. Dostawca powinien powiedzieć, o które chodzi; porównanie sieci wyjaśnia, dlaczego to rozróżnienie ma znaczenie.
Odbiór: zamiana przychodzącego XML w faktury zakupu
Każdy obowiązek zaczyna się od odbioru, więc oprogramowanie musi odczytywać pliki XRechnung, ZUGFeRD/Factur-X i UBL — z e-maila, z przesłania lub z sieci — do rekordu zakupu bez ręcznego przepisywania.
Proszę zapytać, co dzieje się z hybrydowym PDF: czy osadzony XML jest wyodrębniany i używany, czy PDF jest traktowany jak obraz? Proszę zapytać, czy dostawca, kwoty, rozbicie VAT, termin płatności i tytuł przelewu są mapowane do faktury zakupu oraz czy plik, który nie przechodzi walidacji, jest odrzucany, czy oznaczany. Proszę zapytać, jak przychodzące dokumenty Peppol trafiają do skrzynki odbiorczej po zarejestrowaniu identyfikatora firmy. Dla Niemiec zob. odbieranie e-faktur.
Archiwizacja: plik ustrukturyzowany jest oryginałem
Tam, gdzie faktura jest plikiem ustrukturyzowanym, to ten plik — a nie jego wizualizacja w PDF — musi być przechowywany przez krajowy okres przechowywania, w postaci niezmienionej i możliwej do odtworzenia.
Belgijski organ zauważa, że „zasady archiwizacji pozostają niezmienione” przez obowiązek, co jest prawdą wszędzie: okresy przechowywania i wymogi integralności są krajowe i starsze niż e-fakturowanie. Zmienia się przedmiot. Proszę zapytać, czy oprogramowanie przechowuje wystawiony XML (i odebrany XML) w postaci wysłanej, czy potrafi wyeksportować archiwum hurtowo i czy faktura pozostaje dostępna po zakończeniu subskrypcji. Okresy przechowywania oraz ewentualne krajowe wymogi dotyczące niezmienności lub ścieżki audytu wymagają potwierdzenia przez specjalistę.
Rozstrzygnięcia podatkowe: wyprowadzane z faktów, nie wpisywane
Pozycja VAT na fakturze wynika z kraju sprzedawcy, kraju nabywcy, statusu nabywcy jako przedsiębiorcy i rodzaju świadczenia; oprogramowanie powinno wyprowadzać ją z tych faktów i odmawiać zgadywania tam, gdzie fakty są niewystarczające.
W Europie ma to większe znaczenie niż gdziekolwiek indziej, ponieważ formaty ustrukturyzowane niosą kody kategorii VAT i przyczyny zwolnienia w sposób jawny, a walidatory sprawdzają je względem kwot. Proszę zapytać, czy oprogramowanie rozróżnia wyniki: stawka podstawowa, stawka zerowa, zwolnienie, odwrotne obciążenie i poza zakresem; czy sprawdza numer VAT nabywcy w VIES przy wystawianiu; czy zapisuje decyzję wraz z fakturą do późniejszego audytu; oraz — co ważne — czy ma uczciwy stan „wymaga danych” zamiast stawki domyślnej. Reguły stojące za rozstrzygnięciami opisuje strona e-fakturowanie transgraniczne, a bezpłatny walidator numerów VAT sprawdza numery.
API: faktura zwykle powstaje gdzie indziej
W firmie SaaS, na platformie handlowej lub w biznesie sterowanym przez ERP faktura powstaje w innym systemie; oprogramowanie do e-fakturowania potrzebuje udokumentowanego API z uwierzytelnianiem, idempotentnym tworzeniem, webhookami i trybem testowym.
Proszę zapytać, czy API tworzy szkice, które są następnie wystawiane pod walidacją produktu, czy wystawia faktury prawnie wiążące bezpośrednio (co omija powyższe kontrole); czy klucze można ograniczyć do jednej firmy i do odczytu lub zapisu; czy żądania POST przyjmują klucz idempotencji, tak aby ponowione wywołanie nie mogło utworzyć dwóch faktur; które zdarzenia są wypychane przez webhook i jak są podpisywane; oraz jaki jest limit zapytań. Programiści zechcą przeczytać dokumentację referencyjną przed zakupem — zob. API e-fakturowania i dokumentację referencyjną API.
Lista kontrolna
Dwanaście pytań, które oddzielają pokrycie od deklaracji; dostawca, który na każde odpowiada prostym „tak”, „nie” lub „przez dostawcę X”, mówi Państwu to, co muszą Państwo wiedzieć.
- Które formaty krajowe są generowane automatycznie na podstawie kraju firmy i w jakich składniach oraz profilach?
- Które zestawy reguł walidacji działają przed wystawieniem i w jakich wersjach?
- Czy nieudana walidacja blokuje wystawienie?
- Dla Belgii: który akredytowany punkt dostępowy przenosi ruch i czy dostawca sam nim jest?
- Dla Francji: czy dostawca jest plateforme agréée, albo przez którą PA przesyła, i czy to działa produkcyjnie?
- Dla Polski: czy integracja z KSeF była używana produkcyjnie?
- Czy przychodzące pliki XRechnung, ZUGFeRD/Factur-X i UBL są odczytywane do faktur zakupu z użyciem osadzonego XML?
- Czy oryginał ustrukturyzowany jest przechowywany w postaci wystawionej i eksportowalny hurtowo?
- Czy traktowanie VAT jest wyprowadzane z faktów transakcji, z kontrolą VIES i zapisanym rozstrzygnięciem?
- Czy API tworzy szkice pod walidacją, z ograniczonymi kluczami, idempotencją i podpisanymi webhookami?
- Czy istnieje tryb testowy, który zachowuje się jak produkcja?
- Które z powyższych dostawca opisuje jako ograniczenia i czy ograniczenia są opatrzone datą?
Jak KRONENWERK to obsługuje
KRONENWERK w pełni pokrywa formaty, walidację, odbiór, rozstrzygnięcia podatkowe i API; ograniczenia dotyczą transportu i są nazwane poniżej.
| Pozycja listy kontrolnej | KRONENWERK | Status |
|---|---|---|
| Generowanie formatu | XRechnung i ZUGFeRD (Niemcy), Factur-X PDF/A-3 z osadzonym CII (Francja), UBL Peppol BIS Billing 3.0 (Belgia), XML FA(3) (Polska), wybierane na podstawie kraju firmy wystawiającej. Faktury PDF z krajowymi regułami podatkowymi dla Kanady i Stanów Zjednoczonych. | Obsługiwane (FA(3): Obsługiwane z ograniczeniami) |
| Walidacja przed wystawieniem | Formaty niemieckie walidowane regułami Schematron KoSIT i sprawdzane krzyżowo biblioteką Mustang; każda faktura ustrukturyzowana walidowana przy wystawianiu. | Obsługiwane |
| Transport — Peppol | KRONENWERK wysyła i odbiera przez Peppol za pośrednictwem akredytowanego dostawcy punktu dostępowego (Storecove) po podłączeniu firmy w Ustawienia → Doręczanie. KRONENWERK sam nie jest punktem dostępowym Peppol. | Obsługiwane z ograniczeniami |
| Transport — Francja | KRONENWERK nie jest plateforme agréée. Transmisja jest planowana przez funkcję zatwierdzonej platformy Storecove i nie jest gotowa produkcyjnie. | Jeszcze niegotowe |
| Transport — Polska | Moduł KSeF 2.0 (uwierzytelnianie tokenem, sesja, wysyłka FA(3), pobieranie UPO, odbiór) zbudowany i zależny od środowiska; nieużywany z produkcyjnym KSeF. Subskrypcje nie są sprzedawane polskim firmom, dopóki nie zostanie to udowodnione. | Jeszcze niegotowe |
| Transport — Niemcy | Plik ustrukturyzowany doręczany z fakturą e-mailem lub do pobrania; opcjonalnie przez Peppol jak wyżej. | Obsługiwane |
| Odbiór | Przychodzące XRechnung, ZUGFeRD/Factur-X i UBL odczytywane do faktur zakupu; bezpłatny walidator sprawdza plik bez jego zapisywania. | Obsługiwane |
| Archiwizacja | Plik ustrukturyzowany jest generowany przy wystawianiu jako część faktury, a pliki przychodzące są odczytywane do faktur zakupu. Okresy przechowywania, eksport i ewentualny wymóg niezmienności w Państwa jurysdykcji powinien potwierdzić Państwa doradca. | Wymaga potwierdzenia przez specjalistę |
| Rozstrzygnięcie podatkowe | Dla każdej faktury na podstawie kraju sprzedawcy, kraju nabywcy, statusu przedsiębiorca/konsument i rodzaju świadczenia: stawka podstawowa, stawka zerowa, zwolnienie, odwrotne obciążenie, poza zakresem albo „wymaga danych” / „wymaga potwierdzenia przez specjalistę”; numer VAT nabywcy sprawdzany w VIES przy wystawianiu; rozstrzygnięcie zapisywane wraz z fakturą. | Obsługiwane |
| API | Publiczne API pod adresem https://kronenwerk.org/api/extern/v1 z kluczami Bearer (greif_live_… / greif_test_…), ograniczonymi do firmy; POST /invoices/drafts tworzy szkice, które są wystawiane w produkcie po walidacji; Idempotency-Key na POST; podpisane webhooki (invoice.issued, invoice.paid, invoice.cancelled, purchase.recorded, payment.recorded); serwer MCP pod /api/extern/mcp; limit 240 zapytań na klucz, uzupełniany w sposób ciągły. W planie Enterprise. | Obsługiwane |
| Tryb testowy | Klucz greif_test_ działa na tym samym API w trybie testowym dla firmy, która go utworzyła; brak osobnego hosta sandbox. | Obsługiwane |
KRONENWERK nie składa deklaracji ani nie odprowadza żadnego podatku, nie udziela porad podatkowych ani prawnych i nie posiada certyfikatu bezpieczeństwa; nie daje żadnej gwarancji co do wyników zgodności. Poza e-fakturowaniem jest produktem księgowym — księga podwójna, faktury zakupu i wydatki, połączenia bankowe przez Enable Banking i Plaid, wiele firm i wiele walut, pięć języków interfejsu. Zob. e-fakturowanie w KRONENWERK, fakturowanie, plany oraz, dla programistów, przegląd dla programistów. Powrót do centrum wiedzy o Europie.
Najczęściej zadawane pytania
Czy „zgodne z EN 16931” oznacza, że oprogramowanie działa w każdym kraju UE?
Nie. EN 16931 ustala model treści; każdy kraj dodaje własny profil, kanał i terminy, a Polska używa schematu spoza EN. Proszę pytać osobno o każdy kraj.
Czy oprogramowanie musi być punktem dostępowym Peppol?
Nie. Większość produktów łączy się przez akredytowany punkt dostępowy; liczy się to, że dostawca mówi, który to punkt, i że połączenie działa dla Państwa firmy.
Czy mogę używać niezarejestrowanego narzędzia do francuskiego e-fakturowania?
Można w nim przygotowywać faktury, ale DGFiP stwierdza, że tylko zarejestrowana plateforme agréée może przesyłać je na platformy Państwa klientów i wysyłać dane do administracji.
Czy API powinno wystawiać faktury bezpośrednio?
Raczej nie. Tworzenie szkiców przez API i wystawianie ich pod walidacją produktu utrzymuje kontrole formatu i podatku na ścieżce; API KRONENWERK działa w ten sposób.
Czy kopia PDF wystarczy do archiwum?
Tam, gdzie faktura jest plikiem ustrukturyzowanym, ten plik jest fakturą; proszę zachować go w postaci wystawionej. Krajowe zasady przechowywania wymagają potwierdzenia przez specjalistę.
Źródła
- European Commission — Obtaining a copy of the European standard on eInvoicing — odczytano
- OpenPeppol — Peppol Interoperability Framework — odczytano
- DGFiP — Facturation électronique et plateformes agréées — odczytano
- Bundesfinanzministerium — Fragen und Antworten zur Einführung der obligatorischen E-Rechnung — odczytano
- FPS BOSA / efactuur.belgium.be — Structured electronic invoices between companies are compulsory since 2026 — odczytano
- Ministerstwo Finansów — Tryb offline i kody QR — odczytano
- KRONENWERK developer documentation — odczytano