SAP Finance Master Data Integration

Sap Finanzstammdaten Im Büro Infografikstil

Wie integrierte Stammdaten verlässliche Finanzprozesse und konsistente Abschlusszahlen ermöglichen 

Vom organisatorischen Rahmen über Sachkonto, Kostenstelle, Profit Center und Business Partner bis zum Finanzbeleg im Universal Journal. 

 

Kurzüberblick 

Kaum ein Finanzprozess beginnt ausschließlich im Finanzwesen. Eine Bestellung entsteht im Einkauf, ein Warenausgang in der Logistik, eine Kundenrechnung im Vertrieb, eine Projektbuchung im Projektsystem und eine Zahlung im Bankenumfeld. Dennoch müssen alle daraus resultierenden Geschäftsvorfälle vollständig und richtig im Hauptbuch, in der Kostenrechnung, im Management Reporting und gegebenenfalls in weiteren Rechnungslegungskontexten ankommen. 

Dafür benötigt SAP nicht nur korrekt gepflegte Sachkonten sondern zusätzlich auch Buchungskreise, Kostenrechnungskreise, Werke, Kostenstellen, Profit Center, PSP-Elemente, Business Partner, Materialien, Anlagen und Bankverbindungen. Diese bilden den organisatorischen Rahmen sowie die Kontierungs- und Steuerungsinformationen für die nachfolgenden Transaktionen ab. Dabei ist die Trennung zwischen Stammdaten und Customizing nicht immer eindeutig. 

Das Sachkonto bestimmt die finanzielle Klassifikation. Die Kostenstelle beschreibt den Kostenverantwortungsbereich, das Profit Center die Ergebnisverantwortung und das PSP-Element den Projektbezug. Material- und Werkseinstellungen beeinflussen Bewertung und automatische Kontenfindung. Der Business Partner verbindet Finance mit Kunden, Lieferanten, Einkauf, Vertrieb, Zahlungsverkehr und sogar das Werk. 

In SAP S/4HANA werden primäre Kosten beziehungsweise Erlöse und sekundäre Kosten über den Sachkontenstamm abgebildet. Im Universal Journal werden Finanz- und Controllinginformationen auf gemeinsamen Belegpositionen zusammengeführt. 

Kernbotschaft: Finance-Stammdaten sind keine isolierten Datensätze. Sie verbinden operative Prozesse mit Finanzbuchhaltung, Controlling und Reporting. 

Einführung: Warum eine Bestellung auch ein Finance-Thema ist 

Montagmorgen, 09:15 Uhr. Eine Filiale bestellt neue Laptops. Im Einkauf werden ein Lieferant, ein Material beziehungsweise eine Warengruppe, ein Werk und eine Kostenstelle angegeben. Für die finanzielle Verarbeitung werden Informationen aus mehreren Bereichen benötigt: 

  • Business Partner: Identifikation des Lieferanten, Zahlungsdaten und Steuerdaten. 
  • Kostenstelle: Kostenverantwortungsbereich. 
  • Profit Center: Ergebnisverantwortung. 
  • Sachkonto: Klassifikation von Aufwand, Bestand oder Anlagezugang. 
  • Werk und Material: logistischer Kontext, Bewertung und Kontenfindung. 
  • Bankverbindung: spätere Zahlungsabwicklung und Steuerdaten. 

Ein technisch vorhandener Stammsatz ist nicht automatisch fachlich verwendbar. Er muss im richtigen System, im passenden organisatorischen Kontext, im relevanten Zeitraum und mit den erforderlichen Zuordnungen verfügbar sein. 

1. Die Architektur integrierter Finance-Stammdaten 

Ein Finance-Architekturmodell beginnt nicht beim einzelnen Sachkonto. Es umfasst mehrere aufeinander aufbauende Ebenen: 

Referenzdaten  →  Organisationsstrukturen  →  Hierarchien und Gruppen  →  Stammdatenobjekte  →  Geschäftstransaktionen  →  Finanzbelege  →  Universal Journal  →  Bilanz, GuV und Management Reporting 

