Automated dunning in NetSuite: structuring collections without a side system.

The pattern behind almost every dunning process

Ask most finance teams how collections actually runs, and the honest answer follows a familiar shape. Someone exported the list of open receivables from the ERP into a spreadsheet a few years ago, because reminder letters needed to go out and nobody had time to build the process properly inside the system of record. That spreadsheet — or a mail-merge tool bolted on next to it — became the process. One person owns it. They know which customers are on which reminder stage, roughly, because they carry it in their head and in a column of manually updated dates.

The company grows. Entities multiply, invoice volume climbs, the customer base spreads across more countries. The spreadsheet does not get rebuilt — it gets patched. A second tab for a second entity. A second person helping out during peak season, working from a copy of the file that is a day out of date the moment it is opened. Nobody set out to run receivables this way. It is simply where "we'll fix it properly later" ends up, year after year, while the ERP underneath was capable of running the whole thing natively the entire time.

What the drift actually costs

The cost of a dunning process that lives beside the ERP rather than inside it is not abstract. It shows up in specific, recurring ways:

• No single source of truth. The spreadsheet and the ERP disagree the moment a payment is applied, a credit note is issued, or a second person updates their own copy. Nobody can say with confidence, at a glance, who has actually been reminded and when.
• Duplicate reminders. Two people working overlapping lists — or one person working from a stale export — send the same customer two reminder letters in the same week. It looks unprofessional at best, and damages a customer relationship that finance was trying to protect at worst.
• No clean audit trail. When a dispute needs to be reconstructed — did the customer receive the second reminder before the account was placed on hold — the answer lives in an email inbox, a mail-merge log, or someone's memory, not in a system record that can be pulled on demand.
• Dunning logic in someone's head. Escalation levels, cooldown periods between reminders, which customers get an extra grace period — the rules exist, but they exist as tribal knowledge rather than as configuration. The process cannot scale past the one person who understands it, and it cannot survive their absence.

A reminder that goes out twice is not a system failure. It is a design failure that was never fixed — because the process was never asked to live inside the system of record in the first place.

What a properly designed native dunning process needs

None of this is a NetSuite limitation. It is a delivery gap — the dunning process was never designed as a first-class configuration inside the ERP. A properly built native process needs a specific set of capabilities, and all of them are achievable without a side tool:

• Configurable dunning levels, deadlines, cooldowns and escalation paths. The rules that decide when a first reminder becomes a second, when a cooldown period prevents a customer from being contacted twice too soon, and when an account escalates — held in configuration, not in someone's memory.
• Portfolio-level and invoice-level handling, side by side. Most B2B collections work happens as scheduled dunning runs across the customer portfolio. But finance also needs to reach into a single invoice and handle it on its own terms — a disputed line, a VIP account, an exception — without breaking the batch process for everyone else.
• Multi-language communication. An international customer base does not receive reminder letters in one language. The process needs to generate and send correspondence in the customer's language as a matter of configuration, not manual translation.
• Safeguards against duplicate reminders. The system, not a person, has to be the one that knows a reminder already went out for this invoice at this level, this period.

JPS-iQ Collections, as the concrete illustration

This is exactly the gap our own module, JPS-iQ Collections, was built to close. It digitises the full dunning process natively inside NetSuite, from previewing open receivables through to sending and documenting reminders — no export, no side spreadsheet, no separate mail-merge step.

Concretely, it supports both customer-level B2B dunning runs across the portfolio and targeted handling of individual invoices, with configurable dunning levels, deadlines, cooldowns and escalation paths. Reminder letters go out as automatically generated PDFs dispatched by email, in the customer's language, with built-in protection against duplicate reminders. Optional credit hold and finance-charge logic are available where a group's collections policy calls for them. Every step — preview, dispatch, escalation — is recorded inside NetSuite, which is what makes the audit trail real rather than reconstructed after the fact.

What to check before you build or buy a dunning process

Whether your organisation is evaluating a third-party collections tool, building something in-house, or simply deciding whether to finally formalise the spreadsheet process, the same three questions apply:

• Does it run inside the ERP, or beside it? A tool with its own copy of customer and invoice data is a second system to keep in sync, and every place where two systems have to agree is a place where reconciliation breaks quietly.
• Is there a real audit trail? Not a log file somewhere, but a record — inside the system of record — of every reminder, every level, every date, retrievable the moment a dispute or an audit requires it.
• Can the dunning rules actually be configured without a developer? Escalation levels, cooldowns and language variants change as the business changes. If every adjustment needs a change request, the process will quietly fall back to manual workarounds within a year.

This is the same discipline that runs through Finance as one of the group's core areas of expertise: architecture decisions that hold up under audit, not workarounds that hold up until the next one. A dunning process that has drifted into a spreadsheet is rarely a sign that the ERP cannot do the job. It is usually a sign that nobody was asked to design it properly inside the system that was already there.