Intercompany Kostenumlagen & -verteilungen auf Projekte (1)

23 Sonntag Okt 2016

Schlagwörter

Gemeinkosten, indirekte Kosten, Intercompany, Projektkostenumlagen

Im vorherigen Beitrag habe ich verschiedene Möglichkeiten aufgezeigt, wie man über Dynamics AX Standardfunktionen indirekte Kosten auf Projekte verteilen kann. Der primäre Fokus im letzten Beitrag lag hierbei auf sog. intra-company Kostenumlagen und -verteilungen.
Innerhalb dieses und der folgenden Beiträge möchte ich diesen Fokus auf intercompany Kostenumlagen und -verteilungen erweitern und anhand von verschiedenen Beispielen aufzeigen, wie diese im Standard von Dynamics AX realisiert werden können.

Beispiel 1: Mitarbeiter der Firma USSI arbeiten auf Projekten der Firma FRSI

Teil A: Ausgangssituation
Im Rahmen dieses ersten Beispiels möchte ich zunächst auf die Standard intercompany Arbeitszeitnachweisfunktion eingehen, welche es Mitarbeitern erlaubt Zeiten auf Projekten, die in anderen Gesellschaften angelegt wurden, zu erfassen.
Der ein oder andere hat bestimmt schon von dieser Standardfunktion gehört bzw. etwas darüber gelesen. Ungeachtet dessen möchte ich dennoch innerhalb dieses ersten Beispiels auf dieses Szenario eingehen, weil es die Grundlage alle weiteren komplexeren intercompany Szenarien bildet.
Ausgangsbasis für dieses erste Beispiel ist eine Mitarbeiterin, die in der Firma USSI angestellt ist und für ein Kundenprojekt das in der Firma FRSI angelegt ist eine Softwareinstallation durchführt. Damit diese Mitarbeiterin ihre Zeiten auf das entsprechende Kundenprojekt in der Firma FRSI erfassen kann sind die folgenden Einstellungen erforderlich.

Teil B: Systemeinrichtung

Setup B.1: Intercompany Kunden – Lieferanten Beziehung
Zunächst ist es erforderlich in den Firmen USSI und FRSI entsprechende Kunden- und Lieferantenkonten anzulegen, welche über die Standard intercompany Funktion miteinander verknüpft werden, wie dies im folgenden Screenshot aufgezeigt ist.

Hinweis: Da im Rahmen der Projektbuchungseinstellungen keine Möglichkeit besteht auf eine bestimmte Gesellschaft zu referenzieren ist es erforderlich die entsprechenden Kunden-/Lieferantenkonten mit einer entsprechenden intercompany Finanzdimension einzurichten. Zu weiteren Einzelheiten hierzu, siehe auch weiter unten im Detail.

Setup B.2: Projekt Kategorien
Die zweite erforderliche Einrichtung bezieht sich auf die Einrichtung von Projektkategorien, die in beiden am intercompany Prozess beteiligten Firmen eingerichtet sein müssen.
Hinweis: Ist die Kategorie auf die Zeiten erfasst werden sollen nur in einer Firma angelegt, so wird die Verarbeitung der Zeiterfassung auf dem Projekt in der anderen Firma mit folgendem Fehlerhinweis unterbrochen:

Setup B.3: Intercompany Verrechnung
Sobald alle erforderlichen Projektkategorien in beiden Firmen angelegt wurden, kann im nächsten Schritt die Einrichtung der intercompany Verrechnungseinstellungen im Hauptbuch vorgenommen werden. Beispiel:

Die Einrichtung dieser Verrechnungsbeziehungen ist selbst nicht unmittelbar für die Buchung der intercompany Arbeitszeitnachweise erforderlich. Für eine richtige Zuordnung und Auswahl der entsprechenden Gesellschaften und Projekte ist diese Einrichtung allerdings unerlässlich.
Für den Fall dass eine solche Beziehung bspw. zwischen der Firma USSI und FRSI nicht besteht, ist eine Auswahl in der Arbeitszeitnachweismaske nicht möglich. Der folgende Screenshot zeigt dieses Systemverhalten nach Löschung der USSI-FRSI Verrechnungsbeziehung auf.

