ERPNext pricing rules and promotional schemes

When ERPNext pricing rules replace manual discounts

A sales or finance lead who keeps overriding prices by hand on quotations and invoices has a configuration problem, not a discipline problem. Every manual change is a one-off decision that nobody else can see, repeat or audit. ERPNext's pricing rule documentation recommends a clear split: use Pricing Rules for exceptions that repeat, a direct transaction discount for a one-time adjustment, and a Promotional Scheme for a tiered campaign with several slabs. Before the build starts, sort the current manual overrides into those three groups. Anything that appears on more than one document in a quarter is a candidate for a Pricing Rule.

A Pricing Rule is the right tool when the same condition keeps triggering the same price change, such as a negotiated margin for a customer group, a discount on a product family, or a free item when a set quantity is ordered. Scope it with the conditions it actually needs (customer, customer group, item, item group, territory, date range, minimum quantity) and set a validity window so it expires without anyone remembering to remove it. A direct discount on the transaction is better for a single deal that will not recur, because it leaves no standing rule in the system. Ask the business owner to confirm which overrides are truly one-off before anything is built. A Promotional Scheme fits a campaign where the discount depends on how much the customer buys across several slabs. Confirm the slab structure and the end date with the commercial team first, because changing a live campaign mid-period creates disputes that are hard to unwind.

Choosing between a Pricing Rule, a transaction discount and a Promotional Scheme

A one-time adjustment is a concession granted on a single transaction, such as a goodwill credit after a delayed delivery or a negotiated discount on one large quotation that will not recur. ERPNext's pricing rule documentation points to a direct transaction discount for this case rather than a standing rule. The discount is entered on the sales document itself, so it stays attached to the quotation, sales order or invoice it affects.

Where it is set up: On the Quotation, Sales Order or Sales Invoice, in the discount fields of that document.
Who should own it: The account owner who negotiated the concession, with approval from a role that the sales approval policy names.
Audit trail it leaves: The discount sits on the submitted document with its user and timestamp in the version history, so reviewers can see it per transaction.
Risk to watch: Repeated one-off discounts entered by hand become inconsistent pricing that no one can report on.
Recurring cost: Typically none beyond the approval step, since no configuration is kept.

Confirm with your finance team which roles may enter transaction-level discounts and whether a discount threshold should trigger approval.

How ERPNext selects and applies a matching pricing rule

When a sales or purchase document is saved, ERPNext checks each active Pricing Rule against the transaction and applies the rule whose conditions fit the line. The conditions you set on a rule act as filters. Item code, item group and brand narrow the match at the product level. Customer, customer group and territory narrow it at the buyer level. Currency and the validity dates control whether the rule is live for that document at all. A rule with an empty field usually matches any value in that field, so a rule with no customer set can apply to every customer. Once a rule matches, it sets the discount percentage, the rate, or the margin on that line, and it can also trigger a free item. Confirm in your version how a blank field is treated, because this is the most common source of unexpected discounts.

The harder question is what happens when more than one rule matches the same line. ERPNext uses priority and related settings on the rule to decide which one wins, and some rule combinations can be set to apply together rather than exclusively. Check the exact matching order, the priority behavior and whether stacked rules are allowed against the ERPNext Pricing Rule documentation and in your release. Then test it with real customer, item and date combinations in a staging site before go-live. Record the expected result for each test case, because the rule set will change over time and a later rule can silently override an earlier one.

Pricing Rule options and when each fits

This table compares the Pricing Rule settings a buyer configures, from what the rule applies to through discount type, priority, validity and minimum conditions. Read each row for when the setting fits and what else it can touch, because most pricing conflicts come from broad scopes and overlapping dates rather than from the discount itself.

Setting	When it fits	What it can accidentally affect
Applies on item	One product with a stable, specific price exception	Only that item, but renamed or duplicated item codes will not pick up the rule
Applies on item group	A product family that should share one discount or margin	Every new item added to the group later, including items not yet priced
Applies on brand	Vendor-led promotions tied to a manufacturer or label	Items recorded under that brand in any item group, which may cross your category plans
Price discount	Percentage off the list price for a repeatable customer or channel	Margin reports, since the reduced price flows into standard selling and gross profit
Rate	A fixed negotiated price for a defined item and customer segment	Stale prices if list prices change, because the fixed rate does not follow the price list
Margin	Targets a minimum or set margin on items sold through a channel	Cost data quality, since the calculation depends on the valuation rate in stock
Free item	Buy-one-get-one or bundled giveaways on a qualifying purchase	Inventory counts and cost of goods, because free units still leave stock
Priority	Resolving overlapping rules when more than one could apply	Rules you did not intend to override, if priorities are set without a written order
Validity dates	Seasonal campaigns or contract periods with a known end	Documents dated outside the window, and open quotations that carry an expired price
Minimum quantity or amount	Volume incentives that reward larger orders	Small orders that expected the discount, and disputes if the threshold is changed mid-campaign

