Standardisierung von Leistungsnachweisen

Neben dem Vertragsrecht stellen das Handels- und Steuerrecht Anforderungen an die Dokumentation von Leistungen und Rechnungen, welche für die Standardisierung von Leistungsnachweisen relevant sind.

Handelsrechtlich (HGB) gilt für bilanzierungspflichtige Unternehmen das Gebot ordnungsgemäßer Buchführung, einschließlich der vollständigen und richtigen Erfassung von Geschäftsvorfällen (§§ 238, 239 HGB). Jeder Geschäftsvorfall muss durch einen geeigneten Beleg nachprüfbar sein (Belegprinzip). Leistungsnachweise sind Teil dieser Belegkette: Sie untermauern die Entstehung von Forderungen und Verbindlichkeiten. Für Kaufleute und bilanzierende Unternehmen besteht zudem eine Aufbewahrungspflicht für Buchungsbelege von i.d.R. 10 Jahren (vgl. § 257 Abs. 1 Nr. 4, Abs. 4 HGB für Handelsbücher und Belege; § 147 Abs. 3 AO für steuerliche Aufbewahrung). Rechnungen als Belege über Entgeltforderungen müssen folglich 10 Jahre archiviert werden – digital eingehende Rechnungen sind dabei gleichwertig zu behandeln wie Papierrechnungen. Gleiches sollte für zugehörige Leistungsnachweise gelten: Wenn sie für das Verständnis und die Prüfung der Rechnung relevant sind, sind sie Bestandteil der abzulegenden Unterlagen. Eine Trennung von Rechnung und zugehörigem Leistungsnachweis (z.B. nur Aufbewahrung der Rechnung ohne die Belege) widerspricht dem Grundsatz der Nachvollziehbarkeit und Nachprüfbarkeit der Buchführung. Vielmehr müssen die Unterlagen so geordnet aufbewahrt werden, dass ein Dritter (z.B. Betriebsprüfer) die Verbindung zwischen Rechnung und Leistungsnachweis erkennen und den Vorgang sachlich nachvollziehen kann.

Steuerrechtlich sind vor allem die Vorgaben des Umsatzsteuergesetzes (UStG) und der Abgabenordnung (AO) einschlägig. § 14 UStG regelt die Anforderungen an eine ordnungsgemäße Rechnung. Für den Vorsteuerabzug muss die Rechnung bestimmte Pflichtangaben enthalten, u.a. eine genaue Bezeichnung der erbrachten Leistung und Menge bzw. Umfang sowie das Leistungsdatum (§ 14 Abs. 4 Nr. 5 und Nr. 6 UStG). Ein Leistungsnachweis kann hier indirekt relevant werden: Er stellt sicher, dass die Rechnung diese Angaben korrekt und detailliert enthält. So darf etwa die Leistungsbeschreibung in der Rechnung nicht zu vage sein – in der Rechtsprechung wurde z.B. entschieden, dass Formulierungen wie „Montagearbeiten, 10 Stunden“ ohne nähere Spezifizierung der Art der Arbeiten problematisch sein können. Ein standardisierter Leistungsnachweis, der die erbrachten Tätigkeiten genau auflistet, ermöglicht es dem Rechnungssteller, die Rechnung präzise und prüfungssicher zu formulieren. Sollte das Finanzamt im Rahmen einer Umsatzsteuersonderprüfung die inhaltliche Richtigkeit oder Nachvollziehbarkeit einer Rechnung hinterfragen, dienen Leistungsnachweise als ergänzende Belege, um die ordnungsgemäße Leistungserbringung zu belegen. Zwar sind Leistungsnachweise selbst keine Pflichtanhänge einer Rechnung nach UStG, doch bilden sie häufig Teil des steuerlich relevanten „Beleg-Pakets“. Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern und Unterlagen in elektronischer Form) betonen, dass zu einem Geschäftsvorfall alle zugehörigen Unterlagen aufzubewahren und durch einen verlässlichen Prüfpfad zu verknüpfen sind.

Ein weiterer steuerrechtlicher Aspekt ist die Sicherstellung der Echtheit und Unversehrtheit von Rechnungen. Seit der gesetzlichen Gleichstellung elektronischer Rechnungen (durch Umsetzung der RL 2010/45/EU ins deutsche Recht) gilt: Die Echtheit der Herkunft, Unversehrtheit des Inhalts und Lesbarkeit der Rechnung müssen gewährleistet sein (vgl. § 14 Abs. 1 UStG sowie BMF-Schreiben vom 2. Juli 2012). Der Gesetzgeber nennt hierzu ausdrücklich technische Verfahren wie qualifizierte elektronische Signaturen oder EDI-Verfahren, erlaubt aber ebenso ein innerbetriebliches Kontrollverfahren als Nachweis. Dieses Kontrollverfahren soll einen verlässlichen Prüfpfad zwischen Rechnung und Leistung schaffen. Praktisch bedeutet das: Der Rechnungsempfänger muss prüfen können, dass die Rechnung inhaltlich mit der tatsächlich gelieferten Leistung übereinstimmt. Genau hier sind Leistungsnachweise zentral: Durch Abgleich jeder Rechnungsposition mit einem vorliegenden Leistungsnachweis (z.B. Lieferschein, Abnahmeprotokoll, Stundenzettel) stellt das Unternehmen sicher, dass die Rechnung vom richtigen Aussteller stammt und inhaltlich korrekt ist. Eine automatisierte positionsweise Rechnungsprüfung, die auf standardisierten Leistungsnachweisen basiert, erfüllt somit ein wesentliches steuerliches Erfordernis – nämlich die Einrichtung eines internen Kontrollsystems zur Rechnungsprüfung, das dem Finanzamt gegenüber als Sicherungsmaßnahme für die Echtheit und inhaltliche Richtigkeit dient. Damit wird auch der Vorsteuerabzug rechtlich abgesichert, da die Voraussetzungen (echte, unversehrte und sachlich richtige Rechnung) plausibel nachgewiesen werden können.

• Prüfbarkeit der Rechnung sicherstellen: Leistungsnachweise müssen so beschaffen sein, dass der Auftraggeber damit die Rechnung sachlich prüfen kann. Fehlende Leistungsnachweise können die Zahlungspflicht hinausschieben oder ein Zurückbehaltungsrecht begründen, sofern vertraglich vereinbart oder nach Treu und Glauben erforderlich.

• Fälligkeitsrelevanz: In bestimmten Verträgen (insb. Bauverträgen, § 650g BGB) ist eine prüffähige Abrechnung gesetzliche Fälligkeitsvoraussetzung. In anderen Fällen wird dies durch Vertrag geregelt. Leistungsnachweise sind daher oftmals faktische Bedingungen für die Entstehung des Zahlungsanspruchs, müssen aber fair gestaltet sein (keine unverhältnismäßige Benachteiligung des Auftragnehmers).

• Inhaltliche Mindestanforderungen: Der Leistungsnachweis sollte alle Angaben enthalten, die benötigt werden, um Art, Umfang und Qualität der Leistung nachvollziehen zu können. Dazu zählen insbesondere eindeutige Leistungsbeschreibungen, Mengen- oder Zeitangaben, Bezug auf Vertragspositionen und ggf. Zeichnungen oder Aufmaßdaten. Diese Detailtiefe ist notwendig, um sowohl dem Auftraggeberinteresse als auch den Anforderungen aus § 14 UStG (Leistungsbeschreibung) gerecht zu werden.

• Dokumentations- und Aufbewahrungspflicht: Leistungsnachweise sind Teil der kaufmännischen und steuerlichen Dokumentation. Sie müssen über lange Zeiträume (10 Jahre) manipulationssicher aufbewahrt und bei Betriebsprüfungen vorgelegt werden können. Dies erfordert eine entsprechende Organisation der Archivierung (vgl. GoBD), in der Leistungsnachweise mit den zugehörigen Rechnungen verknüpft sind.

• Authentizität und Integrität: Im elektronischen Prozess müssen Leistungsnachweise so eingebunden sein, dass sie zur Sicherstellung der Echtheit der Rechnung beitragen. Beispielsweise kann ein Leistungsnachweis mit einer eindeutigen Referenznummer in der Rechnung angegeben sein oder digital signiert vorliegen, um Manipulation auszuschließen. Die Integrität der Dokumente (d.h. Unveränderbarkeit nachträglich) ist zu gewährleisten – etwa durch geeignete Dateiformate, Hashwerte oder Archivsysteme nach § 239 HGB und § 146 AO (Unveränderbarkeitsgrundsatz).

Nachdem die rechtlichen Anforderungen geklärt sind, stellt sich die Frage, wie Leistungsnachweise strukturell und inhaltlich gestaltet sein müssen, um diese Anforderungen in einer digitalisierten, automatisierten Umgebung praktisch umzusetzen. Dies wird im folgenden Abschnitt untersucht.

Um Leistungsnachweise in der digitalen Unternehmenspraxis effektiv nutzen zu können, müssen sie strukturiert und standardisiert sein. Nur dann können IT-Systeme die Informationen auslesen, Verknüpfungen zur Rechnung herstellen und Prüfroutinen automatisiert durchführen. Im Folgenden werden die wesentlichen Anforderungen an Aufbau und Inhalt solcher Leistungsnachweise herausgearbeitet, damit sie maschinenlesbar, prüffähig und revisionssicher sind.

