BT-3Invoice type code
Oficjalna treść reguły
[BR-DE-17] Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) and 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).
Tekst normatywny jest w języku angielskim i cytowany bez zmian.
Dlaczego pojawia się ten błąd
XRechnung zawęża listę UNTDID 1001: w BT-3 należy używać wyłącznie kodów 326 (faktura częściowa), 380 (faktura handlowa), 384 (faktura skorygowana), 389 (samofakturowanie), 381 (nota kredytowa) oraz 875, 876 i 877 (faktury budowlane). Reguła porównuje cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode (UBL) lub rsm:ExchangedDocument/ram:TypeCode (CII) z tą listą i w przeciwnym razie zgłasza ostrzeżenie. Typowe przypadki to 386 (faktura zaliczkowa), 383 (nota obciążeniowa) lub 82 (usługi rozliczane według pomiaru), które są poprawne w EN 16931, ale nie są oczekiwane przez niemieckie urzędy.
Jak to naprawić
Przypisz swoje typy dokumentów do dozwolonych kodów: zwykła faktura 380, faktura częściowa/ratalna 326, korekta 384, nota kredytowa 381 (jako cn:CreditNote w UBL), samofakturowanie 389, faktury budowlane częściowa/częściowo-końcowa/końcowa 875/876/877. Żądanie zaliczki wysyła się zwykle jako 380 lub 326 z informacją o przedpłacie w opisie pozycji; faktura końcowa wykazuje następnie już zapłacone kwoty w BT-113 (kwota przedpłacona). To ostrzeżenie, ale wielu odbiorców traktuje je jako błąd.
Przykład (poprawny)
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>Co sprawdza walidator
Sprawdzany element (kontekst):
UBL
/ubl:Invoice | /cn:CreditNoteTest (XPath):
normalize-space(cbc:InvoiceTypeCode) = $supportedInvAndCNTypeCodes or normalize-space(cbc:CreditNoteTypeCode) = $supportedInvAndCNTypeCodesCII
/rsm:CrossIndustryInvoiceTest (XPath):
normalize-space(rsm:ExchangedDocument/ram:TypeCode) = ('326', '380', '384', '389', '381', '875', '876', '877')Sprawdź swoją fakturę
Upuść plik XML lub PDF w walidatorze; każda naruszona reguła ma link do swojej strony tutaj. Bezpłatnie, bez konta, plik nie jest zapisywany.
To samo sprawdzenie przez API:
curl -F file=@invoice.xml https://einvoicechecker.com/v1/validatePowiązane reguły
BR-DE-26Faktura skorygowana (384) bez odwołania do faktury pierwotnejBR-DE-1Brak instrukcji płatności (BG-16)BR-DE-2Brak danych kontaktowych sprzedawcy (BG-6)BR-DE-3Brak miejscowości sprzedawcy (BT-37)BR-DE-4Element „Kod pocztowy sprzedawcy” musi zostać przekazanyBR-DE-5Brak osoby kontaktowej sprzedawcy (BT-41)BR-DE-6Brak numeru telefonu kontaktowego sprzedawcy (BT-42)BR-DE-7Brak adresu e-mail kontaktowego sprzedawcy (BT-43)
Najczęstsze pytania
Co oznacza BR-DE-17?
BR-DE-17 to reguła xrechnung: Only the following codes from the code list UNTDID 1001 shall be transmitted in the element "Invoice type code" (BT-3): 326 (Partial invoice), 380 (Commercial invoice), 384 (Corrected invoice), 389 (Self-billed invoice) and 381 (Credit note), 875 (Partial construction invoice), 876 (Partial final construction invoice), 877 (Final construction invoice).
Czy moja faktura zostanie odrzucona z powodu BR-DE-17?
Nie. BR-DE-17 to ostrzeżenie: faktura jest przyjmowana, ale odbiorca widzi uwagę. Mimo to popraw ją, ostrzeżenia często stają się błędami w kolejnych wersjach reguł.
Jakich formatów dotyczy BR-DE-17?
XRechnung w składni UBL lub CII, w tym PDF ZUGFeRD / Factur-X z profilem XRECHNUNG. Faktury dla niemieckich instytucji publicznych muszą ją spełniać. Składnia: UBL i CII.
Źródło: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Katalog wygenerowany z oficjalnych zestawów reguł dnia 2026-10-15.