NetSuite Dunning Setup Questions Before Customer Emails Go Out
Before enabling NetSuite dunning emails, prove three things: the invoice is eligible for contact, the recipient is correct and the proposed message reflects the current account position. Then verify how the process pauses, resumes and records delivery attempts. A technically successful schedule can still send an inappropriate reminder if the surrounding data and controls are wrong.
This guide is a pre-send readiness review for the Dunning Letters SuiteApp. It focuses on configuration decisions, safe testing and release evidence. Collection policy, contractual notices and jurisdiction-specific communication requirements need approval from the appropriate business and legal owners.
Choose the scope of the procedure
Oracle's Dunning Overview describes procedures assigned to customers, invoices or invoice groups. Scheduled evaluation determines eligibility and the relevant level; configured preferences determine automatic or manual delivery. Only posting invoices are evaluated.
Choose the level that matches how your customers pay and how your team resolves disputes. A customer-wide conversation can be efficient, but one disputed invoice may require more granular treatment. Document why the chosen scope fits the business and what happens when a customer has several billing contacts.
Map procedure ownership by subsidiary and customer group. Where several procedures could apply, test the assignment result rather than assuming that the most recently edited procedure wins. A release record should identify the actual procedure assigned to every pilot customer.
Establish an eligibility checklist
Before a reminder becomes sendable, confirm the invoice remains open, its due date is correct and the balance reflects recent payments and credits. Check whether unapplied cash could explain the apparent overdue amount.
Define how the process handles disputes, agreed payment plans, insolvency or legal cases and customers requiring manual relationship management. These categories need approved communication rules; they should not be inferred from an aging bucket.
Give exclusions owners and review dates. A paused or excluded invoice should remain visible in a resolution queue. Otherwise, suppressing an inappropriate email can also remove the pressure to solve the underlying problem.
Verify recipients beyond a valid email address
An address can be syntactically valid and still belong to the wrong person. Confirm the payer's accounts-payable contact, the appropriate escalation recipient and whether the customer record's general email should receive notices.
Oracle's recipient configuration guidance describes customer-email controls, additional contacts and level-specific recipients. Review To, CC and BCC behavior using the actual configured records and templates.
Use test cases for a departed contact, a shared AP mailbox, a customer with two legal entities and a sales representative who changes accounts. Ensure that a contact update removes obsolete recipients as well as adding new ones. Avoid assuming that a successful delivery report proves that confidential account information reached an authorized person.
Review the message as a customer would
The message should identify the seller, invoice, balance, currency and clear next step. Include a route for questions and a verified payment method appropriate to the account. Avoid adding unsupported charges or legal threats through a generic template.
Review the wording at every escalation level. A later-stage template may be unsuitable for a customer who has a valid dispute or has already provided a remittance. The relationship owner should approve the tone and the operational owner should confirm the data fields.
Test long customer names, multiple invoices, foreign currency amounts and relevant languages. If a template includes links or attachments, verify that they point to the intended destination and do not expose another customer's information.
Hypothetical example of an unsafe resume
A distributor pauses dunning on a 6,500 invoice while sales investigates a pricing dispute. Two weeks later, finance approves a 500 credit and the customer promises the remaining 6,000 by Friday.
Simply clearing the pause may cause a reminder to go out before that agreed payment date. Oracle's pause and resume documentation warns that clearing Pause Dunning immediately triggers evaluation and may send a letter.
The owner should first verify that the credit posted, the correct balance appears and the communication policy accommodates the promise. Capture the resolution reason before changing the pause state, then confirm the resulting evaluation. This example explains a control point, not a tested result in a customer account.
Run a dry review without contacting real customers
Prepare a bounded test population with controlled recipients and verified outbound-email safeguards. Do not assume that a sandbox automatically prevents every external message; confirm the actual environment settings before running tests.
Include a fully paid invoice, partial payment, unapplied receipt, disputed invoice, missing email, wrong-language contact and customer at an escalation boundary. Record the expected eligibility, recipient, template and amount for each case before evaluating the process.
A dry review is an implementation method, not a claim that the SuiteApp offers a universal button with that name. Use the account's supported evaluation and delivery controls, and have an administrator verify that no real customer message is released during preparation.
Approve the first production release
The release packet should include the customer population, procedure assignments, excluded cases, verified recipients, approved templates and observed test results. Name the person authorized to enable the schedule or release the initial messages.
Start with a scope that the team can review promptly. Check the first actual results for unexpected recipients, missing balances and simultaneous personal collector outreach. Expand only after those findings are resolved.
Keep a rollback or pause procedure ready. It should identify who can stop further sends, how to inspect queued work and who decides whether customers need a correction. Do not automatically resend a batch after an uncertain error; first establish which messages were sent.
Monitor the outcomes that matter
Review undelivered messages, customer replies, incorrectly contacted accounts and unresolved paused cases. Count exceptions by cause so the team can repair contact maintenance, billing accuracy or cash-application timing.
Avoid treating email volume as a collection result. Track whether the expected customer action occurred and whether the underlying balance was paid, credited or otherwise resolved. Keep those outcomes separate in reporting.
For procedure assignment, template testing or support of an existing setup, CuriousRubik's NetSuite support services can help review the actual configuration and first-send evidence.
Before each later template release, compare the changed fields and recipient rules with the approved baseline. A cosmetic edit can accidentally change a balance field, payment link or conditional section. Retain a rendered sample for each affected level and language, and have the business owner approve the changed output rather than only the template source.
Frequently asked questions
Should every overdue invoice receive an automatic email?
Eligibility should follow approved policy and the current account facts. Disputes, payment commitments, unapplied receipts and sensitive cases may need a different communication path.
Can resuming dunning send a message immediately?
Oracle says clearing the pause triggers evaluation immediately and may send a letter. Review the balance, recipients and expected next action before resuming.
Does a valid customer email prove the recipient is correct?
No. Confirm the person's role, entity and permission to receive account information. Review additional contacts and escalation recipients as well.
Is a dry run a guaranteed standard feature?
This guide uses the term for a controlled review method. Verify the supported evaluation, queue and outbound-email controls in your account before testing.
What should happen after a send error?
Establish whether any messages were accepted or delivered before retrying. Preserve the result records and avoid duplicating a reminder when the outcome is uncertain.