Ein Leistungsnachweis sollte in einem formalen Datenformat vorliegen, das von Computersystemen ohne manuelle Eingriffe verarbeitet werden kann. Anstelle von unstrukturierten PDF-Dokumenten oder Papierbelegen müssen also maschinell lesbare Formate eingesetzt werden – idealerweise XML oder ein vergleichbares strukturiertes Format, da XML-Schemata weit verbreitete Standards im E-Business sind. Eine einheitliche Struktur bedeutet: Jeder Leistungsnachweis folgt demselben Datenmodell, mit definierten Feldern und Hierarchien.

• Kopfsegment: Informationen zum Dokument selbst (Dokumentenart = Leistungsnachweis, eindeutige Dokumentnummer, Datum der Leistungserbringung bzw. des Nachweis-Dokuments, Bezug zur Rechnung falls schon bekannt, etc.), Angaben zu Auftragnehmer und Auftraggeber, Referenzen auf Vertrag/Bestellung.

• Leistungspositionen: Eine aufgliederte Liste der erbrachten Leistungen, die idealerweise 1:1 den späteren Rechnungspositionen entsprechen oder diesen eindeutig zugeordnet werden können.

• eine Positionsnummer oder ID (ggf. korrespondierend zur Bestell- oder Vertragsposition),

• Leistungsbeschreibung (klartextlich oder als standardisierter Code),

• Menge/Umfang der Leistung (mit Einheit als Code, z.B. Stunden, Stück, Meter),

• Einheitspreis oder vertraglich vereinbarter Preis je Einheit,

• Positionsgesamtpreis (Menge * Preis) – dieser kann zum Abgleich mit der Rechnungssumme dienen.

• Leistungszeitraum oder -datum, falls relevant (insbesondere bei Dienstleistungen oder bei Abrechnung nach Aufwand sollte der Zeitraum der Tätigkeit angegeben sein, z.B. „01.05.2025–31.05.2025“ für einen Monatsnachweis).

• Zusätzliche Nachweisdaten je Position: Falls die Prüfbarkeit es erfordert, können hier Details aufgeführt werden, z.B. bei Bauleistungen: Aufmaße, Berechnungsansätze, Ort der Leistung; bei Dienstleistungen: detaillierte Tätigkeitsbeschreibung oder Zeitaufstellungen pro Tag; bei Werkleistungen: ggf. Prüfprotokolle, Messwerte etc. Diese könnten in einer Unterstruktur oder als separate anhängige Dokumente abgebildet sein. Wichtig ist, dass ein automatischer Abgleich zumindest prüfen kann, dass ein solcher Detailnachweis vorliegt und schlüssig ist. Beispielsweise kann in der Position ein Verweis auf ein Aufmaß-Dokument erfolgen.

• Freigabe-/Abnahmeinformationen: Um revisionssicher festzuhalten, dass der Auftraggeber die Leistung anerkannt hat, sollte der Leistungsnachweis ein Feld für die Bestätigung/Freigabe enthalten (etwa Name des Prüfenden, Datum der Prüfung, Ergebnis „freigegeben“ oder „Beanstandung“). In einem digitalen Workflow könnte dies die elektronische Signatur oder Freigabemarkierung des Prüfers sein. Diese Information ist wichtig, um später nachvollziehen zu können, ob der Leistungsnachweis vor Rechnungsstellung vom Auftraggeber akzeptiert wurde. Im einfachsten Fall kann diese Freigabe auch im ERP-System hinterlegt sein, doch ein exportierter Leistungsnachweis könnte als statusfeld „vom AG genehmigt am ...“ enthalten.

• Referenz auf den zugrunde liegenden Vertrag oder die Bestellung (z.B. Bestellnummer, Vertragsnummer).

• Referenzen auf andere relevante Dokumente: z.B. Lieferscheine (bei Materiallieferungen), Abnahmeprotokolle, Genehmigungen.

• Rechnungsreferenz: Idealerweise wird die Rechnungsnummer erst bei Rechnungsstellung bekannt; dann sollte die Rechnung auf den Leistungsnachweis referenzieren. Alternativ, wenn der Leistungsnachweis zuerst im Prozess generiert wird, kann umgekehrt später im Leistungsnachweis die Rechnungsnummer nachgetragen oder verknüpft werden. Eine eindeutige ID des Leistungsnachweises ist essentiell, damit die Rechnung diese im Datensatz aufnehmen kann (siehe unten die Diskussion zu Standards: EN 16931 erlaubt z.B. pro Rechnungsposition einen Verweis auf einen „Objektidentifier“, was der Leistungsnachweis-ID entsprechen könnte).

Ein maschinenlesbarer Aufbau ermöglicht es, dass Software automatische Abgleiche vornimmt: Etwa kann das System jede Rechnungsposition einlesen und per ID oder Bestell-/Positionsnummer den zugehörigen Leistungsnachweisdatensatz suchen. Stimmen Leistungsbeschreibung, Menge und Preis überein, kann die Position automatisch als geprüft markiert werden. Abweichungen (z.B. die Rechnung enthält höhere Mengen als der Leistungsnachweis) können automatisch als Ausnahmefall zur manuellen Klärung markiert werden.

Darüber hinaus ermöglicht Standardisierung auch überbetriebliche Prozesse: Wenn Auftragnehmer und Auftraggeber auf ein gemeinsames Format geeinigt sind, können Leistungsnachweise direkt digital ausgetauscht werden. Beispielsweise könnte ein Dienstleister seine Leistungsnachweise in einem XML-Format an den Auftraggeber übermitteln (etwa via EDI/PEPPOL), der diese dann nahtlos in sein Prüfungssystem importiert. Damit das gelingt, muss die Struktur jedoch branchenspezifische Anforderungen berücksichtigen (siehe dazu Abschnitt Standards). Eine Herausforderung ist, ein Format zu finden, das hinreichend flexibel ist, um für verschiedene Branchen und Vertragsarten zu funktionieren, aber dennoch präzise Vorgaben macht, um Interoperabilität sicherzustellen.

Die inhaltliche Ausgestaltung eines Leistungsnachweises bestimmt maßgeblich, ob er für den Empfänger prüffähig ist. Wie bereits im Rechtsrahmen erörtert, muss der Leistungsnachweis so detailliert sein, dass der Auftraggeber nachvollziehen kann, welche Leistung in welcher Qualität und Menge erbracht wurde.

• Klare Leistungsbeschreibung: Jeder Eintrag muss verständlich beschreiben, was geleistet wurde. Hier können standardisierte Leistungsbeschreibungen oder Kataloge hilfreich sein (z.B. im Bauwesen die VOB/C-Leistungsbeschreibungen, in der IT evtl. ITIL-Services etc.). Eine Kodierung mit Klassifikationssystemen (z.B. CPV-Codes bei öffentlichen Aufträgen oder UNSPSC für Waren/Dienstleistungen) könnte zusätzlich maschinell unterstützen, ist aber als alleinige Beschreibung nicht ausreichend. Wichtig ist die eindeutige Zuordenbarkeit zur vereinbarten Leistung im Vertrag. Beispiel: Anstatt „Beratungsleistung 40 Stunden“ sollte stehen „IT-Consulting zur Implementierung von System X – 40 Stunden im Mai 2025, gem. Vertrag Pos. 3.2“. Dadurch sieht der Auftraggeber sofort, welche Vertragsleistung angesprochen ist.

• Mengen- und Einheitenangaben: Die Quantifizierung der Leistung muss prüffähig erfolgen. Im Bau z.B. durch Aufmaß: Der Leistungsnachweis sollte die Berechnung der Menge dokumentieren (etwa „Länge 5,0m × Breite 4,0m = 20,0 m² gestrichene Fläche“), ggf. mit Verweis auf Pläne oder örtliche Angaben. In Dienstleistungsverträgen sollten Zeitnachweise die genauen Stunden und idealerweise die Tage (z.B. „5h am 12.05., 7h am 13.05., ...“) oder Projektabschnitte ausweisen. Maschinenlesbar können solche Angaben als strukturierte Felder hinterlegt sein (z.B. eine Liste von Datum-Uhrzeit-Bereichen oder Einzelleistungen). Diese Detailtiefe macht die Prüfung für den Auftraggeber transparent: Er kann z.B. überprüfen, ob die abgerechneten Stunden mit dem tatsächlichen Anwesenheitsprotokoll übereinstimmen, oder ob die gemessene Bauleistung den Vertragspositionen entspricht. Aus Sicht des Rechnungsprüfers gilt: Je umfangreicher und komplexer eine Leistung ist, desto mehr Detailinformationen werden für die Prüfbarkeit benötigt. Der Standard sollte daher erlauben, bei Bedarf sehr detaillierte Informationen einzubetten. Für maschinelle Prozesse bedeutet dies auch, dass die Systeme ggf. nicht alle Details verstehen müssen, aber zumindest erkennen können, dass Nachweis-Dokumente vorhanden sind (z.B. ein Aufmaß als separate Datei). Sofern eine Vollautomatisierung angestrebt wird, könnten auch die Prüfregeln formalisiert werden (z.B. Vergleich der berechneten Fläche mit Planmaßen). Das erfordert jedoch domänenspezifische Logik und geht über einen generischen Standard hinaus.

