Podczas wysyłania faktury przez platformę eConnect może pojawić się komunikat o błędzie. Większość błędów jest związana z brakującymi lub nieprawidłowymi danymi w fakturze. Poniżej opisane są najczęstsze komunikaty, ich przyczyny i sposoby rozwiązania.

Ten ogólny komunikat o błędzie jest wywoływany przez walidację przed wysyłką w interfejsie platformy. Platforma sprawdza przed wysyłką, czy wartość identyfikatora (np. OINO, numer rejestrowy) odpowiada oczekiwanemu formatowi. Jeśli ta weryfikacja się nie powiedzie, pojawia się ten komunikat o błędzie.

Zgłoszenie przez AFAS / E-verbinding: na pytanie „czy mogę wysłać ponownie z AFAS lub E-verbinding?” odpowiedź to zwykle wysłanie ponowne przez platformę (Skrzynka wychodząca > Wyśl ponownie), a nie ponowne generowanie w AFAS -- o ile dokument znajduje się już w skrzynce wychodzącej. Czerwony błąd „Nieznany błąd podczas wywoływania zdarzenia aplikacji” przy ponownym wysyłaniu to prawie zawsze ta sama walidacja schematu/wartości co powyżej, a nie osobna awaria AFAS. Zobacz też sekcję „Ponowne wysłanie faktury z poprawną referencją” poniżej.

Częsty przykład: schemeID 0190 (OINO) wymaga dokładnie 20 cyfr. Jeśli wartość zawiera prefix — np. NL:OINO:00000001001932779000 zamiast po prostu 00000001001932779000 — walidacja kończy się niepowodzeniem.

Uwaga: ten błąd może wystąpić również w przypadku faktur utworzonych przez API, nie tylko ręcznie.

Rozwiązanie: sprawdzenie wartości identyfikatora i usunięcie ewentualnych prefiksów lub nieprawidłowych znaków. Wartość musi dokładnie odpowiadać oczekiwanemu formatowi dla schemeID (np. 20 cyfr dla OINO, 8 cyfr dla numeru rejestrowego).

Ogólna zasada -- wpisuj tylko wartość numeryczną; platforma automatycznie dodaje prefiks schemeID. Dotyczy to wszystkich schematów identyfikacji, nie tylko OINO. Jeśli użytkownik również samodzielnie wpisuje prefiks (np. 0088:1234567890123 podczas gdy schemat jest już ustawiony na GLN/0088), walidacja formatu kończy się błędem. Przykład GLN (schemeID 0088, GS1): wybierz schemat GLN i wpisz w polu wartości tylko cyfry GLN -- bez 0088: na początku.

Jeśli dostawca umieszcza apostrof przed numerem OIN w XML (znany artefakt Excela), routing Peppol kończy się niepowodzeniem. Starszy system rozpoznaje fakturę i dostarcza ją wewnętrznie — odbiorca nie widzi faktury w swojej skrzynce zobowiązań, ale otrzymuje e-mail powiadomienia z linkiem.

Rozwiązanie: proś dostawcę o podanie numeru OIN bez apostrofu w XML i o sprawdzenie ustawień eksportu Excela.

Platforma waliduje każdą fakturę zgodnie z obowiązującymi standardami Peppol i NLCIUS przed wysłaniem. Kody błędów zaczynające się od BR (Business Rule) wskazują, która reguła nie została spełniona.

Własna organizacja (dostawca) nie jest prawidłowo wybrana w fakturze. Dzieje się tak, gdy pole dostawcy zostało ręcznie zmienione lub gdy organizacja nie została jeszcze aktywowana.

Rozwiązanie: kliknięcie ikony ołówka obok "Dostawca" i ponowne wybranie własnej organizacji. Jeśli organizacja nie została jeszcze aktywowana, należy to zrobić zgodnie z artykułem Dodawanie i aktywacja organizacji.

Dodany załącznik ma typ MIME, który nie jest dozwolony w aktualnej walidacji Peppol BIS Billing V3. Dozwolone typy załączników to (BT-125):

application/xml nie jest dozwolony jako typ MIME załącznika w aktualnej walidacji BIS Billing V3. XML jako załącznik należy do EN 16931-1:2026 i przyszłej wersji Peppol (prawdopodobnie BIS Billing 4.0) — nie dodawaj załącznika XML, aby rozwiązać problem BR-CL-24.

Częsta przyczyna (Business Central i inne systemy ERP): system ERP automatycznie dołącza pliki przypisane do zaksiegośowanej faktury. Załącznik z niedozwolonym typem (np. dokument Word) powoduje błąd BR-CL-24.

Rozwiązanie:

1. Sprawdź, jakie załączniki są przypisane do faktury w systemie ERP (Business Central: Zaksiegośowana faktura sprzedaży > Załączniki).
2. Usuń lub zastąp załączniki z niedozwolonym typem — np. przekonwertuj dokument Word na PDF.
3. Wyślij fakturę ponownie.

Warianty wyszukiwania: "BR-CL-16", "Payment means in an invoice MUST be coded using UNCL4461 code list", "PaymentMeansCode puste", "UNCL4461", "BT-81 nieprawidłowy".

BR-CL-16 występuje, gdy Payment means type code (BT-81, cbc:PaymentMeansCode w cac:PaymentMeans) jest puste, zawiera dowolny tekst lub nie występuje na liście kodów UNCL4461. Dosłowny komunikat brzmi m.in.: "Payment means in an invoice MUST be coded using UNCL4461 code list".

Rozwiązanie: ustaw PaymentMeansCode na prawidłowy kod UNCL4461, np. 30 (przelew), 49 (polecenie zapłaty), 58 (przelew SEPA) lub 59 (polecenie zapłaty SEPA). To poprawka w UBL źródłowym u nadawcy -- w przypadku otrzymanej i przekazanej dalej faktury (InvoiceReceived) PaymentMeans jest przekazywany 1:1, więc ponowne wysłanie bez korekty nie pomoże. Zweryfikuj wcześniej za pomocą Document Validator.

Jednostka wpisana przy pozycji faktury nie jest rozpoznawana jako prawidłowy kod UN/ECE. Dzieje się tak przy użyciu skrótu lub własnej nazwy.

Rozwiązanie: użycie standardowej jednostki z listy wyboru, takiej jak "Sztuki" (EA), "Godziny" (HUR) lub "Dni" (DAY).

Typ identyfikatora w polu "OrganisatieID" nie zgadza się z typem w polu "Wyślij przez". Na przykład: OrganisatieID jest ustawione na OIN, ale "Wyślij przez" na KvK.

Rozwiązanie: upewnienie się, że oba pola używają tego samego typu identyfikatora.

Numer VAT dostawcy jest nieobecny w fakturze.

Rozwiązanie: uzupełnienie numeru VAT w ustawieniach organizacji.

Jeżeli Twoja organizacja nie posiada numeru VAT (np. fundacja, organ publiczny lub usługodawca zdrowotny świadczący wyłącznie usługi zwolnione z VAT)? Nie używaj wartości zastępczej NL000000000B01. Zamiast tego wybierz kategorię VAT 'O' — poza zakresem VAT podczas wystawiania faktury. Przy kategorii 'O' obowiązek podania numeru VAT znika, a faktura spełnia standard Peppol. Zob. także Odwrotne obciążenie VAT i kategoria VAT O po objaśnienie kodów kategorii VAT.

Fundacje, niektóre organy publiczne i usługodawcy zdrowotni świadczący wyłącznie usługi zwolnione z VAT nie posiadają numeru VAT. Podczas tworzenia faktury na platformie pojawia się wymog podania numeru VAT dostawcy.

Rozwiązanie: Wybierz kategorię VAT 'O' — poza zakresem VAT (kod UNCL5305 O, "Services outside scope of tax") w formularzu fakturowania. Przy kategorii 'O' wymog interfejsu dla pola numer VAT znika i faktura może zostać wysłana bez numeru VAT dostawcy.

Nie używaj fikcyjnych numerów VAT takich jak NL000000000B01 — to nie jest przewidziane rozwiązanie dla tego scenariusza. Kategoria 'O' jest prawidłowym wybórem dla organizacji bez obowiązku VAT.

Różnica 'E' i 'O': Kategoria VAT 'E' (Exempt from VAT) jest przeznaczona dla podatników VAT fakturujących określoną transakcję zwolnioną. Kategoria 'E' wymaga numeru VAT. Kategoria 'O' jest dla organizacji bez jakiegokolwiek obowiązku VAT.

