Anforderung an E-Invoices

Inhalt

• Anforderung an E-Invoices
  • Anforderungen an die Rechnungsstellung (E-Invoices)
    • 1. Verbindliches Format und Übermittlungsweg
    • 2. Zulässige Umsatzsteuer-Kategorien (VAT)
    • 3. Technische Zuordnung wichtiger Rechnungsfelder (Mapping)
    • 4. Struktur und Zeitpunkt der Abrechnung
    • 5. Zwingende Rechnungsinhalte
    • 6. Wichtige Besonderheit: Verbot von Gutschriften
    • BASIC - Specification: ZUGFeRD_2.1_FacturX_1.0.05_Basic_Struktur.pdf
      • Nur für die Niederlande
  • Invoicing Requirements (E-Invoices)

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):
  Wichtig: Die Einrichtung einer SFTP-Verbindung kann nachgelagert zum Go-Live erfolgen.
  Für den Start muss der Übermittlungskanal E-Mail verwendet werden.

  • 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.

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.
  
  

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

1. 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.

1. Feststehende Angaben

2.1 Conrad-Entities im Peppol-Netz (Stand Peppol Directory, 21.07.2026)

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).

1. 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.