In den meisten polnischen KMU, mit denen wir das durchgehen, sieht das Bild gleich aus. Die Personalsachbearbeiterin macht die Lohnliste in einem System. Sie exportiert das als PDF und gibt es der Buchhalterin. Die Buchhalterin öffnet Excel, tippt die Beträge ins ERP und betet, dass sie sich nicht verrechnet. Das dauert 4 bis 8 Stunden im Monat, und der Fehler kommt meistens ans Licht, wenn ein Mitarbeiter eine um 200 zł zu niedrige Überweisung erhält und im Büro anruft.
Dieser Prozess lässt sich integrieren. Nicht für eine halbe Million, nicht mit einem SAP-Berater und nicht in einem Jahr. In der Regel in ein paar Wochen, mit dem, was du sowieso schon hast. Unten steht, was konkret zu tun ist und worauf man achten muss — aus der Sicht einer Firma, die das in polnischen KMU schon dutzendfach gemacht hat.
Woher das Chaos kommt
In einem typischen KMU mit 30-50 Personen leben HR-Lohn und Finanzen in getrennten Welten. Die Personalsachbearbeiterin arbeitet in enova365 oder in Symfonia Kadry i Płace, weil dort Verträge, Urlaub, Sozialabgaben, Zeiterfassung und alle polnischen „Kleinigkeiten" liegen, die das ERP nicht kann. Die Buchhalterin arbeitet in Comarch Optima oder Subiekt GT, weil dort Rechnungen gebucht, USt abgerechnet und JPK gemeldet werden. Beide Systeme laufen gut — jedes für sich.
Das Problem zeigt sich an der Naht. Die Lohnliste entsteht in HR, muss aber in den Büchern als vollständiger Satz von Buchungen auf Kosten- und Verbindlichkeitskonten landen. Jemand muss das rüberholen. In den meisten Firmen, die wir gesehen haben, macht das ein Mensch. Von Hand. Jeden Monat. Derselbe Mensch tippt jeden Monat dieselben Kontonummern und dieselben Positionen — nur mit anderen Beträgen.
Das ist nicht nur verlorene Zeit. Das ist eine Fehlerquelle, die drei Monate später hochkommt, wenn jemand die Lohnkosten auf einem Projekt prüft und plötzlich zweitausend złoty nicht stimmen. Dann fängt die Suche an, wer was wo eingetragen hat — und im Excel vom Juli steht nicht mehr, wer welchen Betrag geändert hat.
Ein konkretes Beispiel aus der Praxis
Bei einem unserer Kunden — einem 45-Personen-Betrieb der Fleischverarbeitung in Mittelpolen — arbeitete HR in enova365 und die Buchhaltung in Comarch Optima. Jeden Monat generierte die Personalsachbearbeiterin die Lohnliste, druckte das PDF, gab es der Buchhalterin, und die Buchhalterin verbrachte etwa 6 Stunden damit, 45 Mitarbeiter × mehrere Kostenkonten von Hand in Optima abzutippen. Dazu kamen ZUS (Sozialversicherung), PIT (Lohnsteuer) und Pfändungen — jeweils als separate Buchungen.
Im Durchschnitt einmal pro Quartal tauchte ein Fehler von 500-2000 zł auf, der im Folgemonat storniert werden musste.
Nach der Integration, die wir in drei Wochen geliefert haben: die Personalsachbearbeiterin arbeitet weiter in enova, generiert aber statt eines PDFs eine Exportdatei (eine an JPK-KR angelehnte Buchungsstruktur), die über eine Middleware direkt in Optima als fertige Buchungssätze landet — mit Konto, Kostenstelle und Projekt bereits zugeordnet. Die Buchhalterin sieht in Optima einen „Beleg zur Freigabe", prüft ihn in 20-30 Minuten und bucht ihn mit einem Klick. Abschreibfehler sind komplett verschwunden, weil niemand mehr etwas abtippt.
Die zurückgewonnenen 5-6 Stunden im Monat sind keine Revolution. Aber der 500-2000 zł Quartalsfehler, der wegfiel — schon, weil den vorher niemand zu den Prozesskosten gezählt hat.
Was konkret verbunden werden muss
Eine HR-Lohn ↔ ERP-Integration ist meistens kein „ein Webhook". Es ist ein Paket aus vier oder fünf Datenflüssen, die getrennt behandelt werden müssen, weil sie unterschiedliche Zyklen und Empfänger haben.
- Verbuchen der monatlichen Lohnliste. Monatlich, größtes Volumen. Braucht ein präzises Mapping: Lohnart → Kostenkonto + Kostenstelle.
- Auszahlungen an Mitarbeiter. Bankdatei (Elixir oder MT101) einmal im Monat. Meistens macht das die Bank über die ERP-Integration, aber die Beträge müssen mit der Lohnliste übereinstimmen.
- Sozialversicherungs- und Steuerabrechnungen. Getrennte Zahlungen, getrennte Konten, andere Fälligkeiten. Müssen im ERP als datierte Verbindlichkeiten landen, nicht als Aufwand.
- Abwesenheiten und Zeiterfassung. Wenn die Firma Stunden auf Projekte verteilt, müssen die Stunden aus HR in das Projektmodul im ERP fließen — sonst ist die Projektrentabilität Fiktion.
- Einstellungen und Austritte. Ein Statuswechsel (Neueinstellung, Vertragsende) sollte sofort ins ERP fließen — und in die Module, die es wissen müssen (z. B. Vertriebsnutzer im CRM).
Jeder dieser fünf Flüsse kann getrennt angegangen werden. Wir fangen meistens mit dem ersten an — der Verbuchung der Lohnliste — weil dort der größte Zeitverlust und das größte Fehlerrisiko liegt.
Wie das technisch funktioniert
Es gibt keine einzig richtige Architektur. In der Praxis funktionieren drei Ansätze in polnischen KMU.
- Datei-Export-Import. HR erzeugt eine Datei (XML, CSV, JSON), die in einen vereinbarten Ordner fällt. Eine Middleware liest sie stündlich aus und schiebt sie per API ins ERP. Einfach, günstig, für die meisten Firmen bis 100 Personen ausreichend.
- Direkte API. Das HR-System hat eine API (enova365 seit Jahren, Comarch seit kurzem), also verbinden wir sie direkt über eine Middleware-Schicht. Schneller, aber die API-Versionen auf beiden Seiten müssen gepflegt werden.
- Gemeinsame Datenbank. Selten empfohlen, kommt aber vor, wenn beide Systeme in derselben SQL-Server-Instanz liegen. Dann sind Views und Stored Procedures der einfachste Weg. Vorsicht bei Updates — die reißen die Integration über Nacht auf.
Bei jedem dieser Ansätze brauchst du eine Middleware-Schicht — und sei es nur ein PowerShell-Skript. Verbinde Systeme nicht „direkt auf Stoß", sonst reißt das erste Update auf einer der beiden Seiten die Verbindung, und du fragst dich, warum die Lohnliste nicht mehr durchkommt.
Was schiefgehen kann
Die häufigsten Fehler, die wir bei HR-ERP-Integrationen gesehen haben:
- Fehlendes Kontenmapping. Du startest das Projekt, die Personalsachbearbeiterin sagt „ich weiß, wie das geht", und nach einem Monat stellt sich heraus, dass niemand weiß, auf welches Konto „Ermessensprämie" gebucht werden soll. Ergebnis: die Integration steht, bis die Buchhaltung und die Geschäftsführung sich einigen. Mach das Mapping schriftlich, bevor du eine Zeile Code schreibst.
- Korrekturen ignorieren. Menschen werden krank, buchen Überstunden nachträglich, bekommen Nachzahlungen. Die Integration muss Korrekturen können — sonst hast du jeden Monat manuelle Nacharbeiten, die den Sinn der Automatisierung aufheben.
- Daten ohne Freigabe schicken. Wir haben einmal eine Firma so integriert, dass die Daten nachts automatisch von HR ins ERP flossen. Die Personalsachbearbeiterin hatte einmal vergessen, den Monat abzuschließen — eine unvollständige Lohnliste landete im ERP. Seither bauen wir immer einen „freigeben und senden"-Schritt auf der HR-Seite ein. Automatisierung ohne menschlichen Checkpoint ist gefährlich.
- Kein Log. Wenn etwas nicht durchgeht, willst du wissen, was und wann. Die Middleware sollte jede Operation mit ID, Zeitstempel und Status protokollieren. Im Audit (und beim Mitarbeiter, der wegen der fehlenden Überweisung anruft) rettet dir das den Abend.
Wie geht es weiter
Eine HR-Lohn ↔ ERP-Integration ist kein Technologieprojekt, sondern ein Organisationsprojekt mit einer technischen Schicht. Die größte Herausforderung ist nicht der Code, sondern die Einigung mit Buchhaltung und HR darüber, was wohin geht und in welcher Form. Der Code selbst sind meistens 5-15 Arbeitstage.
Wenn bei dir immer noch jemand jeden Monat die Lohnliste von einem System ins andere abtippt — das ist ein realer Kostenpunkt, der nur selten mitgezählt wird. Ein paar Stunden im Monat mal dem Stundensatz der Buchhaltung, dazu regelmäßige Fehler und Quartalsstress. Ein Integrationsprojekt rechnet sich typischerweise in 4-6 Monaten.
Wenn du sehen willst, wie das konkret bei dir aussehen würde — welche Systeme du hast, wo der eigentliche Engpass sitzt — das erste Gespräch ist kostenlos und dauert eine halbe Stunde.
Die Lohnliste von Hand abzutippen ist kein IT-Problem. Es sind 6 Stunden im Monat und ein 500-2000 zł Quartalsfehler, den niemand zu den Prozesskosten zählt.