Przy kategorii O nie wpisuj wartości zastępczej w polu numeru VAT. Wartości takie jak nvt, n/d, NA lub myslnik nie są prawidłowym numerem VAT i nadal spowodują błąd walidacji. Organizacja strukturalnie nie posiada numeru VAT? Wybierz kategorię O i pozostaw pole numeru VAT puste — nie wpisuj w nim niczego.

Warianty wyszukiwania: "Typ VAT jest wymagany na pozycji faktury", "I18N_INV.UI.VALUE_MISSING", "puste pole VAT pozycja faktury", "faktura robocza nie można zapisać VAT", "SnelStart XML szkic kategoria VAT".

Ten komunikat pojawia się, gdy kategoria VAT (rozwijane pole VAT) pozostała pusta na co najmniej jednej pozycji faktury. Komunikat blokuje zarówno Zapisz, jak i Wyślij. Występuje to często przy XML dostarczonym przez Email Odbiorcę (np. z SnelStart), który wpływa jako szkic bez prawidłowej kategorii VAT dla każdej pozycji.

Rozwiązanie:

1. Przejdź do Faktury sprzedaży → Faktury robocze i otwórz odpowiedni szkic.
2. Dla każdej pozycji faktury wybierz właściwą kategorię VAT w rozwijanym polu. Nie wybieraj stawki na podstawie założenia -- wybierz kategorię odpowiadającą faktycznej dostawie.
3. Sprawdź także pozostałe wymagane pola: datę faktury, Dostawcę i Klienta. Jeśli któreś z tych pól jest nieprawidłowe, użyj ikony ołówka, aby ponownie wybrać stronę z listy rozwijanej zamiast wpisywać nazwę ręcznie.
4. Sprawdź numer VAT pod kątem kodu kraju i separatorów (np. BE0665904901 dla Belgii), zob. BR-CO-09 poniżej.
5. Zapisz i wyślij fakturę.

Strukturalnie przy dostawie ERP/XML: niekompletny eksport z oprogramowania księgowego lub fakturującego prowadzi do niewiarygodnego automatycznego wysyłania (auto-send). Dostawca oprogramowania musi dołączyć prawidłową kategorię VAT dla każdej pozycji faktury w XML.

Zob. także "Pole Dostawca to lista rozwijana, nie pole tekstowe" i BR-CO-09 powyżej, oraz Email Odbiorca dla auto-send XML (tylko przy prawidłowym XML).

Przy fakturowaniu instytucji rządowych wymagany jest numer IBAN.

Rozwiązanie: uzupełnienie numeru IBAN w danych płatności faktury.

Błąd ten występuje, gdy CompanyID zawiera numer VAT zamiast numeru rejestrowego lub OIN.

Technicznie: EndpointID i CompanyID to dwa oddzielne pola o różnym przeznaczeniu. EndpointID określa routing przez Peppol i akceptuje każdy typ z listy kodów EAS. CompanyID identyfikuje podmiot prawny.

Rozwiązanie: sprawdzenie UBL generowanego przez system i upewnienie się, że CompanyID zawiera numer rejestrowy lub OIN.

Warianty wyszukiwania: „OP-T10-R008”, „Party Company Identifier Scheme”, „schemeID NL:KVK”, „schemeID NL:VAT”, „literowy kod schemeID CompanyID”, „CompanyID scheme nieprawidłowy”.

OP-T10-R008 (Party Company Identifier Scheme) występuje, gdy atrybut schemeID w polu Party CompanyID (PartyLegalEntity/CompanyID lub PartyIdentification) zawiera historyczny kod literowy, taki jak NL:KVK lub NL:VAT, zamiast numerycznego kodu PEPPOL. Jest to niedopuszczalne: walidacja wymaga scheme z oficjalnej listy identyfikacji stron PEPPOL.

Kod literowy NL:KVK jest traktowany przez Peppol Service Bus (PSB) jako alias trasowania dla scheme 0106, ale to nie dotyczy tego pola UBL -- to dwa różne konteksty.

Rozwiązanie: zastąp kod literowy numerycznym kodem EAS, na przykład schemeID="0106" dla holenderskiego numeru rejestrowego:

<cbc:CompanyID schemeID="0106">12345678</cbc:CompanyID>

Puste pole CompanyID podlega innej regule -- zobacz „NL-R-005 / NL-R-003” powyżej. Więcej informacji o typach identyfikatorów i schemeID: Party identifiers.

Warianty wyszukiwania: „BR-AE-10”, „SOAP:CLIENTBR-AE-10”, „Reverse charge shall have a VAT exemption reason”, „BT-120”, „BT-121”, „brak powodu zwolnienia odwrotne obciążenie”, „faktury odrzucone reverse charge”.

BR-AE-10 występuje, gdy kategoria VAT AE (Reverse Charge) w zestawieniu VAT (BG-23) nie zawiera powodu zwolnienia: ani BT-121 (kod), ani BT-120 (tekst, np. „Reverse charge”). To błąd w dostarczonym UBL z ERP lub pakietu fakturującego -- eConnect waliduje fakturę, ale nie modyfikuje automatycznie pól AE.

Rozwiązanie:

1. Sprawdź, czy każda pozycja lub doliczenie faktury z kategorią VAT AE ma stawkę VAT 0%.
2. W eksporcie UBL systemu źródłowego uzupełnij pole TaxExemptionReason (BT-120) i/lub kod (BT-121) dla każdego zestawienia AE.
3. Zwaliduj fakturę wcześniej przez Document Validator.
4. Wyślij ponownie skorygowaną fakturę -- ponowne wysłanie oryginalnego, błędnego XML nie rozwiązuje tego problemu.

Zob. także Odwrotne obciążenie VAT: kody K, AE i G po pełne wyjaśnienie kodów odwrotnego obciążenia VAT.

Te reguły walidacji EN 16931 sprawdzają, czy zestawienie VAT i sumy faktury są wzajemnie spójne. Wartości są obliczane przez wysyłane oprogramowanie — nie są to pola, które można poprawić w interfejsie eConnect.

Warianty wyszukiwania BR-CO-12 / BR-E-01: "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "suma dopłat się nie zgadza", "koszty wysyłki nie na pozycji faktury", "Shipping costs AllowanceCharge", "brak zestawienia Exempt".

BR-CO-12 występuje, gdy suma dopłat na poziomie faktury nie zgadza się z sumą poszczególnych dopłat dokumentu — na przykład gdy koszty wysyłki są ujęte jako osobny AllowanceCharge na poziomie faktury (ChargeIndicator=true, powód "Shipping costs" / kod FC). Jest to prawidłowy UBL; zobacz Dopłaty i rabaty po strukturę. BR-E-01 występuje, gdy pozycja faktury, dopłata lub rabat dokumentu z kategorią VAT 'Zwolniony z VAT' (E) nie ma odpowiadającego zestawienia Exempt w podsumowaniu VAT.

Częsta przyczyna: zaokrąglanie VAT od każdej pozycji zamiast według stawki VAT lub niezgodność między kwotami pozycji a rabatami na poziomie faktury.

Rozwiązanie: skontaktowanie się z dostawcą wysyłanego oprogramowania w celu korekty. eConnect nie może poprawiać tych wartości, ponieważ obliczenie jest ustalone w dostarczonym XML.

Warianty wyszukiwania: „Invalid payload BR-S-08”, „Delivery Failed BR-S-08”, „podsumowanie VAT się nie zgadza”, „pozycja faktury bez ilości”, „brak ilości pozycji faktury”, „BT-116”, „VAT category taxable amount”.

Oprócz błędów zaokrąglenia BR-S-08 występuje również, gdy pozycja faktury nie ma ilości (lub ma pustą ilość) (Invoiced quantity / BT-129). W takim przypadku kwota pozycji bez VAT jest nieprawidłowa (ilość x cena jednostkowa plus dopłaty pozycji minus rabaty pozycji), przez co suma pozycji odbiega od VAT category taxable amount (BT-116) w zestawieniu VAT dla Standard rated. Dosłowny komunikat błędu często wygląda tak: Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....

Różnica względem błędów xs:decimal: w sekcji „'nie jest prawidłowym xs:decimal'” powyżej samo pole kwoty nie jest prawidłową liczbą dziesiętną (puste lub notacja naukowa). Przy BR-S-08 pole kwoty jest prawidłową liczbą, ale obliczenie między kwotami pozycji a zestawieniem VAT się nie zgadza.

Lista kontrolna pierwszej linii (przed eskalacją do dostawcy oprogramowania):

