SAP FICO erklärt: 7 Dinge, an denen Einführungen scheitern

SAP FICO besteht aus zwei Modulen, die wie eines arbeiten. Das Finanzwesen (FI) liefert die Zahlen, die Wirtschaftsprüfer und Aufsichtsbehörden sehen. Das Controlling (CO) liefert die Zahlen, mit denen das Management das Geschäft steuert. Auf S/4HANA buchen beide in ein einziges Universal Journal. Dieser Artikel richtet sich an Finanzverantwortliche, Programmleiter und FICO-Berater, die einen S/4HANA-Finanzstrang starten, betreiben oder retten müssen. Er erklärt, wie FI und CO zusammenspielen, wo sie an den Rest von SAP anbinden und welche sieben Entscheidungen Einführungen scheitern lassen. Nutzen Sie die Bereitschafts-Checkliste gegen Ende, bevor Sie in den Benutzerabnahmetest (UAT) gehen.

Ich arbeite seit 25 Jahren an SAP-FICO-Projekten, über den gesamten Lebenszyklus vom Blueprint bis zum Support, und immer wieder zeigen sich dieselben Muster. Manche Probleme sind technischer Natur. Häufiger entstehen sie durch Entscheidungen, die früh übereilt oder übersehen wurden.

Der Zeitpunkt spielt 2026 eine Rolle. SAP ECC verlässt Ende 2027 die Mainstream-Wartung, die meisten Finanzteams auf ECC stecken deshalb mitten in der Migration oder stehen kurz davor. Die folgenden Fehler kosten in einem S/4HANA-Programm mehr als auf ECC, weil das Universal Journal später weniger Spielraum lässt, schlechtes Design aufzufangen.

Das Finanzwesen (FI) schaut nach außen. Gesetzliche Vorgaben, Bilanz, Gewinn- und Verlustrechnung, die Zahlen, die das Unternehmen verlassen. Jede Finanztransaktion in SAP landet im FI.

Das Controlling (CO) schaut nach innen. Kostenverfolgung, Budgetierung und Profitabilität für Managemententscheidungen. Kostenstellen zeigen, wo Geld ausgegeben wird. Die Ergebnisrechnung zeigt die Marge nach Kunde, Region oder Produkt.

In der Praxis lassen sich beide nicht trennen. Eine Lieferantenrechnung in der Kreditorenbuchhaltung bucht ins Hauptbuch und kann in Kostenstellenberichte einfließen. Ein Anlagenzugang aktualisiert die Bücher und wirkt sich auf die Kostenplanung aus. Zu wissen, wo FI endet, wo CO beginnt und wo sich beide überschneiden, unterscheidet Finanzverständnis vom bloßen Wissen, welche Taste man drückt.

Auf S/4HANA verschwimmt die Grenze weiter. Das Universal Journal (Tabelle ACDOCA) speichert FI- und CO-Positionen in einem Datensatz. Zwei Folgen sind für das Design wichtig. Kostenarten sind jetzt Sachkonten mit einer Kostenartenart, keine separaten Stammdaten mehr. Und SAPs empfohlenes Profitabilitätsmodell ist die Margenanalyse (kontenbasiertes CO-PA). Das kalkulatorische CO-PA (Costing-based) gibt es On-Premise und in der Private Edition weiterhin. Das Lernmaterial von SAP ist jedoch eindeutig: In S/4HANA Cloud ist es nicht verfügbar, und neue Investitionen fließen in die Margenanalyse.

Das sind die wichtigsten Komponenten, die ein FICO-Team konfiguriert:

