[{"content":"BT-13 ist die Bestellnummer des Käufers – die Referenz auf dessen Bestellung oder Auftrag. In csv2zugferd mappen Sie sie auf orderReference.orderNumber. Sie verankert die Rechnung an der ursprünglichen Bestellung und erleichtert die Zuordnung beim Empfänger.\nWas ist BT-13? # BT-13 (Purchase order reference) ist die Bestellnummer, die der Käufer vergeben hat. Sie ermöglicht es dem Rechnungsempfänger, die Rechnung automatisiert seiner eigenen Bestellung zuzuordnen. Es ist ausdrücklich nicht die interne Auftragsnummer des Verkäufers und nicht die Rechnungsnummer.\nPflicht oder optional? # Optional nach EN 16931, aber praktisch oft verpflichtend. Viele Besteller – insbesondere öffentliche Auftraggeber und größere B2B-Kunden – akzeptieren Rechnungen nur mit korrekt gesetzter Bestellnummer. Im Zweifel sollte BT-13 gesetzt werden, sobald eine Bestellung zugrunde liegt.\nYAML-Key in csv2zugferd # orderReference: orderNumber: column: \u0026#34;ORDER_NO\u0026#34; orderDate: column: \u0026#34;ORDER_DATE\u0026#34; orderNumber entspricht BT-13. orderDate ist optional und ergänzt das Bestelldatum.\nCSV-Beispiel # INVOICE_NO ORDER_NO ORDER_DATE RE-2026-0001 BST-2026-0042 18.05.2026 INVOICE_NO ist die vom Verkäufer vergebene Rechnungsnummer und gehört nicht in orderReference. ORDER_NO ist die Bestellnummer des Käufers und wird auf BT-13 gemappt.\nSo landet der Wert im ZUGFeRD-XML # orderReference.orderNumber wird als Kaufauftragsreferenz (BuyerOrderReferencedDocument) im Rechnungskopf geschrieben. Der Wert wird unverändert übernommen; eine inhaltliche Prüfung gegen eine reale Bestellung findet nicht statt.\nTypischer Fehler # Interne Auftragsnummer statt Käufer-Bestellnummer – die Nummer aus dem eigenen ERP gehört nicht in BT-13. Rechnungsnummer erneut als Bestellnummer verwendet, sodass beide Felder denselben Wert tragen. Bestellnummer in eine Notiz geschrieben (invoice.note) statt strukturiert in orderReference.orderNumber – dann ist sie für den Empfänger nicht maschinell auswertbar. Praxishinweis für csv2zugferd # Liegt für alle Rechnungen dieselbe Rahmenbestellung vor, lässt sich orderNumber per value fest setzen. Im Regelfall stammt die Bestellnummer aber pro Rechnung aus einer CSV-Spalte (column).\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht YAML-Konfiguration BT-72 Lieferdatum ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-13-bestellnummer/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-13 Bestellnummer in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-131 ist der Zeilennettobetrag – der Nettobetrag einer einzelnen Rechnungsposition. In csv2zugferd ist das kein einfaches Eingabefeld: Der Wert wird in der Regel aus netUnitPrice, billedQuantity und der Rabattlogik abgeleitet, nicht direkt aus einer CSV-Spalte übernommen.\nWas ist BT-131? # BT-131 (Invoiced item net amount) ist der Nettobetrag der Position vor Umsatzsteuer, nach Abzug positionsbezogener Rabatte. Er ist die Grundlage für die Steuerbasis und damit für die Gesamtsummen der Rechnung. Fachlich gilt:\nZeilennettobetrag (BT-131) = rabattierter Netto-Einzelpreis × Menge Pflicht oder optional? # Pflicht. Jede Rechnungsposition braucht einen Zeilennettobetrag. Anders als bei Name oder Bestellnummer geben Sie den Wert in csv2zugferd aber nicht selbst ein, sondern lassen ihn berechnen.\nYAML-Key in csv2zugferd # Es gibt keinen direkten Key lineTotalAmount je Position. BT-131 entsteht aus den Positionsfeldern und der Summenlogik:\nlineItems: fields: netUnitPrice: column: \u0026#34;PRODUCT_PRICE\u0026#34; billedQuantity: column: \u0026#34;PRODUCT_QUANTITY\u0026#34; discountPercent: column: \u0026#34;PRODUCT_DISCOUNT\u0026#34; totals: mode: \u0026#34;auto\u0026#34; Bei totals.mode: auto berechnet csv2zugferd den Zeilennettobetrag aus netUnitPrice, billedQuantity und – falls vorhanden – discountPercent.\nCSV-Beispiel # PRODUCT_PRICE_0 PRODUCT_QUANTITY_0 PRODUCT_DISCOUNT_0 357,00 2 10 % Rechnung: rabattierter Einzelpreis = 357,00 × (1 − 0,10) = 321,30; Zeilennettobetrag BT-131 = 321,30 × 2 = 642,60. Eine eigene Spalte für den Zeilenbetrag ist nicht nötig.\nauto vs. manual # auto (empfohlen): Zeilennetto, Rabatte, Steuerbasis, MwSt-Gruppen und Gesamtbetrag werden vollständig aus den Positionsdaten berechnet. Die Werte sind per Konstruktion konsistent. manual: Summen kommen aus geprüften CSV-Spalten (lineTotalAmount, taxBasisAmount, grandTotalAmount …). Nur sinnvoll, wenn die CSV fachlich abgesicherte Summen liefert – sonst drohen Widersprüche. Rabatte und BT-131 # discountPercent akzeptiert 10, 10.00 oder 10%. csv2zugferd bildet den Rabatt validierungsfreundlich als rabattierten Netto-Einzelpreis ab:\nBrutto-Listenpreis → GrossPriceProductTradePrice rabattierter Netto-Einzelpreis → NetPriceProductTradePrice Zeilennettobetrag BT-131 = rabattierter Einzelpreis × Menge Für discountPercent-Positionsrabatte wird kein AppliedTradeAllowanceCharge erzeugt, damit EN-16931-Regeln wie BR-S-08 konsistent bleiben.\nSo landet der Wert im ZUGFeRD-XML # Der berechnete Betrag wird je Position als Zeilennettobetrag (SpecifiedLineTradeSettlement → LineTotalAmount) geschrieben und fließt in die Steuerbasis und die Gesamtsummen der Rechnung ein.\nTypischer Fehler # Manuell gelieferte Summen passen nicht zu Menge und Preis – die häufigste Ursache für abgelehnte Rechnungen. Rabatt nur textlich erwähnt, aber nicht strukturiert über discountPercent berücksichtigt. Zeilenbeträge und Steuersummen widersprechen sich, weil Teile manuell und Teile automatisch berechnet werden. Praxishinweis für csv2zugferd # Verwenden Sie totals.mode: auto, sobald Preis, Menge und Steuersatz vollständig aus der CSV kommen. Genau hier liegt ein inhaltlicher Vorteil gegenüber generischen Vorlagen: konsistente Summen ohne manuelles Nachrechnen.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht BT-152 Umsatzsteuersatz je Position YAML-Konfiguration ZUGFeRD-Validierung ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-131-zeilennettobetrag/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-131 Zeilennettobetrag in ZUGFeRD richtig berechnen","type":"docs"},{"content":"BT-152 ist der Umsatzsteuersatz je Position – der Prozentsatz, mit dem eine einzelne Rechnungsposition besteuert wird. In csv2zugferd mappen Sie ihn auf lineItems.fields.taxPercent. Er ist die Grundlage für korrekte Steuersummen und MwSt-Gruppen.\nWas ist BT-152? # BT-152 (Invoiced item VAT rate) gibt den Umsatzsteuersatz der Position als Prozentzahl an, etwa 19 oder 7. Zusammen mit der Steuerkategorie (taxCategoryCode, z. B. S für den Standardsatz) bestimmt er, wie die Position in den Steuergruppen der Rechnung verrechnet wird.\nPflicht oder optional? # Faktisch erforderlich. Für steuerpflichtige Positionen (Kategorie S) muss ein Steuersatz angegeben sein, damit Steuerbasis und MwSt-Beträge berechnet werden können. Fehlt BT-152, sind die Summen nicht ableitbar und die Rechnung nicht konform.\nYAML-Key in csv2zugferd # lineItems: fields: taxPercent: column: \u0026#34;INVOICE_TAX\u0026#34; fixedFields: taxType: value: \u0026#34;VAT\u0026#34; taxCategoryCode: value: \u0026#34;S\u0026#34; taxPercent entspricht BT-152. taxCategoryCode (Steuerkategorie) und taxType ergänzen den Satz fachlich konsistent.\nCSV-Beispiel # PRODUCT_NAME_0 INVOICE_TAX Demo Software 9 Light Lizenz 19.00 INVOICE_TAX (19.00) wird auf BT-152 gemappt. Im Beispiel ist es eine globale Spalte: Der Wert steht einmal in der CSV und gilt für jede erzeugte Position.\nSo landet der Wert im ZUGFeRD-XML # taxPercent wird je Position als anzuwendender Steuersatz (ApplicableTradeTax → RateApplicablePercent) geschrieben und steuert die Zuordnung zu den MwSt-Gruppen sowie die Berechnung der Steuerbeträge.\nTypischer Fehler # Globaler Steuersatz fälschlich positionsbezogen erwartet – oder umgekehrt: ein positionsbezogener Satz wird global gesetzt, obwohl Positionen unterschiedlich besteuert sind. Falsches Dezimalformat – etwa 0,19 statt 19, wodurch die Steuersummen um den Faktor 100 daneben liegen. Steuerkategorie und Steuersatz inkonsistent – z. B. Kategorie Z (Nullsatz) mit einem Satz von 19. Praxishinweis für csv2zugferd # Haben alle Positionen denselben Satz, genügt eine globale Spalte wie INVOICE_TAX in fields.taxPercent. Bei gemischten Sätzen muss taxPercent aus einer positionsbezogenen Spalte (TAX_0, TAX_1, …) kommen und zur jeweiligen taxCategoryCode passen.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht BT-131 Zeilennettobetrag ZUGFeRD-Validierung ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-152-umsatzsteuersatz/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-152 Umsatzsteuersatz je Position in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-153 ist die Positionsbezeichnung – der lesbare Name eines Rechnungspostens. In csv2zugferd mappen Sie ihn auf lineItems.fields.name. Er ist nicht identisch mit der internen Artikelnummer.\nWas ist BT-153? # BT-153 (Item name) ist die menschenlesbare Bezeichnung der Rechnungsposition, etwa „Demo Software 9 Light Einzelplatz-Lizenz\u0026quot;. Es beschreibt, was abgerechnet wird, in einer für den Empfänger verständlichen Form – im Unterschied zu technischen Codes oder Artikelnummern.\nPflicht oder optional? # Pflicht. Jede Rechnungsposition (BG-25) muss eine Positionsbezeichnung BT-153 enthalten. Fehlt der Name, ist die Position nicht EN-16931-konform und die Validierung schlägt fehl.\nYAML-Key in csv2zugferd # lineItems: mode: \u0026#34;columns\u0026#34; fields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; sellerAssignedId: column: \u0026#34;PRODUCT_CODE\u0026#34; name entspricht BT-153. Daneben hält sellerAssignedId (BT-155) die Verkäufer-Artikelnummer – beide Felder sind getrennt zu mappen.\nCSV-Beispiel # PRODUCT_NAME_0 PRODUCT_CODE_0 Demo Software 9 Light Lizenz 00110 PRODUCT_NAME_0 ist der lesbare Positionsname und wird auf BT-153 gemappt. PRODUCT_CODE_0 ist der interne Artikelcode und gehört in sellerAssignedId, nicht in den Namen.\nSo landet der Wert im ZUGFeRD-XML # lineItems.fields.name wird je Position als Artikelname (SpecifiedTradeProduct → Name) geschrieben. Im columns-Modus löst csv2zugferd die Spalte positionsbezogen auf: Position 0 liest PRODUCT_NAME_0, Position 1 PRODUCT_NAME_1 usw. Die Iteration stoppt, sobald die Namensspalte leer ist.\nTypischer Fehler # Produktcode statt Positionsname – eine reine Nummer als name, die der Empfänger nicht lesen kann. Technische Kürzel ohne lesbare Beschreibung, etwa SW9-LIC-L statt eines verständlichen Namens. Leere Namensspalte, obwohl Preis und Menge vorhanden sind – im columns-Modus bricht die Positionserkennung dann an dieser Stelle ab. Praxishinweis für csv2zugferd # Im columns-Modus dient der konfigurierte Spaltenname als Fragment für nummerierte Spalten (PRODUCT_NAME_0, PRODUCT_NAME_1, …). Achten Sie darauf, dass die Namensspalte lückenlos befüllt ist, weil ein leerer Name die Iteration über die Positionen beendet.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht BT-155 Verkäufer-Artikelnummer YAML-Konfiguration ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-153-positionsbezeichnung/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-153 Positionsbezeichnung in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-155 ist die Verkäufer-Artikelnummer – die vom Verkäufer vergebene, eindeutige Kennung eines Artikels. In csv2zugferd mappen Sie sie auf lineItems.fields.sellerAssignedId, nicht in die Bezeichnungs- oder Beschreibungsfelder.\nWas ist BT-155? # BT-155 (Item Seller\u0026rsquo;s identifier) ist die Artikelnummer, unter der der Verkäufer das Produkt führt. Sie identifiziert die Position eindeutig und maschinenlesbar – im Unterschied zur lesbaren Positionsbezeichnung BT-153.\nPflicht oder optional? # Optional nach EN 16931. In der Praxis ist BT-155 aber wertvoll: Der Empfänger kann die Position über die Artikelnummer automatisiert in ERP, Warenwirtschaft oder DMS zuordnen. Wo eine Artikelnummer existiert, sollte sie gesetzt werden.\nYAML-Key in csv2zugferd # lineItems: fields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; sellerAssignedId: column: \u0026#34;PRODUCT_CODE\u0026#34; description: column: \u0026#34;PRODUCT_DESCRIPTION\u0026#34; sellerAssignedId entspricht BT-155. name (BT-153) bleibt für den lesbaren Namen reserviert, description für echte Artikelbeschreibungen.\nCSV-Beispiel # PRODUCT_NAME_0 PRODUCT_CODE_0 PRODUCT_DESCRIPTION_0 Demo Software 9 Light Lizenz 00210 Einzelplatz, 12 Monate PRODUCT_CODE_0 (00210) ist die Verkäufer-Artikelnummer und wird auf BT-155 gemappt. Der lesbare Name steht in PRODUCT_NAME_0, die Beschreibung in PRODUCT_DESCRIPTION_0.\nSo landet der Wert im ZUGFeRD-XML # lineItems.fields.sellerAssignedId wird je Position als vom Verkäufer vergebene Artikelkennung (SpecifiedTradeProduct → SellerAssignedID) geschrieben. Im columns-Modus wird die Spalte positionsbezogen aufgelöst (PRODUCT_CODE_0, PRODUCT_CODE_1, …).\nTypischer Fehler # Artikelnummer als description gemappt statt in sellerAssignedId – dann steht die Nummer im Beschreibungsfeld und ist nicht als Kennung auswertbar. Käufer- und Verkäufer-Artikelnummer vermischt – BT-155 ist ausdrücklich die Nummer des Verkäufers. Nummer fehlt und erschwert dem Empfänger die spätere Weiterverarbeitung in ERP oder DMS. Praxishinweis für csv2zugferd # sellerAssignedId ist für interne Produktnummern gedacht; description bleibt für echte Artikelbeschreibungen reserviert. Trennen Sie beide Spalten sauber, damit Nummer und Freitext nicht in dasselbe XML-Feld geraten.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht BT-153 Positionsbezeichnung BT-131 Zeilennettobetrag ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-155-verkaeufer-artikelnummer/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-155 Verkäufer-Artikelnummer in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-44 ist der Käufername – der offizielle Name des Rechnungsempfängers. In csv2zugferd mappen Sie diesen Wert auf den YAML-Key buyer.name. Das Feld ist die elementare Empfängeridentität einer ZUGFeRD- oder XRechnung-Rechnung.\nWas ist BT-44? # BT-44 bezeichnet nach EN 16931 den Namen des Käufers, also der Organisation oder Person, an die die Rechnung adressiert ist. Es ist der rechtlich erkennbare Empfängername, nicht ein Vertriebs- oder Kurzname und nicht der Ansprechpartner.\nPflicht oder optional? # Pflicht. Ohne Käufername ist eine Rechnung nach EN 16931 nicht konform. BT-44 muss in jeder ZUGFeRD- und XRechnung-Rechnung vorhanden und befüllt sein. Bleibt das Feld leer, schlägt die Validierung fehl.\nYAML-Key in csv2zugferd # In csv2zugferd gehört der Käufername in den buyer-Block:\nbuyer: name: column: \u0026#34;ACCOUNT_NAME\u0026#34; Die weiteren Adressfelder (postalCode, city, street, country) stehen daneben im selben Block. name ist davon unabhängig und immer erforderlich.\nCSV-Beispiel # ACCOUNT_NAME INVOICE_BILL_CITY CONTACT_LASTNAME Beispiel Nord GmbH Hamburg Schmidt Der Firmenname steht in ACCOUNT_NAME und wird auf BT-44 gemappt. CONTACT_LASTNAME ist der Ansprechpartner und gehört nicht in buyer.name, sondern in buyer.contact.\nSo landet der Wert im ZUGFeRD-XML # buyer.name wird im ZUGFeRD-XML als Name des Käufers (BuyerTradeParty) geschrieben. Validatoren prüfen lediglich, dass das Feld vorhanden und nicht leer ist – die inhaltliche Richtigkeit des Namens liegt beim Anwender.\nTypische Fehler # Ansprechpartner statt Firmenname gemappt, z. B. CONTACT_LASTNAME in buyer.name. Kurz- oder Vertriebsname statt des rechtlich erkennbaren Empfängernamens. Käufername leer, obwohl Adressdaten wie Straße und Ort vorhanden sind – das führt zu einer ungültigen Rechnung. Praxishinweis für csv2zugferd # buyer.name akzeptiert sowohl eine CSV-Spalte (column) als auch einen festen Wert (value). Stellen Sie nur dann einen festen Wert ein, wenn alle Rechnungen denselben Empfänger haben – im Normalfall kommt der Käufername aus der CSV.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht YAML-Konfiguration BT-13 Bestellnummer ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-44-kaeufername/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-44 Käufername in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-72 ist das tatsächliche Liefer- oder Leistungsdatum – der Tag, an dem die Ware geliefert oder die Leistung erbracht wurde. In csv2zugferd mappen Sie es auf delivery.actualDeliveryDate. Es ist klar vom Rechnungsdatum zu trennen.\nWas ist BT-72? # BT-72 (Actual delivery date) gibt an, wann die berechnete Lieferung oder Leistung tatsächlich erfolgt ist. Es ist ein eigenständiger fachlicher Inhalt und nicht identisch mit dem Ausstellungsdatum der Rechnung (BT-2) oder dem Fälligkeitsdatum (BT-9).\nPflicht oder optional? # Optional nach EN 16931. Sobald Lieferung und Rechnungsstellung aber an unterschiedlichen Tagen liegen – der Regelfall –, ist das Lieferdatum fachlich und steuerlich relevant und sollte gesetzt werden.\nYAML-Key in csv2zugferd # delivery: actualDeliveryDate: column: \u0026#34;DELIVERY_DATE\u0026#34; actualDeliveryDate setzt das tatsächliche Lieferdatum BT-72. Der delivery-Block kann zusätzlich deliveryNoteNumber und deliveryNoteDate für die Lieferscheinreferenz enthalten; alle drei Felder sind optional.\nCSV-Beispiel # INVOICE_DATE DELIVERY_DATE 31.05.2026 24.05.2026 INVOICE_DATE ist das Rechnungsdatum und wird im Rechnungskopf gesetzt. DELIVERY_DATE ist das Lieferdatum und wird auf BT-72 gemappt – hier liegt es vor dem Rechnungsdatum.\nSo landet der Wert im ZUGFeRD-XML # delivery.actualDeliveryDate wird als tatsächliches Lieferdatum (ActualDeliverySupplyChainEvent) geschrieben. Das Datum muss dem in csv.dateFormat konfigurierten Format entsprechen, damit es korrekt geparst wird.\nTypischer Fehler # Rechnungsdatum als Lieferdatum wiederverwendet, obwohl beide Tage unterschiedlich sind. Fälligkeitsdatum als Lieferdatum missbraucht – BT-9 und BT-72 haben unterschiedliche Bedeutung. Uneinheitliche Datumsformate in der CSV, sodass einzelne Zeilen nicht zum konfigurierten csv.dateFormat passen. Praxishinweis für csv2zugferd # Das Datumsformat wird zentral in der YAML unter csv.dateFormat (z. B. dd.MM.yyyy) festgelegt und gilt für alle Datumsspalten. Prüfen Sie vor dem ersten Lauf, dass DELIVERY_DATE exakt diesem Format folgt.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht Schnellstart BT-13 Bestellnummer ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-72-lieferdatum/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-72 Lieferdatum in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-9 ist das Fälligkeitsdatum – der Tag, bis zu dem die Rechnung zu zahlen ist. In csv2zugferd setzen Sie es über paymentTerms.dueDate. Es macht das Zahlungsziel eindeutig, statt es nur in einer Freitext-Zahlungsbedingung zu beschreiben.\nWas ist BT-9? # BT-9 (Payment due date) gibt das konkrete Datum an, bis zu dem die Zahlung erwartet wird. Es ist ein strukturiertes Datum und damit maschinell auswertbar – im Unterschied zu einer reinen Textangabe wie „zahlbar innerhalb von 14 Tagen\u0026quot;.\nPflicht oder optional? # Optional nach EN 16931. Sinnvoll ist BT-9 überall dort, wo ein festes Zahlungsziel gilt. Dann kann der Empfänger das Datum direkt übernehmen, ohne es aus den Zahlungsbedingungen errechnen zu müssen.\nYAML-Key in csv2zugferd # paymentTerms: description: value: \u0026#34;Zahlbar ohne Abzug bis zum Faelligkeitsdatum\u0026#34; dueDate: column: \u0026#34;INVOICE_DUEDATE\u0026#34; dueDate entspricht BT-9. description ist die optionale Freitext-Zahlungsbedingung und ersetzt das strukturierte Datum nicht.\nCSV-Beispiel # INVOICE_DATE INVOICE_DUEDATE 31.05.2026 24.06.2026 INVOICE_DUEDATE (24.06.2026) wird auf BT-9 gemappt. Das Datum muss dem in csv.dateFormat konfigurierten Format entsprechen.\nSo landet der Wert im ZUGFeRD-XML # paymentTerms.dueDate wird als Fälligkeitsdatum (SpecifiedTradePaymentTerms → DueDateDateTime) geschrieben. Wie alle Datumsfelder wird der Wert anhand von csv.dateFormat geparst.\nTypischer Fehler # Zahlungsbedingung ohne strukturiertes Datum – nur ein Freitext in description, aber kein dueDate. Datumsformat passt nicht zum konfigurierten csv.dateFormat. Fälligkeitsdatum mit Lieferdatum verwechselt – BT-9 und BT-72 haben unterschiedliche Bedeutung. Praxishinweis für csv2zugferd # BT-9 ist ein knappes Zahlungsziel-Feld, kein Einstieg in vollständige Bankdaten. Steht in der CSV kein eigenes Fälligkeitsdatum, kann – wie in der Demo – dieselbe Datumsspalte für Rechnungs- und Fälligkeitsdatum genutzt werden; sauberer ist eine eigene Spalte.\nWeiterführende Links # BT-Felder in ZUGFeRD – Übersicht BT-72 Lieferdatum YAML-Konfiguration ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-9-faelligkeitsdatum/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-9 Fälligkeitsdatum in ZUGFeRD richtig mappen","type":"docs"},{"content":"BT-Felder sind die fachlichen Bausteine jeder strukturierten Rechnung. Diese Übersicht führt die für csv2zugferd wichtigsten Business Terms zusammen und zeigt für jedes Feld, welcher YAML-Key beim CSV-zu-ZUGFeRD-Mapping dazugehört.\nWas BT-Felder sind # BT steht für Business Term. Die europäische Norm EN 16931 beschreibt das semantische Datenmodell einer elektronischen Rechnung und vergibt jedem fachlichen Inhalt eine eindeutige Nummer: BT-44 für den Käufernamen, BT-131 für den Zeilennettobetrag, BT-152 für den Umsatzsteuersatz einer Position und so weiter. Mehrere zusammengehörige Business Terms werden zu Gruppen (BG) gebündelt, etwa alle Felder einer Rechnungsposition.\nZUGFeRD und XRechnung sind beide Umsetzungen derselben EN 16931. Ein BT-Feld bedeutet in beiden Formaten dasselbe – es wird nur in unterschiedlichen Profilen und in einer anderen XML-Syntax abgelegt. Wer die BT-Nummer kennt, weiß deshalb unabhängig vom konkreten Format, welcher Inhalt gemeint ist.\nWarum BT-Felder für csv2zugferd wichtig sind # csv2zugferd verkauft keinen E-Rechnungseditor, sondern einen Mapping-Workflow: Eine CSV-Spalte wird per YAML auf ein strukturiertes Rechnungsfeld abgebildet, und daraus entsteht eine valide ZUGFeRD-Datei. Genau an dieser Stelle treffen drei Ebenen aufeinander:\nSemantik – was das BT-Feld fachlich bedeutet. Produktabbildung – welcher YAML-Key in csv2zugferd dazu gehört. Praxis – aus welcher CSV-Spalte der Wert typischerweise kommt. Die häufigste Frage in der Praxis lautet deshalb nicht „Was sagt die EN 16931 zu BT-44?\u0026quot;, sondern „In welchen YAML-Key gehört der Käufername, und welche CSV-Spalte mappe ich darauf?\u0026quot;. Diese Übersicht und die verlinkten Detailseiten beantworten genau das.\nDie wichtigsten BT-Felder im Überblick # Die folgende Tabelle verbindet Bedeutung, YAML-Key und ein knappes Beispiel. Jede Zeile verlinkt auf die ausführliche Detailseite.\nBT-Feld Bedeutung YAML-Key in csv2zugferd Beispielwert BT-44 Käufername buyer.name Beispiel Nord GmbH BT-13 Bestellnummer des Käufers orderReference.orderNumber BST-2026-0042 BT-72 Liefer-/Leistungsdatum delivery.actualDeliveryDate 24.05.2026 BT-153 Positionsbezeichnung lineItems.fields.name Demo Software 9 Light Lizenz BT-155 Verkäufer-Artikelnummer lineItems.fields.sellerAssignedId 00210 BT-131 Zeilennettobetrag abgeleitet aus netUnitPrice, billedQuantity, Rabatt 642,60 BT-152 Umsatzsteuersatz je Position lineItems.fields.taxPercent 19 BT-9 Fälligkeitsdatum paymentTerms.dueDate 24.06.2026 BT-Felder nach Themen gruppiert # Käuferdaten # BT-44 (Käufername) ist die elementare Empfängeridentität und nahezu in jedem Workflow ein Pflichtfeld. In csv2zugferd gehört der Wert in buyer.name, die übrigen Adressfelder stehen daneben im buyer-Block.\nBestell- und Lieferbezug # BT-13 (Bestellnummer) und BT-72 (Lieferdatum) verankern die Rechnung an Bestellung und tatsächlicher Leistung. Beide werden häufig mit anderen Datums- oder Nummernfeldern verwechselt – die Detailseiten grenzen sie sauber ab.\nPositionsdaten # BT-153 (Positionsbezeichnung) und BT-155 (Verkäufer-Artikelnummer) beschreiben eine Rechnungsposition lesbar bzw. eindeutig. Sie liegen in csv2zugferd im lineItems.fields-Block und dürfen nicht miteinander vermischt werden.\nSteuer und Summen # BT-152 (Umsatzsteuersatz je Position) und BT-131 (Zeilennettobetrag) bilden die Grundlage für valide Summen. BT-131 ist dabei kein einfaches Eingabefeld, sondern wird von csv2zugferd aus Menge, Einzelpreis und Rabatt abgeleitet – siehe die zugehörige Detailseite.\nTypische Mapping-Fehler # Käufername fehlt oder enthält den Ansprechpartner statt der Firma (BT-44). Bestellnummer im falschen Feld – interne Auftragsnummer statt Käufer-Bestellnummer (BT-13). Artikelnummer als Beschreibung gemappt statt in sellerAssignedId (BT-155). Steuersatz fehlt oder wird global vs. positionsbezogen verwechselt (BT-152). Zeilenbetrag manuell widersprüchlich geliefert, sodass er nicht zu Menge und Preis passt (BT-131). Wann sich die Detailseiten lohnen # Die Detailseiten beantworten für ein einzelnes Feld jeweils: Was ist es? Pflicht oder optional? Welcher YAML-Key? Welcher typische Fehler? Sie sind die richtige Anlaufstelle, wenn ein konkretes Mapping nicht aufgeht oder ein Validator ein bestimmtes BT-Feld bemängelt.\nKäuferdaten: BT-44 Käufername Bestell- und Lieferbezug: BT-13 Bestellnummer · BT-72 Lieferdatum Positionsdaten: BT-153 Positionsbezeichnung · BT-155 Verkäufer-Artikelnummer Steuer und Summen: BT-152 Umsatzsteuersatz · BT-131 Zeilennettobetrag Zahlung: BT-9 Fälligkeitsdatum Nächster Schritt mit csv2zugferd # Die BT-Felder sind die Sprache der Norm – das Mapping ist Ihre Arbeit in der YAML-Datei. Drei Wege führen direkt weiter:\nYAML-Konfiguration – die vollständige Mapping-Struktur mit FieldMapping, rows- und columns-Modus. Schnellstart – das Demo-Paket mit fertiger config_demo.yml, an der sich jedes BT-Feld nachvollziehen lässt. Download – csv2zugferd lokal herunterladen und eigene Rechnungen erzeugen. ","date":"18. Juni 2026","externalUrl":null,"permalink":"/docs/bt-felder-zugferd/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"BT-Felder in ZUGFeRD mit csv2zugferd","type":"docs"},{"content":"E-Rechnungen unterliegen denselben Aufbewahrungspflichten wie Papierrechnungen — mit einem entscheidenden Unterschied: Der strukturierte XML-Teil muss elektronisch und maschinell lesbar erhalten bleiben.\nDiese Seite ist eine technische Einordnung und keine Rechts- oder Steuerberatung. Aufbewahrungsfristen # Rechtsgrundlage Frist Gilt für §14b UStG 8 Jahre Rechnungen mit Umsatzsteuerrelevanz §257 HGB 10 Jahre Handelsbücher, Buchungsbelege Die Frist beginnt mit dem Ende des Kalenderjahres, in dem die Rechnung ausgestellt wurde. Im Zweifel gilt die längere Frist.\nWas GoBD-konform bedeutet # Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (GoBD) des BMF verlangen:\nUnveränderlichkeit: Die archivierte Datei darf nachträglich nicht verändert werden können. Vollständigkeit: Alle steuerrelevanten Rechnungen müssen lückenlos erfasst sein. Maschinelle Auswertbarkeit: Der strukturierte XML-Teil muss für Betriebsprüfungen maschinell lesbar bleiben. Auffindbarkeit: Rechnungen müssen innerhalb angemessener Frist auffindbar und lesbar sein. Schutz vor Verlust: Datensicherung und Zugriffsschutz sind Voraussetzung. Ein einfacher Windows-Ordner ohne Zugriffsprotokoll und ohne Schreibschutz erfüllt diese Anforderungen in der Regel nicht.\nWarum der XML-Teil erhalten bleiben muss # Eine ZUGFeRD-Rechnung ist eine PDF/A-3-Datei mit eingebettetem XML. Beide Teile sind Bestandteil des Belegs. Der XML-Teil enthält die strukturierten Rechnungsdaten, die für die automatische Weiterverarbeitung und Betriebsprüfung benötigt werden.\nDas XML auszudrucken oder die Datei in ein nicht-archivierfähiges Format zu konvertieren widerspricht den GoBD-Anforderungen.\nWas csv2zugferd leistet — und was nicht # csv2zugferd erzeugt ZUGFeRD-konforme PDF/A-3-Dateien mit eingebettetem XML und legt sie im konfigurierten Ausgabeverzeichnis ab. Die Erzeugung ist der erste Schritt.\ncsv2zugferd archiviert nicht. Es gibt keine Datenbank, kein Zugriffsprotokoll und keine Unveränderlichkeitsgarantie für erzeugte Dateien.\nFür die GoBD-konforme Langzeitarchivierung wird ein separates System benötigt:\nDokumentenmanagementsystem (DMS) mit revisionssicherer Ablage Dediziertes E-Rechnungsarchiv eines Steuerberaters oder Dienstleisters Integriertes ERP-Archiv mit GoBD-Zertifizierung Der empfohlene Workflow: csv2zugferd erzeugt → Archivierungssystem übernimmt die Datei unveränderlich.\nAufbewahrung beim Empfang # Wer E-Rechnungen empfängt, muss ebenfalls den strukturierten Teil in seiner ursprünglichen Form aufbewahren. Eine empfangene ZUGFeRD-Rechnung darf nicht in ein anderes Format konvertiert und die Originaldatei anschließend gelöscht werden.\nSeit dem 1. Januar 2025 sind alle inländischen B2B-Unternehmen verpflichtet, E-Rechnungen empfangen zu können. Die Aufbewahrungspflicht gilt ab dem ersten empfangenen Beleg.\n","date":"25. Mai 2026","externalUrl":null,"permalink":"/artikel/e-rechnung-aufbewahrung/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"E-Rechnungen aufbewahren – 8 Jahre GoBD-konform archivieren","type":"artikel"},{"content":"Das Demo-Paket enthält alles, um csv2zugferd ohne Konfigurationsaufwand auszuprobieren: eine fertige Windows-Exe, zwei Beispiel-Rechnungen und eine vollständige YAML-Konfiguration.\nDemo-Paket auf GitHub herunterladen Paketinhalt # Datei Beschreibung csv2zugferd-win-x64.exe Windows-64-bit-Exe, self-contained config_demo.yml Fertige YAML-Konfiguration für die Demo-CSV demo-2026-0001.csv Beispiel-Rechnung 1 (Softwarelizenzen mit Rabatt) demo-2026-0001.pdf PDF-Vorlage zu Rechnung 1 demo-2026-0002.csv Beispiel-Rechnung 2 (Lizenzen, Service, Schulung) demo-2026-0002.pdf PDF-Vorlage zu Rechnung 2 create-zugferd-demo.cmd Startskript für Windows Schnellstart # ZIP-Archiv aus den GitHub Releases herunterladen. Alle Dateien in einen gemeinsamen Ordner entpacken. create-zugferd-demo.cmd per Doppelklick oder in der Eingabeaufforderung starten. Die erzeugten ZUGFeRD-Dateien liegen danach im Unterordner output\\.\nDie zwei Demo-Rechnungen # DEMO-2026-0001 — Softwarelizenzen mit Rabatt # Käufer: Beispiel Nord GmbH\nPos Produkt Menge Einzelpreis Rabatt Einheitencode 0 Demo Software 9 Light Einzelplatz-Lizenz 2 357,00 € 10 % C62 (Stück) 1 Demo Software 9 Standard Einzelplatz-Lizenz 1 579,00 € — C62 (Stück) Netto: 1.221,60 € · MwSt 19 %: 232,10 € · Brutto: 1.453,70 €\nDEMO-2026-0002 — Lizenzen, Service und Schulung # Käufer: Beispiel West GmbH\nPos Produkt Menge Einzelpreis Rabatt Einheitencode 0 Demo Software 9 Enterprise Floating-Lizenz 5 1.839,00 € 10 % C62 (Stück) 1 Software Service Vertrag Enterprise 5 275,85 € — ANN (Jahr) — per Regex aus Produktcode 002xx 2 Vor-Ort-Schulungen 2 1.500,00 € — DAY (Tag) — per Regex aus Produktname Schulung Netto: 12.654,75 € · MwSt 19 %: 2.404,40 € · Brutto: 15.059,15 €\nconfig_demo.yml im Detail # Die YAML-Konfiguration verbindet die CSV-Spalten mit den ZUGFeRD-Feldern. Jeder Abschnitt ist unabhängig konfigurierbar.\nCSV-Einstellungen # csv: separator: \u0026#34;,\u0026#34; encoding: \u0026#34;UTF-8\u0026#34; hasHeader: true decimalSeparator: \u0026#34;.\u0026#34; dateFormat: \u0026#34;dd.MM.yyyy\u0026#34; Die Demo-CSV verwendet Komma als Trennzeichen und Punkt als Dezimalzeichen — typisch für CRM-Exporte. Datumsfelder stehen im Format 24.05.2026.\nZUGFeRD-Ausgabe # zugferd: version: \u0026#34;2.3\u0026#34; profile: \u0026#34;Extended\u0026#34; format: \u0026#34;CII\u0026#34; Profil Extended erlaubt alle Pflicht- und optionalen Felder der ZUGFeRD-2.3-Spezifikation. CII ist das XML-Format nach UN/CEFACT Cross Industry Invoice.\nRechnungskopf # mapping: invoice: invoiceNumber: column: \u0026#34;INVOICE_NO\u0026#34; invoiceDate: column: \u0026#34;INVOICE_DUEDATE\u0026#34; currency: value: \u0026#34;EUR\u0026#34; orderReferenceId: column: \u0026#34;SALESORDER_ID\u0026#34; referenceOrderNo: column: \u0026#34;SALESORDER_ID\u0026#34; INVOICE_DUEDATE wird hier bewusst als Rechnungsdatum verwendet, weil die Demo-CSV kein separates Ausstellungsdatum enthält. SALESORDER_ID erscheint zweimal: als orderReferenceId beim Erstellen des InvoiceDescriptor und als referenceOrderNo für die Bestellreferenz im Rechnungskopf.\nKäuferdaten — aus der CSV # buyer: name: column: \u0026#34;ACCOUNT_NAME\u0026#34; postalCode: column: \u0026#34;INVOICE_BILL_CODE\u0026#34; city: column: \u0026#34;INVOICE_BILL_CITY\u0026#34; street: column: \u0026#34;INVOICE_BILL_STREET\u0026#34; country: value: \u0026#34;DE\u0026#34; contact: column: \u0026#34;CONTACT_LASTNAME\u0026#34; Adressdaten kommen direkt aus der CSV. country ist fest auf DE gesetzt, weil die Demo-Rechnungen alle deutschen Käufern gehören. CONTACT_LASTNAME liefert den Ansprechpartner.\nVerkäuferdaten — fest in der YAML # seller: name: value: \u0026#34;Demo Software GmbH\u0026#34; postalCode: value: \u0026#34;10115\u0026#34; city: value: \u0026#34;Musterstadt\u0026#34; street: value: \u0026#34;Demostrasse 1\u0026#34; country: value: \u0026#34;DE\u0026#34; taxRegistrations: - value: \u0026#34;Demo\u0026#34; scheme: \u0026#34;FC\u0026#34; - value: \u0026#34;DE000000000\u0026#34; scheme: \u0026#34;VA\u0026#34; Verkäuferdaten sind für alle Rechnungen identisch und stehen deshalb als feste Werte in der YAML. Das ist die empfohlene Vorgehensweise für eigene Konfigurationen: Stammdaten einmal in der YAML hinterlegen, nicht in jeder CSV-Zeile wiederholen. FC steht für Steuernummer, VA für Umsatzsteuer-ID.\nLieferung und Bestellreferenz # delivery: actualDeliveryDate: column: \u0026#34;SALESORDER_DUEDATE\u0026#34; orderReference: orderNumber: column: \u0026#34;SALESORDER_ID\u0026#34; actualDeliveryDate setzt das Lieferdatum (BT-72). Hier wird das Fälligkeitsdatum der Bestellung als Lieferdatum verwendet. orderNumber entspricht BT-13 (Bestellnummer des Käufers).\nRechnungspositionen — columns-Modus # lineItems: mode: \u0026#34;columns\u0026#34; columnPattern: style: \u0026#34;suffix\u0026#34; separator: \u0026#34;_\u0026#34; startIndex: 0 zeroPadding: 0 Im columns-Modus steht die gesamte Rechnung in einer CSV-Zeile. Positionen werden über nummerierte Spaltensuffixe erkannt: PRODUCT_NAME_0, PRODUCT_NAME_1 usw. Die Iteration stoppt, sobald PRODUCT_NAME_N leer ist.\nPositionsfelder # fields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; sellerAssignedId: column: \u0026#34;PRODUCT_CODE\u0026#34; netUnitPrice: column: \u0026#34;PRODUCT_PRICE\u0026#34; billedQuantity: column: \u0026#34;PRODUCT_QUANTITY\u0026#34; taxPercent: column: \u0026#34;INVOICE_TAX\u0026#34; discountPercent: column: \u0026#34;PRODUCT_DISCOUNT\u0026#34; Feld CSV-Spalte Besonderheit name PRODUCT_NAME_N Positionsbezeichnung, Pflichtfeld sellerAssignedId PRODUCT_CODE_N Interne Artikelnummer, positionsbezogen netUnitPrice PRODUCT_PRICE_N Netto-Einzelpreis vor Rabatt billedQuantity PRODUCT_QUANTITY_N Menge taxPercent INVOICE_TAX Globale Spalte — einmal pro Rechnung, gilt für alle Positionen discountPercent PRODUCT_DISCOUNT_N Positionsbezogener Rabatt, akzeptiert 10, 10.00 oder 10% INVOICE_TAX ist eine globale Spalte: der Wert 19.00 steht einmal in der CSV und wird auf jede erzeugte Position angewendet. PRODUCT_DISCOUNT_N ist dagegen positionsbezogen — Position 0 liest PRODUCT_DISCOUNT_0, Position 1 liest PRODUCT_DISCOUNT_1.\nEinheitencodes per Regex — fixedFields # fixedFields: unitCode: default: \u0026#34;C62\u0026#34; rules: - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^002\u0026#34; value: \u0026#34;ANN\u0026#34; - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^003\u0026#34; value: \u0026#34;DAY\u0026#34; - when: column: \u0026#34;PRODUCT_NAME\u0026#34; regex: \u0026#34;(?i)vor-ort-schulung|schulung\u0026#34; value: \u0026#34;DAY\u0026#34; taxType: value: \u0026#34;VAT\u0026#34; taxCategoryCode: value: \u0026#34;S\u0026#34; fixedFields enthält Positionsfelder, die meistens konstant sind, aber FieldMapping mit rules unterstützen.\nDer Einheitencode unitCode wird per Regex aus dem Produktcode oder Produktnamen abgeleitet:\nBedingung Regex Ergebnis Bedeutung PRODUCT_CODE_N beginnt mit 002 ^002 ANN Jahr (Jahreslizenzen, Serviceverträge) PRODUCT_CODE_N beginnt mit 003 ^003 DAY Tag (Tagessätze) PRODUCT_NAME_N enthält „Schulung\u0026quot; (?i)vor-ort-schulung|schulung DAY Tag (Schulungen) sonst — C62 Stück (Standardfall) Im columns-Modus werden Regelspalten positionsbezogen aufgelöst: bei Position 1 prüft die Regel PRODUCT_CODE_1, bei Position 2 PRODUCT_CODE_2 usw.\nSummen # totals: mode: \u0026#34;auto\u0026#34; auto berechnet alle Summen aus den Positionsdaten: Zeilennetto, Rabatte, Steuerbasis, MwSt-Gruppen und Gesamtbetrag. Keine manuelle CSV-Spalte nötig.\nZahlungsbedingungen # paymentTerms: description: value: \u0026#34;Zahlbar ohne Abzug bis zum Faelligkeitsdatum\u0026#34; dueDate: column: \u0026#34;INVOICE_DUEDATE\u0026#34; Die Zahlungsbeschreibung ist fest in der YAML. Das Fälligkeitsdatum kommt aus INVOICE_DUEDATE — derselben Spalte, die auch als Rechnungsdatum dient.\nNächster Schritt # Sie haben das Demo-Paket erfolgreich ausprobiert. Im nächsten Schritt erstellen Sie Ihre eigene config.yml für Ihre CSV-Datei und erzeugen daraus Ihre erste ZUGFeRD-PDF.\nJetzt eigene config.yml mit KI erstellen Ausgabe prüfen # Die erzeugten PDF-Dateien im Ordner output\\ sind valide ZUGFeRD-2.3-Rechnungen im Profil Extended. Für die Prüfung siehe ZUGFeRD-Validierung →.\n","date":"25. Mai 2026","externalUrl":null,"permalink":"/docs/schnellstart/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"Schnellstart – Demo-Paket herunterladen und ausführen","type":"docs"},{"content":"Die deutsche E-Rechnungspflicht verlangt ein strukturiertes elektronisches Format nach EN 16931. ZUGFeRD erfüllt diese Anforderung — aber nicht mit jedem Profil.\nDiese Seite ist eine technische Einordnung und keine Rechts- oder Steuerberatung. Zugelassene und ausgeschlossene Profile # Profil E-Rechnungspflicht Begründung MINIMUM Nicht zugelassen Enthält nicht alle steuerrechtlichen Pflichtangaben strukturiert BASIC-WL Nicht zugelassen Enthält nicht alle steuerrechtlichen Pflichtangaben strukturiert BASIC Zugelassen Alle EN-16931-Pflichtfelder im XML Comfort Zugelassen EN-16931-konform, erweiterter Umfang EN 16931 Zugelassen Entspricht dem EN-16931-Standard direkt Extended Zugelassen Vollständiger Umfang, für komplexe Szenarien XRechnung Zugelassen Reines XML, kein PDF-Anteil, EN-16931-konform MINIMUM und BASIC-WL sind explizit ausgeschlossen, weil sie nicht alle umsatzsteuerrechtlichen Pflichtangaben in maschinenlesbarer Form enthalten. Das BMF und die IHK bestätigen dies in ihren Leitfäden.\nWas EN 16931 verlangt # EN 16931 ist eine europäische Norm für das semantische Datenmodell von Rechnungen. Sie definiert, welche Felder eine E-Rechnung enthalten muss, damit sie von Systemen automatisch verarbeitet werden kann.\nKonkret müssen im strukturierten XML-Teil vorhanden sein:\nRechnungsnummer, Ausstellungsdatum, Fälligkeitsdatum Vollständige Adressdaten von Aussteller und Empfänger Steuernummer oder Umsatzsteuer-ID beider Parteien Einzelne Positionen mit Menge, Einheitenpreis und Steuersatz Nettobetrag, Steuerbetrag und Gesamtbetrag Zahlungsbedingungen MINIMUM und BASIC-WL bilden diese Felder nicht vollständig strukturiert ab — sie eignen sich für Buchungsdokumente und Gutschriften im Konzernumfeld, nicht für rechtsverbindliche Ausgangsrechnungen im Sinne der E-Rechnungspflicht.\ncsv2zugferd erzeugt Extended # csv2zugferd erzeugt ZUGFeRD 2.3 im Profil Extended. Extended ist das umfangreichste Profil und enthält alle Pflichtfelder der EN 16931 sowie zusätzliche optionale Felder für komplexe Rechnungsszenarien wie Rahmenverträge, Lieferscheinreferenzen und positionsbezogene Rabatte.\nDie Konfiguration steht in der YAML-Datei:\nzugferd: version: \u0026#34;2.3\u0026#34; profile: \u0026#34;Extended\u0026#34; format: \u0026#34;CII\u0026#34; Wer das Profil reduzieren möchte, kann Extended gegen EN16931, Comfort oder Basic austauschen. MINIMUM und BASIC-WL werden von csv2zugferd technisch unterstützt, sind aber für die E-Rechnungspflicht ungeeignet.\nMindestversion: ZUGFeRD 2.0.1 # Ältere ZUGFeRD-Versionen — insbesondere ZUGFeRD 1.0 — erfüllen die EN-16931-Anforderungen nicht. Für die E-Rechnungspflicht ist mindestens ZUGFeRD 2.0.1 in einem zulässigen Profil erforderlich.\ncsv2zugferd erzeugt Version 2.3, die aktuelle und vollständig normkonforme Version.\nZUGFeRD und XRechnung im Vergleich # Beide Formate sind für die E-Rechnungspflicht im B2B-Bereich gleichwertig zugelassen:\nZUGFeRD XRechnung Format PDF/A-3 + eingebettetes XML Reines XML Lesbarkeit Sichtbar als PDF Nur maschinell lesbar Typischer Einsatz B2B, direkter Versand per E-Mail B2G (Pflicht), B2B (Alternative) Leitweg-ID Nicht erforderlich Nur im B2G-Bereich csv2zugferd Ja Nein Der Vorteil von ZUGFeRD: Die Rechnung ist gleichzeitig ein lesbares PDF und eine maschinenverarbeitbare XML-Datei — ohne zusätzlichen Konvertierungsschritt für den Empfänger.\nWeiterlesen: Factur-X vs. ZUGFeRD\n","date":"25. Mai 2026","externalUrl":null,"permalink":"/artikel/zugferd-profile-e-rechnungspflicht/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"Welche ZUGFeRD-Profile erfüllen die E-Rechnungspflicht?","type":"artikel"},{"content":"Wir freuen uns über Ihr Interesse an csv2zugferd. Nachfolgend informieren wir Sie über die Verarbeitung personenbezogener Daten beim Besuch dieser Website sowie über Ihre Rechte nach der Datenschutz-Grundverordnung (DSGVO).\nzugferd-tools.de ist eine reine Informations- und Download-Website für das Open-Source-Werkzeug csv2zugferd. Die Website nimmt keine Rechnungsdaten entgegen, bietet keinen Upload-Workflow und stellt keine Konten, Bestell- oder Cloud-Funktionen bereit. Eine Nutzung ist grundsätzlich ohne aktive Angabe personenbezogener Daten möglich; technisch notwendige Daten (z. B. die IP-Adresse in Server-Logfiles) werden jedoch bei jedem Aufruf verarbeitet.\nVerantwortlicher # Verantwortlicher im Sinne der DSGVO und sonstiger datenschutzrechtlicher Bestimmungen ist:\nAnschrift:Rillsoft GmbH Mollenbachstr. 14 71229 Leonberg, Deutschland Vertreten durch:Dimitri Sapunou (Geschäftsführer) Tel.:+49 7152 30725570 E-Mail:info@rillsoft.de Website:www.rillsoft.de Die Rillsoft GmbH ist Herausgeberin und Maintainerin des Open-Source-Werkzeugs csv2zugferd und betreibt diese Website. Weitere Anbieterangaben finden Sie im Impressum.\nLokale Verarbeitung durch csv2zugferd # csv2zugferd verarbeitet CSV-, PDF- und YAML-Daten lokal auf dem Rechner des Anwenders. Die Rechnungsinhalte verlassen das System des Anwenders dabei nicht; eine Übertragung von Rechnungsdaten an uns oder an Dritte über diese Website findet nicht statt. Für die Richtigkeit, Vollständigkeit und steuerliche Bewertung der verarbeiteten Daten bleibt der Anwender verantwortlich.\nServer-Logfiles # Beim Aufruf der Website werden durch den Hosting-Anbieter automatisch Daten erfasst und in Server-Logfiles gespeichert. Erfasst werden können insbesondere:\nverwendeter Browsertyp nebst Version verwendetes Betriebssystem die zuvor besuchte Internetseite (Referrer) Name der abgerufenen Seite und übertragene Datenmenge Datum und Uhrzeit des Zugriffs die IP-Adresse des zugreifenden Systems der Internet-Service-Provider des zugreifenden Systems Diese Daten dienen ausschließlich dem technisch fehlerfreien Betrieb, der Sicherheit und der Auslieferung der Website. Eine Zusammenführung mit anderen Datenquellen oder eine personenbezogene Auswertung findet nicht statt. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren und stabilen Betrieb der Website). Die Logfiles werden nur so lange gespeichert, wie dies für diese Zwecke erforderlich ist; eine längere Speicherung erfolgt nur bei konkreten Anhaltspunkten für eine rechtswidrige Nutzung.\nHosting # Die Website wird bei der Host Europe GmbH, Hansestraße 111, 51149 Köln, Deutschland, gehostet; die Server befinden sich in Deutschland. Der Anbieter verarbeitet die oben genannten Server-Logfiles in unserem Auftrag auf Grundlage eines Auftragsverarbeitungsvertrags gemäß Art. 28 DSGVO. Weitere Informationen zum Datenschutz beim Hosting-Anbieter finden Sie unter https://www.hosteurope.de/AGB/Datenschutzerklaerung/.\nCookies und lokale Speicherung # Diese Website setzt nur technisch notwendige Mittel ein. Für die Darstellung (z. B. die gewählte Hell-/Dunkel-Ansicht) und die seiteninterne Suche werden Einstellungen im lokalen Speicher Ihres Browsers (Local Storage) abgelegt. Diese Daten verbleiben in Ihrem Browser und werden nicht an uns übertragen.\nEine Webanalyse oder ein Tracking zu Marketing- oder Statistikzwecken (z. B. Google Analytics, Google Ads) findet derzeit nicht statt. Sollten künftig optionale Cookies oder vergleichbare Technologien zu Analyse- oder Marketingzwecken eingesetzt werden, geschieht dies nur nach Ihrer vorherigen Einwilligung (Art. 6 Abs. 1 lit. a DSGVO), die Sie jederzeit mit Wirkung für die Zukunft widerrufen können.\nDie meisten Browser sind so eingestellt, dass sie Cookies und lokalen Speicher akzeptieren. Sie können diese in den Browser-Einstellungen einschränken oder löschen; hierdurch kann der Funktionsumfang der Website eingeschränkt werden.\nKontaktaufnahme per E-Mail # Wenn Sie uns per E-Mail kontaktieren, werden die von Ihnen übermittelten Daten (z. B. Name und E-Mail-Adresse) zum Zweck der Bearbeitung Ihrer Anfrage gespeichert. Eine Weitergabe zu Werbezwecken erfolgt nicht. Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (vorvertragliche Maßnahmen bzw. Vertragserfüllung), im Übrigen Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Bearbeitung von Anfragen). Die Daten werden gelöscht, sobald sie für die Bearbeitung nicht mehr erforderlich sind und keine gesetzlichen Aufbewahrungspflichten entgegenstehen.\nDownload und Quellcode über GitHub # csv2zugferd wird über GitHub Releases bereitgestellt; der Quellcode ist auf GitHub öffentlich verfügbar. Anbieter ist die GitHub, Inc. (88 Colin P. Kelly Jr. Street, San Francisco, CA 94107, USA), ein Unternehmen von Microsoft.\nWenn Sie einen GitHub-Link auf dieser Website anklicken oder eine Datei von GitHub herunterladen, wird eine Verbindung zu den Servern von GitHub aufgebaut. Dabei werden Daten (insbesondere Ihre IP-Adresse sowie technische Verbindungsdaten) an GitHub übermittelt und können in ein Drittland (USA) übertragen werden. Auf diese Verarbeitung haben wir keinen Einfluss; sie erfolgt in der Verantwortung von GitHub. Rechtsgrundlage für die Einbindung der Verweise ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an der Bereitstellung von Quellcode und Downloads). Informationen zur Datenverarbeitung durch GitHub finden Sie unter https://docs.github.com/site-policy/privacy-policies/github-general-privacy-statement.\nWenn Sie über GitHub Issues Fehler melden, beachten Sie bitte: Stellen Sie keine sensiblen oder personenbezogenen Rechnungsdaten in öffentliche Issues ein. Verwenden Sie hierfür ausschließlich anonymisierte Beispiel- oder Testdaten.\nDatenübermittlung an Dritte # Eine Übermittlung Ihrer personenbezogenen Daten an Dritte erfolgt nur, wenn hierfür eine datenschutzrechtliche Grundlage besteht, insbesondere wenn\nSie nach Art. 6 Abs. 1 lit. a DSGVO ausdrücklich eingewilligt haben, dies nach Art. 6 Abs. 1 lit. b DSGVO zur Bearbeitung Ihrer Anfrage erforderlich ist, nach Art. 6 Abs. 1 lit. c DSGVO eine gesetzliche Verpflichtung besteht, die Weitergabe nach Art. 6 Abs. 1 lit. f DSGVO zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen erforderlich ist, oder wir Dienstleister als Auftragsverarbeiter gemäß Art. 28 DSGVO einsetzen (z. B. Hosting-Anbieter). Soweit dabei Daten an Empfänger in einem Drittland (insbesondere USA, z. B. im Zusammenhang mit GitHub) übermittelt werden, erfolgt dies auf Grundlage geeigneter Garantien bzw. der Verantwortlichkeit des jeweiligen Anbieters.\nSpeicherdauer # Wir verarbeiten und speichern personenbezogene Daten nur für den Zeitraum, der zur Erreichung des jeweiligen Zwecks erforderlich ist oder durch gesetzliche Aufbewahrungspflichten vorgegeben wird. Nach Wegfall des Zwecks oder Ablauf der Fristen werden die Daten routinemäßig gelöscht.\nDatensicherheit # Wir treffen angemessene technische und organisatorische Maßnahmen, um Ihre Daten vor Verlust, Missbrauch und unbefugtem Zugriff zu schützen, und verbessern diese entsprechend der technologischen Entwicklung fortlaufend. Bei der Auslieferung der Website kommt eine TLS-Verschlüsselung zum Einsatz. Internetbasierte Datenübertragungen können jedoch grundsätzlich Sicherheitslücken aufweisen; ein absoluter Schutz vor dem Zugriff durch Dritte ist nicht möglich.\nIhre Rechte als betroffene Person # Nach der DSGVO stehen Ihnen folgende Rechte zu:\nRecht auf Auskunft (Art. 15 DSGVO) Recht auf Berichtigung (Art. 16 DSGVO) Recht auf Löschung (Art. 17 DSGVO) Recht auf Einschränkung der Verarbeitung (Art. 18 DSGVO) Recht auf Datenübertragbarkeit (Art. 20 DSGVO) Recht auf Widerspruch gegen die Verarbeitung (Art. 21 DSGVO) Recht auf jederzeitigen Widerruf einer erteilten Einwilligung mit Wirkung für die Zukunft (Art. 7 Abs. 3 DSGVO) Zur Ausübung Ihrer Rechte oder bei Fragen zur Verarbeitung Ihrer Daten können Sie sich jederzeit an info@rillsoft.de wenden.\nBeschwerderecht bei einer Aufsichtsbehörde # Unbeschadet anderweitiger Rechtsbehelfe steht Ihnen nach Art. 77 DSGVO ein Beschwerderecht bei einer Datenschutz-Aufsichtsbehörde zu, wenn Sie der Ansicht sind, dass die Verarbeitung Ihrer personenbezogenen Daten gegen datenschutzrechtliche Bestimmungen verstößt.\nÄnderungen dieser Datenschutzerklärung # Wir passen diese Datenschutzerklärung an, wenn sich die Rechtslage oder die tatsächliche Datenverarbeitung ändert. Es gilt jeweils die hier veröffentlichte aktuelle Fassung.\nStand: 23. Mai 2026\n","date":"23. Mai 2026","externalUrl":null,"permalink":"/datenschutz/","section":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","summary":"","title":"Datenschutz","type":"page"},{"content":"zugferd-tools.de ist die Informations- und Download-Website für das Open-Source-Werkzeug csv2zugferd. Herausgeberin und Maintainerin ist die Rillsoft GmbH.\nAngaben gemäß § 5 DDG # Anbieter:Rillsoft GmbH Mollenbachstr. 14 71229 Leonberg, Deutschland Vertreten durch:Dimitri Sapunou (Geschäftsführer) Tel.:+49 7152 30725570 E-Mail:info@rillsoft.de Website:www.rillsoft.de Handelsregister:Amtsgericht Leonberg, HRB 3053 Umsatzsteuer-IdNr.:DE222015909 Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV # Dimitri Sapunou, Rillsoft GmbH, Mollenbachstr. 14, 71229 Leonberg, Deutschland.\nMarkenhinweis # zugferd-tools.de ist kein offizielles Angebot des Forums elektronische Rechnung Deutschland (FeRD) e. V. ZUGFeRD® ist eine Marke des FeRD e. V.; Factur-X ist eine Bezeichnung des FNFE-MPE. Die Nennung dieser Bezeichnungen dient ausschließlich der Beschreibung der unterstützten Formate und begründet keine Verbindung zu oder Anerkennung durch die Markeninhaber.\nHaftung für Inhalte # Diese Website wurde mit größtmöglicher Sorgfalt erstellt. Für die Richtigkeit, Vollständigkeit und Aktualität der Inhalte können wir jedoch keine Gewähr übernehmen. Als Diensteanbieter sind wir gemäß § 7 Abs. 1 DDG für eigene Inhalte auf diesen Seiten nach den allgemeinen Gesetzen verantwortlich. Nach §§ 8 bis 10 DDG sind wir als Diensteanbieter jedoch nicht verpflichtet, übermittelte oder gespeicherte fremde Informationen zu überwachen oder nach Umständen zu forschen, die auf eine rechtswidrige Tätigkeit hinweisen.\ncsv2zugferd wird als Open-Source-Werkzeug ohne Gewähr bereitgestellt. Die erzeugten XML- und PDF-Dateien müssen vor produktiver Nutzung fachlich und technisch geprüft werden. Das Werkzeug ersetzt keine steuerliche, rechtliche oder fachliche Beratung; für die Richtigkeit, Vollständigkeit und steuerliche Bewertung der Eingabe- und Ausgabedaten bleibt der Anwender verantwortlich. Maßgeblich sind die Lizenzbedingungen (Apache-2.0).\nHaftung für Links # Unser Angebot enthält Links zu externen Websites Dritter (z. B. GitHub), auf deren Inhalte wir keinen Einfluss haben. Deshalb können wir für diese fremden Inhalte auch keine Gewähr übernehmen. Für die Inhalte der verlinkten Seiten ist stets der jeweilige Anbieter oder Betreiber verantwortlich. Bei Bekanntwerden von Rechtsverletzungen entfernen wir derartige Links umgehend.\nUrheberrecht # Die durch die Betreiberin erstellten Inhalte und Werke auf diesen Seiten unterliegen dem deutschen Urheberrecht. Vervielfältigung, Bearbeitung, Verbreitung und jede Art der Verwertung außerhalb der Grenzen des Urheberrechts bedürfen der schriftlichen Zustimmung der Rillsoft GmbH.\nDer Quellcode von csv2zugferd wird hiervon unberührt unter der Lizenz Apache-2.0 bereitgestellt und kann gemäß deren Bedingungen genutzt werden.\nVerbraucherstreitbeilegung # Wir sind nicht bereit und nicht verpflichtet, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen.\n","date":"23. Mai 2026","externalUrl":null,"permalink":"/impressum/","section":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","summary":"","title":"Impressum","type":"page"},{"content":"csv2zugferd erzeugt die ZUGFeRD-XML-Datei und bettet sie in die PDF/A-3-Ausgabe ein. Die fachliche und technische Prüfung liegt beim Anwender. Zwei kostenlose Validierungs-Tools erleichtern diesen Schritt.\nHinweis vor dem Hochladen # Rechnungen enthalten typischerweise sensible Geschäftsdaten: Empfängername und -adresse, Leistungsbeschreibung, Beträge und Steuernummern. Vor dem Hochladen einer echten Rechnung:\nDatenschutzerklärung und Nutzungsbedingungen des jeweiligen Dienstes prüfen. Für erste Tests eine Rechnung mit fiktiven Testdaten verwenden, keine Produktivdaten. Interne Richtlinien zum Umgang mit Rechnungsdaten beachten. ELSTER E-Rechnungsportal # Das E-Rechnungsportal der Finanzverwaltung nimmt ZUGFeRD- und XRechnung-Dateien entgegen und prüft sie auf strukturelle Konformität.\nE-Rechnungsportal auf elster.de öffnen →\nGeeignet für: ZUGFeRD 2.x, XRechnung — keine Anmeldung für die Prüffunktion erforderlich.\ne-rechnungs-checker.de # Ein schneller Online-Validator für strukturierte Rechnungsformate. Lädt die XML- oder PDF/A-3-Datei hoch und zeigt Konformitätsfehler im Detail an.\ne-rechnungs-checker.de öffnen →\nWas die Tools prüfen # Beide Dienste prüfen die strukturelle Konformität der XML-Daten gegen die ZUGFeRD- bzw. EN-16931-Spezifikation:\nPflichtfelder vorhanden und korrekt befüllt Feldformate (Datum, Betrag, Steuersatz) Namespace und Schema-Version bei PDF/A-3: korrekte Einbettung des XML-Anhangs Was sie nicht prüfen: inhaltliche oder steuerliche Richtigkeit der Rechnungsdaten — das liegt beim Anwender.\nEmpfohlener Ablauf # csv2zugferd erzeugt die Ausgabedatei (PDF/A-3 oder XML). Ausgabedatei im ELSTER-Portal oder e-rechnungs-checker.de hochladen. Konformitätsfehler beheben — meist im YAML-Mapping oder in den CSV-Quelldaten. Erst nach erfolgreicher Prüfung produktiv einsetzen. Haftungsausschluss # Eine fehlerfreie Validierung bestätigt die strukturelle Konformität der Datei — nicht die steuerliche oder rechtliche Richtigkeit der Rechnungsdaten. csv2zugferd wird ohne Gewähr bereitgestellt. Für die inhaltliche Richtigkeit, Vollständigkeit und steuerliche Bewertung der Rechnungsdaten bleibt der Anwender verantwortlich. Eine strukturell konforme ZUGFeRD-Datei ist keine Garantie dafür, dass die ausgewiesenen Beträge, Steuersätze oder Empfängerdaten korrekt sind. Das Tool ersetzt keine steuerliche, rechtliche oder fachliche Beratung. Weitere Angaben finden Sie im Impressum und in der Datenschutzerklärung.\n","date":"23. Mai 2026","externalUrl":null,"permalink":"/docs/validierung/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"ZUGFeRD Rechnung validieren – kostenlose Prüf-Tools","type":"docs"},{"content":"Technische Einordnungen rund um ZUGFeRD, E-Rechnungspflicht und CSV-Workflows:\nCSV zu ZUGFeRD ZUGFeRD ohne Cloud E-Rechnungspflicht 2025 bis 2028 Welche ZUGFeRD-Profile erfüllen die E-Rechnungspflicht? E-Rechnungen aufbewahren – 8 Jahre GoBD-konform ZUGFeRD mit C# und .NET erzeugen ","date":"22. Mai 2026","externalUrl":null,"permalink":"/artikel/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","type":"artikel"},{"content":"Als CLI eignet sich csv2zugferd für Skripte, geplante Aufgaben und interne Rechnungsworkflows.\nGet-ChildItem .\\input -Filter *.csv | ForEach-Object { .\\csv2zugferd-win-x64.exe ` --csv $_.FullName ` --pdf \u0026#34;.\\pdf\\$($_.BaseName).pdf\u0026#34; ` --config \u0026#34;.\\config.yml\u0026#34; ` --output \u0026#34;.\\out\u0026#34; } Für produktive Workflows sollten Logs, Exit-Codes, Prüfschritte und eine fachliche Stichprobenkontrolle eingeplant werden.\nWeiterführend: PowerShell-Batch-Beispiel.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/batch-verarbeitung/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"Batch-Verarbeitung – mehrere ZUGFeRD-Rechnungen per CLI","type":"docs"},{"content":"Die Beispiele zeigen typische CSV-Strukturen und passende Aufrufe.\nSchnellstart – Demo-Paket Rows-Modus Columns mit Suffix Columns mit Prefix Datasrc mit globaler Steuer Excel-Export PowerShell-Batch ","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/","section":"Beispiele","summary":"","title":"Beispiele","type":"beispiele"},{"content":"Beim Prefix-Format steht die Positionsnummer vor dem Feldnamen.\nRechnungsnummer;1Menge;1Preis;1Beschreibung;2Menge;2Preis;2Beschreibung 471102;2;120.00;Beratung;1;80.00;Support .\\csv2zugferd-win-x64.exe --csv test_columns_prefix.csv --pdf invoice.pdf --config config_columns_prefix.yml --output out ","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/columns-prefix/","section":"Beispiele","summary":"","title":"Columns mit Prefix","type":"beispiele"},{"content":"Bei diesem Format liegen mehrere Positionen in einer CSV-Zeile.\nINVOICE_NO,INVOICE_TAX,PRODUCT_NAME_0,PRODUCT_QUANTITY_0,PRODUCT_PRICE_0,PRODUCT_NAME_1,PRODUCT_QUANTITY_1,PRODUCT_PRICE_1 0002483,19.00,Rillsoft Cloud Standard,1,1440.00,,, .\\csv2zugferd-win-x64.exe --csv .\\test\\datasrc.csv --pdf .\\test\\2483.pdf --config .\\test\\config_datasrc.yml --output .\\test\\output Dieses Muster ist typisch für CRM- oder ERP-Exporte, bei denen die Positionen nummeriert sind, Steuer und Summen aber als globale Rechnungsfelder vorliegen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/columns-suffix/","section":"Beispiele","summary":"","title":"Columns mit Suffix","type":"beispiele"},{"content":"CSV ist kein Rechnungsstandard, aber ein praktisches Austauschformat. Viele bestehende Systeme können Rechnungsdaten zuverlässig als CSV exportieren.\ncsv2zugferd setzt genau dort an: Die CSV enthält die strukturierten Rechnungsdaten, die PDF-Vorlage enthält den sichtbaren Beleg, und das Tool erzeugt daraus eine ZUGFeRD-Ausgabe.\nDer Vorteil liegt in der Wiederholbarkeit. Statt Rechnungsdaten aus PDFs zu erraten, wird eine stabile Datenquelle gemappt.\nDas Mapping geschieht über eine YAML-Datei: YAML-Konfiguration.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/artikel/csv-zu-zugferd/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"CSV zu ZUGFeRD – Strukturierte Rechnungsdaten konvertieren","type":"artikel"},{"content":"Ein PDF-Konverter ist bequem, wenn nur einzelne Rechnungen ohne strukturierten Datenexport verarbeitet werden sollen.\nEin CSV-Workflow ist robuster, wenn Rechnungsdaten bereits aus CRM, ERP oder Warenwirtschaft exportiert werden können.\nFrage Besser passend Einzelne PDF manuell umwandeln Online-Konverter Viele Rechnungen aus CSV verarbeiten csv2zugferd Keine Rechnungsdaten hochladen csv2zugferd Daten aus PDF nachträglich erkennen Online-Konverter Wiederholbarer interner Prozess csv2zugferd Einstieg: csv2zugferd installieren.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/vergleich/csv-zu-zugferd-vs-pdf-konverter/","section":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","summary":"","title":"CSV zu ZUGFeRD vs. PDF-Konverter – Unterschiede","type":"vergleich"},{"content":"csv2zugferd unterstützt mehrere CSV-Strukturen.\nrows # Im rows-Modus steht jede Rechnungsposition in einer eigenen Zeile. Gemeinsame Rechnungsdaten werden wiederholt oder gruppiert.\nGeeignet für:\nERP-Exporte mit einer Position pro Zeile Rechnungen mit variabler Positionsanzahl gut prüfbare tabellarische Daten columns mit suffix # Im Columns-Suffix-Modus stehen Positionen in nummerierten Spalten:\nPRODUCT_NAME_0;PRODUCT_QUANTITY_0;PRODUCT_PRICE_0;PRODUCT_NAME_1;PRODUCT_QUANTITY_1;PRODUCT_PRICE_1 Typische Konfiguration:\nlineItems: mode: \u0026#34;columns\u0026#34; columnPattern: style: \u0026#34;suffix\u0026#34; separator: \u0026#34;_\u0026#34; startIndex: 0 zeroPadding: 0 columns mit prefix # Im Columns-Prefix-Modus steht die Nummer vor dem Feldnamen:\n1_Menge;1_Preis;1_Beschreibung;2_Menge;2_Preis;2_Beschreibung Typische Konfiguration:\nlineItems: mode: \u0026#34;columns\u0026#34; columnPattern: style: \u0026#34;prefix\u0026#34; prefix: \u0026#34;\u0026#34; separator: \u0026#34;_\u0026#34; startIndex: 1 zeroPadding: 0 Globale Rechnungsfelder im columns-Modus # Im columns-Modus können Positionsfelder nummeriert sein, während andere Werte global einmal pro Rechnung vorliegen.\nBeispiel:\nfields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; billedQuantity: column: \u0026#34;PRODUCT_QUANTITY\u0026#34; netUnitPrice: column: \u0026#34;PRODUCT_PRICE\u0026#34; taxPercent: column: \u0026#34;INVOICE_TAX\u0026#34; Dabei wird PRODUCT_NAME_0 als Positionsspalte gelesen, INVOICE_TAX dagegen als globale Einzelspalte für alle Positionen derselben Rechnung.\nDiese Modi sind praktisch, wenn ein CRM oder eine Tabellenkalkulation eine Rechnung vollständig in einer Zeile exportiert.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/csv-modi/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"CSV-Modi – rows, columns-suffix und columns-prefix","type":"docs"},{"content":".\\csv2zugferd-win-x64.exe [options] Option Kurz Pflicht Beschreibung --csv -c ja Pfad zur CSV-Datei mit Rechnungsdaten --pdf -p ja Pfad zur PDF-Vorlage --config -g ja Pfad zur YAML-Konfigurationsdatei --output -o nein Ausgabeverzeichnis --xml-only nein Nur XML erzeugen, kein PDF --verbose -v nein Debug-Ausgabe aktivieren --config ist Pflicht, weil csv2zugferd CSV-Parsing, Mapping und ZUGFeRD-Ausgabe immer aus einer expliziten YAML-Datei lädt.\n--pdf ist auch dann Pflicht, wenn mit --xml-only nur XML erzeugt werden soll. Ohne --xml-only wird zusätzlich eine ZUGFeRD-PDF geschrieben.\nDie Beispiele verwenden .\\csv2zugferd-win-x64.exe, weil dies der Dateiname des Windows-Downloads aus den Releases ist.\nBeispiele # Nur XML erzeugen:\n.\\csv2zugferd-win-x64.exe --csv .\\test\\datasrc.csv --pdf .\\test\\2483.pdf --config .\\test\\config.yml --output .\\test\\output --xml-only XML und PDF erzeugen:\n.\\csv2zugferd-win-x64.exe --csv .\\test\\datasrc.csv --pdf .\\test\\2483.pdf --config .\\test\\config.yml --output .\\test\\output Für die YAML-Konfigurationsdatei: YAML-Konfiguration. Praxisbeispiel: Beispiel im rows-Modus.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/cli-parameter/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"csv2zugferd CLI-Parameter – alle Optionen im Überblick","type":"docs"},{"content":"Der Fokus der Dokumentation liegt auf reproduzierbaren CSV-Workflows: strukturierte Eingabedaten, YAML-Mapping und lokale Ausgabe von ZUGFeRD-Dateien.\nEinstieg # Schnellstart – Demo-Paket Installation CLI-Parameter YAML-Konfiguration KI-Hilfe für config.yml CSV-Modi PDF-Vorlage Batch-Verarbeitung Fehlerbehandlung Validierung BT-Felder # BT-Felder in ZUGFeRD mit csv2zugferd – Übersicht und Einstieg BT-44 Käufername BT-13 Bestellnummer BT-72 Lieferdatum BT-153 Positionsbezeichnung BT-155 Verkäufer-Artikelnummer BT-131 Zeilennettobetrag BT-152 Umsatzsteuersatz je Position BT-9 Fälligkeitsdatum ","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","type":"docs"},{"content":" csv2zugferd ist als Windows-x64-CLI verfügbar. Download über GitHub Releases. Der Quellcode ist unter Apache-2.0 veröffentlicht.\nGitHub Releases öffnen Release-Umfang # Windows-x64-Exe (self-contained, kein .NET erforderlich) SHA256-Prüfsumme pro Release-Datei Release Notes mit bekannten Änderungen Demo-Paket mit Beispiel-Rechnungen und fertiger YAML-Konfiguration Quellcode und Build-Hinweise auf GitHub Lizenz: Apache-2.0 Beispiel # .\\csv2zugferd-win-x64.exe --csv invoices.csv --pdf invoice.pdf --config config.yml --output out Signatur und Prüfsumme # Zu jedem Release wird eine SHA256-Prüfsumme bereitgestellt. Eine Signatur bestätigt die Herkunft der Datei und die Integrität des Downloads — sie ist keine Garantie für die fachliche oder steuerliche Richtigkeit der erzeugten Rechnungen.\nSystemanforderungen # Windows x64. Die Exe ist self-contained — eine separate .NET-Installation ist nicht erforderlich. Weitere Distributionsformen wie NuGet Global Tool, Docker, Winget oder Scoop werden geprüft.\nErzeugte Dateien prüfen # Vor dem produktiven Einsatz empfiehlt sich eine Validierung der erzeugten XML- oder PDF/A-3-Datei. ELSTER und e-rechnungs-checker.de bieten dafür kostenlose Prüf-Tools an.\nZUGFeRD-Validierung: verfügbare Tools →\nHaftungsausschluss # csv2zugferd wird ohne Gewähr bereitgestellt. Die erzeugten XML- und PDF-Dateien müssen vor produktiver Nutzung fachlich und technisch geprüft werden. Das Tool ersetzt keine steuerliche, rechtliche oder fachliche Beratung. Für die Richtigkeit, Vollständigkeit und steuerliche Bewertung der Eingabe- und Ausgabedaten bleibt der Anwender verantwortlich. Die Bereitstellung erfolgt zu den Bedingungen der Lizenz Apache-2.0, die einen Gewährleistungs- und Haftungsausschluss enthält. Weitere Angaben finden Sie im Impressum und in der Datenschutzerklärung.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/download/","section":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","summary":"","title":"csv2zugferd Download – ZUGFeRD CLI für Windows","type":"page"},{"content":"csv2zugferd ist als Windows-x64-Exe über die GitHub-Release-Seite verfügbar. Eine klassische Installation ist nicht nötig.\nOption 1 — Demo-Paket (empfohlen für den Einstieg) # Das Demo-Paket enthält die Exe, zwei fertige Beispiel-Rechnungen, eine YAML-Konfiguration und ein Startskript. Kein eigenes CSV nötig.\nDemo-ZIP aus den GitHub Releases herunterladen. Alle Dateien in einen Ordner entpacken. create-zugferd-demo.cmd per Doppelklick starten. Ergebnis im Unterordner output\\ prüfen. → Demo-Paket im Detail\nOption 2 — Einzel-Exe # Release auf GitHub öffnen. csv2zugferd-win-x64.exe herunterladen. SHA256-Prüfsumme prüfen. Exe in ein lokales Tool-Verzeichnis legen. .\\csv2zugferd-win-x64.exe --help Die Exe kann direkt verwendet und optional in den PATH aufgenommen werden.\n→ Windows-Exe herunterladen\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/installation/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"csv2zugferd installieren – Setup und Voraussetzungen","type":"docs"},{"content":"Die Datei test\\datasrc.csv enthält eine komplette Rechnung in genau einer CSV-Zeile.\nTypische Merkmale:\nPositionen stehen in Suffix-Spalten wie PRODUCT_NAME_0, PRODUCT_PRICE_0 Steuer und Summen stehen global pro Rechnung in Spalten wie INVOICE_TAX, INVOICE_TOTAL als PDF-Vorlage wird eine echte Datei verwendet, hier test\\2483.pdf Passender Aufruf:\n.\\csv2zugferd-win-x64.exe --csv .\\test\\datasrc.csv --pdf .\\test\\2483.pdf --config .\\test\\config.yml --output .\\test\\output Wichtiger Ausschnitt aus der YAML-Konfiguration:\nlineItems: mode: \u0026#34;columns\u0026#34; columnPattern: style: \u0026#34;suffix\u0026#34; separator: \u0026#34;_\u0026#34; startIndex: 0 zeroPadding: 0 fields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; netUnitPrice: column: \u0026#34;PRODUCT_PRICE\u0026#34; billedQuantity: column: \u0026#34;PRODUCT_QUANTITY\u0026#34; taxPercent: column: \u0026#34;INVOICE_TAX\u0026#34; Dabei wird INVOICE_TAX nicht als Positionsspalte gesucht, sondern als globale Rechnungs-Spalte gelesen und auf jede erzeugte Position angewendet.\nFür einen XML-Testlauf kann derselbe Aufruf mit --xml-only ergänzt werden. Das Testskript test\\test.cmd verwendet bewusst die echte 2483.pdf statt einer leeren Dummy-Datei.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/datasrc-globale-steuer/","section":"Beispiele","summary":"","title":"Datasrc mit globaler Steuer","type":"beispiele"},{"content":"Die deutsche E-Rechnungspflicht schreibt vor, dass inländische B2B-Rechnungen ab Januar 2025 in einem strukturierten elektronischen Format nach EN 16931 empfangen werden müssen. Ab 2027 und 2028 gilt gestaffelt nach Unternehmensgröße auch die Ausstellungspflicht.\nNicht jedes CRM, ERP oder Altsystem kann sofort ZUGFeRD oder XRechnung ausgeben. Wenn ein System aber CSV und PDF liefern kann, ist ein lokales Konvertierungswerkzeug ein pragmatischer Zwischenschritt.\nDiese Seite ist eine technische Einordnung und keine Rechts- oder Steuerberatung. Fristen im Überblick # Zeitraum Pflicht Betroffene Ab 1. Januar 2025 Empfangspflicht Alle inländischen B2B-Rechnungsempfänger Ab 1. Januar 2027 Ausstellungspflicht Unternehmen mit Vorjahresumsatz über 800.000 EUR Ab 1. Januar 2028 Ausstellungspflicht Alle übrigen inländischen B2B-Rechnungssteller Die Fristen beziehen sich auf inländische B2B-Transaktionen. B2C und grenzüberschreitende Rechnungen fallen nicht unter dieselbe Regelung.\nErlaubte Formate # Die gesetzliche Anforderung verlangt ein strukturiertes elektronisches Format nach EN 16931. In Deutschland sind das vor allem:\nZUGFeRD (hybrides PDF/A-3 mit eingebettetem XML) XRechnung (reines XML, kein sichtbares PDF) Factur-X (entspricht ZUGFeRD, für den deutsch-französischen Kontext) Ein einfaches PDF ohne strukturierten XML-Anteil erfüllt die Anforderungen ab 2027/2028 nicht mehr.\nWas csv2zugferd beiträgt # csv2zugferd erzeugt ZUGFeRD-konforme PDF/A-3-Dateien mit eingebettetem XML aus bestehenden CSV-Exporten und einer Rechnungs-PDF. Das Tool ist kein Buchhaltungssystem und ersetzt keine steuerliche oder rechtliche Prüfung der erzeugten Rechnungen.\nTypischer Einsatzfall: Ein CRM oder ERP exportiert Rechnungsdaten als CSV. Eine PDF-Vorlage liegt bereits vor. csv2zugferd kombiniert beides zu einer ZUGFeRD-Rechnung – lokal, ohne Upload, automatisierbar.\nVor dem produktiven Einsatz sollten erzeugte Rechnungen fachlich und technisch geprüft werden.\nFür einen direkten Vergleich mit SaaS-Alternativen: lokales CLI vs. SaaS für E-Rechnungen. Download: csv2zugferd kostenlos herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/artikel/e-rechnungspflicht-2025-2028/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"E-Rechnungspflicht 2025 bis 2028 – Fristen und Formate","type":"artikel"},{"content":"Viele Teams pflegen Rechnungsdaten in Excel oder erhalten CSV-Exporte aus CRM- und ERP-Systemen.\nEmpfehlung:\nein festes Spaltenlayout definieren CSV-Trennzeichen dokumentieren Zahlen- und Datumsformat stabil halten bei columns klar zwischen Positionsspalten und globalen Rechnungsfeldern unterscheiden YAML-Mapping versionieren Danach kann dieselbe Konfiguration wiederholt genutzt werden.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/excel-export/","section":"Beispiele","summary":"","title":"Excel-Export","type":"beispiele"},{"content":"ZUGFeRD und Factur-X bezeichnen denselben technischen Standard für hybride elektronische Rechnungen. ZUGFeRD ist der deutsche Name, Factur-X der französische und europäische Name für dieselbe Spezifikation. Beide basieren auf EN 16931 im CII-Format (Cross Industry Invoice) und sind seit ZUGFeRD 2.1 / Factur-X 1.0 vollständig kompatibel – eine Factur-X-Rechnung ist gleichzeitig eine gültige ZUGFeRD-Rechnung.\nTechnischer Aufbau # Das hybride Format bettet maschinenlesbares XML in eine PDF/A-3-Datei ein. Der sichtbare Teil ist die normale Rechnungs-PDF. Der eingebettete XML-Anteil enthält alle strukturierten Rechnungsdaten nach dem CII-Datenmodell.\nVerschiedene Profile steuern den Umfang der Pflichtfelder:\nProfil Inhalt MINIMUM Rechnungskopf ohne vollständige Positionsdaten BASIC WL Rechnungskopf und Positionen ohne Einzelpreise BASIC Vollständige Rechnung, EN-16931-konform EN 16931 (COMFORT) Standardprofil, vollständig normkonform EXTENDED Erweitertes Profil für nationale Zusatzfelder csv2zugferd erzeugt standardmäßig das Extended-Profil.\nWarum ZUGFeRD auf dieser Website? # Im deutschen Markt ist ZUGFeRD der verbreitetere Suchbegriff. Factur-X ist der relevante Begriff im französischen und internationalen Kontext. Technisch erzeugt csv2zugferd Dateien, die beiden Bezeichnungen entsprechen.\nEinstieg: CSV zu ZUGFeRD – Einführung. Tool: csv2zugferd herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/factur-x/","section":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","summary":"","title":"Factur-X und ZUGFeRD – Gemeinsamkeiten und Unterschiede","type":"page"},{"content":"ZUGFeRD und Factur-X sind seit ZUGFeRD 2.1 / Factur-X 1.0 technisch identisch. Ein als Factur-X 1.0 erzeugtes Dokument ist gleichzeitig ein gültiges ZUGFeRD 2.1-Dokument. Der Unterschied liegt ausschließlich im Namen und der regionalen Verbreitung.\nVersionsgeschichte # Version Standard Basis Kompatibilität ZUGFeRD 1.0 (2014) Nur Deutschland Eigenes Datenmodell Nicht kompatibel mit Factur-X ZUGFeRD 2.0 (2018) Deutschland EN 16931, CII Annäherung an Factur-X Factur-X 1.0 / ZUGFeRD 2.1 (2019) Deutschland + Frankreich EN 16931, CII Vollständig harmonisiert ZUGFeRD 2.2 / Factur-X 1.0.06 Deutschland + Frankreich EN 16931, CII Fehlerkorrekturen, equivalent ZUGFeRD 2.3 / Factur-X 1.0.07 Deutschland + Frankreich EN 16931, CII Aktuelle Version ZUGFeRD 1.0 ist nicht mit Factur-X kompatibel. Für neue Implementierungen ist ausschließlich ZUGFeRD 2.x / Factur-X 1.x relevant.\nProfilzuordnung # Beide Standards verwenden dieselben Profile mit denselben technischen Inhalten:\nZUGFeRD-Bezeichnung Factur-X-Bezeichnung Inhalt MINIMUM MINIMUM Rechnungskopfdaten, keine vollständigen Positionsdaten BASIC WL BASIC WL Kopf und Positionen, ohne Einzelpreise BASIC BASIC Vollständige Rechnung, EN-16931-konform COMFORT EN 16931 Standardprofil, vollständig normkonform EXTENDED EXTENDED Erweitertes Profil für nationale Zusatzfelder csv2zugferd erzeugt standardmäßig das Extended-Profil.\nTechnisches Format # Beide Standards verwenden:\nPDF/A-3 als Containerformat für die hybride Rechnung CII (Cross Industry Invoice, UN/CEFACT) als XML-Datenmodell EN 16931 als semantische Grundlage (ab ZUGFeRD 2.0 / Factur-X 1.0) Das eingebettete XML trägt ab ZUGFeRD 2.1 den Dateinamen factur-x.xml – unabhängig davon, ob das Dokument als ZUGFeRD oder Factur-X bezeichnet wird.\nRegionale Verwendung # Region Bezeichnung Herausgeber Deutschland ZUGFeRD FeRD (Forum elektronische Rechnung Deutschland) Frankreich Factur-X FNFE-MPE Europa allgemein Factur-X Harmonisiertes EU-Format Weiterführend: Factur-X und ZUGFeRD – Überblick. Tool: csv2zugferd herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/vergleich/factur-x-vs-zugferd/","section":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","summary":"","title":"Factur-X vs. ZUGFeRD – Versionsgeschichte und Kompatibilität","type":"vergleich"},{"content":"Typische Fehlerquellen:\nCSV-Trennzeichen passt nicht zur Konfiguration Spaltenname fehlt oder ist anders geschrieben globale Rechnungsfelder im columns-Modus sind falsch als Positionsspalten konfiguriert oder umgekehrt Zahlenformat passt nicht zur erwarteten Kultur Pflichtfelder für die Rechnung fehlen PDF-Datei ist nicht lesbar oder nicht vorhanden PDF und XML enthalten fachlich abweichende Rechnungsdaten lokaler Build erfolgt mit einem zu alten .NET SDK statt mit .NET 10 Schnelle Diagnose # Für Konfigurationsfehler ist --verbose der erste Schritt. In der Debug-Ausgabe sieht man unter anderem:\nerkannte CSV-Header aktiven lineItems-Modus aufgelöste Feldfragmente im columns-Modus erkannte Positionswerte inklusive MwSt Fehler melden # Bug Reports sollen über GitHub Issues erfolgen. Keine echten Rechnungen, Kundendaten oder vertraulichen Dateien öffentlich hochladen.\nWeiterführend: YAML-Konfiguration – Felddefinitionen und Modus-Übersicht.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/troubleshooting/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"Fehlerbehandlung","type":"docs"},{"content":"Eine KI kann beim ersten Entwurf einer config.yml helfen, wenn bereits eine CSV-Datei aus CRM, ERP oder Excel vorliegt. Die erzeugte Konfiguration ist ein Startpunkt und muss lokal mit csv2zugferd getestet werden.\nGeeignete Modelle sind zum Beispiel ChatGPT, Claude, Gemini, Microsoft Copilot, Mistral Le Chat und Perplexity.\nVor dem Hochladen # Echte Rechnungs- oder Kundendaten dürfen nur hochgeladen werden, wenn das intern erlaubt ist.\nWenn das nicht sicher geklärt ist:\nCSV-Datei anonymisieren Kundennamen, Adressen, IDs und Steuerdaten maskieren ein lokal oder vertraulich betriebenes KI-System verwenden Vorgehen # CSV-Datei in die KI laden. Den Standard-Prompt verwenden. Antwort als config.yml prüfen. Konfiguration lokal mit csv2zugferd testen. Erstellte ZUGFeRD-PDF validieren. XML und PDF vor produktiver Nutzung fachlich und technisch prüfen. Standard-Prompt # Dies ist der Hauptprompt für den ersten Entwurf der config.yml.\nDie weiteren Prompts auf dieser Seite dienen dazu, eine bereits mit diesem Prompt erzeugte config.yml gezielt zu verbessern.\nIch möchte für das Tool csv2zugferd eine config.yml erstellen. Ich habe eine CSV-Datei hochgeladen. Analysiere die Kopfzeile und die Datenstruktur und erstelle daraus eine vollständige YAML-Konfiguration für csv2zugferd. Wichtige Dokumentation: - https://zugferd-tools.de/docs/yml-konfiguration/ - https://zugferd-tools.de/docs/csv-modi/ - https://zugferd-tools.de/docs/cli-parameter/ - https://zugferd-tools.de/beispiele/datasrc-globale-steuer/ Aufgabe: 1. Erkenne, ob die CSV eher dem Modus \u0026#34;rows\u0026#34; oder \u0026#34;columns\u0026#34; entspricht. 2. Wenn \u0026#34;columns\u0026#34; verwendet wird, prüfe, ob Positionsfelder nummeriert sind, z. B. PRODUCT_NAME_0, PRODUCT_PRICE_0 usw. 3. Prüfe, ob Steuer- oder Summenfelder global pro Rechnung vorliegen, z. B. INVOICE_TAX, INVOICE_TOTAL, INVOICE_SUBTOTAL. 4. Erstelle eine vollständige config.yml für csv2zugferd. 5. Verwende nur Spaltennamen, die wirklich in der CSV vorkommen. Nichts erfinden. 6. Wenn Informationen fehlen, setze sinnvolle feste Werte per value und markiere diese Annahmen klar. 7. Gib nach der YAML eine kurze Liste mit offenen Fragen oder Unsicherheiten aus. Bitte beachte: - Die Ausgabe soll eine gültige YAML-Datei für csv2zugferd sein. - Verkäufer-Stammdaten dürfen als feste values gesetzt werden, wenn sie nicht in der CSV enthalten sind. - Für lineItems.taxPercent kann im columns-Modus auch eine globale Spalte wie INVOICE_TAX verwendet werden. - totals.mode soll \u0026#34;manual\u0026#34; sein, wenn die CSV bereits Summenfelder enthält, sonst \u0026#34;auto\u0026#34;. - country möglichst als ISO-Code wie DE ausgeben. Strenge Regeln: 1. Erfinde keine YAML-Schlüssel. 2. Verwende keine plausibel klingenden, aber undokumentierten Felder wie z. B. delivery.shipTo, seller.email oder document.notes, wenn diese nicht dokumentiert sind. 3. Wenn ein gewünschter Inhalt nicht mit dokumentierten Feldern abbildbar ist, nimm ihn nicht in die YAML auf, sondern nenne ihn unter „Offene Punkte“. Gib zuerst nur die YAML-Datei aus und danach einen kurzen Abschnitt \u0026#34;Offene Punkte\u0026#34;. Impressum-Prompt # Dieser Prompt dient dazu, eine bereits mit dem Standard-Prompt erzeugte config.yml zu verbessern.\nEr ist für Fälle gedacht, in denen Verkäuferdaten fehlen oder als feste Werte aus dem Impressum gepflegt werden sollen.\nWenn die ausstellende Firma immer gleich ist, ist ein festes seller-Mapping meist robuster als CSV-Spalten für Verkäuferdaten.\nEine KI kann die Werte aus einer Impressum-Seite vorbereiten, zum Beispiel:\nhttps://www.musterfirma.de/impressum/ Danach müssen diese Angaben geprüft werden:\nFirmenname Straße, PLZ, Ort, Land Steuernummer Umsatzsteuer-ID Schemes wie FC für Steuernummer und VA für Umsatzsteuer-ID Ich habe bereits eine config.yml für csv2zugferd erstellt. Ich habe zusätzlich eine bestehende config.yml. Überarbeite die vorhandene config.yml so, dass für seller.name, seller.postalCode, seller.city, seller.street, seller.country und seller.taxRegistrations bevorzugt feste value-Werte aus der Impressum-Seite der ausstellenden Firma verwendet werden. Impressum-Seite: https://www.musterfirma.de/impressum/ Wichtige Dokumentation: - https://zugferd-tools.de/docs/yml-konfiguration/ - https://zugferd-tools.de/docs/csv-modi/ - https://zugferd-tools.de/docs/cli-parameter/ - https://zugferd-tools.de/beispiele/datasrc-globale-steuer/ Aufgabe: 1. Analysiere die bestehende config.yml. 2. Überarbeite die vorhandene config.yml, statt sie unnötig komplett neu zu erfinden. 3. Verwende für seller.name, seller.postalCode, seller.city, seller.street, seller.country und seller.taxRegistrations bevorzugt feste value-Werte aus der Impressum-Seite. 4. Behalte vorhandene seller.value-Einträge bei, wenn sie bereits fachlich korrekt und vollständig sind. 5. Ersetze seller-Spalten-Mappings möglichst durch feste value-Werte aus der Impressum-Seite. 6. Wenn Informationen aus dem Impressum unklar sind, markiere diese Punkte ausdrücklich. Bitte beachte: - Verkäuferdaten sollen nach Möglichkeit als feste values gesetzt werden. - Bestehende Strukturen der config.yml sollen erhalten bleiben, wenn sie bereits korrekt sind. - Für taxRegistrations sollen passende Schemes verwendet werden, zum Beispiel `FC` für Steuernummer und `VA` für Umsatzsteuer-ID. - country möglichst als ISO-Code wie DE ausgeben. - Alle nicht betroffenen Bereiche der config.yml sollen unverändert bleiben. Gib zuerst nur die YAML-Datei aus und danach einen kurzen Abschnitt \u0026#34;Offene Punkte\u0026#34;. Antwort prüfen # Eine brauchbare KI-Antwort sollte:\nden richtigen CSV-Modus wählen nur reale Spaltennamen aus der CSV verwenden globale Rechnungsfelder von Positionsfeldern trennen feste Verkäuferdaten sauber als value setzen, wenn die CSV dafür nicht geeignet ist eine direkt testbare config.yml liefern Unsicherheiten offen benennen Lokal testen # Normaler Lauf mit XML und PDF:\n.\\csv2zugferd-win-x64.exe --csv .\\kundendaten.csv --pdf .\\rechnung.pdf --config .\\config.yml --output .\\output --verbose Reiner XML-Testlauf:\n.\\csv2zugferd-win-x64.exe --csv .\\kundendaten.csv --pdf .\\rechnung.pdf --config .\\config.yml --output .\\output --xml-only --verbose Validiere die erstellte ZUGFeRD-PDF # Nach dem lokalen Test sollte die erzeugte PDF validiert werden.\nVerwende dafür nur die Hinweise auf der Seite ZUGFeRD-Validierung →.\nFehlerkorrektur # Wenn Fehler auftreten, kopiere die Fehlermeldung einfach zusammen mit der aktuellen config.yml zurück in denselben Prompt.\nDas ist oft der schnellste Weg, um Mapping-Fehler, fehlende Pflichtfelder oder unpassende Datums-, Zahlen- und Summenfelder gezielt korrigieren zu lassen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/ki-hilfe-config-yml/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"KI-Hilfe für config.yml","type":"docs"},{"content":"Ein lokales CLI verarbeitet Rechnungsdaten ohne Upload und ohne externe Abhängigkeit. Ein SaaS-Dienst bietet eine browserbasierte Oberfläche, erfordert aber den Upload vertraulicher Rechnungsdaten an einen Drittanbieter und laufende Kosten. Für wiederholbare technische Workflows sind die Unterschiede entscheidend.\nVergleich im Überblick # Kriterium csv2zugferd (lokal) SaaS-Dienst Datenhaltung lokal, kein Upload Rechnungsdaten gehen an Drittanbieter Internetverbindung nicht erforderlich erforderlich Kosten kostenlos, Open Source laufende Abo- oder Nutzungskosten Automatisierung vollständig skriptbar (PowerShell, CI/CD) meist manuell oder API mit Konto Integration direkt in bestehende Skripte einbindbar API-Anbindung erforderlich Rechnungsvolumen beliebig, unbegrenzt oft volumenabhängig bepreist Offline-Betrieb ja nein csv2zugferd # läuft lokal lässt sich skripten verarbeitet strukturierte CSV-Daten ist Open Source unter Apache-2.0 benötigt keinen Upload von Rechnungsdaten arbeitet reproduzierbar mit versionierter YAML-Konfiguration SaaS # läuft im Browser ist oft für Einzelvorgänge optimiert kann PDF-Erkennung und Formulare anbieten bringt dafür Upload, Konto, Pricing und Anbieterabhängigkeit mit Wann ist SaaS sinnvoll? # SaaS-Dienste eignen sich für Anwender, die gelegentlich einzelne Rechnungen konvertieren und keine eigene Infrastruktur betreiben wollen. Für Unternehmen mit regelmäßigen Batchläufen, Datenschutzanforderungen oder bestehenden CSV-Exportworkflows ist ein lokales CLI typischerweise besser geeignet.\nWeiterführend: ZUGFeRD ohne Cloud und direkt zum csv2zugferd herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/vergleich/lokales-cli-vs-saas/","section":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","summary":"","title":"Lokales ZUGFeRD CLI vs. SaaS – wann welche Lösung","type":"vergleich"},{"content":"csv2zugferd nutzt eine vorhandene Rechnungs-PDF als sichtbaren Beleg und bettet die erzeugten XML-Daten ein.\nDas passt zu Systemen, die bereits eine korrekte PDF-Rechnung erzeugen, aber noch keine ZUGFeRD-konforme Hybridrechnung ausgeben.\nVerhalten im CLI # Ohne --xml-only erzeugt das Tool:\neine XML-Datei eine PDF-Datei mit eingebettetem ZUGFeRD-XML Mit --xml-only wird nur die XML-Datei geschrieben. Der Parameter --pdf bleibt dennoch erforderlich, weil die CLI-Signatur konsistent bleibt und derselbe Aufruf leicht auf einen PDF-Lauf umgestellt werden kann.\nEmpfehlung # Für realistische Tests sollte eine echte Rechnungs-PDF verwendet werden, nicht nur eine leere Platzhalterdatei. Im Repository ist dafür zum Beispiel test\\2483.pdf geeignet.\nWichtig # Die sichtbare PDF und die eingebetteten XML-Daten müssen fachlich zusammenpassen. Abweichungen zwischen PDF und XML können zu Problemen bei Empfängern, Prüfungen oder Folgeprozessen führen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/pdf-vorlage/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"PDF-Vorlage","type":"docs"},{"content":"$config = \u0026#34;.\\config.yml\u0026#34; $output = \u0026#34;.\\out\u0026#34; Get-ChildItem \u0026#34;.\\csv\u0026#34; -Filter \u0026#34;*.csv\u0026#34; | ForEach-Object { $pdf = \u0026#34;.\\pdf\\$($_.BaseName).pdf\u0026#34; .\\csv2zugferd-win-x64.exe --csv $_.FullName --pdf $pdf --config $config --output $output } Produktive Batchläufe sollten Rückgabecodes auswerten und fehlgeschlagene Rechnungen getrennt protokollieren.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/powershell-batch/","section":"Beispiele","summary":"","title":"PowerShell-Batch","type":"beispiele"},{"content":"Der Rows-Modus ist geeignet, wenn jede Rechnungsposition in einer eigenen CSV-Zeile steht.\nRechnungsnummer;Datum;Kunde;Position;Menge;Preis 471102;2026-05-18;Muster GmbH;Beratung;2;120.00 471102;2026-05-18;Muster GmbH;Support;1;80.00 .\\csv2zugferd-win-x64.exe --csv .\\testdata\\test_rows.csv --pdf .\\rechnung.pdf --config .\\testdata\\config_rows.yml --output .\\output ","date":"22. Mai 2026","externalUrl":null,"permalink":"/beispiele/rows-modus/","section":"Beispiele","summary":"","title":"Rows-Modus","type":"beispiele"},{"content":"Die YAML-Datei beschreibt, wie CSV-Spalten auf Rechnungsdaten und Positionen gemappt werden.\nGrundstruktur # csv: separator: \u0026#34;,\u0026#34; encoding: \u0026#34;UTF-8\u0026#34; hasHeader: true decimalSeparator: \u0026#34;.\u0026#34; dateFormat: \u0026#34;dd.MM.yyyy\u0026#34; zugferd: version: \u0026#34;2.3\u0026#34; profile: \u0026#34;Extended\u0026#34; format: \u0026#34;CII\u0026#34; mapping: invoice: {} buyer: {} seller: {} delivery: {} orderReference: {} lineItems: {} totals: {} paymentTerms: {} FieldMapping # Fast alle Mapping-Felder verwenden dieselbe FieldMapping-Struktur:\nfeldName: value: \u0026#34;Fester Wert\u0026#34; column: \u0026#34;CSV_SPALTE\u0026#34; default: \u0026#34;Fallback\u0026#34; scheme: \u0026#34;VA\u0026#34; rules: - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^003\u0026#34; value: \u0026#34;DAY\u0026#34; Schlüssel Beschreibung value Fester Wert. Hat Vorrang vor allen anderen Angaben. column CSV-Spalte, aus der der Wert gelesen wird. default Fallback, wenn value, column und rules keinen Wert liefern. scheme Optionaler Schema-Qualifier, z. B. für elektronische Adresse oder Steuerregistrierung. rules Geordnete Regex-Regeln, mit denen Werte aus anderen CSV-Spalten abgeleitet werden. Auflösungsreihenfolge:\nvalue, wenn gesetzt column, wenn gesetzt und der CSV-Wert nicht leer ist rules von oben nach unten default, wenn gesetzt leerer String bzw. fachlicher Code-Fallback im Mapper Regex-Regeln # Regex-Regeln erlauben flexible Ableitungen ohne Codeänderung. Die erste passende Regel gewinnt. Ungültige Ausdrücke werden geloggt und ignoriert.\nunitCode: default: \u0026#34;C62\u0026#34; rules: - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^002\u0026#34; value: \u0026#34;ANN\u0026#34; - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^003\u0026#34; value: \u0026#34;DAY\u0026#34; - when: column: \u0026#34;PRODUCT_NAME\u0026#34; regex: \u0026#34;(?i)vor-ort-schulung|schulung\u0026#34; value: \u0026#34;DAY\u0026#34; Groß-/Kleinschreibung lässt sich mit Inline-Optionen wie (?i) steuern. Im columns-Modus werden Regelspalten positionsbezogen aufgelöst: bei column: \u0026quot;PRODUCT_CODE\u0026quot; und Suffix-Muster wird für Position 0 PRODUCT_CODE_0, für Position 1 PRODUCT_CODE_1 geprüft.\nBeispiel für den Rechnungskopf # invoice: invoiceNumber: column: \u0026#34;INVOICE_NO\u0026#34; invoiceDate: column: \u0026#34;INVOICE_DUEDATE\u0026#34; currency: value: \u0026#34;EUR\u0026#34; orderReferenceId: column: \u0026#34;SALESORDER_ID\u0026#34; referenceOrderNo: column: \u0026#34;SALESORDER_ID\u0026#34; name: value: \u0026#34;WARENRECHNUNG\u0026#34; note: column: \u0026#34;INVOICE_NOTE\u0026#34; Beispiel für Käuferdaten # buyer: name: column: \u0026#34;ACCOUNT_NAME\u0026#34; postalCode: column: \u0026#34;INVOICE_BILL_CODE\u0026#34; city: column: \u0026#34;INVOICE_BILL_CITY\u0026#34; street: column: \u0026#34;INVOICE_BILL_STREET\u0026#34; country: value: \u0026#34;DE\u0026#34; contact: column: \u0026#34;CONTACT_LASTNAME\u0026#34; taxId: column: \u0026#34;BUYER_VAT_ID\u0026#34; taxScheme: value: \u0026#34;VA\u0026#34; electronicAddress: column: \u0026#34;BUYER_VAT_ID\u0026#34; scheme: \u0026#34;GermanyVatNumber\u0026#34; taxScheme akzeptiert FC (Steuernummer) oder VA (Umsatzsteuer-ID). Unterstützte Werte für scheme bei electronicAddress: GermanyVatNumber, LuxemburgVatNumber.\nBeispiel für Verkäuferdaten # Verkäuferdaten können aus CSV-Spalten kommen oder als feste Stammdaten in der YAML-Datei stehen. Für wiederkehrende Verkäuferdaten sind feste Werte empfohlen.\nseller: name: value: \u0026#34;Muster Lieferant GmbH\u0026#34; postalCode: value: \u0026#34;80333\u0026#34; city: value: \u0026#34;Muenchen\u0026#34; street: value: \u0026#34;Lieferantenstrasse 20\u0026#34; country: value: \u0026#34;DE\u0026#34; taxRegistrations: - value: \u0026#34;201/113/40209\u0026#34; scheme: \u0026#34;FC\u0026#34; - value: \u0026#34;DE123456789\u0026#34; scheme: \u0026#34;VA\u0026#34; electronicAddress: value: \u0026#34;DE123456789\u0026#34; scheme: \u0026#34;GermanyVatNumber\u0026#34; Scheme Bedeutung FC Steuernummer VA Umsatzsteuer-ID taxRegistrations unterstützt sowohl feste Werte per value als auch CSV-Werte per column.\nBeispiel für Lieferdaten # delivery: deliveryNoteNumber: column: \u0026#34;DELIVERY_NOTE_NO\u0026#34; deliveryNoteDate: column: \u0026#34;DELIVERY_NOTE_DATE\u0026#34; actualDeliveryDate: column: \u0026#34;DELIVERY_DATE\u0026#34; Alle drei Felder sind optional. deliveryNoteNumber und deliveryNoteDate werden gemeinsam als Lieferscheinreferenz geschrieben. actualDeliveryDate setzt das tatsächliche Lieferdatum.\nBeispiel für Bestellreferenz # orderReference: orderNumber: column: \u0026#34;ORDER_NO\u0026#34; orderDate: column: \u0026#34;ORDER_DATE\u0026#34; orderNumber entspricht BT-13 (Bestellnummer des Käufers). orderDate ist optional.\nBeispiel für lineItems im rows-Modus mit Rabatt # lineItems: mode: \u0026#34;rows\u0026#34; fields: name: column: \u0026#34;Artikel_Name\u0026#34; description: column: \u0026#34;Artikel_Beschreibung\u0026#34; sellerAssignedId: column: \u0026#34;Artikelnummer\u0026#34; netUnitPrice: column: \u0026#34;Einzelpreis_Netto\u0026#34; billedQuantity: column: \u0026#34;Menge\u0026#34; taxPercent: column: \u0026#34;MwSt_Prozent\u0026#34; unitCode: value: \u0026#34;C62\u0026#34; taxType: value: \u0026#34;VAT\u0026#34; taxCategoryCode: value: \u0026#34;S\u0026#34; allowanceCharge: enabled: true isDiscount: value: true chargePercentage: column: \u0026#34;Rabatt_Prozent\u0026#34; reason: column: \u0026#34;Rabatt_Grund\u0026#34; isDiscount: true erzeugt einen Rabatt (TradeAllowance), false einen Zuschlag (TradeCharge). Im columns-Modus wird Rabatt stattdessen über discountPercent in fields konfiguriert.\nBeispiel für lineItems im columns-Modus # lineItems: mode: \u0026#34;columns\u0026#34; columnPattern: style: \u0026#34;suffix\u0026#34; separator: \u0026#34;_\u0026#34; startIndex: 0 zeroPadding: 0 fields: name: column: \u0026#34;PRODUCT_NAME\u0026#34; sellerAssignedId: column: \u0026#34;PRODUCT_CODE\u0026#34; netUnitPrice: column: \u0026#34;PRODUCT_PRICE\u0026#34; billedQuantity: column: \u0026#34;PRODUCT_QUANTITY\u0026#34; taxPercent: column: \u0026#34;INVOICE_TAX\u0026#34; discountPercent: column: \u0026#34;PRODUCT_DISCOUNT\u0026#34; fixedFields: unitCode: default: \u0026#34;C62\u0026#34; rules: - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^002\u0026#34; value: \u0026#34;ANN\u0026#34; - when: column: \u0026#34;PRODUCT_CODE\u0026#34; regex: \u0026#34;^003\u0026#34; value: \u0026#34;DAY\u0026#34; - when: column: \u0026#34;PRODUCT_NAME\u0026#34; regex: \u0026#34;(?i)vor-ort-schulung|schulung\u0026#34; value: \u0026#34;DAY\u0026#34; taxType: value: \u0026#34;VAT\u0026#34; taxCategoryCode: value: \u0026#34;S\u0026#34; Wichtig dabei:\nPRODUCT_NAME, PRODUCT_PRICE und ähnliche Felder werden als Fragment für nummerierte Spalten wie PRODUCT_NAME_0 verwendet. INVOICE_TAX kann im selben Block als globale Rechnungs-Spalte verwendet werden und gilt dann für jede erzeugte Position. sellerAssignedId ist für interne Produktnummern. description bleibt für echte Artikelbeschreibungen reserviert. fixedFields unterstützt vollständiges FieldMapping inklusive rules — nützlich z. B. für positionsabhängige Einheitencodes. Rabatte # discountPercent akzeptiert Werte wie 10, 10.00 oder 10%. Der Rabatt wird validierungsfreundlich als rabattierter Netto-Einzelpreis abgebildet:\nBrutto-Listenpreis → GrossPriceProductTradePrice (= Originalpreis) Rabattierter Netto-Einzelpreis → NetPriceProductTradePrice (netPrice × (1 − percent/100), 4 Dezimalstellen) Zeilennettobetrag = rabattierter Einzelpreis × Menge Es wird kein AppliedTradeAllowanceCharge für discountPercent-Positionsrabatte erzeugt. Dadurch bleiben EN-16931-Regeln wie BR-S-08 konsistent.\nIm rows-Modus gibt es zusätzlich lineItems.allowanceCharge für weitere Rabatte oder Zuschläge auf Positionsebene, unabhängig von discountPercent.\nSummen # Automatisch (empfohlen, wenn Preise, Mengen und Steuerprozentsatz vollständig aus der CSV kommen):\ntotals: mode: \u0026#34;auto\u0026#34; Manuell (nur sinnvoll, wenn die CSV fachlich geprüfte Summen liefert):\ntotals: mode: \u0026#34;manual\u0026#34; lineTotalAmount: column: \u0026#34;INVOICE_SUBTOTAL\u0026#34; allowanceTotalAmount: value: \u0026#34;0\u0026#34; taxBasisAmount: column: \u0026#34;INVOICE_SUBTOTAL\u0026#34; taxTotalAmount: column: \u0026#34;INVOICE_TAXTOTAL\u0026#34; grandTotalAmount: column: \u0026#34;INVOICE_TOTAL\u0026#34; totalPrepaidAmount: value: \u0026#34;0\u0026#34; Empfehlung # Die YAML-Datei sollte gemeinsam mit dem CSV-Export versioniert werden. Dadurch bleibt nachvollziehbar, welche CSV-Struktur zu welcher Ausgabe geführt hat.\nPraxisbeispiel: columns-Modus mit suffix-Spalten.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/docs/yml-konfiguration/","section":"csv2zugferd Dokumentation – ZUGFeRD aus CSV erzeugen","summary":"","title":"YAML-Konfiguration – ZUGFeRD-Mapping mit csv2zugferd","type":"docs"},{"content":"ZUGFeRD-Rechnungen können auf drei grundlegend verschiedene Weisen erzeugt werden. Welcher Ansatz passt, hängt vom Ausgangsmaterial, dem Integrationsaufwand und den Datenschutzanforderungen ab.\nDie drei Ansätze im Überblick # Ansatz Eingabe Integration Zielgruppe Lokales CLI (csv2zugferd) CSV + PDF-Vorlage Kein Code erforderlich Teams mit CSV-Export aus CRM/ERP Programmatische Bibliothek Code-Aufruf im eigenen System Direkt in Anwendung eingebettet Entwickler mit bestehendem Softwareprojekt SaaS-Dienst PDF-Upload oder Formular Browser oder REST-API Einzelne Rechnungen ohne Infrastruktur Lokales CLI: csv2zugferd # csv2zugferd nimmt strukturierte Rechnungsdaten als CSV und eine vorhandene Rechnungs-PDF entgegen. Das YAML-Mapping beschreibt, welche CSV-Spalten welchen ZUGFeRD-Feldern entsprechen. Kein Code, kein Build-System, keine Abhängigkeiten im eigenen Projekt.\nGeeignet, wenn:\nein CRM, ERP oder Excel CSV exportieren kann eine Rechnungs-PDF als sichtbarer Beleg bereits vorliegt keine Änderung an einer bestehenden Applikation möglich oder gewünscht ist Batch-Verarbeitung oder Automatisierung über PowerShell oder CI/CD gefragt ist Programmatische Bibliotheksintegration # Bibliotheken erlauben es, ZUGFeRD-Rechnungen direkt aus Anwendungscode zu erzeugen. Für die gängigen Plattformen existieren quelloffene Bibliotheken – unter anderem für Java, .NET/C#, Python und PHP.\nGeeignet, wenn:\nRechnungsdaten in einer Datenbank oder einem Objektmodell vorliegen die ZUGFeRD-Erzeugung fester Bestandteil einer bestehenden Anwendung werden soll volle Kontrolle über das erzeugte XML und die Profilauswahl erforderlich ist SaaS-Dienste # SaaS-Werkzeuge bieten browserbasierte Oberflächen für die manuelle Eingabe oder den Upload einzelner Rechnungen. Die Nutzung erfordert kein lokales Setup, aber Rechnungsdaten verlassen das eigene System.\nGeeignet, wenn:\ngelegentlich einzelne Rechnungen ohne strukturierten Datenexport konvertiert werden keine eigene Infrastruktur oder kein Skriptbedarf vorhanden ist Entscheidungsmatrix # Situation Empfohlener Ansatz CSV-Export vorhanden, kein Quellcode-Eingriff csv2zugferd Eigene Anwendung soll ZUGFeRD ausgeben Bibliotheksintegration Gelegentlich einzelne Rechnungen manuell SaaS Batch-Workflow, hunderte Rechnungen csv2zugferd oder Bibliothek Vollständige Kontrolle über XML-Ausgabe Bibliotheksintegration Kein Rechnungsdaten-Upload gewünscht csv2zugferd oder Bibliothek Weiterführend: Lokales CLI vs. SaaS im Detail. Tool: csv2zugferd herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/vergleich/zugferd-bibliotheken/","section":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","summary":"","title":"ZUGFeRD erzeugen: CLI, Bibliothek oder SaaS?","type":"vergleich"},{"content":"Für .NET-Entwickler gibt es zwei grundsätzlich verschiedene Wege, ZUGFeRD-Rechnungen zu erzeugen: die programmatische Integration einer Bibliothek in den eigenen Anwendungscode oder ein externes CLI-Tool, das CSV-Daten und eine vorhandene PDF entgegennimmt.\ncsv2zugferd: CLI-Ansatz für .NET-Umgebungen # csv2zugferd ist selbst in .NET/C# geschrieben und als eigenständige Windows-Exe verfügbar. Der Aufruf erfolgt über die Kommandozeile oder PowerShell – ohne NuGet-Abhängigkeit im eigenen Projekt.\n.\\csv2zugferd-win-x64.exe --csv invoices.csv --pdf invoice.pdf --config config.yml --output out Dieser Ansatz eignet sich für .NET-Entwickler, die:\nZUGFeRD ohne Code-Änderungen an einer bestehenden Anwendung erzeugen wollen strukturierte Rechnungsdaten bereits als CSV-Export verfügbar haben Batch-Verarbeitung über PowerShell, Azure DevOps oder andere CI/CD-Pipelines benötigen keine NuGet-Abhängigkeit für die ZUGFeRD-Erzeugung einführen wollen Programmatische Bibliotheksintegration # Für die direkte Integration in .NET-Anwendungen existieren quelloffene Bibliotheken. Diese erlauben es, ZUGFeRD-Objekte im Code zu erstellen und als PDF/A-3 mit eingebettetem XML zu serialisieren.\nDieser Ansatz eignet sich, wenn:\nRechnungsdaten direkt aus dem Objektmodell oder der Datenbank stammen das erzeugte XML vollständig kontrolliert werden soll die ZUGFeRD-Erzeugung fester Bestandteil eines ERP, Webservices oder einer API ist Vergleich beider Ansätze # Kriterium csv2zugferd (CLI) Bibliotheksintegration Eingabe CSV + PDF-Vorlage .NET-Objekte oder Datenbankabfragen Code-Änderung nötig Nein Ja NuGet-Abhängigkeit Nein Ja Batch-Fähigkeit Ja, per Skript Ja, im eigenen Code Kontrolle über XML Über YAML-Mapping Vollständig programmatisch Geeignet für CSV-Export-Workflows Anwendungsintegration Systemvoraussetzungen # csv2zugferd läuft auf Windows x64 und benötigt keine separate .NET-Installation – die Exe ist als Self-Contained-Build verfügbar.\nWeiterführend: Installation und Setup. Download: csv2zugferd herunterladen.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/artikel/zugferd-csharp-dotnet/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"ZUGFeRD mit C# und .NET erzeugen","type":"artikel"},{"content":"Rechnungsdaten sind sensible Geschäftsdaten. Ein lokaler Workflow reduziert die Zahl der Systeme, die diese Daten sehen.\ncsv2zugferd verarbeitet CSV, YAML und PDF lokal. Es gibt keinen Upload-Workflow auf der Website und keine serverseitige Rechnungskonvertierung.\nDas ist besonders interessant für Unternehmen, die interne Freigabeprozesse, Altsysteme oder automatisierte Batchläufe betreiben.\nVergleich: Lokales CLI vs. SaaS-Dienste.\n","date":"22. Mai 2026","externalUrl":null,"permalink":"/artikel/zugferd-ohne-cloud/","section":"Artikel zu ZUGFeRD und E-Rechnung – csv2zugferd","summary":"","title":"ZUGFeRD ohne Cloud – lokale Erzeugung mit csv2zugferd","type":"artikel"},{"content":"csv2zugferd ist kein Online-Konverter. Der Fokus liegt auf lokaler Verarbeitung strukturierter CSV-Daten.\nCSV zu ZUGFeRD vs. PDF-Konverter Lokales CLI vs. SaaS ZUGFeRD erzeugen: CLI, Bibliothek oder SaaS? Factur-X vs. ZUGFeRD – Versionsgeschichte und Kompatibilität ","date":"22. Mai 2026","externalUrl":null,"permalink":"/vergleich/","section":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","summary":"","title":"ZUGFeRD-Tools im Vergleich – lokal vs. Online","type":"vergleich"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","externalUrl":null,"permalink":"/","section":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","summary":"","title":"csv2zugferd – CSV zu ZUGFeRD, lokal und automatisiert","type":"page"},{"content":"","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]