Sales operations · ERPNext · Pricing controls
Two Branches, Two Prices, One Customer: How We Approach Pricing Rules
A customer buys the same item from your Dubai and Abu Dhabi branches. One quotation shows AED 100. The other shows AED 105. Then the customer forwards an agreement promising AED 92.
Which price should the salesperson use? Can they offer another discount? And who approves the exception when the customer says, “Your other branch already agreed”?
Our starting point is a pricing policy that people can explain. ERPNext pricing rules should put that policy into practice, with clear boundaries around customer agreements and staff discretion.
A price difference can be legitimate. An unexplained difference is a problem.
Branches may have different delivery commitments, handling costs or local commercial strategies. A different selling price is not automatically a mistake. The difficulty begins when those differences conflict with a customer agreement.
Consider Gulfline Supplies, a fictional UAE trading business with two branches operating under the same legal company. Both sell the same maintenance kit, using the same unit of measure and currency. All figures below exclude VAT and freight.
| Pricing basis | Dubai branch | Abu Dhabi branch |
|---|---|---|
| Standard unit price | AED 100 | AED 105 |
| Negotiated unit price for an eligible customer ordering 10 or more kits | AED 92 | AED 92 |
| Total for 20 kits at standard prices | AED 2,000 | AED 2,100 |
| Total for 20 kits under the valid customer agreement | AED 1,840 | AED 1,840 |
The agreement explicitly covers both branches and has defined start and end dates. Under this example’s policy, it takes precedence over the branch’s standard price when its conditions are met. That is a business decision to configure and test, not a hierarchy we should assume the software will infer.
If the branches are separate legal companies, the agreement must also identify which seller is bound by it. A shared brand does not automatically make every customer contract applicable everywhere.
Write down what the negotiated rate actually covers
“This customer gets a special price” leaves too many unanswered questions. Before configuring the rule, we would establish:
- Customer identity: which customer account is entitled to the rate?
- Products and units: which items, pack sizes and units of measure are included?
- Commercial scope: which branches, companies, currencies and sales channels are covered?
- Eligibility: what quantities and validity dates apply?
- Exceptions: are further discounts, free goods or delivery concessions permitted?
A minimum quantity needs particular care. Does “10 or more” mean 10 units on one order, one delivery, or cumulative purchases during a month? Those are different policies with different implementation requirements.
Customer records matter too. Duplicate accounts created by different branches can make a valid agreement difficult to find or apply. The customer’s delivery address should not silently become the deciding factor unless the agreement makes it one.
Use ERPNext price lists and pricing rules for distinct jobs
Branch price lists
Establish the standard selling rates for the relevant branch or channel, with a defined method for selecting the correct list.
Customer pricing rules
Apply eligible rates or discounts according to the agreed customer, product, quantity and validity conditions.
Exception controls
Define who can change the result, what evidence they must provide and when a second person must approve.
ERPNext supports multiple price lists and pricing rules with eligibility conditions. The implementation still needs a reliable connection between the selling context and the intended price list. A warehouse is not automatically the same thing as a commercial branch.
Overlapping rules need deliberate testing. If a customer agreement, a quantity promotion and a branch offer all match, the result must follow the approved policy. Missing prices need a policy too: should the transaction stop for review, or use an explicitly authorised fallback?
The quiet risk: discounting an already negotiated price
Return to the order for 20 kits at AED 92 each. A salesperson adds a further 5% discount to close the sale. The unit price becomes AED 87.40 and the order falls from AED 1,840 to AED 1,748.
That is another AED 92 conceded on one order. Whether it is sensible depends on the agreement and the commercial circumstances. It should not happen simply because an editable discount field was available.
A clear rule for this example: the negotiated customer rate is final. Any further concession requires approval against that rate, with a recorded reason.
Reviewing only the percentage shown in one field is insufficient. A lower manual rate, an item discount and an additional document discount can all affect the final selling amount. Free goods or waived delivery charges can reduce the commercial return without appearing as the same kind of discount.
ERPNext documents both item-level and additional discounts. Our proposed control is to assess the combined concession against the applicable approved price. A discount percentage alone does not establish whether the order protects the intended margin.
Make approval controls follow the decision
Approval limits should reflect the business. A company might allow limited discretion on standard prices while requiring approval for every exception to a contract rate. The threshold should be agreed with the people responsible for pricing and profitability.
- Protect the inputs. Control who can maintain price lists, customer agreements and pricing rules.
- Protect the transaction. Review access to price-list selection, manual rates, discounts and any option that bypasses pricing rules.
- Show the approver the difference. Present the approved baseline, proposed net price, total concession and reason.
- Recheck material changes. Changing the customer, quantity, item or price after approval should trigger the relevant validation or renewed approval.
- Keep an accountable record. Preserve who requested the exception, who authorised it and what was approved.
ERPNext workflows and permissions can support these controls. Calculating a combined concession or enforcing a particular exception policy may require additional configuration or custom validation.
Controls also need to cover each route into the system. A salesperson’s form, a POS transaction and an integration should be tested separately. A restriction in one screen is not proof that every channel enforces the same policy.
Carry the agreed price through delivery and invoicing
A correctly approved quotation is only the beginning. Check what happens when it becomes a sales order, then a delivery and an invoice. ERPNext selling settings include controls for maintaining rates through the sales cycle. The selected behaviour should match the agreed policy.
What if the customer reduces the order from 20 kits to nine? What if the agreement expires before delivery? The contract should say whether eligibility is determined at quotation, order acceptance or another defined point. The system should enforce that decision.
Historical transactions should retain an understandable record of their agreed prices. Returns and credits should be reconciled to the original sale rather than casually using today’s branch price list.
Test the awkward cases before the first customer dispute
For an ERPNext implementation in Dubai or elsewhere in the UAE, a useful pricing demonstration uses actual business conditions. We would build a test set around cases such as these:
| Test transaction | What it must prove |
|---|---|
| Same eligible customer orders 20 kits at each branch | The agreed AED 92 rate applies consistently within scope. |
| Quantity changes from 10 kits to nine | The agreed eligibility policy is re-evaluated. |
| Agreement is expired or has not started | The applicable date policy prevents an unintended rate. |
| Salesperson adds 5% to a negotiated order | The additional concession requires the defined approval. |
| Customer or price changes after approval | Approval cannot remain valid for a materially different deal without review. |
| Selected branch has no item price | The system follows the agreed missing-price policy. |
| Order becomes an invoice through each supported channel | The authorised price and controls survive the complete journey. |
The practical goal is straightforward: a salesperson should be able to explain the price, a customer should recognise the agreement, and an approver should see exactly what exception they are accepting.
Frequently asked questions
Can ERPNext support different prices for different branches?
Yes. Multiple selling price lists can support branch pricing. The implementation must define how the correct price list is selected for each transaction and control unauthorised changes.
Can one customer receive the same negotiated rate across branches?
Yes, where the agreement covers those branches and its conditions can be represented in the configuration. Customer identity, company scope, quantities, currency and validity dates all need to be checked.
Should a customer rate override a branch promotion?
The commercial policy must decide. Some agreements guarantee a fixed price; others allow a better promotional offer. Overlapping rules should be configured and tested against that decision.
Can discounts require manager approval?
Approval processes can be configured using workflows, permissions and, where needed, custom validation. Test the combined financial effect of rate changes and discounts, including changes made after approval.
Will these controls guarantee profitability?
No. Consistent pricing reduces unauthorised concessions, but profitability also depends on purchasing costs, freight, fulfilment costs, returns and other expenses. Margin reviews need a clearly defined and reliable cost basis.
Bring us the price your team struggles to explain
A branch exception, a customer agreement or a discount that needs three phone calls is a useful place to start. At Craft Interactive, we can discuss how those decisions should work in your ERPNext implementation , from the first quotation to the final invoice.