Komponente	Bereich	Was sie verwaltet
Hauptbuch (FI-GL)	FI	Zentraler Nachweis aller Finanztransaktionen; Grundlage für die gesetzliche Berichterstattung
Kreditorenbuchhaltung (FI-AP)	FI	Lieferantenrechnungen, Zahlungen, Verbindlichkeiten
Debitorenbuchhaltung (FI-AR)	FI	Kundenrechnungen, Forderungseinzug, Kreditmanagement
Anlagenbuchhaltung (FI-AA)	FI	Zugang, Abschreibung und Abgang von Anlagevermögen
Bankbuchhaltung	FI	Kontoauszüge, Abstimmung, Liquiditätsposition
Kostenstellenrechnung	CO	Kosten nach Abteilung oder Funktion
Innenaufträge	CO	Temporäre Kostensammler für Veranstaltungen, Kampagnen und kleine Projekte
Profit-Center-Rechnung	CO	Erlöse und Kosten je Geschäftseinheit
Margenanalyse (CO-PA)	CO	Marge nach Kunde, Produkt, Kanal oder Region

Der FI-CO-Abgleich entfällt. Mit einem Journal und ohne separate Summentabellen verschwindet der Abgleich zum Periodenabschluss, der in ECC Beratertage fraß, weitgehend. Die Kehrseite: Kostenstellendesign und Profitabilitätsmerkmale müssen zum Zeitpunkt des Designs stimmen. Es gibt keine Aggregationsschicht, die Fehler verbirgt.

Konsolidierung und Planung bekommen ein neues Zuhause. SAP positioniert S/4HANA Group Reporting als Nachfolger von SAP Business Planning and Consolidation (BPC) für die Konsolidierung und SAP Analytics Cloud für die Planung. Die Mainstream-Wartung für BPC endet 2027. Mein Leitfaden zu SAP BPC beschreibt, was zu tun ist, wenn Sie es noch betreiben.

Joule ist real, aber eng begrenzt. In den KI-Release-Hinweisen von SAP aus Mitte 2025 finden sich Einsatzfälle im Finanzbereich wie das Anlegen von Anlagenstammdaten und die Überwachung von Kontoauszügen über Joule. Beschrieben wird auch ein Agent für die Debitorenbuchhaltung, der überfällige Posten nachverfolgt. SAP Joule for Consultants, seit Mai 2025 allgemein verfügbar, beantwortet Konfigurationsfragen aus SAP-Hinweisen und Activate-Inhalten. Alles funktioniert besser mit sauberen Daten. Nichts davon behebt schlechtes Design.

Clean Core verändert, was „Anpassen“ bedeutet. In S/4HANA Cloud Public Edition lässt sich der Kern gar nicht verändern. In der Private Edition und On-Premise geht es, aber jede Modifikation erhöht den Upgrade-Aufwand und das Regressionsrisiko. Die Gewohnheiten aus ECC (Z-Tabellen für Buchungsregeln, Erweiterungen für Steuerlogik, ABAP-Ableitungen im CO-PA) gehören heute in die Standardkonfiguration oder in Side-by-Side-Erweiterungen auf SAP BTP. Das erhöht den Einsatz bei Fehler 4 weiter unten.

FICO ist mit fast jedem anderen SAP-Modul verbunden. An den Übergaben treten die meisten Integrationsprobleme auf: Jedes Team testet seinen eigenen Bereich, und niemand testet die Verbindung.

Modul	Integrationspunkt	Was auf S/4HANA passiert
MM (Materialwirtschaft)	WE/RE-Verrechnung, Rechnungsbuchung, Bestandsbewertung	Der Wareneingang bucht einen WE/RE-Eintrag nach ACDOCA; die Lieferantenrechnung gleicht ihn aus und bucht in die Kreditorenbuchhaltung
SD (Vertrieb)	Fakturierung, Erlöse, Forderungen, Kredit	Die Fakturierung aktualisiert Erlöse und Forderungen im Universal Journal; IFRS 15 nutzt Revenue Accounting and Reporting, wo Verträge es erfordern
PP (Produktionsplanung)	Herstellkosten, Bestand in Arbeit (WIP), Abweichungen	Auftragskosten laufen in ACDOCA auf; WIP und Abweichungen werden im selben Journal abgerechnet
HCM / Personalabrechnung	Buchung der Abrechnung, Kostenzuordnung	Abrechnungsergebnisse werden als Aufwand und Verbindlichkeit ins FI gebucht und fließen auf Kostenstellen
PS (Projektsystem)	Budgets, Abrechnung, Projekterlöse	Projektkosten und -erlöse werden mit sofortiger Sichtbarkeit im FI/CO gebucht
PM (Instandhaltung)	Kosten von Instandhaltungsaufträgen	Lohn- und Materialkosten sammeln sich auf Aufträgen und werden ans CO abgerechnet
Group Reporting	Konsolidierung	Liest ACDOCA direkt; keine separate Konsolidierungsdatenbank

