Für welche Meldepflichten arbeiten Sie?

Für Reporting mit festen Terminen im Umfeld von Kapitalertragsteuer und Quellensteuer: MiKaDiv nach §§ 45b, 45c EStG, Steuerreporting und Meldungen an das BZSt, perspektivisch die Register- und Meldepflichten aus FASTER ab 2030. Andere Themen des Meldewesens klären wir im Erstgespräch – und sagen ehrlich, wo unsere Domäne endet.

Ab wann gilt MiKaDiv, und welche Fristen sind zu halten?

MiKaDiv gilt für Kapitalerträge, die nach dem 31. Dezember 2026 zufließen; das Verfahren startet zum 1. Januar 2027. Die Meldungen sind im Folgejahr fällig: bescheinigte Meldungen bis 31. März, sonstige bis 30. April, die Sammelmeldung nach § 45c EStG bis 31. Juli (Quelle: BZSt).

Wer ist nach MiKaDiv meldepflichtig – auch die KVG?

Meldepflichtig sind die auszahlenden Stellen und Kreditinstitute nach § 45b EStG, Wertpapiersammelbanken nach § 45c EStG und inländische Emittenten nach § 45b Abs. 9 EStG. KVGs und Fondsbuchhaltung sind meist nicht selbst Meldende, liefern aber die Daten der Verwahrkette – und tragen die Folgen für die Quellensteuer-Erstattung, wenn diese lückenhaft sind. Die rechtliche Einordnung Ihres Hauses klärt Ihre Steuerberatung; wir gestalten den Prozess.

Sind Sie UX-Designer oder Business Analyst?

Beides, in einer Rolle: UX Consultant und Business Analyst mit Schwerpunkt Regulatory Reporting. Wir schreiben Fachkonzepte, User Stories und Testfälle und gestalten die Workflows, in denen sie gelebt werden. Für Intermediäre in Stichworten: Requirements Engineering, Anforderungsanalyse, Prozessmodellierung (BPMN), Usability-Tests, Figma.

Brauchen Sie Zugang zu unseren produktiven Daten?

Nein. Wir arbeiten mit Beobachtung im Fachbereich, anonymisierten Beispielen und synthetischen Testdaten. Für Prototypen und UAT genügen realistische, aber erfundene Datensätze.

Wie gehen Sie mit Korrekturen und Rückweisungen um?

Wir modellieren den Korrekturlauf als eigenen Workflow: Rückmeldung des BZSt lesen, Fehler fachlich zuordnen, Datensatz korrigieren, erneut freigeben, erneut melden – alles im Audit-Trail. Das Statusmodell kennt den Zustand ‚zu korrigieren‘ ausdrücklich, statt ihn in einer Excel-Spalte zu verstecken.

Arbeiten Sie für den Hersteller oder für uns?

Pro Projekt nur für eine Seite. Beauftragt uns eine KVG oder Verwahrstelle mit der Einführung, arbeiten wir für sie – nicht für den Hersteller. Informationen aus einem Auftrag fließen nicht in einen anderen.

Wie schnell sehen wir Ergebnisse, und wie lange begleiten Sie?

Die Ist-Analyse liefert innerhalb weniger Wochen ein Prozessbild mit priorisierten Risikostellen. Danach richtet sich der Umfang nach Stichtag und Modul – vom Fachkonzept bis zur Hypercare nach dem ersten Meldezyklus. Wir schätzen das im Erstgespräch gemeinsam.

Meldepflichten und regulatorisches Reporting

Meldepflichten bedienbar machen – UX und Einführung für regulatorisches Reporting.

Für Fondsbuchhaltung, Steuern und Operations bei KVGs, Verwahrstellen und Depotbanken – und für Hersteller von Reporting-Modulen. Wir gestalten die Workflows hinter MiKaDiv, Steuerreporting und Meldungen an das BZSt so, dass Fachanwender Datensätze finden, prüfen, korrigieren und termingerecht freigeben. Ergebnis: Meldungen, die pünktlich, nachvollziehbar und ohne Parallel-Liste rausgehen.

Erstgespräch vereinbaren Wie wir vorgehen

Kurz gesagt