1. Sprawdź wszystkie pozycje faktury pod kątem wypełnionej ilości i kwoty pozycji bez VAT.
2. Kwota pozycji = ilość x cena jednostkowa (plus dopłaty pozycji, minus rabaty pozycji); żadnych pustych pól kwoty.
3. Zleć ponowne obliczenie sum VAT w systemie źródłowym.
4. Wyślij skorygowaną fakturę przez Peppol. Ponowne wysłanie tego samego dokumentu bez korekty nie rozwiązuje BR-S-08 -- Wyślij ponownie w skrzynce wychodzącej nie zmienia kwot pozycji ani VAT (ten sam zakres ponownego wysyłania co przy R120 powyżej).
5. Błąd nadal występuje przy kompletnych ilościach? Wtedy chodzi o błąd zaokrąglenia lub inny błąd obliczeniowy w ERP lub eksporcie UBL -- przekaż do dostawcy oprogramowania.

Kategoria VAT E vs. O: czy organizacja nie posiada numeru VAT (fundacja, organ publiczny, ochrona zdrowia)? Użyj kategorii O (poza zakresem VAT) — zob. sekcję »Organizacje zwolnione z VAT: kategoria O« powyżej. Kategoria E zawsze wymaga numeru VAT.

Warianty wyszukiwania: „Processing is not possible”, „We were unable to process the UBL invoice in the attachment”, „BR-CO-18”, „BR-Z-01”, „BR-Z-05”, „Zero rated”, „stawka zerowa UBL”, „brak zestawienia VAT BG-23”, „XML + PDF wysłane razem”, „UBL odrzucony PDF mimo to przetworzony”, „tłumienie komunikatu błędu XML”, „ditch the XML”.

Zero rated (Z, stawka 0% VAT) nie jest synonimem zwolnienia (kategoria E) ani odwrotnego obciążenia VAT (kategoria AE) -- pozycje, stawki i sumy VAT muszą być wzajemnie spójne:

• BR-CO-18: dla każdej użytej kombinacji kategorii VAT, stawki, podstawy zwolnienia i kodu artykułu faktura musi mieć co najmniej jedno zestawienie VAT (BG-23). Brak lub niekompletne -- odrzucenie.
• BR-Z-01: jeśli kategoria Z jest użyta na pozycji faktury, dopłacie lub rabacie dokumentu, zestawienie VAT musi zawierać co najmniej jedną pozycję z kategorią Z („co najmniej jedną”, nie „dokładnie jedną”).
• BR-Z-05: jeśli kategoria VAT to Z, stawka VAT musi wynosić 0.

Kombinacja XML + PDF w jednym e-mailu (dual-path): jeśli przychodzi e-mail zarówno z załącznikiem XML, jak i PDF, a XML zostaje odrzucony na jednej z tych reguł, wiadomość e-mail z platformy może pokazać „Processing is not possible” lub „We were unable to process the UBL invoice in the attachment” -- podczas gdy PDF został przetworzony i znajduje się w skrzynce odbiorczej. To nie jest podwójny błąd: oba załączniki są oceniane osobno, a komunikatu o błędzie dotyczącego XML nie można stłumić, dopóki obecne są inne pomyślnie przetworzone załączniki.

Wszystkie te błędy znajdują się w przesłanym UBL od nadawcy lub jego oprogramowania. eConnect nie koryguje pól VAT w przesłanym XML; ponowne wysłanie tego samego, błędnego XML niczego nie rozwiązuje -- potrzebna jest nowa, skorygowana faktura. Można zweryfikować wcześniej za pomocą Document Validator.

Rozwiązanie (wybierz jedną z tych strukturalnych ścieżek):

1. Popraw UBL u źródła: dostawca lub oprogramowanie uzupełnia zestawienie VAT (kategoria Z z odpowiednim zestawieniem, stawka 0, spójne pozycje i sumy).
2. Pomiń XML: wyślij tylko PDF, bez załącznika XML w tym samym e-mailu (dotyczy tylko ścieżki przesyłania przez e-mail, nie jest zamiennikiem dla wysyłki przez Peppol).
3. Email Receiver tylko na PDF: wsparcie może skonfigurować Email Receiver klienta tak, by akceptował tylko faktury cyfrowe (PDF), dzięki czemu XML przestaje być walidowany.

Jeśli faktura idzie przez Peppol lub natywny UBL, opcja 1 jest jedynym strukturalnym rozwiązaniem -- PDF nie jest tam zamiennikiem dla ważnego UBL.

Warianty wyszukiwania: „Błąd Peppol”, „status dostawy”, „status dostawy we własnym oprogramowaniu”, „zaokrąglanie w czasie”, „dwa miejsca dziesiętne oprogramowanie źródłowe”, „kwoty bez VAT niepoprawne”, „nowa partia ten sam błąd”.

Triage przy wielu możliwych przyczynach („Błąd Peppol” / status dostawy ERP): to samo zgłoszenie może zawierać zarówno błąd obliczeniowy R120, jak i błąd schematu EndpointID. Postępuj w tej kolejności:

1. Sprawdź najpierw dosłowny kod lub tekst błędu w skrzynce wychodzącej eConnect (platform.econnect.eu) -- nie tylko status w ERP lub pakiecie księgowym klienta (np. „dostawa” lub „błąd”). Status ERP nie jest tym samym co status platformy eConnect.
2. Błąd wskazuje na „sum invoice line”, zaokrąglanie lub dwa miejsca dziesiętne w pakiecie źródłowym? Wtedy chodzi o to obliczenie pozycji R120 -- poprawka leży po stronie oprogramowania wysyłającego.
3. Chodzi o nieprawidłowy EndpointID ze schematem 0190 (holenderski OIN) dla dłużnika belgijskiego? Użyj wtedy schematu 0208 (belgijski numer przedsiębiorstwa, 10 cyfr bez punktów) lub schematu, w którym odbiorca faktycznie jest zarejestrowany na Peppol -- zobacz sekcję o belgijskim numerze przedsiębiorstwa poniżej.
4. Nowa partia zawodzi ponownie? Dzieje się to tylko, gdy ta sama przyczyna leżąca u podłoża (obliczenie R120 i/lub schemat EndpointID) wciąż jest w XML -- nie z powodu samej etykiety typu partii.

Ten błąd jest również zgłaszany jako błąd „sum invoice line". R120 to reguła obliczeniowa, która sprawdza, czy LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + dopłaty − rabaty. R120 nie zabrania wprost kwot ujemnych; walidacja kończy się niepowodzeniem, gdy obliczenie nie jest spójne. Zdarza się to często, gdy rabat na poziomie pozycji (AllowanceCharge na poziomie pozycji) przekracza cenę artykułu, na przykład w nocie kredytowej z wysokim rabatem.

Korekta należy do oprogramowania wysyłającego (programu, w którym faktura została utworzona), a nie do eConnect: eConnect nie dostosowuje kwot w przesłanym pliku XML.

Rozwiązanie: użyj kwoty netto korekty bezpośrednio jako PriceAmount i pomiń element AllowanceCharge w linii. Szczegóły i przykład XML znajdziesz w artykule o dopłatach i rabatach. Prośba o plik XML faktury jest potrzebna wyłącznie jako pogłębiona analiza w przypadku nietypowych wzorców, a nie jako pierwszy krok.

Ponowne wysłanie nie rozwiązuje R120. Wyślij ponownie w skrzynce wychodzącej poprawia pola routingu i referencji (takie jak EndpointID lub numer zamówienia) — nie kwoty pozycji ani rabatów pozycji. W przypadku R120 ponowna próba z tym samym dokumentem nie ma sensu: popraw obliczenie w oprogramowaniu wysyłającym lub utwórz nowy dokument.

Faktura utworzona bezpośrednio na platformie (bez zewnętrznego XML z ERP)? Utwórz nową fakturę sprzedaży — dokument w skrzynce wychodzącej jest tylko do odczytu i nie można go usunąć. Upewnij się, że ilość × cena jednostkowa równa się kwocie pozycji dla każdej linii, bez oddzielnego rabatu pozycji przekraczającego cenę artykułu; w razie potrzeby wpisz bezpośrednio cenę netto. Ponownie wybierz odbiorcę i wyślij przez Peppol. Nieudany dokument może pozostać w skrzynce wychodzącej; oznaczenie go jako duplikatu nie jest problemem.

Faktura korygująca z AFAS (przez eVerbinding) nie dociera. Gdy faktura korygująca przesłana przez AFAS i eVerbinding wywołuje R120, tekst błędu może nie wymieniać R120 wprost: status pokazuje wtedy „niepowodzenie dostarczenia" lub „document format not supported by receiver", często po nieudanej transformacji NLCIUS do Peppol BIS. Jest to skutek błędu walidacji treści, a nie dowód, że odbiorca jest nieosiągalny lub odrzuca fakturę.

