E-Rechnung aus SAP: das Feld-Mapping auf die finisma-API

1. Kein Add-on, eine Schnittstelle

Die Versuchung im SAP-Umfeld ist, jede neue Anforderung im System selbst zu lösen. Für die E-Rechnung ist das der teurere Weg. Ein Add-on bedeutet einen Namensraum, einen Transport durch drei Systeme, Wartungsfenster und eine Abhängigkeit, die bei jedem Support-Package wieder auf den Tisch kommt. Die Norm ändert sich derweil unabhängig von Ihrem Release-Stand: EN 16931 bekommt Errata, die KoSIT-Prüfregeln der XRechnung werden zweimal im Jahr aktualisiert.

finisma bleibt außerhalb. Was Sie brauchen, sind zwei Dinge, die Ihr System schon kann: Rechnungsdaten aus einer Faktura ziehen und einen HTTP-Request absetzen. Der Request geht an POST /api/v1/invoices, mit der Rechnungs-PDF und den strukturierten Daten als JSON. Zurück kommt die geprüfte ZUGFeRD-Rechnung. Kein Objekt wandert ins SAP-System, kein Server steht beim Kunden.

2. Wo die Rechnung in SAP entsteht

Bevor Sie ein einziges Feld abbilden, klären Sie die Quelle. In SAP liegt „die Rechnung“ an drei Stellen, und sie tragen unterschiedliche Daten:

• SD-Faktura (VBRK/VBRP). Der Regelfall für die Ausgangsrechnung. VBRK trägt den Kopf (Nummer, Datum, Währung, Partner, Vorgangsart), VBRP die Positionen (Material, Menge, Einheit, Nettowert). Hier holen Sie den Großteil des Mappings.
• FI-Buchhaltungsbeleg (BKPF/BSEG). Nur nötig, wenn die Rechnung rein in FI entsteht, etwa bei Rechnungen ohne SD-Prozess. Für den steuerlichen Aufriss ist ergänzend die Tabelle BSET gut, weil dort Steuerbasis und Steuerbetrag je Satz sauber getrennt stehen.
• Bestellung des Kunden (VBKD). Die Bestellnummer, die Ihr Kunde erwartet, steht in VBKD-BSTKD und gehört in ein eigenes Feld der E-Rechnung. Sie ist nicht die Leitweg-ID, dazu mehr in Abschnitt 4.

Für den häufigsten Fall, die Ausgangsrechnung aus dem Vertrieb, reicht die Kombination aus VBRK, VBRP und VBKD plus den Adress- und Bankstammdaten. Die folgende Tabelle geht von dieser Quelle aus.

3. Das Feld-Mapping: SAP → BT-Nummer → finisma-JSON

Die Norm nummeriert jedes Rechnungselement als „Business Term“ (BT). Das finisma-JSON benennt dieselben Elemente sprechend. Wenn Sie Ihr Mapping einmal gegen diese Tabelle sauber gezogen haben, sind Sie durch. Die BT-Nummer ist die Brücke: sie steht in jeder EN-16931-Dokumentation und macht das Mapping überprüfbar.

Zwei Dinge sind nicht in der Tabelle, weil sie in SAP oft anders heißen als man denkt. Erstens: Die Adresse ist eine line1, kein getrenntes Straßen- und Hausnummernfeld. Ziehen Sie Straße und Hausnummer aus ADRC zusammen. Zweitens: Es gibt kein Feld für die Steuernummer, nur vatId. Wer in SAP mit STCD1 statt STCEG arbeitet, hat für die B2B-E-Rechnung die falsche Kennung gezogen. Beide Punkte kosten im ersten Testlauf Zeit, deshalb stehen sie in Abschnitt 6 noch einmal ausführlich.

4. Leitweg-ID: der Wert, den SAP selten sauber liefert

Die Leitweg-ID gehört in buyerReference (BT-10) und ist bei Rechnungen an öffentliche Auftraggeber Pflicht. Ohne sie lehnt das Empfangsportal die Rechnung ab. Das Problem: SAP hat kein Standardfeld dafür. In der Praxis liegt der Wert an einer von zwei Stellen.