Beabstracto ist ein UX-Studio in München für komplexe Fachsysteme. Für regulatorisches Reporting – MiKaDiv nach §§ 45b, 45c EStG, Steuerreporting, Meldungen an das Bundeszentralamt für Steuern (BZSt) – gestalten wir die Arbeitsabläufe, in denen Fachanwender Meldungen finden, validieren, korrigieren, freigeben und nachverfolgen. Dazu kommt die Einführungsbegleitung auf Kundenseite: Ist-Analyse, Fachkonzept, Testkonzept und UAT, Key-User-Schulung, Go-live und Hypercare. Auftraggeber sind KVGs, Verwahrstellen und Depotbanken sowie Hersteller von Reporting-Modulen. Eine Ist-Analyse liefert innerhalb weniger Wochen erste belastbare Ergebnisse.

Wir arbeiten dabei als UX Consultant und Business Analyst mit Schwerpunkt Regulatory Reporting an der Schnittstelle von Fachbereich, Entwicklung und Hersteller.

Auf einen Blick

Rolle: UX Consultant und Business Analyst Regulatory Reporting, Requirements Engineer, Einführungs- und Rollout-Begleitung
Leistungen: UX für Reporting-Workflows (Manage Reports), Fachkonzept und Anforderungsanalyse, Testkonzept und UAT, Key-User-Schulung, Go-live und Hypercare
Branchen: Kapitalverwaltungsgesellschaften (Master-KVG, Service-KVG), Verwahrstellen, Depotbanken und Zahlstellen, Hersteller von Reporting- und Quellensteuer-Software
Systeme: MiKaDiv-Reporting-Module, Software zur Quellensteuer-Erstattung, Schnittstellen zu Fondsbuchhaltung und Backoffice (herstellerneutral)
Einsatz: Remote, München, vor Ort nach Absprache
Sprachen: Deutsch, Englisch, Portugiesisch

Woran scheitert Reporting im Alltag – trotz fertigem Format?

Format bekannt, Schnittstelle steht – und am Stichtag wird es trotzdem eng. Diese Situationen hören wir am häufigsten.

Fester Termin, loser Prozess
MiKaDiv-Meldungen haben feste Fristen im Folgejahr: 31. März, 30. April, 31. Juli. Der Weg dorthin läuft aber noch über Excel, E-Mail und Zuruf. Wer wann was freigegeben hat, steht nirgends.
Verwahrkette in falscher Granularität
Die Daten kommen von Verwahrstellen und Lagerstellen in unterschiedlicher Tiefe und Historie. Pro Bestand und Ertragsfall soll die Kette nachvollziehbar sein – oft ist sie nur im Kopf einzelner Personen. Ein Fehler hier trifft Meldung und Erstattung zugleich.
Validierungsfehler ohne Übersetzung
Das System liefert Fehlercodes, die im Fachbereich niemand ohne Entwickler deuten kann. Korrekturen landen im Ticket statt im Workflow. Unter SLA-Druck wird geraten statt geprüft.
Vier-Augen-Prinzip nur auf Papier
Die interne Richtlinie fordert eine Freigabe, das Werkzeug kennt keinen Checkpoint. Also geht die Datei per Mail raus und jemand antwortet ‚ok‘. Für eine Prüfung ist das kein Audit-Trail.
Neues Modul, keine Einführung
Der Hersteller liefert das Reporting-Modul, der Fachbereich soll es ab Januar produktiv nutzen. Fachkonzept, Testfälle, Key User und Schulung fehlen – und niemand übersetzt zwischen Fachbereich und Entwicklung.

Welche Termine den Takt vorgeben

Regulatorisches Reporting hat keine beweglichen Ziele. Diese Daten sind gesetzt.

1.1.2027
Start des MiKaDiv-Verfahrens; es gilt für Kapitalerträge, die nach dem 31.12.2026 zufließen: 31.3. · 30.4. · 31.7.
Meldefristen im Folgejahr: bescheinigte Meldungen, sonstige Meldungen, Sammelmeldung nach § 45c EStG: 1.1.2030
Anwendung der FASTER-Richtlinie mit Register und Meldepflichten für zertifizierte Finanzintermediäre; Umsetzung bis 31.12.2028: 11
wiederverwendbare UX-Fundamente – vom Glossar bis zum KPI-Framework – aus einem MiKaDiv-Reporting-Projekt

Was wir konkret liefern

Drei Leistungen, kombinierbar – je nachdem, ob Sie ein Reporting-Modul einführen, eines bauen oder Ihren Meldeprozess belastbar machen wollen.

Manage Reports: finden, validieren, korrigieren, freigeben, nachverfolgen

