How ERPNext dunning letters work for overdue receivables
A finance leader whose overdue receivables are chased by individual emails and a shared spreadsheet usually has three problems at once: nobody can prove which reminder went to which customer, late fees are rarely charged because nobody agrees on the rate, and the final demand is written by hand outside the system that holds the invoice. ERPNext issues dunning documents directly from overdue Sales Invoices, so each reminder is tied to the invoice, the outstanding amount and the date it was sent. The fees and interest applied at each stage come from Dunning Types, which define the charge for each level of demand. This section explains how that chain works and when a team should formalize it rather than keep chasing by hand.
Formalizing collections is worth the effort when late payments are frequent enough that the team needs a repeatable sequence, when contracts or local rules expect a stated late fee or interest rate, or when auditors and management want evidence that demands were issued on time. The Dunning Type is the decision point: it sets the name, the flat fee, the interest rate and the text used at each level. Before building anything, confirm with your finance and legal advisers which charges your customer terms actually allow, which interest basis applies, and which stages must precede a final demand in each country where you invoice. Those answers determine the configuration far more than the software does. The page covers the Dunning Type configuration, issuing dunning from overdue invoices, letter text per language, and linking the final payment back to the demand. Confirm the exact fields, print formats and document behavior against the ERPNext version you run, because the Frappe documentation and release notes are the reference for each release.
Dunning configuration options and when each fits
This table compares the configuration choices for ERPNext dunning, from fees and interest on each Dunning Type to letter language, print formats and manual or scheduled issuing. Read each row for the situation where it fits and the cost it adds to your collections process. The main takeaway is that most choices can be settled in the written scope before build, and the ones that touch legal wording need your legal or finance owner to sign off.
| Option | When it fits | Trade-off to weigh |
|---|---|---|
| Fee and interest on each Dunning Type | Your terms or local rules set specific late fees or interest, and you want them applied consistently to each dunning stage. | Each stage needs its own rates. Confirm with your finance lead and counsel that the amounts and calculation basis are permitted where your customers are. |
| One Dunning Type for all invoices | Small receivables books with one set of terms and a single collections tone. | Fees and wording cannot vary by customer segment, so large or strategic accounts may need manual handling. |
| Separate Dunning Types by stage or segment | Different reminder tone, fees or interest for first notice, final demand, or distinct customer groups such as public bodies. | More configuration to maintain and test, and every change to rates or wording needs review across each type. |
| Letter text per language | Customers in several languages and you need reminders that match the language of the invoice and the customer's terms. | Each language needs a translated version reviewed by a native speaker, and updates must be kept in step across languages. |
| Standard print format | You accept default layouts and only need company branding and the required invoice references. | Limited control over legal wording or layout. Confirm with your counsel whether the default content meets local demand requirements. |
| Custom print format | Your demand letters must carry specific legal notices, bank details or local formatting. | Print formats need build, testing and ownership. Changes after go-live require a controlled release process. |
| Manual issuing of dunning | Low volume, or cases where a collector must review each overdue account before a letter goes out. | Relies on staff discipline and produces inconsistent timing. Record who issued each letter for audit purposes. |
| Scheduled issuing from overdue invoices | High invoice volume with consistent terms, and you want letters produced on a regular cycle without manual lists. | Errors in rules or data can send letters to the wrong customers at scale. Test against a sample of overdue invoices before enabling it. |
| Linking final payment to the demand | You need a traceable record that the payment settled the demanded amount, including fees and interest. | Requires disciplined payment allocation. Partial payments and credit notes need a defined treatment before go-live. |
How to set up Dunning Types and letters in ERPNext
This sequence takes a finance team from confirmed fee and interest accounts to a first dunning run that produces letters for overdue invoices. Each step ends with a check so that errors are caught on a sandbox invoice before any customer receives a letter.
Confirm the dunning fee and interest accounts
The finance lead and the ERPNext administrator confirm which income accounts receive dunning fees and late payment interest, and which receivable account each entry posts against. Check that each account exists in the company's chart of accounts, has the correct root type and currency, and belongs to the company that issues the letters. Done means the accounts are named in writing and the controller agrees with the choice before any Dunning Type is created.
Create the Dunning Type records
An ERPNext administrator creates one Dunning Type for each stage of collection the business wants to formalize, such as a first reminder and a final demand. For each type, enter the company, the dunning fee and interest settings, the accounts confirmed in the previous step, and the letter text. Check the saved records by reopening them and confirming that the accounts and amounts match the agreed policy, since these values control what the system posts.
Write letter text for each language
The collections lead drafts the body text for each Dunning Type in every language used by customers, with a reviewer who reads the local business and legal wording. Confirm that the placeholders for customer name, invoice number, outstanding amount, fees, interest and due dates resolve correctly in the print preview. Done means each language version has been previewed for a sample invoice and signed off by the person who owns the collections policy.
Test on a sandbox invoice
On a sandbox or test site, a tester creates a customer, submits a sales invoice with a past due date, and issues a dunning document from it. Verify the fee and interest postings in the general ledger, the ageing position of the invoice, the letter output and its language. Repeat with a partial payment to confirm the figures recalculate. Done means the journal entries and the letter match a hand calculation, and any defect is logged and fixed before production use.
Confirm the rules for linking final payments
The finance lead and an accountant agree how a payment received after a final demand is reconciled to the dunning documents and the original invoice. Test that the payment allocates to the invoice, that fees and interest are settled as intended, and that the dunning status updates. Confirm with the auditors or the controller which evidence they expect to see, such as the letter copies and the posting trail. Done means the test payment closes the demand cleanly and the reconciliation steps are documented.
Run the first dunning run in production
The collections lead selects the overdue invoices for the first run, using the filters and company restrictions set during testing, and generates the dunning documents. Review a sample of the letters and the postings before sending anything to customers, then distribute the letters through the agreed channel. Done means the run's documents, postings and letter copies are saved, and the person responsible has recorded the exceptions for follow-up.
How one overdue invoice moves through dunning
The accounts receivable clerk starts the cycle. When a submitted Sales Invoice passes its due date with an outstanding balance, the clerk reviews the overdue list and decides which customers are ready for a reminder. In ERPNext, the reminder is a Dunning document created from one or more overdue invoices, and the Dunning Type determines its stage, fees and letter. The clerk checks the invoice facts before generating anything, because the letter repeats them to the customer.
- Overdue selection: Confirm each invoice is submitted, still outstanding and past the due date calculated from its payment terms.
- Stage choice: Pick the Dunning Type that matches the step (first reminder, second notice or final demand) so the template and charges are correct.
- Document creation: Generate the Dunning from the customer's overdue invoices, then review each line for disputed or partly paid items.
- Contact and language: Check the customer's preferred language and the contact the letter will go to, since letter text is set per language.
- Prior credits: Look for open credit notes or unallocated payments that already cover part of the amount.
Before the Dunning is sent, confirm that every invoice on it should be chased at this stage and that nothing in the customer's account already settles it.
The controller sets the policy that the clerk applies. Dunning fees and interest change what the customer owes, so the controller decides which charges are allowed, how they are calculated and where they post. Because these amounts affect receivables and the ageing report, the controller also reviews the accounting before the first letter goes out, not after a customer queries it.
- Charge accounts: Confirm the income accounts for dunning fees and interest exist in the chart of accounts and map to the right reporting lines.
- Interest basis: Confirm how ERPNext calculates interest on each Dunning Type and whether your contracts and local law permit the rate and basis you set.
- Posting effect: Confirm whether fees and interest create journal entries against receivables and how they appear in the ageing report.
- Approval step: Decide who approves a Dunning before it is sent, and which cases need a second review.
- Legal wording: Have counsel in each jurisdiction review the letter text, especially for final demands.
Test the full path on a non-production copy of your site with sample invoices, then reconcile the receivable balance before and after to confirm the postings match your expectations.
The customer sees the result of the process as a letter, usually sent by email or printed. What they receive has to be clear enough to act on without calling your team: which invoices are overdue, what the original amounts are, what fees and interest were added, the total demanded, the payment deadline and where to pay. Ambiguous letters generate disputes that stall collection, so the customer's view is a design requirement for the Dunning Type and print format.
- Invoice detail: The letter should list each overdue invoice with its reference, date and original amount.
- Charges shown separately: Fees and interest should appear as their own amounts so the customer can check the total.
- Language: Confirm the letter text exists in the customer's language and that the correct version is selected for each recipient.
- Payment instructions: Bank details on the letter must match the company's accounts, and the deadline must be stated.
- Dispute route: Give a contact address for questions, and make sure a disputed invoice is paused and routed back to the clerk.
Before go-live, send test letters to internal addresses in each language and check that every figure matches the underlying invoices.
The process closes when the customer pays, and the payment has to be tied back to the demand, not only to the original invoice. A payment may cover the invoice alone, the invoice plus fees and interest, or only part of the total. Each case leaves a different balance, and the record needs to show which lines are settled and which still need follow-up. This step is where collections data either stays accurate or drifts out of line with the ledger.
- Allocation: Confirm the Payment Entry allocates to the invoice and to the fee and interest lines, not just the invoice.
- Partial payment: Confirm how the unpaid remainder carries into the next Dunning stage.
- Bank matching: Use the Payment Reconciliation tool to match bank receipts against outstanding amounts.
- Settled status: Confirm how the Dunning record reflects full settlement in your version before relying on it for reporting.
- Write-off: Decide how uncollectible balances are handled once the final demand has lapsed, and who approves the entry.
At month end, check that the receivable balance, the ageing report and the bank records agree for every customer that received a Dunning during the period.
Where dunning projects go wrong
Most dunning problems in ERPNext are configuration gaps that surface only when a letter goes out or a customer disputes one. The four failure points below are set up before the first letter is issued, and each one is easier to fix during build than after customers have received demands.
Fee and interest accounts left unset
Dunning Types can charge a dunning fee and interest, and both post to accounts that must exist and be correct for the company. If the income accounts are missing or point to the wrong company, the demand either fails to calculate or books the charge to an unintended account. Confirm the fee and interest accounts for each company in a test environment, then review a sample journal entry produced by a dunning run before go-live.
Letter text missing for a language
Dunning letters use print formats and letter text that are set per language. A customer whose preferred language has no approved text may receive a blank letter, an English fallback that breaks local rules, or no letter at all. Agree the list of customer languages with the credit team, approve the wording for each one with legal or local counsel, and test each template with a real customer record before the first run.
Demands sent before terms expire
Dunning relies on overdue status, which depends on the due date generated from payment terms. If a template is applied to a customer on longer terms, or a due date was calculated from the wrong posting date, the letter demands money that is not yet owed. Check the due date on a sample of invoices against each customer's payment terms, and set a grace period in the Dunning Type where your policy requires one.
Payments not tied to the demand
A payment received after a dunning letter must be matched to the invoice and to the dunning record, or the file stays open and the customer keeps receiving reminders. Partial payments, bank references that do not match invoice numbers and fees posted separately from principal make this worse. Define who reconciles incoming payments, how fees and interest are allocated, and when a dunning record is closed, then test that flow with a partial payment before the process runs in production.
Controls over fees, interest and customer letters
Decide first who may create, submit, edit and cancel dunning documents, because ERPNext applies these rights through role permissions on each DocType, not through a separate collections setting. In practice, the collections team usually needs to create and read Dunning records, while only a finance approver should submit them and cancel them. Check the permission rules for Dunning and Dunning Type in your version with the Role Permission Manager, and test them with a non-administrator user before go-live. Also confirm whether User Permissions restrict dunning by company, since a collections user who can see several legal entities may issue letters on the wrong entity's invoices.
Fee and interest rates sit on the Dunning Type master, so changes to them affect every future letter. Treat Dunning Type edits as master data changes: limit write access to a small finance group and define in your own policy the approved fee amounts, interest basis, grace periods and any maximums. The platform enforces only what is configured. If you plan to add custom fee logic through a Server Script, note that from version 15 Server Scripts are disabled by default, must be enabled with server_script_enabled, and cannot run on Frappe Cloud public shared benches. Put any such script and the letter text for each language under change control, with a named owner who signs off each edit.
For review, rely on the document history that ERPNext keeps for submitted and cancelled records, and enable Track Changes on the DocTypes you want to audit. Each dunning fee and interest charge should trace to a posted accounting entry, so run a periodic check that the ledger movements match the dunning register for the period. Cancellations should be explained, not silently reversed. Set a review cadence, decide who signs it off, and define how long records and letter versions are retained, which your auditors and the policy you set will need to confirm. DeployOpen can help document these controls, but auditors and certification bodies decide whether they are sufficient.
Security and operational considerations
Dunning letters contain customer names, balances, invoice details and bank instructions, and they go out on a schedule without anyone reviewing each one. The cards below cover who can see and send them, how email and scheduled runs behave, and what to recheck after an upgrade. Each one is a point where a collections process can leak data, send the wrong demand or quietly stop.
Limit who can issue dunning
Dunning letters expose customer names, overdue amounts and invoice references to anyone who can open the print view or trigger a run. Decide which roles may create Dunning records, submit them and change Dunning Types, and keep those roles separate from the people who post payments. Confirm that a user with read access to a customer record cannot also generate a letter for every overdue account. Test the restriction with a non-finance account before go-live.
Control letter templates and language text
Letter text is saved as print formats and translated strings, so anyone who edits a template changes what every customer receives. Restrict edit rights on print formats and track changes through your customization process rather than in the live site. Check that each language version names the correct company, bank details and contact address. A wrong remittance account in a final demand is a payment fraud risk that customers may not question.
Verify outgoing dunning email
Dunning emails depend on the outgoing email account, sender domain authentication and the customer's contact address on file. Send a test dunning to an internal mailbox, confirm the attachment renders the correct amounts and check that the message is not routed to a shared or outdated contact. Agree who receives bounces and replies, because a customer's dispute reply that lands in an unmonitored inbox can turn into a missed legal deadline.
Review scheduled and automated runs
Dunning is usually triggered by a scheduled job or a manual batch, and failed background jobs can skip customers without any visible error. Confirm which runs are scheduled, what overdue threshold they use and who is notified when a job fails. If you add Server Scripts to automate fee or interest logic, check that the script setting is enabled on your deployment, since hosted shared plans may not allow it. Keep a record of each run so a customer can be shown the exact letter sent.
Recheck dunning after each upgrade
Minor releases of ERPNext ship frequently, and changes to accounting, print or email code can alter fee calculation, rounding or template rendering. After every upgrade, rerun a set of known overdue invoices against a staging copy and compare the generated letters and interest figures with the previous output. Include a check that payments linked to a final demand still close the correct invoices. Record the results so auditors can see the control was tested after the change.
Protect backups and copies of letters
Dunning records and generated PDFs are copies of customer financial data, and they often end up in exports, email archives and shared drives. Include them in the backup scope and the retention rules for accounts receivable, and set a deletion policy that matches your data protection obligations. Restrict who can export the Dunning list. Restores should be tested against a sample so you know a rebuilt site still links each letter to the right invoice and payment.
Questions buyers ask about ERPNext dunning and collections
How much does it cost to set up dunning letters in ERPNext?
Cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The main cost components are discovery of your current collections policy, configuration of Dunning Types and letter templates, account mapping for fees and interest, testing against real overdue invoices, and handover. The work is one-time, while the ongoing cost is the time your finance team spends reviewing letters and maintaining wording as policy changes. Ask for a quote that separates configuration, custom letter work and any retainer for later changes. ERPNext itself is free and open-source under GPL-3.0, so licensing is not a cost driver for this topic. Hosting costs depend on where you run ERPNext, and the ERPNext pricing page lists Frappe Cloud starting points for reference.
How long does it take to configure dunning in ERPNext?
Duration depends on how many dunning policies you have, how many languages the letters need, and how much of your fee and interest logic is already written down. A single policy in one language is the simplest case. Each additional Dunning Type, letter language or account mapping adds review and testing. The longest step is usually agreeing the policy with finance and legal, not building it in ERPNext. DeployOpen states timelines only in the written scope for each engagement, so ask for a schedule that lists the policy sign-off as a milestone. Your own team can start the policy and wording work before any build begins, which often shortens the engagement.
What does our finance team need to provide before dunning is built?
Before configuration starts, your team should provide a written fee and interest policy, the letter wording for each language you invoice in, and the account mapping for fee and interest income. The policy should state when a reminder is issued, which overdue thresholds trigger each level, what fee applies at each level, how interest is calculated and on which base, and who approves exceptions. For each language, you need approved text for every level, including the legal notice wording your counsel requires. For account mapping, confirm which ledger accounts receive dunning fees and interest income, and which cost centers apply. Missing items here are the most common cause of rework.
Can our finance team configure ERPNext dunning without a partner?
Yes, a team with ERPNext accounting experience can configure Dunning Types, fee and interest settings and basic letter templates in the standard interface. The harder part is making the configuration match the written policy and testing edge cases, such as partial payments, credit notes on overdue invoices and invoices in foreign currency. A partner adds value when you need multiple languages with legal wording, custom print formats, scheduled or automated issue rules, or linkage between the final payment and the demand. Decide which of those you need, then review what your team can own over time. Your team will also need to maintain the letters after go-live.
What makes custom dunning letter work cost more?
Custom letter work costs more when it goes beyond the standard templates. The main drivers are the number of languages, legal or regulatory wording that must be checked for each jurisdiction, custom print formats with specific layout or branding, and logic that depends on customer groups, territories or invoice types. Server-side logic also adds work: in ERPNext version 15 and later, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so the hosting choice affects what is possible. Ask the partner to list each custom element separately in the quote, with a note on who approves the final wording.
How do we link the final payment to the dunning demand in ERPNext?
The link is created by recording the payment against the overdue sales invoice that the dunning letter referred to, so the outstanding balance, the fees and the interest close together. Your team should confirm that the payment reconciles to the invoice and that the dunning record shows the payment in its history. Check how partial payments are allocated between principal, fees and interest, because the allocation rule changes what remains open. Document the process so that collectors and auditors can follow one demand from the first reminder to the final settlement. Test this with several payment patterns before go-live.
What should we confirm about interest and fees for legal compliance?
Confirm with your legal and tax advisers which interest and fee rules apply in each country where you collect debts, and whether there are caps, notice periods or wording requirements. DeployOpen prepares systems and evidence for compliance assessments but does not decide your legal position or issue certifications. Ask the implementation to record each rule in the policy document, so the configured value can be traced back to its source. Revisit the setup when rules change, because the letters and calculations must follow the current law.
What ongoing support do dunning configurations need after go-live?
After go-live, the configuration needs review when policy changes, when you add a language or customer segment, or when ERPNext is upgraded to a new version. ERPNext and Frappe Framework version 14 reached end of life on January 31, 2026, so plan upgrades on a supported version. Ongoing support, upgrades and testing are available as DeployOpen retainers, and the scope is agreed in writing. Your team should keep a change log for letter wording and fee settings so that each change is approved and dated.
How DeployOpen scopes and delivers ERPNext collections
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside your own infrastructure, and ERPNext collections work follows the same method. We start from your collections policy and overdue-invoice data, configure Dunning Types and letter text in the languages your customers use, and test every step on a non-production copy of your site before go-live.
How we scope
- Written scope lists the Dunning Types, fee and interest rules, and the customer groups each will cover.
- We confirm which overdue invoices, companies and currencies are in scope before any configuration starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We configure Dunning Types with fees and interest rules and test them against sample overdue invoices.
- Letter text is written per language and checked with your finance and legal reviewers before activation.
- Payment linking to the dunning demand is tested end to end, including partial and late payments.
How we hand over
- You receive the configuration, letter templates and a runbook describing when and how dunning is issued.
- Test cases and results document each rule so your auditors or internal reviewers can trace the logic.
- Your team is trained to issue, review and reverse dunning letters without relying on DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover ERPNext version changes that affect Dunning Types, print formats or email delivery.
- Confirm response expectations and what the retainer excludes in the written agreement before signing.
