Braucht die Anbindung ein Projekt im SAP-System?

Nein. Belegschmied setzt hinter dem Punkt an, an dem die Rechnung als fertige PDF vorliegt. Es gibt keinen Eingriff in SAP, kein Add-on, keinen Transport und keine Änderung am Rechnungsdruck. Angebunden wird nur der Weg, auf dem die fertige PDF zu uns kommt.

Ersetzt das SAP Document and Reporting Compliance (DRC)?

Nein, es ergänzt es. DRC bearbeitet die Rechnungen, die SAP selbst erzeugt. Belegschmied bearbeitet die Restmenge, die außerhalb von SAP entsteht und deshalb nie in DRC ankommt. Wer beides hat, deckt zusammen den vollen Rechnungsausgang ab.

Was passiert bei Rechnungen an öffentliche Auftraggeber?

Die brauchen eine Leitweg-ID (BT-10). Steht sie auf der PDF, wird sie übernommen. Steht sie nicht darauf, kann Belegschmied sie nicht erfinden: die Rechnung wird als XRechnung abgelehnt, weil BR-DE-15 die Angabe erzwingt. Die Leitweg-ID gehört deshalb in die Vorlage der erzeugenden Anwendung.

SAP und E-Rechnung: Rechnungen außerhalb von SAP anbinden

Q: Wie verhindern Sie, dass eine Rechnung doppelt als E-Rechnung rausgeht?

Die Rechnungsnummer ist pro Arbeitsbereich eindeutig. Wird dieselbe Nummer ein zweites Mal eingeliefert, bricht die Verarbeitung mit DUPLICATE_INVOICE_NUMBER ab und der Einlieferer bekommt eine Fehlermail. Ein wiederholter API-Aufruf mit derselben Rechnung erzeugt also keine zweite E-Rechnung.

Kurze Antwort: Sie binden nichts in SAP ein. Belegschmied setzt hinter der fertigen PDF an, nimmt sie über die REST-API, einen beobachteten Ordner oder per Mail entgegen, erzeugt daraus eine geprüfte E-Rechnung nach EN 16931 und versendet sie über Ihre eigene Infrastruktur. SAP bleibt unberührt, die Fachabteilung behält ihren Ablauf, und die Restmenge wird trotzdem pflichtkonform.

Dieser Guide beschreibt den Fall, der in SAP-Häusern regelmäßig übrig bleibt: SAP ist das führende System für den Großteil der Rechnungen, aber ein Teil des Rechnungsausgangs entsteht daneben. In Word, in Excel, in einer Fachanwendung, in einem Branchentool. Diese Restmenge nennen wir Schattenrechnungen. Sie ist kein Organisationsversagen, sondern das, was jedes ERP produziert, sobald ein Geschäftsvorfall nicht in seine Stammdaten passt.

Warum SAP diese Rechnungen nicht abbildet

Die Gründe wiederholen sich, unabhängig von Branche und Release:

Der Vorfall hat keinen Stammsatz. Weiterberechnungen, einmalige Umlagen, Schadensfälle, Aufwandserstattungen. Für einen einzigen Vorgang legt niemand ein Material und einen Debitor an.
Die Preisfindung passt nicht. Der Betrag entsteht aus einer Nebenrechnung, einer Abstimmung oder einer Vereinbarung, die nicht in Konditionssätzen abbildbar ist.
Der Prozess läuft in einer anderen Abteilung. Die Rechnung entsteht dort, wo das Wissen liegt, nicht dort, wo SAP ausgerollt ist.
Das Customizing wäre teurer als die Ausnahme. Ein Vorgang mit dreißig Belegen im Jahr rechtfertigt kein Projekt.

Keiner dieser Gründe verschwindet durch die E-Rechnungspflicht. Was sich ändert, ist die Konsequenz: ab 2027 beziehungsweise 2028 muss auch diese Restmenge als strukturierte E-Rechnung rausgehen. Die ausführliche Herleitung steht im Artikel Rechnungen, die SAP nicht abbildet.

Wo Belegschmied im Verhältnis zu SAP DRC steht

SAP Document and Reporting Compliance ist die Lösung für die Rechnungen, die SAP selbst erzeugt. Sie greift auf die Belegdaten im System zu und erzeugt daraus das strukturierte Format. Das funktioniert gut und ist der richtige Weg für alles, was in SAP entsteht.