• Belege und Anhänge: Oft besteht ein Leistungsnachweis nicht nur aus reinen Zahlen, sondern auch aus ergänzenden Unterlagen, die die Leistung dokumentieren – etwa Fotos, Prüfprotokolle, Zeichnungen, bei Bauleistungen der sog. geänderte Bau-Soll (Planänderungen) oder Messprotokolle. Ein Standard sollte daher vorsehen, dass Anhänge eingebunden werden können. Beispielsweise könnte ein XML-Leistungsnachweis die Möglichkeit bieten, Binärdokumente (PDFs, Bilder) als Base64 eingebettet mitzuliefern oder als externe Links zu referenzieren. So könnte eine Zeitaufschreibung als Excel oder PDF mitgesandt werden, falls dies nötig ist, oder ein Messdiagramm als Bild. Für die maschinelle Prüfbarkeit sind diese Anhänge per se schwierig (da unstrukturiert), aber sie sichern die vollständige Dokumentation für Revisionszwecke. Die Empfehlung (analog zur E-Rechnung) lautet, Anhänge möglichst ebenfalls strukturiert oder zumindest im Prozess integriert mitzuführen. Wichtig: Der Leistungsnachweis sollte in seinen Metadaten beschreiben, welche Anhänge vorhanden sind und was sie darstellen (z.B. Dokumenttyp „Zeichnung“, „Foto vorher/nachher“, „Messprotokoll Nr. 123“). Dies ermöglicht es dem Prüfer (menschlich oder AI-gestützt), gezielt die richtigen Nachweise einzusehen.

• Eindeutige Identifikatoren und Referenzen: Bereits angesprochen wurde die Notwendigkeit eindeutiger IDs. Jeder Leistungsnachweis sollte eine globale eindeutige Kennung tragen (z.B. eine UUID oder zumindest eine Kombination aus Lieferant + Nummer + Datum). Innerhalb des Leistungsnachweises sollten Positionen ebenfalls Identifikatoren haben. Diese erlauben im Zusammenspiel mit Rechnungen eine Verknüpfung. Ein strukturierter Leistungsnachweis kann z.B. jeder Position ein Leistungsnachweis-Positions-ID geben, die in der e-Rechnung beim jeweiligen Posten als „Leistungsobjekt-Referenz“ angegeben wird. EN 16931 sieht genau solch ein Feld vor (BT-128 „Object identifier for an item“), das genutzt werden könnte, um z.B. eine Service Entry Sheet Nummer oder Lieferschein-Nummer je Position anzugeben. Damit erkennt das System: Rechnungsposition 1 basiert auf Leistungsnachweis XYZ Pos. 10 etc. Diese Referenzierung ist der Schlüssel zur automatischen Abstimmung (“matching”). Ohne sie müsste über Textmatching oder Beträge geraten werden, was fehleranfällig ist. In einem standardisierten Szenario würde der Leistungsnachweis vor Rechnungsstellung erstellt und dem Rechnungssteller (ggf. vom Leistungsempfänger bestätigt) vorliegen; der Rechnungssteller (Auftragnehmer) nimmt diese IDs und fügt sie in seine elektronische Rechnung ein. Die Rechnung wird so zum zentralen Knoten, der über Referenzen mit den Leistungsnachweisen verbunden ist.

• Prüfvermerke und Status: Idealerweise enthält ein Leistungsnachweis auch Felder für den Prüfstatus (freigegeben/gesperrt) und eventuelle Kommentare oder Abweichungen. In vielen Fällen wird der Auftraggeber zunächst den Leistungsnachweis kontrollieren und bei Unstimmigkeiten Korrekturen verlangen, bevor die Rechnung gestellt wird. Ein digitaler Prozess könnte das abbilden: Der Leistungsnachweis hat initial Status „Eingereicht“, nach Prüfung vielleicht „Abgelehnt“ mit Kommentar oder „Freigegeben“ mit Freigabedatum. Diese Informationen sollten festgehalten werden, denn sie belegen im Streitfall, dass der Auftraggeber die Leistung anerkannt hat (konkludente Abnahme bei Werkverträgen!). Sie sind auch wichtig für die Revisionssicherheit, da man später nachvollziehen kann, welche Version des Nachweises gültig war.

Revisionssicherheit bedeutet in diesem Kontext, dass die Dokumentation den Anforderungen von Prüfern (intern oder extern, z.B. Wirtschaftsprüfer, Steuerprüfer) standhält. Ein revisionssicherer Leistungsnachweis muss insbesondere vollständig, wahr, zeitgerecht, geordnet und unveränderbar archiviert sein (Grundsätze ordnungsmäßiger Buchführung, § 239 HGB; GoBD).

• Unveränderbarkeit nach Finalisierung: Sobald ein Leistungsnachweis „abgeschlossen“ ist (z.B. vom Auftraggeber freigegeben und der Rechnung zugrunde gelegt), darf er nicht mehr inhaltlich verändert werden, ohne dass eine Änderungshistorie vorliegt. Technisch lässt sich dies durch protokollierte Versionsstände oder digitale Signaturen lösen. Beispielsweise könnte jeder Leistungsnachweis vom Ersteller digital signiert werden; nach Freigabe könnte der Freigeber eine zweite Signatur hinzufügen. Jede nachträgliche Änderung würde die Signaturen ungültig machen. Alternativ kann das Archivsystem sicherstellen, dass ursprüngliche Dokumente unverändert abgelegt werden (WORM-Speicher oder entsprechende Softwarekontrollen). Die GoBD fordert, dass Änderungen an elektronischen Aufzeichnungen ausgeschlossen oder zumindest dokumentiert werden. Dies gilt auch für zugehörige Dokumente wie Leistungsnachweise. In der Praxis sollte das verwendete Format etwa Zeitstempel und Prüfsummen beinhalten oder das DMS (Dokumentenmanagementsystem) übernimmt die Unveränderbarkeitsgarantie.

• Verknüpfung von Belegen (Prüfpfad): Revisionssicherheit erfordert, dass ein Prüfer die Entstehung und Abwicklung eines Vorgangs lückenlos nachvollziehen kann. Daher muss der Leistungsnachweis im System mit der Rechnung und dem Buchungssatz verknüpft sein. In einer idealen Standardisierung ist die Referenz gegenseitig: Die Rechnung verweist auf den Leistungsnachweis (siehe oben), und in der Ablage wird wiederum beim Leistungsnachweis vermerkt, in welcher Rechnung/ Buchung er mündete. So kann z.B. ein Betriebsprüfer von einer Kontobuchung auf die Rechnung und weiter auf den Leistungsnachweis gelangen. Diese Verknüpfung muss auch noch Jahre später bestehen, weshalb ein einheitliches Archivierungskonzept erforderlich ist. Die Bundesverwaltung fordert z.B. bei e-Rechnungen, dass Rechnungsanlagen eingebettet im Datensatz übermittelt werden – analog sollte der Leistungsnachweis zumindest logisch mitgeführt werden, anstatt als separates, womöglich verlorenes Dokument zu enden. Entweder man integriert den Leistungsnachweis als Anhang zur e-Rechnung (dazu später mehr bei Standards), oder man speichert ihn unter derselben Vorgangsnummer in einem Archiv.

• Metadaten und Indexierung: Ein standardisierter Aufbau erleichtert es, die Dokumente korrekt zu indizieren. Jedes Dokument sollte Metadaten tragen (z.B. Lieferant, Datum, Vertragsnummer, Projektnummer etc.), damit die spätere Suche und Zuordnung gelingt. Revisionssicher heißt auch, dass man innerhalb angemessener Zeit alle relevanten Belege finden kann. Ein XML-Leistungsnachweis kann solche Metadaten in definierte Felder packen, was die Indexierung automatisiert ermöglicht.

• Lesbarkeit für Menschen: Trotz aller Maschinenauswertbarkeit darf nicht vergessen werden, dass ein Prüfer oder Richter im Streitfall die Informationen menschenlesbar benötigt. GoBD verlangt die menschliche Lesbarkeit elektronischer Unterlagen während der gesamten Aufbewahrungsfrist. Daher sollte entweder das Format selbst lesbar sein (XML alleine ist für Laien schwer lesbar, aber es kann zumindest per Stylesheet oder Viewer dargestellt werden), oder es wird ein konvertiertes Format (PDF-Report) mitgespeichert. Ein Vorteil der Standardisierung ist, dass man generische Darstellungsprogramme entwickeln kann. Beispielsweise gibt es Viewer für XRechnung, welche die XML in ein verständliches Layout umsetzen. Ähnliches wäre für Leistungsnachweise denkbar.

Zusammengefasst muss der Leistungsnachweis inhaltlich vollständig und wahrheitsgemäß sein, strukturiert und referenzierbar vorliegen sowie unveränderlich und geordnet archiviert werden. Nur dann ist er "maschinenlesbar, prüffähig und revisionssicher" im Sinne der gestellten Anforderungen. Diese Anforderungen bilden den Maßstab, an dem existierende oder zu entwickelnde Standards für Leistungsnachweise zu messen sind. Im nächsten Abschnitt werden daher bestehende Standards und Normen betrachtet, die für eine solche Standardisierung in Frage kommen, und es wird analysiert, ob und wie sie angepasst werden müssen, um die skizzierten Anforderungen zu erfüllen.