Referenzdaten 

  • Länder und Regionen 
  • Währungen und Wechselkurstypen 
  • Maßeinheiten und Sprachen 
  • Steuerkategorien 
  • Zahlungsbedingungen und Zahlwege 

Organisationsstrukturen 

  • Mandant 
  • Buchungskreis 
  • Controlling-Bereich beziehungsweise Kostenrechnungskreis 
  • Werk und Bewertungsbereich 
  • Einkaufs- und Verkaufsorganisation 
  • Kreditsegment 

Hierarchien und Gruppen 

Hierarchien und Gruppen können einzelne Stammdatenobjekte für organisatorische Steuerung, Planung, Verrechnung, Berechtigungen, Konsolidierung und Reporting gruppieren. Eine Hierarchie ist nicht mit einem einzelnen Stammsatz gleichzusetzen und bei Business Partnern im S/4 HANA vermehrt Beziehungen eingesetzt. 

Architekturprinzip: Referenzdaten und organisatorische Voraussetzungen müssen vorhanden sein, bevor Hierarchien und Stammdatenobjekte vollständig angelegt, migriert oder repliziert werden können. 

2. Stammdatenobjekt, Stammsatz und Hierarchie 

Begriff  Bedeutung 
Stammdatenobjekt  Fachliche Objektart, etwa Kostenstelle oder Profit Center 
Stammsatz  Konkrete Ausprägung, etwa Kostenstelle 4711 
Hierarchie  Struktur aus Knoten, Ebenen und zugeordneten Objekten 
Gruppe  Zusammenfassung mehrerer Objekte für Verarbeitung oder Auswertung 
Rolle  Fachliche Verwendung, etwa Kunden- oder Lieferantenrolle 
Organisationsstruktur  Kontext wie Buchungskreis, Werk oder Controlling-Bereich 
Referenzdaten  Wiederverwendete Werte wie Länder, Währungen und Einheiten 
Customizing  Systemeinstellungen zur Steuerung von Prozessen und Objektverhalten 

 

Eine Kostenstelle ist nicht ihre Kostenstellenhierarchie. Ein Profit Center ist nicht die Profit-Center-Standardhierarchie. Ein PSP-Element ist nicht der vollständige Projektstrukturplan. 

3. Buchungskreis als Fundament des externen Rechnungswesens 

Der Buchungskreis ist eine zentrale Organisationseinheit des externen Rechnungswesens. Auf seiner Ebene werden Geschäftsvorfälle einer rechtlich beziehungsweise rechnungslegungsbezogen abgrenzbaren Einheit erfasst und ausgewertet. 

  • Hauptbuchführung sowie Debitoren- und Kreditorenbuchhaltung 
  • Anlagenbuchhaltung und lokaler Abschluss 
  • Bilanz und Gewinn-und-Verlust-Rechnung 
  • Buchungskreiswährung und steuerliche Einstellungen 
  • Zahlungsverkehr sowie lokale Kontierungs- und Abschlussanforderungen 

Ein global vorhandenes Objekt ist nicht automatisch in jedem Buchungskreis buchbar. Zentrale und buchungskreisspezifische Daten müssen gemeinsam betrachtet werden. Wesentliche Stammdaten sind buchungskreisspezifisch auszuprägen. 

 

4. Kostenrechnungskreis als organisatorischer Rahmen 

Der Kostenrechnungskreis ist die organisatorische Einheit, innerhalb der eine vollständige Kostenrechnung durchgeführt werden kann. Ein Kostenrechnungskreis kann einem oder mehreren Buchungskreisen zugeordnet sein. Für eine 1: n-Zuordnung müssen insbesondere der operative Kontenplan und weitere organisatorische Voraussetzungen zueinander passen. Die wichtigste Einstellung im Kostenrechnungskreis ist die Währung, die bei einem zentralen Kostenrechnungskreis zur Konzernwährung wird. 

Ein oder mehrere Buchungskreise Kostenrechnungskreis → Kostenstellen, Innenaufträge, PSP-Elemente und weitere CO-Objekte 