How rule conflicts are resolved and where they go wrong

Pricing rules, promotional schemes and manual discounts can all touch the same sales line in ERPNext. The cards below cover the four conflict cases that most often produce wrong prices or free goods at go-live, and the check to run for each before users start quoting.

Two rules match the same item

ERPNext evaluates Pricing Rules against each line using the conditions you set, such as item, item group, customer, customer group, territory, company and quantity. When two or more active rules match the same line, the one with the higher priority is applied and the others are ignored, so a broad rule can quietly override a narrow one if its priority is set higher. Before go-live, test each product line with a matching customer and quantity and confirm which rule name appears on the document. Confirm the applied rule on a test order for every product family.

Priority ties between rules

When two rules share the same priority, the result depends on how the matching rules are sorted, and that sort is not something a sales team should rely on. The safe pattern is a unique priority for every rule that can match the same item, with the narrowest scope given the highest priority. Ask your implementer to export the active rule list and check each overlapping pair by hand. Review the list again whenever a new campaign is added, because ties usually appear in the second season, not the first.

Rule combined with a manual discount

A Pricing Rule can set a discount, and a user can also type a discount directly on the sales order or invoice. The two do not simply add up in a way users expect, and the manual figure may replace or sit on top of the rule depending on the fields filled in. Decide policy first: either block manual discounts for roles that should not override rules, or require an approval step for them. Test one line with a rule discount and one with a manual discount, then compare the totals on the invoice with the figures in the rule definition.

Free item rule stacking with a discount

A free item rule adds goods to the document, and a percentage discount on the same basket can also apply to the paid items. Without a limit, a customer can receive the free item and the discount together, which changes margin on the promotion. Check whether the free item line is excluded from the discount, whether the free quantity is capped, and whether the free item carries a zero rate that still moves stock. Run the promotion through the warehouse and the sales ledger, because the free item must be reported and costed correctly.

Setting up pricing rules and a promotional scheme

This sequence moves a pricing decision from a written commercial policy into tested ERPNext configuration, so that repeatable discounts, margins and tiered campaigns apply predictably to quotations, sales orders and invoices. Each step ends with a check that a named owner can sign off before the next step begins.

Define the commercial policy and approval owner
Before anything is configured, the commercial team and finance agree in writing which discounts, margins and free items are allowed, for which customer groups, items, territories and periods, and the maximum value of each. Name one approval owner who can accept or reject a rule change and one person who maintains the configuration. Separate one-time negotiated adjustments, which belong on the transaction, from repeatable rules, which belong in Pricing Rules. The step is done when the policy is a short signed document that lists every rule to be built, its owner and its expiry or review condition.
Build a test price list and company
Create a separate test company or a sandbox site, with a test price list, test customer groups, test items and a test warehouse, so that rule testing cannot change live prices or stock. Load a small set of items with standard selling rates that match the production price list. The step is done when a test quotation on a standard item shows the expected base rate from the test price list and the price list is linked to the correct customer group.
Create Pricing Rules with explicit priority
Build each repeatable rule as a Pricing Rule with its applicability conditions (item, item group, brand, customer, customer group, territory, company, period and minimum quantity), its action (discount percentage, discount amount, or a rate for the price list), and an explicit Priority value. Use the Priority field to decide which rule wins when more than one matches, and record that order in the policy document. Where a rule must not be combined with others, set the rule's exclusion setting accordingly and confirm that setting in the version of ERPNext you run. The step is done when a rule-by-rule table lists conditions, action, priority and expected outcome for each test case.
Create a Promotional Scheme for tiered campaigns
Use a Promotional Scheme only where a campaign has several slabs, such as a discount that rises with purchased quantity or value. Define the scheme, then add each slab as a Pricing Rule under it, with the threshold and benefit for that slab. Set the scheme validity dates and the applicability conditions once, so slabs do not drift apart. If a campaign has only one threshold, a single Pricing Rule is usually simpler to audit. The step is done when a test order at each slab boundary (just below and at the threshold) produces the benefit the policy states.
Test quotations, sales orders and invoices
Run the test cases from the rule table through the full document chain: a quotation, then a sales order, then a delivery note and a sales invoice. Check that the rate, discount and any free item appear with the same values on each document, and that a change to quantity or customer triggers the expected rule. Also test the cases that should not apply, including expired rules, excluded customer groups and quantities below the threshold. Record the actual result beside each expected result. The step is done when every test case matches its expected result, or each mismatch has a documented fix and a retest.
Review the rules with finance before go-live
Walk finance through the rule table, the test results and the sales invoice output, focusing on the revenue and tax effects of free items, discounts on invoices and the accounts used for discounts. Confirm who can create or change Pricing Rules in production, and how changes are approved and dated. Schedule a review of expired or unused rules at a date the policy owner sets. The step is done when finance and the approval owner have signed the review, production permissions match the policy, and the approved rule set is copied into the live company.