Der elektronische Datenaustausch im Rechnungswesen stützt sich bereits auf verschiedene Standards, insbesondere für Rechnungsdaten selbst. Zu nennen sind hier vor allem die Europäische Norm EN 16931 für elektronische Rechnungen sowie darauf basierende Implementierungen wie XRechnung (deutscher Core Invoice Usage Specification) und ZUGFeRD/Factur-X (Hybridformat mit PDF und XML). Ferner hat sich das PEPPOL-Netzwerk mit der Spezifikation PEPPOL BIS Billing 3.0 als verbreiteter Austauschstandard etabliert, um strukturierte Rechnungen europaweit interoperabel zu versenden. Darüber hinaus existieren branchenspezifische Formate – so etwa GAEB-DA XML im Bauwesen – und globale Standards wie UBL 2.1 (Universal Business Language) oder UN/CEFACT CII (Cross Industry Invoice). Im Folgenden wird untersucht, inwieweit diese Standards Leistungsnachweise berücksichtigen und was ggf. angepasst oder erweitert werden muss, um Leistungsnachweise standardisiert abzubilden.

Die EN 16931 definiert das semantische Datenmodell einer Kernrechnung (core invoice). Sie legt also fest, welche Informationen eine elektronische Rechnung mindestens enthalten soll und wie sie strukturiert sind (z.B. Verkäufer, Käufer, Rechnungspositionen mit Beschreibung, Menge, Preis, Steuer etc.). Dieses Modell ist jedoch primär auf die Rechnung selbst fokussiert. Leistungsnachweise als separate Dokumente sind nicht Teil des Kerndatensatzes. Allerdings bietet die Norm Felder für Verweise auf begleitende Dokumente. Konkret gibt es im Modell die „Additional Supporting Documents“ (Geschäftsgruppen BG-24), die es erlauben, auf weitere Dokumente Bezug zu nehmen. In der technischen Umsetzung via UBL heißen diese Strukturen AdditionalDocumentReference. Darüber kann eine Rechnung z.B. einen Leistungsnachweis referenzieren, entweder durch Angabe einer Dokumentennummer, einer URL oder sogar durch Einbettung des Dokuments (Base64) in den Rechnungsdatensatz. So könnte ein Stundenzettel als eingebettete Datei in der E-Rechnung mitgeschickt werden. Die deutsche Umsetzung XRechnung verlangt sogar, dass etwaige Anlagen nicht separat per E-Mail geschickt, sondern immer im XML-Datensatz eingebettet werden, um die Einheitlichkeit und Zuordenbarkeit zu gewährleisten.

Diese Möglichkeit, Anhänge einzubetten, sorgt zumindest dafür, dass Leistungsnachweise mit der Rechnung zusammen elektronisch übermittelt und archiviert werden können. Allerdings bleibt der Inhalt des Leistungsnachweises in diesem Szenario unstrukturiert, sofern er z.B. als PDF eingebettet wird. Für die maschinelle Weiterverarbeitung ist das nicht ideal – das System erkennt zwar, dass eine „timesheet.pdf“ angehängt ist (ggf. anhand der DocumentDescription „Zeitnachweis“), aber kann die Details darin nicht ohne OCR oder manuelle Prüfung auswerten. Ein Zwischenschritt könnte sein, dass der Leistungsnachweis selbst ebenfalls in einem strukturierten XML-Format vorliegt und als solches angehängt wird (z.B. als XML Datei mit eigenem Schema, eingebettet in Base64). Das System des Empfängers könnte diese Datei dann separat einlesen und verarbeiten. In der Bauwirtschaft gibt es dazu bereits einen Ansatz: XRechnung erlaubt die Einbettung von GAEB-XML Dateien. So berichten Softwarehersteller, dass GAEB-Dateien vom Typ X89 oder X98b in die XRechnung eingebettet werden können, um Mengen auf Positionsebene mitzuliefern. Ein konkretes Beispiel: Ein Bauunternehmer sendet eine elektronische Rechnung im Format XRechnung; darin eingebettet ist eine GAEB X89B-Datei, welche die Rechnungspositionen mit dem Leistungsverzeichnis und Aufmaßdetails enthält. Das empfangende AVA-System oder ERP kann diese GAEB-Datei auslesen und erhält so strukturiert alle Leistungsdetails jeder Position. Dadurch wird die bisher bestehende „digitale Lücke“ zwischen Rechnung und Leistungsnachweis geschlossen. Die Orca AVA-Software kommentiert hierzu, dass GAEB X89B als vielversprechende Lösung gesehen wird, um geforderte rechnungsbegleitende Unterlagen (RBU) digital mitzuführen. Ist dieser Standard etabliert, wäre eine Automatisierung des Abgleichs Rechnung–Leistungsnachweis möglich.

Allerdings ist die EN 16931 in der aktuellen Fassung (und damit XRechnung) nicht auf hierarchische oder kumulative Rechnungen ausgelegt, wie sie im Bauwesen häufig vorkommen. Probleme treten auf bei Teilrechnungen, Abschlagszahlungen und der Zuordnung von Umsatzsteuer bei komplexen Leistungsverzeichnissen. Daher hat das Bundesministerium der Finanzen für die Baubranche eine Übergangsfrist von drei Jahren eingeräumt, während der man noch Zusatzinformationen als Anlagen beifügen darf, um diese Lücken zu überbrücken. Dies ist ein deutlicher Hinweis, dass der Standard weiterentwickelt werden muss, um branchenspezifische Anforderungen (wie etwa kumulative Abrechnungen und detaillierte Leistungsnachweise) besser abzudecken. Eine mögliche Weiterentwicklung wäre eine Erweiterung des EN 16931-Datenmodells um optionale Strukturen für hierarchische Positionen oder Nachweis-Details. Alternativ könnten Spezialprofile für Branchen definiert werden – z.B. ein „Construction Invoice Model“ als CIUS (Core Invoice Usage Specification) auf Basis von EN 16931, das Felder für Aufmaße etc. enthält.

Neben EN 16931/UBL gibt es das UN/CEFACT Cross-Industry Invoice (CII)-Format als weiteres XML-Schema, das in der EU als Alternativsyntax zugelassen ist. CII ist sehr mächtig und theoretisch flexibler in der Abbildung von komplexen Szenarien (z.B. erlaubt es tiefe Strukturen). Allerdings ist CII in der Praxis weniger verbreitet als UBL/PEPPOL. Es könnte aber eine Option sein, CII-Erweiterungen zu nutzen, um Leistungsnachweise direkt in der Rechnungsstruktur abzubilden.

ZUGFeRD/Factur-X wiederum nutzt entweder EN 16931-Core (im Profil EN16931) oder kann in erweiterten Profilen zusätzliche Felder aufnehmen. Denkbar wäre, dass ein zukünftiges Factur-X „Extended“ Profil Felder für Leistungsnachweis-IDs oder Details definiert. Bisher ist diese Richtung aber nicht bekannt; die Extended-Profile zielen eher auf branchenübergreifende Zusätze wie Bankverbindungen, Bestellnummern etc.

Ergebnis zu Rechnungsstandards: Die vorhandenen eRechnungs-Standards bieten Ansatzpunkte, Leistungsnachweise mitzutransportieren (über Anhänge/Referenzen), aber sie sind nicht speziell dafür entworfen, Leistungsnachweise inhaltlich standardisiert darzustellen. Es bedarf daher ergänzender Standards oder Profile, die die in Abschnitt 2 beschriebenen Leistungsnachweis-Datenstrukturen definieren.

In bestimmten Branchen existieren bereits etablierte Datenformate, die Teil des Leistungsnachweis-Prozesses sind. Hervorzuheben ist das GAEB-Format im Bauwesen. GAEB (Gemeinsamer Ausschuss Elektronik im Bauwesen) definiert Austauschformate für Ausschreibung, Vergabe und Abrechnung von Bauleistungen. Im Kontext Abrechnung gibt es GAEB-Dateien wie DA11, X31 (Aufmaß-Dateien) und X89, X90 (Abrechnungsunterlagen/Rechnung). Beispielsweise enthält eine GAEB-X31-Datei typischerweise detaillierte Aufmaße zu einzelnen Positionen (also die „Leistungsnachweise“ im Bau). Eine X89-Rechnungsdatei enthält die Abrechnungspositionen mit Bezug auf das Leistungsverzeichnis. Die neue Version X89B wird explizit als Medium genannt, um rechnungsbegleitende Unterlagen digital mitzuführen. Die Strategie ist, die XRechnung (bzw. EN16931-Rechnung) mit GAEB-Daten anzureichern, da GAEB die hierarchischen und mengenmäßigen Details liefern kann, die EN16931 fehlen.