5. Sachkonto, Kostenarten und Kontenstrukturen 

Der Sachkontenstamm legt fest, wie ein Geschäftsvorfall im Hauptbuch klassifiziert, gebucht und weiterverarbeitet wird. Er umfasst je nach Kontoart Informationen auf Kontenplan-, Buchungskreis- und gegebenenfalls Kostenrechnungskreisebene. 

  • Sachkontoart, Bilanz- oder Erfolgskonto und Kontengruppe 
  • Kontowährung, Steuerkategorie und Feldstatusgruppe 
  • Offene-Posten-Verwaltung und Abstimmkontenkennzeichen 
  • Funktionsbereich, Kostenartkategorie und automatische Buchungen 

Primäre Kosten (Erträge) und Erlöse haben ihren Ursprung grundsätzlich außerhalb der internen CO-Verrechnung. Sekundäre Kosten entstehen durch innerbetriebliche Wertflüsse wie Leistungsverrechnung, Umlage, Zuschlagsberechnung oder Abrechnung. 

In SAP S/4HANA werden sekundäre Kostenarten als Sachkonten des Typs Sekundärkosten geführt. Das Sachkonto ist das führende Objekt für die integrierten Kostenartinformationen. 

Kontenplan und Berichtsstruktur 

Der Kontenplan bildet den Ordnungsrahmen. Sachkontenhierarchien sowie Bilanz- und GuV-Strukturen gruppieren Konten für Reporting und Abschluss. Die reine Übertragung eines Sachkontos stellt noch keine identische Berichtszuordnung im Zielsystem sicher. 

6. Kostenstelle und Kostenstellenhierarchie 

Eine Kostenstelle repräsentiert einen organisatorischen Verantwortungsbereich, in dem Kosten geplant, gesammelt, überwacht und verrechnet werden. 

  • Kostenrechnungskreis und Buchungskreis 
  • Bezeichnung, verantwortliche Person und Gültigkeitszeitraum 
  • Kostenstellenart, Profit Center und Funktionsbereich 
  • Hierarchiebereich und Sperrkennzeichen 

Die Kostenstellenstandardhierarchie strukturiert die Kostenstellen innerhalb des Kostenrechnungskreis. Zusätzliche Gruppen können für Planung, Reporting, Verteilung, Umlage oder Selektion verwendet werden. 

Eine Kostenstelle kann technisch vorhanden und dennoch unvollständig integriert sein, wenn ihre Hierarchie- oder Gruppenzuordnung fehlt. 

7. Profit Center und Profit-Center-Hierarchie 

Ein Profit Center bildet einen managementorientierten Ergebnisverantwortungsbereich ab. Profit Center können beispielsweise nach Produktlinien, Regionen, Werken, Standorten oder Geschäftsbereichen aufgebaut werden und Kostenstellen, Materialien, Innenaufträgen, PSP-Elementen, Anlagen oder Aufträgen zugeordnet sein. 

Vom einzelnen Profit Center sind Profit-Center-Gruppen, Standardhierarchie, alternative Hierarchien sowie Knoten und Objektzuordnungen zu unterscheiden. 

Die Profit-Center-Hierarchie und die Profit Center bildet die grundsätzliche Reporting Struktur und ist im Kern nicht zu detailliert aber zukunftsweisend langfristig zu wählen. 

8. PSP-Element und Projektstrukturplan 

Ein PSP-Element ist ein einzelnes Strukturelement eines Projekts. Je nach Ausprägung kann es für Planung, Kontierung, Budgetierung, Beschaffung, Fakturierung und Abrechnung verwendet werden. 

  • Buchungskreis und Kostenrechnungskreis 
  • Profit Center und verantwortliche Kostenstelle 
  • Projektwährung, Objektklasse und Status 
  • Kontierungs-, Planungs- und Fakturierungseigenschaften 
  • Abrechnungsvorschrift 

Der Projektstrukturplan bildet das Projekt hierarchisch ab. Ein sichtbares PSP-Element ist nicht automatisch für Beschaffung, Zeitbuchung oder Finanzbuchung verwendbar. 

