How customer statements of accounts work in ERPNext
Finance teams with many customers carrying open invoices need a periodic statement that shows what each customer owes and how old those balances are. ERPNext can generate and email statements from filters such as customer group and territory, with an ageing summary, once outgoing email and scheduling are in place. The outgoing email setup is the prerequisite most teams underestimate, because a statement that is generated but never delivered does not help collections. Ad hoc reports suit a one-off question from a manager. A scheduled statement run suits a recurring obligation to send balances to customers on a fixed rhythm, with a consistent layout and a record of what was sent.
The exact behavior of the statement tool, including which filters are offered, how the ageing buckets are defined, what the default layout includes, and how scheduling is configured, depends on the ERPNext version you run. Confirm these details in your own environment before designing the process, ideally on a copy of production data with a few test customers. Check the version's documentation and release notes, and ask whether the statement can be limited to customers with an outstanding balance, since sending zero-balance statements is a common complaint.
Before go-live, decide who owns the customer list used for each run, who approves the send, and how bounced or undelivered emails are handled and reported back to the team. Confirm that the sending address, reply-to address and signature match what customers expect, and that customers with no email address on file are listed for follow-up rather than silently skipped. A test run with internal recipients, followed by a review of one sample statement per customer group, will expose most filter and formatting errors before real balances leave the company.
What a statement run depends on before the first email
A statement run is only as good as the data and infrastructure behind it. Each dependency below has a different owner, and a gap in any one of them shows up as bounced emails, wrong balances or statements that never leave the system.
Clean customer masters
Each customer that should receive a statement needs a primary contact with a valid email address, and the statement should go to the right people. Stale addresses, shared mailboxes nobody reads and duplicate customer records split balances across accounts. Before the first run, ask the accounts receivable lead to export customers with no email, bounced addresses and duplicates, and agree who corrects them in the master data. Owner: accounts receivable lead.
Outgoing email account
ERPNext sends statements through an Email Account configured for the site, so the sender address, SMTP server and authentication must work from the server itself. Test a delivery to an internal mailbox and check that replies reach a monitored inbox. Confirm with the mail administrator that the sending domain has the SPF, DKIM and DMARC records your mail provider requires. Owner: IT or mail administrator.
Scheduler and background workers
Scheduled statement runs depend on the background scheduler and worker processes being active. If the scheduler is paused, the run silently does not fire, and a long batch can queue behind other jobs. Ask the platform team to confirm the scheduler is enabled on the production site, that workers are healthy, and who receives failure alerts. Owner: platform or DevOps team.
Statement print format
The statement layout is a print format that lists invoices, payments and the ageing buckets for each customer. Build and review it with finance before the first run, including the currency, company logo, bank details and the language used for each customer group. Changes to the format after go-live alter every statement sent, so record approvals. Owner: finance controller.
Customer group and territory assignments
Selection by customer group or territory only works if every customer carries the right values. A customer left in the default group or with no territory gets missed or sent in the wrong batch. Agree the selection rules with sales operations, document which groups receive statements monthly and which quarterly, and check counts against a manual list before sending. Owner: sales operations.
Access rights for run and review
The users who select customers, trigger the run and review results need roles that allow them to read customer balances and send email, and nothing beyond that. Limit who can edit print formats or the email account, and check that reviewers can see the send log. Confirm the role matrix with the security owner before the first production run. Owner: IT security and finance systems owner.
Which selection and layout options fit which customer base
This table compares the main choices for who receives a statement, what each statement shows, how often the run happens and where copies go. Read each row for when the option fits, what it risks and what to confirm in your ERPNext version before the first live run.
| Option | When it fits | Risk to manage | Confirm in your version |
|---|---|---|---|
| Selection by customer group | Customers already sorted into groups such as wholesale, retail or key accounts, with one statement rule per group | Customers with a blank or wrong group are silently left out of the run | Which filters the statement run accepts and whether blank groups can be included |
| Selection by territory | Sales regions or countries map cleanly to who manages each account and who should receive the email | Territory is often set on the sales side only, so older customers may be missing or assigned to the wrong region | How territory is stored on customer records and how it is applied in the filter |
| Single named customer list | A short, controlled group such as a pilot, a set of disputed accounts or a few large clients | Manual lists go stale quickly and new customers are not picked up automatically | Whether the run accepts an explicit customer selection and how it handles disabled customers |
| All customers | Smaller books where every active account should receive a statement on the same cycle | Over-sending to customers with zero balance, dormant accounts or contacts who should not get statements | Whether zero-balance customers are skipped and how the run treats disabled or frozen accounts |
| Ageing summary | Customers who need a clear view of what is overdue without line-level detail, or a quick monthly reminder | Summary totals can hide a disputed or old invoice that the customer needs to see | Which ageing buckets appear and whether the ageing period matches your credit terms |
| Full transaction detail | Customers who reconcile against their own ledger, or contracts that require every invoice and credit note listed | Longer documents, more questions from customers and larger email attachments | Which transaction types are included, such as credit notes, advances and payments on account |
| Monthly run | A stable credit cycle with month-end close as the natural statement date | Customers may not pay on time for a 30-day cycle, so payments made after the run are not reflected | Whether the run can be scheduled and what date the statement reports as of |
| Fortnightly or on-demand run | Accounts with short terms, high volume or disputes that need a quicker update | More runs mean more email volume and more chances of duplicate or conflicting statements | How scheduled runs are configured and whether a run can be repeated without duplicating emails |
| Per-customer email | Customers expect their own statement addressed to their accounts payable contact | Missing or outdated contact emails on the customer record mean no delivery | Which contact is used as the recipient and how the email template is set per customer |
| Copy to finance mailbox | Finance needs a record of what each customer received and a place to spot bounced or unexpected statements | A shared mailbox can receive large volumes, and personal data is copied to more people | Whether a copy address can be set on the run and how bounced emails are reported |
How to set up statement sending in ERPNext step by step
This sequence takes statement sending from clean customer data to an approved, repeatable batch run, with a named check at each stage so finance can see that every prerequisite holds before customers receive anything.
Verify customer master data
Your ERPNext administrator exports the Customer list with customer group, territory, primary email address and default currency, then checks a sample against the source system. Use the Data Import tool with its downloadable template to correct gaps in bulk, and import only a few thousand records at a time as the documentation advises. Done when every customer you plan to email has a valid billing contact and the sample export matches the records you checked by hand.
Configure and test the outgoing email account
Create or confirm the Email Account that statements will use, including sender address, SMTP host and authentication. Ask your IT team to confirm that the sending domain has the SPF, DKIM and DMARC records your mail provider requires, since these settings sit outside ERPNext. Send a test message to an internal mailbox and a few external ones. Done when the test messages arrive in the inbox rather than spam and the sender name shows correctly.
Confirm scheduler and background workers run
Confirm with whoever operates the site that the scheduler and background worker processes are running on your hosting model, whether Frappe Cloud, Docker Compose or a bench installation on your own servers. Scheduled statement jobs and bulk email both depend on these workers. Check the background job queue after a short test job. Done when a scheduled test job completes and the queue shows no stuck or failed jobs.
Build or select the statement print format
Choose an existing Print Format for the Customer statement or build one that shows open invoices, payments, credit notes and the ageing summary your finance team uses. Confirm the company logo, bank details, currency formatting and language settings. Render the format for one customer with a known balance. Done when the rendered statement totals match the Accounts Receivable report for that customer to the cent.
Define the filter set and run a limited test
Define the filters for the batch, such as company, as-on date, customer group or territory, and whether the ageing summary is included. Run the batch against one small customer group, not the full list, and send only to internal test addresses first. Done when the test selects exactly the intended customers, excludes inactive or disabled ones, and every statement shows the expected as-on date.
Review rendered output with finance
Finance reviews a sample of rendered statements, including customers with credit balances, disputed invoices, multiple currencies and advances. Check that the wording, ageing buckets and payment terms reflect current policy and that no internal notes or other customers' data appear. Record review comments and resolve them before the next run. Done when finance signs off the sample in writing and each comment is closed.
Document approval for each batch
Write down who selects the customer group, who approves the send, who can override a recipient and who handles bounces or replies. Store the approval record with the batch date, filter values and count of statements sent. Ask your compliance or data protection lead to confirm that the process meets your internal policies for customer communications. Done when the approval roles are written, assigned and the first live batch has a recorded sign-off.
Choosing a statement cadence for each kind of customer base
A business with many retail or trade accounts usually wants one statement run for everyone on the same day each month. The filter can stay broad, selecting by company and, where needed, one customer group per run, so the run covers the whole receivables ledger and nobody is missed. Every account then receives a statement with the same layout, which keeps support questions predictable.
- Filter pattern: fix the company and run the whole customer base, or split by customer group only if contact data is uneven across groups.
- Review step: sample statements for a few zero-balance accounts and a few accounts with credit notes, and confirm the opening and closing balances match the Accounts Receivable report.
- Contact hygiene: confirm each customer has a primary billing contact with a valid address before the first run, since most early failures come from missing or outdated contacts.
- Failure mode, duplicate sends: a rerun after a timeout or a second overlapping schedule can email the same statement twice. Check the send log before retrying any batch.
Check the send log and a sample of statements against the receivables report before every monthly run.
A distributor with a few hundred key accounts usually sends statements grouped by territory and sales owner, on a fixed day, so the territory manager can answer the customer's calls. The filter is narrower: one territory or a small set of territories per run, with the company fixed and the ageing basis agreed with finance before the first send. Sales staff review their own accounts, which makes the run a shared commercial task as well as a finance one.
- Filter pattern: territory plus sales partner or owner, with the company fixed. Run one territory at a time when each sales team reviews its own list.
- Review step: the territory manager signs off the recipient list and any accounts on hold, such as accounts with a disputed invoice, before the send.
- Dispute holds: exclude or flag accounts with open disputes or a dunning letter already in progress, so the statement does not contradict a letter the customer has already received.
- Failure mode, dormant contacts: a key account may change its accounts payable team while the sales contact stays the same. Statements then go to someone who no longer pays invoices. Confirm the billing contact on each account at a set interval, such as each quarter.
Check each territory's recipient list against the billing contact on the customer record, not the sales contact.
A company with a long tail of small, infrequent buyers often needs less than a full statement. An ageing-only reminder, showing the overdue buckets and the total due, is shorter, easier for the customer to act on and cheaper to review. Limit the run to accounts with balances past due, so that the list stays small enough for finance to check before each cycle.
- Filter pattern: an overdue balance threshold, a customer group for the long tail, and ageing buckets chosen by finance. Exclude zero balances so that settled accounts are never contacted.
- Review step: confirm each listed account has a balance above the threshold and check for payments received since the ageing was last updated, since the report may not yet reflect them.
- Frequency control: send at a set interval rather than on every scheduled run, so a customer does not receive the same reminder each week. Confirm how the schedule and frequency options behave in your version before relying on them.
- Failure mode, dormant contacts and repeat reminders: accounts that stopped buying still carry a balance, and reminders sent to closed mailboxes create bounces and damage the sender's reputation. Route bounced and inactive accounts to a manual decision.
Review bounce reports and recent payments before each reminder cycle, and pass unanswered accounts to the collections process.
Security and operational controls for statement emails
Statement runs touch every open receivable and every customer's contact details in one action, so they need the same controls as any financial batch. The cards below cover who can run them, how balances are protected in transit and in shared inboxes, and how the run is logged, monitored and recovered.
Restrict who can run batches
Sending statements to many customers should be a permission held by a small group, not a side effect of general accounting access. Use Role Permissions and user permissions so that only the accounts receivable owner can select a customer group or territory and trigger the send. Review that list each quarter, because roles tend to accumulate over time. Confirm which role your team uses for bulk email in your own site before go-live.
Protect balances in shared mailboxes
A statement contains a customer's full open balance and invoice list, so it should not land in a general inbox where unrelated staff can read it. Decide whether statements are sent from a dedicated accounts address, whether copies go to an internal archive, and who may forward them. Check that the content shown in the email body matches what the customer is entitled to see, and confirm the rules with your data protection lead.
Keep credentials out of user notes
The outgoing mail account password belongs in the site configuration and the server environment, not in a shared document, a chat thread or an Email Account record that many users can read. Restrict who can open the Email Account and rotate the credential when staff change. Ask your implementation partner to confirm how the password is stored in your deployment and who holds server access.
Audit every batch sent
Record who started each statement run, which filters were applied, which customers were included and when each message was queued. ERPNext's Email Queue and Communication records help, but they should be checked against the filter used for the run, not assumed to be complete. Store the run parameters with the batch so an auditor or a customer dispute can trace a statement back to the balance it reported.
Monitor the queue and failed deliveries
A run that reports success may still leave messages stuck in the queue or bounced at the mail server. Review the Email Queue for held or failed items after each batch, and set a named owner for resending. Confirm which mail provider, sending limits and bounce handling apply to your domain, since these vary by provider and are outside ERPNext itself.
Plan custom statement logic with server scripts
Custom statement layouts or selection rules often start as Server Scripts. From version 15, 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. Decide early whether statement logic will live in a custom app on your infrastructure, and include the enablement and code review steps in the plan. Check the current Server Script documentation before you rely on this approach.
Include backups and the scheduler in routine operations
Scheduled statement runs depend on the background scheduler and workers being healthy, and a restore may bring back balances that were already paid. Confirm that scheduler status is monitored, that backups are taken on a schedule you can state, and that a restore test has been run. Ask your partner to document which steps are needed after a restore before statements are sent again.
Trade-offs between statements, reminders and dunning
Before scheduling anything in ERPNext, decide which of three communications a customer should receive for an open balance: a periodic statement of account, an overdue reminder, or a formal dunning letter. They carry different messages. A statement says "here is everything we show against your account" and is informational. A reminder says "this invoice is past its due date" and asks for payment without a penalty. A dunning letter, built from a Dunning Type with any fees or interest you configure, says "this is a formal demand, and charges may apply". Sending the wrong one changes how the customer reads the balance, so map each customer group to one primary communication before the first run.
Payment terms decide when a letter is justified. Due dates come from the invoice's payment schedule, so a statement sent before an instalment falls due will show a balance the customer does not yet owe. Confirm that the ageing buckets in your statement filters match how your Payment Terms Templates calculate due dates. For the same balance in the same week, a statement followed by a dunning letter is a common and avoidable collision. Set a rule that a customer with an active dunning cycle is excluded from routine statement runs, or that the statement is held until the dunning step closes. Test this with a few illustrative customers before you enable the schedule.
In regulated and public-sector contexts, the choice matters more. Buyers in these settings often have internal procedures, approval rules and dispute processes that treat formal demands differently from routine correspondence. Ask each such customer, or its procurement team, which communications it expects and where invoices must be disputed. Keep a record of which letter went to whom and when, since that trail supports both collections and any later challenge. Confirm with your legal and finance leads which contract clauses define late payment or charges before you configure any fee on a dunning type. The next steps are in the dunning and payment terms topics in this group.
Limits to confirm in your environment before go-live
Statement runs touch layout, scheduling, master data, volume and customization at once, so a gap in one usually shows up as a wrong or missing statement in another. The six cards below are the points to test in your own environment and installed version before any customer receives a statement.
Statement layout and filters
Confirm that the statement print format and the filters available in your installed ERPNext version produce the layout your customers and auditors expect. Check the ageing buckets, the currency shown, the period covered and whether open items and unapplied payments appear as you require. Test with a sample of real account types, not only a clean demo customer.
Scheduled jobs and email throughput
Find out how your hosting model runs scheduled jobs and how fast outgoing email is delivered for a large batch. Ask who controls the scheduler, whether background workers are dedicated to your site, and what your mail relay allows per hour. Shared hosting may restrict the settings that statement runs depend on, so confirm before you promise a send time.
Customer master data for grouping
Selection by customer group or territory is only as reliable as the master data behind it. Check that every customer has a group, territory and primary contact with a valid email address, and that the grouping fields are maintained by a named owner. Duplicate or blank records are the most common reason a statement goes to the wrong recipient or is skipped.
Batch size and splitting
The Data Import documentation advises importing only a few thousand records at a time, which is guidance for data loads rather than a send limit. Decide how to split large customer lists into batches, how each batch is logged and how a failed batch is re-run without duplicate emails. Test the split on a copy of production data first.
Language and currency localization
Decide whether statements must appear in each customer's language or in the customer's billing currency. Check whether your print formats, labels and number formats can switch by language, and whether multi-currency balances are shown correctly in one statement. Mixed-currency customers often need a separate review before the first run.
Custom code permitted by the plan
Some layouts or automations need server-side logic, and the Frappe Framework disables server scripts by default from version 15 onward. Confirm whether your hosting plan allows enabling them and who approves any custom app or script. If the plan does not allow custom code, design the statement within standard print formats and reports.
Questions finance and IT leaders ask before sending statements
What does it cost to set up customer statement emails in ERPNext?
The cost is the labor to configure and verify the feature, and it is usually a one-time project cost plus a smaller recurring cost for changes. ERPNext itself is free and open source, and self-hosting it has no license fee. The main cost drivers are the state of your customer master data, the number of statement layouts and groups you need, the mail setup, and the testing and review cycles with finance. Ask any provider for a quote built from a written scope that lists each of these items separately. For hosting, the ERPNext pricing page at frappe.io lists the published Frappe Cloud plan prices, which are separate from any implementation work.
How long does a customer statement project take?
Duration depends mainly on how clean your customer data is, how many customer groups or territories need their own statement runs, and how many approval steps finance and management require before the first live send. A small set of groups with clean contacts is a much shorter exercise than a multi-company book with missing email addresses. Ask for a schedule that separates data cleanup, mail setup, sample review and go-live, and confirm which approvals are in the critical path.
What does our team need to provide for the project?
You need a named finance owner who can decide statement wording, ageing buckets and which customers receive what, a dedicated mail account or sending domain, administrator access to the ERPNext site for configuration, and someone who signs off sample statements before any customer receives one. Access to a test copy of the site is also useful, so samples can be checked against real invoices without sending anything to customers.
Can an internal team set up statements without a partner?
Yes, for simple setups with a limited number of groups, a single company and reliable customer email addresses, an internal ERPNext administrator can usually configure the feature alone. The harder cases are multi-company books, many territories, email deliverability questions and scheduled runs at volume. Whichever route you choose, write a run procedure that covers who selects the recipients, who checks the samples, how failed sends are handled and who approves a change to the template.
Does the ERPNext version change how statements work?
Yes, the feature set, report layouts and background job behavior can differ between major versions, so confirm the version you run before you design anything. Frappe's supported versions page lists which ERPNext and Frappe Framework versions are supported and their end-of-life dates. Version 14 reached end of life on January 31, 2026, while version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029. Plan your statement design on a supported version, and test again after each minor release, since both supported major versions receive frequent updates.
What should we check before any statement goes to a customer?
Check that the recipient list matches the selected customer group or territory, that balances and ageing buckets agree with the receivables report, that each statement shows the right company and currency, and that the sending address, reply-to address and signature are correct. Send a sample set to internal reviewers first. Confirm that scheduled jobs run as expected on your hosting setup, and that someone monitors bounced emails after each run.
How does DeployOpen price this work?
DeployOpen does not publish a price list. Most engagements are fixed-scope, so a quote follows from a written scope that sets out the deliverables, the timeline and the items your team provides. Before you ask for a quote, list your customer groups, companies, currencies, mail provider and the number of statement runs you expect, so the scope can be written against them. Scope, deliverables and timelines are agreed in writing before work starts.
How DeployOpen scopes and delivers statement sending
DeployOpen plans, implements and documents statement sending inside your own ERPNext environment, so the scheduled emails, filters and mail setup run on infrastructure you control. Engagements are fixed-scope, with the statement format, recipient selection and delivery settings agreed in writing before any build work starts.
How we scope
- Inventory the customer groups, territories and receivable accounts that statements must cover, and who signs off each selection.
- Confirm the ERPNext version and hosting model, since statement behavior and background job setup depend on your environment.
- Agree the written scope, deliverables and timeline for statement sending before any configuration or build work begins.
How we build
- Configure the outgoing email account and sender identity that statements will use, and confirm how bounces and replies are handled.
- Set up the statement filters, ageing summary layout and scheduled sending for each agreed customer group or territory.
- Test with internal recipients and a sample of real accounts, checking balances, ageing buckets and attachments before scheduled runs go live.
How we hand over
- Document the statement schedule, selection rules, mail settings and the steps to add or remove a customer from the mailing list.
- Walk your finance and IT owners through how to review a failed send, rerun a batch and confirm the data behind each statement.
- Record the configuration in a form your team can review and reproduce, so changes are traceable after handover.
How we support
- Offer ongoing support, upgrades and monitoring of scheduled sends as a retainer, scoped separately from the initial build.
- Review statement runs after ERPNext upgrades or mail provider changes, since either can alter sending behavior.
- Ask any support provider to confirm response scope, change handling and how statement data is accessed in your environment.
