NetSuite Beratung für Finance, Operations und Manufacturing.

Ein globaler Kontenrahmen, gemeinsam genutzt von allen Gesellschaften statt je Gesellschaft dupliziert, mit Zugriffssteuerung auf Gesellschaftsebene. Lokale statutorische Details — Kostenstellen, Funktionsbereiche, Steuercodes — werden über Dimensionen (Abteilung, Klasse, Standort, benutzerdefinierte Segmente) abgebildet, nicht über zusätzliche Sachkonten.

Das hält die Kontenstruktur schlank genug für eine saubere Konsolidierung, während Dimensionen so viel lokale Detailtiefe tragen, wie Controlling tatsächlich braucht.

Die Multibook-Buchhaltung von NetSuite bucht eine Transaktion einer Gesellschaft in mehr als einen Buchhaltungskreis — zum Beispiel einen lokalen statutorischen Kreis (HGB oder ein anderes lokales GAAP) und einen separaten IFRS-Kreis — mit kreis-spezifischen Regeln für Umsatzrealisierung, Abschreibung, Leasing oder Rückstellungen.

Beide Kreise teilen sich dieselben Transaktionen und denselben Kontenrahmen; sie weichen nur dort ab, wo die Rechnungslegungsstandards tatsächlich abweichen. Finance erfasst eine Transaktion nie zweimal, um den zweiten Zahlensatz zu erzeugen.

Intercompany-Transaktionen laufen über eine eigene Intercompany-Kontenstruktur und, in unseren Designs, über eine Verrechnungs-/Abgleichsebene, damit Differenzen während des Monats sichtbar und nachvollziehbar sind, statt erst zum Abschluss entdeckt zu werden.

Zum Periodenende wendet die Konsolidierung die Beteiligungsstruktur des Konzerns an — voll, quotal oder nach der Equity-Methode je nach Beteiligungsverhältnis — und eliminiert Intercompany-Salden und nicht realisierte Gewinne. Die Währungsumrechnung folgt den Regeln der funktionalen Währung jeder Gesellschaft, und die daraus resultierende Währungsumrechnungsrücklage (CTA) wird im Eigenkapital erfasst, nicht als Verrechnungsposten stehen gelassen.

Der Abschluss läuft entlang eines Kalenders mit Aufgabenabhängigkeiten: Gesellschaftsabschlüsse müssen vor dem Intercompany-Abgleich abgeschlossen sein, der Intercompany-Abgleich vor der Konsolidierung, die Konsolidierung vor dem Konzern-Reporting.

Funktionstrennung wird über das Rollen- und Berechtigungsmodell von NetSuite durchgesetzt — wer buchen darf, wer freigeben darf, wer einsehen darf — statt über manuelle Freigabelisten, und Freigabe-Workflows wenden Wesentlichkeitsschwellen an, sodass kleine Buchungen schneller durchlaufen als große oder ungewöhnliche.

In der Praxis lassen sich die meisten Verzögerungen auf drei Ursachen zurückführen: Intercompany-Differenzen, die erst spät auffallen, weil es keinen unterjährigen Abgleich gab; Konsolidierungsanpassungen, die händisch außerhalb des Systems vorgenommen werden; und Abschlussaufgaben ohne verbindliche Reihenfolge, sodass Gesellschaften in beliebiger Reihenfolge abschließen und die Konsolidierung auf die langsamste wartet.

Die Architektur zu korrigieren — Abgleich, Reihenfolge und Kreis-Design — behebt die Verzögerung, ohne zusätzliches Finance-Personal zu benötigen.

Stücklisten werden auf die Ebene modelliert, die der Shopfloor tatsächlich braucht — einschließlich Phantombaugruppen für Zwischenbaugruppen, die nie bestandsgeführt werden, sowie Kuppel- und Nebenprodukte, wenn ein Prozess mehr als ein Ergebnis liefert.

Arbeitspläne hängen die Arbeitsgänge, Arbeitsplätze sowie die Standard- Ausführungs- und Rüstzeiten an, die aus dieser Stückliste einen kalkulierten, planbaren Fertigungsauftrag machen — statt einer statischen Teileliste.

Standardkosten geben Controlling eine stabile Kalkulationsgrundlage für Planung und Preisbildung, mit Abweichungen (Preis, Verbrauch, Satz), die separat ausgewiesen werden, statt in den Ist-Kosten zu verschwinden. Wir setzen bei wiederholbarer Fertigung standardmäßig auf Standardkosten und nutzen Ist- oder Durchschnittskosten dort, wo das Ergebnis tatsächlich nicht wiederholbar ist — etwa bei auftragsbezogener Fertigung mit volatilen Einsatzpreisen.

