Rechnungen, die SAP nicht abbildet: E-Rechnungs-konform ohne SAP-Projekt

In fast jedem Unternehmen, das mit SAP fakturiert, gibt es eine zweite, leisere Rechnungswelt: die Fälle, die das System nicht abbildet. Sondervereinbarungen, Weiterberechnungen, Nebenerlöse, Konstellationen, die das Customizing nie vorgesehen hat. Diese Rechnungen entstehen heute in Word oder Excel, werden als PDF exportiert und per Mail verschickt. Das funktioniert seit Jahren, und je nach Haus reden wir nicht über Einzelfälle, sondern über hunderte bis tausende Rechnungen im Monat.

Mit der E-Rechnungspflicht wird genau diese Restmenge zum Compliance-Problem: Ab dem 1. Januar 2027 dürfen Unternehmen mit mehr als 800.000 Euro Gesamtumsatz im Vorjahr im inländischen B2B-Geschäft keine einfachen PDF-Rechnungen mehr stellen. Und die naheliegenden Antworten passen beide nicht. Die Rechnungen in SAP nachzubauen scheitert am selben Grund, aus dem sie nie in SAP waren. Eine zweite Rechnungssoftware einzuführen nimmt den Fachabteilungen genau die Flexibilität, wegen der sie in Word arbeiten.

Die kurze Antwort dieses Artikels: Sie brauchen weder ein SAP-Projekt noch eine zweite Rechnungssoftware. Der Word-Excel-Prozess kann bleiben, wenn dahinter eine Schicht sitzt, die aus der fertigen PDF eine konforme E-Rechnung macht, sie validiert, zustellt und archiviert. Der lange Weg dorthin, inklusive der beiden Alternativen und ihrer ehrlichen Nachteile, steht in den nächsten Abschnitten.

Warum es diese Rechnungen überhaupt gibt

Wer nur die offizielle Systemlandschaft kennt, wundert sich, dass ein Konzern mit SAP überhaupt Rechnungen in Word schreibt. Wer die Fakturierungspraxis kennt, wundert sich nicht. Die typischen Gründe:

• Individuelle Vertragskonstellationen. Sonderkonditionen, Staffeln, einmalige Vereinbarungen, Freitextpositionen: Was die Preisfindung und die Formulare im SAP nicht vorsehen, lässt sich dort ohne Change Request nicht abrechnen. Die Fachabteilung braucht die Rechnung aber diese Woche.
• Nebenerlöse außerhalb des Kerngeschäfts. Weiterberechnung von Kosten, Untervermietung, Schadensersatz, Versicherungserstattungen, Verkauf von Anlagevermögen. Für Erlösarten, die es ein paar Mal im Jahr gibt, wird kein Fakturierungsprozess eingerichtet.
• Konzerninterne Weiterberechnungen. Leistungen zwischen Gesellschaften, die über Buchungskreis-Grenzen laufen und im System nicht als Kundenauftrag existieren.
• Gesellschaften ohne ERP-Anbindung. Zugekaufte Einheiten, kleine Tochtergesellschaften, ausländische Standorte: bis die Integration kommt (wenn sie kommt), wird manuell fakturiert.
• Wirtschaftlichkeit. Ein Customizing-Projekt für einen Sonderfall kostet oft mehr, als der Sonderfall je einbringt. Word ist die rationale Antwort darauf, kein Versäumnis.

Das Muster dahinter: SAP deckt die strukturierte Masse ab, Word deckt den Rest ab. In der Summe ist dieser Rest größer, als man denkt. Bei großen Häusern sind es schnell drei- bis vierstellige Stückzahlen pro Monat, verteilt über mehrere Abteilungen und Gesellschaften.

Was die E-Rechnungspflicht für diese Restmenge bedeutet

