Is NetSuite Native Dunning Enough? One Collections Week, Step by Step

At 8:40 on a Monday morning, at a company where NetSuite dunning is switched on and configured the way the implementation partner recommended, a collector opens the aging report and exports it to Excel.

Nothing is broken. The weekend dunning run went out on schedule. The templates rendered, the levels fired at the right thresholds, and the customers who crossed thirty days past due got the thirty day letter. The export happens anyway, because the aging report answers the question "who is late" and the collector needs the answer to a different question: who do I call today, and what do I say when they pick up.

That second question is where collections actually happens, and it is worth being precise about which parts of the week your ERP completes on its own. So this is a walk through one ordinary collections week on NetSuite native dunning, step by step. At each step, two columns: what the native run does, and what a person does for it. At the end, the second column gets added up.

What kind of thing are you actually shopping for?

Two categories sit behind that walkthrough, and which one you are shopping decides your outcome before a vendor name comes up. A collections tool automates one step of the order-to-cash cycle, and native dunning is the most minimal example of the type: it owns the sending step, competently. An end-to-end order-to-cash analyst carries credit through to the AR forecast and coordinates sales, customer success and finance around each account. The move is from a calendar that fires to a book that gets read, from reminders sent to promises kept, from one column automated to the whole week accounted for. One is a step. The other is the cycle.

Key takeaways

1. NetSuite native dunning automates the sending step of collections completely and competently. The steps around it, building the working list, personalising outreach, reading replies, logging promises, suppressing reminders on disputed invoices, applying cash and forecasting, are performed by a person, and those steps consume most of a collector's week.
2. The clearest signal that a finance team has outgrown ERP native dunning is a spreadsheet: when collectors maintain a parallel sheet for promises to pay, disputes and follow-up dates, that sheet has become the real collections system while the ERP holds the invoices.
3. In a worked example of a two collector team with roughly 900 open invoices, the manual steps around the dunning run total about 18 hours a week, close to 830 hours a year, or four tenths of a full time role spent on work no reminder schedule can absorb.
4. The distance between the two categories shows up first in how a rollout goes. In the G2 Summer 2026 Enterprise Accounts Receivable indices, Tesorio posts Usability 9.03, Implementation 8.59 and Relationship 8.69, and averages 1.31 months to go live against a category average of 5.35 months.
5. For a team coming off native dunning, user adoption is the number that decides the outcome, because collectors already have a working habit inside the ERP. Tesorio's User Adoption score is 95 percent against a category average of 64 percent.

Monday 8:40am: who decides which accounts get worked this week?

A person does. NetSuite native dunning has no view on this, by design.

Dunning fires on elapsed days. An invoice crosses a threshold you configured, the matching level sends, and the sequence advances. Every account that crossed thirty days past due is treated as one population. That is correct behaviour for a reminder schedule and it is silent on the question the collector is actually asking on Monday morning.

Consider two accounts sitting at day 31 in the same run. The first has paid on day 47 for eleven consecutive quarters, always after one nudge, always in full. The second is a customer whose AP contact left in June, whose last two invoices went to a shared inbox nobody is watching, and whose parent company just consolidated onto a new procurement portal. Both receive the same letter at the same hour in the same tone. One of them is fine. The other is the account that turns into a write off conversation in November.

The collector knows this, which is why the aging report gets exported. The Excel file is where the ranking happens: colour coding by risk, a column for last contact, a column for who owes a callback. That file is a piece of software your team wrote and now maintains.

Native handles: the aged receivables data, saved searches, subsidiary scoping. A person handles: ranking the book by likelihood to slip, choosing the accounts that fit into the week, and holding the reasoning in a spreadsheet the ERP cannot read.

Monday 10:15am: does the dunning run send the right message to the right account?

It sends the configured message to the qualifying account, which is a narrower promise than it sounds.

Native dunning levels are defined centrally and applied broadly. You get a ladder: a gentle notice, a firmer one, a final demand, each attached to a days past due threshold and a template, scoped by subsidiary and suppressed by an exclusion flag where you have set one.