9. Ergänzende Controlling-Objekte 

  • Innenaufträge sammeln Kosten und gegebenenfalls Erlöse für abgegrenzte Maßnahmen (Innenaufträge werden durch PSP-Elemente abgelöst). 
  • Leistungsarten bilden intern erbrachte Leistungen und deren Verrechnung ab. 
  • Statistische Kennzahlen stellen nicht monetäre Größen für Planung, Verteilung und Umlage bereit. 

10. Business Partner, Kunden- und Lieferantenintegration 

In SAP S/4HANA ist der Business Partner das führende Objekt für Personen und Organisationen, mit denen Geschäftsbeziehungen bestehen. Einem Business Partner können mehrere Rollen gleichzeitig zugewiesen sein, wie beispielsweise die Kunden- und oder Lieferantenrolle. 

Kundenbezogene Daten 

  • Umsatzsteuer-Identifikationsnummer 
  • länderabhängige Steuerklassifikation 
  • Vertriebswegs spezifische Kundendaten 
  • Zahlungsbedingungen und Kontierungsgruppe 
  • Abstimmkonto und Zahlweg 

 

Lieferantenbezogene Daten 

  • allgemeine Business-Partner-Daten 
  • buchungskreisspezifische Finanzdaten 
  • Einkaufsorganisations- und Zahlungsdaten 
  • steuerliche Merkmale und Partnerfunktionen 
  • Rechnungsprüfungsmerkmale 

Partnerrolle Rechnungssteller 

Im betrachteten Prozess ist die Partnerrolle RS, Rechnungssteller, für die Eingangsrechnungsprüfung vorgesehen. Die tatsächlich erforderlichen Partnerrollen hängen jedoch vom Partnerfindungsverfahren und Prozessdesign ab. RS ist keine allgemeine Pflicht für jeden Lieferanten. 

Automatische Wareneingangsabrechnung 

Beim sogenannten ERS-Verfahren (Evaluated Receipt Settlement) erzeugt SAP eine eigene Abrechnung (Gutschrift) auf Grundlage der vereinnahmten Wareneingänge. Zur Abbildung dieses Prozesses im System müssen im Business Partner bestimmte Felder, wie beispielsweise die Automatische Wareneingangsabrechnung (ERS-Kennzeichen) und das Flag für die Wareneingangsbezogene Rechnungsprüfung, gesetzt sein, um den Prozess einzusetzen. Auch ein Retourenprozess kann über das ERS-Verfahren abgewickelt werden, dazu muss der Business Partner in der Rolle Lieferant als Retourenlieferant gekennzeichnet sein. Sobald ein Lieferant ein Retourenlieferant ist, ist auch die Ausprägung der Kundenrolle verpflichtend. 

11. Werk als Integrationsobjekt im Retail-Umfeld 

Das Werk ist eine zentrale Organisationseinheit in Materialwirtschaft, Produktion und Retail. Es kann eine Filiale, einen Produktionsstandort, einen logistischen Standort oder eine Zentrale repräsentieren. 

Werkszuordnung 

  • Buchungskreis und Bewertungsbereich 
  • Einkaufsorganisation und Materialstamm 
  • Bestandsführung und Profit-Center-Zuordnung 
  • Vertriebs- oder Retailspezifische Strukturen 

Werk, Bewertungsbereich, Buchungskreis, Material und Profit Center bilden ein zusammenhängendes Organisations- und Ableitungsmodell. 

12. Materialstamm, Bewertung und Finance-Integration 

Aus Sicht Finance sind im Materialstammsatz wichtige Felder für die Integration zu hinterlegen. 

Werksspezifische Materialdaten 

Im Materialstamm wird es in der Sicht Vertrieb: allg./Werk das Profit Center hinterlegt. Im Retail befindet es sich in den Logistikdaten des Materials. 

Vertriebssicht und Steuerklassifikation 

