Was wir gemeinsam erheben, um den Umfang sauber zu schneiden.
Diese Seite ist der Kern von Phase 0. Sie listet auf, was an Dokumentation, Zugängen, Beispieldaten und vertraglichen Klärungen vorliegen muss, bevor der MVP belastbar geschätzt und gestartet werden kann. Vieles davon liegt bei der Pilotkanzlei bereits vor — anderes muss erst beschafft oder freigegeben werden.
Der größte Risikoposten der ersten Wochen ist nicht das Engineering, sondern die Beschaffung: BMD-Schnittstellen-Doku, reale Beispieldateien, FreeFinance-API-Zugang, Mandanten-Zustimmung. Wenn das vorliegt, ist der Bridge-Kern in 2–3 Wochen lauffähig.
Format-Spezifikation, Modulumfang, reale Beispieldaten.
Der zentrale Engpass: ein operativer Datenzugang in BMD, bei dem wir die zu lesenden Felder pro Datentyp (Stammdaten, Buchungen, OP, Anlagen) auswählen können. Konkret heißt das eines von beiden — NTCS-REST-API mit selektierbaren Endpunkten und Feldern oder ein parametrisiertes NTCS-Export-Modell, das pro Datentyp definiert, welche Felder in die CSV laufen. Ohne diesen Zugang bleibt die Bridge ein Konzept.
FIBU01-/FIBU04-Spec in der Version, die auf Ihrer NTCS-Installation läuft. Liegt typischerweise als PDF im Schnittstellen-Modul oder über das BMD-Partner-Portal. Wesentlich: Feldreihenfolge, Pflicht-/Optional-Markierung, Encoding-Konvention, Decimal-/Datum-Format.
Die XML-Vorlagen Ihrer NTCS-Installation für Konten, Personenkonten, Buchungssätze, OP-Listen, Anlagen. Sie zeigen, welche Felder Ihre Kanzlei wirklich nutzt — die Spec-Standardfelder können sich je Konfiguration unterscheiden.
Welche BMD-Module sind aktiv: FIBU, Lohn, Anlagenrechnung, Konsolidierung, Belegmanagement, Office-Anbindung. Bestimmt, welche Datenströme die Bridge überhaupt zu berühren hat.
Ein vollständiges Datenpaket aus einer realen Periode (idealerweise letztes Quartal):
— Mandantenstamm-Export — Sachkontenrahmen mit Steuerschlüssel-Zuordnung — Personenkonten (Kunden + Lieferanten) — Buchungsexport in FIBU01 und FIBU04 — Offene-Posten-Liste — Anlagenverzeichnis (falls relevant)
Welche Schlüssel sind in BMD definiert, was bedeuten sie steuerrechtlich (UStG-Tatbestand, %-Satz, Land, OSS-Relevanz). Ist mandantenabhängig — Schlüssel 8 in Mandant A ist nicht zwingend Schlüssel 8 in Mandant B.
Kontenplan-Variante (BMD-Standard, kanzleieigene Anpassung, Branchenmodifikation), Personenkonten-Nummernkreise, Kostenstellen-/-träger-Nutzung, Konventionen bei Stornierungen und Korrekturen.
Account-Zugang, API-Doku, Modulumfang im Pilotmandanten.
Ein eigens angelegter FF-Mandant für die Pilot-Migration — sauber, leer, mit dem geplanten Modulumfang. Kein produktiver Mandant in der ersten Iteration, um Replay/Rollback gefahrlos zu üben.
FreeFinance-API-Zugang liegt vor (Stand 2026-04-27). Konkrete Klärungen offen: Scope des Tokens (Stammdaten-Schreibzugriff, Buchungs-Schreibzugriff, Beleg-Anhang), Rate-Limits, Bulk-Endpunkt-Verfügbarkeit.
Aktuelle Version der FreeFinance-API-Doku, am besten als OpenAPI/Swagger-Spezifikation. Falls nur HTML/PDF: das.
Welche FF-Module sind im Pilotmandanten aktiv: Bankanbindung (welche Banken, PSD2-Status), OCR-Belege, FinanzOnline-Anbindung, Lohnverrechnung, Anlagenrechnung, OSS.
Hat die Kanzlei eine Partnervereinbarung oder einen direkten Ansprechpartner bei FreeFinance? Erleichtert API-Eskalation, Bulk-Operationen, Sandbox-Zugang.
Profil, Volumen, operative Realität.
Branche, Rechtsform, Mitarbeiterzahl, USt-Regelung (Regelbesteuerer / Kleinunternehmer / OSS), Buchungsvolumen pro Monat, Bilanzierung oder E/A-Rechnung.
Wer bucht heute: Mandant selbst, Kanzlei-Mitarbeiter:in, Mischbetrieb. Beleg-Volumen pro Monat, OCR-Quote, Bank-Anbindung-Stand. Zeigt, ob Modus A oder Modus B passt.
Schriftliche Freigabe des Mandanten, dass seine Daten für die Pilot-Implementierung verarbeitet werden dürfen, inklusive Auftragsverarbeitungsvertrag mit dem Bridge-Betreiber.
Welche § 131-/132-BAO-Anforderungen gelten konkret? Bestehende Verfahrensdokumentation? Bisherige Archiv-Lösung für BMD-Buchungsdaten?
Wie wird ein gescheiterter Pilot zurückgerollt — wer setzt BMD wieder als operatives System ein, wer übernimmt die Buchungen der Brücken-Periode? Klärt das Worst-Case-Szenario, bevor es eintritt.
Modus-Wahl, Co-Development-Modell, Erfolgskriterien.
Architektonische Weichenstellung: wird die Bridge ein internes Werkzeug für die Pilotkanzlei (kürzerer Weg zur ersten Migration, weniger Multi-Tenancy-Aufwand, Kanzlei besitzt das Werkzeug) — oder ein kommerzielles, kanzlei-übergreifendes Produkt (mehr Mandantentrennung, White-Label-Pfad, längerer Engineering-Zyklus, Vermarktung an weitere Kanzleien)? Beeinflusst Datenmodell, Hosting-Topologie, Co-Development-Vertragsform, IP-Verteilung. Klärung gehört in die ersten Wochen — beide Wege sind tragfähig, der Mischpfad nicht.
Wird der Pilotmandant nach Modus A (permanente Auslagerung) oder Modus B (Hybrid) geführt? Bestimmt die Bridge-Komplexität und den Implementierungs-Pfad.
Wie wird der Pilot-Aufwand vergütet — Festpreis, Time&Material, Beteiligung am späteren Produkt, Kombination. Inklusive Aufwandserwartung der Kanzlei (Stunden für Datenfreigaben, Tests, Korrekturen).
Was muss am Ende von P0 / P1 messbar erfüllt sein, damit der Pilot „erfolgreich" heißt: z. B. „Stammdaten-Migration in < 30 min", „Audit-Log deckt 100 % der Buchungen ab", „Mandant kann eine Woche normal in FF arbeiten ohne Rückfrage".
Verfügbare Stunden des Kanzlei-Mitarbeiters für Daten-Workshops, Test-Sessions, Korrektur-Schleifen. Realistisches Kalender-Fenster (welcher Quartalsabschluss steht im Weg).
NDA zwischen Kanzlei und Bridge-Betreiber. Auftragsverarbeitungsvertrag zwischen Kanzlei (Verantwortliche:r) und Bridge-Betreiber (Auftragsverarbeiter) für die Mandantendaten.
Hosting, Zugänge, Audit-Anforderungen.
AT-Cloud, EU-Cloud, Self-Hosting in der Kanzlei, Hybrid. Datenstandort-Anforderungen aus berufsrechtlicher Sicht (Datenschutzbehörde-Prüfung).
Falls REST-API genutzt wird: VPN-Zugang, IP-Whitelist, Service-Account, Stand der Authentifizierung (Basic / Token / OAuth).
Bestehende Kanzlei-Identitäten (Microsoft 365, Google Workspace, eigener IdP). SSO-Bedarf für das Bridge-Cockpit.
Existierende Kanzlei-Sicherheitsstandards (ISO 27001, BSI C5, branchenspezifische Auditierung). Penetrations-Test-Erwartung vor Produktivgang.
RPO/RTO-Erwartung für die Bridge-Datenbank. Backup-Frequenz, Aufbewahrung, Wiederherstellungs-Tests.
Pragmatisch, nicht bürokratisch.
Diese Liste ist der maximale Bedarf. Vieles davon liegt in jeder gut geführten Kanzlei mit aktiver BMD-NTCS-Installation entweder schon vor oder lässt sich in einer Stunde rauskramen. Was nicht vorliegt, klären wir strukturiert in zwei bis drei kurzen Workshops in den ersten Wochen.
Sinn der Liste ist, die Beschaffungs-Lücken früh sichtbar zu machen — nicht, eine Pflicht-Checkliste vor dem ersten Gespräch abzuhaken. Wenn ein Punkt unklar ist, klären wir ihn gemeinsam.