Wir gestalten den Workflow, in dem Fachanwender große Mengen an Meldungen unter SLA-Druck bearbeiten: ein explizites Statusmodell pro Datensatz, Filter und Bulk-Aktionen für den Massenbetrieb, ein Fehler-Mapping, das Validierungsfehler in fachliche Sprache übersetzt, und ein Vier-Augen-Checkpoint vor dem Versand an das BZSt. Jede Entscheidung bleibt im Audit-Trail nachvollziehbar. Für Hersteller von Reporting-Modulen arbeiten wir als externe UX-Beratung am Produkt, für KVGs und Verwahrstellen an Prozess und Konfiguration.

Statusmodell und Zustandsübergänge pro Meldung (offen, in Prüfung, freigegeben, übermittelt, angenommen, zu korrigieren)
Fehler-Mapping: Validierungsfehler → fachliche Bedeutung → Korrekturpfad
Informationsarchitektur und Haupt-Journeys (Manage Reports, Report-Detail, Korrekturlauf)
Vier-Augen-Checkpoint und Freigabelogik vor dem Versand
Klickbarer Prototyp mit realistischen Daten für Usability-Tests mit Fachanwendern

Manage Reports: finden, validieren, korrigieren, freigeben, nachverfolgen

Statusmodell und Zustandsübergänge pro Meldung (offen, in Prüfung, freigegeben, übermittelt, angenommen, zu korrigieren)
Fehler-Mapping: Validierungsfehler → fachliche Bedeutung → Korrekturpfad
Informationsarchitektur und Haupt-Journeys (Manage Reports, Report-Detail, Korrekturlauf)
Vier-Augen-Checkpoint und Freigabelogik vor dem Versand
Klickbarer Prototyp mit realistischen Daten für Usability-Tests mit Fachanwendern

Vom regulatorischen Text zum umsetzbaren Fachkonzept

Als Business Analyst und Requirements Engineer übersetzen wir Meldepflicht, Kommunikationshandbuch und interne Richtlinien in Anforderungen, die Entwicklung und Hersteller umsetzen können. Wir modellieren Prozesse end-to-end (BPMN), schreiben User Stories mit Abnahmekriterien und leiten daraus Testfälle ab. Das regulatorische Mapping – welche Vorgabe welches Systemverhalten erzwingt – wird dokumentiert, nicht gemutmaßt.

Ist-Analyse und Prozessaufnahme mit dem Fachbereich
Fachkonzept inklusive regulatorischem Mapping (§§ 45b, 45c EStG, Kommunikationshandbuch, interne Freigaberegeln)
User Stories, Abnahmekriterien und Testfälle für die UAT
Glossar und Taxonomie als gemeinsame Sprache für Fachbereich, Entwicklung und Hersteller
Schnittstellenanforderungen zu Fondsbuchhaltung, Backoffice und Verwahrstelle

Einführungsbegleitung, bis der Prozess ohne uns läuft

Wir begleiten die Einführung eines Reporting-Moduls auf Kundenseite – vom Testkonzept über die UAT bis zu Go-live und Hypercare. Key User werden früh eingebunden und geschult, damit das Wissen im Haus bleibt. Die Messgrößen sind einfach: fristgerecht freigegebene Meldungen, weniger Rückfragen beim Hersteller, keine Parallel-Liste mehr.

Testkonzept und UAT-Planung mit fachlichen Testfällen
Key-User-Konzept, Schulungsunterlagen und Anwenderschulung
Go-live-Checkliste, Cutover-Plan für den Stichtag und Hypercare-Begleitung
Rollout-Reporting an die Projektleitung: offene Punkte, Risiken, Akzeptanz
Übergabe an den Regelbetrieb mit dokumentierten Arbeitsanweisungen

Domänensprache

Diese Begriffe prägen den Reporting-Alltag. Wir sprechen sie, damit Workshops nicht mit Grundlagen beginnen müssen.

Meldepflicht und Meldefrist
MiKaDiv (§§ 45b, 45c EStG)
Bundeszentralamt für Steuern (BZSt)
Kommunikationshandbuch und XML-Schema
ELMA und Übertragungsweg
Verwahrkette, Lagerstelle, Wertpapiersammelbank
Auszahlende Stelle und Depotbank
Steuerbescheinigung und Sammelmeldung
Granularität und Datenqualität
Validierung, Korrekturmeldung, Rückweisung
Vier-Augen-Prinzip und Freigabe
Audit-Trail und Nachvollziehbarkeit
SLA und Statusmodell
FASTER, eTRC, zertifizierter Finanzintermediär