In der Sicht Vertrieb: VerkOrg1 wird die landesabhängige Steuerklassifikation hinterlegt. Wichtig zu beachten ist, dass die Steuerklassifikation länderabhängig und nicht verkaufsorganisationsabhängig gepflegt wird. 

Steuerinformationen im Einkauf 

In der Sicht Einkauf wird der Steuerindikator des Materials gesetzt. 

Buchhaltungssicht und Bewertung 

In der Sicht Buchhaltung 1 wird die Bewertungsklasse des Materials hinterlegt, die letztendlich mit über die Kontenfindung bestimmt. Des Weiteren wird in der Einkaufssicht ebenfalls bestimmt, ob ein Material zum gleitenden Durchschnittspreis bewertet werden soll oder nicht. SAP unterscheidet im Kern S für Standardpreis und V für gleitenden Durchschnittspreis. 

  • Bewertungsklasse 
  • Preissteuerung und Materialpreis 
  • Material-Ledger-Konfiguration 
  • Währungs- und Bewertungsansatz 

13. Vom Stammsatz zum Finanzbeleg 

Bestellung  →  Wareneingang  →  Rechnungseingang  →  FI-Beleg  →  Universal Journal  →  Bilanz, GuV und Management Reporting 

Stammdatenobjekt  Beitrag zum Geschäftsvorfall 
Business Partner  Lieferant, Zahlungs- und Buchungskreisdaten 
Material  Produkt, Bewertungsklasse und Preissteuerung 
Werk  logistischer Standort und Bewertungskontext 
Sachkonto  finanzielle Klassifikation 
Kostenstelle  Kostenverantwortungsbereich 
Profit Center  Ergebnisverantwortung 
PSP-Element  Projektbezug 
Bankverbindung  spätere Zahlungsabwicklung 

 

Ein Fehler bei der Buchung des FI-Belegs kann seinen Ursprung bereits in fehlerhaft gepflegten Stammdaten oder falschen Ableitungsregeln haben. 

SCREENSHOT 2: Vom Stammdatenobjekt über Kontierung und Ableitung zum Finanzbeleg, anschließend zum Universal Journal / ACDOCA und weiter zu Bilanz, GuV, Kostenrechnung und Reporting. 

14. Stammdaten im Universal Journal 

Das Universal Journal bildet in SAP S/4HANA die gemeinsame Belegbasis für Financial Accounting und Management Accounting. Externe und interne Geschäftsvorfälle werden auf Sachkonten abgebildet. Kontierungsdimensionen wie Kostenstelle, Profit Center, Projekt, Innenauftrag, Funktionsbereich, Segment und Material können abhängig vom Geschäftsvorfall in den Journalpositionen enthalten sein. 

Die zentrale Positionstabelle ist ACDOCA. Fehlerhafte Stammdaten und Ableitungen wirken sich direkt auf die gespeicherten Dimensionen und damit auf Bilanz, GuV, Kostenrechnung und Reporting aus. 

Stammdatenqualität ist keine Vorstufe des Reportings, sondern ist Bestandteil der Qualität jedes einzelnen Journalpostens. 

15. Stammdaten-Anlagenbuchhaltung und Bankstammdaten 

Anlagenbuchhaltung 

  • Anlagenklasse und Buchungskreis 
  • Kostenstelle und Profit Center 
  • Standort und Aktivierungsdatum 
  • Abschreibungsschlüssel und Nutzungsdauer 
  • Investitionsauftrag oder PSP-Element 

Bank, Hausbank und Bankkonto 

Der Bankstamm beschreibt das Kreditinstitut. Die Hausbank bildet die Beziehung eines Buchungskreises zur Bank ab. Das Hausbankkonto repräsentiert ein eigenes Konto. Der Bankkontenstamm enthält IBAN, Währung und weitere Informationen und stellt über das zugeordnete Hauptbuchkonto die Verbindung zur buchhalterischen Verarbeitung dar. 

16. Empfohlene Verantwortlichkeit der Finance-Stammdatenpflege 