Das Universal Journal verändert, wie diese Integrationen scheitern. In ECC zeigten sich FI-CO-Differenzen als Abstimmungsproblem. Auf S/4HANA erzeugt eine MM-Buchung, die auf dem falschen Konto landet, einen echten Journaleintrag, der storniert und neu gebucht werden muss. Prüfungsfeststellungen kommen schneller. Zur Logistikseite dieser Übergaben finden Sie meine Leitfäden zu SAP SD und SAP PP.

1. 01Wareneingang in MMBestand und Bestandswert werden aktualisiert
2. 02KontenfindungDie Bewertungsklasse bestimmt die Sachkonten
3. 03WE/RE-Eintrag in ACDOCAEine Universal-Journal-Zeile für FI und CO
4. 04LieferantenrechnungGleicht den WE/RE-Eintrag aus
5. 05KreditorenbuchhaltungBucht ins Hauptbuch und kann in Kostenstellenberichte einfließen

Ein Journaleintrag, den FI und CO gemeinsam lesen

1. Stammdaten, für die niemand verantwortlich ist

Die meisten Projekte sind sich in Woche eins einig, dass die Stammdaten bereinigt werden müssen. Dann übernimmt die Konfiguration, die Termine werden enger, und die Stammdaten bleiben liegen. Bis zum Test.

Ein Handelskunde in den VAE hatte eine Kostenstellenhierarchie, die vollständig aussah. Die Bezeichnungen passten. Die Summen stimmten. Im Integrationstest tauchten Filialkosten unter Regionalverantwortlichen auf, die keinen Sinn ergaben, und einige Daten fehlten ganz.

Die Struktur war nie daran geprüft worden, wie die Filialen tatsächlich arbeiten. Sie beruhte auf den Annahmen des Einführungsteams. Die Neustrukturierung der Kostenstellenzuordnung und der Berichtslogik dauerte zwei Wochen, mit guten Leuten, die sich ausschließlich darum kümmerten.

Die üblichen Verdächtigen kennt man. Sachkonten, die aus dem Altsystem kopiert wurden, ohne den aktuellen Berichtsbedarf zu prüfen. Lieferantenstammsätze mit veralteten Steuerdaten oder fehlenden Bankverbindungen. Kostenstellenhierarchien, die dem Organigramm folgen statt dem Kostenfluss. Profit-Center, die spät dazukommen. Benennen Sie einen Verantwortlichen für die Stammdaten, bevor der Blueprint abgeschlossen ist. Schon eine grobe Prüfung von Struktur, Nutzung und Lücken verhindert den Großteil der späteren Bereinigung.

2. CO ohne Beteiligung der Controller konfiguriert

Das Controlling kommt meist an zweiter Stelle. FI wird früh entworfen, geprüft und getestet. CO folgt mit weniger Aufmerksamkeit, in der Annahme, es sei einfacher und lasse sich später fertigstellen.

Das geht nicht.

