Divide by credit sales16 days
$800,000 ÷ $1.5m × 30
Only the invoices actually waiting are in the denominator. Four of the nine pages do this, and it is the figure Corporate Finance Institute itself reports for the month.
Divide by all revenue9.6 days
$800,000 ÷ $2.5m × 30
The $1m taken as cash joins the denominator and waits for nothing. Reported days fall by exactly the cash share, and the number itself never says so.
Corporate Finance Institute’s own worked month, divided two ways. Four of the nine pages divide by credit sales, three by all revenue, and two print both denominators on the same page. The gap is the share that arrived as cash and was never waiting.
What the nine pages divide by
Four divide by credit sales. Corporate Finance Institute prints "Accounts Receivables / Net Credit Sales X Number of Days". Salesforce and Billtrust print the same division with the days moved to a different place in it. Versapay's formula is an image, and the prose beside it says to divide total receivables due by total net credit sales. Of these four, only Billtrust mentions averaging the balance, and only in its worked example and its twelve month version, not in the formula it leads with.
Three divide by all revenue. Wall Street Prep uses "(Average Accounts Receivable / Net Revenue) x 365 Days" and is the one page of the nine to put an average in its headline formula. Wikipedia divides by annual sales and does not contain the phrase credit sales anywhere. Upflow's calculation page divides by gross sales over the period, three times over.
Two print both. CreditPulse says Net Revenue in its intro, its heading and its FAQ, and Net Credit Sales in both of its worked examples. Upflow's formula page says gross sales in the prose and Total Credit Sales in the box one line below it.
Wall Street Prep is the only page that says why it uses revenue, and its sentence concedes the argument before it makes it: "While analyzing only credit sales, rather than net sales, is technically more accurate, public companies seldom report their revenue with cash and credit sales separated". That is an honest reason and it belongs to public filings. It does not transfer to a business reading its own invoice file, where the split is right there.
Those last two matter more than the seven that pick a side, because they disagree in opposite directions. On Upflow the box is stricter than the prose above it. On CreditPulse the examples are stricter than the formula they sit under. A reader who copies the formula from one page and the example from the other ends up with two numbers, from two pages that both look authoritative.
What the fork costs
Corporate Finance Institute prints the arithmetic itself, so there is no need to invent a business. Its example has $2.5 million of revenue for the month, of which $1.5 million is on credit and $1 million is cash, against $800,000 of receivables. It divides by the credit sales and reports 16 days.
Divide the same receivables by the same month's whole $2.5 million and it is 9.6.
The relationship is exact, not approximate. Using all revenue multiplies your reported DSO by the share that is genuinely on credit. This example is 40 per cent cash, so the loose number is 60 per cent of the strict one, and 9.6 is 60 per cent of 16. Take nothing at the counter and the two formulas are the same formula, which is why the disagreement survives: on a pure trade book it never shows up.
That also settles which way the error runs. The loose denominator always reports fewer days than the credit book is actually waiting, and the number itself never says so. Three of the nine pages do warn: CreditPulse writes that including cash sales "understates your DSO", Versapay that DSO "does not consider cash sales", and Corporate Finance Institute explains why they are excluded at all, "because they are considered a zero DSO".
The second fork is the balance on top
The numerator has its own disagreement, and it is quieter. Three of the nine say to average accounts receivable rather than take the closing balance, and two of those three then bless the closing balance on the same page. Wall Street Prep: "the more common approach is to use the ending balance for simplicity". CreditPulse: "Either approach is valid; pick one and use it consistently". So the numerator has the same both-on-one-page problem as the denominator, in a politer form.
A single date is a photograph. Invoice heavily in the last week of the quarter and the closing balance is high and DSO reads long. Invoice early and it reads short. Neither says anything about how fast anybody pays.
For a growing business the two forks fight each other. Sales rise, the closing balance sits above the average, and the point in time numerator reads worse than the truth while the loose denominator reads better. Two errors in opposite directions is not a cancellation. It is a number nobody can unpick.
The case for the loose denominator
The strongest argument against this article is on one of its nine pages. Wikipedia says the metric is "often misinterpreted as the average number of days to fully collect payment after making a sale", and should be read instead as the days worth of sales you currently have outstanding. On that reading total revenue is the right denominator, because the question is how large the receivable book is against the rate the business sells at, not how long an invoice waits.
Two more things point the same way. Corporate Finance Institute and CreditPulse both place DSO inside the cash conversion cycle, whose other terms are built on total cost of sales, so a credit only DSO does not sit consistently beside them. And every published benchmark on these pages comes from listed company filings, which, as Wall Street Prep says, do not separate credit from cash. Switch to credit sales and your own number gets more accurate while your comparison to those benchmarks gets worse.
So the fork is not error against correctness. It is two questions wearing one name. How long is an invoice waiting, and how much of my selling rate is tied up in receivables. The failure is not picking one. The failure is not saying which.
What your file has and what the formula wants
Two of the nine pages tell you what to do when the split is not available. Wall Street Prep explains why it cannot be had from filings. CreditPulse gives the instruction: "If you cannot isolate credit sales from cash sales in your system, total net revenue is an approximation, but flag it as imprecise." Six of the nine mention cash sales at all; the rest only name the rule and leave you with it.
What to do instead
Say which denominator you used, every time you say the number
A DSO without its denominator is not a metric, it is a digit. Two people in the same company can compute 16 and 9.6 from the same books and both be right.
If you are asking how long invoices wait, use the payment dates instead
Days sales outstanding is a proxy for that question. If your file records when each invoice was paid, the average of payment date minus invoice date answers it directly, with no denominator to argue about.
Compare the number only to itself
Seven of the nine pages offer a benchmark, and none states which denominator produced it. Your own last quarter is the only comparison with a denominator you control.
Where this sits in my own tool
KPI Vitals has a card called Days sales outstanding. Its tooltip reads: "Outstanding divided by revenue in the window, times the days in the window. How long the average invoice waits to be paid. It moves with the window because the revenue underneath it does."
The first sentence is the loose fork twice over, all revenue underneath and a snapshot balance on top. The second sentence is the misreading Wikipedia names, printed on my own card. The third sentence admits a third fork out loud: the balance is frozen at the last month in the file while the denominator moves with the period buttons, so the same book reads differently depending on which button is pressed. On the demo figures built into the dashboard shell it runs 19 days on the one month view and 24 on the twelve month view; load the sample workbook that ships in the same folder and the spread is wider still, 93 days against 115. My own article says the period must be the same on both sides of the division. My own card breaks that.
There is a fourth. The day count is thirty times the number of months rather than the days in the window, so a year is 360 days and every figure the card prints leans about one and a half per cent low.
I would like to say I weighed any of this. I did not. And the worst part is not the arithmetic, it is what sits unused beside it: the file carries a payment date for every settled invoice, so the average days to pay is already computable, with no denominator and no argument. The tool reads that column and uses it only to decide whether a row is still open. It ships the proxy and prints the proxy's strongest claim as a fact.
Two smaller things a buyer should know. The ageing buckets and the outstanding balance are measured on the last invoice date in the file, so a payment recorded after that date is not seen and its invoice still counts as open. And the open invoice count counts rows rather than invoices, so a line level export inflates it.
I wrote about those buckets in the ageing report piece, about the same waiting time under its clinical name in days in A/R, and about the reciprocal of this metric, where the argument moves to the numerator, in the turnover ratio. The tool itself is KPI Vitals, and the list above is what it does today, not what it should do.
Sources and method
I opened twelve pages across two searches on 8 September 2026. Three refused an automated fetch and are named rather than quietly dropped: QuickBooks, HighRadius and Plooto, all three large publishers on this subject, so the sample leans away from them. That leaves nine: Wall Street Prep, Billtrust, Corporate Finance Institute, Salesforce, Versapay, CreditPulse, Wikipedia and two pages from Upflow.
Every verdict was set by opening the page, not by searching it for words. Versapay is why: its formula is rendered as an image, so a scan looking for a formula block finds none. The prose beside it spells the same formula out, and that is where its verdict comes from.
Each page was asked the same questions before I read any of them: what is in the denominator, does it say to average the balance, does it mention cash sales, does it say what to do when credit and cash are not separated, and does it offer a benchmark. Counts: four credit, three revenue, two printing both. Three name averaging. Six mention cash sales and two say what to do about them. Seven give a benchmark.
An earlier version of this article counted three pages as printing both denominators. One of them, Upflow's calculation page, does not: its three mentions of credit sales are all definitions of what DSO measures, and every denominator on it is gross. That verdict was the only one in my file with no supporting quote, which is exactly where it should have been caught.
Questions people actually ask
Accounts receivable divided by sales, times the days in the period. The argument is over which sales. Of the nine pages read here, four divide by credit sales, three by all revenue, and two print both denominators on the same page.
It depends which question you are asking. For how long an invoice waits, credit sales. For how much of your selling rate is tied up in receivables, total revenue is defensible and keeps you comparable to published benchmarks, which come from filings that cannot separate the two. What is not defensible is publishing the number without saying which you used.
By exactly the share of revenue that is not on credit. Corporate Finance Institute’s own example is 40 per cent cash, and the same receivables read 16 days against credit sales and 9.6 against all revenue.
Three of the nine say so, opening plus closing over two, and two of those three also say the closing balance is fine. A single closing balance moves with when you happen to invoice rather than with how fast anyone pays.
Most pages that specify say net, and CreditPulse lists using gross revenue as a mistake because returns and discounts skew it. Both Upflow pages say gross. So this fork is unsettled too, it is just smaller than the credit versus all one.
The same shape of arithmetic under different vocabulary, but not the same argument. DSO argues credit sales against all revenue. Days in A/R argues charges net of credits, which is the AAFP definition, against average daily net revenue, which is the hospital one. Different denominators, the same failure to say which.
No, and not because one term is missing. Cash received is neither term: the numerator is what is still owed and the denominator is what you billed. A bank statement has neither.
WRITTEN BY
Olha · clinic data analyst
I build the reporting our managers open every morning at a multi-branch medical clinic — and package it so other practices don't have to start from scratch.
Published on 8 September 2026. Three limits worth stating outside the body text. The sample is two search phrasings on one day and three of the twelve pages refuse this location, so rerun the method rather than trust the counts. I have not shown that either denominator is wrong; both are defensible, and the finding is that three pages use both without saying so and that the choice moves the number by a knowable amount. And the tool this article sells takes the looser fork on both counts, which is said in the body rather than left for a reader to discover.