# Days sales outstanding (DSO) for a sales manager: what the CRM can show and which deal terms stretch it

https://salesbond.app/blog/days-sales-outstanding-payment-terms-deal-field-hubspot/
Published: 2026-10-20 · Updated: 2026-10-26

Days sales outstanding (DSO) is the average number of days it takes a company to collect cash after a credit sale. Finance computes it, but part of it is decided at the sale: payment terms, deposits and the date the invoice goes out. A sales manager can keep that part visible with one required deal property for payment terms and a report of won deals by terms, and leave the DSO calculation and payment status to finance.

Most of what is written about DSO is for the person who computes it. This piece is for the manager whose deals feed it.

## What days sales outstanding measures, and whose number it is

The formula, as [Wall Street Prep](https://www.wallstreetprep.com/knowledge/days-sales-outstanding-dso/) gives it:

DSO = (average accounts receivable ÷ revenue for the period) × days in the period

Average receivables is the opening plus the closing balance, divided by two. Wall Street Prep uses net revenue in the denominator and notes that counting only credit sales is technically more accurate; public companies just rarely report credit sales separately. If your finance team has the credit sales figure, that is the one to use.

A hypothetical quarter makes it concrete. Average receivables of $120,000, credit sales of $360,000 over 90 days: 120,000 ÷ 360,000 = 0.33, times 90, gives a DSO of 30 days. On average, the company waits a month for its money.

What does it tell you? Lower means cash comes in sooner, and Wall Street Prep reads the trend: DSO rising against earlier periods points to slower collection. “Good” depends on the industry, so compare against your own last few quarters.

Every input to that formula lives in the accounting system. None of them is a deal property.

So finance owns the number. Sales owns the setup: the promises inside each won deal that decide how long receivables stay receivable. Treat DSO as purely a collections problem and you end up chasing invoices that were always going to be 60 days late, because that is what the rep agreed to.

## Three deal terms that stretch (or shorten) DSO

Open any won deal and look for three decisions. A rep made each of them, often in the last week of the quarter.

Payment terms first. Net 30 and net 60 are not the same deal at the same price; the longer one is an extra month of credit, and procurement knows it. Pricing that request is its own subject ( [how to answer “our terms are net 60”](https://salesbond.app/blog/net-60-payment-terms-request-pipedrive/)). For DSO the point is simpler: the terms a rep writes into the contract are the floor under the number, and a book of net 60 deals will not produce a 30-day DSO however good collections are.

Deposits second. A deposit paid on signature turns part of the receivable into cash before the invoice cycle starts. Whether a deal should wait for prepayment before it counts as won is a forecasting question ( [signed but not paid](https://salesbond.app/blog/pipedrive-won-not-paid-prepayment-invoice/)).

The invoice trigger third, and this one is usually invisible. Check what your contracts count the terms from. If it’s the invoice date, the clock does not start until the invoice goes out, and that might be at kickoff, at first delivery, or whenever someone in sales remembers to tell finance. Picture a deal signed on the 3rd and invoiced on the 24th (a made-up example, but a familiar one): three weeks added to its collection time that no report in either system shows as a decision. It was one.

One more check sits in front of all three. If finance vets new customers before extending credit, long terms should wait for that answer, not for the end of the quarter. Once terms, deposit and invoice trigger sit on the deal, they feed a [cash flow forecast from the pipeline](https://salesbond.app/blog/cash-flow-forecast-crm-pipeline/): close date, plus invoice lag, plus terms.

![Timeline of one won deal: terms and invoice timing set at the sale in the CRM, due date and payment measured by finance](https://salesbond.app/wp-content/uploads/2026/10/days-sales-outstanding-payment-terms-deal-field-hubspot-2.png)

Everything after the invoice goes out belongs to finance. A customer who owes money and wants to reorder is a separate conversation: [the customer who owes you money wants to reorder](https://salesbond.app/blog/customer-overdue-invoice-new-order-pipedrive/).

## One deal property: payment terms, required at Closed won

We would put exactly one property on the deal for this, and make it a dropdown. Free text for payment terms produces “net 30”, “Net30”, “30 days” and “standard”, and a report built on that is a report of spelling.

HubSpot lets you create custom properties for deals. The short path: click the settings icon, go to **Properties**, pick **Deal properties** from the object dropdown, click **Create property**, enter the label and choose the field type ( [HubSpot: create and edit properties](https://knowledge.hubspot.com/properties/create-and-edit-properties)). You need Edit property settings permissions. Dropdown select is the field type you want here.

What goes in the dropdown is a team decision, not a HubSpot one. A version that works for a small B2B team:

1. Prepaid in full
2. Deposit, balance on delivery
3. Net 15
4. Net 30
5. Net 60
6. Other, approved by (name in the deal notes)

If “Other” is the most common value after a quarter the list is wrong, not the reps.

Then make it required when a deal is won. HubSpot does this with conditional stage logic: in settings, under **Data Management**, click **Objects**, select Deals, open the **Pipelines** tab and your pipeline. In the Closed won row, hover over the **Conditional logic rules** column, click **Add rule**, add the payment terms property under **Dependent properties** and select **Required**. A required property means users cannot create or update the record until they set a value for it ( [HubSpot: set up and manage object pipelines](https://knowledge.hubspot.com/object-settings/set-up-and-customize-pipelines)).

Why Closed won and not earlier? Terms change during negotiation, and a required field at Proposal gets filled with a guess. At Closed won the contract exists and the rep is copying from it. Note that the rule fires when a user creates a deal in that stage or moves one into it by hand; where that leaves gaps is covered in [HubSpot required properties by deal stage](https://salesbond.app/blog/hubspot-stage-required-properties/).

## One report: won deals by payment terms

The property is worth nothing until someone reads it in aggregate. The report is plain: deals closed won in the period, count and amount broken out by payment terms, and then the same split by deal owner.

Read it twice. Once by terms: what share of this quarter’s bookings is on net 60 or longer? If that share grew since last quarter, DSO is heading up, and finance will see it when those invoices come due. You are seeing it now. Then by rep. Two reps with the same bookings and the same price list can hand finance very different receivables, and before the cash arrives this report is the only place that difference shows.

A third cut, by segment, is optional. Enterprise accounts with procurement departments sit on longer terms, and that is normal. A 20-seat customer on net 60 is a question for the rep.

In HubSpot, custom reports need a Professional or Enterprise subscription, and a single object report on deals is the type that fits: one object, no joins, querying the live CRM database ( [HubSpot: create custom reports](https://knowledge.hubspot.com/reports/create-custom-reports)). On a tier without custom reports, export a list of won deals with the the payment terms column and do the two cuts in a spreadsheet. Slower, just as honest.

For most teams this report belongs with the manager, not on the shared dashboard, where it would show reps each other’s terms ( [access and filter rules for HubSpot dashboards](https://salesbond.app/blog/hubspot-dashboard-sales-manager-setup/)).

## What HubSpot cannot tell you: paid or not

The CRM knows the deal was won, when, for how much and on what terms. It does not know whether the customer paid. That fact lives in the accounting system, and copying it into the CRM by hand is the kind of task that gets done for three weeks and then stops.

So do not compute DSO from HubSpot. A number built from won dates and terms is a promise, not a receivable: it assumes every invoice went out on signature and every customer paid on the due date, which is exactly the assumption DSO exists to test.

What you can ask finance for is small and specific: which invoices from your team’s deals are past due, by customer, with days overdue. Monthly is enough. Put that list next to your won deals by terms report and you have the whole picture, what sales promised and what actually happened. The gap between them is either an invoice trigger problem (sales told finance late) or a collections problem (the customer is slow), and the two have different owners.

A disclosure, since we are at the edge of the CRM: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive, and today it works with Pipedrive, HubSpot, Salesforce and Zoho CRM. It analyses deal and customer data from the CRM, finds risks and explains what needs attention. Payment status is not deal data, so here too the finance side comes from finance. If you want to see your pipeline through that lens, [check your CRM with SalesBond](https://salesbond.app/).

## Three questions for finance, once a month

You bring the won deals by terms report, finance brings the overdue list. If you already run a monthly [bookings, billings and revenue check](https://salesbond.app/blog/bookings-vs-billings-vs-revenue-pipedrive/) with finance, add these to it rather than booking another slot.

Are the terms drifting? Compare this month’s split to the last two. If the net 60 share keeps growing someone is giving it away, and the report by rep says who.

Which deals were exceptions, and who approved them? Every “Other” in the dropdown should have a name attached. If it doesn’t, the exception wasn’t approved. It was just typed in.

Which overdue invoices come from deals where the invoice went out late? Finance cannot answer this one alone, because they don’t see the signature date without opening the deal. You do. The deal signed on the 3rd and invoiced on the 24th is your problem, not the customer’s, and the fix is a handoff rule rather than a collections call.

Write down the three answers and compare next month. That replaces the quarterly surprise where finance announces DSO is up and sales had no idea.

## Two ways to misuse the number

The first is grading a rep on DSO. Its tempting once the report by owner exists, and it is wrong, because DSO mixes what the rep decided (terms, deposit) with what the rep never touched: how fast the customer’s AP department runs, whether finance invoiced on time. Judge the rep on the terms they agreed and whether exceptions were approved. If a rep’s customers pay late on net 30, that is information about the customers, and it belongs on the account, not in the rep’s review.

The second is turning the CRM into a collections tool. Sooner or later somebody suggests a “payment received” checkbox and a task to chase the customer on day 31. We wouldn’t. The CRM does not know the invoice status, so the checkbox will be wrong within a month, and a rep chasing an invoice is doing finance’s job with worse information.

Sales belongs in the cash conversation upstream, at the three decisions this started with. This week, add the payment terms property and the Closed won rule. In a month you will have the first report to bring to finance, and the next time DSO moves, you will already know which part of it was yours.