Man kann GAEB als De-facto-Standard für Leistungsnachweise im Bau betrachten. Er ist allerdings sehr domänenspezifisch (enthält z.B. Bauleistungsverzeichnis-Kategorien, Kostengruppen, etc.). Für andere Gewerke ist GAEB nicht direkt nutzbar. Doch es zeigt, dass branchenspezifische Erweiterungen sinnvoll sind. Ähnliches könnte es in anderen Industriezweigen geben: Z.B. in der Fertigungsindustrie sind Lieferavise (Despatch Advice) standardisiert (im EDIFACT-Format DESADV oder als UBL DespatchAdvice) – sie dienen als Leistungsnachweis für Warenlieferungen. Für Dienstleistungen fehlt ein allgemein verbreiteter Standard, doch Ansätze existieren: Ein Zeiterfassungs-Datensatz könnte analog zu einem Lieferschein behandelt werden. Im PEPPOL-Netz gibt es z.B. den PEPPOL BIS Despatch Advice, der grundsätzlich auch für Dienstleistungen genutzt werden könnte (der Standardtext erwähnt, der DespatchAdvice kann sowohl für Waren als auch für Dienstleistungen verwendet werden). In der Praxis wird er meist für Warensendungen genutzt. Interessanterweise erlaubt der PEPPOL Despatch Advice ebenfalls, Anhänge wie Zeichnungen oder Stundenzettel mitzusenden. Das zeigt, dass man in solchen Nachrichten zwar an Leistungsnachweise denkt, aber diese wiederum unspezifisch als Binäranhang versendet. Ein definierteres Schema für z.B. „TimeSheet“ als XML gibt es im Peppol-Baukasten derzeit nicht. Theoretisch ließe sich ein neues Dokumentenprofil etablieren, z.B. „Service Delivery Report“ als eigenes PEPPOL-Dokument, analog zum Despatch Advice für Waren. Diese Option könnte im Rahmen der OpenPEPPOL-Community vorangetrieben werden, um auch Dienstleistungsnachweise standardisiert austauschen zu können. Bislang muss man sich hier mit generischen Methoden behelfen. Manche Unternehmen nutzen z.B. cXML (Commerce XML, verbreitet von B2B-Plattformen wie Ariba) für den Austausch von Bestellungen und Rechnungen; cXML hat das Konzept der „Service Entry Sheets“ in gewisser Weise im ERP integriert (z.B. SAP IDocs gibt es einen Typ „ServiceEntrySheet“). Aber ein offener Standard fehlt. Hier könnte UBL als Basis dienen: UBL ist sehr umfangreich und bietet auch Dokumenttypen wie Work Order, Order Response, etc. Zwar ist in UBL 2.3 kein dediziertes „Work Confirmation“ Dokument ersichtlich, doch UBL ist erweiterbar.

Neben GAEB gibt es eventuell in anderen Bereichen Normen: im IT-Projektgeschäft vielleicht MSP-Standards oder CSV-Strukturen für Zeitnachweise; in Wartungsverträgen eventuell DIN 276 (Kosten gliederung) – aber nichts so etabliert wie GAEB im Bau.

Fazit branchenspezifisch: Wo es ausgeprägte Branchenstandards gibt (Bau: GAEB), sollten diese in eine Gesamtlösung eingebunden werden, anstatt das Rad neu zu erfinden. Das bedeutet aber gleichzeitig, dass die Interoperabilität zwischen allgemeinem Rechnungsdatensatz und branchenspezifischem Nachweisdatenformat gewährleistet sein muss. Die GAEB-XRechnung-Kombination ist ein Beispiel einer solchen Interoperabilität. Für andere Branchen müsste man analog vorgehen: Identifizieren, welche Strukturen dort genutzt werden, und sie mit dem Rechnungsstandard verheiraten. Ggf. müssen neue branchenspezifische XML-Schemata entwickelt werden, wo es noch keine gibt (z.B. ein Standard-XML für Zeiterfassung bei Beratungsleistungen, orientiert an EVB-IT Mustern).

Die UBL 2.1/2.3 (OASIS Universal Business Language) verdient Erwähnung, weil sie quasi einen Werkzeugkasten an XML-Bausteinen für Geschäftsdokumente darstellt. UBL umfasst definierte Strukturen für Bestellungen, Lieferscheine, Rechnungen u.v.m. Sie ist auch die Grundlage von EN16931 (das Invoice-Modell lehnt sich daran an). UBL könnte prinzipiell um ein Konzept des Leistungsnachweises erweitert werden. Denkbar wäre, einen UBL-konformen XML-Schema zu definieren, etwa „PerformanceCertificate“ oder „ServiceCompletion“, das aus bestehenden UBL-Komponenten (Party, LineItem, etc.) gebaut ist. Damit würde man auf etablierten Syntaxelementen aufsetzen, was die Implementierung erleichtert (da viele Bibliotheken UBL unterstützen). UBL sieht z.B. bei Rechnungspositionen vor, einen Leistungszeitraum anzugeben – was für Dienstleistungen relevant ist – sowie OrderLineReference und DocumentReference je Position. Letzteres Feld (DocumentReference mit DocumentTypeCode=130) ist genau dafür gedacht, auf ein Objekt zu verweisen, auf dem die Rechnung basiert, z.B. ein vorheriges Dokument vom Lieferanten. In EN16931 ist festgelegt, dass Code „130“ als „Objektreferenz“ für eine Rechnungsposition zu nutzen ist. Dies könnte der Schlüssel sein, um Leistungsnachweise einzubinden: Der Leistungsnachweis erhält eine ID, und die Rechnung führt diese als DocumentReference@130 pro Position. So wird zumindest die Verknüpfung standardkonform hergestellt, auch wenn der Inhalt des Leistungsnachweises selbst nicht im Rechnungsformat steckt.

UBL hat weiterhin den Vorteil, dass es international und breit einsetzbar ist. Wenn deutsche Industrieunternehmen standardisierte Leistungsnachweise einführen, sollte dies nach Möglichkeit kompatibel mit internationalen Partnern sein – viele globale Unternehmen nutzen UBL (z.B. in skandinavischen Ländern, den Niederlanden etc. ist e-Invoicing via UBL Standard). Eine Erweiterung oder Profilbildung in UBL/PEPPOL-Kontext könnte also größere Akzeptanz finden, als ein komplett eigenständiger nationaler Standard.

PEPPOL BIS: Da PEPPOL die Implementierungsvorschriften liefert, wäre ein pragmatischer Weg: Das OpenPEPPOL-Konsortium könnte neue Profile schaffen, z.B. „BIS Service Confirmation“ analog zu BIS Despatch Advice. Die technischen Leitplanken (Validierungsregeln, Codelisten etc.) könnten dabei übernommen werden. Schon jetzt sind die existierenden BIS-Nachrichten so gestaltet, dass sie Attachments erlauben und Kerninformationen standardisiert austauschen. Es wäre also wenig überraschend, wenn in Zukunft PEPPOL den Bereich Procure-to-Pay um einen standardisierten Performance/Service Receipt ergänzt – zumal öffentliche Auftraggeber in der EU zunehmend End-to-End digitale Prozesse verlangen (Stichwort: elektronisches Bestellwesen und Wareneingang).

• Für Warenlieferungen: Hier existieren bereits eingeführte Standards (Despatch Advice, Lieferscheinformate, GS1/EDI) zur Leistungsbestätigung. Diese können als Leistungsnachweis dienen. Sie sollten in den Rechnungsabgleich integriert werden (z.B. automatischer 3-Wege-Abgleich Bestellung – Wareneingang – Rechnung). Anpassungsbedarf besteht weniger in den Formaten als in der konsequenten Referenzierung dieser Nachweise in der Rechnung (z.B. Angabe Lieferscheinnummer pro Rechnungsposition). EN16931 bietet hierzu Möglichkeiten, und XRechnung/PEPPOL-Regeln sollten diese stärker forcieren. Empfehlenswert wäre eine Validierungsregel, dass bei Sachlieferungen die Rechnungsposition einen Lieferscheinreferenz enthält – das ist heute optional, könnte aber in bestimmten Profilen verpflichtend gemacht werden.

• Für Dienst- und Werkleistungen: Ein eigenständiger Leistungsnachweis-Standard wird benötigt. Dieser könnte branchenspezifisch gestaltet sein (z.B. ein Standard für Bauleistungen = GAEB, einer für IT-Dienstleistungen, etc.), aber sollte zumindest auf einem gemeinsamen konzeptionellen Modell basieren, damit Mischkonstellationen (z.B. ein Rahmenvertrag mit sowohl Liefer- als auch Dienstleistungen) nicht zu völlig disparaten Daten führen. UBL bietet hier eine Ausgangsbasis. Ggf. könnten vorhandene, aber proprietäre Formate (z.B. SAP’s Service Entry Sheet IDoc, CSV-Formate) als Blaupause dienen. Wichtig wäre, dass so ein Standard öffentlich dokumentiert und frei nutzbar ist, um eine breite Implementierung zu fördern – analog zur offenen Verfügbarkeit von EN16931-Schemas.

• Integration mit e-Rechnung: Der Rechnungsstandard selbst könnte evolviert werden. Auf EU-Ebene könnte man überlegen, EN16931 um Felder für detailliertere Nachweis-Infos zu erweitern (vielleicht als optionale Module). Die in Deutschland aufgetretenen Probleme (Teilrechnungen, Bau) zeigen, dass der Kernstandard noch Lücken hat. Hier sollte normativ nachgebessert werden, gegebenenfalls durch eine EN16931-2 oder branchenspezifische Ergänzungsnormen. Bis dahin helfen nur nationale Profile (wie XRechnung mit Anlagen) oder bilaterale Absprachen.

