ForHosting KIT · Finanzen und Geld

DSO-Rechner

Sehen Sie, wie lange Geld nach einem Verkauf auf Rechnung gebunden bleibt: 40000 Forderungen bei 365000 jährlichem Kreditumsatz ergeben eine Debitorenlaufzeit von 40 Tagen. Durchschnittlicher Tagesumsatz und Forderungsumschlag inklusive. Kostenlos in Ihrem Browser.

  • Kostenlos
  • Läuft in Ihrem Browser
  • Ohne Anmeldung
  • Ihre Daten bleiben auf Ihrem Gerät
Nutzen Sie es über WebAPIE-MailTelegramApp bald
Wenn Sie eingeben
Forderungen
40.000
Kreditverkäufe
365.000
Tage
365
Erhalten Sie
Forderungslaufzeit in Tagen
40
Durchschnittliche tägliche Kreditverkäufe
1.000
Forderungsumschlag
9,125

Die Debitorenlaufzeit, oder DSO, ist die Working-Capital-Identität, die einen Forderungssaldo und ein Intervall von Kreditverkäufen in einen Inkassoverzug in Tagen verwandelt. Mit Forderungen, Kreditumsatz der Periode und der Länge dieses Fensters gilt: DSO gleich Forderungen geteilt durch Kreditumsatz, mal Anzahl der Tage. Controller, Kreditverantwortliche und Studierende schlagen diese Zahl nach, sobald sie sehen müssen, wie lange Zahlungsmittel nach einem Verkauf auf Ziel gebunden bleiben. Dieser Debitorenlaufzeit-Rechner nimmt jene drei Eingaben entgegen, wendet die Identität an und liefert die Inkassodauer in Tagen samt durchschnittlichem täglichem Kreditumsatz und dem impliziten Forderungsumschlag.

Was die Debitorenlaufzeit bedeutet und wie Forderungen über Kreditumsatz zur Tageszahl werden

Die Debitorenlaufzeit misst, wie viele Tage die Kreditkunden eines Unternehmens im Mittel nach einem Verkauf auf Ziel brauchen, bis sie zahlen. Algebraisch sind das Forderungen aus Lieferungen und Leistungen geteilt durch den gesamten Kreditumsatz der Periode, multipliziert mit der Anzahl der Tage in diesem Fenster. Ein Unternehmen, das vierzigtausend Forderungen gegen dreihundertfünfundsechzigtausend Kreditumsatz über ein dreihundertfünfundsechzig-Tage-Jahr hält, hat eine DSO von vierzigtausend durch dreihundertfünfundsechzigtausend mal dreihundertfünfundsechzig, also genau vierzig Tage: durchschnittlicher täglicher Kreditumsatz von eintausend, und vierzig Umsatztage sitzen im Hauptbuch.

Dieselbe Identität ist Forderungen geteilt durch den durchschnittlichen täglichen Kreditumsatz, also Kreditumsatz über Tage; beide Formen liefern denselben Inkassoverzug. DSO ist eine Strom-gegen-Bestand-Umwandlung, keine Prognose einer einzelnen Rechnung und kein Fälligkeitskalender. Eine niedrigere Zahl bedeutet, dass Zahlungsmittel schneller zurückkehren; eine höhere Zahl bedeutet, dass mehr Nettoumlaufvermögen in den Handelsforderungen bleibt.

Vergleichen Sie die DSO mit den genannten Konditionen: sind Rechnungen Net 30 und liegt die DSO nahe fünfundvierzig, kommen die Einzüge im Mittel zu spät, auch wenn jede Rechnung am Ausstellungstag noch aktuell wirkt. Die Länge, die Sie senden, muss zum Umsatzfenster passen — Jahreskreditumsatz mit dreihundertfünfundsechzig oder dreihundertsechzig Tagen, ein Quartal mit neunzig, ein Monat mit dreißig oder den Kalendertagen dieses Monats. Nutzen Sie durchschnittliche Forderungen, Anfang plus Ende durch zwei, wenn Sie eine periodenmittlere DSO wollen, oder Schlussforderungen für eine Momentaufnahme gegen den Umsatz dieses Fensters.

Dieser Endpunkt holt weder Hauptbuchsalden noch Altersstufen noch Konditionskalender; er wendet die Identität an, die Sie liefern, damit Übungsschlüssel, Landing-Widgets und Automatisierung eine einzige prüfbare Tageszahl teilen. Der Kreditumsatz muss eine endliche Zahl streng größer als null sein; ein Umsatz von null kann kein Nenner sein und wird abgelehnt, statt eine Inkassodauer zu erfinden. Forderungen dürfen null sein, was eine DSO von null ergibt, weil nichts mehr einzuziehen ist.