Objekt  Typischer fachlicher Owner  Wichtige Beteiligte 
Sachkonto  Accounting  Controlling, Tax, Consolidation 
Buchungskreis  Finance Architecture / Accounting  Tax, Treasury, Controlling 
Kostenrechnungskreis  Controlling  Accounting, Finance Architecture 
Kostenstelle  Controlling  Fachbereich, HR 
Profit Center  Finance / Controlling  Reporting, Geschäftsbereiche 
PSP-Element  Project Controlling  Projektleitung, Einkauf 
BP-Kunde  Vertrieb / Customer Master Data  Accounting, Tax, Credit Management 
BP-Lieferant  Einkauf / Supplier Master Data  Accounting, Tax, Compliance 
Material  Supply Chain / Material Master Data  Einkauf, Finance, Controlling 
Werk  Supply Chain / Enterprise Structure  Finance, Einkauf, Retail 
Anlage  Asset Accounting  Controlling, Fachbereich 
Bankkonto  Treasury  Accounting, Zahlungsverkehr 

 

Ein Stammdatenobjekt kann mehrere Beteiligte haben, sollte aber einen eindeutig benannten Owner besitzen. 

17. Initialmigration mit dem SAP S/4HANA Migration Cockpit 

Das SAP S/4HANA Migration Cockpit unterstützt je nach Bereitstellungsmodell und Release Migrationsprojekte, bereitgestellte Migrationsobjekte, Direct Transfer oder Staging-Tabellen, Feld- und Wertemapping, Simulation, Fehleranalyse, Ausführung und Statusüberwachung. 

  • Migrationsumfang und Verantwortliche festlegen 
  • Quelldaten bereinigen und Dubletten identifizieren 
  • Mappingregeln definieren 
  • Referenzdaten und Organisationsstrukturen bereitstellen 
  • Hierarchien und abhängige Stammdaten in geeigneter Reihenfolge übertragen 
  • Simulation, Fehlerkorrektur und produktive Migration durchführen 
  • Mengen, Zuordnungen und fachliche Verwendung prüfen 

Das Migration Cockpit dient primär der initialen Datenübernahme. Für laufende Änderungen sind geeignete Replikations- und Integrationsverfahren einzusetzen. 

18. Laufende Replikation: ALE, DRF und SAP Master Data Integration 

ALE und IDoc 

Gemäß der projektspezifischen ALE-Konzeption umfasst der Aufbau insbesondere RFC-Destination und technischen Benutzer, Verbindungs- und Unicode-Test, Modellsicht, Nachrichtentypen, Verteilung der Modellsicht, Partnervereinbarungen sowie Ausgangs- und Eingangsparameter. 

  • SM59: RFC-Destination im Sendersystem 
  • BD64: Modellsicht und Verteilungsbeziehungen 
  • Nachrichtentypen, zum Beispiel GLMAST/GLCORE, COSMAS, PRCMAS, COAMAS und COGRP-Varianten 
  • Partnerprofile aus der Modellsicht generieren und sender- sowie empfängerseitig prüfen 
  • Technische und fachliche Verarbeitung überwachen 

Ein erfolgreich verarbeitetes IDoc bestätigt die technische Verarbeitung. Es beweist nicht, dass das Objekt fachlich vollständig und korrekt verwendbar ist. 

Data Replication Framework 

DRF steuert geeignete Business Objects über Replikationsmodelle, Business-Systeme, Outbound-Implementierungen, Filter sowie Initial- und Änderungsübertragungen. Verfügbare Objekte und Kanäle hängen vom Szenario ab. 

SAP Master Data Integration 

SAP Master Data Integration ist ein Cloud-Service zur Synchronisation von Stammdaten in hybriden Landschaften. Angebundene Anwendungen tauschen Daten über standardisierte Repräsentationen und APIs aus. Unterstützte Objekte und Attribute sind releasebezogen zu prüfen. 

SAP Master Data Governance 

SAP MDG ergänzt die technische Replikation um Änderungsanträge, Workflow, Staging, Prüfung, Genehmigung, Aktivierung, Verteilung, Dublettenprüfung und Massenverarbeitung. 