Seit dem 1. Januar 2025 ist die E-Rechnung im inländischen B2B-Geschäft der gesetzliche Standard. Eine E-Rechnung im Sinne von § 14 UStG ist ein strukturiertes elektronisches Format nach der europäischen Norm EN 16931, in Deutschland praktisch XRechnung oder ZUGFeRD. Eine PDF aus Word ist seitdem nur noch eine „sonstige Rechnung".

Für die Ausgangsseite gelten Übergangsfristen, und hier lohnt ein genauer Blick, weil für größere Unternehmen die frühere Frist greift:

• Ab 1. Januar 2027 müssen Unternehmen mit mehr als 800.000 Euro Gesamtumsatz im Vorjahr E-Rechnungen stellen. Gesamtumsatz heißt: der gesamte Umsatz im Sinne des § 19 Abs. 3 UStG, nicht nur der B2B-Anteil. Praktisch jedes Unternehmen, das in diesem Artikel gemeint ist, liegt darüber.
• Ab 1. Januar 2028 gilt die Pflicht für alle übrigen.

Die vollständige Zeitachse mit allen Ausnahmen steht im Artikel zur E-Rechnungspflicht. Zwei Punkte daraus sind für die Word-Restmenge besonders relevant:

Die Pflicht gilt pro Rechnung, nicht pro System. Es zählt nicht, dass 98 Prozent Ihrer Rechnungen sauber aus SAP kommen. Jede einzelne Word-Rechnung an einen inländischen Unternehmer muss ab dem Stichtag eine E-Rechnung sein.

Dauerrechnungen haben eine Sonderregel. Für Dauerrechnungen, die vor dem Stichtag als sonstige Rechnung gestellt wurden (etwa monatliche Pauschalen), muss erst dann eine E-Rechnung ausgestellt werden, wenn sich die Rechnungsangaben ändern. Das verschafft Luft, ist aber kein Freifahrtschein: Jede Preisanpassung löst die Pflicht aus. Details dazu im Beitrag zum BMF-Schreiben.

Die drei Optionen im Vergleich

Option 1: SAP erweitern, bis auch die Sonderfälle hineinpassen

Der architektonisch sauberste Weg: Customizing, Formulare und Preisfindung so ausbauen, dass die Sonderfälle in SAP fakturiert werden können, und für Format und Übermittlung SAP Document and Reporting Compliance (DRC) oder ein Add-on einsetzen.

Nur: DRC löst das Format-Problem für Rechnungen, die SAP erzeugt. Es erzeugt keine Rechnungen, die SAP nicht abbilden kann. Der eigentliche Aufwand steckt also nicht im E-Rechnungs-Baustein, sondern darin, jeden Sonderfall einzeln in Customizing zu gießen. Das sind Projekte mit Beratungstagen, Change-Prozessen und Regressionsrisiko, für Fälle, die einzeln betrachtet wirtschaftlich nie ein Projekt rechtfertigen. Genau daran ist es in der Vergangenheit ja gescheitert, sonst gäbe es die Word-Rechnungen nicht.

Sinnvoll ist dieser Weg dort, wo sich ein Sonderfall zur Regelmenge entwickelt hat: Was jeden Monat hundertfach gleichartig vorkommt, gehört mittelfristig ins führende System.

Option 2: Eine zweite Rechnungssoftware für die Restmenge

Sevdesk, Lexware und ähnliche Tools erzeugen konforme E-Rechnungen. Für die Konzern-Restmenge haben sie drei strukturelle Probleme. Erstens die Flexibilität: Die Word-Fälle sind gerade die, die sich schlecht in Formulare mit Artikelstamm und Preislogik pressen lassen; eine zweite Software erbt das Problem der ersten. Zweitens der Betrieb: doppelte Stammdatenpflege, eigene Nummernkreise neben den SAP-Nummernkreisen, Schulung für jede beteiligte Fachabteilung, ein zusätzliches System in der IT-Governance. Drittens die Zielgruppe: Diese Werkzeuge sind für kleine Betriebe gebaut, Mandantenstrukturen über mehrere Gesellschaften und Freigabeprozesse sind nicht ihr Anwendungsfall.