Numerische Ausgaben nutzen half-up-Rundung, damit Goldens byteweise über Laufzeiten vergleichen.

Wo ein Debitorenlaufzeit-Rechner seinen Nutzen verdient

Treasury- und FP&A-Akten speichern Schlussforderungen und Periodenumsatz oft in getrennten Spalten; ein deterministischer Endpunkt holt die DSO zurück, ohne eine Tabellenzelle, die jemand später zum Umschlag umschreiben könnte, indem er den Tagesfaktor weglässt. Lehrende und LMS-Plattformen brauchen ein Orakel für die Definitionsfrage, die Studierende bittet, DSO als Forderungen über Kreditumsatz mal Tage zu rechnen, einschließlich des Quartalsfalls mit neunzig Tagen und des Jahresfalls mit dreihundertfünfundsechzig, ohne einen vollen ERP-Auszug.

Inhaltsteams können DSO dem Forderungsumschlag und den Kreditorentagen gegenüberstellen, damit Leserinnen sehen, warum ein kurzer Inkassoverzug einen längeren Zahlungszyklus trotzdem nicht finanziert, und warum der Cash-Conversion-Zyklus alle drei Beine braucht. Integratoren verdrahten den Endpunkt in Notizbücher, Ablaufwerkzeuge oder Rand-Worker, um Goldens zu pinnen, sobald ein Abschlusspaket den gespeicherten Forderungsbestand oder den Kreditumsatz ändert. Nutzen Sie diese Fähigkeit, wenn Sie bereits Forderungen, Kreditumsatz und eine passende Tageszahl haben; haben Sie nur Bareinzüge nach Altersstufe und wollen eine gewichtete Inkassokurve, ist das eine andere Identität und gehört nicht in diese DSO-Definition.

Kreditkonditionen gegenüber dem tatsächlichen Inkassoverzug

Wandeln Sie Schluss- oder Durchschnittsforderungen, Kreditumsatz und Periodentage in DSO und vergleichen Sie die Tageszahl mit genannten Net-30- oder Net-60-Konditionen.

Wie wird die Debitorenlaufzeit berechnet?

Senden Sie einen nichtnegativen Forderungssaldo, einen positiven Kreditumsatz desselben Fensters und die Länge dieses Fensters in Tagen. Vierzigtausend Forderungen gegen dreihundertfünfundsechzigtausend Jahreskreditumsatz sind eine DSO von vierzig Tagen.

Was bedeutet eine hohe oder niedrige DSO?

Eine niedrigere DSO bedeutet, dass Kundinnen schneller zahlen und weniger Zahlungsmittel in den Forderungen sitzen. Eine höhere DSO bedeutet einen längeren Inkassoverzug. Vergleichen Sie das Ergebnis mit Ihren genannten Konditionen: eine DSO deutlich über Net 30 ist ein Inkassoproblem, auch wenn das Hauptbuch noch aktuell wirkt.

Was geschieht, wenn der Kreditumsatz null ist?

Die Debitorenlaufzeit teilt Forderungen durch Kreditumsatz, daher ist ein Umsatz von null kein gültiger Nenner. Der Aufruf wird nicht berechnet.

Soll man 365, 360 oder 90 für die Tage nutzen?

Passen Sie days an das Umsatzfenster an, das Sie senden. Nutzen Sie 365 oder 360 bei Jahreskreditumsatz, 90 bei einem Quartal, und 30 oder die Kalendertage des Monats bei Monatsumsatz. Jahresumsatz mit einem 90-Tage-Faktor zu mischen bläht die DSO auf.

Wie vergleiche ich die Debitorenlaufzeit mit meinem Zahlungsziel?

Legen Sie die Laufzeit neben das Zahlungsziel Ihrer Rechnungen. Fakturieren Sie mit 30 Tagen Ziel und liegt die Laufzeit bei etwa fünfundvierzig, zahlen Ihre Kunden im Schnitt zu spät, auch wenn jede Rechnung am Ausstellungstag pünktlich wirkte.

Nehme ich den Endbestand oder den Durchschnitt der Forderungen?

Für eine Laufzeit über den ganzen Zeitraum nehmen Sie den Durchschnitt aus Anfangs- und Endbestand, also deren Summe geteilt durch zwei. Für eine Momentaufnahme gegenüber den Umsätzen des Zeitraums genügt der Endbestand.

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

POSThttps://api.kit.forhosting.com/fin/days-sales-outstanding

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

