Company Credit Limits in Magento 2: Kreditlimits für Firmenkonten technisch abbilden

1. Company Credit Limits im B2B-Modul einordnen

Company Credit Limits sind Teil des Moduls Magento_CompanyCredit aus der B2B-Suite und bilden ein klassisches Kreditlimit ab, wie man es aus dem B2B-Geschäft außerhalb von Magento kennt: Eine Company erhält ein festgelegtes Guthaben, gegen das Bestellungen über die Zahlungsart Payment on Account gebucht werden können, ohne dass für jede einzelne Bestellung eine sofortige Zahlung nötig ist.

Fachlich unterscheidet sich das deutlich von einem einfachen Zahlungsziel: Es geht nicht nur darum, wann eine Rechnung fällig ist, sondern auch darum, wie viel offener Betrag insgesamt gleichzeitig ausstehen darf. Erst das Zusammenspiel aus Kreditlimit, aktuell ausstehendem Betrag und Zahlungsbedingungen ergibt das vollständige Bild, das Magento einer Company gegenüber abbildet.

2. Das Datenmodell: company_credit und company_credit_history

Das Kreditguthaben einer Company wird in der Tabelle company_credit gespeichert, mit Feldern wie company_id, credit_limit für das insgesamt zugestandene Guthaben, outstanding_balance für den aktuell ausstehenden Betrag und currency_code für die Währung, in der das Guthaben geführt wird. Das tatsächlich verfügbare Guthaben ergibt sich nicht aus einer eigenen gespeicherten Spalte, sondern wird aus der Differenz von credit_limit und outstanding_balance berechnet.

Jede Veränderung des Guthabens, etwa durch eine neue Bestellung, eine Zahlung, eine Gutschrift oder eine manuelle Anpassung durch einen Administrator, wird zusätzlich als eigener Eintrag in company_credit_history protokolliert, inklusive Operationstyp, Betrag und Referenz auf das auslösende Objekt. Diese Historie ist die primäre Quelle für Nachvollziehbarkeit und sollte bei eigenen Auswertungen immer der Tabelle company_credit als reinem Zustandsspeicher vorgezogen werden.

3. Wie der Checkout das verfügbare Guthaben prüft

Sobald ein Kunde im Checkout Payment on Account als Zahlungsart auswählt, prüft die Kreditlimit-Logik, ob der Bestellwert das aktuell verfügbare Guthaben der Company nicht überschreitet. Technisch läuft diese Prüfung über einen entsprechenden Service, der credit_limit und outstanding_balance gegen den Gesamtbetrag der aktuellen Bestellung abgleicht, bevor die Zahlungsart überhaupt als gültige Option angeboten oder final akzeptiert wird.

Wichtig für eigene Erweiterungen ist der Zeitpunkt der Reservierung: Das ausstehende Guthaben wird bereits beim Platzieren der Bestellung erhöht, nicht erst bei der späteren Rechnungsstellung. Das verhindert, dass mehrere fast gleichzeitig platzierte Bestellungen gemeinsam das Kreditlimit überschreiten, weil jede Bestellung das verfügbare Guthaben sofort und nicht erst nach einer asynchronen Verarbeitung reduziert.

<?php

declare(strict_types=1);

namespace Mironsoft\CompanyCreditExtension\Model;

use Magento\CompanyCredit\Api\CreditLimitRepositoryInterface;

/**
 * Ermittelt das aktuell verfügbare Kreditguthaben einer Company.
 */
class AvailableCreditReader
{
    /**
     * @param CreditLimitRepositoryInterface $creditLimitRepository
     */
    public function __construct(private readonly CreditLimitRepositoryInterface $creditLimitRepository)
    {
    }

    /**
     * Liefert das verfügbare Guthaben als Differenz aus Limit und offenem Betrag.
     *
     * @param int $companyId
     * @return float
     */
    public function getAvailableCredit(int $companyId): float
    {
        $credit = $this->creditLimitRepository->getByCompanyId($companyId);

        return (float) $credit->getCreditLimit() - (float) $credit->getOutstandingBalance();
    }
}

4. Eigene Genehmigungsworkflows bei Überschreitung

Standardmäßig blockiert Magento eine Bestellung per Payment on Account hart, wenn das verfügbare Guthaben nicht ausreicht, es sei denn, ein Administrator hat explizit erlaubt, dass Bestellungen das Guthaben ins Negative ziehen dürfen. Für viele B2B-Projekte reicht diese binäre Logik nicht aus, weil ein Vertriebsmitarbeiter im Einzelfall durchaus eine geringfügige Überschreitung genehmigen möchte, ohne das globale Limit dauerhaft zu erhöhen.

Ein sauberer Ansatz dafür ist, die harte Blockade durch eine eigene Zwischenstufe zu ersetzen: Statt die Bestellung abzulehnen, wird sie mit einem eigenen Status wie pending_credit_approval markiert und an eine definierte Genehmigerrolle weitergeleitet. Das lässt sich technisch am saubersten mit den bestehenden Purchase-Order-Genehmigungsregeln der B2B-Suite kombinieren, ergänzt um eine eigene Regel, die speziell auf eine Kreditlimit-Überschreitung reagiert, statt die komplette Genehmigungslogik neu zu bauen.

