Riese.EInvoice — E-Rechnung als Baustein für Ihre eigene Software
Die Bibliothek, die unter den Office-Vorlagen liegt, gibt es auch einzeln. Sie liest, erzeugt, prüft und wandelt E-Rechnungen nach EN 16931 — ohne Geschäftslogik, ohne Datenbank, ohne Oberfläche. Was damit passiert, entscheidet Ihre Anwendung.
Für Softwarehäuser, Inhouse-Entwicklung und alle, die E-Rechnung in ein bestehendes Programm einbauen wollen, statt daneben ein zweites zu betreiben. Stand Version 0.2.0.
Sieben Dinge, die die Bibliothek kann
Alles läuft über ein neutrales Rechnungsmodell in der Mitte: beide Syntaxen werden darauf abgebildet, alles andere baut darauf auf.
Drei Wege hinein
Neun NuGet-Pakete, nach Aufgabe getrennt: Kern, XML-Abbildung, ZUGFeRD, XRechnung, XSD-Prüfung, Schematron, PDF lesen und PDF schreiben. Man referenziert nur, was gebraucht wird. Der Kern ist netstandard2.0 und läuft von .NET Framework 4.6.1 bis .NET 10.
Riese.EInvoice.Cli (net8.0) mit vier Schaltern: --to-cii, --to-ubl, --to-pdf, --validate. Genug für Stapelverarbeitung und Anbindung aus einer anderen Sprache.
Zwei registrierte Klassen, bewusst nur mit einfachen string-Methoden — VBA muss nichts umrechnen. Beträge dürfen deutsch (1.234,56) oder invariant geschrieben sein, Datumsangaben deutsch oder als ISO.
Core — Modell, Reader, ValidierungspipelineXml — CII-/UBL-Abbildung, FormaterkennungZugferd · XRechnung — lesen und schreibenValidation.Xsd · Validation.SchematronPdf.PdfPig lesen · Pdf.PdfSharp schreibenResetSetInvoiceSetReferencesSetSellerSetBuyerSetPaymentAddLineAddNoteSaveXmlSaveXmlCheckedSavePdfSavePdfFromSavePdfFromWordGetNetTotalGetTaxTotalGetGrossTotalGetLastErrorCountGetLastWarningCountDazu EInvoiceService zum Lesen und Prüfen fremder Rechnungen: ReadInvoiceToJson, GetInvoiceNumber, GetGrossAmount, ValidateFile und weitere. Die vollständigen Signaturen stehen in der mitgelieferten Dokumentation.
Vier Stufen, ein Bericht
Die Validierungspipeline führt beliebig viele Stufen zu einem Ergebnis zusammen. Jede Meldung trägt ihre Stufe und ihren Regelcode — auswertbar, nicht nur anzeigbar.
BR-*-Geschäftsregeln aus EN 16931Das XML wird immer erzeugt, die Befunde stehen daneben, die Anwendung entscheidet. Fällt eine Stufe technisch aus — fehlendes Schema, defektes XSLT — wird daraus eine Meldung, die übrigen Stufen laufen weiter.
Eine Rechnung kann als ZUGFeRD einwandfrei und als XRechnung unvollständig sein — die elektronische Adresse des Empfängers etwa ist keine EN-16931-Pflicht, sondern eine PEPPOL-Regel. Beide Ergebnisse werden deshalb getrennt gemeldet.
Drei Wege zum Rechnungsbild
In allen drei Fällen entsteht PDF/A-3b mit eingebettetem CII-XML: eingebettete Datei im Namensbaum, /AF mit AFRelationship, sRGB-OutputIntent mit ICC-Profil und Factur-X-XMP.
SavePdfFrom — das übergebene PDF bleibt genau, wie es istSavePdfFromWord — das Word-Dokument wird in-process exportiert und veredeltDas Quell-PDF muss selbst PDF/A-tauglich sein: Schriften eingebettet, keine Transparenz. Den Rest ergänzt die Bibliothek. Die mitgelieferte Schrift wird als Subset eingebettet.
Was nicht drin ist
Eine Bibliothek, die alles verspricht, hilft bei der Einschätzung nicht. Diese Punkte fehlen bewusst — wenn Sie einen davon brauchen, sagen Sie es lieber vorher.
Sie wollen E-Rechnung in Ihre eigene Anwendung einbauen?
Schreiben Sie mir, welche Umgebung Sie haben und was am Ende rauskommen soll — ich schicke Ihnen die technische Dokumentation und ein Beispielprojekt.