MiKaDiv: Mitteilungsverfahren Kapitalertragsteuer auf Dividenden aus Aktien und Hinterlegungsscheinen nach §§ 45b, 45c EStG. Gilt für Kapitalerträge, die nach dem 31.12.2026 zufließen; gemeldet wird an das BZSt.
Verwahrkette: Die Kette der Verwahrstellen und Lagerstellen zwischen Emittent und Anleger, pro Bestand und Ertragsfall. Für MiKaDiv muss sie nachvollziehbar gemeldet werden; für die Quellensteuer-Erstattung ist sie dieselbe Datengrundlage.
Kommunikationshandbuch: Technische Vorgabe des BZSt für das Meldeverfahren: Datenformat (XML), Nachrichtenaufbau, Größenlimits und Übertragungsweg. Für MiKaDiv gibt es getrennte Handbücher für Finanzmarktteilnehmer (FM) und Emittenten (FB).
Sammelmeldung: Zusammenfassende Meldung nach § 45c EStG, fällig bis zum 31. Juli des Folgejahres. Sie ergänzt die bescheinigten und sonstigen Meldungen nach § 45b EStG mit Frist 31. März bzw. 30. April.
Vier-Augen-Checkpoint: Ein verbindlicher Schritt vor dem Versand, in dem eine zweite Person die erzeugte Meldung stichprobenartig gegen die Verwahrkette hält und freigibt. Kein Bremsklotz der Automatisierung, sondern ihr Sicherheitsnetz.
Fehler-Mapping: Zuordnung jedes Validierungs- oder Rückweisungsfehlers zu seiner fachlichen Bedeutung, dem betroffenen Datenfeld und dem Korrekturpfad. Macht aus einem Code eine Handlung.
Statusmodell: Die explizit definierten Zustände einer Meldung – offen, in Prüfung, freigegeben, übermittelt, angenommen, zu korrigieren – und die erlaubten Übergänge dazwischen, inklusive der Rolle, die sie auslösen darf.
FASTER: Richtlinie (EU) 2025/50 für eine schnellere und sicherere Entlastung von Quellensteuern: digitale Ansässigkeitsbescheinigung (eTRC), Entlastung an der Quelle oder Schnellerstattung, nationales Register zertifizierter Finanzintermediäre mit Meldepflichten. Umsetzung bis 31.12.2028, Anwendung ab 1.1.2030.

Wie wir vorgehen

Sechs Schritte, die in jedem Reporting-Projekt wiederkehren – auf Kundenseite wie auf Herstellerseite.

1
Ist-Analyse im Fachbereich
Wir beobachten, wie die Meldung heute wirklich entsteht: Quellen, Excel-Listen, Zuruf, Freigaben. Mit Fondsbuchhaltung, Steuern und Operations dokumentieren wir Prozess, Rollen und Schmerzpunkte. Ergebnis: Prozessbild, Risikostellen, priorisierte offene Fragen.
wenige Wochen
2
Gemeinsame Sprache und regulatorisches Mapping
Glossar, Taxonomie und die Zuordnung von Vorgabe zu Systemverhalten – §§ 45b, 45c EStG, Kommunikationshandbuch, interne Richtlinien. Fachbereich, Entwicklung und Hersteller einigen sich auf dieselben Begriffe, bevor Screens entstehen.
3
Fachkonzept und Journeys
End-to-End-Prozesse statt Feature-Listen: Manage Reports, Report-Detail, Korrekturlauf, Freigabe. Daraus entstehen Statusmodell, Fehler-Mapping, Informationsarchitektur und User Stories mit Abnahmekriterien.
4
Prototyp und Usability-Test mit Fachanwendern
Ein klickbarer Prototyp mit realistischen Daten, getestet mit den Menschen, die später unter Frist arbeiten. Wir prüfen, ob Status, Fehler und Freigabe ohne Erklärung verstanden werden – und korrigieren vor der Umsetzung.
5
Testkonzept, UAT und Schulung
Testfälle aus dem Fachkonzept, UAT mit Key Usern, Schulungsunterlagen für den Fachbereich. Abnahme heißt: Eine Meldung läuft von der Datenanlieferung bis zur Freigabe ohne Umweg über Excel.
6
Go-live und Hypercare
Cutover zum Stichtag, Begleitung der ersten Meldezyklen, Nachschärfen von Status und Fehlertexten aus dem echten Betrieb. Übergabe an den Regelbetrieb mit Arbeitsanweisungen – und dem Nachweis, dass die Parallel-Liste weg ist.

Was wir gelernt haben