Für einzelne, klar abgegrenzte Bereiche kann das trotzdem passen. Als Antwort auf eine heterogene Restmenge quer durchs Haus eher nicht.

Option 3: Den Word-Prozess behalten und eine Konvertierungs-Schicht dahintersetzen

Der dritte Weg lässt die Rechnungserstellung, wie sie ist, und setzt dahinter eine Schicht, die aus der fertigen PDF eine E-Rechnung macht. Die Fachabteilung schreibt ihre Rechnung weiter in Word oder Excel und verschickt sie per Mail, wie bisher. Die Schicht dazwischen extrahiert die Rechnungsdaten, validiert sie gegen EN 16931, erzeugt eine ZUGFeRD-Datei (oder eine XRechnung, wo der Empfänger sie verlangt), stellt sie dem Empfänger zu und archiviert sie revisionssicher.

Die ehrlichen Nachteile: Die Rechnung selbst entsteht weiterhin manuell, dieser Weg automatisiert die Konformität, nicht die Erstellung. Und eine Extraktion aus PDF braucht eine Validierungs- und Kontrollstrecke, blindes Vertrauen wäre fahrlässig; deshalb gehört zwingend eine EN-16931-Validierung jeder einzelnen Rechnung dazu. Dafür bleibt SAP unberührt, kein Change Request, kein Regressionstest, und die Einführung dauert Tage statt Quartale.

Wir bauen mit Belegschmied selbst eine solche Schicht, neutral sind wir in diesem Vergleich also nicht. Die Abwägung selbst gilt aber unabhängig davon, welches Werkzeug die Schicht stellt.

Wie die Konvertierungs-Schicht konkret arbeitet

Am Beispiel Belegschmied sieht der Ablauf so aus:

1. Eingang: Für die Einlieferung der PDFs gibt es mehrere Wege, je nach gewünschtem Automatisierungsgrad. Vollautomatisch: Die Rechnungen werden per REST-API übergeben, oder ein Power-Automate-Flow schickt sie ohne manuellen Schritt per Mail an Ihr Belegschmied-Postfach, etwa sobald eine PDF in einem bestimmten SharePoint-Ordner liegt (eine Flow-Vorlage dafür stellen wir bereit). Ohne IT-Beteiligung: Die Fachabteilung schickt die PDF direkt an das Postfach, setzt es beim Versand an den Kunden in CC oder lädt die Datei im Browser hoch.
2. Extraktion und Prüfung: Die Rechnungsdaten werden aus der PDF extrahiert und gegen EN 16931 validiert. Was nicht eindeutig oder nicht vollständig ist, wird nicht stillschweigend geraten, sondern zur Korrektur angehalten.
3. Format und Zustellung: Aus PDF und Daten entsteht eine ZUGFeRD-Rechnung (das Original-Layout bleibt sichtbar, die XML liegt eingebettet daneben) oder eine XRechnung für Behörden. Der Versand läuft im Enterprise-Tarif über Ihr Microsoft 365 oder Ihren eigenen SMTP-Server, die Rechnung kommt also aus Ihrer Domain, nicht aus einer fremden.
4. Archiv: Jede Rechnung wird 10 Jahre unveränderbar gespeichert, gesetzlich gefordert sind 8 (§ 147 AO, § 14b UStG). Wie die GoBD-konforme Archivierung im Detail aussieht, steht im verlinkten Artikel.

Mehrere Gesellschaften und Standorte laufen als getrennte Mandanten mit eigenen Stammdaten. Der Enterprise-Tarif deckt bis zu 15.000 Rechnungen pro Monat ab und kostet 199 € pro Monat; für Anbindungen an ein Dokumentenmanagement- oder Archivsystem gibt es die REST-API, individuelle Integrationen setzen wir auf Projektbasis um.

Was Ihre Word- und Excel-Vorlagen liefern müssen