Controls that stop unauthorized discounting

Pricing Rules and Promotional Schemes change what every quotation and invoice charges, so who can write them matters as much as how they are built. The cards below cover the access, separation of duties, change history and expiry checks that keep discount logic under the control of the people accountable for margin.

Limit who can create pricing rules

Pricing Rule and Promotional Scheme edits should sit with a small group, not with every user who can create a quotation. Map the DocTypes to roles in your ERPNext roles and permissions setup, then remove create and write rights from sales roles that only need to apply rules. Confirm the exact permission levels in your own environment before you grant anything, because the access you need depends on how your sales and pricing teams are organized.

Separate quoting from campaign approval

The sales user who quotes a customer should not also be the person who sets a campaign's slabs, free items or validity dates. Keep quoting access to applying existing rules and reserve Promotional Scheme approval for a pricing owner, such as a sales operations or finance lead. Write this split down as a rule of your process, then check that the permissions reflect it, since a user who can both quote and edit a rule can give themselves a discount.

Log every rule change

Before go-live, confirm that version tracking is enabled for Pricing Rule and Promotional Scheme so each edit to a rate, threshold or customer target is recorded with its author and time. Ask your partner or vendor to show the version history for a test rule. Without this record, a discount that was approved last quarter may be impossible to explain during a margin review or audit.

Review rule expiry dates

A Pricing Rule with a validity end date that is missed, or one with no end date at all, can keep discounting long after a campaign has finished. Set a recurring review of active rules, filtered by validity dates and by the customers or items they target, and assign an owner to each one. Ask your team to confirm how expired rules behave in quotations and invoices in the version you run.

Watch for overlapping rules

When more than one rule matches the same item and customer, the outcome depends on priority and conflict settings, so a new campaign can silently override an existing margin rule. Review overlap whenever a rule is added, and test representative quotations before publishing. Document the priority order your organization expects so approvers can check results against it.

Test changes before they go live

Changes to discount logic should go through a non-production site first, where a sample of quotations and sales invoices can be checked against expected prices. Keep a short list of test cases covering standard, promotional and excluded customers. This step catches permission mistakes and rule conflicts before real customers see the new terms.

Questions buyers ask before configuring ERPNext pricing

What drives the effort of configuring ERPNext pricing rules?

The main drivers are how many price lists you run, how many customer segments need different terms, how complex the campaigns are, and how clean your current item and customer data is. Each price list, segment and exception adds rules that must be designed, entered, tested and explained to sales staff. Campaigns with several slabs, free items and stacked eligibility conditions take the longest to specify, because each condition interacts with the others. Messy item codes, duplicate customers or inconsistent unit-of-measure data often cost more time than the rules themselves. Ask any partner to break the quote down by these drivers so you can see which ones you can reduce before work starts.

Can our internal team configure ERPNext pricing rules alone?

Often yes, if one person understands your pricing policy and has time to learn how Pricing Rules are matched, prioritized and applied to transactions. The Pricing Rule documentation covers the core options, and ERPNext's own guidance points to a Pricing Rule for repeatable exceptions, a direct transaction discount for one-time adjustments, and a Promotional Scheme for tiered campaigns. The risk is not the first rule but the interactions between rules, because priority, stacking and conflict behavior are easy to misread. If no one on your team can explain how a given quote price was calculated, bring in outside review before the rules go live.

What does a partner need from us to scope pricing work?

A partner needs your current price lists with their effective dates, your approved discount policy in writing, and a set of sample quotes or invoices that show how prices are applied today. It also helps to have a list of active campaigns, the customer groups and territories they target, and the approval limits for manual discounts. Sample documents matter most, because they reveal the exceptions that policy documents leave out. Share any spreadsheets your sales team uses to calculate prices, and name the person who can approve a rule change so that scope questions get answered quickly.

