#38 - Oktober 2026
Receivables
Sammelübergabe an das Inkasso aus Beleg-Übersicht
Was sich geändert hat:
Neue Sammelaktion „An Inkasso übergeben“ im Stapel-Dropdown der Beleg-Übersicht (einschließlich aller gefilterten Ansichten/Arbeitslisten) und im Buchungs-Tab des Kunden
Eine Auswahl über viele Kunden hinweg wird in einem Durchgang verarbeitet: Ein Bestätigungsdialog zeigt die Anzahl der Einträge, die Anzahl der Kunden und die Summen je Währung an. Anschließend läuft die Übergabe im Hintergrund mit einem Fortschrittsbalken ab.
Eine Zusammenfassung pro Kunde am Ende listet die übergebenen und die fehlgeschlagenen Einträge samt Grund auf
Warum das wichtig ist:
Bisher funktionierte die manuelle Übergabe nur innerhalb eines einzelnen Kunden. Debitorenteams, die mit gefilterten Listen arbeiten, können jetzt einen ganzen Stapel überfälliger Posten eskalieren, ohne jeden Kunden einzeln zu öffnen.
Buchungstext in Klärungsexporten
Was sich geändert hat:
Das Layout für den Klärungsexport enthält eine neue optionale Spalte „Beleg Text“ (EN: „Journal Entry text“), die neben den anderen Belegspalten platziert ist.
Sie funktioniert in CSV-, XLSX- und geplanten Klärungsexporten, die das Layout verwenden.
Die Zelle bleibt bei Klärungen ohne Beleg leer, zum Beispiel bei abzugsbasierten Klärungen.
Ausstehende Gründe und Freitextantworten im Klärungsexport
Was sich geändert hat:
Das Layout für den Klärungsexport enthält drei neue Spalten: Letzter Grund, Letzte zusätzliche Gründe, Letzte Freitextantwort. Sie zeigen die Antwort an, die die Klärungsliste anzeigt, auch wenn sie noch nicht akzeptiert wurde.
Alle Grundspalten im Überblick:
Letzter Grund / zusätzliche Gründe / Freitextantwort: die in dieser Runde aktuell relevante Antwort (ausstehend, akzeptiert, abgelehnt oder abgelaufen)
Aktueller Grund / zusätzliche Gründe / Freitextantwort: die in dieser Runde akzeptierte Antwort
Zuletzt akzeptierter Grund: die zuletzt akzeptierte Antwort über alle Runden hinweg, auch aus der Zeit vor einem Neustart
Überarbeitete obere Kopfzeile
Was sich geändert hat:
Aufgeräumtere Kopfzeile: ein kleineres Logo ohne dunklen Block, eine beschriftete „Menü“-Schaltfläche, die sich beim Darüberfahren öffnet und per Tastatur bedienbar ist (Pfeiltasten zum Navigieren, Escape zum Schließen), sowie besserer Kontrast für den blassgrauen und blauen Text.
Am Ende des Menüs werden jetzt für alle Nutzer der Firmenname und die Firmen-ID angezeigt. Klicken Sie auf die ID, um sie zu kopieren. Nutzer mit mehreren Firmen sehen ihre Firmen-ID zusätzlich neben ihrem Profilbild auf Bildschirmen ab 1200 px Breite. Der Breadcrumb „Funktionsgruppe > Seite“ entfällt, da er bereits in der Subnav-Leiste angezeigt wird.
Die Tastenkürzel-Hinweise zeigen ⌘ auf dem Mac und Strg unter Windows. ⌘E (Menü) und ⌘B (Suche) lösen nicht mehr die browsereigenen Tastenkürzel aus. Profilmenü > Wissensdatenbank öffnet jetzt docs.bilendo.de auf Deutsch oder Englisch.
Warum das wichtig ist:
Die Kopfzeile ist leichter lesbar und schneller zu bedienen, und die Firmen-ID ist immer nur einen Klick entfernt, wenn der Support oder eine Integration danach fragt.
Login-Authentifizierung für Posteingangsserver
Was sich geändert hat:
Das Dropdown-Menü für die Authentifizierung bei Posteingangsservern (IMAP) bietet jetzt neben „Plain“ auch „Login“ an. Login meldet sich mit dem IMAP-Befehl
LOGINmit Benutzername und Passwort an.Wenn der Mailserver die Anmeldung deaktiviert hat (
LOGINDISABLED), schlägt der Verbindungstest mit einer Meldung fehl, die den Server und die abgelehnte Methode nennt.Wird die Authentifizierungsmethode bei einem aktiven Server geändert, wird dieser deaktiviert. Der Kunde muss ihn erneut aktivieren, wobei der Verbindungstest mit der neuen Methode ausgeführt wird. Bestehende Server bleiben auf Plain und funktionieren weiterhin.
Warum das wichtig ist:
Kunden mit eigener Mail-Infrastruktur konnten das Antwort-Tracking nicht verbinden, wenn ihr Server Plain nicht unterstützt, und Microsoft OAuth war die einzige Alternative. Jetzt können sie sich einfach mit Benutzername und Passwort verbinden.
Drilldown von den Beträgen in Fälligkeitsstruktur zu den Buchungssätzen
Was sich geändert hat:
Die Summenbeträge in Fälligkeitsstruktur (Aging Report) sind jetzt anklickbar: Fällige Forderungen / Offen (fällig), Offen (nicht fällig), Gesamt / Gesamtforderungen und Gesamtguthaben / Nicht zugeordnetes Guthaben. Das funktioniert im Kopfbereich und in jeder Tabellenzeile, einschließlich erweiterter verschachtelter Zeilen.
Ein Klick öffnet die Liste der Buchungssätze (oder, im Analytics-Tab eines Kunden, den Tab mit den Buchungssätzen dieses Kunden). Die Liste ist bereits auf offene Forderungen oder offene Guthaben vorgefiltert und übernimmt die Artikel- und Benutzerdefinierte-Felder-Filter sowie die Währung des Berichts, sodass die Listensumme mit dem angeklickten Betrag übereinstimmt. Der Saldo bleibt ohne Link, da er Forderungen und Guthaben miteinander verrechnet.
Warum das wichtig ist:
Nutzer müssen die Filter des Reports nicht mehr manuell in der Belegübersicht nachbauen, um herauszufinden, woraus sich eine Kennzahl zusammensetzt. Besonders wichtig ist das bei Gutschriften, bei denen bisher nicht ersichtlich war, welche Belege den Betrag ausmachen.
Neue PDF-Vorschau: funktioniert in jedem Browser, mit Download und Druck
Was sich geändert hat:
PDF-Vorschauen in Bilendo verwenden jetzt unseren eigenen Viewer statt des im Browser integrierten. Sie laden in jedem Browser auf die gleiche Weise, auch in Safari, wo Vorschauen zuvor beim Ladesymbol hängen blieben.
Die Vorschau-Symbolleiste bietet Seitennavigation mit Seitenzähler, Vergrößern und Verkleinern, Seitenbreite, ganze Seite und neu auch Download und Drucken. Der Download speichert die Datei unter ihrem ursprünglichen Namen.
Vorschauen öffnen sich in Seitenbreite, sodass Dokumente ohne Vergrößern lesbar sind. Die Dateischnellvorschau und die Vollbild-Vorschau von Klärungsanhängen zeigen weiterhin die ganze Seite.
Warum das wichtig ist:
Mahnungen, Briefe, Rechnungen und Anhänge können direkt in Bilendo geprüft, gespeichert und gedruckt werden – in jedem Browser und ohne die Datei vorher anderswo zu öffnen.
Mahnsperrgründe
Was sich geändert hat:
Jede manuelle Mahnsperre bei einem Kunden oder Buchungsposten enthält jetzt einen Mahnsperrgrund, der aus einem Katalog pro System ausgewählt wird (auch beim Setzen für mehrere Buchungsposten von der Kundenseite aus, beim Abschluss einer Klärung, bei Workflow-Nebeneffekten und bei Zahlungsversprechen; optionales Ablaufdatum).
Mahnsperrgründe aus dem ERP (SAP-Feld MANSP) werden für Kunden und Buchungsposten importiert, schreibgeschützt angezeigt und laufen ab, sobald ein späterer Import sie nicht mehr liefert.
Der Grund erscheint in der Historie der Mahnsperren, als Spalte und Filter in den Kunden- und Buchungspostenlisten sowie im Export mit seiner Beschreibung und je einem Feld für den manuellen und den externen ERP-Code, sodass in Bilendo gesetzte Gründe an das ERP zurückgegeben werden können.
Warum das wichtig ist:
Debitorenteams sehen auf einen Blick, warum ein Konto oder Posten gesperrt ist, statt es im ERP nachschlagen zu müssen, und in Bilendo beschlossene Sperren tragen einen Code, den das ERP versteht. Jede Sperre ist in der Historie nachvollziehbar, was Audits und Übergaben erleichtert.
Mahnsperrgrund wird beim Schließen einer Klärung vorausgewählt
Was sich geändert hat:
Wenn ein Konto genau einen auswählbaren manuellen Mahnsperrgrund hat (bei Konten ohne eigene Gründe „Manual Dunning Block“), wird dieser jetzt vorausgewählt, wenn eine Klärung mit einem Mahnstopp geschlossen wird („Manuellen Mahnstopp bis zum Wiedervorlagedatum hinzufügen“ im Schließen-Dialog). Der Sachbearbeiter kann schließen, ohne das Dropdown zu bedienen, und der Mahnstopp wird mit diesem Grund gespeichert und in der Mahnstopp-Historie angezeigt.
Dieselbe Vorauswahl gilt jetzt auch im Batch-Modal „Manuellen Mahnstopp hinzufügen“ und im Mahnstopp-Modal eines Journaleintrags. Die Zahlungszusage funktionierte bereits auf diese Weise und nutzt nun dieselbe Logik.
Bei Konten mit mehreren Gründen erfolgt keine Vorauswahl, und es wird wie bisher ein Grund ausgewählt. Im Journaleintrags-Modal gibt es außerdem keine Vorauswahl, solange ein weiterer entfernbarer Mahnstopp auf diesem Eintrag aktiv ist, damit kein manueller Stopp hinzugefügt wird, den der Benutzer nicht angefordert hat.
Warum das wichtig ist:
Seit der Einführung der Mahnsperrgründe erforderte das Schließen einer Klärung mit einem Mahnstopp einen zusätzlichen Klick, selbst wenn das Dropdown nur eine Option anbot. Dieser Klick entfällt für diese Konten, und der Arbeitsablauf ist wieder so schnell wie zuvor.
Geschäftsbereich im Dropdown der Vertriebseinheit der Klärung
Was sich geändert hat:
Wenn eine Klärung neu zugewiesen wird (Bearbeitungsdialog für Gebiet, Geschäftsbereich und Vertriebseinheit), zeigt jede Vertriebseinheit im Dropdown nun ihr Gebiet und ihren Geschäftsbereich als graue Zusatzinformation neben dem Namen an, in der Form Gebiet ➝ Geschäftsbereich.
Eine Vertriebseinheit ohne Geschäftsbereich zeigt nur ihr Gebiet an. Die Suche berücksichtigt weiterhin den Namen der Vertriebseinheit.
Nur dieses Dropdown ändert sich. Alle anderen Stellen, an denen Vertriebseinheiten aufgelistet werden, zeigen weiterhin nur das Gebiet an.
Warum das wichtig ist:
Das Dropdown ist bereits auf ein Gebiet gefiltert. Daher zeigte bisher jeder Eintrag denselben Gebietsnamen, und die Vertriebseinheiten sahen gleich aus. Sachbearbeiter, die mehreren Vertriebseinheiten angehören, können jetzt die richtige auswählen, ohne raten zu müssen.
Klärungen nach Grund filtern
Was sich geändert hat:
Die Klärungsliste hat einen neuen Filter Grund (Mehrfachauswahl). Er bietet die erforderlichen Gründe des Unternehmens sowie „Sonstiger Grund“ (eine akzeptierte Antwort ohne Grund).
Er lässt sich mit den anderen Filtern der Liste kombinieren. Drilldowns aus den Berichten zu Klärungsgründen öffnen die Liste jetzt mit dem Filter „Grund“ und dem vorausgewählten Grund, anstatt mit einem unsichtbaren Filter.
Gründe, die bereits in Antworten verwendet werden, gehen nicht mehr verloren, wenn sie jemand löscht: Sie werden archiviert, bleiben im Filter „Grund“ mit dem Badge „Archiviert“ auswählbar und werden in den anderen Gründelisten ausgeblendet.
Warum das wichtig ist:
Sachbearbeiter müssen lange Arbeitslisten nicht mehr von Hand durchsuchen. Sie können direkt zu beispielsweise allen Klärfällen springen, die mit „Mahnlauf fortsetzen“ beantwortet wurden, und diese in einem Zug übernehmen oder schließen.
Differenzgrund im Klärfall
Was sich geändert hat:
Der Klärfall zeigt jetzt den Differenzgrund (Code und Beschreibung, z. B. ST - Steuer) der verknüpften Buchung in den erweiterten Buchungsdetails an (Bezeichnung „Differenzgrund“ / „Difference Reason“).
Derselbe Wert erscheint in der Hovercard der Buchung.
Hat die Buchung keinen Differenzgrund oder hat der Klärfall keine verknüpfte Buchung, wird nichts angezeigt (keine leere Bezeichnung).
Warum das wichtig ist:
Der Differenzgrund ist die eigene Antwort des ERP-Systems darauf, warum eine Position strittig ist oder zu wenig bezahlt wurde. Sachbearbeiter müssen den Beleg nicht mehr öffnen, um zu verstehen, warum ein Klärfall besteht.
Mahnstopp-Filter im Fälligkeitsbericht
Was sich geändert hat:
Der Fälligkeitsbericht hat zwei neue Filter: „Mahnstopp“ und „Mahnsperrgrund“, mit denselben Optionen wie in der Liste der offenen Posten. Der Filter für den Sperrgrund wird nur angezeigt, wenn ihn auch die Liste der offenen Posten anzeigt (Mahnsperrgründe aktiviert).
Summen, Fälligkeitsintervalle und Gutschriften berücksichtigen nur die passenden Posten, also dieselben Posten, die die Liste der offenen Posten mit diesem Filter anzeigt. Die Filter gelten auch für die Kundenseite, verschachtelte Posten und den Drilldown zur Buchungsliste.
Beide Filter lassen sich miteinander und mit bestehenden Filtern (z. B. Buchungskreis) kombinieren und in einem vorkonfigurierten Fälligkeitsbericht auf einem Dashboard speichern. Ohne Auswahl verhält sich der Bericht wie bisher.
Warum das wichtig ist:
Posten mit Mahnstopp sind absichtlich zurückgestellt, blähen aber die Summen im Fälligkeitsbericht auf und verdecken, was das Team tatsächlich bearbeiten kann. Jetzt kann ein gespeicherter Bericht pro Buchungskreis nur einbringbare Forderungen oder nur die zurückgestellten anzeigen.
Links in Kommentaren: Autolink und neuer Tab
Was sich geändert hat:
• Eine in einen Kommentar eingegebene oder eingefügte URL wird automatisch zu einem anklickbaren Link, sobald ein Leerzeichen oder die Eingabetaste folgt. Der Text muss nicht mehr markiert und die Link-Schaltfläche in der Symbolleiste verwendet werden.
• Links in Kommentaren öffnen sich in einem neuen Browser-Tab, sodass Nutzer auf der Bilendo-Seite bleiben. Das gilt auch für bereits vorhandene Kommentare, da der neue Tab beim Anzeigen des Kommentars festgelegt wird.
• Funktioniert im Kommentarformular und in den Kommentarfeldern der Klärungsabläufe (akzeptieren, ablehnen, Konflikte lösen, Gruppenkommentar pro Posten, Klärungsnachricht).
Warum das wichtig ist:
Wer in Kommentaren externe Quellen dokumentiert, zum Beispiel Akten von Auskunfteien, spart pro Link mehrere Klicks. Außerdem verliert man beim Öffnen eines Links nicht mehr seinen Platz in Bilendo.
Fälligkeitsstrukturbericht zum Stichtag
Was sich geändert hat:
Die Filterleiste des Fälligkeitsstrukturberichts enthält jetzt den Filter „Stichtag (aktuell, wenn leer)“, den bisherigen Filter „Offen am“, begrenzt auf heute. Bleibt er leer, verhält sich der Bericht genau wie bisher und verwendet offene Beträge.
Bei gesetztem Stichtag werden nur Buchungssätze berücksichtigt, die an diesem Tag offen waren. Die Zeitintervalle (Buckets) werden relativ zum Stichtag berechnet, nicht relativ zu heute. Auch das Alter der „Ältesten Forderung“ auf der Kundenseite wird ab dem Stichtag gezählt.
Bei gesetztem Stichtag sind alle Beträge und Summen Buchungssatzbeträge statt offener Beträge. Ein Warnhinweis über dem Bericht und auf der Kundenseite erklärt, warum. Drilldown-Links übernehmen den Stichtag, sodass die Buchungssatzlisten mit dem Bericht übereinstimmen.
Ein Stichtag, der nicht interpretiert werden kann oder in der Zukunft liegt, führt zurück zum aktuellen Bericht.
Auch die Buchungssatzlisten (Filterleiste, gespeicherte Filter, Exporte) ändern sich: In Kombination mit „Offen am“ richten sich die Filter für den Fälligkeitsstatus und die Zeitintervalle nun nach diesem Datum statt nach heute. „Offen am“ selbst bleibt unverändert.
Warum das wichtig ist:
Kunden können die Fälligkeitsstruktur für ein vergangenes Berichtsdatum (Monatsende, Quartalsende, Prüfungsanfrage) rekonstruieren, statt nur den aktuellen Live-Status zu sehen. Der Hinweis macht deutlich, dass die Zahlen eine andere Grundlage haben als der Live-Bericht.
Kundensaldo im Export der Buchungssätze
Was sich geändert hat:
Das Layout des Buchungssatz-Exports enthält ein neues Feld „Customer balance“ (DE: „Kunden-Saldo“). Es wird wie die anderen Betragsfelder in CSV und XLSX formatiert.
Der Webhook-Export der Buchungssätze enthält eine neue Spalte customer_balance, die am Ende angehängt wird, sodass die bestehende Spaltenreihenfolge unverändert bleibt (in XML: ein Element <customer_balance>).
Jede Zeile zeigt den Saldo des Kunden des Buchungssatzes, also denselben Wert wie die Spalte „Kunden-Saldo“ in der Buchungssatz-Übersicht. Ein Kunde ohne gespeicherten Saldo zeigt 0.
Zu beachtender Nebeneffekt: JSON-Webhooks und die Buchungssatz-Antworten der API v2 enthalten jetzt ebenfalls customer_balance.
Warum das wichtig ist:
Sachbearbeiter, die die Offene-Posten-Liste außerhalb von Bilendo bearbeiten, müssen den Saldo jedes Kunden nicht mehr nachschlagen und von Hand hinzufügen.
Ergebnisse der globalen Suche öffnen sich in einem neuen Tab
Was sich geändert hat:
• Kundentreffer in der globalen Suche sind jetzt über die gesamte Zeile echte Links, sodass Rechtsklick „In neuem Tab öffnen“, Mittelklick und Cmd/Strg+Klick funktionieren.
• Das Gleiche gilt für Treffer bei Buchungssätzen in der globalen Suche.
• Die Navigation mit den Pfeiltasten und die Eingabetaste funktionieren weiterhin wie bisher.
Warum das wichtig ist:
Nutzer können mehrere Kundendatensätze nebeneinander öffnen, ohne ihre Suchergebnisse oder ihre Position in der Liste zu verlieren. Das erspart wiederholtes Suchen, wenn Kunden verglichen oder mehrere Kunden nacheinander bearbeitet werden.
Ruhigere Seitenleiste, skalierbare gespeicherte Ansichten und eine dezentere Listenfußzeile
Was sich geändert hat:
• Seitenleiste: Abstände statt Trennlinien, dezentere Abschnittstitel, jeweils nur eine hervorgehobene Zeile (hellblaue Pille), Zähler als Badges am rechten Rand, Zähler mit Wert null werden ausgeblendet.
• Gespeicherte Ansichten: Der Abschnitt ist einklappbar und zeigt Ordner sowie die ersten 5 Ansichten und die geöffnete Ansicht. „Alle N anzeigen“ öffnet das Pop-up „Alle gespeicherten Ansichten“ mit Suche und einem Bearbeitungsmodus (Neuanordnen, Umbenennen, Löschen, Ordner hinzufügen). Ein Papierkorb beim Darüberfahren löscht eine Ansicht oder einen Ordner nach Bestätigung. Im Dialog „Ansicht speichern/bearbeiten“ kann direkt ein Ordner angelegt werden; zudem gibt es „Kein Ordner“ und eine Erklärung zu „Standardansicht“. Drag-and-drop, die Pokal-Markierung für die Standardansicht und die Anheftung an die Startseite funktionieren weiterhin. Das Entfernen der geöffneten Ansicht über den Chip in der Filterleiste erfordert jetzt eine Bestätigung.
• Listenfußzeile (alle Listenseiten sowie Export unter Einstellungen → Benutzer und Sicherheitsereignisse): Die Ergebnisanzahl wird als einfacher Text statt als rotes Badge angezeigt („9.999+“ bleibt anklickbar, um die vollständige Anzahl zu laden). Export und Tabellendesign sind graue Textschaltflächen ohne Symbole, getrennt durch eine Trennlinie.
• Einstellungen: Die Suche in der Seitenleiste bleibt beim Scrollen oben stehen, und der Abschnitt „Klärungen“ in den Einstellungen ist standardmäßig eingeklappt.
Warum das wichtig ist:
Listenseiten wirken weniger überladen, und Benutzer mit vielen gespeicherten Ansichten und Ordnern können diese finden, sortieren und aufräumen, ohne durch eine lange Seitenleiste scrollen zu müssen.
Eigenes Zugriffsrecht für benutzerdefinierte Felder
Was sich geändert hat:
• Benutzerrollen haben ein neues Recht „Benutzerdefinierte Felder“, das unter Kunden, Journaleinträgen und Aufträgen eingeordnet ist, mit den üblichen Stufen: Lesen und Schreiben, Lesen, Kein Zugriff.
• Eine Rolle kann jetzt die benutzerdefinierten Felder eines Kunden bearbeiten, ohne die Kundendetails bearbeiten zu dürfen. Nur Felder, die als vom Benutzer aktualisierbar eingerichtet sind, können überhaupt bearbeitet werden; importierte oder per API befüllte Felder bleiben schreibgeschützt.
• „Kein Zugriff“ blendet die Werte benutzerdefinierter Felder für dieses Objekt überall aus: in der Detailansicht, in Listen, Filtern, Exporten, Berichten und Kennzahlen-Kacheln. Bestehende Rollen wurden auf die Stufe ihres übergeordneten Rechts migriert, sodass bei der Veröffentlichung niemand Zugriff gewonnen oder verloren hat.
Warum das wichtig ist:
Teams, in denen Kollegen benutzerdefinierte Felder pflegen (Klassifizierungen, interne Kennzeichen, Datenqualität), müssen diesen nicht mehr zusätzlich Schreibzugriff auf die Stammdaten geben.
So ändern Sie es:
• Einstellungen > Benutzerverwaltung > Benutzerrollen: Die neue Zeile „Benutzerdefinierte Felder“ befindet sich direkt unter Kunden, Journaleinträgen und Aufträgen.
• Das Unterrecht kann das Recht des jeweiligen Objekts nie überschreiten: „Kunden: Kein Zugriff“ blendet auch die benutzerdefinierten Felder der Kunden aus.
• Es ändert sich nichts, bis ein Administrator eine Rolle anpasst, da jede Rolle bei der Veröffentlichung ihren bisherigen Zugriff behalten hat.
Vorgesetzter am Benutzer als Eskalationsziel für Klärungen
Was sich geändert hat:
Jeder Benutzer kann nun eine optionale Führungskraft haben (ein aktiver Benutzer desselben Unternehmens). Sie wird im Tab „Zuständigkeiten & Zugriff“ des Benutzers (zuvor „Zugriffsrechte“) festgelegt, auf der Benutzerseite und in der Benutzerliste angezeigt und kann über eine optionale Spalte „Manager E-Mail“ importiert werden. Ein Benutzer kann nicht seine eigene Führungskraft sein, und Berichtslinien dürfen keinen Zyklus bilden.
Klärungs-Workflows bieten die Führungskraft des Bearbeiters an drei Stellen an: als Eskalationsstufe („an Manager des Bearbeiters“), als Neustart-Einstellung („Manager einbeziehen (Bearbeiter)“) und als Bearbeiterquelle. Sie kann auf anderen Stufen desselben Workflows mit der Team- oder BU-Führungskraft kombiniert werden.
Wenn die Stufe ausgelöst wird, geht die Anfrage an die Führungskraft des aktuellen Bearbeiters, und das Ereignisprotokoll nennt diese Führungskraft. Gibt es keinen Bearbeiter oder keine Führungskraft, wird niemand neu zugewiesen, und das Protokoll hält fest, dass es keinen Empfänger gab (wie bei einer BU-Manager-Eskalation ohne Manager).
Warum das wichtig ist:
Benutzer in mehreren Teams ziehen nicht mehr eine ganze Gruppe in jede Eskalation hinein, und Matrix- oder Shared-Service-Strukturen erreichen die tatsächlich verantwortliche Person. Die Berichtslinie wird einmal in der Benutzerverwaltung gepflegt, und jeder Workflow kann ihr folgen.
Bereichsleiter als Eskalationsziel für Klärungen
Was sich geändert hat:
Bereiche haben nun eine optionale Führungskraft, die im Bereichsformular in den Einstellungen wie die Führungskraft einer Business Unit festgelegt und in der Bereichsliste angezeigt wird.
Klärungs-Workflows bieten den Bereichsleiter als Eskalationsstufe („an Manager von [Bereich]“), in der Neustart-Einstellung („Manager einbeziehen ([Bereich])“) und als Bearbeiterquelle an. Er kann auf einer anderen Stufe mit der Führungskraft der Business Unit kombiniert werden, z. B. zuerst BU-Manager, danach Bereichsleiter.
Bereichsleiter sehen die an sie eskalierten Klärungen unter „An mich eskaliert“. Hat ein Bereich keine Führungskraft, verhält sich die Stufe wie eine BU-Manager-Stufe ohne Manager: kein Empfänger, und die Timeline weist darauf hin.
Warum das wichtig ist:
Kunden, die nach Region oder Land organisiert sind, erhalten eine echte zweite Eskalationsstufe oberhalb des BU-Managers. Es sind keine separaten Workflows pro Gebiet mehr nötig und auch keine Teams, die nur existieren, um einen Manager abzubilden.
Übersetzung von benutzerdefinierten Feldern
Was sich geändert hat:
• Neuer Einstellungsbereich „Übersetzungen benutzerdefinierter Felder“ unter Unternehmensstruktur
• Titel und Beschreibung jedes benutzerdefinierten Felds können in bg, cs, de, en, es, fr, hu, it, pl, ro übersetzt werden (von Bilendo unterstützte Sprachen)
• Benutzer sehen die Bezeichnungen benutzerdefinierter Felder überall in ihrer eigenen Sprache: in Detailansichten, Bearbeitungsdialogen, Tabellenköpfen, Filtern, Kennzahlen und im Tabellendesign
Warum das wichtig ist:
Benutzer in anderen Ländern sehen keine Bezeichnungen mehr, die sie nicht verstehen. Dadurch sind benutzerdefinierte Felder für internationale Teams nutzbar.
Kommentar-Benachrichtigungen in Oberflächenvorlagen
Was sich geändert hat:
• Der Tab „Benachrichtigungen“ einer Oberflächenvorlage enthält jetzt einen Bereich „Kommentare“. Administratoren können pro Rolle E-Mail ein- oder ausschalten und den Rhythmus festlegen. Außerdem können sie die Einstellung wie bei den anderen Benachrichtigungsbereichen über die Vorlage vorgeben oder sperren.
Warum das wichtig ist:
Administratoren können jetzt sinnvolle Standardwerte für Kommentar-Benachrichtigungen für ganze Rollen festlegen, statt sich darauf zu verlassen, dass jeder Benutzer sie selbst konfiguriert. Benutzer, die für Kommentare eine tägliche oder wöchentliche Zusammenfassung gewählt haben, erhalten ihre E-Mails jetzt tatsächlich.
Risk
Risikoübersicht | Komplett neu gestalteter Header des Tabs „Risikomanagement“
Vorher → Nachher
Vorher: Kreditlimit, Risikoklasse und Score befanden sich in getrennten Blöcken. Die Risikoklasse verwendete dasselbe kleine Label wie die Indexseite.
Vorher: Man konnte nur schlecht erkennen, ob eine Risikoklasse dem Score folgte oder manuell festgelegt wurde, oder wo der Score innerhalb seines Klassenbereichs lag.
Vorher: Es gab auf der Seite nirgends Trends. Um zu sehen, ob sich das Zahlungsverhalten verbessert oder verschlechtert, musste man sich durch Berichte arbeiten.
Nachher: eine Karte in voller Breite, die die Frage beantwortet: „Wie riskant ist dieses Konto aktuell, und in welche Richtung entwickelt es sich?“ – ohne die Seite zu verlassen.
Was ist neu – Bereich für Bereich
Kreditlimit
Betrag, Ablaufdatum und ein neuer Auslastungsbalken (genutzt / frei in € und %)
Bedingungen-Badge mit Anzahl. Ein Klick darauf zeigt den vollständigen Text in einem Popover (kein „Mehr anzeigen“ mehr)
Unbesichertes Limit mit einem Chip für den gedeckten Betrag; das nicht versicherte Risiko wird angezeigt, wenn eine Deckung einen Selbstbehalt hat
Risikoklasse + Score
Kachel für die Risikoklasse in der Klassenfarbe, mit einem Änderungsindikator (z. B. B → C), wenn sich die Klasse beim letzten Scoring-Lauf verändert hat
Score-Kachel daneben mit direktem Link zum Berechnungsprotokoll
Neue Risikoklassen-Skala mit allen Klassen, Bandgrenzen und einer Score-Markierung, sodass Sie sehen, wo der Score innerhalb seiner Klasse liegt
Manuelle Klassen sind klar gekennzeichnet: graue Leiste, Klasse in der Mitte, keine Score-Markierung. Ein Kommentarsymbol öffnet den vollständigen Verlauf
Bilendo Risikobewertung (neu)
Eine kurze generierte Zusammenfassung des Zahlungsverhaltens (ADP/DBT), der Score-Entwicklung und der Limitauslastung über die letzten 12 Monate
Feste Satzstruktur, damit Kunden vergleichbar sind. Sie klassifiziert, sie gibt keine Empfehlung ab
Wann wird sie angezeigt? Nur wenn genügend Daten für eine faire Aussage vorliegen:
der Kunde hat ein aktives Kreditlimit (wird bei Kunden mit reinem Vorschlag nicht angezeigt)
die Score-Historie reicht 12 Monate zurück
ADP und DBT lassen sich aus bezahlten Posten in der Policenwährung über die letzten 12 Monate berechnen
Zusätzliche Klauseln erscheinen nur, wenn sie relevant sind: der nicht versicherte Betrag (nur bei Kreditversicherung) und der Ablaufhinweis (Limit läuft in ≤ 60 Tagen ab)
„Spürbare“ Veränderung = ±3 Score-Punkte oder ±2 Tage ADP/DBT. Darunter steht im Text, dass sich der Wert kaum bewegt hat bzw. stabil ist
Trends – 12 Monate (neu)
Score, ADP und DBT mit Sparklines und der 12-Monats-Veränderung (rot = wesentlich, gelb = moderat)
Jede Kennzahl wird angezeigt, sobald sie verfügbar ist. Dadurch kann ein Kunde Trends, aber keine Bewertung haben
„Details“ öffnet ein kombiniertes Modal mit dem Diagramm „Risikoklasse & Score“ und dem Zahlungsverhalten
Überall einheitlich
Die neue Skala wird auch im Risikoklassen-Modal, im Header des Score-Tabs und in der Übersicht der Kreditlimitvorschläge verwendet
Kunden mit nur einem Vorschlag (noch ohne Limit) erhalten dieselbe Karte statt des bisherigen „Ausstehend“-Blocks
Das Design der Konditionen ist über Karte, Seitenleiste und Historie hinweg vereinheitlicht
Warum das wichtig ist
Kreditmanager sehen das vollständige Risikobild eines Kunden in Sekunden: das aktuelle Obligo, wie die Risikoklasse zustande kam und ob sich die Lage verbessert oder verschlechtert. Und das alles, ohne Tabs zu wechseln oder Berichte zu öffnen.
Währungsumrechnung für 166 Währungen im Credit Management
Was sich geändert hat:
Wechselkurse stammen jetzt von ExchangeRate-API (166 Währungen) statt aus dem EZB-Referenzkurs-Feed (etwa 29 Währungen).
Kreditrichtlinien, Kreditlimitvorschläge und der FCS-Score können jetzt Währungen umrechnen, die die EZB nie abgedeckt hat, zum Beispiel AED, SAR, MAD, EGP und NGN.
Die Kurse werden täglich um 06:00 UTC synchronisiert, einschließlich Wochenenden (zuvor werktags um 17:00 UTC). Der Tooltip bei umgerechneten Beträgen lautet jetzt „Wechselkurs vom <Datum>“ statt „EZB-Kurs vom <Datum>“.
Konfigurierbares PDF zur Kreditlimitentscheidung
Was sich geändert hat:
Administratoren können das PDF zur Kreditlimitentscheidung unter Einstellungen › Risiko › PDF zur Kreditlimitentscheidung konfigurieren: Abschnitte ein- oder ausschließen, per Drag & Drop neu anordnen sowie pro Abschnitt „Auf neuer Seite beginnen“ und „Abschnitt ausblenden, wenn keine Daten vorhanden sind“ festlegen.
Drei neue Abschnitte: Kennzahlen (KPI-Kacheln: Saldo, Umsatz YTD, Umsatz Vorjahr, Offene Posten, ADP, DBT, auswählbar), Bilanzanalyse und Zusätzliche Informationen (ausgefüllte Felder für zusätzliche Informationen).
Live-Vorschau mit Seitenanzahl, alternativ als Strukturvorschau. Schreibgeschützt: keine Entscheidung, kein gespeichertes Dokument, keine Benachrichtigung.
Warum das wichtig ist:
Kunden haben unterschiedliche Genehmigungsprozesse und Datenquellen. Bisher bedeutete jede Änderung am PDF eine Codeänderung auf unserer Seite. Administratoren können das Dokument jetzt selbst an ihren eigenen Prozess anpassen.
Bilanzanalyse: Jahres-, Quartals- und Monatsansichten
Was sich geändert hat:
Die Bilanzdaten sind jetzt in drei Bereiche unterteilt: Jährlich, Quartalsweise und Monatlich. Jeder Bereich zeigt eigene Daten und KPIs.
Nach dem Erstellen einer Bilanzanalyse über die Kundenseite gelangen Nutzer direkt in die neue Analyse.
Ein Fehler wurde behoben, durch den Kommentare zu Bilanzanalysen nicht gespeichert werden konnten.
Warum das wichtig ist:
Kunden können Entwicklungen pro Berichtszeitraum analysieren, ohne Daten zu vermischen, zum Beispiel eine Jahresbilanz 2026 neben einer Bilanz für das 1. Quartal. Nach der Erstellung sind weniger Klicks nötig, und Notizen gehen nicht mehr verloren.
Eine URL für mehrere Webhooks wiederverwenden
Was sich geändert hat:
Eine URL konnte bisher nur für einen Webhook verwendet werden
Dieselbe URL kann jetzt für mehrere Webhooks wiederverwendet werden
Bestehende Webhooks sind nicht betroffen
Warum das wichtig ist:
Kunden sind nicht mehr auf eine URL pro Webhook beschränkt.
Kommentare zu Kreditlimitvorschlägen erfordern keine Kategorie mehr
Was sich geändert hat:
Kommentare zu Kreditlimitvorschlägen können wieder gespeichert werden, ohne eine Kategorie auszuwählen
Die Pflichtprüfung für Kategorien ist nun gezielt für Kommentare zu Kreditlimitvorschlägen deaktiviert
Die Kategorieanforderungen bleiben für alle anderen Kommentartypen unverändert
Warum das wichtig ist:
Das Kommentarformular für Kreditlimitvorschläge enthält keine Kategorieauswahl. Kunden mit verpflichtenden Kommentarkategorien konnten daher keine Vorschläge kommentieren. Das funktioniert jetzt ohne Umweg.
Manuelles Überschreiben des Selbstbehalts bei Kreditdeckungen
Was sich geändert hat:
Der Selbstbehalt einer einzelnen Deckung kann jetzt manuell überschrieben werden. Zuvor folgte er immer dem Standardwert der Police.
Über ein neues Bearbeiten-Symbol neben dem Selbstbehalt-Feld der Deckung können Nutzer einen individuellen Prozentsatz eingeben (z. B. 20 % statt 10 %).
Warum das wichtig ist:
Kreditversicherer legen für bestimmte Deckungen mitunter nicht standardmäßige Selbstbehalte fest. Kunden können diese Konditionen jetzt in Bilendo exakt abbilden, anstatt an den Standardwert der Police gebunden zu sein.
Risikoklassen nach Herkunft filtern (manuell vs. automatisch)
Was sich geändert hat:
Der Risikoklassenfilter bietet jetzt die Option „Herkunft der Risikoklasse“: Automatisch oder Manuell
Automatisch = Die aktuelle Risikoklasse wurde vom System berechnet
Manuell = Die aktuelle Risikoklasse wurde von einem Benutzer festgelegt oder überschrieben (eine überschriebene automatische Klasse erscheint unter „Manuell“)
Warum das wichtig ist:
Kunden können automatische Klassen auch manuell setzen. Bisher war der einzige Weg, den Unterschied zu erkennen, die Kennzeichnung über das manuelle Design. Jetzt können sie manuelle Überschreibungen in einer einzigen gefilterten Ansicht prüfen.
Mehr Creditsafe-Risikowarnungen
Was sich geändert hat:
Bilendo verarbeitet jetzt zusätzlich eine Auswahl länderspezifischer Creditsafe-Alerts (ca. 50 Insolvenzcodes in 15 Ländern) und nicht mehr nur globale Alerts und einige französische.
Neue Indikatoren für Vorinsolvenz (Frühwarnung) in der Auswahl: Zahlungsverhalten, Zwangsvollstreckung/Inkasso, Gerichtsurteile sowie Steuer- und Sozialversicherungsschulden
Dieses erste Release deckt die von Klüber Lubrication ausgewählten Alert-Codes ab. Weitere Creditsafe-Alert-Codes folgen in einem späteren Release
Warum das wichtig ist:
Kunden mit internationalen Debitoren erhalten frühere und umfassendere Risikosignale und können so handeln, bevor es zu einer Insolvenz kommt.
BoniCheck-Policen-ID wird jetzt bei namenlosen Deckungen angezeigt
Was sich geändert hat:
Die in einer BoniCheck-Anfrage verwendete Policen-ID wird jetzt auf der daraus resultierenden namenlosen Deckung angezeigt (Widget „Kreditdeckungen“).
Beispiel: „Allianz Boni Check, Policy #WP21200004“, neben dem gewährten Betrag und dem Status.
Warum das wichtig ist:
Kreditmanager können eine unbenannte Deckung bis zur BoniCheck-Anfrage zurückverfolgen, die sie erstellt hat – ohne Anfragen manuell durchsuchen zu müssen.
Gesicherter Betrag wird jetzt in die Währung des Kreditlimits umgerechnet
Was sich geändert hat:
Der gesicherte Betrag (Summe aller Kreditversicherungen) wird jetzt in der Währung des Kreditlimits angezeigt, darunter steht der ursprüngliche Betrag (z. B. 2.532.911,60 zł / 578.000,00 €).
Ein Info-Tooltip schlüsselt den gesicherten Betrag pro Versicherer auf (z. B. Atradius, Orvia), ebenfalls umgerechnet. Umgerechnete Werte sind als Näherungswerte mit „≈“ gekennzeichnet.
Verfügbar in der Kreditlimit-Seitenleiste, im Tab „Risikomanagement“ und in der Detailansicht des Kreditlimit-Vorschlags.
Warum das wichtig ist:
Kunden mit Limits in einer anderen Währung als ihre Versicherungsdeckung können Limit und Deckung jetzt direkt vergleichen, ohne manuell umzurechnen. So ist sofort ersichtlich, ob ein Limit vollständig gedeckt ist.
Neuer Typ für benutzerdefinierte Felder: „Berechnet“
Was sich geändert hat:
Es gibt einen neuen Typ für benutzerdefinierte Felder mit dem Namen „Berechnet“.
Er wird automatisch mit den in der Scorecard berechneten Werten befüllt.
Diese Werte können jetzt im Exportlayout zugeordnet und in ein ERP- oder andere externe Systeme exportiert werden.
Warum das wichtig ist:
Bisher konnten in der Bilendo-Scorecard berechnete Parameter für Datenexporte keinem eigenen benutzerdefinierten Feld zugeordnet werden. Kunden können Scorecard-Ergebnisse jetzt ohne Umweg direkt an ihr ERP- oder an externe Systeme übergeben.
Karte „Zusätzliche Informationen“: Backend-Link aus dem Leerzustand entfernt
Was sich geändert hat:
Wenn ein Unternehmen keine benutzerdefinierten Textfelder hat, zeigt die Karte „Zusätzliche Informationen“ den Link „Benutzerdefinierte Felder konfigurieren“ zum Backend nicht mehr an (zuvor nur für Bilendo-Admin-Benutzer sichtbar).
Alle Benutzer sehen nun dieselbe Meldung: „Wenden Sie sich an den Customer Success, um benutzerdefinierte Felder einzurichten.“
Warum das wichtig ist:
Der Leerzustand ist jetzt für alle einheitlich und verweist nicht mehr auf ein Backend, auf das Kunden keinen Zugriff haben.
Kunden direkt in Bilendo anlegen, einschließlich virtueller Kunden
Was sich geändert hat:
Die Kundenübersicht enthält jetzt eine Schaltfläche „Erstellen“, um einen Kunden manuell anzulegen. Sie funktioniert ohne externe Anbindung (ERP-/Buchhaltungsintegration). Sie wird Unternehmen mit Scoring & Risk sowie Benutzern mit Schreibzugriff auf Kunden angezeigt.
Im Dialog „Neuer Kunde“ und im Dialog „In Kunde umwandeln“ (Scoring & Risk > Neue Kunden) können Sie jetzt einen Kundentyp auswählen:
Kunde: mit Kundennummer, Buchungskreis und Kreditkontrollbereich (Standard, Ablauf unverändert)
Virtueller Kunde: nur für die Konsolidierung, keine Geschäftsbeziehung. Nur der Name ist erforderlich.
Beim Wechseln des Typs bleiben bereits eingegebene Daten erhalten. Der Menüeintrag „Virtuellen Kunden erstellen“ öffnet jetzt denselben Dialog mit vorausgewähltem „Virtueller Kunde“.
Warum das wichtig ist:
Kunden können ihren Kundenstamm jetzt manuell aufbauen, ohne eine Integration. Außerdem können sie virtuelle Kunden für die Konsolidierung direkt beim Anlegen oder Konvertieren von Kunden erstellen, ohne separaten Dialog.
Gut zu wissen:
Virtuelle Kunden benötigen weiterhin keine Kundennummer, keinen Buchungskreis und keinen Kreditkontrollbereich.
Wenn ein Benutzer die Schaltfläche „Erstellen“ nicht sieht, prüfen Sie „Scoring & Risiko“ und seinen Schreibzugriff auf Kunden.
Manuelle Deckung mit einem Betrag von 0
Was sich geändert hat:
Manuelle Kreditdeckungen können jetzt mit einem Betrag von 0 erstellt werden (zuvor lag das Minimum bei 1).
Berichte zu Kreditdeckungen zeigen dafür „Gewährt: 0“ an.
Warum das wichtig ist:
Wenn ein Kreditversicherer eine Deckungsanfrage ablehnt, können Kunden dies jetzt als Deckung von 0 erfassen. Die Deckungshistorie und der Versicherungspool zeigen dann die tatsächliche Situation statt der bisherigen Deckung.
Parent-ID ist jetzt auf der customer#show-Seite bearbeitbar
Was sich geändert hat:
Ist die Beziehungsstruktur aktiviert, kann die Parent-ID über die Seitenleiste auf der Kundenseite bearbeitet werden („Bearbeiten“).
Die Seitenleiste zeigt die Parent-ID (bearbeitbar) und das konfigurierte Zuordnungsattribut (schreibgeschützt).
Der Bearbeitungsdialog weist darauf hin, dass Änderungen durch den nächsten ERP-Import überschrieben werden können.
Warum das wichtig ist:
Zuordnungen zwischen übergeordneten und untergeordneten Kunden lassen sich direkt in Bilendo korrigieren, ohne auf eine Korrektur im ERP und den nächsten Import warten zu müssen.
Abgelaufene manuelle Deckungen sind jetzt im Bericht „Kreditversicherungen“ sichtbar
Was sich geändert hat:
Abgelaufene manuelle Deckungen werden jetzt im Bericht „Kreditvericherungen“ mit dem Badge „Abgelaufen“ angezeigt
Die Anzeige erfolgt nur, wenn für dieselbe Verbindung keine aktive Deckung vorhanden ist (angezeigt wird die zuletzt abgelaufene)
Abgelaufene Deckungen werden nicht in den Gesamtbetrag oder die Anzahl der Deckungen eingerechnet
Historische Berichte (Stichtagsberichte) zeigen die zum jeweiligen Zeitpunkt aktiven Deckungen, ohne den Badge „Abgelaufen“
Warum das wichtig ist:
Kunden und Kreditmanager sehen nach dem Ablauf einer manuellen Deckung nicht mehr einen „leeren“ Deckungsbereich. Sie können erkennen, dass eine Deckung bestand und wann sie endete, was Gespräche über die Verlängerung erleichtert.
Änderungsprotokoll für Zusatzinformationen
Was sich geändert hat:
Jedes Feld „Zusätzliche Informationen“ auf dem Tab „Risikomanagement“ eines Kunden zeigt jetzt an, wer es zuletzt geändert hat und wann.
Ein Uhr-Symbol öffnet den Verlauf des Felds: frühere Werte, Autor, Quelle und das Datum, an dem der jeweilige Wert ersetzt wurde.
Entfernte Werte werden im Verlauf als „Entfernt“ angezeigt.
Warum das wichtig ist:
Teams können nachvollziehen, wer risikorelevante Notizen bearbeitet hat, beispielsweise vor einer Kreditentscheidung oder in einem Audit-Gespräch.
Wichtig:
Jede Änderung an einem Feld „Zusätzliche Informationen“ ist jetzt einer Person und einem Zeitpunkt zuordenbar.
Der vollständige Verlauf je Feld ist nur einen Klick entfernt – einschließlich Entfernungen.
Werte, die vor diesem Release gespeichert wurden, haben keinen Autor und kein Datum. Die Nachverfolgung beginnt mit der ersten Änderung nach dem Release.
Interne Kommentare zu Sicherheiten
Was sich geändert hat:
Sicherheiten haben jetzt im Sicherheitenfenster einen Tab „Kommentare“ mit einer Kommentaranzahl.
Eine neue Spalte „Kommentare“ zeigt die Anzahl in der Sicherheitenübersicht und in der Sicherheitenkarte auf dem Tab „Risikomanagement“ des Kunden an.
Archivierte Sicherheiten erscheinen jetzt ebenfalls auf dem Tab „Risikomanagement“ (gleiche Logik wie bei abgelaufenen). Der Link zu den Einstellungen der Sicherheitsarten wurde dort entfernt.
Warum das wichtig ist:
Teams können interne Informationen zu einer Sicherheit (zum Beispiel, warum sie archiviert wurde oder was der Versicherer gesagt hat) direkt dort festhalten, wo sie arbeiten, statt in Nebenkanälen.
Anbietername im Tooltip manueller Kreditdeckungen
Was sich geändert hat:
Beim Überfahren des Schild-Symbols einer manuellen Kreditdeckung mit der Maus wird jetzt der Name des verknüpften Anbieters (der in den Einstellungen angelegte) statt des generischen „Custom“ (DE: „Benutzerdefiniert“) angezeigt.
Dies gilt für die Kartenansicht, den Vergleichsmodus sowie die Legacy-Tabelle bzw. das PDF.
Ist der Deckung kein Anbieter zugeordnet, zeigt der Tooltip weiterhin „Custom“ an.
Warum das wichtig ist:
Nutzer, die Kreditdeckungen prüfen, sehen auf einen Blick, wer eine manuelle Deckung bereitstellt, ohne sie zu öffnen oder anderswo nachzuschlagen.
Benutzerdefinierte Sortierung für Sicherheiten und Kommentarkategorien
Was sich geändert hat:
Wertpapiere und Kommentarkategorien können jetzt per Drag-and-drop neu angeordnet werden.
Die gespeicherte Reihenfolge wird in den entsprechenden Dropdown-Listen für Sicherheiten und Kommentarkategorien übernommen.
Die Neuanordnung funktioniert genauso wie bei Risikointegrationen.
Warum das wichtig ist:
Nutzer, die täglich mit Sicherheiten und Kommentarkategorien arbeiten, können die am häufigsten verwendeten Einträge dort platzieren, wo sie sie haben möchten, statt sich mit einer festen Reihenfolge in den Dropdown-Listen abfinden zu müssen.
Diagramm in der Bonitätsauskunftshistorie
Was sich geändert hat:
Das Modal „Bonitätsauskunftshistorie“ hat jetzt die Tabs „Liste“ und „Diagramm“. Das Diagramm zeigt den Score und das empfohlene Limit im Zeitverlauf, mit einem Filter für 1/2/3 Jahre (Standard: 1 Jahr).
Eine Kennzahlen-Fußzeile zeigt den Score, die Veränderung gegenüber dem vorherigen Bericht, das empfohlene Limit und die Anzahl der Berichte im Zeitraum. Ein Klick auf einen Datenpunkt öffnet den jeweiligen Bericht.
Das bestehende Score-Diagramm verwendet nun das Berichtsdatum für seinen Zeitraum, zeigt für dd_monitor den Bürgel-Bonitätsindex an und lässt bei manuellen „-“-Einträgen eine Lücke statt einer 0.
Warum das wichtig ist:
Kunden erkennen Score-Entwicklungen auf einen Blick, statt Zeilen in einer Liste vergleichen zu müssen. Es funktioniert wie die ihnen bereits bekannte Kreditlimit-Historie.
Öffnen Sie die Historie einer Bonitätsauskunft und wechseln Sie zum Tab „Diagramm“, um den Verlauf zu sehen.
Ein Diagramm benötigt mindestens zwei bewertete Berichte im gewählten Zeitraum, andernfalls wird „Noch nicht genügend Historie“ angezeigt.
Korrigierte Spaltenbezeichnung im Hovercard „Nicht versichertes Risiko“
Was sich geändert hat:
Die Betragsspalte im Hovercard „Nicht versichertes Risiko“ war mit „Deduction“ beschriftet. Sie heißt jetzt „Deductible“.
Im Deutschen lautet die Bezeichnung jetzt „Selbstbehalt“ statt „Belastungsanzeige“. „Belastungsanzeige“ ist der Begriff für das Modul „Deductions“ und war daher irreführend.
Die Zahlen sind unverändert. Nur der Spaltentitel wurde geändert, und er stimmt jetzt mit den Ansichten für Kreditsicherheiten und Kreditdeckungen überein.
Warum das wichtig ist:
Die Spalte zeigt den Selbstbehaltanteil jeder Sicherheit, und die alte Bezeichnung deutete etwas anderes an. Kunden sehen hier jetzt denselben Begriff wie überall sonst in den Kreditdeckungen (Credit Covers).
Angezeigter Grund für gesperrte unbenannte Deckungen
Was sich geändert hat:
Die Warnung in den Kundendetails („Dieser Kunde ist bis ... für den Erhalt von Covers ohne Namen gesperrt") enthält jetzt eine Zeile „Grund: ..." mit entweder „Überfällige offene Forderungen" oder „Verspätet bezahlte Forderungen".
Unter dem Grund werden die Buchungssätze, die die Sperre verursacht haben, als Links aufgelistet (sofern der Benutzer auf Buchungssätze zugreifen darf). Bis zu 10 werden direkt angezeigt, und „und X weitere" öffnet ein Modal mit allen.
Kunden, die vor diesem Release gesperrt wurden, haben noch keinen erfassten Grund. Eine einmalige Nachberechnung trägt ihn für sie nach. Bei Kunden, deren Schulden inzwischen beglichen sind, wird kein Grund hinterlegt, sodass die Warnung für sie wie bisher aussieht.
Warum das wichtig ist:
Benutzer müssen nicht mehr in den Forderungen suchen, um herauszufinden, warum ein Kunde kein Cover ohne Namen erhalten kann. Sie sehen die Ursache und die zugehörigen Rechnungen direkt in der Warnung und können entscheiden, was zu tun ist.
Wichtig:
• Die Sperrwarnung in den Kundendetails nennt jetzt den Grund der Sperre: überfällige offene Forderungen oder verspätet bezahlte Forderungen.
• Die zugehörigen Buchungssätze sind direkt unter dem Grund verlinkt, sodass die Rechnungen hinter der Sperre nur einen Klick entfernt sind.
• Bei älteren Sperren kann der Grund leer sein, falls er nicht rekonstruiert werden konnte. Die Warnung mit dem Datum erscheint weiterhin wie bisher.
Beantragter Betrag im Kreditlimit-Verlauf und in der Entscheidungs-PDF
Was sich geändert hat:
Der Abschnitt „Genehmigungsdetails“ in der Detailansicht des Kreditlimit-Verlaufs und im Entscheidungs-PDF enthält jetzt eine Zeile „Angefragter Betrag“.
Der angefragte Betrag ist der Betrag, der vor der ersten Bearbeitung durch einen Benutzer galt. Eine systemseitige Neuberechnung vor einer Benutzerbearbeitung zählt als Anfrage. Auch Entscheidungen, die vor dieser Änderung getroffen wurden, zeigen ihn an.
Betragsänderungen zeigen jetzt, wer sie vorgenommen hat (Avatar, Name | Betrag geändert, mit Von/Auf). Jede Änderung wird aufgelistet, nicht nur die letzte. Jede Änderung steht unter dem Genehmigungsschritt, der zum Zeitpunkt der Änderung noch offen war. Eine Änderung nach der Validierung erscheint direkt unter den Genehmigungsschritten.
Warum das wichtig ist:
Wenn Prüfer oder Genehmiger einen Betrag anpassen (zum Beispiel 5.000 → 4.000 → 3.000), zeigte der Verlauf bisher nur den Endbetrag. Jetzt lassen sich die ursprüngliche Anfrage und die endgültige Entscheidung auf einen Blick vergleichen, in der App und im PDF.
Bonitätsscores als risikofarbene Badges
Was sich geändert hat:
Externe Bonitätsscores in der Seitenleisten-Karte für Bonitätsinformationen und in den Zeilen des Risikomanagements werden jetzt als farbig getönte Badges statt als einfacher fetter Text dargestellt.
Creditsafe, Creditreform, Atradius, D&B und Coface werden in Grün, Orange oder Rot angezeigt, sofern die eigene Skala des Anbieters dies zulässt. Allianz behält seine Notenfarben.
DD-Monitor, Coface Icon, Skyminder und manuelle Scores bleiben grau.
Warum das wichtig ist:
Kunden sehen das Risikoniveau eines Schuldners auf einen Blick, ohne die Skala des jeweiligen Anbieters kennen zu müssen. Das Verlaufsfenster und die Liste der Kreditinformationen behalten ihren bisherigen Score-Stil.
Manuelle Deckungen verhalten sich jetzt wie Versicherer-Deckungen
Was sich geändert hat:
Manuelle Deckungen im Bericht zu Kreditdeckungen zeigen in den meisten Zellen nicht mehr „—“ an. Die Spaltenansicht zeigt ein Manuell-Badge, Gewährter Betrag #2 / Ablaufdatum #2 sowie die Policenbedingungen. Die Kartenansicht zeigt die Bedingung im gleichen Warnstreifen wie bei Atradius.
Beim Anlegen einer manuellen Deckung können Sie jetzt eine Police (oder „Keine Police“) auswählen und eine Bedingung („Bedingter Betrag“) mit eigenem Betrag und Ablaufdatum hinzufügen. Eine einzelne Police wird vorausgewählt, und ihr Selbstbehalt wird als Standardwert angezeigt.
Der Selbstbehalt funktioniert wie bei Allianz und Atradius: Er greift auf die Police der manuellen Verbindung zurück und kann direkt in der Zeile überschrieben werden. Policen einer manuellen Verbindung erhalten eine frei wählbare Policen-ID.
Warum das wichtig ist:
Intern vereinbarte oder verhandelte Deckungen können am selben Ort und im selben Format gepflegt werden wie Versicherer-Deckungen. So lässt sich der Gesamtdeckungsbetrag pro Kunde verlässlicher beurteilen.
Manuelle Deckungen verwenden dasselbe Layout wie verbundene Deckungen und sind statt mit einem Versicherer-Logo mit einem Manuell-Badge gekennzeichnet.
Eine Bedingung (Betrag plus Gültigkeitsdatum) bei einer manuellen Deckung speist Gewährter Betrag #2 / Ablaufdatum #2, wie bei Atradius-Deckungen.
Gut zu wissen: Eine manuelle Deckung ist ausschließlich über die Policen-ID mit ihrer Police verknüpft. Wird eine Police in den Einstellungen umbenannt oder gelöscht, behält die Deckung die alte ID und verliert den Selbstbehalt-Fallback sowie die Policenbedingungen. Bedingungen werden im PDF-Export nicht angezeigt.
Trendfarbe pro Bilanzparameter und Kennzahl
Was sich geändert hat:
Jeder Bilanzparameter und jede Kennzahl in einer Vorlage für die Bilanzanalyse hat jetzt einen Schalter „Höher ist besser“.
Ist der Schalter deaktiviert, wird ein steigender Wert in der Spalte „Trend“ rot und ein fallender grün dargestellt; der Pfeil folgt weiterhin dem Wert.
Gilt für die Bilanzanalyse auf der Kundenseite und für das PDF der Kreditlimit-Entscheidung. Der Schalter ist standardmäßig aktiviert, sodass bestehende Vorlagen genauso aussehen wie zuvor.
Warum das wichtig ist:
Bisher war ein steigender Wert immer grün. Bei Zahlen wie Verbindlichkeiten oder Schulden ist das das falsche Signal, sodass die Analyse einen sich verschlechternden Kunden auf den ersten Blick gesünder aussehen lassen konnte.
Bilanzanalyse in der Eingabewährung
Was sich geändert hat:
Wurde die Bilanzanalyse eines Kunden in einer anderen Währung als der seiner Vorlage erfasst, zeigt die Seitenkopfzeile einen Umschalter zwischen Vorlagenwährung und Eingabewährung. Die Vorlagenwährung bleibt die Standardeinstellung.
In der Eingabewährung zeigen Parameter und Kennzahlen die Werte so an, wie sie erfasst wurden; der Tooltip zeigt den Betrag in der Vorlagenwährung und den Wechselkurs. Wurden Perioden in unterschiedlichen Währungen erfasst, trägt jede Periodenspalte ein Währungs-Badge, und Trends zwischen den Perioden werden weiterhin in der Vorlagenwährung verglichen.
Die Farben der Kennzahlen basieren immer auf der Vorlagenwährung, und das PDF zeigt weiterhin die Vorlagenwährung.
Warum das wichtig ist:
Kreditteams und regionale Kolleginnen und Kollegen können Bilanzzahlen in der Währung besprechen und prüfen, in der das Unternehmen tatsächlich berichtet, ohne die vergleichbare umgerechnete Ansicht zu verlieren.
Wichtig:
Standardmäßig ändert sich nichts: Die Analyse wird in der Vorlagenwährung geöffnet, sodass Ratings und Vergleiche unverändert bleiben.
Mit einem Klick werden die Zahlen so angezeigt, wie sie erfasst wurden. Das ist praktisch, wenn Sie den Jahresabschluss einer ausländischen Tochtergesellschaft gemeinsam mit regionalen Kolleginnen und Kollegen prüfen.
Der PDF-Export verwendet immer die Vorlagenwährung, sodass geteilte Berichte konsistent bleiben.
Manuelle Kreditdeckungen mit Ablaufdatum in der Vergangenheit
Was sich geändert hat:
Das Feld für das Ablaufdatum im Formular für manuelle Kreditdeckungen („Neue Kreditdeckung“) akzeptiert jetzt Datumsangaben in der Vergangenheit, sodass historische Deckungen erfasst werden können.
Eine manuelle Deckung, die mit einem Ablaufdatum in der Vergangenheit angelegt wird, wird als abgelaufen gespeichert. Sie lässt die aktuell aktive manuelle Deckung des Kunden mit demselben Produkttyp nicht mehr ablaufen.
Neue manuelle Deckungen und Sicherheiten werden abgelehnt, wenn das Ablaufdatum vor dem Startdatum liegt. Versicherungsdeckungen werden nicht auf diese Weise geprüft.
Warum das wichtig ist:
Kunden können in Bilendo jetzt eine vollständige Deckungshistorie führen, ohne die aktuell aktive Deckung zu beeinträchtigen. Unmögliche Datumskombinationen werden nicht mehr gespeichert.
Frühere Bilanzanalysen bearbeiten
Was sich geändert hat:
• „Vorherige Bilanzanalyse bearbeiten“ hat bisher nur die zuletzt erstellte Analyse geöffnet. Die Auswahl eines früheren Jahres oder Zeitraums schlug mit „Period has already been taken“ fehl.
• Wenn für den gewählten Zeitraum keine Analyse existiert, sehen Nutzer die Meldung „Für diesen Zeitraum wurde keine Analyse gefunden“.
Warum das wichtig ist:
Kunden, die sich eine Historie aufbauen, indem sie mehrere Jahre auf einmal erfassen, können jetzt einen Fehler in einem älteren Jahr korrigieren. Trends und Vergleiche beruhen dadurch nicht mehr auf falschen Zahlen.
Wichtig:
• Jede vorhandene Analyse eines Kunden kann unabhängig von ihrer Position in der Historie erneut geöffnet und korrigiert werden.
• Das Bearbeiten einer früheren Analyse funktioniert wie das Bearbeiten der neuesten: gleiche Schritte, gleiche Felder, gleiche Validierung. Nur Schritt 1 wählt jetzt den Zeitraum aus.
• Korrigierte Zahlen fließen in alles ein, was sie für diesen Kunden verwendet, etwa KPIs, Trends und Vergleiche mit benachbarten Jahren. Das Sperren älterer Einträge ist nicht Teil dieser Änderung.
Entscheidungs-PDF zeigt jetzt das vollständige Bild für die Freigabe
Was sich geändert hat:
Der Kundenblock oben zeigt den Buchungskreis und die Kreditkontrollbereiche, die der Benutzer sehen darf.
Das Risikoprofil zeigt das unbesicherte Limit (Unsecured Limit) und das nicht versicherte Exposure (Uninsured Exposure) an (gleiche Regeln wie in der Kreditlimit-Karte im Web, gleiche Währung wie die übrigen Beträge im PDF).
Die Kreditdeckung wird wie in der Web-Vergleichsansicht gedruckt (drei Deckungen pro Tabelle), einschließlich manueller Deckungsantworten. Die Kreditinformationen enthalten jetzt auch Angaben, die im Web nur in Tooltips und Modals angezeigt werden. Manuelle Einträge erscheinen mit ihren Details, genau wie Einträge von Anbietern.
Fehlende Werte werden mit einem Strich statt mit einer Null dargestellt. Die bestehenden PDF-Einstellungen (Abschnitte anzeigen, ausblenden, neu anordnen) funktionieren weiterhin.
Warum das wichtig ist:
Freigebende und Prüfer können eine Kreditentscheidung allein anhand des PDFs beurteilen, ohne den Kundenstammsatz oder das Portal des Versicherers zu öffnen.
Kreditlimit-Bedingungen im Kreditlimit-Export
Was sich geändert hat:
Das Layout des Kreditlimit-Exports bietet jetzt eine Spalte „Auflagen“. Sie ist außerdem Teil des Standardexports ohne Vorlage.
Jede Auflage wird als Name der genehmigenden Person, Doppelpunkt und Text geschrieben (z. B. „Anna Schmidt: Garantie der Muttergesellschaft erforderlich“). Mehrere Auflagen werden in der Reihenfolge ihrer Erteilung mit „ | “ verbunden.
Zeilenumbrüche innerhalb einer Auflage werden zu Leerzeichen, sodass jedes Kreditlimit in einer Zeile bleibt. Kommas, Semikolons und Anführungszeichen verschieben beim Öffnen der CSV-Datei in Excel keine anderen Spalten. Limits ohne Auflagen haben eine leere Zelle.
Warum das wichtig ist:
Kunden, die den Kreditlimit-Export an die Konzernzentrale senden, müssen die Genehmigungsauflagen nicht mehr manuell zusammentragen. Die Datei deckt nun ab, was die Zentrale benötigt.
E-Mail zur Kreditlimit-Genehmigung: Kennzahlen und ein direkter Link zum Vorschlag
Was sich geändert hat:
Der Betreff nennt jetzt den vorgeschlagenen Betrag und den Kunden, z. B. „Genehmigung erforderlich: Kreditlimit von 50.000,00 € für Neon GmbH (10001)“.
Die E-Mail zeigt das vorgeschlagene Limit neben dem aktuellen, mit der Änderung in Betrag und Prozent, außerdem Gültigkeit, Kreditrichtlinie, Risikoklasse, Score, offenen Saldo und Aufträge, abgesicherten Betrag und ungedecktes Risiko, aktive Kreditdeckungen, Bonitätsinformationen je Anbieter, frühere Genehmigungen mit ihren Auflagen sowie den Genehmigungsschritt („Schritt 2 von 3“).
Die Schaltfläche öffnet statt der Vorschlagsliste direkt den Vorschlag im richtigen Unternehmen.
Genehmigende sind oft Kreditleiter oder C-Level, die direkt aus ihrem Posteingang entscheiden. Sie sehen nun, ob das Limit steigt oder sinkt und warum, bevor sie klicken, und landen direkt dort, wo sie genehmigen oder ablehnen.
Manuelle Kreditversicherungen und Bonitätsauskünfte archivieren
Was sich geändert hat:
Manuelle Kreditversicherungen (aktiv oder abgelaufen) und manuelle Bonitätsauskünfte haben jetzt die Aktion „Archivieren“, die hinter einem Bestätigungsdialog liegt. Dieser nennt den Anbieter, den Betrag bzw. Score und das Datum.
Ein archivierter Eintrag zählt für den Kunden nicht mehr: Eine Versicherung fließt nicht mehr in die versicherte Summe ein, und eine Auskunft ist nicht mehr die aktuelle Bonitätsauskunft (die neueste verbleibende Auskunft dieses Anbieters tritt an ihre Stelle). Die Kreditrichtlinie wird erneut ausgeführt, sodass Limits und Vorschläge, die auf dem falschen Eintrag beruhten, korrigiert werden.
Es entsteht kein Eintrag „Versicherung abgelaufen“, keine Ablaufbenachrichtigung und kein Risikoalarm. Die Aktivität des Kunden zeigt, wer was wann archiviert hat, und archivierte Einträge bleiben unter dem Statusfilter „Archiviert“ sichtbar.
Warum das wichtig ist:
Bisher konnte ein fehlerhafter manueller Eintrag nur bearbeitet (Auskünfte) oder beendet (Versicherungen) werden, und eine beendete Versicherung sah aus wie eine tatsächlich abgelaufene Versicherung. Jetzt wird ein Fehler sauber entfernt, und die Historie des Kunden bleibt korrekt.
Wichtig:
• Archivieren ist für Fehler gedacht. Eine Versicherung, die tatsächlich geendet hat, wird weiterhin mit „Versicherung beenden“ beendet, sodass die Historie sie als abgelaufen zeigt.
• Das Archivieren kann nicht rückgängig gemacht werden. War der Eintrag doch richtig, erfassen Sie ihn erneut; eine Versicherung, die beim Anlegen der falschen beendet wurde, bleibt beendet und wird ebenfalls erneut erfasst.
• Nur manuelle Einträge können archiviert werden, und zwar von Benutzern, die manuelle Kreditversicherungen oder Bonitätsauskünfte bearbeiten dürfen. Versicherungen und Auskünfte von angebundenen Anbietern wie Creditreform, Allianz Trade oder Atradius bieten die Aktion nicht an.
Hilfeartikel: Manuelle Kreditversicherungen und Bonitätsauskünfte
Eingabewährung einer Bilanzanalyse korrigieren
Was sich geändert hat:
In „Vorherige Bilanzanalyse bearbeiten“ zeigt Schritt 1 die Eingabewährung wieder an, und sie kann geändert werden, auch nachdem die Zahlen erfasst wurden.
Nach einer Bestätigung bleiben die eingegebenen Zahlen exakt unverändert, und nur ihre Währungsbezeichnung ändert sich. Die Kennzahlen werden mit dem Wechselkurs der neuen Währung in die Vorlagenwährung umgerechnet.
Eine Kundengruppe, die automatisch anhand der Bilanzkennzahlen zugewiesen wurde, wird auf Basis der neu berechneten Kennzahlen erneut zugewiesen. PDFs zu Kreditlimit-Entscheidungen, die vor der Korrektur erstellt wurden, behalten ihre ursprünglichen Werte.
Warum das wichtig ist:
Eine versehentlich gewählte Währung verfälscht nicht mehr die Kennzahlen und die Kreditentscheidung, und Kunden müssen nicht mehr die gesamte Bilanz erneut erfassen oder den Support um Korrektur bitten.
Wichtig:
• Die Zahlen werden umbenannt, nicht umgerechnet: Verwenden Sie die Funktion, wenn die Zahlen stimmen und nur die Währung falsch war.
• Es können nur Währungen ausgewählt werden, die beim Erstellen einer Analyse angeboten werden, und nur Benutzer mit der Berechtigung zum Bearbeiten von Bilanzanalysen können sie ändern.
• Der Score bleibt wie eingegeben, und die Korrektur fügt dem Aktivitätsstream des Kunden keinen Eintrag hinzu. Das Löschen einer falschen oder doppelten Analyse ist nicht Teil dieser Änderung.
Aufträge nach Land und Benutzer filtern
Was sich geändert hat:
Die Auftragsliste hat unter „+“ zwei neue Filter: Land (das Land der Standardadresse des Kunden) und Benutzer (der dem Kunden zugewiesene Benutzer).
Beide akzeptieren mehrere Werte und lassen sich mit den bestehenden Filtern (Status, Buchungskreis, Datum) kombinieren; die Summe auf dieser Seite und die Gesamtsumme richten sich nach dem gefilterten Ergebnis.
Dieselben beiden Filter stehen im Filterschritt von Webhooks für Aufträge zur Verfügung.
Warum das wichtig ist:
Sachbearbeiter in der Debitorenbuchhaltung müssen nicht mehr jeden Auftrag durchscrollen, um die Aufträge ihrer eigenen Kunden oder eines bestimmten Landes zu finden. Eine lange Auftragsliste lässt sich mit zwei Klicks auf den relevanten Teil eingrenzen.