Kolejność diagnozy: najpierw logi, XML tylko do pogłębionej analizy.

1. Najpierw otwórz logi nadawcy lub status w skrzynce wychodzącej dokumentu i szukaj dosłownego kodu R120, tekstu „Invoice line net amount MUST equal" lub zgłoszonego błędu transformacji NLCIUS do BIS.
2. Tylko jeśli to nie wyjaśnia problemu: otwórz fakturę w skrzynce wychodzącej i użyj menu rozwijanego Pobierz XML, aby wyświetlić przesłany plik XML. Prośba o plik XML od klienta to opcjonalny krok pogłębiony, nie pierwsza czynność, gdy logi już pokazują błąd.

eConnect nie konwertuje ilości ani cen. W przypadku prawidłowej linii kredytowej lub korygującej oczekuje się ujemnej ilości i dodatniej ceny jednostkowej (całkowita kwota jest wtedy ujemna). eConnect nie zmienia znaku ilości ani cen z ujemnego na dodatni ani odwrotnie — R120 kończy się niepowodzeniem na obliczeniu w przesłanym pliku XML z systemu źródłowego (np. AFAS). Fakt, że interfejs platformy wyświetla tylko plik PDF bez oddzielnego widoku XML, nie wskazuje, że eConnect przepisuje kwoty.

Także bez rabatu liniowego (czysta niezgodność ilość × cena). R120 zawodzi także, gdy na pozycji nie ma AllowanceCharge, ale Quantity × (PriceAmount / BaseQuantity) nie odpowiada LineExtensionAmount. Wskazuje to zazwyczaj na błąd dziesiętny lub czynnik 100 w cenie lub kwocie pozycji w XML źródłowym, na przykład 200 × 5,14 = 1028,00 zamiast 10,28. W takim przypadku sprawdź pola XML ręcznie -- nie tylko sumy widoczne w interfejsie.

Sumy na ekranie są poprawne, ale R120 wciąż zawodzi. Klient może stwierdzić, że kwoty na ekranie wersji roboczej są poprawne; to nie wyklucza R120. R120 sprawdza pola w XML (Quantity, PriceAmount, BaseQuantity, LineExtensionAmount, AllowanceCharge), a nie to, co jest wyświetlane na ekranie. Jeśli faktura wersji roboczej lub dostarczony XML źródłowy wciąż zawodzi na R120, popraw w systemie źródłowym i wyślij nowy lub poprawiony dokument. Ręczna zmiana OrganisationID lub jednostki nie rozwiązuje R120 -- to inne reguły walidacji.

Te trzy kody błędów pojawiają się, gdy faktura została technicznie wysłana, ale odbiorca lub walidator odrzuca treść na podstawowych polach w UBL/XML. Przyczyna leży w samym pliku XML, nie w połączeniu Peppol, ID Peppol ani sposobie dostarczenia do dłużnika.

Rozwiązanie: popraw odpowiednie pola w oprogramowaniu, w którym faktura jest tworzona -- CustomizationID i ProfileID to wartości ustalone dla danego typu dokumentu, nie ustawienie w platformie eConnect. Jeśli brakuje zarówno BuyerReference, jak i OrderReference, dodaj jedno z nich przed ponownym wysłaniem faktury.

Uwaga dotycząca R007 i innych profili BIS: wartość domyślna w tabeli dotyczy standardowej faktury/noty kredytowej. Self-billing i inne profile Peppol BIS (np. self-billing invoicing) mają własny, odmienny ProfileID. Nie wymuszaj wartości domyślnej na fakturach, które celowo używają innego profilu BIS -- najpierw sprawdź, jaki profil ma zastosowanie, zanim zastosujesz tę FAQ.

Nie mylić z: brakującą rejestracją Peppol u odbiorcy, nieprawidłowym EndpointID, awarią Access Point lub komunikatem "brak dostępnych reguł walidacji" (zob. odpowiednią sekcję poniżej) -- te przypadki mają inne symptomy niż ta kombinacja specyfikacji, profilu i referencji.

Źródło: zgłoszenie #15272547 (2026-07-28).

Warianty wyszukiwania: "P0112", "invoice type code 326 or 384 is only allowed when both buyer and seller are German organisations", "typecode 326", "faktura częściowa", "gdzie zmienić typ faktury", "zmiana kodu typu faktury w portalu", "nie widzę pola typu faktury", "384 francuskie faktury sprzedaży", "debet i kredyt na tej samej fakturze Francja", "faktura korygująca nie we Francji", "obie strony nie mają siedziby we Francji", "obie strony nie w kraju X", "InvoiceTypeCode 384 FR", "P0112 Francja", "mixed debit credit BIS 3.0", "podział 380 381".

Ten błąd występuje, gdy cbc:InvoiceTypeCode (BT-3) ma wartość 326 (faktura częściowa) lub 384 (faktura korygująca), a dostawca i odbiorca nie są obydwaj organizacjami niemieckimi. Reguła Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 dopuszcza 326 i 384 tylko, gdy obie strony są niemieckie.

Brak reguły specyficznej dla FR: tekst błędu lub własna interpretacja o "obie strony nie mają siedziby we Francji" lub "nie w kraju X" jest błędną parafrazą. P0112 sprawdza wyłącznie Niemcy (dostawca i odbiorca), nie kraj faktury ani siedzibę stron francuskich. Wychodząca francuska jednostka z kodem typu 384 na BIS Billing 3.0 napotyka to samo ograniczenie DE→DE -- nie istnieje osobna ścieżka "faktura korygująca FR".

Interfejs portalu: wybór typu faktury znajduje się po prawej stronie na wersji roboczej faktury. Etykiety klienta obejmują m.in. fakturę częściową (obok standardowych terminów "faktura korygująca" i "faktura handlowa") -- łatwo to przeoczyć.

Rozwiązanie (portal, faktura NL lub nie-DE, w tym FR/BIS 3.0):

1. Przejdź do Faktura sprzedaży → utwórz fakturę (wersja robocza).
2. Po prawej stronie wersji roboczej: sprawdź typ faktury -- zwróć uwagę na etykietę faktura częściowa.
3. Wybierz Fakturę handlową (kod typu 380) zamiast faktury częściowej (326) lub faktury korygującej (384), o ile nie jest to prawdziwa korekta i zarówno nadawca, jak i odbiorca są niemieccy.
4. Dla korekty do odbiorcy niebędącego niemieckim: użyj noty kredytowej lub ujemnej faktury 380 plus nowej faktury -- zob. Warianty noty kredytowej. Nie używaj kodu typu 326/384 poza DE→DE.
5. Przy korekcie z zarówno pozycjami debetowymi, jak i kredytowymi na tej samej fakturze poza DE→DE: podziel na dwa dokumenty -- 380 (debet) i 381 (kredyt) -- lub użyj jednej 380 z pozycjami kredytowymi jako ujemną ilość i pozytywną cenę.

Źródło: Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

Ten błąd występuje na pozycji(-ach) faktury z kategorią VAT Dostawa wewnątrzwspólnotowa / Intra-community supply (K, BT-151), gdy brakuje wymaganych danych VAT. Dla kategorii K wymagane są: VAT dostawcy (seller VAT, BT-31) lub VAT przedstawiciela podatkowego (seller tax representative VAT, BT-63), oraz VAT nabywcy (buyer VAT, BT-48). Brakujące dane znajdują się w danych strony (organizacji lub dłużnika), nie na samej pozycji faktury. Komunikat błędu nie wskazuje jednego konkretnego numeru pozycji -- reguła uruchamia się, gdy tylko jedna z pozycji faktury używa kategorii K.

Rozwiązanie:

1. Ustal, która(-e) pozycja(-e) faktury używa(ją) kategorii VAT K (dostawa wewnątrzwspólnotowa).
2. Wprowadź numer VAT dostawcy (seller VAT) w ustawieniach organizacji lub wprowadź przedstawiciela podatkowego (seller tax representative VAT).
3. Wprowadź numer VAT klienta (buyer VAT) w danych dłużnika.
4. Wyślij fakturę ponownie. Dokument w skrzynce wychodzącej jest tylko do odczytu -- w razie błędu należy utworzyć nową fakturę sprzedaży.

Belgijskie ID Peppol mogą mieć dwie formy:

Format numeru VAT: BE plus dokładnie 10 cyfr (dodać wiodące zera jeśli potrzebne). Weryfikacja numeru VAT możliwa za pomocą narzędzia VIES Komisji Europejskiej (ec.europa.eu/taxation_customs/vies).