• als Geschäftspartner-Identifikation in BUT0ID, unter einem eigenen Identifikationstyp, den viele Häuser DE:LWID nennen, oder
• im Adress-Zusatz über ADR11 (SSFID), wenn die Kennung am Rechnungsempfänger hängt.

Welche Stelle bei Ihnen gefüllt ist, hängt davon ab, wie die Stammdatenpflege den Wert einträgt. Legen Sie das früh fest, sonst schreibt Ihr Mapping mal die eine, mal die andere Quelle, und die Rechnungen an die Behörde fallen sporadisch durch. Was die Leitweg-ID im Detail ist und wie ihre Prüfziffer aufgebaut ist, steht im Artikel Leitweg-ID in der E-Rechnung. Verwechseln Sie sie nicht mit der Bestellnummer des Kunden: die geht als purchaseOrderReference nach BT-13 und stammt aus VBKD-BSTKD.

5. Gutschrift: der Typ trägt die Richtung

Der häufigste Denkfehler beim Mapping: eine Gutschrift mit negativen Beträgen zu schicken. Die Norm arbeitet anders. Die Richtung einer Rechnung steckt im Dokumenttyp, die Beträge bleiben immer positiv. finisma lehnt negative Summen ausdrücklich ab und meldet AMOUNT_NEGATIVE.

In SAP erkennen Sie den Fall an der Vorgangsart VBRK-VBTYP. Der Wert M steht für die Rechnung, O für die Gutschrift. Übersetzen Sie das in documentTypeCode:

Bei einer Gutschrift gehört zusätzlich der Bezug auf die Ursprungsrechnung dazu: precedingInvoiceNumber und precedingInvoiceDate. Wie der Dokumenttyp die Beträge steuert und warum das Minuszeichen in die Irre führt, vertieft der Artikel Gutschrift als E-Rechnung erstellen.

6. Drei Fallstricke, die jeden ersten Testlauf kosten

Diese drei tauchen bei fast jeder SAP-Anbindung auf. Wer sie vorher kennt, spart sich die erste Ablehnungsrunde.

USt-IdNr statt Steuernummer

SAP führt beide getrennt: die USt-IdNr in STCEG, die Steuernummer in STCD1 bis STCD5. Das finisma-Schema kennt nur vatId (BT-31 für den Verkäufer, BT-48 für den Käufer), kein Feld für die Steuernummer. Mappen Sie also STCEG. Zieht Ihr Programm versehentlich STCD1, steht in der Rechnung die falsche Kennung, und im Reverse-Charge-Fall nach § 13b fehlt die Pflicht-USt-IdNr des Empfängers ganz. Der Sonderfall ist im Artikel Reverse Charge in der E-Rechnung beschrieben.

Mengeneinheiten übersetzen

BT-130 (unitCode) erwartet einen Code nach UN/ECE Rec 20. SAP liefert in VBRP-VRKME die interne oder ISO-Einheit, und die stimmt nur selten überein. ST wird zu C62 (Stück), STD zu HUR (Stunde), M2 zu MTK. finisma kennt die gängigen Aliase und setzt fehlende Angaben auf C62; die vollständige Liste plus die akzeptierten Aliase liefert GET /api/v1/codelists/units. Prüfen Sie Ihre real verwendeten Einheiten einmal dagegen, dann ist der Punkt erledigt. Welche Codes trotz naheliegender Schreibweise abgelehnt werden, zeigt der Artikel Mengeneinheiten in der E-Rechnung.

Skonto strukturiert, nicht als Fließtext

In SAP steckt der Zahlungsrabatt in der Zahlungsbedingung (ZTERM, Tabelle T052) als Prozentsatz und Tagefrist. Bilden Sie ihn strukturiert ab, über payment.discountPercent und payment.discountDays. Nur dann kann das Empfängersystem den Skonto automatisch ziehen. Der reine Bedingungstext gehört zusätzlich in payment.terms, ersetzt die beiden Felder aber nicht. Warum viele Umwandlungen den Rabatt verlieren, steht im Artikel Skonto in der E-Rechnung.

7. Der Aufruf gegen /api/v1/invoices