Die Entscheidung fällt einmalig, in der Blueprint-Phase, weil ein Methodenwechsel mitten im Programm teuer wird.

Backflush-Verbrauch bucht Komponenten automatisch bei Abschluss eines Arbeitsgangs, auf Basis der Stückliste — passend, wo der Komponentenverbrauch vorhersehbar ist und der Erfassungsaufwand auf dem Shopfloor gering bleiben soll. Die manuelle Entnahme liefert explizite Sichtbarkeit auf Transaktionsebene — passend, wo Komponentensubstitution, Ausschuss oder Ausbeuteabweichung erfasst werden müssen, sobald sie auftreten.

Die meisten Fertigungskunden fahren eine Mischung, nach Artikel oder Arbeitsplatz, nicht eine einzige Regel für das ganze Werk.

MRP verrechnet den Bedarf gegen vorhandenen und bestellten Bestand, zeitphasiert die daraus resultierenden Bedarfe und versetzt sie um die Vorlaufzeit, um Planaufträge zu erzeugen, wobei Sicherheitsbestand Prognosefehler bei kritischen Artikeln abfedert.

Die Kapazitätsplanung mit endlicher Kapazität prüft diese Planaufträge dann gegen die tatsächliche Kapazität der Arbeitsplätze, statt unbegrenzten Durchsatz anzunehmen; wo ein Arbeitsplatz zum Engpass wird, wird dort der Plan angepasst, nicht auf Stücklistenebene.

Wir richten die Bewertungsmethode danach aus, was die Gesellschaft für statutorisches und Management-Reporting tatsächlich braucht: Standardkosten für Gesellschaften mit Standardkalkulation, Durchschnitts- oder FIFO-Bewertung, wo lokales GAAP es verlangt oder Standardkosten nicht tragfähig sind.

Die Bewertungsmethode ist eine Finance-Architektur-Entscheidung, mit Controlling und Wirtschaftsprüfung vor Go-live abgestimmt, kein ungeprüft übernommener Systemstandard.

Eine erste Gesellschaft wird nach einer Vorlage aufgebaut: Kontenrahmen, Dimensionsstruktur, Steuer- und Reporting-Logik. Jeder weitere Länder-Rollout nutzt diese Vorlage erneut und ergänzt nur die tatsächlich lokale Ebene — USt-/Intrastat-Meldewesen, SEPA-Zahlungsformate, DATEV-Export für die deutschen Gesellschaften, statutorische Formate anderswo — statt die Finance-Architektur pro Land neu zu entwerfen.

Das verhindert, dass ein Zehn-Länder-Rollout zu zehn getrennten Implementierungen wird.

NetSuite liefert zwei strukturierte Releases pro Jahr (zum Beispiel 2026.1 und 2026.2). Wir testen jedes Release in einer Sandbox gegen die Anpassungen des Kunden, bevor es in Produktion geht, und pflegen eine gezielte Release-Notes- Prüfung für Änderungen, die Finance- oder Manufacturing-Konfiguration betreffen.

Nichts erreicht die Live-Umgebung, ohne zuvor in der Sandbox gelaufen zu sein.

Über das Rollen- und Berechtigungsmodell von NetSuite — wer einen Lieferanten anlegen darf, wer eine Zahlung freigeben darf, wer eine Buchung erfassen darf — konfiguriert entlang der tatsächlichen Freigabematrix des Kunden, nicht nach einer generischen Vorlage.

Wir prüfen das Rollenmodell in der Blueprint-Phase gegen die tatsächlichen Kontrollanforderungen des Kunden (und die Erwartungen seiner Wirtschaftsprüfung), sodass Funktionstrennung durch das System durchgesetzt wird, statt sich darauf zu verlassen, dass niemand eigene Vorgänge freigibt.

Die Finance- und Manufacturing-Architektur-Entscheidungen aus der Blueprint-Phase werden dokumentiert, nicht nur implementiert — sodass die nächste Person, die das System betreut, ob wir selbst in der Hypercare oder ein internes Team danach, nachvollziehen kann, warum die Kontenstruktur, das Kreis-Setup oder die Kalkulationsmethode so aussehen, wie sie aussehen.

Diese Dokumentation ist auch das, was einen internationalen Rollout in die nächste Gesellschaft zu einer wiederholbaren Übung macht, statt zu einem Neu-Erfinden-Projekt.