Setup B.4: Projekteinrichtung Firma FRSI
Bei der Projekteinrichtung in der Firma FRSI – auf welches später die entsprechenden Zeiten gebucht werden sollen – ist darauf zu achten, dass diese Einrichtung mit Hinterlegung einer entsprechenden intercompany Finanzdimension erfolgt. Andernfalls wird eine spätere Identifikation und Trennung von intercompany Kosten und Erlösen z.B. im Rahmen der Konsolidierung erheblich erschwert.

Hinweis: Die anderen an dieser Stelle verwendeten Finanzdimensionen (Abteilung 0023 & Projekt 0000027) sind für die Verarbeitung und Buchung der Zeiten auf intercompany Projekten nicht zwingend erforderlich. Aus Darstellungsgründen wurden diese beiden Größen allerdings an dieser Stelle mit aufgenommen.

Setup B.5: Mitarbeiter USSI
Nach der Einrichtung des Projekts in der Firma FRSI wird im nächsten Schritt der Mitarbeiter in der Firma USSI entsprechend eingerichtet. Im Rahmen dieser Einrichtung gibt es weiter keine Besonderheiten zu beachten außer derjenigen, dass die Mitarbeiter mit ihren zugehörigen Finanzdimensionen, wie den ihnen zugeordneten Abteilungen / Kostenstellen, usw. eingerichtet werden.

Setup B.6: Intercompany Verkaufspreis
Aus systemtechnischer Sicht ist die Einrichtung von intercompany Verkaufspreisen, welche für die Buchung und Abrechnung zwischen den Gesellschaften verwendet werden regelmäßig kein Problem, da lediglich ein bestimmter interner Verrechnungspreis zu hinterlegen ist.
Aus buchhalterischen und steuerlichen Gesichtspunkten ist die Festlegung von intercompany Verrechnungspreisen allerdings erheblich komplexer. Diese Komplexität lässt sich hauptsächlich auf eine Vielzahl von zum Teil widersprüchlichen intercompany Verrechnungspreisregeln zurückführen, auf die im Rahmen dieses Beitrags nicht eingegangen werden kann. Ein guter Ausgangspunkt für die hier angesprochenen Verrechnungspreisregeln stellen die OECD Transfer Pricing Guidelines dar.

Basierend auf dem grundlegenden OECD arm’s length Prinzip wurde für das hier verwendete Beispiel ein Verrechnungspreis in Höhe von 300 USD festgelegt, welcher dem Preis entspricht, den auch externe Kunden berechnet bekommen. Siehe hierzu den folgenden Screenshot.

Hinweis: Im Zusammenhang mit der Festlegung von internen Verrechnungspreisen erlaubt Dynamics AX auch die Nutzung von Auf- und Abschlags-Verkaufspreismodellen um hierdurch bestimmte Intercompany-Preis-Modelle aus den OECD Richtlinien abbilden zu können.

Teil C: Prozessschritte

Schritt C.1: Verarbeitung von intercompany Arbeitszeitnachweisen
Nachdem alle zuvor aufgeführten Einrichtungsschritte abgeschlossen wurden, kann die Mitarbeiterin der Firma USSI über die Arbeitszeitnachweismaske das zugehörige Projekt in der Firma FRSI auswählen und ihre Zeiten hierauf buchen. Zu beachten ist in diesem Zusammenhang dass die Finanzdimensionen, die auf dem Projekt hinterlegt wurden automatisiert in den Arbeitszeitnachweis übertragen werden, wie dies im folgenden Screenshot aufgezeigt ist.

Mit Buchung des Arbeitszeitnachweises generiert Dynamics AX die folgende Sachkontobuchung in der Firma USSI, welche auf der einen Seite das gewöhnliche Projekt-Kostenkonto (Nr. 540100) mit den Kosten für die geleisteten Arbeitsstunden belastet und auf der anderen Seite das Lohn- und Gehaltsverrechnungskonto Nr. 602100 entsprechend entlastet.