Opcja Peppol nie pojawia się dla belgijskiego dłużnika? Sprawdzenie, z jakim typem identyfikatora dłużnik jest zarejestrowany w Peppol. Niektóre belgijskie organizacje są zarejestrowane tylko przez 0208: (KBO), a nie przez 9925: (VAT). W takim przypadku spróbować numeru KBO: numer VAT bez BE na początku (np. dla BE0123456789 numer przedsiębiorstwa to 0123456789; dla BE1xxxxxxxxx to 1xxxxxxxxx -- oba prefiksy są ważne).

Inne: ujemne kwoty pozycji nie są dozwolone w fakturach belgijskich; użyć ujemnej ilości z pozytywną ceną.

Kody błędów BR-DE-* to niemieckie reguły walidacji specyficzne dla XRechnung.

Brak Leitweg-ID (EAS 0204): częsty przy fakturowaniu do niemieckich organów publicznych. Należy zażądać Leitweg-ID od zamawiającej instytucji i dodać jako identyfikator ze schemeID 0204.

PDF nieakceptowany: od 1 stycznia 2025 roku Niemcy wprowadziły obowiązek odbierania e-faktur. Zwykły PDF często nie jest już wystarczający. Wysyłanie faktury jako XRechnung lub ZUGFeRD.

Odrzucenie KSeF: często spowodowane nieprawidłowym formatem XML FA_VAT. Jednostka PSB eConnect normalnie obsługuje poprawną transformację do polskiego formatu KSeF.

Błędy certyfikatów: mogą wystąpić, jeśli certyfikaty KSeF nie są prawidłowo zainstalowane lub wygasły.

Limit zapytań: KSeF stosuje limity na liczbę zapytań. eConnect stosuje przetwarzanie wsadowe, aby temu zapobiegać.

UWV stosuje własne reguły walidacji poza standardową walidacją Peppol/NLCIUS.

• UWV Duży Przepływ Gotówki (reintegracja, szkolenia, świadczenia): OIN 00000004191771249000
• UWV Mały Przepływ Gotówki (zarządzanie): OIN 00000004172892677000

Rozwiązanie dla kodu UWV: uzupełnienie brakującego pola na fakturze. Seria UWV001 dotyczy wymaganych pól dostawcy; seria UWV002 elementów identyfikacji.

Ten komunikat pojawia się w Skrzynce nadawczej, gdy faktura nie mogła zostać dostarczona do odbiorcy przez sieć Peppol. Możliwe przyczyny:

• Odbiorca nie jest zarejestrowany w Peppol: odbiorca nie posiada aktywnej rejestracji Peppol. Platforma automatycznie oferuje e-mail fallback.
• EndpointID nieprawidłowe: adres Peppol odbiorcy jest nieprawidłowy. Należy sprawdzić numer rejestrowy lub OIN wpisany jako kontrahent.
• Problem techniczny po stronie odbiorcy: faktura została prawidłowo wysłana, ale nie mogła zostać przetworzona przez system odbiorcy.

Przy nieudanym dostarczeniu można ponownie wysłać fakturę, korygując EndpointID.

Pole dostawcy nie zawiera danych. Dzieje się tak, gdy organizacja nie została wybrana lub nie została aktywowana.

Rozwiązanie: kliknięcie ikony ołówka obok pola dostawcy i wybranie organizacji. Jeśli organizacja nie została jeszcze aktywowana, należy najpierw wykonać kroki opisane w artykule Dodawanie i aktywacja organizacji.

Numer VAT musi być wpisany bez spacji, kropek lub myślników, łącznie z kodem kraju. Prawidłowy format dla Holandii to NL123456789B01. Belgijskie numery VAT muszą być wpisane jako BE plus dokładnie 10 cyfr, bez separatorów.

Jeśli wpisana kwota znika przy przejściu do następnego kroku, pole prawdopodobnie zawiera niedozwolone znaki. Pole kwoty akceptuje wyłącznie cyfry z przecinkiem jako separatorem dziesiętnym. Kwoty należy wpisywać jako 100,00, nie jako € 100,00 ani 100.00.

Warianty wyszukiwania: "czerwona ikona stop wysyłanie", "czerwone kółko wysyłanie", "faktury nie można wysłać", "wysyłanie się nie udaje", "ikona stop faktura", "notatka faktury wymagana", "IBAN konto bankowe wymagane", "więcej informacji notatka faktury", "dane płatności IBAN puste", "pola wymagane wysyłanie faktury".

Przy wysyłaniu ręcznej faktury sprzedaży może pojawić się czerwona ikona stop: faktura nie zostaje wysłana. Przyczyną jest walidacja formularza po stronie klienta -- nie jest to błąd Peppol ani sieciowy, ani wada platformy. Dłużnik/OIN, dostępność Peppol i numer zamówienia mogą być już poprawne, a mimo to wysyłanie kończy się niepowodzeniem, ponieważ inne wymagane pole pozostało puste.

Sprawdź te dwa pola:

1. Notatka faktury (sekcja Więcej informacji) -- wpisz krótką notatkę lub referencję, np. numer zamówienia lub referencję uzgodnioną z odbiorcą.
2. IBAN konto bankowe (sekcja Dane płatności) -- wpisz IBAN, na który ma wpłynąć płatność, w razie potrzeby przez Zmień. IBAN na poziomie organizacji jest opcjonalny, ale puste pole IBAN na samej fakturze może mimo to blokować wysyłkę.

Różnica względem innych blokad:

• Przycisk wysyłania nie reaguje lub pokazuje symbole zastępcze: zob. "Przycisk wysyłania Peppol nie reaguje" poniżej (automatyczne tłumaczenie przeglądarki).
• Faktura pozostaje w wersjach roboczych: zob. odpowiednią sekcję (ustawienie organizacji lub brak "Wyślij przez").

Wysyłanie nadal się nie udaje po uzupełnieniu obu pól? Poproś o zrzut ekranu z dokładnym komunikatem błędu, a nie tylko z ikoną stop.

Warianty wyszukiwania: "numer rachunku bankowego niepoprawnie sformatowany", "rachunek bankowy niepoprawnie sformatowany", "IBAN niepoprawnie sformatowany", "błąd formatu IBAN", "spacje w IBAN", "formatowanie IBAN dane płatności", "błąd IBAN przy wysyłaniu faktury ręcznej".

Przy wysyłaniu ręcznej faktury sprzedaży może pojawić się komunikat, że numer rachunku bankowego lub IBAN nie jest poprawnie sformatowany, nawet jeśli numer jest merytorycznie poprawny. Przyczyną jest walidacja formatu przed wysłaniem dla IBAN lub rachunku bankowego w sekcji Dane płatności -- nie jest to błąd Peppol ani sieciowy. Spacje, myślniki lub inne separatory (albo brak kodu kraju) powodują, że kontrola kończy się niepowodzeniem.

Rozwiązanie:

1. Otwórz fakturę i przejdź do Dane płatności (IBAN lub rachunek bankowy).
2. Wpisz pełny IBAN jako jeden ciąg znaków: kod kraju plus cyfry/litery, bez spacji, myślników ani innych separatorów (forma: NL00BANK0123456789).
3. Nie używaj starego numeru rachunku bez kodu kraju -- niderlandzkie rachunki zaczynają się od NL.
4. Zapisz i wyślij fakturę ponownie.

Różnica względem innych blokad:

• Puste pole IBAN z czerwoną ikoną stop przy polach wymaganych -- zob. "Czerwona ikona stop przy wysyłaniu" powyżej.
• "ID niepoprawnie sformatowane" dotyczy formatu identyfikatora/schemeID, nie rachunku bankowego -- zob. sekcje o nieznanych błędach/walidacji identyfikatora powyżej.

Komunikat nadal się pojawia? Poproś o dokładną zawartość pola (w tym spacje lub znaki) oraz dosłowny komunikat błędu lub zrzut ekranu.

Warianty wyszukiwania: "przycisk wysyłania nie reaguje", "ekran ładowania zawiesza się przy wysyłaniu", "dziwny tekst na fakturze", "dziwna nazwa dostawcy", "nielogiczna jednostka na fakturze", "organizacja pokazuje dziwny tekst", "logowanie wielokrotnie w celu zapisania", "ponowne logowanie w celu wysłania", "pola faktury przetłumaczone", "tłumaczenie przeglądarki podczas tworzenia faktury", "nie mogę się zalogować", "dziwny tekst na stronie logowania".