curl -X POST https://api.kit.forhosting.com/fin/days-sales-outstanding \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"accounts_receivable":40000,"credit_sales":365000,"days":365}'
{
  "accounts_receivable": 40000,
  "credit_sales": 365000,
  "days": 365
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "fin.days_sales_outstanding",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

HTTPCodeBedeutung
401unauthorizedDer API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
402insufficient_balanceIhr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
404unknown_typeUnbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
429rate_limitedZu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Ein Kreditumsatz von null scheitert mit invalid_input, statt durch null zu teilen.

Eingabevertrag, Antwortform und Fehlerverhalten

Beispiel: vierzigtausend Forderungen, dreihundertfünfundsechzigtausend Kreditumsatz und dreihundertfünfundsechzig Tage liefern eine DSO von vierzig, durchschnittlichen Tagesumsatz von eintausend und einen Umschlag von neun Punkt eins zwei fünf. Der Kreditumsatz ist das Feld, das der Produktvertrag hervorhebt: ein Umsatz von null wird niemals still durch Barumsatz, Nettoumsatz oder eins ersetzt, und eine fehlende Umsatzzahl wird nicht als null behandelt. Fehlgeschlagene Validierung wird nicht berechnet, sodass Erkundungsskripte günstig bleiben, wenn Entwickelnde absichtlich einen Kreditumsatz von null senden, um den Fehlerpfad zu bestätigen. Senden Sie per POST einen JSON-Körper mit drei Pflicht-Endlichen. accounts_receivable (Aliasse ar, receivables, accounts_receivable_balance, ending_receivables und average_receivables) ist der Forderungsbestand in Währungseinheiten für dasselbe Fenster wie die Umsatzzahl; er muss endlich und größer oder gleich null sein. credit_sales (Aliasse total_credit_sales, net_credit_sales, sales, credit_sales_total und net_sales) ist der Kreditumsatz der Periode in derselben Währung und muss eine endliche Zahl streng größer als null sein. days (Aliasse days_in_period, period_days, n und period) ist die Länge dieses Umsatzfensters in Tagen und muss eine endliche Zahl streng größer als null sein. decimals ist optional, eine ganze Zahl von null bis zwölf, Vorgabe sechs, und steuert die half-up-Rundung der numerischen Ausgaben. Bei Erfolg spiegelt der Körper die drei Eingaben, dann days_sales_outstanding als Inkassodauer in Tagen, average_daily_credit_sales als Kreditumsatz über Tage und — wenn Forderungen positiv sind — receivables_turnover als Kreditumsatz über Forderungen. Eine Formelzeichenkette formuliert, dass DSO gleich accounts_receivable über credit_sales mal days ist. Fehlende Felder, nicht endliche Werte, ein negativer Forderungssaldo, eine Periodenlänge von null oder negativ, oder ein Kreditumsatz von null oder negativ scheitern mit invalid_input unter Nennung des Feldes und werden nicht berechnet. Bevorzugen Sie schlichte JSON-Zahlen gegenüber Zeichenketten mit Währungssymbolen oder Tausendertrennzeichen; numerische Zeichenketten werden nur angenommen, wenn sie einem strengen Muster einer endlichen Zahl ohne Kommas oder Etiketten entsprechen. Der Preis ist ein festes $0.002 je erfolgreichem Aufruf mit unit item.

Wo ein Debitorenlaufzeit-Rechner seinen Nutzen verdient

Weil die Umsetzung reine parse-Analytik der Stufe A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Grundpreis $0.002 ohne Modell-Token und ohne ausgehendes Netz. Halten Sie credit_sales streng positiv, pinnen Sie das gerundete Feld days_sales_outstanding in Prüfungen, und Sie erhalten reproduzierbare Inkassodauern für Widgets, Hörsäle und Betrieb, ohne eine eigene Working-Capital-Bibliothek aufzustellen.

Abschlusspakete des Nettoumlaufvermögens

Holen Sie days_sales_outstanding aus Forderungs- und Kreditumsatzspalten zurück, ohne versehentlich den Tagesfaktor wegzulassen (das wäre Umschlag, nicht DSO).

DSO-Hausaufgaben und LMS-Schlüssel

Bewerten Sie Aufgaben, die DSO als (accounts_receivable / credit_sales) × days rechnen lassen, einschließlich jährlicher 365-Tage- und vierteljährlicher 90-Tage-Fenster.

Was kostet der Debitorenlaufzeit-Rechner?

Das Browser-Werkzeug ist kostenlos. API-Anfragen nutzen vorausbezahltes KIT-Guthaben zu $0.002 je erfolgreichem Aufruf; ungültige Eingabe wird nicht berechnet.

Vollständige KIT-Dokumentation lesen →