In einem Telekommunikationsprojekt, an dem ich gearbeitet habe, wurde CO-PA spät konfiguriert. Die Tests sahen gut aus. Buchungen liefen durch, Berichte liefen. Dann prüften Vertrieb und Finanzen die Margen, und die Top-Produkte zeigten eine negative Profitabilität. Wichtige Kostenarten waren nicht zugeordnet, und die Ableitungsregeln waren unvollständig. Die Korrektur bedeutete, Berichtsstrukturen neu zu entwerfen, die bereits abgenommen waren.

CO funktioniert nur, wenn die Menschen, die die Berichte lesen, also Controller und Finanzleiter, es mitgestalten. Sie denken in Kostenverhalten und Marge, nicht in Systemfluss. Holen Sie sie im Blueprint dazu, nicht im UAT.

3. Fachanwender sehen das System erstmals im UAT

Im UAT zeigen sich Probleme, und es ist der teuerste Ort, sie zu finden. Das Design ist eingefroren, die Konfiguration fast fertig.

Bei einer Finanztransformation für eine Holdinggesellschaft in Südostasien startete das UAT zuversichtlich. Die Skripte waren fertig. Die technischen Prüfungen waren bestanden. Dann meldete sich das Finanzteam an. Für viele war es das erste Mal, dass sie die Bildschirme sahen. Felder, die sie täglich nutzten, waren weg. Schritte waren ohne Erklärung hinzugekommen. Workflows waren so umgebaut worden, dass es technisch Sinn ergab und operativ keinen.

Wir mussten zentrale Abläufe überarbeiten, und ein Teil der Logik musste neu aufgebaut werden. Das Projekt verlor Wochen.

Zeigen Sie den Anwendern früh unfertige Bildschirme. Das ist immer günstiger, als ihnen spät fertige zu zeigen.

4. Eigenentwicklung, wo Konfiguration gereicht hätte

Eigener Code fühlt sich schneller und kontrollierter an. Man bekommt genau das, was verlangt wurde. Mit der Zeit wird er schwer zu testen, schwer zu ändern und fragil, und auf S/4HANA erhöht jede Modifikation den Upgrade-Aufwand.

Ich habe einmal an einer globalen Einführung in sechs Ländern gearbeitet, bei der die Steuerlogik vollständig in ABAP gebaut wurde: Länderregeln, Ausnahmen, produktbasierte Sätze. Es funktionierte. Aber der SAP-Standard deckte das bereits mit Konditionsarten, Steuerkalkulationsschemata und Länderkonfiguration ab.

Als ein Land einen Steuersatz änderte, musste der Fachbereich einen Entwicklungsauftrag stellen, warten und alles neu testen. Was am Anfang effizient wirkte, wurde zum Engpass bei jeder Steueränderung. Die Lösung in solchen Fällen: die Eigentabellen ablösen, die Logik in die Standardkonfiguration verlagern und nur die wirklich einzigartigen Regeln in einer kleinen Erweiterung behalten.

Dasselbe Muster zeigt sich auch anderswo. Eigene Validierungen für Buchungsregeln, die die Konfiguration bereits abdeckt. Berichte, die neu gebaut werden, obwohl es Standard-Fiori-Apps oder CDS-Views gibt. Fest codierte Freigabeschritte ohne Spielraum für Änderungen. Stellen Sie jedes Mal eine Frage: Wo liegt diese Logik, und übersteht sie das nächste Upgrade ohne ein Projekt? Lautet die Antwort „im Kern“ oder „das haben wir nicht geprüft“, verlagern Sie sie in die Konfiguration oder nach BTP.

5. Ungeprüfte Integrationspunkte

Beim Testen konzentrieren sich die Teams auf ihr eigenes Modul. Die Modulgrenzen bleiben ungeprüft.

Bei einem Rollout in der Fertigung wurden Wareneingänge in MM korrekt verarbeitet. Der Bestand wurde aktualisiert. Die Logistik hatte keine Beanstandungen. Im FI gab es zu diesen Wareneingängen keine Buchungsbelege.