Aus unserer UX-Beratung für den Hersteller einer Software zur Quellensteuer-Erstattung – und aus Reporting-Prozessen, in denen das Format längst stand, die Daten aber nicht.

01
Erst die Sprache, dann die Screens
Domänenwissen lag verteilt bei Entwicklern, Product Owner und Geschäftsführung; Personas waren implizit und nicht priorisiert. Ein Glossar, eine Taxonomie und das regulatorische Mapping (BZSt, ELMA, MiKaDiv, SLAs) brachten alle an denselben Tisch. Erst danach ließ sich sinnvoll über Interface-Verhalten streiten. Wer mit Screens beginnt, diskutiert Meinungen; wer mit Begriffen beginnt, diskutiert Entscheidungen.
02
Workflows statt Features
Reporting wurde zunächst als Liste von Funktionen besprochen. Als wir den Ablauf end-to-end aufzeichneten – Datenanlieferung, Validierung, Korrektur, Freigabe, Versand, Rückmeldung –, wurden Versagenspunkte und SLA-Risiken sichtbar, die kein einzelnes Feature abgedeckt hätte. Aus Versagenspunkten wurden UX-Spannungen, daraus Design-Prinzipien, daraus Verhalten im Interface.
03
Fehler müssen Handlungen werden
Ein Validierungsfehler, der nur als Code erscheint, erzeugt ein Ticket. Ein Fehler, der sagt, welches Feld in welcher Verwahrstelle betroffen ist und wie der Korrekturpfad aussieht, erzeugt eine Korrektur. Das Fehler-Mapping war eines der Fundamente, mit denen Entwickler Filter, Validierung, Bulk-Aktionen und die Report-Detail-Struktur konkret modellieren konnten.
04
Der Checkpoint ist das Sicherheitsnetz der Automatisierung
Ein vollautomatischer Versand meldet auch dann, wenn die Datenlage eigentlich ‚nein‘ sagen würde. Ein Vier-Augen-Checkpoint vor dem Versand kostet Minuten und verhindert, dass ein systematischer Fehler der Verwahrkette in die Meldung durchschlägt. Wer einmal erlebt hat, dass eine Meldung vor dem Versand korrigiert wurde, vertraut der nächsten mehr – und baut keine Parallel-Liste.
05
Ein Prototyp mit realistischen Daten entscheidet mehr als ein Konzept
Ein hochauflösender Prototyp der Manage-Reports-Journey wurde von Stakeholdern großer Banken wie Produktionssoftware behandelt. Er klärte den MVP-Umfang, gab Entwicklern ein konkretes Modell für Report-Detail und Audit-Trail und machte jede UI-Entscheidung auf Persona, Risikoszenario und Prinzip rückführbar. Konzepte überzeugen Fachleute selten; erlebbare Abläufe schon.

Erfahrung

Öffentliche Cases und Fachbeiträge aus dem Umfeld von Quellensteuer und Reporting. Keine Namen von Banken, KVGs oder Verwahrstellen.

Software für Quellensteuer-Erstattung

MiKaDiv-Reporting-Modul: UX-Beratung für den Hersteller

Als externe UX-Beratung für den Hersteller einer Software zur Quellensteuer-Erstattung haben wir die UX-Grundlagen für ein neues MiKaDiv-Reporting-Modul erarbeitet: gemeinsame Sprache, Personas, Prozess- und Fehler-Mapping, Informationsarchitektur und ein Prototyp der Manage-Reports-Journey. Elf wiederverwendbare Fundamente, vom Glossar bis zum KPI-Framework.

→

Fachbeitrag

MiKaDiv: Warum die Verwahrkette jetzt sichtbar werden muss

Was an MiKaDiv operationell schwierig ist, warum Granularität und Qualität der Verwahrkette der empfindliche Punkt sind und welche Checkliste für die Monate bis zum Stichtag hilft.

→

Fachbeitrag

Excel-Liste als Symptom: Backoffice trifft Steuer

Die parallele Excel-Liste entsteht, wo Frist, fehlendes Dokument und Status des Falls nicht am selben Ort liegen – meist an der Schnittstelle zwischen Backoffice- und Steuersystem.

→

Fachliche Referenzen

An diesen Quellen orientieren wir unsere Arbeit; wir behaupten keine Zertifizierung und keine institutionelle Beziehung.

Bundeszentralamt für Steuern (BZSt) · 2026

Mitteilungsverfahren MiKaDiv – Verfahrensseite und Kommunikationshandbuch MiKaDiv FM

