BT-3Invoice type code
Officiële regeltekst
[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).
De normatieve tekst is Engels en wordt ongewijzigd geciteerd.
Waarom deze fout optreedt
XRechnung beperkt de lijst UNTDID 1001: in BT-3 horen alleen 326 (deelfactuur), 380 (handelsfactuur), 384 (gecorrigeerde factuur), 389 (self-billing factuur), 381 (creditnota), 875, 876 en 877 (bouwfacturen) te worden gebruikt. De regel vergelijkt cbc:InvoiceTypeCode / cbc:CreditNoteTypeCode (UBL) of rsm:ExchangedDocument/ram:TypeCode (CII) met die lijst en geeft anders een waarschuwing. Typische boosdoeners zijn 386 (vooruitbetalingsfactuur), 383 (debetnota) of 82 (gemeten diensten), die geldig zijn in EN 16931 maar niet worden verwacht door Duitse overheden.
Zo lost u het op
Koppel uw documenttypen aan de toegestane codes: gewone factuur 380, deel- of termijnfactuur 326, correctie 384, creditnota 381 (als cn:CreditNote in UBL), self-billing 389, bouwdeelfactuur/deel-eindfactuur/eindfactuur 875/876/877. Een verzoek om aanbetaling wordt normaal als 380 of 326 verstuurd met de vooruitbetaling in de regeltekst; de eindfactuur gebruikt dan BT-113 (vooruitbetaald bedrag) voor de reeds betaalde bedragen. Dit is een waarschuwing, maar veel ontvangers behandelen het als fout.
Voorbeeld (geldig)
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>Wat de validator controleert
Gecontroleerd element (context):
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')Controleer uw factuur
Sleep uw XML of PDF naar de validator; elke overtreden regel linkt naar zijn pagina hier. Gratis, zonder account, het bestand wordt niet opgeslagen.
Dezelfde controle via API:
curl -F file=@invoice.xml https://einvoicechecker.com/v1/validateGerelateerde regels
BR-DE-26Gecorrigeerde factuur (384) zonder verwijzing naar eerdere factuurBR-DE-1Betalingsinstructies (BG-16) ontbrekenBR-DE-2Contactgegevens van de verkoper (BG-6) ontbrekenBR-DE-3Plaats van de verkoper (BT-37) ontbreektBR-DE-4Het element "Postcode verkoper" moet worden verstrektBR-DE-5Contactpunt van de verkoper (BT-41) ontbreektBR-DE-6Telefoonnummer van de verkoper (BT-42) ontbreektBR-DE-7E-mailadres van de verkoper (BT-43) ontbreekt
Veelgestelde vragen
Wat betekent BR-DE-17?
BR-DE-17 is een xrechnung-regel: 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).
Wordt mijn factuur geweigerd vanwege BR-DE-17?
Nee. BR-DE-17 is een waarschuwing: de factuur wordt geaccepteerd maar de ontvanger ziet de melding. Los het toch op, waarschuwingen worden in latere regelversies vaak fouten.
Voor welke formaten geldt BR-DE-17?
XRechnung in UBL- of CII-syntax, inclusief ZUGFeRD / Factur-X-PDF's met het profiel XRECHNUNG. Facturen aan Duitse overheden moeten eraan voldoen. Syntax: UBL en CII.
Bron: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Catalogus gegenereerd uit de officiële regelsets op 2026-10-15.