Migration übernimmt einen Ausgangsbestand. Replikation synchronisiert laufende Änderungen. Governance regelt Ownership, Prüfung, Freigabe und Lebenszyklus. 

19. Praxiserprobte ALE-Verteilungsreihenfolge 

Die folgende Reihenfolge basiert auf der projektspezifischen ALE-Konzeption und hat sich für die betrachtete Systemlandschaft bewährt. Sie stellt keinen allgemeingültigen SAP-Standard dar. 

Reihenfolge  Objekt  Transaktion 
1  Profit-Center-Hierarchie  KE79 
2  Profit Center  KE77 
3  Kostenstellengruppe  KAVB 
4  Kostenstelle  BD16 
5  PSP-Elemente  CJAL 
6  Sachkonten  BD18 
7  klassische Kostenartenverteilung  BD24 
8  Bankenstamm  FI08 

 

Die Reihenfolge ist je Landschaft anhand von Releases, Nachrichtentypen, Organisationsstrukturen, unterstützten Objekten und kundenspezifischen Erweiterungen zu validieren. Bei BD24 ist die Integration sekundärer Kostenarten in den S/4HANA-Sachkontenstamm besonders zu berücksichtigen. 

Nicht die Transaktionsnummer bestimmt die richtige Reihenfolge, sondern die fachliche Abhängigkeit der Objekte. 

SCREENSHOT 3: Governance, Initialmigration und laufende Replikation mit SAP MDG, SAP S/4HANA, ALE/IDoc, DRF, SAP Master Data Integration und Zielanwendungen. 

20. Wo Finance-Stammdatenprozesse Lücken entwickeln 

  • Führendes System und Ownership sind nicht eindeutig. 
  • Referenzdaten und Organisationsstrukturen fehlen im Integrationskonzept. 
  • Objekte werden ohne Hierarchie- oder Gruppenzuordnung verteilt. 
  • Buchungskreissichten oder zeitliche Gültigkeiten fehlen. 
  • Kostenstellen besitzen kein gültiges Profit Center. 
  • Sachkonten oder Kostenartkategorien passen nicht zum Prozess. 
  • Partnerrollen oder ERS werden ohne Prozessbezug als Pflicht behandelt. 
  • Bewertungsklasse, Preissteuerung oder Material Ledger passen nicht zum Bewertungskonzept. 
  • Kundenspezifische Felder fehlen in Mapping, Migration oder Schnittstelle. 
  • PSP-Elemente sind sichtbar, aber nicht kontierbar. 
  • Ableitungsregeln sind nicht dokumentiert. 
  • IDocs werden nur technisch überwacht. 
  • Steuerindikatoren im BP bzw. Warenempfänger und Material nicht gepflegt. 
  • Tests prüfen den Stammsatz, aber nicht Finanzbeleg, ACDOCA und Reporting. 

Ein fehlerfrei übertragener Stammsatz ist nicht automatisch ein fachlich richtig integriertes Stammdatenobjekt. 

21. Ein pragmatischer Prüfpfad (Quality Check) 

Prüfschritt  Leitfrage 
Architektur  Welche Referenzdaten, Organisationsstrukturen und Objekte bestehen? 
Führendes System  Wo darf ein Objekt angelegt und geändert werden? 
Ownership  Wer beantragt, prüft, genehmigt und überwacht? 
Datenmodell  Welche zentralen und organisatorischen Sichten werden benötigt? 
Hierarchien  Welche Standard-, Alternativ- und Berichtshierarchien sind relevant? 
Abhängigkeiten  Welche Objekte müssen vorab vorhanden sein? 
Gültigkeit  Ab wann dürfen Objekt und Zuordnung verwendet werden? 
Ableitung  Welche Merkmale werden aus welchen Stammdaten ermittelt? 
Projektvorgaben  Welche Regeln sind kundenspezifisch und welche SAP-Standard? 
Migration  Welche Objekte werden initial übernommen? 
Replikation  Welche Verfahren und Reihenfolgen werden eingesetzt? 
Monitoring  Wo werden technische und fachliche Fehler erkannt? 
Belegtest  Entstehen korrekte Finanz- und Controllingbelege? 
Universal Journal  Sind Kontierungsdimensionen in ACDOCA korrekt? 
Reporting  Stimmen Bilanz, GuV, Kostenrechnung und Reporting? 
Lebenszyklus  Wie werden Änderungen, Sperrung und Gültigkeitsende gesteuert? 

 