Jeśli przycisk wysyłania nie reaguje lub ekran ładowania zawiesza się podczas wysyłania faktury Peppol i widoczna jest nieprzetłumaczona składnia szablonu, np. {{invoice.data.supplierDetails.name}} zamiast wprowadzonych wartości, przyczyną jest prawdopodobnie automatyczne tłumaczenie przeglądarki.

Ten sam wzorzec może wystąpić podczas tworzenia (nowej) faktury: nielogiczne lub "przetłumaczone" etykiety/wartości pol, m.in. dostawca, organizacja i jednostka, gdzie zapisanie lub wysłanie udaje się tylko po wielokrotnym ponownym zalogowaniu. Ma to tę samą przyczynę co symbole zastępcze na przycisku wysyłania -- nie jest to defekt produktu i nie jest powodem do ponownej instalacji oprogramowania klienckiego (platforma działa wyłącznie w przeglądarce).

To samo występuje na stronie logowania platform.econnect.eu i w innych miejscach interfejsu: teksty symboli zastępczych lub surowe klucze i18n (na przykład {{lang.text}} lub I18N_COLLABRR_WS.*) zamiast normalnych etykiet. Użytkownicy często zgłaszają to jako „nie mogę się zalogować”. Zobacz także Logowanie i 2FA.

Automatyczne tłumaczenie stron w przeglądarce (Chrome lub Edge) ingeruje w DOM platformy. Powoduje to nieprawidłowe działanie przycisków i sprawia, że symbole zastępcze szablonu lub i18n, albo nielogiczne etykiety pol, pozostają widoczne.

Rozwiązanie (kolejność pierwszej linii):

1. Wyłącz automatyczne tłumaczenie w przeglądarce dla platformy eConnect (w tym platform.econnect.eu).
2. Twarde odświeżenie (Ctrl+F5) i zaloguj się ponownie; ponownie otwórz lub utwórz fakturę, jeśli potrzebne.
3. Wciąż nie działa? Wyczyść pamięć podręczną przeglądarki i/lub wypróbuj inną przeglądarkę.
4. Problem się utrzymuje? Poproś o zrzut ekranu strony faktury wraz z przeglądarką i jej wersją.

Warianty wyszukiwania: "błąd przy wysyłaniu", "przerywany błąd portalu", "działa po ponownym uruchomieniu", "błąd wysyłania bez szczegółów", "komunikat błędu bez treści".

Czasami użytkownik zgłasza błąd przy wysyłaniu przez platformę, bez podania dokładnego tekstu błędu lub zrzutu ekranu. Bez tej treści nie ma wystarczających informacji do rzetelnej diagnozy; nie jest to znana szeroka awaria.

Możliwy pierwszy krok (nie potwierdzona przyczyna):

1. Wyczyść pamięć podręczną przeglądarki i/lub wypróbuj inną przeglądarkę.
2. Jeśli to nie pomoże, poproś o więcej kontekstu: dokładny komunikat błędu lub zrzut ekranu, godzinę i numer faktury.

Nie mylić z:

• Przycisk wysyłania nie reaguje, ekran ładowania zawiesza się, lub nielogiczne etykiety/symbole zastępcze -- zobacz "Przycisk wysyłania Peppol nie reaguje" wyżej (automatyczne tłumaczenie przeglądarki, z własną kolejnością pierwszej linii).
• Status SentRetry lub SentError po akceptacji -- zobacz sekcję o automatycznym ponownym doręczeniu Peppol dalej na tej stronie; to mechanizm ponownej próby po stronie serwera, nie problem z pamięcią podręczną przeglądarki.

Warianty wyszukiwania: „Proszę podać prawidłowy ID podmiotu dostawcy”, prawidłowy ID podmiotu dostawcy, ID podmiotu dostawcy, ID podmiotu dostawcy poprawny.

Ten komunikat dotyczy Dostawca / Party ID -- Twojego własnego identyfikatora organizacji na fakturze (standard NL: numer Izby Handlowej, 8 cyfr, schemat 0106), nie dłużnika. Przyczyną jest zazwyczaj puste lub nieprawidłowe wybranie Dostawcy, ręcznie wpisany tekst zamiast listy rozwijanej, lub identyfikator bez włączonej opcji Wysyłanie.

Rozwiązanie: kliknij ikonę ołówka przy Dostawca i wybierz ponownie swoją organizację z listy rozwijanej. Następnie sprawdź w Organizacje → Twoja organizacja → Szczegóły, że co najmniej jeden identyfikator ma włączoną opcję Wysyłanie. Zobacz też Party identifiers § Party ID.

Podwójny symptom (częsty przy administracji publicznej): czy ten komunikat pojawia się razem z „tylko e-mail” lub „Peppol niedostępny do wyboru” przy dłużniku publicznym? To dwie odrębne przyczyny jednego zagadnienia:

1. Dostawca/Party ID (własna organizacja) -- rozwiązanie jak wyżej.
2. Dłużnik publiczny niedostępny przez Peppol -- dla administracji publicznej NL, Wysyłaj przez musi być ustawione na OIN/OINO, a ID Organizacji musi być dokładnym 20-cyfrowym OIN, bez prefiksu 0190:. Brak opcji Peppol oznacza, że odbiorca korzysta z dostarczenia e-mail (nie awaria), nie używaj numeru Izby Handlowej. Zobacz „not available” przy wysyłaniu (testowym) do odbiorcy poniżej oraz „Fakturowanie do holenderskiej administracji publicznej” w bazie wiedzy.

Zapisz i ponownie Wyślij po poprawieniu obu punktów; Peppol powinien wtedy pojawić się dla dostępnego OIN.

Ten komunikat pojawia się, gdy ręcznie przesyłasz fakturę XML i w pliku brakuje pola EndpointID dostawcy. W interfejsie platformy jest to pole "Partij-ID" w sekcji "Dostawca".

Rozwiązanie: wybierz wartość z własnej organizacji z listy rozwijanej. Jeśli lista nie pokazuje właściwego wyniku, wybierz ponownie dostawcę, aby odświeżyć powiązanie.

Warianty wyszukiwania: „Nie znaleziono identyfikatorów aktywowanych do wysyłki dla firmy dostawcy”, identyfikatory aktywowane do wysyłki, „weryfikacja dostawcy jeszcze nie wykonana”, wysyłanie faktury nowa administracja, dwie organizacje z i bez sp. z o.o., identyfikatory niezweryfikowane.

Ten komunikat, oraz zgłaszane przez klienta „weryfikacja dostawcy jeszcze nie wykonana” przy pierwszej fakturze lub nowej administracji, zwykle nie wskazuje na osobny krok KYC dostawcy. Przyczyna niemal zawsze leży w jednym z tych czterech punktów.

Lista kontrolna (w kolejności):

1. Czy wybrano właściwą organizację dostawcy? Przy dwóch podobnych organizacjach (np. ta sama nazwa z i bez „sp. z o.o.”) mogła zostać wybrana niewłaściwa. Użyj ikony ołówka, aby wybrać organizację ze zweryfikowanymi identyfikatorami -- organizacja bez zweryfikowanych identyfikatorów nie może wysyłać.
2. Czy organizacja jest aktywowana? Jeszcze nie aktywowana: najpierw aktywuj przez Dodawanie i aktywacja organizacji.
3. Czy przełącznik „Wysyłanie” jest włączony? Przejdź do Organizacje → twoja organizacja → Szczegóły i sprawdź, czy co najmniej jeden identyfikator (najlepiej NIP/REGON) ma włączony przełącznik Wysyłanie. Dla aktywowanej organizacji zwykle jest to już włączone.
4. Czy numer VAT jest poprawny? Sprawdź numer VAT zarówno dostawcy, jak i dłużnika pod kątem kodu kraju i separatorów -- zob. BR-CO-09 powyżej. Błąd formatu VAT może wystąpić równocześnie z tym komunikatem.

Jeśli komunikat utrzymuje się po tych czterech krokach, wyślij fakturę ponownie po poprawieniu danych organizacji lub faktury.

Jeśli faktura nie może zostać wysłana i pozostaje w folderze "Wersje robocze", należy sprawdzić dwa elementy:

1. Wysyłanie włączone: sprawdzenie w ustawieniach organizacji, czy opcja "Wysyłanie dokumentów" jest aktywowana.
2. Wyślij przez ustawione: w sekcji "Kontrahent" obok OrganisatieID musi być wybrana opcja "Wyślij przez". Bez tego ustawienia faktura nie może zostać wysłana.