• Standardisierungsgremien: Es wäre sinnvoll, dass Gremien wie DIN, CEN oder Branchenverbände sich des Themas annehmen. Für die Bauwirtschaft passiert dies durch GAEB kontinuierlich. Für den Industriesektor allgemein könnte der Verband elektronische Rechnung (VeR) oder Bitkom eine Rolle spielen, um Leitfäden für Leistungsnachweise zu entwickeln.

• XML-Schema Verfügbarkeit: Sobald es definierte XML-Schemata für Leistungsnachweise gibt (z.B. GAEB X89B, oder ein analoges Schema für Dienstleistungen), sollten diese breit publiziert werden, idealerweise als Ergänzung zu den e-Invoice Schemas. Die Existenz eines standardisierten XML allein ist aber nur die halbe Miete – es muss auch in Softwarelösungen implementiert und von den Parteien genutzt werden. Das führt zum letzten Abschnitt: den erforderlichen Maßnahmen zur Umsetzung in der Praxis.

Im Ergebnis gibt es geeignete Elemente in bestehenden Standards, doch eine vollständige Standardisierung des Leistungsnachweises erfordert ein Zusammenwirken verschiedener Normen. EN16931/PEPPOL bieten das Rückgrat für Rechnungsdaten und die Transportschicht; GAEB und ähnliche liefern detaillierte Fachformate; UBL gibt einen universellen Baukasten. Die Aufgabe besteht darin, diese Komponenten zusammenzuführen. Im folgenden Abschnitt wird daher betrachtet, welche technischen, organisatorischen und vertraglichen Maßnahmen notwendig sind, um einen solchen Standard erfolgreich in den Unternehmensalltag zu implementieren und einen rechtssicheren automatisierten Prüfprozess zu gewährleisten.

Die Einführung standardisierter Leistungsnachweise allein garantiert noch keinen Erfolg – es bedarf eines ganzheitlichen Maßnahmenbündels, um den Prüfprozess in Unternehmen rechtskonform und effizient zu gestalten. Dies umfasst technische Lösungen, organisatorische Abläufe und vertragliche Regelungen mit Geschäftspartnern. Im Folgenden werden diese drei Ebenen beleuchtet und Maßnahmen vorgeschlagen, um die zuvor entwickelten Standards und Anforderungen praktisch umzusetzen.

• Systemintegration und Workflows: Zunächst muss eine IT-technische Infrastruktur vorhanden sein, die Leistungsnachweise elektronisch erzeugen, übermitteln, empfangen und verarbeiten kann. In der Regel wird dies das ERP-System oder ein vorgelagertes Beschaffungs-/Projektmanagement-System übernehmen. Konkret sollten Unternehmen prüfen, ob ihr ERP (z.B. SAP, Oracle, Microsoft Dynamics) Module für Leistungsbestätigungen hat (SAP etwa hat das Konzept des „Service Entry Sheet“ für Dienstleistungsbestätigungen). Falls ja, sollten diese genutzt und so konfiguriert werden, dass sie nach dem definierten Standarddatensatz exportieren und importieren können. Ist dies nicht vorhanden, kommen spezialisierte Zusatzsoftware oder Workflow-Tools in Betracht (z.B. AVA-Software im Bau, die bereits GAEB und XRechnung kombiniert). Die Systeme müssen so integriert sein, dass bei Eingang einer elektronischen Rechnung die automatische Prüfung gegen die vorhandenen Leistungsnachweise angestoßen wird.

• Die Rechnung (XML) wird eingelesen; für jede Position wird die referenzierte Leistungsnachweis-ID ausgelesen.

• Das System sucht im Datenbestand den entsprechenden Leistungsnachweis-Datensatz.

• Die relevanten Felder (Menge, Artikel/Leistungsnummer, Preis) werden verglichen.

• Bei Übereinstimmung erfolgt ein Haken, bei Abweichung wird ein Fehler erzeugt.

Damit dieser Abgleich fehlerfrei laufen kann, müssen vorher die Leistungsnachweise elektronisch vorliegen. Es empfiehlt sich daher, Lieferanten / Auftragnehmer aktiv in den Prozess einzubinden: Zum Beispiel könnten sie über ein Webportal ihre Leistungsnachweise einreichen (in Standard-XML), die vom Auftraggeber geprüft und im System freigegeben werden. Der Clou: Sobald freigegeben, könnte das System daraus automatisch eine Bestätigungsmeldung oder sogar eine Gutschrift generieren. Alternativ erstellt der Lieferant selbst die Rechnung, aber weiß durch die Freigabe, dass sie durchgehen wird. Solche End-to-End-Prozesse (oft Closed Procurement Loop genannt) sind technisch anspruchsvoll, aber modernste Software (Stichwort: Procure-to-Pay Plattformen) bieten so etwas bereits an. Beispiele sind Ariba, Coupa etc., die einen Abgleich Purchase Order – Goods Receipt – Invoice als Kernfunktion haben.

• Datensicherheit und Authentizität: Um rechtssicher zu sein, müssen technische Maßnahmen getroffen werden, die die Authentizität und Integrität der Dokumente gewährleisten.

• Nutzung sicherer Übertragungswege: Der Austausch von Rechnungen und Leistungsnachweisen sollte beispielsweise über PEPPOL oder andere gesicherte Netzwerke erfolgen, oder per verschlüsselter Verbindung zu einem Portal. E-Mail ohne Ende-zu-Ende-Verschlüsselung wäre unsicher.

• Digitale Signatur von Leistungsnachweisen und Rechnungen: Zwar ist rechtlich die Signatur keine Pflicht mehr, doch technisch kann sie das Vertrauen stärken. Denkbar ist, dass ein Leistungsnachweis vom Aussteller qualifiziert elektronisch signiert wird, um seine Urheberschaft und Unverändertheit zu dokumentieren. Ebenso könnte der Auftraggeber bei Freigabe eine Signatur anbringen („geprüft und freigegeben von...“). Alternativ können auch Siegel (Unternehmenssignaturen) oder Blockchain-Technologien genutzt werden, um eine fälschungssichere Nachweis-Kette zu erzeugen. Wichtig ist, dass im Streitfall gezeigt werden kann, wann und von wem ein Nachweis erstellt und genehmigt wurde, ohne Manipulationsmöglichkeit.

• Validierungstools: Technisch sollten eingehende Dateien gegen das Schema validiert werden (z.B. XML Schema Validation) und weitere Geschäftsregeln geprüft werden. Hier helfen Standard-Bibliotheken (für EN16931 gibt es z.B. offene Validierungsartefakte). Für den Leistungsnachweis-Standard müsste ähnliches geschaffen werden. Unternehmen sollten diese Validierungen einrichten, um sofort fehlerhafte Dateien abzulehnen und korrekte Daten zu verarbeiten.

• Archivierungssystem: Ein zentrales technisches Element ist die revisionssichere Archivierung (elektronisches Archiv oder DMS). Dieses System muss die Vorgaben der GoBD erfüllen – es sollte also z.B. über eine Unveränderbarkeitsfunktion verfügen (WORM, Protokollierung von Änderungen), Berechtigungsmanagement (nur lesender Zugriff für die Mehrheit, Löschungen nur gemäß Aufbewahrungsfristen und protokolliert) und Möglichkeiten, Datenexport für Prüfer bereitzustellen (GDPdU/IDEA-Konforme Exporte). Leistungsnachweise und Rechnungen sollten gemeinsam archiviert werden. Das heißt z.B.: im Archiv wird pro Vorgang ein „Dossier“ angelegt, in dem alle zugehörigen Dokumente liegen. Oder es gibt Verknüpfungsfelder. Moderne Systeme erlauben eine Suche, die etwa bei Eingabe der Rechnungsnummer alle verknüpften Leistungsnachweise findet. Ein hoher Automatisierungsgrad und Standardformat erleichtert dies: Metadaten können automatisch ausgelesen und als Index ins Archiv gegeben werden. Die Nachvollziehbarkeit (GoBD-Prinzip) wird so sichergestellt, da ein Prüfer lückenlos vom Beleg zum Folgebeleg springen kann.

• Schnittstellen und Interoperabilität: Technische Maßnahmen müssen auch unternehmensübergreifend gedacht werden. Daher sollten Unternehmen auf Standardschnittstellen setzen. Die Einführung von PEPPOL-Schnittstellen, die sowohl Rechnungen als auch Despatch Advices etc. verarbeiten können, ist ratsam. Einige Provider bieten ganzheitliche e-Prokurationslösungen an, die bereits auf solche Standards bauen. Wenn ein Unternehmen viele Lieferanten hat, die technisch weniger ausgestattet sind, könnte es auch Konverter-Services bereitstellen: z.B. ein einfaches Web-Formular, in das der Lieferant die erbrachten Leistungen eintippt, woraufhin das System daraus einen strukturierten Leistungsnachweis generiert. Solche Portalansätze verhindern, dass man jeden kleinen Dienstleister von XML überzeugen muss – stattdessen nutzt er eine Weboberfläche und im Hintergrund läuft Standardkommunikation. Wichtig ist, dass die Datenqualität stimmt: Fehlerhafte oder unvollständige Leistungsnachweise führen zu Verzögerungen. Deshalb sollten technische Validierungen so früh wie möglich (möglichst schon beim Lieferanten-Eingabefeld) ansetzen.