Schritt C.2: Buchung der intercompany Projektrechnung
Nach der Erfassung der Stunden erfolgt im nächsten Schritt die Buchung der intercompany Rechnung über die entsprechende Projektmodulfunktion. Beispiel:

Sobald alle zu berechnenden Positionen ausgewählt und gebucht wurden …

… verbleibt der folgende Buchungsbeleg.

Hinweis: Das im Rahmen dieser Buchung verwendete intercompany Forderungskonto Nr. 133100 stammt aus den Debitoren Buchungsprofileinstellungen und das intercompany Erlöskonto aus den Sachkontobuchungseinstellungen im Projektmodul.

Schritt C.3: Buchung der zugehörigen Kreditorenrechnung in der Firma FRSI
Mit der Buchung der intercompany Projektrechnung in der Firma USSI wird gleichzeitig eine entsprechende Kreditorenrechnung in der Firma FRSI erstellt, die im Bereich der ausstehenden Kreditorenrechnungen im Kreditorenmodul identifiziert werden kann.

Die Buchung dieser Rechnung führt zu folgender Sachkontobuchung:

Um die einzelnen Buchungen besser nachvollziehen zu können, habe ich diese in der folgenden Übersicht nochmals zusammengefasst.

Was man der obenstehenden Übersicht entnehmen kann ist …

Erstens, dass die Kosten für die erfassten IC-Stunden auf dem zugehörigen Projekt in der Firma FRSI erst mit Buchung der IC-Rechnung, nicht aber vorher identifiziert werden können.
Zweitens, dass die im Rahmen der Konsolidierung gelb und orange hervorgehobenen Konten über die mitgebuchte intercompany Finanzdimension einfach und leicht identifiziert werden können. Hinweis: Die FRSI intercompany Finanzdimension, die im Rahmen der IC-Rechnungsbuchung verwendet wird, wird aus den Einstellungen des IC-Debitorenkontos herangezogen. Im Gegensatz hierzu stammt die FRSI intercompany Finanzdimension der ersten und letzten Buchung aus den Projekteinstellungen in der Firma FRSI.
Drittens, dass ein Vergleich der Kosten und intercompany Erlöse – im folgenden Screenshot grün hervorgehoben – eine Verifizierung der Angemessenheit der angewandten intercompany Verrechnungspreise gegenüber externen Adressaten wie Wirtschafts- und Steuerprüfern ermöglicht.

Hinweis: Wie bereits mehrfach erwähnt ist die Nutzung einer intercompany Finanzdimension für den gesamten Prozess entscheidend. Diesbezüglich gilt es zu beachten, dass es über die Projektbuchungseinstellungen nicht möglich ist Konteneinstellungen in Abhängigkeit bzw. Referenz zu einer bestimmten Firma zu hinterlegen, sondern dass zwingend die Nutzung von Finanzdimensionsgrößen hierfür erforderlich ist.

Was buchhalterisch geschieht, wenn die intercompany Finanzdimensionsinformation auf Ebene des IC-Projekts fehlt, kann aus dem folgenden Screenshot identifiziert werden.

Die rot hervorgehobenen Flächen und Pfeile zeigen auf, dass es bei fehlender intercompany Finanzdimensionshinterlegung auf Ebene des Projekts zu erheblichen Schwierigkeiten im Rahmen der Konsolidierung kommen kann, da die zu konsolidierenden intercompany Buchungen nicht einfach identifiziert werden können. Gleiches gilt für die Prüfung der verwendeten Verrechnungspreisregeln.

Zwischenergebnis
Ich hoffe dass Ihnen dieser Beitrag einige neue Hinweise im Hinblick auf den Einsatz der intercompany Arbeitszeiterfassung liefern konnte auch wenn sie bereits zuvor davon gehört und/oder gelesen haben. Vor dem Hintergrund dieser Standardfunktion möchte ich im folgenden Beitrag auf andere, komplexere intercompany Verrechnungsszenarien eingehen.

Kostenumlagen & -verteilungen auf Projekte

02 Sonntag Okt 2016

Posted by Ludwig Reinhard in Projekt

