Hilfe für Organisationen

NEXITO WORK trennt zwei Ebenen: Der SaaS-Betreiber verwaltet die Plattform, Organisationen, Zugänge, Tarife und die NEXITO-eigene SaaS-Abrechnung. Ein Mandant arbeitet dagegen in seinem eigenen Organisationsdatenraum und verwaltet dort Kunden, Projekte, Rechnungen und Firmen.

Der technische Betreiberpfad ist als /admin dokumentiert. Der normale Mandantenarbeitsbereich startet unter /. Der Betreiberpfad ist kein Ersatz für die normale Kundenansicht und darf nur für ausdrücklich freigegebene Betreiberkonten sichtbar sein.

Der NEXITO-Login verwendet die Anwendungsauthentifizierung. Das Vercel-Konto ist nur für Hosting und Deployment und macht einen Benutzer nicht automatisch zum Betreiber. Betreiberrechte werden serverseitig über die freigegebene Betreiberidentität geprüft.

Öffentliche Registrierung ist im privaten Startmodell nicht die Grundlage. Der erste Owner wird kontrolliert angelegt; weitere Nutzer kommen über Einladungen und erhalten nur die für ihre Organisation und Rolle erlaubten Zugriffe.

Eine Organisation ist der abgeschottete Mandantendatenraum. Eine rechtliche Firma ist eine Firma innerhalb dieser Organisation. Sie hat eigene Anschrift, Steuerprofil, Währung, Bankkonten, Nummernkreise und Zahlungsanbieter.

Lege rechtliche Firmen unter /settings/legal-entities an. Ein Benutzer kann mehrere Firmen verwalten, wenn seine Membership und Rolle das erlauben. Ein Firmenwechsel ist keine bloße Filteränderung: Datenabfragen, Schreibaktionen, Reports, Rechnungen und Providerverbindungen müssen auf den ausgewählten beziehungsweise serverseitig erlaubten Firmenbereich begrenzt bleiben.

Die Auswahl der Organisation und der rechtlichen Firma erfolgt im Arbeitsbereich über den jeweiligen Wechsler. Wer nur einer Firma zugeordnet ist, darf keine andere Firma auswählen oder deren Daten per URL, Formular oder API anfordern.

Organisations-Branding findest du unter /settings/branding. Dort gehören Name, Farben, Favicon, Logo und Typografie der Organisation hin. Das Branding soll für Arbeitsbereich, Kundenportal, E-Mail-Vorlagen und Dokumente verwendet werden.

Für Dokumente und Rechnungen kann eine rechtliche Firma ein eigenes Dokumentprofil mit Firmenname, Adresse, Logo und Briefpapier gegenüber dem Organisations-Branding verwenden. So bleiben mehrere Firmen im selben Mandanten sichtbar getrennt.

Logos und Favicons werden über den vorgesehenen Upload in den geschützten Storage geladen. Eine Asset-URL oder ein Storage-Pfad ist nur eine erweiterte Referenz für bereits vorhandene Dateien; private Dokumente dürfen nicht als öffentliche URL ausgegeben werden.

Kunden werden unter /crm angelegt. Kontakte gehören zu einem Kunden und können in Kommunikation, Projekten, Angeboten und Rechnungen wiederverwendet werden. Leads und Deals bleiben mit ihrem Organisations- und Firmenkontext verbunden.

In Vorgängen mit Kundenauswahl soll ein bestehender Kunde gesucht oder direkt im Auswahlfeld angelegt werden können, ohne den aktuellen Vorgang zu verlieren. Neue Kunden benötigen mehr als Name und E-Mail, sobald Rechnungs-, Portal- oder Zahlungsprozesse verwendet werden: Anschrift, Ansprechpartner, Steuer- und Zahlungsdaten müssen strukturiert erfasst und validiert werden.

Rechnungen werden unter /invoices bearbeitet und immer einer rechtlichen Firma zugeordnet. Betrag und Steuer werden als Minor Units oder präzise Decimal-Werte verarbeitet; für Geld sind keine Float-Berechnungen zulässig.

Währungen werden mit dreistelligen ISO-4217-Codes angegeben, zum Beispiel EUR, USD oder GBP. Ein Währungscode ist kein Länder- oder Sprachkürzel.

Nummernkreise werden unter /settings/number-sequences je rechtlicher Firma und Dokumenttyp verwaltet. Zur Finanzbasis gehören unter anderem Angebote, Aufträge, Verträge, Rechnungen, Gutschriften, Zahlungen, Ausgaben, Mahnungen und offene Posten.

Für deutsche Firmenprofile sind XRechnung und ZUGFeRD, E-Rechnungs-Validierung und Visualisierung sowie die unveränderte Aufbewahrung strukturierter XML-Daten vorgesehen. Das PDF ersetzt nicht die strukturierte E-Rechnungsdatei. Vor produktiver Verwendung müssen Datenstand, XML, Validierung und steuerliche Behandlung fachlich geprüft werden; diese Dokumentation erklärt keine steuerliche Freigabe.

Unter /recurring-schedules werden wiederkehrende Leistungen und Rechnungspläne angelegt. Ein leeres Enddatum bedeutet grundsätzlich unbefristete Laufzeit. Eine Anzahl von Zyklen ist nur eine optionale Begrenzung, nicht die Definition eines normalen Abos.