Real payers do not fit one ladder. A few patterns that show up in any book past a few hundred accounts:

• The customer who pays reliably, but only after the invoice is uploaded to their supplier portal. Email reminders are decoration for this account. The action that gets you paid is a portal check on day 20.
• The customer who will not pay without a valid PO number printed on the invoice, and whose AP system rejects silently rather than replying.
• The customer with a master services agreement that specifies a sixty day term, sitting inside a book configured for net thirty, and receiving a past due notice on day 31 that is factually wrong.
• The strategic account where the correct day 45 action is the account manager making a call, and where an automated final demand actively damages a renewal conversation.

Encoding those in native dunning means building levels until the level list itself becomes a maintenance project, or handling them off system. Most teams choose off system, which means a person is checking the run against a mental list of exceptions before it goes out, or apologising after it does.

Native handles: sending the configured ladder, on schedule, without a human touching it. A person handles: everything the ladder cannot express, and the apologies when the ladder is wrong.

Tuesday: where do the replies go?

Into somebody's inbox, and that is the structural problem.

The dunning run sends from a template. When the customer replies, and a meaningful share do, the reply lands in a mailbox: a shared AR address if the team has been disciplined about it, an individual inbox if the collector has been sending personalised follow ups from their own account. Either way the thread now lives in email, and its content is invisible to the ERP.

What is in those replies: remittance advice for payments already sent, questions about a PO, a request for a copy of an invoice, a note that the contact has changed, a dispute over a line item, a promise to pay on Friday. Each one changes what should happen next on that account. None of them changes anything automatically.

Handling time is the small part of the cost. The larger part is that the account's history is now split across at least three places: the invoice record in NetSuite, the thread in email, and the note in the spreadsheet. When a different collector picks up the account, or when the manager asks why an account at 68 days has had no contact in two weeks, the answer has to be reassembled by a person.

Native handles: sending, and delivery status where your mail configuration reports it. A person handles: triaging replies, routing them, and reconstructing account history on request.

Wednesday: what happens to a promise to pay?

It gets written down somewhere, and where it gets written down determines whether it survives.

A promise to pay is the highest value artifact in collections. A customer on a call says the payment will run in Friday's batch. That single fact should do three things: suppress the next scheduled reminder so you do not insult a customer who has just committed, set a follow-up for Monday if the payment does not land, and feed the cash forecast for the week.

Native dunning gives you a place to stop a reminder, generally an exclusion flag on the customer or the transaction, and coarse controls get used inconsistently under time pressure. It does not carry a promise date, it does not restart the sequence when the promise breaks, and it does not tell the treasury team what is expected to land on Friday.

So the promise goes in the spreadsheet. And the spreadsheet, which started as a triage aid on Monday, is now the system of record for the only forward looking data the collections process produces.

Native handles: stopping or pausing dunning on a flagged account. A person handles: recording the promise, restarting outreach when it breaks, and passing the expected date to whoever builds the forecast.

Thursday: how does a dispute stop the next reminder?

Through a flag somebody remembers to set, in a window somebody has to notice.

Disputes are the case where automated dunning does the most damage. An invoice is under dispute for a short delivery. The customer has raised it in writing. The credit memo is being reviewed internally. On day 45, the sequence advances and a final demand goes out on the disputed amount. That email costs you a relationship hour, a manager escalation, and occasionally a payment that was about to be released on the undisputed lines.

The native controls exist. The exclusion is set at the customer or transaction level, so a dispute on one line of one invoice tends to get handled by suppressing something larger than the dispute, which then has to be remembered and unsuppressed later. Nobody remembers. The account goes quiet for six weeks and reappears in the ninety day bucket.

The test to run on your own book this week: pick five accounts currently in dispute and check whether the dunning suppression on each one was reversed at the right time, and by whom. The answer is usually instructive.

Native handles: suppression once a flag is set. A person handles: noticing the dispute in time, setting the flag at the right level, and reversing it when resolved.