Warianty wyszukiwania: "faktura ERPx nie w skrzynce wychodzącej", "status przetwarzania dostawy eConnect", "sprawdzić dziennik Unit4 eConnect", "faktura z ERPx niewidoczna eConnect", "ERPx wysłane nic w eConnect", "dzienniki eConnect numer faktury ERPx", "Unit4 ERPx status przetwarzania dostawy", "faktura elektroniczna ERPx nie doszla eConnect".

Faktura elektroniczna utworzona w Unit4 ERPx nie trafia do skrzynki wychodzącej eConnect, podczas gdy dane kontrahenta w ERPx wyglądają poprawnie (metoda wysyłki e-faktura, format Peppol, wypełnione OIN/schemat). ERPx czasami wyświetla dla faktury status przetwarzania "w przetwarzaniu".

Kolejność pierwszej linii:

1. Poproś o numer faktury (plus data faktury, organizacja/administracja eConnect oraz ewentualny kod błędu lub znacznik czasu ERPx). Bez numeru faktury niemożliwe jest wiarygodne przeszukanie dziennika lub skrzynki wychodzącej.
2. Wyszukaj numer faktury w skrzynce wychodzącej (i wersjach roboczych) oraz w dziennikach eConnect.
   • Nie znaleziono w skrzynce wychodzącej i nie w dziennikach eConnect: dokument nie doszedł do eConnect. Odesłij klienta z powrotem do konsultanta ERPx/Unit4 -- przyczyna leży wtedy po stronie zgłoszenia lub konektora ERPx, nie u eConnect.
   • Znaleziono: postępuj według standardowej ścieżki statusu skrzynki wychodzącej na tej stronie (dostawa nieudana, wersja robocza, duplikat lub przetworzone poprawnie).
3. Przy w pełni wypełnionych danych kontrahenta bez dowodu dostarczenia nie zakładaj natychmiast problemu z dostępnością Peppol lub EndpointID kontrahenta. Decydujący jest dowod dostarczenia do eConnect (znalezienie numeru faktury w skrzynce wychodzącej lub dzienniku), nie stan danych kontrahenta.

Dokładne znaczenie statusu ERPx "w przetwarzaniu" w stosunku do dostarczenia do eConnect nie jest ustalonym faktem produktowym -- używaj tego statusu tylko jako sygnału od klienta, nie jako dowodu, że faktura już doszła do eConnect.

Platforma eConnect czasem używa prefiksu przestrzeni nazw w generowanych fakturach UBL (np. <urn:Invoice xmlns:urn="...">). Obie formy — z prefiksem i bez — są technicznie prawidłowym XML.

Odbiorca odrzucający faktury na podstawie prefiksu przestrzeni nazw nie jest zgodny z Peppol. Prefix przestrzeni nazw nie jest konfigurowalny dla poszczególnych odbiorców.

Komunikat do klienta: faktura jest technicznie prawidłowa. Odbiorca musi używać prawidłowego parsera XML obsługującego zarówno przestrzenie nazw z prefiksem, jak i domyślne. Odrzucenie na podstawie prefiksu przestrzeni nazw nie jest dozwolone w Peppol.

Kody błędów EBMS, takie jak EBMS:0003 i EBMS:0004, są błędami transportu AS4 w komunikacji między punktami dostępu. Klienci widzą SentError lub SentRetry na platformie — sam kod EBMS nie jest widoczny w interfejsie klienta.

Działanie: odesłanie klienta do TechSupport. TechSupport może zapoznać się ze szczegółami błędu przez ślad audytów i Application Insights.

Kod błędu status 40 oznacza, że dokument nie został pomyślnie przetworzony. Dwie możliwe przyczyny:

1. Błąd przetwarzania IDR: IDR nie może przetworzyć dokumentu i zwraca status 40.
2. Odrzucenie po stronie platformy: IDR przetworzył dokument, ale platforma następnie ustawia go na status 40 (np. z powodu błędu walidacji po konwersji).

Diagnostyka: pracownik eConnect musi zbadać w CloudWatch, jakie etapy przetwarzania przeszedł dokument.

Warianty wyszukiwania: "poprawić EndpointID wyślij ponownie", "faktura wysłana na błędny ID Peppol resend", "ID Peppol zmieniony odbiorca ponowna dostawa", "wyślij ponownie PeppolID", "faktura ponownie z innym PeppolID", "Wyślij ponownie Edytuj PeppolID", "wertykalny wielospój wyślij ponownie", "menu wiersza wyślij ponownie skrzynka wychodząca", "faktura Dostarczono klient nic nie widzi", "returnedMessageId odbiorca brakująca faktura".

Przez opcję Wyślij ponownie w skrzynce wychodzącej można ponownie przesłać już wysłaną fakturę. Przed faktycznym wysyłaniem można jeszcze zmienić pola takie jak referencja (numer zamówienia, OrderReference). Faktura zostaje wysłana ponownie z tym samym numerem faktury, ale z poprawną referencją.

Zgłoszenie przez AFAS / E-verbinding: jeśli dokument znajduje się już w skrzynce wychodzącej, ponowne wysłanie przez Wyśl ponownie na platformie jest właściwą drogą -- nie ponowne generowanie w AFAS lub E-verbinding. Jeśli ta czynność zwraca czerwony błąd zdarzenia aplikacji, najpierw sprawdź kombinację schemat/wartość identyfikatora odbiorcy (zobacz sekcję „Nieznany błąd podczas wywoływania zdarzenia aplikacji” powyżej). Jeśli dokument nie znajduje się jeszcze w skrzynce wychodzącej, przyczyna leży w kanale zgłaszania (ERP/E-verbinding) -- ponowne wysłanie nie ma w tym przypadku zastosowania.

Status Doręczono nie potwierdza, że odbiorca widzi fakturę w swojej księgowości. Technicznie Doręczono oznacza, że punkt dostępu dłużnika zaakceptował dokument. Jeśli dłużnik nadal zgłasza, że niczego nie otrzymał, przekaż klientowi returnedMessageId jako identyfikator referencyjny do zapytania u własnego dostawcy usług Peppol odbiorcy (zobacz sekcję „Status 'doręczono' ale odbiorca nie otrzymał faktury” poniżej).

To zalecane podejście, gdy odbiorca odrzuca fakturę z powodu błędnego numeru zamówienia lub innego błędu referencji. Pozwala uniknąć konieczności wystawiania korekty i nowej faktury.

W aktualnym standardzie Peppol BIS Billing 3.0 i NLCIUS obsługiwana jest tylko 1 referencja zamówienia (OrderReference) na fakturę. Jest to ograniczenie wynikające z normy europejskiej EN 16931. Jeśli faktura obejmuje kilka zamówień, dostawca musi wysyłać osobne faktury.

AdditionalDocumentReference może zawierać dodatkowe referencje innych typów (projekt, umowa lub referencja nabywcy), ale nie wiele OrderReference.

Przyszłość: Znowelizowana EN 16931-1:2026 (formalnie zatwierdzona przez CEN 13 marca 2026) dodaje obsługę wielu zamówień na fakturę. Oczekuje się, że zostanie to uwzględnione w przyszłej wersji standardu Peppol (możliwie BIS Billing 4.0). Do tego czasu obowiązuje aktualne ograniczenie 1 OrderReference na fakturę w BIS Billing 3.0 i NLCIUS.

Warianty wyszukiwania: "OrderReferentieNummer", "KopersReferentieNummer", "OrderReferentieNummer vs KopersReferentieNummer", "zamówienia niepowiązane w ERPx", "PO tylko w BuyerReference".

Jeśli faktura zostaje odrzucona z powodu brakującego lub nieznanego numeru zamówienia, należy rozróżnić dwa poziomy.

1. Referencja jest obowiązkowa zgodnie z EN 16931. Referencja -- numer zamówienia lub inna referencja (BuyerReference, referencja umowy lub projektu) -- jest wymagana. Faktura bez żadnej referencji nie spełnia podstawowych reguł normy.

2. eConnect domyślnie nie odrzuca na podstawie treści referencji. Jedyną sytuacją, w której platforma odrzuca na tym punkcie, jest brak jakiejkolwiek referencji.

3. Konfiguracja specyficzna dla klienta może być bardziej rygorystyczna. Rzeczywiste odrzucenie zależy od konfiguracji odbiorcy. W określonej konfiguracji faktura może zostać odrzucona, jeśli referencja jest nieznana u tego odbiorcy. Jest to zależne od konfiguracji i nie jest standardowym zachowaniem platformy eConnect.