Die Restmenge erreicht DRC nie, weil sie nie einen SAP-Beleg hatte. Für sie gibt es drei Optionen:

Option	Aufwand	Was sie löst	Was offen bleibt
Vorgänge in SAP nachbilden	Projekt, Monate	Vollständige Abbildung im führenden System	Kosten pro Ausnahme, neue Ausnahmen entstehen weiter
Zweite Rechnungssoftware einführen	Mittel	Strukturierte Erfassung	Die Fachabteilung muss ihren Ablauf ändern, doppelte Nummernkreise
Vorgelagerte Konvertierungs-Schicht	Klein	Pflichtkonformität ohne Prozessänderung	Die Rechnung muss als PDF vollständig sein

Belegschmied ist die dritte Option. Der Preis dafür steht offen in der Tabelle: was nicht auf dem Dokument steht, kann nicht ins XML. Wir defaulten keine Inhalte. Welche Felder das betrifft, steht im Feldabgleich für Word- und Excel-Vorlagen.

Welcher Einlieferungsweg passt?

Vier Wege, geordnet nach Automatisierungsgrad. Sie schließen sich nicht aus, viele Häuser fangen unten an und arbeiten sich hoch.

1. REST-API

Der Weg für alles, was programmatisch angestoßen werden kann: ein Job auf dem Fileshare, ein Skript hinter dem Rechnungsdruck der Fachanwendung, ein Middleware-Schritt. Ein Aufruf je Rechnung.

curl -X POST https://belegschmied.de/api/v1/invoices/outbound \
  -H "Authorization: Bearer bs_live_dein_key" \
  -F "pdf=@RE-2026-104721.pdf" \
  -F "recipient_email=kreditoren@kunde.de"

Die Antwort kommt sofort mit 202 Accepted, die Verarbeitung läuft asynchron:

{
  "conversion_id": "3f6a2e10-8c41-4d7a-9b02-5e1f7a03cc19",
  "status": "accepted",
  "status_url": "/api/v1/conversions/3f6a2e10-8c41-4d7a-9b02-5e1f7a03cc19"
}

Den Endstand holen Sie über die conversion_id:

curl https://belegschmied.de/api/v1/conversions/3f6a2e10-8c41-4d7a-9b02-5e1f7a03cc19 \
  -H "Authorization: Bearer bs_live_dein_key"

{
  "id": "3f6a2e10-8c41-4d7a-9b02-5e1f7a03cc19",
  "type": "outbound",
  "status": "processed",
  "error_code": null,
  "error_message": null,
  "received_at": "2026-08-31T09:14:02.000Z",
  "processed_at": "2026-08-31T09:14:41.000Z",
  "invoice": {
    "id": "9c01b7aa-2f65-4a10-8d33-71b0e4c9a882",
    "invoice_number": "RE-2026-104721",
    "invoice_date": "2026-08-31",
    "currency": "EUR",
    "status": "sent",
    "total_net": 1200.00,
    "total_vat": 228.00,
    "total_gross": 1428.00,
    "recipient_emails": ["kreditoren@kunde.de"],
    "confidence_score": 0.97,
    "validation_valid": true
  }
}

Vollständige Endpunktliste, Fehlercodes, Rate-Limits und die Abrufe für XML, PDF und Validierungsbericht stehen in der REST-API-Dokumentation. Die API ist ab dem Business-Tarif enthalten, den Schlüssel erzeugen Sie selbst unter Einstellungen → REST-API.

2. Power-Automate-Flow auf einen beobachteten Ordner

Der Weg ohne Entwicklung, wenn Microsoft 365 ohnehin im Haus ist: Ein Flow beobachtet einen SharePoint- oder OneDrive-Ordner, in dem die Fachabteilung ihre fertigen Rechnungen ohnehin ablegt, und liefert jede neue Datei ein. Für die Fachabteilung ändert sich nichts. Die Schritte im Detail stehen im Microsoft-365-Guide.

3. Mail an die Versandadresse oder CC

Jeder Arbeitsbereich hat eine eigene Adresse unter in.belegschmied.de. Was dort ankommt, wird verarbeitet. Das ist der Weg für jede Anwendung, die eine Rechnung per Mail verschicken kann, und für Abteilungen ohne IT-Beteiligung. Beim CC-Weg geht die Rechnung wie bisher an den Kunden und wir bekommen sie mit.

4. Upload im Browser

Für Einzelfälle, für den Anfang und für alles, was den automatischen Weg noch nicht kennt.

