Anforderungen an die Rechnungsstellung (E-Invoices)
1. Verbindliches Format und Übermittlungsweg
Verbindlicher technischer Standard: Rechnungen sind zwingend als elektronische Rechnung (E-Invoice) im Format ZUGFeRD 2.1 / Factur-X 1.0.05, Profil BASIC auszustellen. Das Profil ist konform zur EU-Norm EN 16931. XRechnung 3.0 (EN-16931-konform) ist ebenfalls erlaubt.
Übermittlungskanal – E-Mail: Die Rechnung ist als reine XML-Datei (XRechnung) oder als ZUGFeRD-Datei (PDF/A-3 mit eingebettetem XML) per E-Mail an die zuständige Adresse zu senden:
Niederlande: Invoice.byfile@conrad.nl
Deutschland: Invoice.byfile@conrad.de
Übermittlungskanal – SFTP: Alternativ zur E-Mail können Rechnungen über den Conrad-SFTP-Server übermittelt werden (Details siehe angehängte Guideline Public Key - SFTP.pdf):
Host: pds1.conrad.com, Port: 8022
Protokoll: ausschließlich SFTP (Zugriff via SSH/SCP nicht möglich)
Authentifizierung: SSH-Public-Key-Verfahren, kein Passwort. Zulässige Schlüsseltypen: RSA, DSA oder ECDSA (empfohlen RSA 4096 Bit, ohne Passphrase)
Schlüsselpaar erzeugen: Windows via WinSCP/PuTTYgen, Linux via ssh-keygen -b 4096. Nur den Public Key an Conrad senden – der Private Key darf das eigene System nie verlassen
Public Key anfragen über supplier.edi@conrad.de oder support.edi@conrad.de (je nach Thematik); Conrad legt damit ein Freigabe-Ticket beim Netzwerkteam an
BenutzerID: entspricht der SAP-Lieferantennummer mit vorangestelltem „S", z. B. S96101321. Anmeldung: sftp -P 8022 <BenutzerID>@pds1.conrad.com
Dateiname: frei wählbar; erforderlich ist nur eine konstante Dateiendung (üblich .txt oder .edi)
Ordner in = an Conrad zu sendende Dateien; Ordner out = von Conrad bereitgestellte Dateien
Upload zuerst mit Endung .tmp, nach vollständiger Übertragung in den Zielnamen umbenennen (so verarbeitet Conrad nur vollständige Dateien); Dateien älter als 5 Tage werden automatisch gelöscht
Ausschluss anderer Formate: Rechnungen in abweichenden Formaten (z. B. einfaches PDF) oder über andere Kanäle gelten als nicht ordnungsgemäß und werden zurückgewiesen.
Referenz für die Umsetzung: Verbindliche und alleinige Referenz für die vereinbarte Struktur ist die beigefügte Spezifikation ZUGFeRD_2.1_FacturX_1.0.05_Basic_Struktur.pdf (Pflichtfelder gemäß EN 16931, zulässige USt-Kategorien, vollständige Beispiel-XML).
2. Zulässige Umsatzsteuer-Kategorien (VAT)
Die XML-Kategorie-Codes sind durch die EN 16931-Norm standardisiert (Codeliste UNCL 5305). Der Kategoriecode wird im Feld <ram:CategoryCode> gesetzt, der Steuersatz im Feld <ram:RateApplicablePercent>. Einen eigenen Code für den ermäßigten Satz gibt es nicht — Standard- und ermäßigter Satz laufen beide als Kategorie S, unterschieden nur über den Prozentwert.
Die Kategorie ist länderunabhängig (S = steuerpflichtig, AE = Reverse Charge); nur der Prozentsatz richtet sich nach dem Land des steuerbaren Umsatzes.
| Land | Sachverhalt | CategoryCode | RateApplicablePercent |
|---|---|---|---|
NL | Standardtarief | S | 21.0 |
NL | Verlaagd tarief (ermäßigt) | S | 9.0 |
DE | Regelsteuersatz | S | 19.0 |
DE | ermäßigter Satz | S | 7.0 |
NL / DE | Reverse Charge / verlegging | AE | 0.0 (USt-IdNr. des Käufers erforderlich) |
Im OCFA-Warengeschäft (Elektronik) gilt im Regelfall der Standardsatz (NL 21 %, DE 19 %); der ermäßigte Satz (NL 9 %, DE 7 %) nur für explizit ermäßigt besteuerte Waren.
Hinweis: „Kategorie R" existiert in EN 16931 nicht (Beleg wird abgelehnt) — ermäßigt = S mit dem jeweiligen Landessatz. Kategorie E entfällt, da im OCFA-Warengeschäft keine steuerbefreiten Umsätze vorkommen.
3. Technische Zuordnung wichtiger Rechnungsfelder (Mapping)
Für die automatisierte Verarbeitung sind die folgenden Felder im XML wie angegeben abzubilden. Grundlage sind die Strukturtabelle und die Beispiel-XML der Spezifikation ZUGFeRD_2.1_FacturX_1.0.05_Basic_Struktur.pdf.
Rechnungskopf
Rechnungsnummer (BT-1): Feld <ram:ID> unterhalb von <rsm:ExchangedDocument>.
Rechnungstyp (BT-3): Feld <ram:TypeCode> unterhalb von <rsm:ExchangedDocument> – Wert 380 (Handelsrechnung).
Rechnungsdatum (BT-2): Feld <udt:DateTimeString> in <ram:IssueDateTime> (Attribut format="102", z. B. 20260527).
Rechnungsposition
Positionsnummer (BT-126): Feld <ram:LineID> in <ram:AssociatedDocumentLineDocument>.
Artikelnummer des Lieferanten (BT-155): Feld <ram:SellerAssignedID> in <ram:SpecifiedTradeProduct>.
Artikelname (BT-153): Feld <ram:Name> in <ram:SpecifiedTradeProduct>.
Bruttopreis (BT-148): Feld <ram:ChargeAmount> in <ram:GrossPriceProductTradePrice>.
Nettopreis (BT-146): Feld <ram:ChargeAmount> in <ram:NetPriceProductTradePrice>.
Menge (BT-129): Feld <ram:BilledQuantity> in <ram:SpecifiedLineTradeDelivery> (Attribut unitCode, z. B. C62 = Stück).
USt-Kategorie / USt-Satz je Position (BT-151 / BT-152): Felder <ram:CategoryCode> und <ram:RateApplicablePercent> in <ram:ApplicableTradeTax>.
Positions-Nettobetrag (BT-131): Feld <ram:LineTotalAmount> in <ram:SpecifiedTradeSettlementLineMonetarySummation>.
Verkäufer / Käufer
Lieferantennummer, von Conrad zugewiesen (BT-29): Feld <ram:ID> in <ram:SellerTradeParty>.
USt-IdNr. des Verkäufers (BT-31): Feld <ram:ID> mit schemeID="VA" in <ram:SellerTradeParty>/<ram:SpecifiedTaxRegistration>.
USt-IdNr. des Käufers (BT-48): Feld <ram:ID> mit schemeID="VA" in <ram:BuyerTradeParty>/<ram:SpecifiedTaxRegistration> – zwingend bei Reverse Charge (AE).
Referenzen
Käufer-Referenz (BT-10): Feld <ram:BuyerReference>.
Zu finden im Feld “references.order_reference_for_customer” (Mirakl)
Bestellnummer (BT-13): Feld <ram:IssuerAssignedID> in <ram:BuyerOrderReferencedDocument>.
Zu finden im Feld “commercial_id” (Mirakl)
Lieferung
Lieferdatum (BT-72): Feld <udt:DateTimeString> in <ram:ActualDeliverySupplyChainEvent>/<ram:OccurrenceDateTime> (Attribut format="102").
Lieferavis / Tracking-ID, DESADV (BT-16): Feld <ram:IssuerAssignedID> in <ram:DespatchAdviceReferencedDocument>.
Zahlung & Steuer
Rechnungswährung (BT-5): Feld <ram:InvoiceCurrencyCode> – auf EUR einzustellen.
Zahlungsart (BT-81): Feld <ram:TypeCode> in <ram:SpecifiedTradeSettlementPaymentMeans> – Wert 30 (Überweisung).
Zahlungskonto IBAN (BT-84): Feld <ram:IBANID> in <ram:PayeePartyCreditorFinancialAccount>.
BIC (BT-86): Feld <ram:BICID> in <ram:PayeeSpecifiedCreditorFinancialInstitution>.
USt-Aufschlüsselung Beleg (BT-116 bis BT-119): Felder <ram:BasisAmount>, <ram:CalculatedAmount>, <ram:CategoryCode>, <ram:RateApplicablePercent> in <ram:ApplicableTradeTax> (unter <ram:ApplicableHeaderTradeSettlement>).
Zahlungsbedingungen (BT-20): Feld <ram:SpecifiedTradePaymentTerms>/<ram:Description>. Hier wird auch die Skonto-Logik als definiertes Textmuster übergeben (Beispiel: #SKONTO#TAGE=14#PROZENT=3.00#).
Fälligkeitsdatum (BT-9): Feld <ram:SpecifiedTradePaymentTerms>/<ram:DueDateDateTime>.
Belegsummen
Summe Positions-Nettobeträge (BT-106): Feld <ram:LineTotalAmount> in <ram:SpecifiedTradeSettlementHeaderMonetarySummation>.
Summe Zuschläge / Abschläge (BT-108 / BT-107): Felder <ram:ChargeTotalAmount> / <ram:AllowanceTotalAmount>.
Gesamtbetrag ohne USt (BT-109): Feld <ram:TaxBasisTotalAmount>.
USt-Gesamtbetrag (BT-110): Feld <ram:TaxTotalAmount> (Attribut currencyID).
Gesamtbetrag inkl. USt (BT-112): Feld <ram:GrandTotalAmount>.
Vorausgezahlter Betrag (BT-113): Feld <ram:TotalPrepaidAmount>.
Fälliger Zahlbetrag (BT-115): Feld <ram:DuePayableAmount>.
Buchungsreferenz des Käufers (BT-19): Feld <ram:ID> in <ram:ReceivableSpecifiedTradeAccountingAccount>.
4. Struktur und Zeitpunkt der Abrechnung
Einzelabrechnung: Jede Bestellung, die über die Plattformschnittstelle getätigt wird, ist einzeln und separat nach der jeweiligen Bestellnummer abzurechnen. Jede Rechnung referenziert dazu genau eine Bestellnummer im Feld <ram:IssuerAssignedID> in <ram:BuyerOrderReferencedDocument> (BT-13). Sammelrechnungen über mehrere Bestellungen sind unzulässig.
Rechnungstyp und Währung: Es sind ausschließlich Handelsrechnungen zu übermitteln – <ram:TypeCode> = 380 (BT-3). Gutschriften (Code 381) sind unzulässig (siehe Abschnitt 6). Die Rechnungswährung ist fest EUR – <ram:InvoiceCurrencyCode> (BT-5).
Zeitpunkt: Die Übermittlung der Rechnung hat unverzüglich nach dem physischen Warenversand zu erfolgen. Das Rechnungsdatum (BT-2) darf nicht vor dem Versand-/Lieferdatum (BT-72) liegen.
Übereinstimmung: Rechnungen und Lieferscheine müssen formal und inhaltlich exakt übereinstimmen. Der Bezug wird technisch über die Lieferavis-/DESADV-Referenz <ram:DespatchAdviceReferencedDocument>/<ram:IssuerAssignedID> (BT-16) und das Lieferdatum <ram:ActualDeliverySupplyChainEvent> (BT-72) hergestellt.
Für Version 2 - wird nachgereicht:
Teillieferungen: Jede Teillieferung ist separat abzurechnen und in der Rechnung als Teillieferung zu kennzeichnen (vgl. Abschnitt 5). Zu klären: Wird die Kennzeichnung im Freitext <ram:IncludedNote> (BT-22) oder in einem definierten Feld erwartet?
5. Zwingende Rechnungsinhalte
Neben den gesetzlichen Pflichtangaben (insbesondere für den Vorsteuerabzug) muss die Rechnung folgende spezifische Daten enthalten (in Klammern das jeweilige XML-Feld):
Von Conrad zugewiesene Lieferantennummer (ram:SellerTradeParty/ram:ID, BT-29).
Versendungsart (z. B. Paketdienst oder Spedition) – als Freitext in ram:IncludedNote/ram:Content (BT-22).
Tracking-ID der Lieferung (DESADV) (ram:DespatchAdviceReferencedDocument/ram:IssuerAssignedID, BT-16).
Lieferscheindaten:
Bestellnummer (ram:BuyerOrderReferencedDocument/ram:IssuerAssignedID, BT-13) und Bestelldatum;
Artikelnummer (ram:SellerAssignedID, BT-155) und Stückzahl (ram:BilledQuantity, BT-129);
herstellerseitige Seriennummern (sowie ggf. IMEI-Nummern);
Ausstellungsdatum des Lieferscheins;
im Fall von Teillieferungen eine entsprechende Kennzeichnung.
Urheberrechtsabgaben: Bei abgabepflichtigen Geräten/Speichermedien sind die genaue Höhe der Abgabe (als Zuschlag ram:SpecifiedTradeAllowanceCharge, BT-141) und die zuständige Verwertungsgesellschaft (z. B. ZPÜ) transparent auszuweisen.
BT-141 ist nur verpflichtend, wenn es denn einen Zuschlag/Rabatt per BG-27, BG-28 gibt. Ansonsten kann es leer bleiben.
6. Wichtige Besonderheit: Verbot von Gutschriften
Lieferanten dürfen Conrad keine Gutschriften ausstellen, da diese aus technischen Gründen im System nicht verarbeitet werden können. Zulässig ist ausschließlich der Rechnungstyp ram:TypeCode = 380 (Handelsrechnung); der Code 381 (Gutschrift) wird zurückgewiesen.
Alle finanziellen Korrekturen (z. B. bei Retouren, Transportschäden, Fehlmengen oder falschen Urheberrechtsabgaben) werden ausschließlich über eine von Conrad an den Lieferanten ausgestellte Belastungsanzeige abgewickelt.
Wichtig bei Fehlern: Sind Rechnungen unvollständig oder fehlen zwingende Pflichtfelder der Spezifikation, hat Conrad daraus resultierende Verzögerungen bei Bearbeitung und Bezahlung nicht zu vertreten.
BASIC - Specification: ZUGFeRD_2.1_FacturX_1.0.05_Basic_Struktur.pdf
Die beigefügte Spezifikation ist die einzige Referenz für die vereinbarte Struktur – Pflichtfelder gemäß EN 16931, die geltenden Umsatzsteuerkategorien (siehe Abschnitt 2: S = steuerpflichtig mit Landessatz — DE 19 % / 7 %, NL 21 % / 9 %; AE = Reverse Charge 0 %) sowie eine vollständige Beispiel-XML-Datei.
Nur für die Niederlande
Information zu Nutzung des peppol Netzwerkes
Ergänzend zur Rechnungsübermittlung per E-Mail und SFTP ist die Übermittlung über das Peppol-Netz alternativ verfügbar. Peppol arbeitet im 4-Corner-Modell: Sender und Empfänger sind jeweils über zertifizierte Access Points angebunden, die Zustellung erfolgt über das Netz anhand der Participant-ID des Empfängers.
Feststehende Angaben
2.1 Conrad-Entities im Peppol-Netz (Stand Peppol Directory, 21.07.2026)
| Entity | Land | Participant-ID | Registrierte Dokumenttypen | Registriert seit |
|---|---|---|---|---|
Conrad Electronic Benelux BV | NL | 9944:nl007738213b01 | Invoice + CreditNote, jeweils in Peppol BIS Billing 3.0 und NLCIUS v1.0 | 29.01.2026 |
Conrad Electronic SE | DE | 9930:de131832937 | nur ApplicationResponse (MLR) – kein Invoice-Empfang | 10.03.2023 |
Conrad Electronic Italia SRL | IT | 0210:02778790218 | DespatchAdvice, Order – kein Invoice-Empfang | 17.05.2021 |
Wichtig: Rechnungen können derzeit ausschließlich an die niederländische Entity (9944:nl007738213b01) zugestellt werden. Die deutsche Participant-ID ist nur für MLR registriert und nimmt keine Rechnungen entgegen.
Gutschriften sind generell nicht erlaubt.
2.2 Produktiv und Test
Die Participant-ID bleibt identisch in Produktiv und Test. Unterschiedlich ist nicht die ID, sondern das Netz bzw. die SML, die der sendende Access Point abfragt:
Produktiv → Produktiv-SML
Test → Test-SML / SMK (acc.edelivery…)
Der Testversand wird über das Peppol-Testnetz (Test/SMK, nicht Produktiv) geroutet; die Empfänger-ID bleibt dabei unverändert.
2.3 Format
Syntax: UBL 2.1
Profil (NL): Peppol BIS Billing 3.0 oder NLCIUS v1.0 – beide sind für die NL-Entity registriert
Gutschriften: Für die NL-Entity ist CreditNote zwar technisch registriert, fachlich sind Gutschriften jedoch ausgeschlossen (siehe Abschnitt „Verbot von Gutschriften"). Es ist ausschließlich der Dokumenttyp Invoice zu verwenden.
Umsatzsteuer-Logik unverändert: Kategorie S (steuerpflichtig – NL 21 % / 9 %, DE 19 % / 7 %) bzw. AE (Reverse Charge, 0 %, USt-IdNr. des Käufers erforderlich).
Abgrenzung zu ZUGFeRD
Peppol nutzt UBL 2.1, ZUGFeRD nutzt CII (CrossIndustryInvoice). Beide sind EN-16931-konform, haben aber eine unterschiedliche XML-Struktur. Das Feld-Mapping der ZUGFeRD-Seite gilt für Peppol nicht und wird separat erstellt.
Übertragung über das Peppol-Netz via Access Points, nicht per E-Mail oder SFTP.
Peppol überträgt reines XML – kein PDF-Hybrid wie bei ZUGFeRD.