How do testing and sign-off work for pricing rules?

Testing works best when it uses your own sample quotes and orders as test cases. For each case, the expected price, discount and free items are written down before testing, then the ERPNext result is compared against them, including edge cases such as quantity thresholds at the boundary, expired rules and customers in more than one group. Finance and sales should sign off on the same test set, since they judge different outcomes. Keep the test cases and their results as a record of approved behavior. Agree the sign-off criteria and who gives approval in the written scope, not after the build.

Who maintains pricing rules after go-live?

Your team owns the commercial decisions, such as which campaigns run, which discounts are approved and when a price list changes. Someone must also maintain the rules themselves: expiring old campaigns, reviewing rule priority when new ones are added and checking that reports still reflect the margins you expect. These tasks recur for as long as you sell through ERPNext, and their frequency depends on how often your pricing changes. A partner can support this work under an ongoing retainer, which is one option among several. Confirm with any provider which changes are included and how urgent requests are handled.

Does a Promotional Scheme replace Pricing Rules?

No. ERPNext's documentation recommends Pricing Rules for repeatable exceptions, and a Promotional Scheme for tiered campaigns with several slabs. A scheme is useful when a campaign has multiple levels, such as a different discount at each quantity or spend band, but it still depends on the same underlying pricing logic. Mixing a scheme and standalone rules on the same items raises the chance of unexpected results, so decide early which mechanism governs each product. Test every campaign against the rules that already apply to the same customers.

What should we check if a customer gets the wrong price?

Start with the transaction itself: look at which Pricing Rule or scheme was applied, the price list, the customer group and the quantity or date that triggered it. Then check the priority values and whether rules were set to apply together or whether one overrides another. Confirm that the rule's validity dates and any applicability conditions match what was intended. Finally, check whether a manual discount was entered on the document. Record the cause, correct the rule, and add the case to your test set so the same mistake is caught before the next change.

What to ask for in a pricing rules quote

A pricing rules engagement should be quoted from a written scope that lists four components: discovery of the discount policy, rule design, testing across document types, and training and handover. Discovery covers who approves discounts, which customer groups, price lists, items and territories are in play, how margins are floored, and which exceptions are one-time. Rule design turns that policy into Pricing Rules and, where campaigns use several slabs, a Promotional Scheme. Testing should cover quotations, sales orders, invoices, point-of-sale if used, and returns, because the same rule can behave differently across them. Ask the supplier to name each component, the deliverable it produces, and who on your side must sign off.

Most of the cost is one-time: policy discovery, the first rule set, and the test cases that prove precedence and conflict behavior. Costs rise with the number of price lists, customer groups, item families, currencies and companies, and with how many discount rules overlap. Recurring work appears when campaigns change. Each new seasonal promotion, slab change or margin floor adjustment needs rule edits, retesting and a short briefing for sales staff, so ask whether a quote includes a fixed number of changes, a retainer, or a per-change rate. Also confirm whether the scope covers the first campaign cycle after go-live.

Ask for the scope in writing before work starts, including explicit exclusions such as custom discount logic in server scripts, which are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and which Frappe Cloud public shared benches do not allow. Confirm who owns the test data, who can approve rule changes after handover, and what documentation and training sessions you receive. Check the supported ERPNext version in the Frappe supported versions page so that the rule design matches a version that will still receive updates during your planning horizon.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, customizes and supports self-hosted open-source platforms inside your own infrastructure. For ERPNext pricing rules and promotional schemes, we start from your written price structure and deliver configuration that your pricing team can review, test and maintain.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope lists each price list, pricing rule, promotional scheme and margin rule to be configured.
We document which rule conflicts your business accepts and which need a priority decision from your team.

How we build

We configure Pricing Rules for repeatable exceptions and test each rule against sample sales orders and invoices.
We set up Promotional Schemes for tiered campaigns, checking each slab and free item against agreed values.
We test priority and conflict behavior with documented scenarios, covering overlapping rules and expired dates.

How we hand over

You receive a configuration record listing every rule, its conditions, validity dates and owner.
We run a walkthrough with the users who create quotations and sales invoices, covering who can change rules.
We document the test cases used, so your team can repeat them after each future change to pricing.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
A retainer can cover reviews of new campaigns before they are activated in a live environment.
Ask any partner, including us, to confirm how pricing configuration is handled across ERPNext version upgrades.