Die Ursache war eine Bewertungsklasse, die in der Kontenfindung fehlte. MM verarbeitete ohne Fehler und erzeugte keine Finanzbuchung. Zwei Tage für die Diagnose. Mehrere weitere, um aufzuräumen, was in der Zwischenzeit gebucht worden war.

Ähnliche Fehler, die ich gesehen habe: SD-Fakturen, die wegen Lücken in der Kontenfindung auf falsche Erlöskonten buchen. Anlagenübertragungen in PM, die nie in der Anlagenbuchhaltung ankommen. WE/RE-Logik, die MM- und FI-Team unterschiedlich verstanden haben. Ein Finanzverantwortlicher, der die Testskripte von MM und SD prüft, verhindert das meiste davon. Das Finanzwesen weiß, wie eine Buchung aussehen muss. Ein Logistik-Tester oft nicht.

6. Reporting im letzten Sprint entworfen

Für ein Modul, dessen Zweck es ist, Finanzinformationen zu liefern, schieben Projekte das Reporting mit bemerkenswerter Konsequenz ans Ende. Erst die Buchungen zum Laufen bringen, die Berichte später klären.

Bei einem Konsumgüterkunden in Europa, wo ich die Phase nach dem Go-live begleitete, war CO-PA aufgebaut, waren Felder zugeordnet und Ableitungen konfiguriert. Die erste Segment-GuV hatte die richtigen Überschriften und verstreute, fragmentierte Kosten. Die Erlöse waren in Ordnung. Einige Wertfelder waren gar nicht gefüllt.

Das Finanzteam fiel auf Excel zurück. Schon wieder. Ich musste einspringen, um das zu klären. Ist das Vertrauen in das Reporting einmal verloren, kommt es selten von allein zurück.

Wenn die Marge je Kanal oder die Kosten je Projekt für das Geschäft wichtig sind, muss diese Anforderung bestimmen, wie Daten im Design erfasst werden. Die übliche Reporting-Schicht ist 2026 SAP Analytics Cloud auf dem Universal Journal. Sie ist in manchen GROW- und RISE-Paketen enthalten und in anderen separat zu erwerben, prüfen Sie also Ihren Vertrag. Analytics Cloud auf einem sauberen Profitabilitätsdesign funktioniert. Analytics Cloud auf einem halb konfigurierten nicht. Mehr dazu in meinem Leitfaden zu SAP Analytics Cloud.

7. Sonderfälle, die zwischen den Teams durchfallen

Projekte konzentrieren sich zu Recht auf Prozesse mit hohem Volumen. Dadurch werden Sonderfälle beiseitegeschoben, bis sie auftauchen.

In einem Rollout hatte der Kunde drei Buchungskreise mit drei verschiedenen Geschäftsjahresvarianten: eine nach Kalenderjahr, eine von April bis März, eine nach 4-4-5. Niemand wies im Design darauf hin.

Es zeigte sich in der Intercompany-Abstimmung. Die Perioden passten nicht zusammen. Das Finanzwesen konnte nicht rechtzeitig abschließen, weil jeder Buchungskreis andere Stichtage hatte. Dieses eine Problem warf die Konsolidierung um zwei Wochen zurück.

Planen Sie eine Stunde ein, in der jeder Workstream auflistet, was in seinem Bereich ungewöhnlich ist. Stellen Sie drei Fragen. Gibt es rechtliche oder regionale Regeln, die noch nicht abgebildet sind? Betreibt ein Team manuelle Workarounds außerhalb von SAP? Werden Funktionen wie Anzahlungen, vorerfasste Belege oder Intercompany-Verrechnung genutzt? Die Sonderfälle tauchen immer auf. Die einzige Frage ist, ob in einem Design-Workshop oder im Monatsabschluss.

Gehen Sie diese Liste zwei Wochen vor Beginn des UAT durch. Jedes „Nein“ ist ein Risiko, das mit Verantwortlichem und Datum festzuhalten ist.