Der Endpunkt nimmt multipart/form-data entgegen: den Teil pdf (die visuelle Rechnung) und den Teil invoice (die abgebildeten Daten als JSON). Authentifiziert wird per Bearer-Token. So sieht ein Aufruf aus, mit dem JSON auf das Wesentliche gekürzt:

curl -X POST https://finisma.de/api/v1/invoices \
  -H "Authorization: Bearer fnsm_IHR_KEY" \
  -F "pdf=@rechnung.pdf;type=application/pdf" \
  -F 'invoice={
    "invoiceNumber": "0090001234",
    "documentTypeCode": "380",
    "issueDate": "2026-09-01",
    "currency": "EUR",
    "buyerReference": "04011000-1234512345-06",
    "purchaseOrderReference": "4500012345",
    "seller": {
      "name": "Muster GmbH",
      "vatId": "DE123456789",
      "address": { "line1": "Werkstr. 1", "postalCode": "20095",
                   "city": "Hamburg", "countryCode": "DE" }
    },
    "buyer": {
      "name": "Kunde AG",
      "address": { "line1": "Marktplatz 5", "postalCode": "10115",
                   "city": "Berlin", "countryCode": "DE" }
    },
    "lines": [
      { "name": "Beratung", "quantity": 10, "unitCode": "HUR",
        "unitPriceNet": 100, "vatRatePercent": 19, "lineNetAmount": 1000 }
    ],
    "vatBreakdown": [
      { "ratePercent": 19, "basisAmount": 1000, "taxAmount": 190,
        "categoryCode": "S" }
    ],
    "totalNet": 1000, "totalVat": 190, "totalGross": 1190
  };type=application/json'

Zurück kommt die ZUGFeRD-PDF binär im Body. Wer die Bytes in ABAP oder in der Middleware weiterverarbeitet, setzt Accept: application/json und bekommt { pdf_base64, bytes }. Braucht der Empfänger reine XRechnung ohne PDF, hängen Sie ?format=xml an und erhalten das CII-XML. Passen die Daten nicht zur Norm, etwa weil die Summen nicht aufgehen oder eine Pflichtangabe fehlt, antwortet die API mit strukturierten Fehlern samt Feldpfad statt mit einer Datei.

Die vollständige Referenz mit allen Feldern, Anhängen und Fehlercodes steht in der REST-API-Dokumentation. Wer lieber aus einem Workflow-Tool heraus fakturiert, findet den Weg über n8n beschrieben; die Anbindung als MCP-Server für KI-Agenten steht im Überblick zur E-Rechnung per API.

8. Die Schnittstelle fragt sich selbst ab

Ein Mapping altert. Codelisten wachsen, die Norm bekommt Errata. Damit Ihr Integrationscode nicht gegen fest verdrahtete Annahmen läuft, gibt die API über sich selbst Auskunft, maschinenlesbar:

Das JSON ist typisiert und mit OpenAPI beschrieben. Wer mag, generiert sich aus openapi.json einen typsicheren Client und muss die Felder aus der Tabelle oben nicht von Hand nachbauen. Die Codelisten-Endpunkte eignen sich gut, um Ihr Mapping in einem Test einmal automatisch gegen die aktuellen gültigen Werte zu prüfen, statt es bei jeder Normänderung nachzuziehen.

Alle vier Zugänge (REST, MCP, WebMCP, OAuth) mit Auth-Optionen und Feldern stehen in der Entwickler-Dokumentation. Den Grund, warum das Thema jeden im B2B betrifft, liefert der Überblick zur E-Rechnungspflicht ab 2027.

9. Häufige Fragen zur E-Rechnung aus SAP

Die wichtigsten Antworten kompakt, für alle, die schnell eine Einschätzung brauchen.

Quellen und weiterführende Informationen

• Forum elektronische Rechnung Deutschland (FeRD): ZUGFeRD-Spezifikation
• KoSIT / XRechnung: Standard und Prüftool
• EN 16931-1: Semantisches Datenmodell der elektronischen Rechnung (Business Terms)
• UN/ECE Recommendation 20: Codes für Maßeinheiten im Handel