Was bei hohem Volumen tatsächlich zählt

Bei zweitausend Belegen im Monat sind nicht die glatten Fälle das Thema, sondern die Ausnahmen. Vier Mechanismen entscheiden, ob der Betrieb ruhig läuft.

Doppelte Rechnungsnummern werden hart abgelehnt

Die Rechnungsnummer ist pro Arbeitsbereich eindeutig. Kommt dieselbe Nummer ein zweites Mal, bricht die Verarbeitung mit DUPLICATE_INVOICE_NUMBER ab und der Einlieferer bekommt eine Fehlermail. Das ist beabsichtigt: eine doppelt versendete Rechnung ist ein § 14c-Risiko, kein Komfortproblem.

Praktisch heißt das: ein wiederholter API-Aufruf mit derselben Rechnung erzeugt keine zweite E-Rechnung. Ein Retry nach Timeout ist damit ungefährlich. Wer aus SAP heraus einen Nummernkreis wiederverwendet, merkt es hier sofort statt beim Kunden.

Die Rechnungsnummer muss im PDF-Text stehen

Vor der Erzeugung prüft Belegschmied deterministisch, ob die extrahierte Rechnungsnummer wortwörtlich im Text der PDF vorkommt. Findet sie sich nicht, blockiert der Check mit INVOICE_NUMBER_NOT_IN_PDF. Das schützt gegen zwei Dinge gleichzeitig: gegen eine falsch gelesene Nummer und gegen PDFs ohne Textschicht, etwa eingescannte Ausdrucke.

Wenn Ihre Fachanwendung PDFs als reines Bild erzeugt, ist das der Punkt, an dem es auffällt. Der Test ist einfach: PDF öffnen, Rechnungsnummer mit der Maus markieren. Geht das nicht, gibt es keine Textschicht.

Die Arithmetik wird nachgerechnet, nicht geglaubt

Drei Prüfungen laufen unabhängig von der Extraktion, mit einer Toleranz von einem Cent:

Summe der Positionen gegen das Gesamt-Netto (ARITHMETIC_LINE_ITEMS_MISMATCH)
Je Steuersatz: Netto × Satz gegen die ausgewiesene Steuer (ARITHMETIC_PER_RATE_MISMATCH)
Netto + Steuer gegen Brutto (ARITHMETIC_TOTALS_MISMATCH)

Die Positionssummen im XML werden dabei immer neu gerechnet (Menge × Einzelpreis, abzüglich Positionsrabatt), nie aus dem Dokument übernommen. Grund: die Erzeugung rechnet ebenfalls so, und eine Abweichung zwischen Anzeige und XML wäre der schlimmere Fehler.

Unsichere Extraktionen gehen in die Freigabe statt raus

Jede Verarbeitung bekommt einen Confidence-Wert. Fehlende Pflichtfelder und Rechenabweichungen ziehen ihn pro Befund um 0,15 nach unten. Liegt er unter dem Schwellwert des Arbeitsbereichs (Standard 0,85), landet die Rechnung im Status pending_approval und geht erst nach Bestätigung raus.

Für den vollautomatischen Betrieb lässt sich die generelle Freigabepflicht abschalten; der Confidence-Schwellwert bleibt als Netz darunter. Die Empfehlung für die ersten Wochen ist umgekehrt: Freigabe an, Fehlerbilder sammeln, Vorlagen korrigieren, dann automatisieren.

Fehlerbilder und was dahintersteckt

Die Codes stammen aus der Selbstprüfung der Extraktion und den deterministischen Checks. Sie stehen im Protokoll und in der Fehlermail an den Einlieferer.