1. Verantwortlicher für Stammdaten benannt. Eine Person nimmt Kontenplan, Kostenstellenhierarchie, Profit-Center sowie Lieferanten- und Kundenstammdaten ab. Verantwortlich: Finanzleiter.
2. Kostenstellenhierarchie am realen Kostenfluss getestet. Nicht am Organigramm. Verantwortlich: Leiter Rechnungswesen.
3. Controller haben das Profitabilitätsdesign geprüft. Merkmale, Ableitungsregeln und den ersten Entwurf der Segment-GuV. Verantwortlich: Leiter Controlling.
4. Key-User haben die Bildschirme gesehen. Mindestens ein Walkthrough je Prozess, bevor die UAT-Skripte geschrieben werden. Verantwortlich: Leiter Finanzprozesse.
5. Liste der Eigenentwicklungen geprüft. Für jede Erweiterung ist begründet, warum die Standardkonfiguration es nicht leisten konnte. Verantwortlich: Lösungsarchitekt.
6. Kontenfindung modulübergreifend getestet. Ein Wareneingang, eine Lieferantenrechnung, eine Kundenfaktura und eine Produktionsauftragsabrechnung erzeugen jeweils die erwarteten Buchungen. Verantwortlich: FICO-Lead mit den Leads von MM, SD und PP.
7. Management-Berichte aus echten Testdaten erstellt. Keine Mock-ups. Verantwortlich: Reporting-Lead mit dem Büro des CFO.
8. Geschäftsjahresvarianten, Währungen und Intercompany-Einstellungen über alle Buchungskreise hinweg verglichen. Verantwortlich: FICO-Lead.
9. Workshop zu Sonderfällen durchgeführt. Abgrenzungen, Anzahlungen, vorerfasste Belege, Intercompany-Verrechnung, länderspezifische Steuerregeln. Verantwortlich: Programmmanager.

Was ist SAP FICO, und wofür steht jeder Buchstabe?

FI steht für Finanzwesen (Financial Accounting) und CO für Controlling. Zusammen sind sie die zentralen Finanzmodule von SAP.

FI deckt die externe Berichterstattung ab: Hauptbuch, Kreditorenbuchhaltung, Debitorenbuchhaltung, Anlagenbuchhaltung und Bankbuchhaltung. CO deckt das interne Management-Reporting ab: Kostenstellen, Innenaufträge, Profit-Center und Ergebnisrechnung.

Beide sind eng verknüpft. Auf S/4HANA teilen sie sich ein Universal Journal, man kann also das eine nicht ohne das andere verstehen.

Wie wird SAP FICO mit SAP MM, SD und PP integriert?

MM zu FI: Ein Wareneingang bucht automatisch einen WE/RE-Eintrag. Die Lieferantenrechnung gleicht ihn aus und bucht in die Kreditorenbuchhaltung. Die Kontenfindung muss stimmen, sonst verarbeitet MM, und es entsteht keine Finanzbuchung.

SD zu FI: Die Fakturierung aktualisiert Erlöse und Forderungen. Lücken in der SD-Kontenfindung leiten Erlöse auf falsche Konten oder ins Leere.

PP zu FI/CO: Fertigungsaufträge sammeln Material-, Lohn- und Gemeinkosten. CO rechnet Bestand in Arbeit und Abweichungen ab. Ein schwaches Profitabilitätsdesign führt dazu, dass diese Kosten nie in den Margenberichten ankommen.

Die Lösung ist in allen drei Fällen dieselbe. Ein Finanzverantwortlicher sollte die Integrationstestskripte der anderen Workstreams prüfen.

Was ist der Unterschied zwischen SAP HANA und SAP FICO?

Es sind verschiedene Schichten. SAP HANA ist die In-Memory-Datenbank. SAP FICO ist die Finanzanwendung, die Buchhalter und Controller nutzen.