≈ Hinterlasse einen Kommentar

Schlagwörter

Gemeinkosten, indirekte Kosten, Projektkostenumlagen

Einführung
In einem früheren Beitrag habe ich die Funktion der sog. indirekten Projektkosten dargestellt. Zu Einzelheiten, siehe hier.

Ein wesentliches Ergebnis dieses Beitrags war, dass die Einsatzmöglichkeiten der indirekten Projektkostenfunktion – aufgrund ihrer Limitierung auf Transaktionen, die im unmittelbaren Zusammenhang mit Projektstundenbuchungen stehen – derzeit eingeschränkt ist.

Innerhalb dieses Beitrags möchte ich einen erneuten, allgemeineren Blick auf indirekte Projektkosten („Gemeinkosten“) werfen, um zu analysieren, wie diese auf verschiedene Projekte verteilt werden können, um hierdurch einen Blick auf die Gesamtkosten eines Projekts zu erhalten.

Ein wichtiger Gesichtspunkt in diesem Zusammenhang ist, welche Gemeinkosten überhaupt auf Projekte verteilt werden dürfen. Die meisten Rechnungslegungstandardsetter, wie das IASB oder das FASB, bestimmen in diesem Zusammenhang, dass lediglich solche Gemeinkosten auf Projekte verteilt werden dürfen, die in unmittelbarem Zusammenhang zu Projekten stehen. Siehe hierzu z.B. IAS 11.

In den folgenden Unterkapiteln möchte ich aufzeigen, welche Standardmöglichkeiten in Dynamics AX bestehen, um sowohl direkt als auch nicht direkt auf Projekte zuordenbare Kosten auf diese zu verteilen, um hierdurch eine Analyse der gesamten Projektkosten zu ermöglichen.

Beginnen wir mit dem Beispiel wie Versicherungsgebühren – die eindeutig einer Vielzahl von Projekten zugerechnet werden können – auf diese Projekte verteilt werden können.

Beispiel 1: Umlage von Versicherungsgebühren
Im Rahmen dieses ersten Beispiels werden Versicherungsgebühren über ein gewöhnliches Kreditorenrechnungserfassungsjournal auf dem Sachkonto Nr. 606200 und der Abteilung 023 erfasst, da diese Abteilung primär für die Abwicklung aller Versicherungsverträge im Unternehmen verantwortlich ist.

Um die derart erfassten Kosten auf die verschiedenen Kundenprojekte Nr. 000009 bis 000012 (siehe den folgenden Screenshot) verteilt zu bekommen, wurde zunächst ein internes Kostenprojekt Nr. 000008 eingerichtet, auf dem die Kosten zunächst gesammelt werden.
Hinweis: Das interne Kostenprojekt wurde mit seiner eigenen Projektfinanzdimension Nr. 000008, sowie einer Verrechnungs-Abteilung Finanzdimension Nr. 099 eingerichtet.

Basierend auf diesen Einstellungen wurde im nächsten Schritt ein Projektausgabenjournal unter Nutzung der Kategorie „ALLOC INSURANCE” gebucht.

Hinweis: Die erwähnte Kategorie ist mit dem Sachkonto 606250 verknüpft, welche auf Projekte verrechnete Versicherungskosten erfasst.

Der im Rahmen dieser Buchung eingesetzte Buchungsbetrag entspricht dem Betrag, der uns von der Versicherungsgesellschaft ursprünglich in Rechnung gestellt wurde. Das hierbei verwendete Gegenkonto Nr. 679999 wurde als festes Gegenkonto im Projektausgabenjournal hinterlegt. Alternativ hätte natürlich auch von der Standardgegenkontofunktion im Projektmodul Gebrauch gemacht werden können. Die verwendeten Finanzdimensionen (Abteilung Nr. 099 und Projekt Nr. 000008) ergeben sich schließlich aus den auf Ebene des internen Kostenprojekts hinterlegten Finanzdimensionen.

Ergebnis dieser Buchung ist ein Beleg, welcher ein Versicherungsverrechnungskonto Nr. 606250 belastet und eine entsprechende Entlastungsbuchung auf dem Sachkonto 679999 durchführt.