Verfahrensbeschreibung, FAQ und technisches Handbuch (XML-Format, Nachrichtenaufbau, Fristen).

Deutscher Bundestag, BGBl. I S. 1259 · 2021

Gesetz zur Modernisierung der Entlastung von Abzugsteuern und der Bescheinigung der Kapitalertragsteuer (AbzStEntModG), §§ 45b, 45c EStG

Führt die Rechtsgrundlage von MiKaDiv ein; nach Verschiebung durch das Jahressteuergesetz 2024 anwendbar ab 1.1.2027.

Rat der Europäischen Union · 2025

Richtlinie (EU) 2025/50 des Rates über eine schnellere und sicherere Entlastung von überschüssigen Quellensteuern (FASTER)

eTRC, Entlastung an der Quelle, Schnellerstattung innerhalb von 60 Tagen und ein Register zertifizierter Finanzintermediäre mit Meldepflichten; Anwendung ab 1.1.2030.

ISO/TC 159/SC 4 · 2020

Häufige Fragen

Für welche Meldepflichten arbeiten Sie?: Für Reporting mit festen Terminen im Umfeld von Kapitalertragsteuer und Quellensteuer: MiKaDiv nach §§ 45b, 45c EStG, Steuerreporting und Meldungen an das BZSt, perspektivisch die Register- und Meldepflichten aus FASTER ab 2030. Andere Themen des Meldewesens klären wir im Erstgespräch – und sagen ehrlich, wo unsere Domäne endet.
Ab wann gilt MiKaDiv, und welche Fristen sind zu halten?: MiKaDiv gilt für Kapitalerträge, die nach dem 31. Dezember 2026 zufließen; das Verfahren startet zum 1. Januar 2027. Die Meldungen sind im Folgejahr fällig: bescheinigte Meldungen bis 31. März, sonstige bis 30. April, die Sammelmeldung nach § 45c EStG bis 31. Juli (Quelle: BZSt).
Wer ist nach MiKaDiv meldepflichtig – auch die KVG?: Meldepflichtig sind die auszahlenden Stellen und Kreditinstitute nach § 45b EStG, Wertpapiersammelbanken nach § 45c EStG und inländische Emittenten nach § 45b Abs. 9 EStG. KVGs und Fondsbuchhaltung sind meist nicht selbst Meldende, liefern aber die Daten der Verwahrkette – und tragen die Folgen für die Quellensteuer-Erstattung, wenn diese lückenhaft sind. Die rechtliche Einordnung Ihres Hauses klärt Ihre Steuerberatung; wir gestalten den Prozess.
Sind Sie UX-Designer oder Business Analyst?: Beides, in einer Rolle: UX Consultant und Business Analyst mit Schwerpunkt Regulatory Reporting. Wir schreiben Fachkonzepte, User Stories und Testfälle und gestalten die Workflows, in denen sie gelebt werden. Für Intermediäre in Stichworten: Requirements Engineering, Anforderungsanalyse, Prozessmodellierung (BPMN), Usability-Tests, Figma.
Brauchen Sie Zugang zu unseren produktiven Daten?: Nein. Wir arbeiten mit Beobachtung im Fachbereich, anonymisierten Beispielen und synthetischen Testdaten. Für Prototypen und UAT genügen realistische, aber erfundene Datensätze.
Wie gehen Sie mit Korrekturen und Rückweisungen um?: Wir modellieren den Korrekturlauf als eigenen Workflow: Rückmeldung des BZSt lesen, Fehler fachlich zuordnen, Datensatz korrigieren, erneut freigeben, erneut melden – alles im Audit-Trail. Das Statusmodell kennt den Zustand ‚zu korrigieren‘ ausdrücklich, statt ihn in einer Excel-Spalte zu verstecken.
Arbeiten Sie für den Hersteller oder für uns?: Pro Projekt nur für eine Seite. Beauftragt uns eine KVG oder Verwahrstelle mit der Einführung, arbeiten wir für sie – nicht für den Hersteller. Informationen aus einem Auftrag fließen nicht in einen anderen.
Wie schnell sehen wir Ergebnisse, und wie lange begleiten Sie?: Die Ist-Analyse liefert innerhalb weniger Wochen ein Prozessbild mit priorisierten Risikostellen. Danach richtet sich der Umfang nach Stichtag und Modul – vom Fachkonzept bis zur Hypercare nach dem ersten Meldezyklus. Wir schätzen das im Erstgespräch gemeinsam.