Friday morning: how does cash get applied, and does the aging tell the truth?

Cash application is the step that decides whether Monday's aging report is worth exporting.

Payments arrive as ACH with a remittance file, wires with a reference number that may or may not match an invoice, lockbox files, and checks with a stub. Clean, fully referenced payments match automatically. The rest, short pays, consolidated payments covering fourteen invoices with one total, deductions, unapplied credits, become a queue that a person works through.

Every unapplied payment sitting in that queue on Monday morning is an invoice that still looks overdue. Which means the dunning run may chase a customer who paid ten days ago, and the collector calling from Monday's list is calling accounts that are already square.

This is measurable before you buy anything. In a proof of concept, a customer connected their ERP and saw their own data within one day. Across 1,150 ACH, wire and lockbox payments, the out of the box automatic match rate came in at 78 percent, before any manual configuration. The useful part of that test is that the number came from their own receivables rather than from a reference deck, so it could be checked against what their team was doing by hand.

Native handles: matching clean, fully referenced payments and posting them to the invoice. A person handles: the exception queue, and the accuracy of every downstream number that depends on it.

Friday afternoon: where do the weekly number and the cash forecast come from?

From the collector, verbally, in most companies running native dunning.

The ERP can produce an aging snapshot and a DSO calculation. It cannot tell you what is likely to land next week, because the inputs to that answer are the promises, the disputes and the payer behaviour patterns that live in the spreadsheet and in the collector's head. So the weekly cash call becomes a round of estimates, and the quality of the forecast depends on who is in the room.

This is the point where an AR problem becomes a treasury problem. Finance is making decisions about drawdowns, payroll timing and vendor payments against a number that no system holds and no one can audit.

Native handles: aging, DSO, and historical reporting. A person handles: the forward view, from memory and a spreadsheet.

How big is the gap, in hours?

Add up the second column. Here is the week for a two collector team with roughly 900 open invoices across 400 active customers, on a fully configured native dunning setup.

Those minutes are placeholders. Run the same table with your own numbers, because the shape matters more than the values: one row is automated and seven are not.

The worked example totals 1,080 minutes, 18 hours a week across two collectors, roughly nine hours each. Over 46 working weeks that is about 830 hours a year, four tenths of a full time role, spent on work that no reminder schedule can absorb.

Hours are the visible cost. The larger cost sits in the accounts nobody reached. When the week holds time for twenty five calls out of 400 active customers, the accounts that get worked are the ones that surfaced, and the ones that surfaced are the loudest rather than the riskiest. The quiet account that slipped from 45 days to 75 while the spreadsheet was being maintained is the one that shows up in the bad debt provision.

What actually changes when that gap gets closed?

Two things worth naming, with the numbers attached.

The first is collector throughput. Across Tesorio's customer base, collector productivity increases 3x. That number describes how many accounts one of your people can carry in a week. If twenty five worked accounts a week become seventy five, the coverage problem in the paragraph above changes character for your team.

The second is DSO. Tesorio's average customer DSO reduction is 33 days. Turn that into money with your own arithmetic: at $60 million in annual revenue, one day of DSO is roughly $164,000 of working capital, so 33 days is about $5.4 million released from receivables. Across the customer base that has added up to over $200 million in working capital freed. Platform retention sits at 98 percent, which is the closest thing to a statement about whether teams keep using it after year one.

Those figures are averages from customers who moved off manual processes. Your own book decides how much of that applies, and the honest way to find out is a proof of concept against your data rather than a reference call.

When should you stay on NetSuite native dunning?

More often than a vendor will tell you. The genuine case for staying native is strong under specific conditions, and it holds when three things are true at once.

Your open AR is small enough that one person holds the whole book in their head. Your DSO is stable and inside your target. And nobody is maintaining a spreadsheet to do their job. That last condition is the test that decides it. If the entire process lives inside NetSuite and no one is exporting to Excel, the ERP is doing the work and a new tool would add a vendor relationship, an integration surface, a security review and a line item without removing a task.

