eAU-Änderungen 2027
Neue Datensatzversion. AU ab dem ersten Tag. Teil-Arbeitsunfähigkeit. Neue Beteiligte im Verfahren. Und natürlich neue Felder, neue Regeln und neue technische Details.
Rund um die elektronische Arbeitsunfähigkeitsbescheinigung – kurz eAU – passiert gerade einiges. Wer Schlagzeilen liest, könnte den Eindruck bekommen, dass 2027 das komplette Verfahren noch einmal neu erfunden wird.
Ganz so ist es nicht. Aber langweilig wird es auch nicht.
Denn zum 1. Januar 2027 kommt tatsächlich eine neue eAU-Datensatzversion 3.0. Gleichzeitig hat die Politik weitere Änderungen rund um die Krankschreibung auf den Weg gebracht. Dazu gehören die AU ab dem ersten Krankheitstag und die neue Teilarbeitsunfähigkeit.
Das Problem: Die drei Themen haben unterschiedliche Reifegrade und unterschiedliche Starttermine. Wer heute Software für Entgeltabrechnung, Zeitwirtschaft oder HR entwickelt, muss deshalb sehr genau unterscheiden zwischen dem, was bereits technisch feststeht, dem, was politisch angekündigt wurde, und dem, was erst 2028 produktiv wird.
Und genau da beginnt der Spaß.
- Ab 1. Januar 2027 gilt im eAU-Verfahren die Datensatzversion 3.0. Für die bisherigen Versionen gibt es eine Übergangszeit bis 28. Februar 2027.
- Neu sind unter anderem das Feld „Abrechnungsprogramm“, Änderungen an
Abwesenheit_ab_AG, neue technische Vorgaben und der Rückmeldegrund „Sonderfall“. - Ab 2027 nehmen auch Jobcenter am elektronischen AU-Abruf teil.
- Eine allgemeine AU-Pflicht ab dem ersten Krankheitstag ist politisch vereinbart, aber noch nicht geltendes Recht. Bis zur gesetzlichen Umsetzung gelten die bisherigen Regeln weiter.
- Die neue Teilarbeitsunfähigkeit startet nicht 2027, sondern zum 1. Januar 2028. Der elektronische Austausch mit dem Arbeitgeber über § 109 SGB IV startet sogar erst am 1. Juli 2028.
Was ändert sich bei der eAU 2027 tatsächlich?
Beginnen wir mit dem Teil, der nicht mehr politisches Wunschkonzert, sondern bereits ziemlich konkret ist.
Die vom GKV-Spitzenverband veröffentlichten Grundsätze für das eAU-Verfahren in Version 3.0 gelten ab dem 1. Januar 2027. Auch die XML-Schemata Anforderung_eAU_AG und Rückmeldung_eAU_KK sind ab diesem Zeitpunkt in Version 3.0 zu verwenden. Für eine Übergangszeit bis zum 28. Februar 2027 werden die Annahmestellen noch Meldungen nach alter und neuer Version verarbeiten.
Das klingt zunächst nach einem normalen Versionswechsel. Für einen Softwarehersteller bedeutet „neue Version“ aber bekanntlich etwas mehr als eine neue Zahl im Header.
In der Anforderung wird beispielsweise das Abrechnungsprogramm als neues Feld aufgenommen. Die Datensatz-ID wird eindeutig als 36-stellige UUID festgelegt. Abwesenheit_ab_AG wird innerhalb des Schemas verschoben und zum Pflichtfeld. Hinzu kommen Anpassungen für die neu beteiligten Jobcenter.
Auch auf der Rückmeldeseite gibt es Veränderungen. Der bisherige Rückmeldegrund 6 wird zum „Sonderfall“. Gemeint sind unter anderem Abwesenheiten wie teilstationäre Krankenhausbehandlungen oder bestimmte Reha-Konstellationen, deren vollständige Zeiträume der Krankenkasse häufig erst deutlich später vorliegen. In solchen Fällen bekommt der Arbeitgeber zunächst den Hinweis „Sonderfall“, aber gerade nicht alle sonst üblichen Zeitangaben.
Das ist ein schönes Beispiel dafür, was wir an Sozialversicherungsverfahren so lieben: Ein Sonderfall wird nicht weniger besonders, indem man ihm ein eigenes Kennzeichen gibt. Aber immerhin weiß die Software danach sehr präzise, dass sie gerade nicht alles weiß.
Die eAU wird 2027 noch größer
Eine weitere echte Änderung ist die Erweiterung des Teilnehmerkreises.
Ab 1. Januar 2027 können auch Jobcenter für gesetzlich Versicherte im SGB-II-Leistungsbezug Arbeitsunfähigkeitsdaten elektronisch bei den Krankenkassen abrufen. Das gilt sowohl für gemeinsame Einrichtungen von Bundesagentur für Arbeit und kommunalem Träger als auch für zugelassene kommunale Träger. Dafür wurden eigene technische Vorgaben und Produkt- beziehungsweise Modifikationskennungen in das Verfahren aufgenommen.
Für einen klassischen Arbeitgeber ändert das im Tagesgeschäft zunächst wenig. Für das Verfahren insgesamt ist es aber symptomatisch: Die eAU entwickelt sich von der vermeintlich simplen Digitalisierung eines gelben Scheins immer weiter zu einem vernetzten Sozialversicherungsverfahren mit unterschiedlichen Beteiligten, Rückmeldewegen und Sonderlogiken.
Und genau hier liegt aus unserer Sicht eines der grundsätzlichen Probleme.
Der gelbe Schein in digital. Das hätte so einfach sein können.
Die ursprüngliche Idee klingt fast banal: Ein Arbeitnehmer ist krank. Die Information liegt digital vor. Der Arbeitgeber bekommt Anfang und Ende der Arbeitsunfähigkeit elektronisch zurück.
Fertig.
In der Realität ist die eAU aber kein digitaler gelber Zettel, sondern ein eingebettetes Sozialversicherungs-Meldeverfahren. Arbeitgeber stellen eine elektronische Anforderung an die Krankenkasse. Dafür braucht das Verfahren unter anderem Betriebsnummern, Absenderinformationen, Personendaten beziehungsweise Versicherungsnummer, eindeutige Datensatz-IDs, das richtige Abwesenheitsdatum und eine gültige technische Verfahrensversion. Die Übertragung muss aus einem systemgeprüften Programm gesichert und verschlüsselt erfolgen.
Schon heute steuert das Feld Abwesenheit_ab_AG, welche AU die Krankenkasse überhaupt suchen und zurückmelden soll. Bei einer neuen Abwesenheit ist normalerweise der vom Arbeitnehmer gemeldete erste Abwesenheitstag anzugeben, bei einer fortdauernden AU der erste Tag nach dem Ende des bereits bekannten Nachweises. Das entspricht auch der heute geltenden Verfahrenslogik in unseren bisherigen Unterlagen.
Fachlich ist das alles begründbar. Technisch bedeutet es aber: Aus einer vermeintlich simplen Information ist eine eigene Prozesswelt geworden und eine Faustregel gilt: Eine Vereinfachung zieht in der Sozialversicherung leider erstaunlich häufig zwei neue Sonderfälle hinter sich her.
AU ab Tag 1: Kommt die Drei-Tage-Regel 2027 wirklich weg?
Hier lohnt sich das Warten.
Auch heute gilt weiterhin § 5 Entgeltfortzahlungsgesetz: Grundsätzlich muss die Arbeitsunfähigkeit ärztlich festgestellt werden, wenn sie länger als drei Kalendertage dauert; der Arbeitgeber darf allerdings schon eine frühere ärztliche Feststellung verlangen. (Sehen Sie in Ihrem Arbeitsvertrag nach.)
Am 2. Juli 2026 hat sich der Koalitionsausschuss darauf verständigt, diese Systematik zu verändern. Im Beschlusspapier steht ausdrücklich, dass die telefonische Krankschreibung abgeschafft und eine verpflichtende AU-Bescheinigung ab dem ersten Tag der Erkrankung eingeführt werden soll.
Aber: Das ist Stand 10. August 2026 noch kein geltendes Gesetz. Die Bundesregierung weist selbst darauf hin, dass bis zur Umsetzung die bisherigen Regelungen bestehen bleiben. Auch die telefonische Krankschreibung ist derzeit weiterhin möglich.
Deshalb kann man nicht korrekt behaupten: „Ab 1. Januar 2027 muss jeder ab Tag 1 eine eAU haben.“
Es gilt aktuell: Die AU ab Tag 1 ist politisch angekündigt. Ob sie tatsächlich 2027 in Kraft tritt, wie Ausnahmen aussehen und wie das eAU-Verfahren technisch darauf angepasst wird, ist noch offen.
Und dieser Unterschied ist für Softwareanbieter ziemlich wichtig.
Was würde eine AU ab Tag 1 technisch für die eAU bedeuten?
Heute kennt das Verfahren bewusst die Situation, dass ein Arbeitnehmer bereits beim Arbeitgeber krankgemeldet ist, aber noch keine ärztlich festgestellte AU bei der Krankenkasse vorhanden sein muss. Die bestehende eAU-Verfahrensbeschreibung enthält sogar eigene Matching-Regeln für den Fall, dass Abwesenheit_ab_AG vor dem Beginn der ärztlich festgestellten AU liegt. In der bisherigen Verfahrenslogik kann das etwa passieren, wenn erst ab dem vierten Tag attestiert wurde.
Fällt diese Karenz systematisch weg, verändert sich damit nicht nur eine arbeitsrechtliche Regel. Voraussichtlich verändert sich auch das Nutzungsverhalten des gesamten eAU-Verfahrens: mehr ärztliche Feststellungen bei kurzen Erkrankungen, mehr abrufbare eAU-Fälle und möglicherweise andere Erwartungen an den Zeitpunkt der Arbeitgeberanfrage.
Das ist momentan eine technische Schlussfolgerung, noch keine veröffentlichte neue eAU-Verfahrensvorgabe. Genau deshalb sollte ein Softwarehersteller heute noch keine eigene Interpretation implementieren und hoffen, dass das spätere Verfahren genauso aussieht.
Gesetz, Grundsätze, Verfahrensbeschreibung, Feldlisten, XML-Schemata und Systemprüfung müssen am Ende zusammenpassen. Dazwischen liegen erfahrungsgemäß einige Meetings und Monate wenn nicht Jahre.
Teilzeit-eAU 2027? Fast. Aber eben nicht 2027.
Noch interessanter wird es bei der sogenannten Teilzeit-Krankschreibung. Der offizielle Begriff lautet Teilarbeitsunfähigkeit.
Anders als die AU ab Tag 1 ist diese Änderung inzwischen weit über eine politische Absicht hinaus. Bundestag und Bundesrat haben das GKV-Beitragssatzstabilisierungsgesetz im Juli 2026 beschlossen; der Bundesrat hat keinen Vermittlungsausschuss angerufen.
Die Teilarbeitsunfähigkeit erlaubt künftig bei einer voraussichtlich länger dauernden Erkrankung eine teilweise Arbeitsleistung. Ärztlich vorgesehen sind Stufen von 25, 50 oder 75 Prozent Teilarbeitsunfähigkeit. Voraussetzung ist unter anderem, dass eine Arbeitsunfähigkeit von mehr als vier Wochen zu erwarten ist. Sowohl der Versicherte als auch der Arbeitgeber müssen mitmachen; der Arbeitgeber hat nach der Anzeige sieben Kalendertage Zeit, seine Zustimmung mitzuteilen.
Und jetzt der entscheidende Punkt für alle Überschriften à la „Teilzeit-Krankschreibung ab 2027“:
Die Regelung zur Teilarbeitsunfähigkeit tritt am 1. Januar 2028 in Kraft. Der Arbeitgeber wird die entsprechenden Daten im eAU-Verfahren nach § 109 SGB IV sogar erst ab dem 1. Juli 2028 elektronisch abrufen können. Dann muss er seinerseits die Zustimmung zur teilweisen Arbeitsleistung und den Zeitpunkt der Arbeitsaufnahme elektronisch an die Krankenkasse melden; auch eine vorzeitige Beendigung wird zum elektronischen Meldefall.
2027 ist damit nicht das Jahr der Teilzeit-eAU. 2027 ist das Jahr, in dem die technische Umsetzung dafür vorbereitet werden muss.
Für Softwareanbieter ist das möglicherweise sogar wichtiger.
Und wer zahlt bei der Teilarbeitsunfähigkeit?
Auch diese Frage lässt sich inzwischen wesentlich konkreter beantworten als noch vor einigen Monaten.
Wer während einer Teilarbeitsunfähigkeit tatsächlich arbeitet, erhält für diesen Anteil anteiliges Arbeitsentgelt vom Arbeitgeber. Das Gesetz sieht daneben teilweises Krankengeld entsprechend dem festgestellten Umfang der Teilarbeitsunfähigkeit vor. Für die Entgeltfortzahlung wird die bestehende Systematik entsprechend angewendet; soweit der Arbeitnehmer krankheitsbedingt an der Arbeitsleistung verhindert ist, besteht ein anteiliger Entgeltfortzahlungsanspruch.
Damit entsteht aber auch eine neue fachliche Kette: ärztliche Feststellung, Arbeitnehmerinformation, Entscheidung des Arbeitgebers, teilweise Arbeitsaufnahme, gegebenenfalls anteilige Entgeltfortzahlung beziehungsweise Krankengeld und schließlich elektronische Rückmeldungen zwischen Arbeitgeber und Krankenkasse.
Die Idee dahinter kann sinnvoll sein. Die technische Umsetzung wird dadurch trotzdem nicht automatisch einfach.
Was bedeuten die eAU-Anpassungen konkret?
Wenn wir das für alle diskutierten Punkte heute schon vollständig wüssten, wäre unser Beruf vermutlich deutlich entspannter.
Bei der eAU-Version 3.0 für 2027 wissen wir inzwischen sehr genau, was kommt. Es gibt genehmigte Grundsätze, eine Verfahrensbeschreibung und Feldlisten. Softwareanbieter können und müssen damit arbeiten.
Bei der AU ab Tag 1 sieht es anders aus. Hier steht bislang eine politische Entscheidung am Anfang der Kette. Erst wenn daraus Gesetz wird, können die zuständigen Institutionen die fachlichen und technischen Folgen verbindlich in Verfahren übersetzen.
Bei der Teilarbeitsunfähigkeit steht das Gesetz bereits wesentlich fester. Bis zum elektronischen Arbeitgeberverfahren ab Juli 2028 müssen jedoch noch die Detailregeln für Datensätze, Fristen und elektronische Kommunikation konkretisiert werden; genau diese Details soll der GKV-Spitzenverband in Grundsätzen festlegen.
Das ist die Realität hinter einem Satz wie „Wir digitalisieren die Krankschreibung“.
Politik definiert ein Ziel. Fachgremien übersetzen es in Sozialversicherungslogik. Daraus entstehen Grundsätze und Verfahrensbeschreibungen. Dann kommen Feldlisten, Schemata, Prüfungen und Versionen. Und am Ende sitzt irgendwo ein Softwarehersteller und darf dafür sorgen, dass beim Anwender trotzdem nur ein Button zu sehen ist.
Als hätten wir sonst nichts zu tun.
Warum haben wir bei Xisi dabei einen Vorteil?
Weil genau diese Übersetzung seit über 13 Jahren unser Alltag ist.
Die elektronische Übertragung von Meldungen an Sozialversicherungen, Finanzämter und andere Institutionen gehört seit 2013 zu unserer Kernkompetenz. Wir haben miterlebt, wie aus ursprünglich vergleichsweise isolierten elektronischen Meldeverfahren ein immer dichter vernetztes Ökosystem entstanden ist.
Am Anfang bestand Digitalisierung häufig tatsächlich darin, einen bestehenden Zettel möglichst originalgetreu in eine Datei zu verwandeln. Das war nicht elegant, aber überschaubar.
Heute hängen Verfahren voneinander ab. Stammdaten kommen aus anderen Systemen. Identitäten müssen eindeutig sein. Rückmeldungen lösen Folgeprozesse aus. Versionen ändern sich. Prüfregeln werden erweitert. Ein Verfahren kennt plötzlich Informationen aus einem anderen Verfahren.
Der alte Ansatz ist geblieben. Die technische Welt darum herum nicht.
Und die eAU ist dafür ein ziemlich gutes Beispiel.
Wie arbeiten wir bei Xisi?
Wir warten bei neuen Meldeverfahren nicht darauf, dass irgendwann eine hübsche Zusammenfassung erscheint.
Sobald ein Verfahren konkret wird, arbeiten wir uns in Gesetz, Grundsätze, Verfahrensbeschreibung, Feldlisten und technische Schemata ein. Wir sprechen mit den beteiligten Institutionen und klären die Fragen, die für eine reale Softwareintegration relevant sind.
Unsere Erfahrung ist dabei übrigens differenzierter, als unser gelegentlicher Frust über Sozialversicherungslogik vermuten lässt: Die Zusammenarbeit mit den Institutionen funktioniert häufig sehr gut. Gerade wenn man die richtigen Ansprechpartner gefunden hat, sind Roadmaps, Abstimmungen und technische Prüfungen oft erstaunlich pragmatisch.
Schwierig wird es eher davor. Für Interessierte, Quereinsteiger oder ein Softwarehaus, das erstmals ein SV-Verfahren implementieren möchte, ist die Informationslandschaft alles andere als selbsterklärend. Zuständigkeiten verteilen sich, Dokumente bauen auf anderen Dokumenten auf, Fachsprache setzt Vorwissen voraus und eine kleine fachliche Besonderheit kann plötzlich Auswirkungen auf mehrere technische Ebenen haben.
Wir sind mittendrin: technisch exzellent und menschlich.
Was müssen Softwareanbieter jetzt tun?
Für Softwarehersteller würden wir 2027 und 2028 deshalb nicht als einzelne Stichtage betrachten, sondern als zusammenhängende Roadmap.
Für den 1. Januar 2027 ist die Aufgabe bereits konkret: Datensatzversion 3.0 analysieren und implementieren, neue beziehungsweise geänderte Felder berücksichtigen, Schemata und Prüfungen aktualisieren, Rückmeldegründe sauber verarbeiten und die Übergangsphase bis Ende Februar beherrschen. Dazu gehören auch Änderungen wie das neue Feld „Abrechnungsprogramm“, das verpflichtende Abwesenheit_ab_AG, die eindeutige UUID und der neue Umgang mit dem Rückmeldegrund „Sonderfall“.
Für unsere Kunden ist diese To-do-Liste übrigens schon abgehakt. Die eAU-Version 3.0 haben wir bereits im April 2026 umgesetzt.
Parallel sollten Softwareanbieter AU ab Tag 1 beobachten, aber noch keine erfundene Fachlogik bauen. Sobald ein Gesetz und anschließend konkrete Änderungen des eAU-Verfahrens veröffentlicht werden, muss geprüft werden, welche Auswirkungen das auf Auslösung, Timing und Mengen der Abrufe hat.
Und dann ist da schon 2028: Mit der Teilarbeitsunfähigkeit wird aus dem heutigen eAU-Abruf erstmals deutlich mehr als „Arbeitgeber fragt – Krankenkasse antwortet“. Der Arbeitgeber muss künftig selbst Entscheidungen über Zustimmung, Arbeitsaufnahme und gegebenenfalls Beendigung elektronisch in das Verfahren zurückmelden.
Das sollte man nicht erst im Juni 2028 auf die Sprintplanung schreiben.
Was bietet Xisi konkret?
Genau hier möchten wir unseren Kunden den Teil abnehmen, der mit ihrem eigentlichen Produkt möglichst wenig zu tun hat.
Wer eine HR-, Zeitwirtschafts-, Workforce- oder Abrechnungslösung entwickelt, will in erster Linie gute Software für seine Anwender bauen. Er möchte nicht jedes Mal aufs Neue herausfinden, welcher Datensatz in welcher Version über welchen Weg mit welchem Header zu welcher Annahmestelle muss und was ein neuer Rückmeldegrund im Gesamtverfahren auslöst.
Dafür gibt es Xisi eAU.
Wir kümmern uns um die technische Welt des Meldeverfahrens im Hintergrund und verfolgen die Änderungen an Verfahren und Spezifikationen. Unsere Kunden können sich auf ihre Fachanwendung und ihre Nutzer konzentrieren, statt sich jedes Mal selbst durch Grundsätze, Verfahrensbeschreibungen und XML-Schemata arbeiten zu müssen.
Das bedeutet nicht, dass Änderungen wie die AU ab Tag 1 oder die Teilarbeitsunfähigkeit für Softwareanbieter irrelevant werden. Fachliche Auswirkungen auf die eigene Anwendung bleiben natürlich bestehen.
Aber der komplette Sozialversicherungs-Unterbau muss deshalb nicht zum neuen Lieblingshobby der Entwicklungsabteilung werden.
Das übernehmen wir gerne.
eAU 2027: Vereinfachung bleibt Arbeit
Die elektronische Arbeitsunfähigkeitsbescheinigung hat ohne Frage Papier abgeschafft und Prozesse digitalisiert. Gleichzeitig zeigt die Entwicklung der vergangenen Jahre ziemlich deutlich: Digitalisierung bedeutet im deutschen Meldewesen nicht automatisch weniger Komplexität.
2027 kommt mit eAU-Version 3.0 die nächste konkrete technische Evolutionsstufe. Die AU ab Tag 1 könnte zusätzlich erheblichen Einfluss auf das Verfahren bekommen, sobald daraus geltendes Recht wird. Und mit der Teilarbeitsunfähigkeit wartet für 2028 bereits die nächste große fachliche Erweiterung.
Jeder Sonderfall soll korrekt abbildbar sein. Das ist fachlich nachvollziehbar. Irgendwann steht man damit allerdings mitten im Bürokratiestau auf der Autobahn, jetzt eben digital.
Wir können nicht versprechen, dass die eAU in den nächsten Jahren einfacher wird.
Wir können aber dafür sorgen, dass Sie sich nicht selbst um die gesamte Komplexität kümmern müssen.
Mit und ganz Xisi-Peasy melden.