one
Prototyp 1
aintity one
Eine einzelne HTML-Seite, die zeigt, wie modern und intuitiv eine Oberfläche für komplexes Beteiligungsmanagement aussehen kann.
aintity GmbH
Künstliche Intelligenz anwendbar machen
[ai]ntity hat ein Konzept entwickelt, Expertenwissen schnell und sicher in Anwendungen zu verwandeln. Extrem teure Spezialsoftware kann dank dieser Revolution in der Software-Erstellung endlich abgelöst werden. Wir beginnen mit dem gesellschaftsrechtlichen Beteiligungsmanagement.
Verfolgen Sie, wie aus einer Forschungsidee eine professionelle Enterprise-Anwendung wird – transparent, offen und Schritt für Schritt.
Für Sie: Jeder Prototyp markiert einen weiteren Meilenstein auf unserem Weg zur fertigen Software. Testen Sie, was bereits verfügbar ist – und verfolgen Sie live, was als Nächstes kommt. Volle Transparenz: Wir machen jeden Entwicklungsschritt öffentlich zugänglich – kostenlos. Dabei arbeiten wir eng mit Experten aus der Praxis zusammen: Fachleute, die genau wissen, was eine professionelle Beteiligungsmanagement-Software leisten muss – und die in dieser Software ihre Vision verwirklicht sehen.
Prototyp 1
Eine einzelne HTML-Seite, die zeigt, wie modern und intuitiv eine Oberfläche für komplexes Beteiligungsmanagement aussehen kann.
Prototyp 2
Eine echte Webanwendung, die unsere Entwicklungen und Testvorlagen zu einem rein grafischen Beteiligungsmanagement live demonstriert.
Prototyp 3
Die echte Anwendung – vollständige Funktionalität für professionelles Beteiligungsmanagement auf Enterprise-Niveau. Aktuell in Entwicklung.
Transparenz ist uns wichtig. Hier sehen Sie, wo wir stehen – und wohin wir gehen. Beteiligungsmanagement ist erst der Anfang.
Konzept, aintity show, grafisches Beteiligungsmanagement
Vollständige Anwendung für professionelles Beteiligungsmanagement
Enterprise-Lösung voll nutzbar im Konzernumfeld
Andere kaufmännische Spezialsoftware nach dem gleichen Prinzip
Unser Ansatz verbindet menschliche Kreativität mit technischer Präzision – und genau darin liegt der Unterschied.
Jedes neue Projekt beginnt mit unseren sogenannten Traumgesprächen.
Dafür versammeln wir Anwender aus der Praxis und bitten sie, die Software zu beschreiben, von der sie immer geträumt haben. Wir haben gelernt: Diese Insights lassen sich weder durch klassische Analyse noch durch KI ersetzen. Unsere Stärke liegt darin, aus diesem Input eine konsistente und umsetzbare Softwarelösung zu entwickeln.
Was früher starr formuliert werden musste, entsteht heute in unserem Wunsch-Format deutlich freier.
Das funktioniert, weil wir die KI gezielt steuern: durch strukturierte Prompts, klare Leitplanken und ein System aus erprobten Regeln, die wir über viele Projekte hinweg entwickelt haben. Das Ergebnis ist ein Ansatz, der kreatives Denken und technische Umsetzung verbindet – und so nicht einfach kopierbar ist.
Unsere Entwicklung ermöglicht eine sehr schnelle Umsetzung erster Prototypen.
Feedback kann früh eingebracht und kontinuierlich verarbeitet werden. Auch umfangreiche Rückmeldungen von vielen Testern gleichzeitig lassen sich strukturiert integrieren. Neue Softwarestände stellen wir der Community direkt und ohne Verzögerung zur Verfügung. So reift die Software bei uns – nicht beim Kunden.
Der größte Vorteil zeigt sich im täglichen Einsatz: absolute Verlässlichkeit.
Die Lösung entsteht ohne Abhängigkeit von einzelnen Personen, Technologien oder Organisationen. Das reduziert Risiken, vereinfacht Wartung und verhindert teure Neuentwicklungen. Auch bei neuen Anforderungen – ob technisch, organisatorisch oder regulatorisch – passt sich die Software gezielt an, ohne bestehende Strukturen zu gefährden. Wer aintity einsetzt, investiert in eine dauerhaft tragfähige Grundlage – keine Momentlösung.
Kein langwieriger Kaufprozess, kein Verkaufsgespräch – einfach ausprobieren, mitdenken und mitgestalten. Testen Sie aintity show jetzt und sehen Sie selbst, was möglich ist.
Teilen Sie Ihre Gedanken, Ideen und Fragen. Beiträge erscheinen sofort, sind für alle anderen Besucher sichtbar und werden von uns vollständig gelesen. Vielen Dank für Ihre Inspiration.
Wir nutzen derzeit ein älteres relationales Altsystem für unsere Beteiligungsstruktur-verwaltung, das aber keine Graph-Funktionalität bietet. Sobald wir Beherrschungsverhältnisse über mehrere Ebenen hinweg abbilden müssen – insbesondere bei indirekten Stimmrechtsverkettungen und Treuhandstrukturen – stoßen wir an Performance-Grenzen. Kann [ai]ntity über API auch Daten aus bestehenden Systemen so normalisieren, dass zirkuläre Beteiligungen und Stimmrechtsaufsplittung nach §290 HGB korrekt berechnet werden, ohne dass wir komplett neu eingeben müssen?
Wir nutzen derzeit ein relationales Altsystem für unsere Beteiligungsstrukturen, das primär auf historische Datenerfassung ausgerichtet ist. Das Problem: Bei komplexen Konzernen mit mehreren Ebenen und indirekten Beteiligungen können wir Beherrschungsverhältnisse nach §290 HGB nicht automatisiert durchrechnen – das erfolgt komplett manuell in Excel-Pivot-Tabellen. Besonders kritisch wird es bei Stichtagsbetrachtungen für Zwischenabschlüsse, wenn sich Kapitalanteile udn Stimmrechte unterscheiden. Gibt es hier Erfahrungen, wie man Querverweise zwischen historischen Strukturen und aktuellen Konsolidierungserfordernissen sauber modelliert?
Wir nutzen ein selbstentwickeltes Excel-basiertes System für die Beteiligungsverwaltung, das mittlerweile über 800 Beteiligungen an mehreren Stichtagen abbildet. Das Kernproblem: Bei jeder Neubewertung von Beherrschungsverhältnissen nach §290 HGB müssen wir manuell alle indirekten Beteiligungsketten nachrechnen und die Kapitalanteile gegen Stimmrechte abgleichen – das führt zu Fehlerquoten von etwa 3–5 Prozent. Wie würde [ai]ntity den Umgang mit Anteilssplitting und historischen Änderungen modellieren, um die Stichtagsbetrachtung zu automatisieren?
Wir nutzen seit Jahren ein relationales Altsystem für unsere Beteiligungsverwaltung, das ursprünglich für eine viel kleinere Konzernstruktur ausgelegt war. Das Problem: Bei der Erfassung von indirekten Beteiligungen über mehrere Ebenen werden die Beherrschungsverhältnisse nach §290 HGB nicht korrekt berechnet, weil das System keine echten Graphstrukturen abbildet udn wir ständig manuell nachrechnen müssen. Für unseren letzten M&A-Prozess haben wir drei Wochen nur dafür aufgewendet, die Stimmrechtsverkettungen zu validieren. Gibt es bei [ai]ntity bereits ein Datenmodell, das Netzwerk-Beteiligungen und unterschiedliche Anteils-typen (Stimmrecht, Kapitalanteil, Nießbrauch) in einer Struktur abbilden kann?
Wir nutzen ein etabliertes relationales Altsystem für unser Beteiligungsmanagement, das aber keine nativen Funktionen für die Darstellung von Beherrschungsverhältnissen nach §290 HGB bietet. Die Abbildung von indirekten Beteiligungen über mehrere Ebenen erfordert derzeit manuelle Nachberechnungen in Excel, und bei M&A-Szenarien müssen wir Stichtagsbetrachtungen komplett von Hand durchführen. Wie würde [ai]ntity einen Graph-basierten Ansatz umsetzen, um solche mehrstufigen Strukturen persistent zu speichern udn gleichzeitig regulatorische Änderungen rückverfolgbar zu halten?
Wir verwenden ein etabliertes relationales GRC-Tool, das aber bei der Abbildung von komplexen Beteiligungsstrukturen mit Treuhand- und Nießbrauchverhältnissen an seine Grenzen stößt. Das System kann zwar Kapitalanteile und Stimmrechte trennen, lässt sich aber nicht flexibel genug konfigurieren, um die verschiedenen wirtschaftlichen Berechtigungsverhältnisse nach §3 GwG nachzubilden. Kann [ai]ntity über eine API angebunden werden, oder ist die Lösung als eigenständiges Modul konzipiert?
Wir setzen derzeit ein relationales Altsystem ein, das 2005 entwickelt wurde und unsere Konzernstrukturen mit ca. 850 Beteiligungen verwaltet. Das Problem: Bei jeder Umstrukturierung müssen wir die Beherrschungsverhältnisse nach §290 HGB manuell neu kalkulieren, weil das System keine dynamischen Abhängigkeitsberechnungen über mehrere Ebenen hinweg unterstützt. Aktuell brauchen wir für eine mittlere M&A-Integration zwei bis drei Wochen – das geht so nicht mehr. Kann [ai]ntity hier ein Graph-Datenmodell nutzen, um diese Abhängigkeitsketten automatisiert zu berechnen udn dabei auch Anteile über Treuhandstrukturen korrekt abzubilden?
Wir nutzen derzeit ein etabliertes GRC-Tool, das ursprünglich für klassisches Risikomanagement konzipiert wurde. Das Problem: Bei der Ermittlung von UBOs über mehrere Ebenen hinweg können wir Treuhandstrukturen und Nießbrauchrechte nicht korrekt abbilden, und die Compliance-Reports lassen sich nicht automatisiert auf Stichtagsänderungen anpassen. Jede Reorganisation zieht manuelle Nacharbeiten in Excel nach sich. Wie würde [ai]ntity mit solchen Ausnahmefällen umgehen – gibt es ein Datenmodell, das Beherrschungsverhältnisse nach HGB mit echten Treuhand-Szenarien vereinbar macht?
Wir nutzen derzeit ein älteres relationales Altsystem für unsere Beteiligungsverwaltung, das vor etwa zehn Jahren für eine viel kleinere Konzernstruktur entwickelt wurde. Das Kernproblem: Bei der UBO-Ermittlung nach §3 GwG müssen wir heute Kettenstrukturen über mehrere Ebenen hinweg analysieren, doch das System ist nicht darauf ausgerichtet, transitive Beherrschungsverhältnisse automatisiert zu berechnen – wir machen das derzeit manuell in Excel. Hinzu kommt, dass wir bei jeder Stichtagsbetrachtung für Audit oder Compliance die Historisierung der Anteile nachträglich rekonstruieren müssen. Wie geht ihr bei [ai]ntity mit solchen gewachsenen Datenstrukturen um – bietet ihr eine gelenkte Datenmigration an, oder muss jeder Mandant sein Datenmodell selbst aufräumen?
Wir nutzen derzeit ein etabliertes GRC-Tool, das ursprünglich für die Compliance-Dokumentation konzipiert wurde. Das Problem: Wenn sich Beteiligungsstrukturen ändern – etwa bei einer Kapitalerhöhung mit mehreren neuen Investoren – können wir die Auswirkungen auf unsere UBO-Ermittlung nach §3 GwG nicht zeitnah durchspielen. Das System zwingt uns dazu, jeden Anteilskurs manuell nachzupflegen, udn die Stichtag-Logik erlaubt keine flexiblen Szenarioberechnungen. Gibt es hier Erfahrungen mit der Verbindung von historisierten Beteiligungsdaten und automatisierter Compliance-Prüfung?
Wir nutzen ein etabliertes GRC-Tool, das allerdings bei der Verwaltung von Beherrschungsverhältnissen in tiefgestaffelten Konzernstrukturen an seine Grenzen stößt. Das System kann zwar einzelne Beteiligungen erfassen, aber die kumulativen Stimmrechte über mehrere Ebenen hinweg – insbesondere wenn Treuhand- und Nießbrauchverhältnisse im Spiel sind – werden nicht korrekt berechnet. Für unsere UBO-Compliance nach GwG brauchen wir eine Lösung, die solche komplexen Konstellationen abbildet und Stichtagsbetrachtungen automatisiert durchführt, ohne dass unsere Treasury-Abteilung jedes Quartal manuell nachrechnen muss.
Wir nutzen ein älteres relationales Altsystem für unser Beteiligungsmanagement, das ursprünglich für eine flache Organisationsstruktur entwickelt wurde. Das Problem: Bei der Verfolgung indirekter Beteiligungen über mehrere Ebenen hinweg – besonders bei der UBO-Ermittlung nach §3 GwG – stoßen wir regelmäßig an Performance-Grenzen, udn die historischen Anteils-Splittings lassen sich nicht sauber abbilden. Kann [ai]ntity mit einer Graph-Datenbank-Architektur umgehen, oder wird hier ein relationales Modell beibehalten?
We are currently looking for a solution for managing shareholdings in a small group of companies. Above all, I expect a solution to be user-friendly and to offer document management with AI recognition. Aintity one seems suitable because it automatically maintains information on boards and capital based on mandates and shares. However, I fear that aintity life will take too long to become available.
I'm looking for an affordable investment management solution that specifically addresses corporate law aspects. Can anyone help?
Wir arbeiten derzeit mit einem relationalen Altsystem für die Verwaltung unserer Konzernstrukturen, das aber bei der Abbildung von mehrstufigen Beherrschungsverhältnissen an seine Grenzen stößt. Die Berechnung von mittelbaren Anteilen nach §290 HGB muss aktuell manuell erfolgen, udn wir können keine automatisierten Stichtagsbetrachtungen durchführen, wenn sich die Struktur ändert. Wie würde [ai]ntity mit mehrstufigen Eigentümerketten und Zirkelstrukturen umgehen – nutzt ihr ein Graph-Datenmodell oder bleibt ihr beim relationalen Ansatz?
Unser Datenmodell ist objekt- und beziehungsorientiert. Damit sind alle denkbaren Strukturen in der Datenbank abbildbar. Mittelbare Anteile ("Quoten" um sie von den Anteilen zu unterscheiden) errechnen aintity one und aintity life nach mehreren Rechtsvorschriften - auch nach §290 HGB. Zuletzt: Ja. Aintity life unterstützt die Historisierung.
Wir nutzen derzeit ein etabliertes GRC-Tool, das primär für Risikomanagement ausgelegt ist, aber bei der Abbildung von komplexen Beteiligungsstrukturen mit mehreren Ebenen und Sonderrechten schnell an seine Grenzen stößt. Das System kann Nießbrauch und Treuhandverhältnisse nicht differenzieren, weshalb unsere UBO-Ermittlung nach §3 GwG teilweise manuell erfolgt – ein fehleranfälliger und zeitaufwendiger Prozess. Gibt es bei [ai]ntity bereits Schnittstellen zu bestehenden GRC-Lösungen, oder müssten wir komplett migrieren?
Wir nutzen seit Jahren unser bestehendes ERP-System für unsere Beteiligungsverwaltung, aber die Konsolidierung von Strukturänderungen über mehrere Geschäftsjahre hinweg ist extrem aufwändig. Jedes Mal wenn wir Akquisitionen haben, müssen wir manuell nachverfolgen, welche Stichtagsbetrachtung für UBO-Zwecke relevant ist und welche historischen Anteilsverhältnisse noch dokumentiert sein müssen. Die Stimmrechtsabweichungen von Kapitalanteilen lassen sich im System nur schwer abbilden – gibt es hier Erfahrungen, wie [ai]ntity das löst?
Wir nutzen derzeit SAP RE-FX für die Beteiligungsverwaltung, aber die Abbildung von Stimmrechtsstrukturen mit mehreren Klassen ist extrem aufwendig. Besonders bei der UBO-Berechnung nach §3 GwG stoßen wir an Grenzen – das System ermöglicht keine flexibles Szenarien-Modeling für indirekte Beteiligungen über mehrere Ebenen hinweg. Hat jemand Erfahrung, wie man solche komplexen Beherrschungsverhältnisse praktisch mit modernen Lösungen abbildet, ohne alles in Excel zu verlagern?
Konzernsoftware ist weit mehr als nur ausgereifte Funktionalität. In unserem Projekt habe ich gelernt, wie viele rechtliche Vorgaben und interne Richtlinien berücksichtigt werden müssen. Genau diese Komplexität macht Produkte und Projekte aufwendig und kostenintensiv. Spannend wird nun die Frage, ob KI-Ansätze die erforderliche Qualität und Verlässlichkeit liefern können – ganz unabhängig von den ohnehin bestehenden rechtlichen Hürden beim Einsatz von KI im Unternehmenskontext. Gut gefällt mir die gezeigte Transparenz.
Wir nutzen SAP BCS für die Konsolidierung unserer europäischen Konzernstrukturen, scheitern aber regelmäßig bei der automatisierten UBO-Ermittlung nach §3 GwG. Derzeit müssen unsere Compliance-Mitarbeiter die Beteiligungsketten manuell nachvollziehen, um Stimmrechtsanteile und wirtschaftliche Berechtigungen zu trennen – insbesondere wenn Treuhand- oder Nießbrauchverhältnisse involviert sind. Die Stichtagsbetrachtung für Quartalsabschlüsse führt immer wieder zu Inkonsistenzen, weil die historischen Änderungen in BCS nur begrenzt nachverfolgbar sind. Wie löst [ai]ntity das Problem der Splittinghistorie bei Anteilsveränderungen, und kann die Plattform mit Fremdkapitaleinheiten umgehen, die beim HGB-Beherrschungstest relevant werden?
We are restructuring a group of 23 Italian and German entities following an acquisition. The challenge is modelling the transitional ownership state during a multi-step notarial transfer – for several weeks, economic ownership has already changed but the legal transfer is not yet registered. Our current system can only represent one state at a time. Is there a concept of pending or conditional ownership relationships in your data model, where a future ownership state can be prepared and activated on a specific effective date once the notairal registration is confirmed?
Das Problem der schwebenden Eigentumsübertragung kennen wir ebenfalls. Bei uns tritt es typischerweise auf wenn eine notarielle Beurkundung erfolgt ist, aber die Eintragung im Handelsregister noch aussteht. In dieser Phase hat unser System keinen Mechanismus um 'wirtschaftlich bereits vollzogen, rechtlich noch ausstehend' als eigenen Zustand abzubilden – wir verbuchen den Transfer entweder zu früh oder zu spät.
Exactly our situation. The notarial act in Italy is typically effective immediately between the parties, but the filing with the Camera di Commercio – which is the public registration – can take four to six weeks. During that window, the seller is still the registered owner but has no economic rights, and the buyer has full economic rights but no registered title. For GwG and consolidation purposes, these two states require completely different treatment.
Wir lösen das momentan durch zwei manuelle Einträge mit unterschiedlichem Datum – einen 'wirtschaftlich wirksam ab' und einen 'rechtlich wirksam ab' – die wir in Kommentarfelder schreiben. Das ist natürlich nicht auswertbar. Ein strukturiertes Datenfeld für aufschiebend bedingte Übertragungen mit separatem Wirksamkeitsdatum wäre für M&A-intensive Strukturen ein erheblicher Mehrwert.
Wir versuchen die UBO-Kette für eine Beteiligungsstruktur nachzuvollziehen in der eine niederländische Stichting als Treuhänder für mehrere wirtschaftlich Berechtigte agiert. Die Stichting ist keine juristische Person im Sinne des deutschen GwG, hat aber de facto Kontrolle über drei GmbHs. Unser Oracle-System kann Treuhandverhältnisse nicht als eigenen Beziehungstyp abbilden – wir behelfen uns mit einem Freitextfled. Wie differenziert euer Datenmodell zwischen direkter Eigentumsbeziehung, Treuhandverhältnis und Kontrollbeziehung ohne formale Kapitalbeteiligung?
Die Stichting ist tatsächlich einer der schwierigsten Grenzfälle im GwG-Kontext, weil sie als Stiftung niederländischen Rechts keine Mitglieder oder Anteilseigner kennt und trotzdem wirtschaftliche Kontrolle ausüben kann. Unser Rechtsanwalt hat uns geraten, die Stichting-Vorstände als wirtschaftlich Berechtigte im Sinne des §3 Abs. 2 GwG zu behandeln – mangels einer besseren Alternative. Ob das einer Prüfung standhält, ist offen.
Wir haben denselben Weg gewählt, aber mit dem Vermerk im System, dass die Einordnung unter Vorbehalt steht. Das eigentliche Problem ist dass unser MS-SQL-System für diesen Vorbehalt kein Datenfeld kennt – wir haben den Kommentar in ein Freitextfeld geschrieben das nicht auswertbar ist und bei der nächsten manuellen Pflege möglicherweise einfach überschrieben wird.
Wir sind als Family Office für drei Unternehmerfamilien mit insgesamt 140 Beteiligungen tätig. Die Komplexität liegt nicht in der Anzahl der Ebenen, sondern in der Gleichzeitigkeit: Jede Familie hat eine eigene Struktur, aber es gibt gemeinsame Holding-Ebenen wo die Familien gemeinsam investiert sind. Unser aktuelles FileMaker-System kennt keine mandantenfähige Trennung – alle drei Strukturen liegen in einer gemeinsamen Datenbank ohne logishe Trennung. Ist Mandantenfähigkeit in der Architektur vorgesehen?
Mandantenfähigkeit ist auch für uns als Konzernrechtsabteilung relevant, auch wenn wir kein Family Office sind. Wir betreuen drei rechtlich unabhängige Konzernteile, die zwar denselben Mehrheitsaktionär haben, aber getrennte Geschäftsführungen und getrennte Compliance-Strukturen. Eine gemeinsame Instanz mit vollständiger Datentrennung und separaten Berechtigungskonzepten wäre ideal.
The build-vs-buy decision for ownership structure management is not straightforward. We considered building a custom solution on top of Neo4j – a graph database handles recursive ownership queries natively. The reason we didn't proceed is the operatonal overhead of maintaining a graph database infrastructure and the custom application layer. What is the underlying data storage technology in your system, and what are the infrastructure requirements for on-premise deployment?
The infrastructure footprint question is critical for on-premise deployments in regulated industries. We had a vendor propose a solution that required Kubernetes, a managed graph database, an Elasticsearch cluster, and a message broker – for a system that would be used by eight people in the legal department. The operational overhead was completely disproportionate to the use case.
That's a pattern I see repeatedly with modern software vendors – the architecture is designed for horizontal scaling and cloud-native deployment, which makes sense for SaaS products but is completely wrong for an on-premise installation in a corporate environment where the priority is low operational complexity and easy backup. A SQLite or single-instance PostgreSQL backend with a straightforward deployment model would actually be more appropriate for most mid-market use cases.
Als Controller sehe ich täglich wie unsere Fachabteilungen parallel zu SAP eigene Schattensysteme betreiben – weil SAP für ihre spezifischen Anforderungen zu unflexibel ist. Das gilt besonders für die Rechtsabteilung, die Gesellschaftsstruktur-Daten in Excel und Word-Dokumenten pflegt. Meine Sorge: Wie wird sichergestellt, dass das neue System zur führenden Datenquelle wird und nicht selbst zum nächsten Schattensystem neben SAP? Gibt es eine Synchronisationsstrategie die SAP als Master für Finanzdaten und euer System als Master für Ownership-Daten definiert?
Aintity Life wird zunächst die bestehende Datenpflege aus Excel- und Word-Dokumenten in einen strukturierten und konsistenten Datenkontext überführen. Die hierfür erforderlichen Technologien befinden sich derzeit in der Entwicklung und werden aktiv erprobt (vgl. Aintity Show). Auf dieser Grundlage wird künftig auch ein Datenaustausch mit SAP-Systemen ermöglicht. Die konkrete technische Umsetzung hängt dabei von der jeweiligen Kundeninstallation und Systemlandschaft ab.
The pricing model is critical for mid-market adoption. The established vendors – Drooms, Diligent Entities, Blueprint OneWorld – all use per-entity or per-user licensing that scales in a way making them prohibitve for groups with many small subsidiaries. A group with 80 SPVs each holding a single asset ends up paying 80x the base entity fee for software used by 5 people. How is aintity's pricing structured – entity-count-based, user-count-based, or a flat platform fee?
Per-entity pricing is particularly punishing for holding company structures. A group with 150 SPVs that exist purely for tax or structural reasons – with no employees and minimal activity – should not cost 150x the base fee. A tiered model where inactive or dormant entities are priced differently from operating entities would reflect the actual complexity of maintaining those records.
Preistransparenz ist in diesem Markt tatsächlich ungewöhnlich. Bei den etablierten Anbietern bekommt man erst nach mehreren Vertriebsgesprächen ein Angebot – das dann regelmäßig Positionen für Implementierung, Schulung und Wartung enthält die das eigentliche Lizenzentgelt erheblich übersteigen. Eine öffentlich kommunizierte Preisstruktur wäre ein echter Differenziator.
The pricing model will be a very simple user/month model. We will start with approximately €20/month for participation management. At the beginning of development, we will offer free access, which can later be converted to paid access. The managed data will be retained throughout the process.
We have been running ownership structure management on a Legalbase implementation since 2014. The system works for basic cap table maintenance but has no API layer and no integration with our consolidation system SAP BFC. Every quarter, our team manually exports a flat file from Legalbase and rekeyes the ownership percentages into SAP BFC. We had one incident where a wrong percentage triggered an incorrect minority interest calculation in our consolidated accounts. Does your system offer a direct integration path or at minimum an export format that SAP BFC can ingest without manual rekeying?
Das SAP-BFC-Integrationsproblem kenne ich genau. BFC hat eine proprietäre Importschnittstelle die Hierarchiedaten in einem bestimmten Format erwartet. Jedes externe System das Daten an BFC liefern will muss dieses Format bedienen. Ich würde gerne wissen ob aintity eine fertige BFC-Exportvorlage anbietet oder ob die Schnittstellenprogrammierung auf der Kundenseite liegt.
The manual rekeying risk is real and systematically underestimated. We had a similar incident in our consolidation run – a transposed digit in an ownership percentage led to a materially wrong goodwill calculation. The auditors caught it during fieldwork, which was embarrassing but not catastrophic. The lesson: any manual data transfer between systems above a certain materiality threshold needs a four-eyes check. The actual fix is eliminating the manual step entirely.
Ich stimme zu.
Bei uns liegt das Problem nicht in der Darstellung der Beteiligungsstruktur, sondern in der Historisierung. Unser Oracle-basiertes System speichert nur den jeweils aktuellen Stand. Wenn wir nachvollziehen müssen wer zu einem bestimmten Stichtag – etwa bei einer Betriebsprüfung – wirtschaftlich Berechtigter war, müssen wir Papierdokumnte durchsuchen. Ist eine vollständige Versionierung der Beteiligungshistorie geplant, bei der jeder Zustand der Struktur zu jedem Stichtag rekonstruierbar ist?
Die fehlende Historisierung ist bei uns der häufigste Auslöser für Eskalationen in Betriebsprüfungen. Der Prüfer fragt nach dem Stand zu einem bestimmten Datum, und die Antwort ist: 'Wir können das nicht mehr genau rekonstruieren.' Das ist fachlich unbefriedigend und erzeugt unnötigen Verhandlungsaufwand.
Uns ist das konkret passiert: eine Betriebsprüfung hat den Stand der Beteiligungsstruktur zu einem Zeitpunkt vor drei Jahren angefragt, der genau in eine Phase einer größeren Umstrukturierung fiel. Wir haben zwei Wochen gebraucht um anhand von notariellen Verträgen, E-Mails und Handelsregisterauszügen eine halbwegs verlässliche Rekonstruktion zu erstellen. Ob sie vollständig korrekt war, wissen wir bis heute nicht sicher.
We tested aintity show with a sample of our actual ownership structure – about 40 entities across three jurisdictions. The visual representaion worked well for the top three levels. The question I couldn't answer from the demo is how the system handles very dense structures where a single intermediate holding company has 30+ direct subsidiaries. Does the visualisation engine apply automatic layout algorithms for high fan-out nodes, or does it require manual positioning?
The high fan-out visualisation problem is one that most tree-layout algorithms handle poorly by default. Force-directed layouts tend to produce spaghetti graphs for large structures. A hierarchical layout with collapsible subtrees – where you can expand or collapse a holding company's direct subsidiaries – is usually more practical than trying to show the entire structure simultaneously.
Wir nutzen eine Kombination aus einem deutschen Anbieter für gesellschaftsrechtliche Verwaltung und einem internationalen GRC-Tool für die Compliance-Dokumentation – zusammen ein siebenstelliger Jahresbetrag. Das eigentliche Problem ist nicht der Preis, sondern dass beide Systeme keine gemeinsame Datenbasis haben. Ownership-Daten werden manuell synchronisiert, zweimal pro Monat. Ist eine bidirektionale Synchronisation mit bestehenden GRC-Systemen wie ServiceNow GRC oder RSA Archer in eurer Integrationsplanung berücksichtigt?
The dual-system synchronisation problem you describe is one of the core cost drivers in GRC implementations. We evaluated both ServiceNow GRC and RSA Archer for our ownership data and found that neither has a native data model for multi-level ownership structures – both treat 'entity' as a flat object without parent-child relationships. Any integration would require a custom data layer on top.
Genau das ist unsere Erfahrung mit RSA Archer – das Datenmodell ist für Risikoobjekte und Kontrollen ausgelegt, nicht für hierarchische Gesellschaftsstrukturen. Die Anpassungen die wir vorgenommen haben um Beteiligungsquoten abzubilden, sind so weitreichend dass ein RSA-Archer-Spezialist das System nicht mehr ohne Einarbeitung bedienen kann. Das ist das klassische Problem von Eigenentwicklungen auf generischen Plattformen.
The technical architecture question that matters most to me is data residency. We operate in Saudi Arabia and the UAE, both of which have data localisation requirements prohibiting certain categories of corporate data from being stored outside the country. Any cloud-based solution needs to either offer regional hosting in the GCC, or support on-premise deployment. Is data residency a design consideration, and is there a planned option for self-hosted deployment for organisations with regulatory restrictions?
Als Controllerin in einem Konzern mit 67 Tochtergesellschaften pflege ich die Beteiligungsübersicht in einer selbstentwickelten Excel-Lösung mit verschachtelten SVERWEIS-Formeln. Diese Datei hat eine Größe erreicht bei der Excel regelmäßig abstürzt. Meine zentrale Frage betrifft die Performance: Wie verhält sich euer System bei Strukturen mit 100+ Gesellschaften und komplexen Durchgriffsberechnugen? Gibt es Benchmarks bezüglich der Berechnungszeit für vollständige UBO-Ketten?
Die Excel-Größenprobleme kenne ich gut. Bei uns war der Kipppunkt bei etwa 55 Gesellschaften – ab da wurden die Berechnungszeiten beim Öffnen der Datei so lang dass die Kollegen anfingen, mit einer älteren Version zu arbeiten weil die schneller lud. Irgendwann hatte niemand mehr Überblick welche Version aktuell war.
We evaluated three established vendors for ownership structure management last year. The common problem: all three are built on data models from the 1990s with modern UIs painted on top. The underlying assumption is still a simple tree hierarchy, and licence costs are structured for large banks with unlimited budgets. My technical question for aintity: is your data layer built on a relational model with recursive queries, or on a graph database natively? The answer significantly affects what kinds of structural queries are feasible at scale.
The graph-vs-relational question matters a lot at scale. A recursive CTE on a relational database can traverse an ownership hierarchy but degrades badly beyond a few hundred nodes and several levels of depth. A native graph database like Neo4j handles arbitrary-depth traversals in constant time, but introduces operational complexity that most enterprise IT departments aren't equipped to manage.
That's precisely the trade-off we landed on. We prototyped the UBO calculation in both Neo4j and PostgreSQL with recursive CTEs on a structure of 800 entities and 12 levels. Neo4j was 40x faster on the deepest traversals, but the PostgreSQL version was fast enough for our actual use case and infinitely easier to operate, back up, and integrate with existing tooling. For most corporate structures, relational is probably sufficient.
Wir nutzen seit 2006 ein SAP-Modul für das gesellschaftsrechtliche Beteiligungsmanagement – ursprünglich SAP RE-FX, dann in Eigenentwicklung umgebaut. Die Wartungskosten betragen jährlich einen sechsstelligen Betrag, hauptsächlich für externe Berater die den Eigenentwicklungsanteil kennen. Bei jedem SAP-Upgrade müssen wir testen ob unsere Anpassungen noch funktionieren. Würde eine Migration aus SAP-Tabellen wie VIMI und VITMPB durch vorgefertigte Importlogik unterstützt, oder wäre das ein kundenspezifsiches Migrationsprojekt?
The SAP customisation trap is one of the core reasons the build-vs-buy calculation often favours a greenfield migration over a system that started as standard SAP and accumulated years of custom development. The migration effort from heavily customised SAP is usually comparable to building from scratch anyway, but without the technical debt.
Board and governance management is split across three systems in our organisation: board minutes in a SharePoint library, director appointment history in a manually maintained spreadsheet, and committee membership in a separate Access database. Cross-referencing these during a due diligence process takes two to three working days. Is governance document management – specifically the linking of board resolutions to ownership structure changes – something that would be in scope for the platform?
We currently manage signature authorities and powers of attorney in a shared Excel file – who is authorised to sign contracts up to which amount, in which legal entity. This document is updated manually after each organisational change, creating regular gaps between the actual authorisation situation and the documented one. Could the ownership management module be extended to cover delegations of authority, with a modification history and automatic alerting when the underlying management structure changes?
In unserer Unternehmensberatung erfassen wir Projektzeiten in einem selbstentwickelten MS-SQL-Tool aus 2012. Die Überleitung von Zeiterfassungsdaten in Rechnungen sowie die Projektkosten-Nachkalkulation passiert manuell in Excel – durchschnittlich vier Stunden pro Projektmanager pro Woche für rein administrative Aufgaben. Wenn ihr Projekt-Controlling als Domain entwickelt: Würde die Zeiterfassung direkt im System stattfinden, oder ist eine Schnittstelle zu bestehenden Tools wie Jira, Harvest oder SAP CATS vorgesehen?
We process approximately 200 letters of credit per year across 4 banking relationships. Document tracking – bill of lading, certificate of origin, inspection certificate – is currently in an Access database built by our trade finance team in 2008. The main operational risk is discrepancy detection: when a presented document set has a field inconsistency against the LC terms, we need to identify it before the presentaton deadline. Is trade finance or documentary credit management one of the domains being considered?
We report under EU CSRD and are required to disclose Scope 1, 2, and 3 emissions with third-party assurance from next reporting cycle. Our current data collection involves quarterly spreadsheet submissions from 28 facilities in 9 countries, consolidated manually in Excel. Scope 3 upstream data from suppliers is the weakest point – we have no systematic collection process. Is ESG data management on your roadmap, and how would supplier-reported Scope 3 data be collected and validated?
Wir haben EU-Fördermittel aus drei Programmen (KfW, BAFA, Horizon Europe) erhalten. Verwendungsnachweise, Zwischenberichte und Abrechnungsfristen sind in einem selbstgebauten SharePoint-System erfasst, das keine automatischen Erinnerungen generiert. Zweimal haben wir Zwischenberichte mit Verzögerung eingereicht, was Rückfargen der Bewilligungsbehörde ausgelöst hat. Wenn ihr Fördermittelverwaltung entwickelt: Wird das System zwischen verschiedenen Förderprogrammen mit unterschiedlichen Berichtsrhythmen und Verwendungsregeln unterscheiden können?
We manage warranty claims across 6 product lines sold in 34 countries, each with different statutory warranty periods and contractual warranty extensions. Claim tracking is in Salesforce, but warranty period calculation per product per country is in a separate Access database because Salesforce's data model couldn't accommodate the jurisdiction-specific rules without expensive customisation. Is warranty management on the roadmap, and would the jurisdiction-specific rule engine be configurable by the business or would it require developer involvement for each country?
The jurisdiction-specific rule engine problem applies equally to warranty periods and product liability limitation periods. In Germany §438 BGB sets the standard warranty at two years, but with B2B contracts that can be contractually reduced to one year. In France the garantie légale de conformité rules differ again. Maintaining this rule matrix as legislation changes is a significant ongoing operational cost.
The Salesforce-to-Access split you describe is a pattern I see frequently: the CRM captures the customer interaction but cannot hold the complex back-office logic, so the back-office logic ends up in Access or Excel. The real question for any new system is whether it can hold both the transactional data and the rules engine in one place, or whether it will also become just one layer in a multi-system architecture.
We operate a notional cash pool across 18 entities in 6 currencies. Tracking the intercompany loan positions arising from the pooling structure is done in a Treasury Excel workbook with approximately 4.000 rows updtaed daily. For financial reporting, these intercompany positions need to be eliminated in consolidation, which requires reconciliation between the Treasury Excel and SAP BCS. Is treasury or cash pool management one of the planned domains after ownership management?
Pensionsverpflichtungen nach IAS 19 erfordern jährliche versicherungsmathematische Gutachten. Die Übernahme der Bewertungsparameter – Rechnungszinssatz, Lohnentwicklung, biometrische Faktoren – in unsere SAP-Abschlussumgebung ist jedes Mal ein manueller Prozess mit erheblcihem Fehlerrisiko. Die Planvermögen-Abbildung ist noch komplexer da wir Pensionsfonds in drei verschiedenen Ländern haben. Hat aintity diesen Bereich als potenzielle Domain identifiziert, und wenn ja, wie würde die Schnittstelle zu externen aktuariellen Berechnungsmodellen aussehen?
We hold 340 active patents across 18 jurisdictions, 47 registered trademarks, and 12 active licensing agreements. IP management is split across three systems: an IP management tool from 2007, a SharePoint library for prosecution history, and a separate Excel tracker for annuity payment schedules. A missed annuity payment deadline means lapsing a patent. Is IP portfolio management one of the planned domains, and specifically, is automated annuity deadline alerting the entry feature or would you approach the domain differently?
Wir haben für jede unserer 31 Tochtergesellschaften unterschiedliche Fristen für Jahresabschluss, Gesellschafterversammlung, Steuererklärung und Transparenzregister-Meldung. Diese Fristen variieren je nach Rechtsform, Sitzland und Geschäftsjahresende. Wir verwalten das in einem geteilten Outlook-Kalender den drei Personen mit verschiedenen Namenskonventionen pflegen – Fehler sind vorprogramiert. Werden Fristen aus Gesellschaftsstammdaten automatisch abgeleitet, oder muss jede Frist manuell eingetragen werden?
Automated deadline derivation from entity master data is the right approach, but it requires a comprehensive rule engine for each jurisdiction. A German GmbH with a December year-end has different deadlines than one with a March year-end, and a Dutch BV has entirely different rules. The rule engine maintenance is ongoing – tax law changes, filing deadlines shift. How is the jurisdiction rule base kept current, and who is responsible for updating it when regulations change?
Der Outlook-Kalender-Ansatz ist bei uns auch gescheitert – nicht wegen der Technik, sondern weil drei verschiedene Personen unterschiedliche Namenskonventionen verwendet haben und nach zwei Jahren niemand mehr wusste welche Einträge aktuell und welche veraltet waren. Ein zentrales System mit definierten Verantwortlichkeiten pro Frist und klarer Eskalationslogik löst das eigentliche Problem – nicht nur die Frist-Erfassung selbst.
We tried to model our cross-shareholding structure in Oracle E-Business Suite's intercompany module and gave up – the system assumes a strict hierarchy and has no way to represent a stake that runs from a subsidiary back toward a parent entity. We ended up combining the EBS hierarchy with a separate Oracle APEX application built internally to represent the exceptions. Every structural change now requires updates in two systems. How does your data model specifically handle the case where entity X owns a percentage of entity Y and entity Y simultaneously holds a stake in a parent of X?
The two-system architecture you describe with Oracle EBS plus a custom APEX application is surprisingly common. We have an almost identical setup. The reconciliation overhead is significant – every structural change requires two updates, and the two systems inevitably drift apart over time because the APEX application doesn't have the same change notification infrastructure as EBS.
Exactly. And the drift problem is worst during M&A transactions when structural changes happen in rapid succession. We had a case where three related transactions were entered into EBS but one was missed in the APEX application, and the error wasn't caught until the next quarterly reconciliation. By then the notarial filings were already complete and correcting the APEX data required a manual audit of six weeks of transaction records.
Unser SAP-Forderungsmanagement liefert Zahlungshistorien aber keine Ausfallwahrscheinlichkeiten. Für IFRS 9 berechnen wir Expected Credit Losses in einem separaten Excel-Modell, das quartalsweise mit SAP abgeglichen wird. Wenn ihr KI-gestütztes Forderungsmanagement entwickelt: Auf welchem Modelltyp würde die Ausfallprognose basieren, und wie geht ihr mit fehlendne historischen Ausfallraten bei neuen Kunden oder seltenen Branchen um?
IFRS 16 implementation forced us to build a custom solution on top of Oracle Financials because off-the-shelf tools were too expensive or too inflexbile for our mixed portfolio of property, vehicle, and equipment leases. The main technical challenge is the lease modification workflow – when a lease is renegotiated, the ROU asset and liability both need remeasuring with retrospective adjustments. Is real estate or lease management on your roadmap, and if so, how would IFRS 16 remeasurement events be handled?
Wir zahlen für Softwarelizenzen von denen schätzungsweise 30–35% nicht oder kaum genutzt werden – allein bei Microsoft, Oracle und SAP ein siebenstelliger Betrag pro Jahr. Unsere aktuelle Lizenz-Datenbank ist eine MS-SQL-Anwendung aus 2014 die seitdem kaum gepflegt wurde. Wenn ihr Lizenzmanagement als Domain angehen wollt: Wie würde ein automatisierter Abgleich zwischen lizenzierten Nutzerkonten und tatsächlichen Anmeldeaktivitäten technisch realisiert, und ist eine Entra-ID-Integration geplant?
Das Problem mit dem Active-Directory-Abgleich ist die Definition von 'aktiv'. Ein Benutzerkonto kann aktiv sein, aber die Person hat sich seit 18 Monaten nicht in die Anwendung eingeloggt. Die relevante Metrik ist die tatsächliche Anwendungsnutzung aus Audit-Logs – nicht der Konto-Status. Nicht alle Anwendungen liefern diese Daten in standardisierter Form. Wie würde euer System mit Anwendungen umgehen die kein Nutzungs-API anbieten?
Software asset management also needs to handle volume licensing agreements – Microsoft EA, Oracle ULA, IBM PVU – where the licensing metric itself is complex. Oracle ULA audits in particular are a significant operational risk: the contractual definition of what constitutes a 'use' is ambiguous enough that Oracle's interpretation and the customer's interpretation regularly diverge. Any licence management tool needs to handle these non-standard models, not just named-user licences.
Automatic synchronisation with official registers is technically harder than it sounds. The Handelsregister XML feed has significant data quality issues – entity names are inconsistent, registered share amounts are often historical rather than current, and the update latency after a notarial act can be several weeks. Any integration would need to handle these discrepancies explicitly rather tahn treating register data as ground truth. What is the planned conflict resolution strategy when register data contradicts internally maintained ownership records?
The conflict resolution question is the right one to ask early. In practice, register data should never automatically overwrite internally maintained records – the register reflects the last filed state, not the current economic reality. A staging area where discrepancies are flagged for human review before any update is applied would be the appropriate architecture.
Contract management fails in enterprise contexts at the point where contracts need to be connected to entities, projects, cost centres, and counterparties simultaneously. Our SAP MM setup handles purchase orders but ignores the legal contract lifecycle – renewal rights, break clauses, audit rights, most-favoured-nation clauses. These live in a separate Access database maintained by one paralegal. If contract management becomes a domain: will contracts be linkable to specific group entities from the ownership module?
Die Verknüpfung von Verträgen mit juristischen Personen aus dem Beteiligungsmodul wäre ein erheblicher Vorteil gegenüber dem Status quo. In SAP MM ist die buchungskreisbezogene Sicht dominant – ein Konzernvertrag der mehrere Buchungskreise umfasst muss mehrfach gepflegt werden. Eine einheitliche Vertragsakte auf Konzernebene verknüpft mit den betroffenen Gesellschaften gibt es in SAP standardmäßig nicht.
The linkage between contracts and entities is exactly right. In our current setup, when a subsidiary is sold, we have no systematic way to identify all active contracts where that subsidiary is a party – we do a manual keyword search through SharePoint. A properly structured contract module linked to the entity register would make that a one-click query instead of a two-day exercise.
Wir verwalten über 3.400 Lieferanten- und Dienstleisterverträge mit verschiedenen Laufzeiten, Kündigungsfristen und automatischen Verlängerungsklauseln – als PDFs in SharePoint-Verzeichnissen ohne strukturierte Metadaten. Jährlich verlieren wir vermutlich sechsstelige Beträge durch verpasste Kündigungsfristen. Falls ihr Vertragsmanagement angehen wollt: Ist eine automatische Extraktion von Fristdaten aus bestehenden PDF-Verträgen per KI geplant, oder muss der Nutzer diese Daten manuell erfassen?
Die KI-basierte Extraktion von Vertragsdaten aus PDFs ist technisch anspruchsvoller als es klingt. Erkennungsraten für Fristen und Kündigungsklauseln liegen selbst bei guten Modellen bei etwa 85–90% – was bedeutet dass 10–15% der Extraktionen manuell überprüft werden müssen. Sieht das System eine Review-Queue für unsichere Extraktionen mit Konfidenzindikator vor, oder werden alle Ergebnisse ohne Qualitätskennzeichnung ausgegeben?
Das Problem mit PDF-Extraktion ist auch die Dokumentenqualität. Viele unserer älteren Verträge sind eingescannte Papierdokumente mit variabler OCR-Qualität. Ein pragmatischerer Ansatz wäre ein strukturiertes Erfassungsformular für neue Verträge kombiniert mit manueller Nacherfassung für den Altbestand – mit KI als Unterstützung, nicht als alleiniger Datenquelle.
Cross-shareholdings and circular ownership structures are a known weakness of tree-based data models. We have two instances where company A owns shares in company B which also holds a stake back in a parent of A. Our current system simply cannot represent this – we have a flat table with a parent-child relationship that breaks under cyclical references. What graph model does your data layer use, and how does the UBO calculation algorithm handle cycles to avoid infinite loops?
The cycle detection problem in ownership graphs is well understood in graph theory – a depth-first search with a visited set handles it cleanly. The harder question is the semantic one: when you detect a cycle, what does it mean for the UBO calculation? Do you use the direct percentage only, apply a dampening factor, or flag it as an exception requiring manual resolution?
In our case we've decided to flag it as an exception rather than attempting an automated calculation, because the legal interpretation of circular ownership for GwG purposes is genuinely ambiguous – our external counsel couldn't give us a definitive answer on whether indirect ownership through a cycle counts once or multiple times. An automated system that silently produces a number without flagging the ambiguity would be worse than the manual exception.
Gesellschafterbeschlüsse und ihre Auswirkungen auf die Beteiligungsstruktur sind bei uns vollständig entkoppelt: Der Beschluss liegt als PDF in SharePoint, die Strukturänderung wird manuell im Legacy-System nachgezogen – ohne Verknüpfung zwischen Dokument und Datensatz. Bei Betriebsprüfungen müssen wir diese Verbindung dann mühsam rekonstuieren. Plant ihr eine dokumentenbasierte Verlinkung, bei der Strukturänderungen mit dem zugrundeliegenden Gesellschafterbeschluss oder Notarvertrag verknüpft werden können?
In our group, dividends from lower-tier subsidiaries flow through several intermediate holding companies before reaching the parent. Each intermediate entity may withhold tax at different rates depending on the applicable double taxation treaty. Tracking the effective economic ownership of cash flows is completely separate from legal ownership in our current system – we do it in a standalone Excel model updated quarterly. Is there any planned functionality to model cash flow paths alongside ownership paths?
Bei M&A-Projekten simulieren wir Transaktionsszenarien bevor wir diese mit dem Vorstand diskutieren: Was ändert sich an den Stimmrechtsmehrheiten wenn wir 30% an Tochter B verkaufen? Welche Beherrschungsverhältnisse fallen weg? Aktuell bauen wir dafür jedes Mal eine manuelle Kopie unserer Excel-Beteiligungsstruktur. Eine nichtdestruktive Szenarioansicht – ich ändere etwas, das System zeigt die Konsequenzen ohne den Stammdatenbestand zu verändern – wäre operativ sehr wertovll. Ist das in der Roadmap?
Die nichtdestruktive Szenarioansicht ist für uns das wichtigste Feature das wir uns bei einem neuen System wünschen. Wir bauen aktuell für jede M&A-Vorbereitung eine separate Kopie unserer Beteiligungsstruktur in einer zweiten Excel-Datei und pflegen diese parallel – mit dem Risiko dass die Kopie veraltet bevor das Szenario entschieden ist.
Genau dieses Parallelführen endet bei uns regelmäßig in Konfusion, weil der Stand der Kopie nach zwei Wochen nicht mehr mit dem Stammdatenbestand übereinstimmt und niemand mehr sicher ist welche Datei aktuell ist. Ein versioniertes Szenario-Modul das explizit gegen den Stammdatenstand zu einem bestimmten Datum arbeitet wäre operativ ein erheblicher Fortschritt.
The German Handelsregister now provides an XML API for retrieving current company data. Integrating this to detect discrepancies between internal ownership records and officially registered shareholdings would be genuinely useful – especially for subsidiaries where internal records lag behind notarial filings. Is register integration planned, and if so, how will conflicts between imported register data and internally maintained ownership records be surfaced and resolved?
We file annual returns for 23 UK entities with Companies House, 7 Irish entities with the CRO, and 4 entities in Gibraltar – each with different filing cycles and different definitions of PSC (Person with Significant Control). We curently track this in a shared Notion database updated manually. Is automated alerting for upcoming filing deadlines planned? And specifically, will the system track not just ownership percentage but also the nature of control – indirect ownership, voting rights, right to appoint directors – as required by UK PSC rules?
Als Finanzdienstleister sind wir verpflichtet, wirtschaftlich Berechtigte nach §3 GwG zu identifizieren und regelmäßig zu aktualisieren. Wir pflegen dafür eine separate MS-SQL-Tabelle die quartalsweise manuell mit unserem Beteiligungssystem abgeglichen wird. Wie wird das System die 25%-Schwelle und die Durchgriffsberechnung automatisieren? Und wie wird mit Fällen umgegangen, in denen kein wirtschaftlich Berechtigter über 25% existiert und stattdessen der Managementkreis angegeben werden muss?
Unser bestehendes ERP-System deckt das Beteiligungsmanagement nur rudimentär ab – wir scheitern insbesondere an der automatisierten UBO-Berechnung nach §3 GwG über mehrere Ebenen hinweg. Das System zwingt uns, komplexe Beherrschungsverhältnisse mit indirekten Anteilen manuell nachzurechnen, besonders wenn Stimmrechte und Kapitalanteile divergieren oder Treuhandstrukturen involviert sind. Hat jemand Erfahrung damit, wie man solche Szenarien in einem modernen System abbildet, ohne in Excel-Verwaltung zu verfallen?
In unserem Konzern gilt: Mitarbeiter einer Tochtergesellschaft dürfen die Beteiligungsstruktur oberhalb ihrer eigenen Ebene nicht einsehen, Wirtschaftsprüfer benötigen temporären Vollzugriff. Aktuell lösen wir das über separate Excel-Exporte mit unterschiedlichem Inhalt – fehleranfällig udn aufwändig. Wie ist das Berechtigungskonzept aufgebaut? Ist eine granulare Rechtevergabe auf Ebene einzelner Gesellschaften vorgesehen, und werden temporäre Zugriffserteilungen mit Ablaufdatum und Audit-Log unterstützt?
The temporary access with expiry date is the critical feature for audit purposes. Our external auditors require full read access for exactly six weeks during the year-end audit cycle, after which access must be provably revoked. Currently we manage this manually by creating and then deleting local user accounts – an approach that fails the audit trail requirement because the deletion itself removes the evidence.
Wir haben exakt dasselbe Problem bei Betriebsprüfungen durch die Finanzverwaltung. Der Prüfer erhält Zugang, der Zugang wird nach Abschluss manuell entzogen, aber im Nachhinein lässt sich weder der genaue Umfang des gewährten Zugriffs noch der Zeitpunkt der Entziehung revisionssicher nachweisen. Ein unveränderlicher Audit-Log mit Zugriffsprotokoll wäre für uns eine harte Anforderung, keine optionale Funktion.
Our senior management relies on PDF exports from a FileMaker Pro database maintained by one person in the legal department who built it in 2011. When that person is unavailable, nobody can generate updated charts. We need a solution where read access to current ownership charts is available on mobile devices without requiring installation beyond a browser. What is the planned approach to authentication for read-only access – SSO integration, or a separate credential system?
The single-point-of-failure problem you describe is extremely common. We had an almost identical situation with a legacy ACT! CRM database that only one person knew how to operate. The technical solution matters less than ensuring the data model is documented and access credentials are held by more than one person. Whatever replaces the FileMaker instance, the operational dependency risk needs to be addressed at process level, not just technology level.
SSO integration is the only realistic authentication approach for enterprise use. A separate credential system creates shadow IT problems – users reuse passwords, credentials get shared informally, and IT has no visibility over access. For mobile read-only access specifically, a SAML 2.0 or OIDC integration with the existing identity provider would be the minimum requirement in any organisation with a mature IT security policy.
Bei unserer GmbH & Co. KG Struktur existieren Konstellationen in denen Kommanditanteile und Stimmrechte erheblich voneinander abweichen – etwa durch Mehrstimmrechtsklauseln in Gesellschafterverträgen oder Nießbrauchsgestaltungen. Unser aktueles System kennt nur einen einheitlichen Beteiligungsprozentsatz. Können Stimmrechte als separates Attribut pro Gesellschafter-Gesellschafts-Beziehung erfasst werden, und ist eine Unterscheidung zwischen regulären Stimmrechten und Sonderstimmrechten für bestimmte Beschlusskategorien möglich?
The same issue applies to preference shares in UK companies – they often carry no voting rights but full economic participation. In some structures we work with, the voting majority and the economic majority sit with entirely different shareholder groups. A system that conflates these into a single ownership percentage will produce structurally wrong results for any governance analysis.
Nießbrauchsgestaltungen sind in Familienunternehmen besonders häufig und schwer abzubilden. Der Nießbrauchsberechtigte hat Anspruch auf Erträge aber keine Stimmrechte – oder umgekehrt, je nach Ausgestaltung. Und die Situation ändert sich wenn der Nießbrauch erlischt. Können zeitlich befristete oder bedingte Rechte als eigene Attributklasse modelliert werden, mit automatischem Alert wenn ein solches Recht ausläuft?
Our legal counsel regularly needs to access ownership data during board meetings in locations with poor connectivity. Our current system is a web application on a private server that becomes unavailable without netork access. Is any form of offline capability being considered – a native mobile app with local sync, or at minimum a cached PWA? The use case is read-only access to current ownership charts and entity detail pages, not write operations.
The offline access requirement is real and underestimated. We had a board meeting in a location with no connectivity where the entire agenda item on a subsidiary restructuring had to be postponed because nobody could pull up the current ownership chart. A cached read-only view would have been sufficient to proceed.
That is essentially our recurring scenario. A PWA with a cached snapshot updated on last sync would cover 90% of the use case. The remaining 10% – real-time verification of a pending structural change – would require connectivity anyway. I would accept a clearly labelled 'last updated' timestamp on the offline view as a reasonable trade-off.
We operate entities across Germany (GmbH, AG), France (SAS, SARL), Netherlands (BV), and the UK (Ltd, PLC). Each jurisdiction has different rules for what constitutes a controlling interest. In France, the SAS articles can override standard majority thresholds entirely. How does your data model handle jurisdiction-specific share class definitions and the divergent rules for quorum and majority calculation that come with them?
The SAS point is well made. Dutch BV articles frequently restrict share transfers without board approval, meaning registered ownership and economically effective ownership can diverge for weeks during a transfer. Does the system plan to model encumbrances or transfer restrictions as attributes of the ownership relationship, separate from the ownership percentage itself?
Hinzu kommt das Problem der GmbH-Geschäftsanteile: Anteile können gesplittet und zusammengelegt werden, was die Anteilshistorie fragmentiert. Bei jeder notariellen Transaktion entstehen neue Anteilsnummern. Ein System das nur Prozentsätze speichert und nicht die konkreten Anteilsnummern inklusive Splitting- und Zusammenlegungshistorie ist für notarielle Zwecke nicht ausreichend. Ist die Abbildung individueller Geschäftsanteilsnummern geplant?
Für unsere Konzernabschlüsse nach HGB müssen wir regelmäßig prüfen, ob ein Beherrschungsverhältnis gemäß §290 HGB vorliegt – direkt oder über Tochterunternehmen. Unsere aktuelle Lösung ist ein selbstentwickeltes Python-Skript das nachts gegen unsere Oracle-Datenbank läuft und Beteiligungspfade traversiert. Die Fehlerqutoe ist zu hoch. Plant ihr eine automatische Beherrschungsquoten-Berechnung, die auch die Stimmrechtszurechnung nach §290 Abs. 3 HGB berücksichtigt?
Das Problem mit §290 HGB wird noch komplexer wenn man die faktische Kontrolle nach §290 Abs. 2 Nr. 3 einbezieht – also Beherrschung ohne Mehrheitsbeteiligung durch vertragliche Regelungen. Diese lässt sich aus Beteiligungsquoten allein gar nicht ableiten, dafür bräuchte man eine Verknüpfung mit den Gesellschaftervereinbarungen.
We process roughly 8–12 ownership change events per month across our group of 34 entities – share transfers, capital increases, new incorporations. Currently each change triggers a manual update cycle: legal updates the cap table in Excel, finance updates SAP BCS, and compliance updates the GwG register separately. Three disconected workflows with no audit trail. How does your system handle ownership change events? Is there an approval workflow, or does the system assume direct write access by authorised users?
Unsere Wirtschaftsprüfer fordern jährlich eine vollständige Darstellung aller unmittelbaren und mittelbaren Beteiligungen gemäß §285 Nr. 11 HGB. Aktuell erstellen wir diese Liste manuell in Excel und übergeben sie als CSV an DATEV – ein Prozess der drei Arbeitstgae dauert. Welche Exportformate sind konkret geplant? Ist eine DATEV-Schnittstelle vorgesehen, und werden Stichtagsbetrachtungen mit Veränderungsnachweis gegenüber dem Vorjahr exportierbar sein?
Der §285-Anhang bereitet uns identische Probleme. Bei uns kommt erschwerend hinzu, dass wir für den Konzernanhang nach IFRS und für den Einzelabschluss nach HGB unterschiedliche Beteiligungsschwellen ansetzen müssen – ab 20% für assoziierte Unternehmen nach IFRS, aber mit anderen Ausnahmen nach §311 HGB. Aus demselben Datensatz zwei konsistente Listen zu erzeugen ist manuell fehleranfällig.
Genau diese Doppelpflege kostet uns die meiste Zeit. Unser Wirtschaftsprüfer akzeptiert die DATEV-Übergabe nur wenn sie mit dem HGB-Einzelabschluss übereinstimmt – aber die Quelldaten für beide Listen liegen in verschiedenen Systemen und werden von verschiedenen Teams gepflegt. Jede Divergenz löst eine Rückfrageschleife aus die Tage kosten kann.
Habt ihr schon versucht, DATEV Eigenorganisation als Zwischenschicht zu nutzen? Wir haben das kurz evaluiert, aber die Importlogik für Beteiligungsstrukturen ist dort so starr dass sie unsere GmbH & Co. KG Konstruktionen nicht korrekt abbilden konnte.
Our SAP S/4HANA system holds the financial master data for all group entities, but ownership structures are maintained separately in a SharePoint list updated manually by our legal team. We need a REST API that exposes current ownership data in a format compatible with SAP's Business Partner object model. Is the API design planned around standard entity relationship formats like GLEIF LEI or ISO 20022 corporate action schemas, or will it require custom mapping on our side?
The GLEIF LEI data model is actually a reasonable reference point for intercompany ownership APIs – it explicitly separates direct and ultimate parent relationships and uses ISO 20275 entity legal forms. The challenge is that GLEIF data is self-reported and often months out of date, so it can serve as a structural template but not as a data source.
We looked at GLEIF as a potential source for our subsidiary register and gave up for exactly that reason – the self-reported data quality is too inconsistent for compliance purposes. What we actually need is an internal system that uses the GLEIF entity model as its schema but is fed from our own verified data, with the SAP Business Partner as the synchronisation target.
Wir haben eine Beteiligungsstruktur mit 12 Hierarchieebenen. Unser aktuelles System – eine Oracle-basierte Eigenentwicklung aus 2003 – bricht bei der Visualisierung ab der sechsten Ebene zusammen. Die UBO-Ermittlung nach §3 GwG wird deshalb manuell in Excel durchgeführt, was bei jeder Strukturänderung eine vollstädnige Neuberechnung erfordert. Plant ihr eine automatische Durchgriffsberechnung, die sowohl direkte als auch indirekte Anteile kumuliert, und werden dabei Treuhandverhältnisse als separater Beziehungstyp berücksichtigt?
Zwölf Ebenen ist außergewöhnlich tief – bei uns sind es acht und das reicht schon um die Excel-Lösung an ihre Grenzen zu bringen. Die eigentliche Frage ist ob das System bei der Durchgriffsberechnung auch Fälle korrekt behandelt, in denen dieselbe Gesellschaft auf mehreren Wegen erreichbar ist – also Strukturen die keinen reinen Baum bilden.
Genau dieser Fall tritt bei uns auf – durch historische Zusammenschlüsse halten zwei unserer Zwischenholdings jeweils unabhängig voneinander Anteile an derselben Tochtergesellschaft. Das Python-Skript das wir für die UBO-Berechnung verwenden, addiert die Pfade einfach auf und liefert damit falsche Gesamtquoten wenn beide Pfade auf denselben wirtschaftlich Berechtigten zurückgehen.
We currently manage ownership structures through Oracle JD Edwards World, extended with custom BPCS modules from the early 2000s. The system works for financial consolidation but has no concpet of legal ownership as distinct from economic interest. My core question: does your data model separate legal ownership percentage, economic participation rights, and voting rights as independent attributes per relationship, or are these conflated into a single share percentage field?
The distinction between legal and economic ownership is also the core issue in our German structures. We have GmbH interests where the economic rights have been transferred to a trust but the legal title remains with the original shareholder. Our SAP setup treats both as identical, which creates systematic errors in our UBO reporting.
Exactly our situation. And the problem compounds when the economic and legal owners are in different tax jurisdictions – the consolidation treatment differs, the GwG treatment differs, and neither our Oracle system nor our auditors can easily reconcile the two views from the same dataset.
Wir verwalten unsere Beteiligungsstruktur mit 47 Gesellschaften über eine selbstentwickelte Access-Datenbank aus 2009, die auf einem lokalen Server ohne Versionsverwaltung läuft. Meine Frage betrifft die Migration: Gibt es eine strukturierte Importlogik für historische Beteiligungsstände inklusive Stichtagsinformation, und wie wird nach dem Import die Vollständigkeit der übernommenen Daten validiert?
Beitrag hinterlassen