Code	Bedeutung	Ursache in der Praxis	Was hilft
`MISSING_SUPPLIER_TAX_ID`	Weder USt-IdNr. noch Steuernummer gefunden	Die Vorlage der Fachanwendung trägt sie nur im Fußzeilen-Bild, nicht als Text	Beide Angaben als Text in die Vorlage; alternativ als Stammdatum im Arbeitsbereich hinterlegen, dann überlagert es die Extraktion
`INVALID_SUPPLIER_VAT_ID`	USt-IdNr. entspricht nicht dem Muster Ländercode + 8 Zeichen	Leerzeichen oder Bindestriche in der Nummer, oder es wurde die Steuernummer ins Feld gesetzt	Schreibweise `DE123456789` ohne Trenner
`NO_LINE_ITEMS`	Keine Positionen erkannt	Rechnung besteht aus einem Fließtext-Absatz statt einer Positionstabelle	Mindestens eine Zeile mit Bezeichnung, Menge, Einzelpreis und Steuersatz
`NET_TOTAL_MISMATCH`	Positionssumme ≠ ausgewiesenes Netto	Rabatt steht als Text neben der Summe statt als Position oder Nachlass	Rabatte als eigene Zeile oder als ausgewiesenen Nachlass darstellen
`VAT_BREAKDOWN_MISMATCH`	Steueraufstellung summiert sich nicht auf die Gesamtsteuer	Gemischte Steuersätze, Rundung je Position statt je Steuergruppe	Steuergruppen sauber ausweisen
`PREPAID_MISMATCH`	Abschlag und Zahlbetrag widersprechen sich	Schlussrechnung, bei der die verrechneten Abschläge nicht zum Restbetrag passen	Bereits gezahlte Abschläge und Zahlbetrag beide ausweisen
`DUPLICATE_INVOICE_NUMBER`	Nummer existiert im Arbeitsbereich schon	Wiederholte Einlieferung oder wiederverwendeter Nummernkreis	Prüfen, ob die erste Verarbeitung erfolgreich war, bevor neu eingeliefert wird
`INVOICE_NUMBER_NOT_IN_PDF`	Nummer nicht im Dokumenttext auffindbar	PDF ohne Textschicht, etwa aus einem Scan	Digital erzeugte PDF liefern statt eines Ausdrucks

Kommt stattdessen ein Validierungsfehler mit einem Regelcode wie BR-DE-15 oder BR-S-02 zurück, ist die Erzeugung gelaufen und die Prüfung gegen EN 16931 hat abgelehnt. Jede Regel hat eine eigene Seite im Fehler-Lexikon.

Der Feldabgleich

Welche Angabe auf der PDF in welchem Feld der E-Rechnung landet, steht vollständig im Feldabgleich für Word- und Excel-Vorlagen. Er gilt unverändert für Rechnungen aus SAP-Nachbarsystemen, weil er am Dokument ansetzt und nicht am erzeugenden System.

Drei Felder verdienen im SAP-Umfeld besondere Aufmerksamkeit, weil sie in Nachbarsystemen typischerweise fehlen:

Leitweg-ID (BT-10) bei Rechnungen an öffentliche Auftraggeber. Ohne sie lehnt BR-DE-15 die XRechnung ab. Sie muss auf dem Dokument stehen.
Leistungsdatum oder Leistungszeitraum (BT-72 beziehungsweise BT-73/74). EN 16931 verlangt eines von beiden. Ein Rechnungsdatum allein reicht nicht.
Befreiungsgrund bei 0-Prozent-Positionen (BT-120). Ohne ihn werden steuerfreie Positionen als regulär besteuert eingestuft, was BR-S-02 und BR-S-05 auslöst. Reverse Charge, innergemeinschaftliche Lieferung und Kleinunternehmerregelung brauchen also den Text auf der Rechnung.

Was wir nicht behaupten

Es gibt keinen fertigen SAP-Konnektor von uns, kein Add-on und kein zertifiziertes Zusatzpaket. Der Zugriff auf ein SAP-System, eine Anbindung an ein Dokumentenmanagement oder ein Archivsystem sind Projektarbeit und werden als solche vereinbart, nicht als Produktversprechen. Für den beschriebenen Fall ist das auch nicht nötig: Die Restmenge entsteht per Definition außerhalb von SAP, und genau dort setzt der Weg an.

Nächster Schritt

Der belastbarste Test dauert zehn Minuten: Nehmen Sie eine echte Rechnung aus der Restmenge und schicken Sie sie durch PDF zu ZUGFeRD. Das Werkzeug extrahiert, erzeugt und validiert, ohne Konto. Was dabei durchläuft, läuft auch im Betrieb durch; was hängen bleibt, zeigt genau die Vorlagenlücke, die Sie sonst erst bei der ersten echten Ablehnung sehen.

Achtung: Der Validator ist dafür das falsche Werkzeug. Er prüft eine bereits strukturierte Datei gegen EN 16931 und findet in einer gewöhnlichen Word-PDF kein Profil. Die Frage „lässt sich diese Vorlage konvertieren?" beantwortet nur der Weg über die Erzeugung.

SAP anbinden: die Rechnungen, die SAP nicht abbildet