Auf S/4HANA macht HANA das Universal Journal erst praktikabel: FI- und CO-Daten in einer Tabelle, in Echtzeit ausgewertet, ohne Batch-Abstimmung. Ein HANA-Performanceproblem beeinflusst, wie schnell FICO-Berichte laufen. Ein FICO-Konfigurationsproblem bestimmt, was in diesen Berichten steht.

Ist SAP FICO mit S/4HANA im Jahr 2026 noch relevant?

Ja. Die Kernkompetenzen lassen sich übertragen: Kontenfindung, Kostenstellendesign, Profitabilitäts-Setup, Periodenabschluss. Unternehmen brauchen weiterhin Menschen, die Finanzprozesse verstehen und nicht nur Transaktionen.

Geändert hat sich das gefragte Profil. Arbeitgeber wollen FICO-Berater, die das Universal Journal, die Margenanalyse, Group Reporting und Clean-Core-Erweiterungen verstehen und die beraten können, welche ECC-Anpassungen bei der Migration abgelöst werden. Weil die Mainstream-Wartung für ECC 2027 endet, hält die Migrationsarbeit die Nachfrage hoch.

Wenn Sie einen Wechsel in Ihrer FICO-Laufbahn planen: Die Karrierepfade von SAPopedia ordnen die Skills nach Rolle, und das ERPCV-Karrierepaket hilft Ihnen, S/4HANA-Finanzerfahrung im Lebenslauf darzustellen.

Wie verändert Joule SAP-FICO-Einführungen im Jahr 2026?

Weniger, als das Marketing suggeriert, mehr, als Skeptiker annehmen. SAP Joule for Consultants beantwortet Konfigurations- und Codefragen aus den SAP-Hinweisen und Activate-Inhalten von SAP, was die Recherche zum Standardumfang beschleunigt. Im System übernimmt Joule Aufgaben wie das Anlegen von Anlagenstammdaten und die Überwachung von Kontoauszügen, und SAP hat Finanz-Agenten veröffentlicht, etwa einen zum Nachverfolgen überfälliger Forderungen.

Nichts davon ersetzt das Urteilsvermögen im Design bei Steuern in mehreren Ländern, Konzernberichtsstrukturen oder Umsatzrealisierung. Und es funktioniert nur so gut wie die Daten darunter. Wenn Sie Partnerangebote prüfen, fragen Sie, wie sich KI-Werkzeuge in deren Aufwandsschätzungen niederschlagen.

Was sind die wichtigsten FICO-Konfigurationsschritte bei einer Neueinführung?

Das Fundament wird ungefähr in dieser Reihenfolge konfiguriert:

1. Buchungskreise: die rechtlichen Einheiten, die Abschlüsse erstellen.
2. Geschäftsjahresvarianten: Kalenderjahr, April bis März oder 4-4-5. Halten Sie sie über Buchungskreise hinweg konsistent, die miteinander Handel treiben.
3. Kontenplan: die Liste der Sachkonten, nach Möglichkeit über Buchungskreise hinweg gemeinsam genutzt. Diese Entscheidungen wirken sich über die gesamte Lebensdauer des Systems auf jeden Bericht aus.
4. Buchungsperiodenvarianten: welche Perioden für Buchungen offen sind.
5. Feldstatusvarianten: welche Felder Pflicht, optional oder ausgeblendet sind.
6. Steuerkonfiguration: Steuerkennzeichen, Sätze und Länderzuordnung. Hier steckt der Großteil der Lokalisierungskomplexität.
7. Controlling-Strukturen: Kostenrechnungskreis, Kostenstellen, Profit-Center, Innenaufträge und Profitabilitätsmerkmale, gemeinsam mit Controllern entworfen.
8. Kontenfindung: wie Transaktionen aus MM, SD und PP zu FI-Buchungen werden. Validieren Sie sie vor dem Go-live mit End-to-End-Integrationstests.