FMCG pricing scheme software needs to handle layered, time-bound discounts across customers, territories and item groups — and, just as importantly, track what each scheme actually cost. ERPNext manages the pricing and discount logic natively through Pricing Rules and Promotional Schemes. Where it stops is scheme cost tracking and distributor claim settlement, which most FMCG companies end up building as a thin custom layer on top.
That gap is the real story here. ERPNext isn’t a trade promotion management suite out of the box, and it shouldn’t be sold as one. Most FMCG companies running it don’t need one — they need the pricing engine wired correctly and a claims process attached to it.
What FMCG Pricing Scheme Software Actually Needs to Handle
FMCG pricing rarely means one price list. A single SKU might carry a base price, a distributor-tier discount, a territory-specific rate for a competitive market, a quantity slab (“10 cases at 5% off, 25 cases at 8% off”), and a time-bound scheme layered on top for a festival period — all active at once, with rules for which one wins if two apply to the same order.
Three things separate FMCG pricing from a simpler retail discount setup:
Layered, conditional discounts
Rules stack or override based on customer group, territory, item group, brand, and order quantity or value — not a single flat percentage.
Time-bound schemes with hard start and end dates
A festival scheme that runs three days too long, or a scheme that fails to switch off automatically, either costs margin or creates a billing dispute with a distributor.
Scheme cost visibility separate from the invoice
A trade discount reduces revenue on the books, but the business also needs to know what a scheme cost as a line item — by SKU, by region, by scheme — to judge whether it drove enough incremental volume to justify itself.
How ERPNext Handles Pricing and Schemes Natively
ERPNext’s core mechanism for this is the Pricing Rule doctype, paired with Promotional Scheme as a way to manage several related Pricing Rules as one unit rather than creating them one at a time.
A Pricing Rule can apply based on Customer, Customer Group, Territory, Item, Item Group, or Brand, and can be scoped further by minimum and maximum quantity or order value. It supports two distinct discount mechanics that cover most FMCG scenarios:
Price Discount Scheme
a percentage or flat-amount discount off the price list rate. This is the standard "10% off for Distributor Tier A in Western Region" rule.
Product Discount Scheme
a free-item or "buy X get Y" mechanic, which is closer to how FMCG trade schemes are actually structured on the ground than a straight percentage cut. "Buy 20 cases, get 2 free" is a common scheme format, and ERPNext models it directly rather than forcing it into a discount-percentage approximation.
Each rule carries its own validity window (from-date and to-date), so a scheme genuinely turns off on the date it’s supposed to, without someone having to remember to deactivate it manually. When multiple rules could apply to the same order, ERPNext resolves conflicts through a priority field — set explicitly per rule — plus a setting for whether multiple pricing rules are allowed to apply simultaneously or whether only the highest-priority match wins. Getting this priority order right during setup is what prevents a distributor being accidentally given two overlapping discounts, or a scheme silently failing to apply because a more specific rule was never given higher priority than the general one.
For consumer-facing or e-commerce scenarios, ERPNext also supports coupon codes tied to a Pricing Rule, with usage limits per code — useful for a distributor portal or D2C channel running alongside primary distribution, though this matters less for most B2B FMCG trade scheme setups than for retail.
None of this requires customization. A pricing structure with a dozen active schemes across several territories and customer groups is well within what Pricing Rules and Promotional Schemes handle out of the box, provided the underlying Customer Group, Territory and Item Group structure actually reflects how the business segments its market — usually the part that takes longer to get right than the rules themselves.
Where Native Pricing Rules Stop Being Enough
Pricing Rules calculate the discount correctly at the point of sale. What they don’t do is track what a scheme cost the business as a distinct number, or manage the claim-and-settlement process that most FMCG trade schemes run on.
Two gaps show up repeatedly:
There’s also a compliance angle specific to India that’s easy to miss: under GST, a post-sale discount only reduces the taxable value if it was agreed to before or at the time of supply and can be linked back to specific invoices. A scheme negotiated informally after the fact, with no documented pre-agreement, generally can’t be passed through as a GST-compliant discount — it has to be settled as a commercial credit note outside the tax value instead. Getting pricing schemes set up as proper Pricing Rules with documented validity dates isn’t just cleaner operationally; it’s what keeps the discount defensible at the time of an audit. This isn’t tax advice specific to your business — confirm treatment with your GST advisor for your scheme structure.
None of this makes ERPNext the wrong system for FMCG pricing — it means the pricing engine and the claims/scheme-cost layer are two different problems. The honest tradeoff is that you get a genuinely solid pricing engine natively, and the claims layer is something you build once, deliberately, rather than getting for free.
Given how directly scheme cost visibility affects your own margin data — and how it should connect to distributor-level sales and stock visibility across your network rather than living in a separate spreadsheet — this is usually worth scoping properly rather than patching around it.
Getting Scheme Management Right: What to Set Up First
Get the segmentation right before the rules
Customer Group, Territory, and Item Group need to genuinely mirror how the business prices, not a generic default hierarchy.
Set explicit priority on every rule from day one,
rather than relying on creation order or defaults — the single most common cause of "why did this order get the wrong discount" later.
Decide upfront whether schemes are off-invoice or claim-based,
since that determines whether Pricing Rules alone are sufficient or a custom claims workflow needs scoping from the start.
Build the scheme cost report before you need it,
not after finance asks why quarterly numbers don't reconcile.