• Automatisierung und KI-Unterstützung: Perspektivisch können technische Hilfsmittel wie künstliche Intelligenz helfen, insbesondere bei der Prüfung von unstrukturierten Teilen. Z.B. wenn trotz Standard mal ein PDF-Anhang mit Beschreibung vorliegt, könnte eine semantische Analyse prüfen, ob der Inhalt plausibel zur Rechnung passt. Oder bei Abweichungen können Systeme Vorschläge machen (etwa „Die abgerechnete Menge überschreitet den Leistungsnachweis um 5%, wahrscheinlich Tippfehler?“). Solche fortgeschrittenen Tools sind Kür, aber langfristig erhöhen sie die Effizienz und Sicherheit im Prozess.

In Summe schaffen die technischen Maßnahmen die Infrastruktur dafür, dass Leistungsnachweis-Daten fließen und geprüft werden können, während Sicherheit und Dokumentation gewährleistet sind. Doch Technologie allein genügt nicht; es muss auch organisatorisch verankert werden.

Die besten technischen Lösungen nützen wenig, wenn sie nicht in passende Prozesse und organisatorische Regeln eingebettet sind.

• Prozessdefinition und Verantwortlichkeiten: Das Unternehmen muss den Prozess der Leistungsnachweiserfassung und Rechnungsprüfung klar definieren. Typische Fragen: Wer erstellt den Leistungsnachweis (der Auftragnehmer oder der verantwortliche Sachbearbeiter beim Auftraggeber)? Wer prüft und gibt ihn frei (Fachabteilung, Projektleiter, Bauleiter, Einkäufer)? Wie wird die Freigabe dokumentiert? Ab wann darf eine Rechnung gestellt werden? Diese Schritte sollten in einer Verfahrensanweisung festgehalten werden. Beispielsweise könnte die Regel lauten: „Nach Erbringung der Leistung erstellt der Auftragnehmer innerhalb von 5 Werktagen einen Leistungsnachweis im Portal. Der zuständige Fachbereich prüft diesen innerhalb 10 Werktagen. Bei Übereinstimmung wird digital freigezeichnet, bei Abweichungen Rückfrage/ Korrektur. Erst nach Freigabe darf der Auftragnehmer die Rechnung legen, die innerhalb weiterer 5 Tage zu erfolgen hat.“ Solche Fristen und Abläufe sorgen für Klarheit und Schnelligkeit. Sie stellen auch sicher, dass der Verification Process nicht unendlich in die Länge gezogen wird, was im Sinne der EU-Zahlungsverzugsrichtlinie wichtig ist (diese verlangt, dass Prüf- und Abnahmeprozesse i.d.R. innerhalb 30 Tagen abgeschlossen sein sollen, um rechtzeitige Zahlung zu gewährleisten). Organisatorisch sollte auch festgelegt werden, wie mit Abweichungen umzugehen ist: z.B. welches Gremium entscheidet, ob eine nicht zu 100% prüffähige Rechnung dennoch (teilweise) bezahlt wird oder ob formale Mängel rügbar sind.

• Schulung und Change Management: Die Einführung eines standardisierten, automatisierten Prüfprozesses bedeutet oft Veränderung der Arbeitsweise. Mitarbeiter in Einkauf, Fachabteilungen und Buchhaltung müssen entsprechend geschult werden. Sie müssen verstehen, wie sie Leistungsnachweise elektronisch bearbeiten, was die neuen Tools tun, und warum diese Genauigkeit wichtig ist (Stichwort rechtliche Konsequenzen, z.B. Fälligkeit hängt dran). Ein geübter Bauleiter mag früher per Handschlag Leistungen abgenommen haben – nun muss er ggf. ins Tablet den Leistungsnachweis elektronisch freigeben. Solche Änderungen brauchen Überzeugungsarbeit. Ein Vorteil: Die Mitarbeiter von monotoner Prüfarbeit zu entlasten (wenn automatisiert geprüft wird) – das sollte kommuniziert werden. Ebenso ist Lieferantenschulung bzw. -einbindung relevant: Kommunikation mit Lieferanten über die neuen Anforderungen (z.B. „Ab 2025 akzeptieren wir nur noch e-Rechnungen mit standardisierten Leistungsnachweisen, bitte registrieren Sie sich in unserem Portal...“). Hier sind Hilfestellungen zu bieten, damit die Geschäftspartner mitziehen und keine Brüche im Prozess entstehen.

• Internes Kontrollsystem (IKS): Aus Compliance-Sicht sollte der neue Prozess Teil des Internen Kontrollsystems sein. Das bedeutet: Es werden Kontrollpunkte definiert (z.B. „Systemabgleich Rechnung-Leistungsnachweis durchgeführt und protokolliert“), Zuständigkeiten für Kontrollen (z.B. Buchhaltung überprüft stichprobenhaft die korrekte Funktionsweise der Automatik oder klärt Differenzen) und ggf. Vier-Augen-Prinzipien (z.B. Freigabe durch Fachabteilung und zusätzliche Freigabe ab einem gewissen Betrag). Diese Vorkehrungen dienen der Prävention von Fehlern und Missbrauch. Beispielsweise könnte das IKS vorsehen, dass ohne elektronischen Leistungsnachweis keine Rechnung zur Zahlung angewiesen wird – was technisch erzwungen wird. Oder dass bei manueller Übersteuerung (falls mal ausnahmsweise ohne LN gezahlt wird) ein hoher Genehmigungslevel erforderlich ist. All dies muss in Verfahrensdokumentation einfließen, die auch Prüfern vorgelegt werden kann. Damit wird demonstriert, dass das Unternehmen seinen Pflichten (Authentizitäts-/Integritätsnachweis, ordentliche Buchführung) nachkommt.

• Verknüpfung mit bestehenden Prozessen: Der Leistungsnachweis-Prozess sollte idealerweise in bestehende Prozessketten integriert sein, um Medienbrüche zu vermeiden. Beispielsweise: Im Einkauf wird ein Rahmenvertrag abgeschlossen und im System hinterlegt; bei Bedarf wird eine Bestellung/Abruf erzeugt; das System erwartet dann einen Wareneingang oder Leistungsnachweis. Diese Erwartung könnte im System parametriert sein (z.B. Positionstyp „Dienstleistung“ erfordert Service Entry Confirmation). Wenn dann eine Rechnung kommt, ohne dass ein Leistungsnachweis vorliegt, soll das System sie automatisch sperren und eine Nachricht erzeugen. Umgekehrt, wenn der Leistungsnachweis vorliegt und geprüft ist, kann die Rechnung direkt durchgewunken werden (Straight-Through-Processing), was Effizienz bringt. Diese Kopplung erfordert, dass alle Abteilungen mitspielen: Der Einkauf muss die richtigen Bestelltypen nutzen, die Fachabteilung muss die Leistung verbuchen, etc. Das muss organisatorisch abgestimmt sein.

• Monitoring und KPIs: Es ist sinnvoll, den Prozess zu überwachen. Organisation sollte Kennzahlen erheben, z.B. „Anteil automatisch abgeglichener Rechnungen“, „Durchschnittliche Durchlaufzeit vom Leistungsnachweis bis Zahlung“, „Anzahl der Beanstandungen wegen fehlender Prüfbarkeit“. Diese KPIs helfen, Schwachstellen zu finden (etwa bestimmte Lieferanten, die ständig unvollständige Nachweise liefern) und liefern Argumente für weitere Verbesserungen oder Anpassungen von Verträgen.

• Umgang mit Ausnahmen: Trotz Standard kann es immer Sonderfälle geben (z.B. ausländische Lieferanten, rechtliche Sondertatbestände wie Bauhandwerkersicherung, etc.). Organisatorisch sollte es klar definierte Workarounds geben: Etwa, wenn ein Kleinstlieferant technisch nicht in der Lage ist, den Standard zu bedienen, wer entscheidet dann über händische Verfahren? Oder wenn aus rechtlichen Gründen (z.B. öffentliche Vergabe?) ein anderes Format verlangt wird, wie geht man damit um? Solche Ausnahmeprozesse sollte man definieren, um im Einzelfall handlungsfähig zu bleiben, ohne die Grundprinzipien zu verletzen.

Insgesamt stellen die organisatorischen Maßnahmen sicher, dass die Menschen und Abläufe in Einklang mit den technischen Möglichkeiten arbeiten. Sie schaffen Transparenz, Kontrolle und Effizienz im Prozess, was letztlich ein wesentlicher Teil von „Rechtssicherheit“ ist – denn ein klar geregelter Prozess beugt Streit und Fehlern vor.

Damit der Standardisierungs- und Digitalisierungsprozess auch zwischen Unternehmen reibungslos funktioniert, müssen entsprechende vertragliche Vereinbarungen getroffen werden. Dies betrifft sowohl die Verträge mit Lieferanten/Auftragnehmern als auch interne Regelungen und ggf. Kundenverträge auf der Verkaufsseite. Schwerpunktmäßig geht es aber um Verträge mit den Leistungserbringern (Auftragnehmerseite).