Nazwy pól platformy, nie mylić. Na platformie BT-13 (OrderReference/ID) nazywa się OrderReferentieNummer, a BT-10 (BuyerReference) KopersReferentieNummer. Dla dopasowania zamówień ERP (np. Unit4 ERPx) numer zamówienia zakupu powinien znaleźć się w OrderReferentieNummer -- KopersReferentieNummer to własna referencja nabywcy i nie zastępuje dopasowania PO. Faktura może być zgodna z EN 16931 z wypełnionym tylko KopersReferentieNummer (norma wymaga co najmniej jednego z obu pól), a dopasowanie zamówienia w ERP może mimo to nie powiodło się: zgodność z EN nie równa się udanemu dopasowaniu zamówienia. Jeśli wartość PO trafiła przez pomyłkę tylko do KopersReferentieNummer, poproś dostawcę o przeniesienie jej do OrderReferentieNummer; KopersReferentieNummer może pozostać wypełnione dodatkowo.

Działanie:

• Wyślij fakturę ponownie za pomocą opcji Wyślij ponownie (patrz powyższa sekcja) z prawidłową referencją.
• Jeśli numer zamówienia jest nieznany, skontaktuj się z odbiorcą w sprawie pożądanej procedury.

Faktura ze stanem końcowym InvoiceSentError (po błędzie walidacji 4xx) nie podejmuje więcej prób dostarczenia. Tylko błędy 5xx są ponawiane (maksymalnie 8 prób, około 35 godzin). W przypadku błędu 4xx podejmowana jest tylko jedna próba; nic więcej nie jest wysyłane do odbiorcy.

Nie ma punktu końcowego DELETE dla faktur sprzedaży (salesInvoice). Wysłana lub odrzucona faktura sprzedaży jest zdarzeniem istotnym dla audytu i pozostaje dostępna w ścieżce audytu przez 90 dni. Jeśli faktura była nieprawidłowa, wystaw notę kredytową lub fakturę korygującą zgodnie ze standardowym przepływem księgowym.

Błędy walidacji takie jak TaxInclusiveAmount '-1.336061E6' nie jest prawidłowym xs:decimal występują, ponieważ system źródłowy serializuje kwotę numeryczną w notacji naukowej (np. -1.336061E6 dla -1 336 061,00). Pola kwoty UBL są typu xs:decimal, który nie zezwala na notację E.

Częsta przyczyna: system źródłowy przechowuje kwoty wewnętrznie jako double/float i używa domyślnej konwersji łańcucha, która automatycznie przełącza się na notację wykładniczą dla bardzo dużych lub bardzo małych wartości.

Rozwiązanie po stronie klienta: zaktualizować system źródłowy, aby kwoty były zawsze zapisywane jako zwykły łańcuch dziesiętny (np. za pomocą typów decimal/BigDecimal lub wzorca dziesiętnego niezależnego od ustawień regionalnych, bez separatorów tysięcy i bez notacji E).

Po stronie eConnect: nie można poprawić automatycznie -- wartość jest już nieprawidłowa w dostarczonym XML. Skierować do dostawcy pakietu oprogramowania.

Status Doręczono oznacza, że odbierający punkt dostępu (dostawca usług Peppol dłużnika) technicznie zaakceptował dokument i potwierdził tę akceptację. eConnect otrzymuje returnedMessageId (format GUID@econnect.eu): dowód, że faktura dotarła do punktu dostępu odbiorcy.

Jeśli dłużnik twierdzi, że nie otrzymał faktury, podczas gdy status pokazuje 'Doręczono', dokument został doręczony do punktu dostępu dłużnika, ale nie jest jeszcze widoczny w jego własnym oprogramowaniu lub księgowości. Jest to problem dalszego przetwarzania po stronie odbiorcy.

Kroki do rozwiązania:

1. Potwierdzić klientowi, że faktura została pomyślnie wysłana do punktu dostępu Peppol dłużnika oraz że eConnect otrzymał potwierdzenie doręczenia.
2. Doradzić klientowi, aby poprosił dłużnika o kontakt z jego własnym dostawcą usług Peppol. Można przekazać returnedMessageId: za pomocą tego identyfikatora odbierający punkt dostępu może zlokalizować dokument.
3. Dalsze działania leżą po stronie punktu dostępu dłużnika; eConnect jako strona wysyłająca nie ma wglądu poza punkt doręczenia.

Warianty wyszukiwania: „dodaj organizację” przy fakturze, portal dostawcy, nazwa organizacji + numer KRS w prawym górnym rogu, nie można edytować istniejącego wiersza organizacji, nie można zmienić nazwy istniejącej organizacji, zrzut ekranu organizacji klienta w prawym górnym rogu, komunikat o identyfikatorze przy dodawaniu organizacji (dostawca), dodaj własną organizację osobno, dłużnik jako własna organizacja, dodaj odbiorcę faktury do środowiska, aktywuj organizację dłużnika administracji publicznej, odbiorca musi być w środowisku, rejestracja pod własnym OIN gminy, OIN klienta jako własna organizacja, fakturowanie gminy z własnym OIN, OIN odbiorcy to nie własny identyfikator, schemat 0190 dłużnik.

Nowi użytkownicy -- zwłaszcza przechodzący z innych usług e-fakturowania -- czasami próbują dodać organizację odbierającą jako własną organizację na platformie podczas wysyłania faktury. Nie jest to konieczne i powoduje komunikat o błędzie.

Aby wysłać fakturę do odbiorcy, ta organizacja nie musi znajdować się na własnym koncie: podczas tworzenia faktury wybieram odbiorcę za pomocą pola wyszukiwania dłużnika. Można szukać po numerze KRS, nazwie firmy lub numerze OIN.

Warianty wyszukiwania: „nie znaleziono organizacji”, „nie znaleziono organizacji Francja”, „odbiorca nie został znaleziony po nazwie”, „wyszukiwanie dłużnika nie działa”, „wyszukiwanie po nazwie dłużnika”, „nie można wyszukać po ID Peppol”, „faktura przez GLN”, „ręczne wprowadzenie dłużnika”, „baza firm to nie Peppol”, „zagraniczny odbiorca nie w wynikach wyszukiwania”, „organizacja niewybieralna”, „wyszukiwanie VAT FR faktura wersja robocza”, „wyszukiwanie VAT FR puste”, „0225 SIREN Wysyłaj przez”, „OrganisationID SIREN”.

Istota: wyszukiwanie dłużnika po nazwie przeszukuje bazę firm (rejestr przedsiębiorców itp.), nie Peppol. Komunikat „nie znaleziono organizacji” przy nazwie organizacji lub francuskim numerze VAT nie znaczy więc, że odbiorca nie jest zarejestrowany w Peppol, ani że wyszukiwanie po ID Peppol jest niemożliwe -- nie mówi niczego o statusie online/offline odbiorcy w Peppol.

Rozwiązanie:

1. Dłużnik nie został znaleziony w bazie firm? Wprowadź dłużnika ręcznie, podając dane odbiorcy (nazwa, adres, kraj, identyfikator).
2. Czy identyfikator Peppol odbiorcy jest znany?
   • Najczęściej GLN (schemat 0088, etykiety GS1/EAN): ustaw Wysyłaj przez na GLN i wprowadź w OrganisationID tylko cyfry, bez prefiksu 0088: (zob. ogólną zasadę samych cyfr powyżej przy formatowaniu identyfikatorów).
   • Francja / CTC: ustaw Wysyłaj przez na 0225 (SIREN/FR CTC) i wprowadź w OrganisationID tylko wartość SIREN, bez prefiksu 0225: (czyste 9 cyfr, lub rozszerzony format SIREN_SUFFIX/SIREN_SIRET). Nie wprowadzaj tutaj francuskiego numeru VAT -- to osobny schemat (9957). Zob. Party identifiers.
3. Nie twórz odbiorcy przez Dodaj organizację -- ta funkcja służy do własnej organizacji, nie do odbiorcy faktury (zob. sekcję „Pomylenie: próba dodania organizacji odbiorcy jako własnej organizacji” powyżej).
4. Klient podal endpoint, ale jest nieosiągalny? Najpierw potwierdź format schematu/wartości; jeśli okaże się, że odbiorca nie ma jeszcze aktywnej rejestracji odbioru, francuski odbiorca musi zakończyć rejestrację 0225, zanim testowa faktura zostanie wysłana z sukcesem.

Komunikat o błędzie pojawia się nadal i nie jest opisany powyżej? Skontaktuj się przez support.econnect.eu.

• Tworzenie i wysyłanie faktury
• Ponowne wysłanie faktury
• Wysyłanie faktury korygującej (credit note)