Hi zusammen,
hat hier jemand Erfahrung mit dem Thema XRechnung?
Das ist seit Ende 2020 Standard für die elektronische Rechnungsstellung an öffentliche Auftraggeber wie den Bund. Das Format integriert XML in die pdf-Rechnung und ist damit elektronisch verarbeitbar.
Mich würde interessieren, ob jemand dazu Lösungen kennt (im Idealfall OpenSource) oder Erfahrungen damit hat?
Ich habe das bei einem früheren Arbeitgeber im öffentlichen Dienst eingeführt, allerdings als empfangende Stelle und nicht als Rechnungssteller:in.
Streng genommen erfüllt eine PDF-Datei mit eingebettetem XML nicht die Anforderungen (Quelle). Es gibt diverse Programme, mit denen dann aus den XML-Dateien anschaubare Dokumente wie z. B. PDF erzeugt werden können.
Wir hatten damals das CRM von Microsoft im Einsatz (die haben das dauernd umbenannt, irgendwann hieß das mal DynamicsNav) und für Microsoft war das zu speziell, um die Fähigkeit in ihr Produkt einzubauen Es gab dann diverse Plugin-Lösungen.
Allerdings würde mich mal interessieren, welche Behörden tatsächlich XRechnungen verarbeiten können, geschweige denn auf das Format bestehen. Im öffentlichen Dienst heißt eine Verpflichtung noch lange nicht, dass da irgendwas umgesetzt ist…
Bei uns damals war ein riesiger Problembereich, dass in XRechnung die üblichen Prozesse bei der Abwicklung von Bauvorhaben dummerweise nicht wirklich mitgedacht waren: Große Anhänge wie Baupläne, Auftraggeber:innen kürzen einfach was raus, ohne dass es eine korrigierte Rechnung gibt, …
Viele öffentliche Stellen bieten eine sog. Weberfassung, wo die Rechnungsdaten manuell eingetragen werden können und so die Rechnung im korrekten Format übermittelt werden kann, ohne dass man selbst irgendwelche spezielle Software hat. Beispiel Bund
Einen heißen Tipp für eine entsprechende FOSS-Bibliothek oder -Produkt habe ich aber leider auch nicht. Die Koordinierungsstelle für IT-Standards bietet bisschen was an.
Es besteht eine gute Chance, dass wir für einen Kunden im nächsten Jahr eine umfassende Extension bauen, um Rechnungen in CiviCRM deutlich flexibler und sicherer zu handhaben.
Falls ernsthaftes Interesse besteht, könnten wir sicherlich ein XRechnung-Ausgabeformat dazubauen. Melde Dich ggf. gerne Frank.
Allerdings denke ich (wie RoWo-DS) auch, dass es sich lohnt, nochmal zu schauen, wie sich das bei den Behörden „materialisiert“
In der aktuellen iX (Februar 2024) bzw. auch online ist ein Artikel zu E-Rechnungen.
In dem Artikel wird darauf hingewiesen, dass die aktuelle Koalition eine Pflicht zum Empfangen und Versenden (nicht: zur Verarbeitung) von Rechnungen im XML-Format für „nahezu alle Unternehmen“ plant (Gesetzentwurf). Mir ist aber nicht klar, ob das nur für umsatzsteurpflichtige Organisationen gelten wird.
Da sind auch einige Tools gelistet (Konverter, Validatoren, Viewer).
Wir müssen das sehr gut im Auge behalten: Die Einführung der elektronischen Rechnungen ist ein Kernpunkt der Digitalisierung der Wirtschaft, und ist auch im EU-Rechtsrahmen angestrebt. Das wird also auf jeden Fall kommen, und zwar nicht nur in Deutschland, sondern in der ganzen EU, und sicherlich auch in vielen anderen Ländern.
Damit wird es notwendig, die „invoice-Funktionalität“ von CiviCRM so anzupassen, dass elektronische Rechnungen nach den Vorgaben des jeweiligen Landes erzeugt werden. Auch wenn das wahrscheinlich als Extension realisiert wird, sollte das eng mit dem CiviCRM Core abgestimmt werden, damit hier eine Lösung „aus einem Guss“ entsteht.
Der zeitliche Druck wird allerdings für die meisten Organisationen, die CiviCRM einsetzen, nicht so groß sein, weil sie von den diversen Übergangsfristen und Ausnahmeregelungen betroffen sind, die der Gesetzentwurf vorsieht. Der allgemeine Termin 01.01.2025, ab dem Unternehmen zur Ausstellung von eRechnungen verpflichtet sind, dürfte CiviCRM-Anwendende eher nicht betreffen.
Wenn du dazu schon Informationen hast oder ihr selbst plant, diese Extension zu entwickeln, wären wir für weitere Informationen dankbar. Wie Fabian oben schon schrieb, werden wir hoffentlich die Möglichkeit haben, eine neue Rechnungsextension mit sauberem Datenmodell und entwickler*innenfreundlichem Konzept zu entwickeln. Das würde z.B. auch heißen, dass wir unterschiedliche Ausgabeformate modular implementieren können (ähnlich wie bei CiviOffice oder CiviSEPA).
Wir werden die Extension sicherlich erst realisieren, wenn die Vorgaben klar sind.
Mir ist aber wichtig, dass wir von vorneherein eine Lösung implementieren, die sich nahtlos einfügt in den Core Code und das User Interface von CiviCRM für die Rechnungserstellung.
Hallo in die Runde, wir benötigen als Verein zukünftig die Möglichkeit E-Rechnungen zu empfangen, zu verarbeiten und zu versenden. Betrifft das noch jemanden in der Community, so dass wir zusammen eine Entwicklung beauftragen könnten?
Vielen Dank! Maike Hülsmann
CiviCRM ist keine Buchhaltungs-Software! Die Verarbeitung von eingehenden Rechnungen, einschließlich deren Bezahlung, gehört daher nicht zum normalen Funktionsumfang von CiviCRM - und damit gehört der Empfang von XRechnungen auch nicht ins CiviCRM.
Anders ist es mit ausgehenden Rechnungen: CiviCRM hat im Core bereits eine Funktion zum Erstellen von Rechnungen. Damit können pdf-Dateien erzeugt und auch gleich aus CiviCRM verschickt werden, was auch von vielen CiviCRM-Anwender·innen genutzt wird. Hier steht an, die Funktionalität so zu erweitern, dass anstelle von „einfachen pdf-Rechnungen“ künftig auch XRechnungen erstellt werden!
Wer verschickt aktuell von Euch Rechnungen aus dem CiviCRM mit höheren Beträgen? Wir diskutieren bei uns im Haus, ob CiviCRM das Handling der ausgehenden Rechnungen machen soll oder ein anderes Tool das dann in der Buchhaltung auch das Management von offenen Posten übernimmt.
Wir versenden bei Digitalcourage Rechnungen für größere Beträge in einem bestimmten Bereich - es handelt sich um die Anforderung von Beiträgen aus Kampagnen-Bündnissen.
In diesem Fall wird auch die offene Posten-Buchhaltung in CiviCRM gemacht. Erst die tatsächlich eingegangenen Beträge werden in die Buchhaltung übermittelt (mit einem SearchKit-Report, der nach Abschluss eines Monats erstellt wird). Es wäre allerdings auch denkbar, auch die unbezahlten Rechnungen zu übertragen.