Egal welche Option Sie wählen: Die Rechnung muss inhaltlich vollständig sein, sonst scheitert jede Konvertierung. Die häufigsten Lücken in gewachsenen Vorlagen sind fehlende Leistungszeiträume, USt-IdNrn. mit Leerzeichen, Skonto nur als Freitext und Summen, die durch Excel-Rundung nicht konsistent sind. Eine ausführliche Liste dieser Stolpersteine steht im Artikel zu den EN-16931-Fallstricken.

Der schnellste Realitätscheck: Nehmen Sie eine typische Rechnung aus Ihrer Restmenge und prüfen Sie sie mit unserem kostenlosen Validator. Das Ergebnis zeigt in Sekunden, ob Ihre Vorlagen konvertierbar sind oder erst nachgebessert werden müssen.

Häufige Fragen

Müssen wir dafür SAP DRC einführen?

Nein. DRC (Document and Reporting Compliance) erzeugt und übermittelt E-Rechnungen für Belege, die in SAP fakturiert werden. Für Rechnungen, die SAP nicht abbilden kann, hilft es nicht, denn der fehlende Schritt ist nicht das Format, sondern die Fakturierung selbst. Beide Welten schließen sich nicht aus: SAP-Rechnungen über DRC oder ein Add-on, die Restmenge über eine vorgelagerte Schicht.

Gilt für uns 2027 oder 2028?

Maßgeblich ist der Gesamtumsatz des Vorjahres: über 800.000 Euro bedeutet Pflicht ab dem 1. Januar 2027. Die 800.000 Euro beziehen sich auf den gesamten Umsatz, nicht nur auf das inländische B2B-Geschäft. Für Konzerne und Unternehmensgruppen ist 2027 damit der realistische Stichtag.

Reicht es, wenn die Empfänger die PDF weiter akzeptieren?

Nach dem Stichtag nicht mehr. Die Pflicht zur Ausstellung einer E-Rechnung besteht unabhängig davon, ob der Empfänger sich beschwert. Dazu kommt das praktische Risiko auf Empfängerseite: Der Vorsteuerabzug setzt grundsätzlich eine ordnungsgemäße Rechnung voraus, und professionelle Kreditorenbuchhaltungen weisen nicht konforme Rechnungen zunehmend automatisch zurück. Wer PDF schickt, produziert Klärfälle beim Kunden.

Was ist mit unseren Dauerrechnungen?

Dauerrechnungen, die vor dem Stichtag als PDF oder Papier gestellt wurden, bleiben gültig, solange sich die Rechnungsangaben nicht ändern. Bei der ersten Änderung (Preisanpassung, geänderter Leistungsumfang) muss eine E-Rechnung ausgestellt werden. Für Verträge mit regelmäßigen Anpassungen ist die Sonderregel damit nur ein Aufschub.

Ein Teil unserer Rechnungen geht an Behörden. Ändert das etwas?

Ja, für öffentliche Auftraggeber gilt die E-Rechnungspflicht schon länger, und dort ist meist eine XRechnung mit Leitweg-ID gefordert statt ZUGFeRD. Eine Konvertierungs-Schicht sollte beide Formate beherrschen und pro Empfänger das richtige wählen.

Fazit

Die Rechnungen, die SAP nicht abbildet, verschwinden nicht durch die E-Rechnungspflicht, sie brauchen nur einen konformen Weg nach draußen. Sie in SAP nachzubauen ist für echte Sonderfälle unwirtschaftlich, eine zweite Rechnungssoftware verlagert das Problem. Der pragmatische Weg lässt Word und Excel in der Fachabteilung und macht die Konformität zu einem nachgelagerten, automatisierten Schritt: konvertieren, validieren, zustellen, archivieren.

Genau dafür haben wir Belegschmied gebaut. Wenn Sie den Weg mit Ihren eigenen Rechnungen prüfen wollen: 30 Tage kostenlos testen, ohne Eingriff in Ihre Systemlandschaft.