Jeder Prozess bei dem eine Mengeneinheit oder ein Wertefluss entsteht sollte nur Live gehen, wenn eine qualifizierte Finance Validierung und Freigabe erfolgt ist. 

Fazit: Stammdatenqualität entscheidet auf Belegebene 

Eine korrekte Buchung setzt voraus, dass Referenzdaten, Organisationsstrukturen, Hierarchien und Stammdatenobjekte vollständig, gültig und widerspruchsfrei vorliegen. Buchungskreis und Controlling-Bereich bilden den organisatorischen Rahmen. Sachkonto, Kostenstelle, Profit Center, PSP-Element, Business Partner, Material und Werk liefern die finanzielle Klassifikation und Kontierungsdimensionen. 

Diese Informationen werden, während der Geschäftsprozesse kombiniert, abgeleitet und in den Finanzbeleg übernommen. Im Universal Journal bilden sie die Grundlage für Bilanz, GuV, Kostenrechnung, Ergebnisrechnung und Management Reporting. 

Allgemeingültige SAP-Funktionen und projektspezifische Vorgaben sind klar zu trennen. Partnerrollen, Preissteuerung, Material-Ledger-Ausprägung, kundenspezifische Felder und Verteilungsreihenfolgen müssen stets im Kontext des jeweiligen Prozess- und Systemdesigns bewertet werden. 

Können Sie sicher sein, dass Ihre Stammdaten die richtigen Finanzbelege erzeugen? 

GICOM Kurzanalyse 

Im Rahmen einer kompakten Kurzanalyse prüfen wir Referenzdaten und Organisationsstrukturen, Buchungskreise und Controlling-Bereiche, Data Ownership, Sachkonten und Kostenarten, Kostenstellen und Profit Center, Business Partner, Materialien und Werke, Banken, Ableitungslogiken, Migration, Replikation, Governance sowie die Auswirkungen auf Finanzbelege und Universal Journal. Ferner zeigen wir auch gerne auf, ob die Kontenfindung zu Ihren Stammdaten passt. 

Sprechen Sie uns an. Gemeinsam zeigen wir auf, wo Ihre Stammdatenarchitektur zuverlässig funktioniert und wo gezielte Optimierungen möglich sind. 

Quellen und fachliche Grundlage 

Die fachlichen Inhalte wurden anhand öffentlich zugänglicher SAP-Produktdokumentationen sowie interner Projektdokumentation geprüft. Nicht öffentlich zugängliche Dokumentenpfade und SharePoint-Links sind bewusst nicht Bestandteil dieses Beitrags. Projektspezifische Vorgaben sind im Text entsprechend gekennzeichnet. 

Interne Projektdokumentation 

  • Business Partner Felder FI: Kunden- und Lieferantenfelder, Abstimmkonten, Zahlungsdaten, Partnerrolle Rechnungssteller sowie ERS- und Retourenmerkmale. 
  • Materialstamm Felder FI: werksspezifische Profit-Center-Zuordnung, Steuerklassifikation, Bewertungsklasse, Preissteuerung und Material-Ledger-Vorgaben. 
  • Einrichtung ALE-Verteilung: RFC-Verbindung, Modellsicht, Nachrichtentypen, Partnervereinbarungen und projektspezifische Verteilungsreihenfolge. 
  • Übersicht und Analyse MM-Kontenfindung und Bewegungsarten. 

Abruf der öffentlich zugänglichen SAP-Quellen: 21. Oktober 2026. Maßgeblich bleiben die Produktdokumentation, Release Restriction Notes sowie das Prozess- und Systemdesign der jeweils eingesetzten SAP-Lösung.