5. Blockade durch Genehmigungspflicht ersetzen

Technisch lässt sich die harte Blockade über ein around-Plugin auf der Kreditprüfung abfangen. Statt die ursprüngliche Exception unverändert durchzureichen, prüft das Plugin, ob die Überschreitung innerhalb einer definierten Toleranz liegt, und markiert die Bestellung in diesem Fall für eine manuelle Genehmigung, statt den Checkout komplett zu verweigern.

Bei der Umsetzung ist wichtig, dass die eigene Toleranzprüfung nicht die grundsätzliche Kreditlimit-Prüfung umgeht, sondern lediglich das Verhalten bei einer Überschreitung verfeinert. Eine Bestellung, die weit über jede sinnvolle Toleranz hinausgeht, sollte weiterhin hart blockiert werden, damit das Kreditlimit als Kontrollmechanismus nicht durch die eigene Erweiterung ausgehöhlt wird.

<!-- app/code/Mironsoft/CompanyCreditExtension/etc/di.xml -->
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <type name="Magento\CompanyCredit\Model\Validator\CreditLimitValidator">
        <plugin name="mironsoft_credit_tolerance"
                type="Mironsoft\CompanyCreditExtension\Plugin\CreditToleranceApprovalPlugin"
                sortOrder="10"/>
    </type>
</config>

6. Zusammenspiel mit Zahlungsbedingungen

Kreditlimit und Zahlungsbedingungen wie Net 30 sind zwei getrennte, aber zusammenwirkende Mechanismen. Das Kreditlimit steuert, wie viel Betrag insgesamt gleichzeitig offen sein darf, während die Zahlungsbedingung festlegt, bis wann eine einzelne Rechnung beglichen werden muss. Eine Company mit großzügigem Zahlungsziel, aber niedrigem Kreditlimit, kann trotzdem schnell an ihre Grenze stoßen, wenn mehrere Bestellungen innerhalb der Zahlungsfrist zusammenkommen.

Für eigene Reports oder Dashboards ist deshalb wichtig, beide Werte gemeinsam zu betrachten, statt sich nur auf eines der beiden zu verlassen. Eine Company kann ein technisch verfügbares Guthaben von null haben und trotzdem seit Wochen keine überfällige Rechnung aufweisen, wenn alle offenen Beträge noch innerhalb ihrer Zahlungsfrist liegen, was für Finance-Teams eine andere Priorität bedeutet als eine tatsächlich überfällige Forderung.

7. Kreditlimits programmatisch anpassen

Über CreditLimitRepositoryInterface und den zugehörigen Management-Service lässt sich das Kreditlimit einer Company programmatisch auslesen und anpassen, was für die Integration mit einem externen ERP- oder Buchhaltungssystem relevant ist, wenn Bonitätsprüfungen und Limit-Anpassungen zentral in einem anderen System gepflegt werden und Magento nur als nachgelagertes System das aktuelle Limit übernehmen soll.

Für eine solche Integration empfiehlt sich, jede externe Anpassung des Limits ebenfalls als eigenen Eintrag in company_credit_history zu protokollieren, mit einem klar erkennbaren Operationstyp wie external_sync, damit sich später nachvollziehen lässt, ob eine Änderung aus Magento selbst oder aus dem angebundenen externen System stammt.

8. Benachrichtigungen bei kritischem Guthaben

Magento bietet von Haus aus Benachrichtigungen, wenn eine Bestellung mangels Guthaben nicht per Payment on Account durchgeführt werden kann, deckt aber keine proaktive Warnung ab, etwa wenn das verfügbare Guthaben unter eine bestimmte Schwelle fällt, ohne dass bereits eine konkrete Bestellung fehlschlägt. Für ein Frühwarnsystem bietet sich ein Observer auf das Ereignis an, das bei jeder Änderung des ausstehenden Betrags ausgelöst wird.

Dieser Observer kann das neue verfügbare Guthaben gegen eine konfigurierte Warnschwelle prüfen und bei Unterschreitung eine Benachrichtigung an das Vertriebs- oder Finance-Team auslösen, idealerweise über eine asynchrone Verarbeitung, damit die eigentliche Kreditbuchung durch die Benachrichtigungslogik nicht verzögert wird.

9. Betrieb: Multi-Currency und Abgleich mit der Buchhaltung

Da das Kreditguthaben in einer festen Währung geführt wird, verdient der Umgang mit Multi-Currency-Shops besondere Aufmerksamkeit: Eine Bestellung in einer anderen Währung als der hinterlegten Kreditwährung muss vor der Prüfung korrekt umgerechnet werden, und Rundungsdifferenzen bei dieser Umrechnung sollten in der Historie nachvollziehbar dokumentiert sein, statt unerklärt im ausstehenden Betrag zu verschwinden.

Für Shops mit einer angebundenen Buchhaltung lohnt sich außerdem ein regelmäßiger Abgleich zwischen dem in Magento geführten outstanding_balance und dem tatsächlichen offenen Posten im Buchhaltungssystem, weil manuelle Anpassungen im Buchhaltungssystem, etwa Skonto oder Teilzahlungen, nicht automatisch nach Magento zurücksynchronisiert werden, sofern keine eigene Integration dafür existiert.

10. Zusammenfassung

11. FAQ: Company Credit Limits