Nachdem die Versicherungskosten auf diese Art dem internen Kostenprojekt belastet wurden, erfolgt im nächsten Schritt eine Verteilung dieser Kosten über die im Standard verfügbare Anpassungsfunktion. Zu Einzelheiten, siehe auch die folgenden beiden Screenshots.

Hinweis: Aus den vorstehenden Abbildungen kann man leicht entnehmen, dass die im Standard verfügbare Projektregulierungsfunktion als „Umlageinstrument“ verwendet wurde, um hierdurch die zunächst auf dem internen Kostenprojekt gesammelten Kosten auf die verschiedenen Projekte zu verteilen. Ein wesentlicher Nachteil dieser Standardfunktion besteht darin, dass hierbei der Verteilungsschlüssel manuell zu erfassen ist und sich diese Art der Umlage demnach nur für solche Fälle eignet in denen eine Kostenverteilung auf eine überschaubare Anzahl von Projekten erfolgt. Diesbezüglich ist anzumerken, dass über eine überschaubare Systemmodifikation die bereits im Standard verfügbare Verteilungslogik erweitert und voll automatisiert werden kann, um deren Einsatz auch auf solche Fälle hin auszuweiten in denen eine Kostenverteilung auf eine Vielzahl von Projekten zu erfolgen hat.
Alternativ hierzu bietet sich der Einsatz des Excel-add-in’s an, über welches die Umlagebuchungen unmittelbar auf die verschiedenen Projekte in Dynamics AX zugeordnet werden können.

Mit der Buchung der Kostenverteilung auf die unterschiedlichen Projekte erstellt Dynamics AX den folgenden Buchungsbeleg.

Um den gesamten Umlagevorgang besser nachverfolgen zu können, wurden in der nächsten Darstellung alle Buchungen zusammenfassend einander gegenübergestellt.

Der obenstehenden Buchungsdarstellung kann man entnehmen, dass die ursprünglich gebuchten Versicherungsaufwendungen nach wie vor auf dem ursprünglich verwendeten Sachkonto Nr. 606200 identifiziert werden können. Darüber hinaus kann man der Darstellung entnehmen, dass das Verrechnungskonto Nr. 606250, sowie die eingerichtete Verrechnungsabteilung Nr. 099 vollständig entlastet werden, so dass sich folgendes Bild in der Gewinn- und Verlustrechnung (GuV) ergibt:

Aus der obenstehenden nach Abteilungen und Projekten aufgegliederten GuV-Darstellung kann man zum einen entnehmen, dass alle Versicherungskosten auf Projekte verteilt wurden. Dies lässt sich sehr leicht an der in der farblich grün hervorgehobenen Spalte „SUM DEPT“ nachvollziehen, die in Summe betrachtet keinen Saldo mehr aufweist.
Zum anderen können in der obenstehenden Darstellung die insgesamt auf Projekte verteilten Kosten in der letzten – ebenfalls grün hervorgehobenen Spalte – identifiziert werden.

Beispiel 2: Verteilung von Lizenzkosten
An dieser Stelle haben sie sich vielleicht gefragt, warum die im vorherigen Beispiel dargestellte Buchung der Versicherungskosten nicht unmittelbar über das interne Kostenprojekt erfolgte? Innerhalb dieses zweiten Unterkapitels möchte ich diese Frage unter Verwendung eines weiteren Beispiels – der Verteilung von Lizenzkosten auf Projekte – beantworten.
Anders als im ersten Beispiel werden die Versicherungskosten nun unmittelbar auf dem internen Kostenprojekt Nr. 000008 unter der Verwendung einer eigenen Projektkategorie („License Costs“), wie im folgenden Screenshot dargestellt, erfasst.

Bitte beachten Sie dass die hier verwendete Beschaffungskategorie („License Fees“) mit der entsprechenden Projektkategorie („License costs“) verknüpft ist.

Nach Erfassung der Lizenzgebühren erfolgt nun im zweiten Schritt die Verteilung der auf dem internen Kostenprojekt gesammelten Kosten auf die verschiedenen Kundenprojekte Nr. 000010 bis 000012.