Four more cases where staying put is correct:

• Your book is concentrated. If twenty accounts are eighty percent of receivables and a named collector manages each one by relationship, automation has less to grip. Prioritisation matters most across a long tail.
• You are mid migration on the ERP. Building workflows on top of a NetSuite instance that is still being reconfigured means building against fields that are about to change.
• Your real problem is billing accuracy. If invoices go out wrong, no cadence fixes that. A billing or revenue tool is the spend that addresses it, and dunning discipline on incorrect invoices makes the customer relationship worse.
• You have no capacity to run a change this quarter. Every implementation needs an owner inside finance. A rollout with no internal owner produces a tool nobody opens, which is a worse position than the ERP screen your team already knows.

Native dunning also carries advantages a third party tool cannot match. It is included in software you already pay for. Nothing has to move between systems, so nothing can fall out of step. It inherits your ERP's permissions and audit trail. And it improves with each NetSuite release at no additional negotiation.

What should I ask a vendor before layering AR automation on NetSuite?

Ask the operational questions a demo does not cover. Five that produce checkable answers:

1. How does your NetSuite sync handle a custom field we add ourselves, and what happens when the sync fails at 2am? Ask them to walk through the failure behaviour, who is paged, and what collectors see on screen while it is being repaired.
2. Show me the exact logic that ranks accounts for a collector's day, and tell me whether my team can change that logic without a services engagement.
3. How do a logged promise to pay, an open dispute and a pending credit memo each change what gets sent next, automatically and without a person remembering to set a flag?
4. How many days from ERP connection until we see our own aged receivables in your product, and will you run a proof of concept against our data before we sign?
5. What are your most common support complaints, and what is your median first response time?

The first question carries the most weight. Integration reliability is the most common complaint across the accounts receivable software category, and any vendor claiming their ERP integration never breaks is either new or not listening to their customers.

The fifth is worth pressing on because published G2 weaknesses are specific and checkable. HighRadius reviewers cite slow ticket resolution, frequent reassignment of support staff, communication delays, and lengthy implementation with inadequate support. Growfin reviewers cite infrequent updates, minimal customisation, and a mailbox feature with weak filtering and search. Both are real products with real customers, and both sets of complaints are worth raising directly with the vendor rather than treating as disqualifying.

How long does moving off native dunning take?

Short enough to matter, if you pick for it. Tesorio averages 1.31 months to go live against a category average of 5.35 months, and holds Ease of Setup at 97 percent and Ease of Admin at 99 percent against category averages of 85 percent for both. HighRadius publishes 8 months to implement and 16 months to ROI in its own G2 Value at a Glance, and Growfin publishes roughly 3 months to implement with a 6 month ROI, though it carries 58 total G2 reviews with none in the last 90 days and does not appear in the G2 Summer 2026 Enterprise indices at all.

For a team coming off native dunning specifically, the number to weigh is user adoption. Your collectors have a habit that works. Tesorio's User Adoption score is 95 percent against a category average of 64 percent, and a tool that half the team declines to open leaves you running the spreadsheet with an invoice attached to it.

The decision comes down to one thing you can check this week: open your collectors' tracking sheet and count the columns the ERP cannot see. If that number is zero, native dunning is enough. If it is seven, you already know what the second column of this article costs you.

One step, or the whole cycle?

Native dunning is a competent collections tool, and it owns the sending step without a person touching it. The other seven rows of the week sit outside what any reminder ladder reaches. An end-to-end order-to-cash analyst takes the cycle as its unit: credit limit through cash forecast, choosing which accounts to work from how each customer has paid before, and revising that call as replies land. The turn is from chasing the loudest account to working the riskiest, from history split across three places to one record, from a forecast spoken aloud to one you can check. Either answer holds up. The week above shows which one is yours.

If the case for moving is real, the case for moving quickly is stronger. Here is what a fast implementation involves: Tesorio in 30 days