• Vereinbarung der Form des Leistungsnachweises: Bereits im Vertrag (z.B. Rahmenvertrag oder Einzelvertrag) sollte festgehalten werden, welche Form von Leistungsnachweis der Auftragnehmer zu erbringen hat. Das kann sehr konkret erfolgen: z.B. „Der Auftragnehmer wird nach Leistungserbringung einen elektronischen Leistungsnachweis im Format XYZ (Anlage X zum Vertrag beschreibt das Datenformat) erstellen und dem Auftraggeber über das Portal Y zur Verfügung stellen. Der Leistungsnachweis muss die vereinbarten Leistungspositionen, Mengen und Preise enthalten sowie von einem Bevollmächtigten des Auftragnehmers elektronisch signiert sein.“ Durch eine solche Klausel wird der Standard quasi zum Vertragsbestandteil erhoben. Wichtig ist auch die Fristsetzung: „...innerhalb von X Tagen nach Ausführung der Leistung“. Damit wird verhindert, dass Leistungsnachweise verspätet kommen und dadurch Zahlungen verzögert werden.

• Anerkennung des elektronischen Verfahrens: Weiterhin sollte der Vertrag regeln, dass beide Parteien das elektronische Prüfverfahren als rechtsverbindlich anerkennen. Beispielsweise könnte festgehalten werden: „Die Parteien stimmen zu, dass der in diesem Vertrag festgelegte elektronische Leistungsnachweis- und Rechnungsprüfprozess den Anforderungen des § 14 UStG (Authentizität und Unversehrtheit der Rechnung) genügt und als verlässlicher Prüfpfad im Sinne der Steuervorschriften gilt.“ Solche Formulierungen schaffen Klarheit, dass keine Partei später argumentieren kann, die elektronische Form sei unzureichend. Ebenfalls könnte geregelt werden, dass z.B. eine elektronische Freigabe eines Leistungsnachweises einer schriftlichen Abnahme gleichsteht, um Werkvertragsrechtlich Klarheit zu haben (schriftliche Abnahme ist ja ein wichtiger Punkt, den man hier elektronisch substituiert).

• Pflichten bei Abweichungen: Der Vertrag kann definieren, was passiert, wenn der Leistungsnachweis nicht den Vorgaben entspricht. Z.B.: „Ist der Leistungsnachweis inhaltlich unvollständig oder weicht die darin dokumentierte Leistung von der vertraglich geschuldeten Leistung ab, wird der Auftraggeber dies innerhalb von 5 Werktagen rügen. Der Auftragnehmer hat den Nachweis entsprechend zu korrigieren. Bis zur Erbringung eines prüffähigen Leistungsnachweises ist der Auftraggeber berechtigt, die Zahlung zurückzubehalten.“ Diese Klausel schafft verbindliche Regeln zur Nacharbeit und verbindet nochmals deutlich Prüfbarkeit mit Fälligkeit, aber in fairer Weise (mit Fristen und Reaktionspflichten). Sie muss im Rahmen von § 307 BGB ausgewogen formuliert sein – wie das Beispiel zeigt, wird dem AN Gelegenheit zur Korrektur gegeben und kein ewiger Zahlungsausschluss festgelegt, was gemäß der zitierten Rechtsprechung unzulässig wäre.

• Elektronische Rechnungsstellungspflicht: Um die Prozesse komplett zu machen, sollte im Vertrag (oder z.B. in den Einkaufsbedingungen) vereinbart werden, dass der Auftragnehmer verpflichtet ist, elektronische Rechnungen nach dem gemeinsamen Standard zu stellen. In Deutschland ist für B2G mittlerweile gesetzlich die E-Rechnung vorgeschrieben; für B2B darf man es vertraglich vereinbaren. Das heißt, es sollte klargestellt sein: „Rechnungen sind vom Auftragnehmer ausschließlich elektronisch im XML-Format XRechnung (oder ZUGFeRD Profil X) zu übermitteln, wobei im Rechnungsdatensatz die Freigabe-ID des Leistungsnachweises je Position anzugeben ist.“ So stellt man sicher, dass die implementierte Technologie (siehe technische Maßnahmen) auch vertraglich eingefordert werden kann. Falls ein Auftragnehmer dennoch Papierrechnungen schickt, verstößt er gegen den Vertrag – der Auftraggeber könnte sie zurückweisen.

• EDI-Vereinbarungen / Umgang mit elektronischen Dokumenten: Bei einem vollautomatisierten Datenaustausch empfiehlt sich zudem der Abschluss einer EDI-Vereinbarung oder zumindest eine Klausel zur elektronischen Kommunikation. Darin wird geregelt, dass die ausgetauschten elektronischen Dokumente den Papierdokumenten gleichstehen, dass z.B. ein in elektronischer Form ausgestellter Leistungsnachweis als Urkunde gilt und nicht zusätzlich in Papierform nachgereicht werden muss. Typischer Inhalt solcher Vereinbarungen ist auch die Festlegung von Zustell- und Zugangszeitpunkten (wann gilt ein elektronisches Dokument als zugegangen?), von Verfahren bei Fehlern (wie wird verfahren, wenn eine Datei korrupt ist?), und von Beweisabreden (z.B. Protokolldateien als Beweis für Zugang). Diese Punkte sind wichtig, um spätere Streitigkeiten vorzubeugen, etwa wenn der Auftragnehmer behauptet, er habe den Leistungsnachweis gesendet, aber er kam nie an. Mit klaren EDI-Regeln (bspw. „Der Absender erhält eine Empfangsbestätigung, anderenfalls gilt das Dokument als nicht zugegangen“) kann man solche Fälle antizipieren.

• Datenschutz und Vertraulichkeit: Falls Leistungsnachweise personenbezogene Daten enthalten (z.B. Namen von Mitarbeiter X hat 5 Stunden gearbeitet), sollte im Vertrag auch ein Hinweis auf Datenschutz erfolgen. Möglicherweise ist ein Auftragsverarbeitungsvertrag nötig, wenn der Auftraggeber diese Daten speichert. Zumindest sollte geregelt sein, dass beide Seiten die DSGVO einhalten, Daten nur zum Zweck der Vertragsabwicklung nutzen und nach Ablauf der Fristen löschen. Ebenso ist meist eine Vertraulichkeitsklausel im Vertrag, die auch die elektronischen Dokumente einschließt – wichtig etwa, wenn Konstruktionszeichnungen als Nachweis dienen, die nicht an Dritte gelangen sollen.

• Bei Werkverträgen: die elektronische Leistungsfeststellung könnte Bestandteil der Abnahme sein. Man könnte formulieren, dass die Freigabe des Leistungsnachweises durch den Auftraggeber als (Teil-)Abnahme gilt, sofern nicht binnen einer bestimmten Frist Vorbehalte angemeldet werden. Das schafft Klarheit, wann die Werkleistung als abgenommen gilt (wichtig für Beginn der Gewährleistungsfrist etc.).

• Bei Dienstverträgen: hier könnte man die monatliche Turnusabrechnung regeln, d.h. der Auftragnehmer führt ein elektronisches Stundenerfassungssystem und der Auftraggeber bestätigt monatlich die Stunden – das gilt dann als Abrechnungsgrundlage.

• Bei Rahmen-/Abrufverträgen: man sollte festhalten, dass jeder Abruf als eigenes „Projekt“ mit Leistungsnachweisen behandelt wird, und eventuell dem Rahmenvertrag eine Anlage beifügen, die das Verfahren beschreibt. Oft werden bei Rahmenverträgen Leistungsnachweise pro Abruf oder Auftragsschein geführt.

• Sanktionen und Anreize: Vertraglich kann man auch Anreize oder Sanktionen setzen, um die Einhaltung der Prozesse zu fördern. Z.B.: „Erfüllt der Auftragnehmer die vorstehenden Verpflichtungen zur elektronischen Nachweis- und Rechnungstellung nicht, so gerät er mit Zugang unvollständiger Unterlagen nicht in Zahlungsverzug des Auftraggebers; vereinbarte Skontofristen beginnen erst ab Zugang der vollständigen Unterlagen zu laufen.“ Oder positiv: „Bei Einhaltung aller Vorgaben wird die Rechnung bevorzugt innerhalb von X Tagen bezahlt“ – was einem freiwilligen früheren Zahlungsziel entspräche. Solche Klauseln motivieren zur Compliance im Prozess.

• Zusammenarbeit bei Weiterentwicklung: Da Standards und Technologien sich entwickeln, könnte man eine Kooperationsklausel aufnehmen: „Die Parteien verpflichten sich, im Falle zukünftiger Änderungen gesetzlicher Anforderungen (z.B. neue E-Invoicing-Vorschriften der EU) oder Verbesserungen der Standardformate die Vereinbarungen entsprechend anzupassen und konstruktiv zusammenzuarbeiten, um den Prozess auf dem Stand der Technik zu halten.“ Damit drückt man aus, dass beide Seiten flexibel bleiben und Upgrades (z.B. Umstieg auf neuere Schema-Versionen) unterstützen.

Durch solche vertraglichen Maßnahmen wird die Verbindlichkeit des standardisierten Leistungsnachweisprozesses abgesichert. Im Idealfall bilden Vertrag, Organisation und Technik ein nahtloses Gefüge: Der Vertrag verpflichtet zur Nutzung des Systems; die Organisation stellt die Umsetzung sicher; die Technik führt es aus. Dies schafft eine rechtssichere Basis, da alle Eventualitäten (Zugang, Form, Wirkung der elektronischen Dokumente) geregelt sind und alle Beteiligten (Menschen wie Systeme) wissen, was zu tun ist.