How ERPNext payment terms shape receivables and payables
In ERPNext, payment terms decide how a sales or purchase invoice is split into due dates, and those due dates are what your receivable and payable ageing reports use. A finance lead with contracts that call for a deposit, staged payments and a credit period needs those milestones to show correctly in ageing, not just a single total due date. A Payment Terms Template is a named set of Payment Term rows. Each row sets a share of the invoice amount (or a fixed amount), a credit period in days or a due date basis such as invoice date or month end, and optionally an early payment discount. You attach the template to a customer or supplier, or pick it on the invoice, and ERPNext calculates one due date per row.
The template does not do the rest of the job. It does not post payments, match money received to invoices, send reminders or stop an overdue customer from ordering. A deposit recorded as a term still needs a payment entry, and collection follow-up belongs to dunning, which is covered in the collections section. Use a Payment Terms Template when the invoice has more than one expected payment date, when a credit period differs from your default, or when a discount window must apply to a specific schedule. A single due date on the invoice is enough for simple net-30 sales. Before you build templates, confirm with your ERPNext version how the due date basis, discount basis and rounding of the instalment amounts behave, and test one invoice of each contract pattern against the ageing report.
Early payment discounts need the same care, because the discount date is part of the schedule and a late payment can fall outside it. Decide which accounts post the discount, whether it applies to the gross amount or the amount after tax, and who can override a term on a submitted invoice. Those decisions belong in the design document before any template is built, so finance and sales agree on what an invoice means. For the exact fields and behaviour in your version, check the Payment Terms documentation in the ERPNext manual and test with a copy of your production data.
Payment term configuration options and when each fits
This table compares the five ways a team can shape when money is due in ERPNext: deposits, instalments, net credit periods, fixed due dates and early payment discounts. Read each row for the use case, what the option changes in receivable and payable ageing, and what someone on the finance team must keep current after go-live.
| Option | Best fit | Effect on ageing | Ongoing maintenance |
|---|---|---|---|
| Percentage-based deposit | Orders where part of the value is paid up front, such as made-to-order goods or project work | Splits the invoice value into portions with their own due dates, so the unpaid balance ages separately from the deposit | Confirm the percentage still matches the commercial agreement and review templates when pricing or contract terms change |
| Fixed-amount instalments | Agreed payment plans with set amounts on set dates, such as staged deliveries or financed purchases | Each instalment ages on its own due date, so one late portion shows as overdue without marking the whole invoice late | Keep amounts and dates aligned with the signed schedule and update them if the customer renegotiates |
| Net credit period | Standard trade terms where payment is due a set number of days after the invoice date | Due date moves with the posting date, and ageing buckets fill as the period passes | Re-check templates against the terms in each customer or supplier contract, since a mismatch distorts collection lists |
| End-of-month or specific-date due date | Customers who pay on a fixed monthly run, or suppliers paid on a set cycle | Due dates cluster at period ends, which concentrates overdue items in specific ageing reports | Confirm the cut-off logic with the team that runs payment batches and test it near month end |
| Early payment discount row | Negotiated incentives where paying within a short window reduces the amount due | Creates a second, earlier due date with a lower amount, so the same invoice can show different outstanding values by date | Maintain discount percentages and windows in the template, and confirm how discounts are booked when the customer pays late |
Early payment discounts versus ageing and reporting
Finance operations decides the commercial rules before anything is configured: which terms carry a discount, how long the discount window stays open, and whether the discount applies to the net amount or the gross amount including tax. In ERPNext, the discount is attached to a payment term, so each rule is only as good as the template it sits in. The key question is accounting treatment. A discount taken on a customer payment can either reduce the receivable by the discount amount, or be posted to a discount expense account. Confirm which treatment your policy requires and test it on a sample invoice before you rely on it.
- Discount basis: Confirm whether the percentage applies to the net total or the grand total with tax, and whether the discount reduces the tax base. Tax authorities in some jurisdictions treat this differently, so check with your tax adviser.
- Invoice totals: Verify that the outstanding amount on the invoice after the discount window matches what the customer is expected to pay.
- Receivable or expense: Decide whether the discount reduces the receivable on settlement or posts to an expense or income account, and map the account in the company settings.
- Window rules: Agree whether a payment received one day after the discount window closes receives no discount, or whether the grace period is a commercial exception handled manually.
- Approval: Define who may approve a discount outside the standard terms and how that exception is recorded.
Before sign-off, post a test invoice inside and outside the window, pay it in full and in part, and confirm the general ledger entries match the policy.
Controllers care about where each row lands once discounts and instalments are in play. A payment that settles a scheduled term may be partly allocated, partly carried as an advance, or matched to a credit note. Each of these choices affects which bucket the outstanding amount appears in on the Accounts Receivable or Accounts Payable ageing report. Ageing is driven by the due date of each payment schedule row, not only by the invoice date, so a partial payment that leaves an earlier instalment open will age differently from a payment that clears it in full. Test these cases against the report output, not only the ledger.
- Partial allocation: Check how a partial payment is applied across schedule rows, and whether the earliest unpaid row is cleared first.
- Discount on partial payment: Confirm whether a discount applies to a partial payment, or only when the full term is settled inside the window.
- Late payment with discount: Test a payment received after the window closes, and confirm the discount is not applied silently.
- Ageing buckets: Compare each open row in the ageing report against its due date and outstanding amount, including rows partly settled by discount.
- Reconciliation: Use the Payment Reconciliation tool to match payments to invoices, then rerun the ageing report and confirm totals agree with the receivable control account.
Run these cases on a copy of production data, then confirm the ageing totals reconcile to the general ledger balance on the same date.
The most reliable way to validate this setup is a short, written test plan that both finance operations and controllers sign. Each case should state the starting invoice, the payment terms applied, the payment amount and date, the expected ledger entries, and the expected ageing result. Illustrative example: an invoice with a 30-day window and a 2 percent discount if paid within 10 days, paid in two parts, one inside the window and one after it. The reader should check that the discount applies only to the part paid inside the window, and that the remaining balance ages from its own due date.
- Full payment inside window: Confirm the discount amount, the ledger entry, and that the invoice closes with no outstanding balance.
- Full payment after window: Confirm no discount is applied and the invoice closes at the full amount.
- Split payment across window: Confirm how the discount is calculated on each part and that the ageing row for the remainder is correct.
- Overpayment or advance: Confirm the excess is held as an advance and is not treated as an extra discount.
- Period close: Run the receivable and payable ageing reports and the trial balance on the same date, and confirm totals agree before the period is locked.
Keep the test scripts with the implementation records so the same cases can be rerun after upgrades or changes to payment terms.
Setting up payment terms in ERPNext step by step
This sequence takes payment terms from a written business policy to tested invoices and ageing reports, so that due dates, instalments and early payment discounts behave the same way across customers, suppliers and sales documents.
Confirm business terms and the documents that use them
Finance leads and the sales and purchasing owners agree the credit periods, deposits, instalment splits and discount offers in writing, then list which documents will carry them: quotations, sales orders, sales invoices, purchase orders and purchase invoices. Record which customers and suppliers are on each term and which items, if any, need their own term. This step is complete when the policy fits on one page and every term has an owner and a named use case. Ask your implementation partner or internal finance lead to confirm whether any term must change the posting of receivables or payables, not only the due dates, because that changes the design of later steps.
Create Payment Terms records
An accountant or ERP administrator creates one Payment Terms record for each distinct condition, such as a due date measured from invoice date, a fixed day of the month, or a share of the total due at a given point. Name each record so that a user can read the condition without opening it, for example by its credit period and deposit share. Check each record by opening it and confirming the description matches the business policy. The output is a short, tested list of terms that can be reused in templates rather than typed into individual invoices.
Build the Payment Terms Template with rows
The finance administrator builds a Payment Terms Template and adds one row per instalment or payment stage, linking each row to a Payment Terms record and setting its share of the invoice total. Confirm that the shares add up to the full amount before saving, because the template is what splits a single invoice into scheduled amounts. Where an early payment discount applies, configure it on the relevant row according to the discount fields in your version. The check is a dry run: create a test sales invoice with this template and confirm that the payment schedule shows the expected amounts and due dates.
Assign templates to customers, suppliers and items
The master data owner sets the default payment terms template on each customer and supplier record, and on any item that needs its own term, so that documents pick up the correct schedule without manual entry. Use the same template across a customer group where the policy is uniform, and document every exception. Verify by opening a sample customer and supplier and confirming the template appears, then creating a draft order to see it carried through. This closes the step when defaults are consistent with the approved list from step one.
Configure early payment discount rows
Finance confirms with the commercial team exactly when a discount applies, how the discount percentage is calculated, and whether it reduces the invoice total or only the amount received. Configure these rules on the template rows, then review how the discount interacts with the rest of the schedule and with any deposit. Test the discount on a sample invoice paid inside the window and on one paid after it, and confirm the receivable and any discount posting match the written rule. Ask the vendor or implementer to confirm which discount behaviors your installed version supports before you promise them to customers.
Test on sample invoices and orders
A tester runs a set of sample transactions through the full cycle: a quotation or sales order with the template, a sales invoice with a deposit and at least one instalment, a payment against each stage, and a purchase invoice from a supplier with terms. Record the due date and amount shown on each schedule line and compare them with a worked calculation prepared before the test. Include one case where a payment is partial and one where it is late. The step is complete when every test result matches the expected schedule and no unexpected journal entries appear. Keep the test file, because it becomes the regression set for later upgrades or template changes.
Check ageing reports against expected buckets
The finance lead runs the Accounts Receivable and Accounts Payable ageing reports on the test data and confirms that each open instalment falls into the bucket its due date implies. Check that partially paid stages, deposits and discounted amounts show the balance the finance team expects, and that a customer with several instalments does not appear as overdue for amounts that are not yet due. Agree on how the reports will be read by collections and procurement before go-live. The check is a signed-off reconciliation of the sample set to the expected bucket totals, which becomes the baseline for ongoing monitoring.
Controls over who can change payment terms
Payment terms drive due dates, instalment schedules and discount eligibility, so a change to a template can move receivable and payable ageing across many documents. The controls below cover who may create or edit templates, what happens once a document is submitted, how changes are traced, and how the people who set terms stay separate from the people who approve discounts.
Role permissions on Payment Terms Template
ERPNext controls access to each DocType through roles and permission rules, and Payment Terms Template is no exception. Decide which roles may create, read, edit and delete templates, and keep that list short. Confirm that users who only need to select a template on a sales or purchase document can do so without also being able to change the schedule it applies. Test the permission matrix with a non-administrator account before go-live.
Editing terms on submitted documents
Once a sales invoice, purchase invoice or order is submitted, its payment terms should be treated as fixed. Confirm how your ERPNext version handles amendments: a change is normally made by cancelling and amending the document, which creates a new version rather than overwriting the original. Agree who may cancel and amend, and whether a reason must be recorded before doing so, since this is where schedules are most often altered after the fact.
Audit trail of terms changes
Ask which changes ERPNext records automatically, including document version history and the activity timeline on each record, and which need a supporting process. Template edits, custom field changes and scripts that alter due dates may not be captured in the same way, so confirm this in your environment. Decide how long logs are kept and where they are exported, because auditors will ask who changed a schedule and when.
Separating setters from discount approvers
The person who creates a template with an early payment discount should not be the only person who approves its use on live invoices. Map the roles that set terms, the roles that approve discounts and the roles that post the resulting entries, then confirm no single user holds all three. Where ERPNext's built-in permissions cannot express this split, document it as a control to be checked during periodic access reviews.
Scripts that alter due dates
Server Scripts can change document fields on save or on submit, so a script that rewrites due dates or discount percentages bypasses the template-level controls. Inventory any scripts or custom apps that touch payment schedules. Note that starting from version 15 Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, so confirm whether they are switched on in your environment and who approves changes to them.
Periodic access review
Roles and user assignments drift as staff move between finance, sales and operations. Schedule a recurring review of who holds the roles that can edit templates, amend submitted documents and approve discounts. Export the current user and role list, compare it with the approved list, and record the result. Ask your implementation partner to include this review in the handover documentation so it continues after the project ends.
Questions finance teams ask before configuring payment terms
How long does a basic payment terms setup take in ERPNext?
The duration depends on how many payment term types you need, how many customers and suppliers carry non-standard terms, how many discount rules apply, and whether historical open invoices must be migrated with their schedules. A setup with a few standard credit periods and no instalments is a small configuration task. A setup with deposits, multi-stage instalments, early payment discounts for several customer groups and migrated open items takes longer because each rule needs testing against sample invoices. DeployOpen does not publish durations; a written scope with the counts above lets us give a timeline in the quote.
Can our finance team configure payment terms without an implementer?
Yes, for simple cases. Payment Terms Templates and Payment Terms are standard ERPNext masters, and a finance user with accounting permissions can create them, attach them to customers and suppliers, and check the resulting due dates on sample invoices. Outside help is more useful when you need rules that the standard templates do not express, when default terms must be enforced by customer group, or when you need a tested process for changing terms on open invoices. Confirm with your own administrator which roles can edit these masters before you start.
What inputs does an implementer need before configuring payment terms?
Gather three things before the first working session:
- Contract terms for your top customers and suppliers, including deposit percentages, instalment dates and early payment conditions.
- Sample invoices and credit notes that show how each term has been applied in practice, including any exceptions.
- Current receivable and payable ageing reports, so that the new schedules can be checked against balances you already report.
Record who approves exceptions to standard terms, because that decision determines which rules belong in masters and which belong in a manual process.
Do we need server scripts to handle custom payment logic?
Often not. Most term structures, due date offsets and discount conditions can be modelled with the standard Payment Terms Templates. If a rule depends on fields outside that model, such as a contract flag or a project status, a server script may be proposed. In Frappe Framework version 15 and later, server scripts are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them. Confirm the hosting model and your change control policy before designing any script-based rule, and ask whether a custom app is a better home for it.
How do payment terms affect receivable and payable ageing?
Ageing reports measure time from the due date of each schedule row, not only from the invoice date, so a deposit or instalment with its own due date appears in its own ageing bucket. This is why a schedule that is wrong at setup produces misleading ageing even when invoice totals are correct. Test a few invoices with mixed terms and compare the ageing output with a manual calculation before using the reports for collections or cash forecasting. A dunning process that depends on overdue status also inherits these dates.
What should a quote for payment terms work include?
A useful quote lists the scope in writing: the number of payment term templates, the customer and supplier groups they apply to, the early payment discount rules, whether open invoices will be migrated with their schedules, and the environment where the work will be tested. It should separate one-time configuration and testing from any recurring support, and state what the client provides, such as sample invoices and approvals. Ask for acceptance criteria based on specific test invoices. DeployOpen provides quotes from the written scope, and engagements are typically fixed-scope.
Which parts of the setup should we confirm with our own environment?
Confirm the ERPNext version you run, because Frappe's supported versions page lists which versions are still supported and when they end. Confirm whether your site can enable server scripts, whether your hosting provider allows the settings you need, and which user roles can change masters. Also confirm how your current system handles early payment discounts and deposits today, so that the ERPNext configuration reproduces the behaviour you actually rely on.
What to ask for in a scoped quote
A useful quote for payment terms work separates the design of the schedule model from the build, because most of the cost sits in deciding how deposits, instalments and credit periods should behave before any template is created. Ask the partner to itemize configuration design (which Payment Terms Templates your sales and purchasing flows need, how each one maps to invoice and order documents, and how early payment discounts are handled in the ledger), template build, test cases using sample sales and purchase documents, migration of open schedules from your current system, training for accounts receivable and payable staff, and written documentation of how due dates are calculated. DeployOpen does not publish prices. A quote follows from the written scope, so the more precisely the templates, documents and customer or supplier groups are listed, the more reliable the estimate will be.
Separate one-time work from recurring work. Design, build, testing, open schedule migration and initial training are one-time items. Any retainer for later changes, such as new templates after a commercial policy change, a new discount campaign or a version upgrade that touches payment entries, is recurring and should state what is included, how requests are logged, and how urgent changes are handled. Ask what drives each cost up or down: the number of distinct terms your business uses, whether open invoices with existing schedules must be carried over, how many companies or currencies share the schedules, and whether the discount logic must be reviewed by your auditors. Confirm which of these items the quote excludes, such as changes to your bank feeds or dunning letters, since those belong to other scopes.
How DeployOpen scopes and delivers payment term design
DeployOpen plans, implements, customizes, tests and documents ERPNext on infrastructure you control, including the payment terms, instalment schedules and early payment discounts that drive your receivable and payable ageing. Engagements start from a written scope that sets out which terms, schedules and discount rules are in and what evidence you receive at handover.
How we scope
- Inventory every sales and purchase pattern that uses deposits, instalments, credit periods or early payment discounts today.
- Agree which Payment Terms Templates will exist, who may select them, and which ones are retired from migrated data.
- Confirm with your finance team how due dates should fall on weekends, month ends and partial deliveries before any build begins.
- Record the scope, deliverables and timeline in writing, since most engagements are fixed-scope and agreed before work starts.
How we build
- Configure Payment Terms Templates and link them to customers, suppliers and the sales and purchase documents that use them.
- Test a set of sample invoices and purchase invoices through each schedule, checking due dates, discount windows and ageing buckets.
- Verify that early payment discounts post to the accounts your controller approved, including partial and late payments.
- Where your rules go beyond standard behaviour, scope any custom logic separately and confirm the Server Script settings with your administrators.
How we hand over
- Document each template, its terms, the calculation logic and the accounts affected, written for finance users and administrators.
- Provide test cases and results so your team can repeat the checks after upgrades or configuration changes.
- Walk through ageing reports, collections views and receivable reconciliation with the people who will run them each month.
- Deliver the configuration in a form your team can review, version and maintain under your own change control.
How we support
- Agree a support boundary covering fixes, questions and changes to payment terms once the system is live.
- Ask about ongoing support as a retainer, which covers upgrades and reviews of schedules as your commercial terms change.
- Plan a check of ageing and discount postings after each ERPNext minor release, since both supported major versions receive frequent updates.
- Request a written quote that separates one-time design and build work from any recurring support or testing.
