Nutzung von Standardfeldern und kundeneigenen Feldern
Die Aufnahme der Bewegungsart und der Partnergesellschaft in die Summentabelle zur Durchführung einer übergreifenden Intercompany-Abstimmung und in Vorbereitung des Konzernabschlusses sind in der Praxis ein großer Benefit des neuen Hauptbuchs. Aber auch der Bedarf an der Aufnahme kundeneigener Zusatzfelder (Zusatzkontierung) über die im SAP-Standard vorgesehenen Kontierungen hinaus war bei allen Kunden gegeben. Die Motivation liegt hier insbesondere darin, die Verschlüsselung fachlicher Differenzierungsmerkmale in den Kontenplänen der Unternehmen zu vermeiden. In der Praxis soll der Buchungsstoff dabei zumeist nach folgenden Aspekten differenziert werden:

* Organisatorische Aspekte (Vertriebseinheiten, Niederlassungen, etc.)

* Produktbezogene Aspekte (Produktlinien, Produktgruppen, etc.)

* Anforderungen der externen Berichterstattung (RechVersV, etc.)

* Zeitliche Abgrenzungen des Buchungsstoffs (IFRS 1, etc.)

Werden diese Differenzierungsmerkmale über separate Konten abgebildet, kommt es zu einer erheblichen Aufblähung des Kontenplans. Anderseits ist es nur zweckmäßig, ein kundeneigenes Feld einzuführen, wenn dieses wirklich für eine erhebliche Anzahl von Konten relevant ist. Die Abbildung von Geschäftsvorfällen über Konten entspricht der »natürlichen Denke« des Buchhalters und ist leicht zu pflegen, maximiert jedoch die Kontenanzahl und lässt sich nur bedingt systematisch auswerten. Bei allen von uns begleiteten Projekten in diesem Umfeld entschieden sich die Kunden zur Nutzung von Zusatzkontierungen in Form kundeneigener Felder bzw. der SAP-Standard-Zusatzkontierungen der Branchenlösungen.


Segmentberichterstattung und Belegaufteilung
Durch die Bereitstellung einer Segmentkontierung und deren durchgängiger Aufnahme in das Standardberichtswesen wird grundsätzlich eine sehr gute Funktionalität zur Segmentberichterstattung bereitgestellt, die sich in der Praxis bewährt hat. Die weiterführende Unterstützung der Segmentberichterstattung durch die Funktionalität der Belegaufteilung beeinflusst maßgeblich die Komplexität einer Einführung des neuen Hauptbuchs. Fachlich ist insbesondere die A-priori-Ermittlung der Splittingregeln eine große Herausforderung. Vor der Splittingumsetzung ist hauptsächlich zu klären, ob für alle manuellen bzw. maschinellen Buchungen die für eine fachlich zutreffende Schlüsselermittlung notwendigen Voraussetzungen zum Zeitpunkt der Buchung gegeben sind. Auch bei der Datenmigration erhöht die nachträgliche Ermittlung der Splitinformationen den Aufwand und die Komplexität deutlich. Die Belegaufteilung ist immer besonders zweckmäßig, wenn die Schlüssel zum Zeitpunkt der Buchung final bekannt sind und keine nachträgliche Anpassung mehr erfolgen muss. Insofern kann die nachträgliche Anreicherung des Buchungsstoffs am Periodenende bzw. zum Reporting-Zeitpunkt eine fachlich einfacher zu verwirklichende und transparente Alternative zur Belegaufteilung darstellen.

Weiterhin stellt sich die fachliche Frage, ob tatsächlich komplette Segmentbilanzen und GuV-Rechnungen erstellt werden müssen. So lassen sich diese z.B. bei Versicherungsunternehmen aufgrund der gesetzlich vorgeschriebenen Spartentrennung häufig schon über den Buchungskreis auswerten. Eine weitere buchungskreisübergreifende Differenzierung der Sparten etwa nach Kundengruppen ist derzeit nicht vorgeschrieben. Auch bspw. bei Energieversorgern ist eine konsequente Segmentierung sogenannter Zebra-Gesellschaften (eine Gesellschaft, die mehreren Segmenten zuzurechnen ist) sehr aufwendig und im Detail fachlich kaum zu rechtfertigen. Letztlich sahen alle von uns betreuten Kunden von einer unmittelbaren Einführung der Belegaufteilung ab. Aufgrund der fachlichen Komplexität und des Umfangs der aus dem Belegsplitt resultierenden Prozesse und technischen Anpassungen sollte die Einführung der Belegaufteilung unseres Erachtens nach als ein separates (Teil-)Projekt aufgefasst werden. Der Anforderung nach einer nachgelagerten Einführung der Belegaufteilung bei bereits produktivem NewGL wurde mit dem Migrationsszenario 6 nachgekommen. Grundsätzlich ist festzuhalten, dass in der Praxis die Herausforderung in diesem Themenkomplex primär die Fachlichkeit und weniger die systemseitige Funktionalität ist.