Die folgende Buchungsdarstellung fasst die im Rahmen dieses Beispiels generierten Sachkontobuchungen nochmals überblicksartig zusammen.

Ein wesentlicher Unterschied zur ersten Vorgehensweise besteht nun darin, dass sich die Buchungen, die auf der internen Verrechnungs-Abteilung Nr. 099 durchgeführt wurden gegenseitig ausgleichen. Dies hat zur Folge, Lizenzgebühren in Finanzauswertungen auf Ebene von Abteilungen nicht mehr unmittelbar im Detail nachverfolgt werden können. Die folgende Finanzaufstellung zeigt das eben Gesagte nochmals auf.

Beispiel 3: Umlage von Abschreibungsaufwendungen
Im dritten und letzten hier verwendeten Beispiel sollen nun Kosten, die nicht in unmittelbarem Zusammenhang mit Projekten stehen auf diese verteilt werden, um Projektleitern hierdurch einen Überblick über die tatsächlich angefallenen und von den verschiedenen Projekten zu tragenden Gesamtkosten zu ermöglichen.
Die hierfür erforderlich Vorgehensweise entspricht im Wesentlichen derjenigen, die bereits im Rahmen des ersten Beispiels dargestellt wurde. Der wesentliche Unterschied besteht hier nun allerdings darin, dass für die Verteilungsbuchungen statistische Konten verwendet werden, die nicht unmittelbar in Finanzauswertungen einfließen, welche externen Adressaten bereitgestellt werden.
Betrachten wir zunächst den ersten Prozessschritt, die Buchung der Abschreibungen im Anlagenmodul. Diese Buchung wird über das Aufwandskonto 607200 zusammen mit der Abteilung Nr. 024 durchgeführt, welche für das Management der entsprechenden Sachanlagen verantwortlich ist.

Im zweiten Schritt wird nun der Abschreibungsbetrag über ein Projektausgabenjournal auf das interne Kostenprojekt verteilt. Die hierbei verwendeten Projektkategorien und Journaleinstellungen sorgen dafür, dass die folgende Sachkontobuchung auf den statistischen Konten 907250 und 907251 durchgeführt werden.

Der dritte Schritt besteht nun wieder darin die derart auf dem internen Kostenprojekt gesammelten Kosten auf die externen Kundenprojekte – wie weiter oben bereits aufgezeigt– zu verteilen, …

…, so dass sich insgesamt die folgenden Sachkontobuchungen ergeben.

Die folgende Finanzaufstellung fasst die hierbei durchgeführten Buchungen nochmals überblicksmäßig zur besseren Nachvollziehbarkeit zusammen.

Der wesentliche Unterschied im Vergleich zum ersten Beispiel besteht nun darin, dass die in der obenstehenden Darstellung blau hervorgehobenen Zeilen nicht in solche Auswertungen einfließen, die externen Adressaten, wie Wirtschaftsprüfern, Finanzbehörden, Investoren, usw. bereitgestellt werden.

Zusammenfassung
Innerhalb dieses Beitrags habe ich Ihnen aufgezeigt, wie die Standard Projektregulierungsfunktion für die Verteilung (Umlage) von Kosten auf Projekten verwendet werden kann.
Ein wesentlicher Vorteil der hier aufgezeigten Vorgehensweise im Vergleich zu der indirekten Projektkostenfunktion besteht darin, dass sich diese Vorgehensweise für alle Arten von Kosten und nicht ausschließlich stundenbezogene Projektkosten einsetzen lässt.
Abschließen möchte ich mit der Anmerkung, dass die hier dargestellte Umlagefunktion sicherlich keine Optimal-Lösung i.S.e. vollautomatisierten Umlagetools darstellt. Nichtsdestotrotz stellen die Standard Projektmodulfunktionen eine gute Ausgangsbasis für die Implementierung einer vollautomatisierten Umlagefunktion dar, die speziell in solchen Unternehmen benötigt wird, in denen Kosten auf eine Vielzahl von Projekten zu verteilen sind.