Ein Plan benötigt Intervall, Betrag, Währung, rechtliche Firma, Kundenbezug und die gewählte Zahlungsart beziehungsweise den aktivierten Provider. Er muss pausiert, fortgesetzt, beendet und – sofern fachlich vorgesehen – abgeschlossen werden können.

Die Erstellung eines Rechnungsentwurfs und der Versand sind getrennte Aktionen. Die Erstellung läuft über einen dauerhaft speicherbaren, idempotenten Workflow; ein erneuter Lauf darf keine doppelte Rechnung erzeugen. NEXITO-SaaS-Abos des Betreibers gehören ausschließlich in /admin/billing und sind nicht dasselbe wie die Abos eines Mandanten für seine Kunden.

Es gibt zwei getrennte Zahlungsebenen: Erstens bezahlt die Organisation ihr NEXITO-WORK-SaaS-Abo an den Betreiber. Zweitens nimmt eine rechtliche Firma Zahlungen für ihre eigenen Kunden- rechnungen entgegen. Die zweite Verbindung wird je Firma gespeichert und nicht mit einer anderen Firma geteilt.

Unter /settings/payments werden die für die jeweilige Firma freigegebenen Zahlungsanbieter verwaltet. Stripe verwendet ein gehostetes Connect-Onboarding; die Firma muss keinen geheimen Stripe-Key in NEXITO WORK eintragen. Ein echter PayPal- Verbindungsfluss setzt die erforderliche PayPal-Partner- und Referral-Freischaltung voraus. Ohne diese Freigabe darf kein scheinbarer Login-Flow dokumentiert oder angezeigt werden.

Bankkonten werden unter /settings/banking über die austauschbare Plaid-Provider-Schicht verbunden. Der Link-/Consent- Flow, Institute, Konten, Salden, Währungen, Synchronisationsstatus, Re-Consent, Fehler und Wiederholungen gehören zum Banking-Ablauf. CSV-, CAMT- oder MT940-Importe bleiben ein möglicher Fallback.

Provider-Tokens und API-Secrets gehören ausschließlich in den serverseitigen Secret-Storage. Sie dürfen weder inNEXT_PUBLIC_-Variablen noch im Browser, Request-Body, Chat oder Repository landen. Webhooks müssen Signaturen prüfen, idempotent verarbeiten und die richtige Organisation sowie Firma serverseitig ermitteln.

Die Web-Zeiterfassung liegt unter /time. Ein Eintrag kann Mitarbeiter, Projekt, Aufgabe, Beschreibung und Abrechenbarkeit enthalten. Das Auswahlmuster lautet Mitarbeiter → Projekt → Aufgabe; Berechtigungen begrenzen die verfügbaren Optionen.

Der laufende Timer lebt serverseitig. Web-App, PWA und das vorgesehene Tauri-v2-Widget für macOS und Windows sehen deshalb denselben Zustand. Zeiten werden in UTC gespeichert und in der Benutzer- beziehungsweise Tenant-Zeitzone angezeigt. Ein zugeklappter Laptop darf den maßgeblichen Zustand nicht verfälschen.

Das Desktop-Widget ist eine Fernbedienung der authentifizierten API, keine zweite Abrechnungslogik. Es soll Start/Stop, Mitarbeiter-, Projekt- und Aufgabensuche, Tagessumme, Tastenkürzel, Autostart und einen Browser-Redirect-Login bieten. Passwörter gehören nicht in das Widget; Tokens gehören in Keychain beziehungsweise Credential Manager.

Bei kurzer Offline-Zeit werden Start-/Stop-Kommandos mit Idempotency-Key und Reihenfolge gepuffert. Nicht synchronisierte Zeit darf nicht stillschweigend als endgültig abrechenbar gelten. Screenshots, Idle-Überwachung und Aktivitätsüberwachung gehören ausdrücklich nicht zum ersten Widget.

Dokumente und Originaldateien werden unter /documents verwaltet. Als Eingänge sind Upload und Drag-and-drop, Kamera oder Foto aus PWA/App, Inbound-E-Mail, Speicherimport sowie E-Rechnung/XML vorgesehen.

Die Verarbeitung umfasst Dateityp- und Virenprüfung, Klassifikation, OCR, Layout-/Tabellenerkennung, Dublettenerkennung und Konfidenzwerte. Extrahiert werden können unter anderem Lieferant, Kunde, Rechnungsnummer, Datum, Netto, Steuer, Brutto, Währung, Zahlungsziel und Bankdaten.

Der Standardweg ist ein zentraler serverseitiger Mistral-OCR- Zugang von NEXITO. Ein Mandant benötigt dafür keinen eigenen Vision-Key. Rohantwort, Modellversion, Struktur, Konfidenzen, Korrekturen und Prüfschritte bleiben nachvollziehbar gespeichert. OCR darf nicht ohne die vorgesehenen Prüfungen automatisch eine Finanzbuchung erzeugen.

Das unveränderte Original, strukturierte E-Rechnungsdaten, OCR-/Textrepräsentation, Metadaten, Versionen und Verknüpfungen werden getrennt aufbewahrt. Supabase Storage ist der kanonische Dateispeicher; private Belege und kritische Originale bleiben geschützt.