How an ERPNext loyalty program earns and redeems points
A retailer or distributor needs a loyalty program when repeat buyers should earn something measurable from their purchases and spend it on later orders, and when the business wants that reward to sit in the same ledger as its sales. An ERPNext Loyalty Program does this. It awards points from submitted sales and lets eligible customers redeem those points on later Sales Invoices. A program can run on a single tier or on several tiers, where a customer's level depends on cumulative eligible spend. The points logic lives in the program setup, so the sales team does not need to track rewards in a spreadsheet or a separate tool.
The choice between a loyalty program, a Pricing Rule and a Promotional Scheme is mostly about who the reward is for and how long it should last. A Pricing Rule applies a discount or free item whenever its conditions match, for every buyer who qualifies, and it does not build a balance the customer can draw down later. A loyalty program fits when the reward should depend on a customer's history, grow with spend, or be spent over time. A Promotional Scheme suits a time-limited campaign with tiered offers. If the reward is a fixed price for everyone on a given product, a Pricing Rule is usually the simpler tool. Confirm the exact earning, tier and redemption behavior against the ERPNext version you run, because loyalty behavior has changed across releases and the ERPNext Loyalty Program documentation is the reference to check against your own test data.
Loyalty program options and when each fits
This table compares the main loyalty program choices in ERPNext: single or multi-tier structure, how points are collected, where points are redeemed and how expiry is handled. Read each row against your own customer base and sales channels, then confirm the exact field behavior in your ERPNext version before you configure anything. The main takeaway is that tier design, redemption channel and expiry all change what gets posted to the loyalty expense account and what customers see.
| Option | When it fits | What it changes for accounting and customer records |
|---|---|---|
| Single-tier program | One reward structure applies to all eligible customers and the business wants a simple earning rate. | One set of collection rules drives every point award. Customer loyalty point balances are the only tier-related record to reconcile. |
| Multi-tier program | Customers should move to better rewards as cumulative eligible spend grows, for example a standard and a premium level (illustrative). | Tier thresholds are measured on cumulative eligible spend, so customer tier status changes over time. Confirm how tier upgrades and downgrades are recorded before go-live. |
| Collection rule on eligible spend | Only certain items, customer groups or amounts should earn points. | Ineligible sales still post normally but earn no points. Document the eligibility logic so finance can explain the points liability. |
| Redemption on Sales Invoice | Sales are invoiced in the back office and customers redeem points against later invoices. | Redeemed value reduces the invoice amount and is posted to the loyalty expense account. Confirm the account mapping with your accountant. |
| Redemption at POS | Customers pay at the counter and redeem points during the sale. | The redemption flows through the POS invoice, so the same loyalty expense account applies. Test returns and partial redemptions on the POS path separately. |
| Expiry settings | Points should lapse after a set period to limit the outstanding liability. | Expired points leave customer balances and change the reported liability. Confirm the expiry parameters and how expired points are shown on customer records in your version. |
| Returns after redemption | Customers return goods that were bought with points or that earned points. | Returns can reverse earned points or restore redeemed value. Ask the implementation team to test both directions before the program opens. |
Setting up a loyalty program in ERPNext step by step
This sequence takes a team from an empty ERPNext site to a loyalty program that earns points from submitted sales, redeems them on invoices and POS, and posts the cost to the right accounts. Each step closes with a check so problems surface on a non-production site before customers see them.
Confirm the accounting and POS prerequisites
Before creating anything, confirm the company, chart of accounts, cost centers, item groups and the POS profile you plan to use are set up and that the people who will configure loyalty hold the roles needed to edit them. Record which customers and items are eligible, since loyalty points are awarded from submitted sales and the eligibility rules depend on your item and customer master data. You know this step is done when a test Sales Invoice can be submitted cleanly in the staging site and the item and customer groups you intend to use are visible in the lists.
Create the loyalty program record
In the Loyalty Program DocType, create one program for each distinct scheme you run, naming it clearly and selecting the company it belongs to. Decide whether the program is single-tier or multi-tier at this point, because tier thresholds are attached to the program and changing the structure later affects how existing points are read. Confirm the record saves and that the program appears in the list with the expected company and status.
Define collection and tier rules
Set the collection rules that convert eligible spend into points, including the spend amount needed to earn one point and any tier thresholds based on cumulative eligible spend. Add tier rows only if you run a multi-tier scheme, and check that each tier threshold and its benefit are entered in ascending order. Review a worked example with finance (labeled illustrative, for instance a customer who spends a set amount across two invoices) and confirm the expected point balance matches the rule you configured.
Set redemption rules and the expense account
Define how points convert to a monetary value on redemption, then assign the loyalty expense account that receives the cost of points given away, along with the cost center that will carry it. Confirm with your accountant which account and cost center the redemption cost should hit, because the posting appears in the ledger and affects period results. You know this step is done when a test redemption calculation shows the expected discount amount and the expense account resolves to the account your finance team approved.
Link customers to the loyalty program
Enroll eligible customers by setting the loyalty program on each Customer record, or by using your agreed enrollment process if you have many customers. Check that the customer's loyalty program field, customer group and company match the program, because a mismatch stops points from being awarded or redeemed. You know this step is done when a sample customer shows the correct program and an empty or opening point balance.
Test earning points on a staging site
On a non-production site, create and submit a Sales Invoice for the test customer that includes eligible items, then confirm the loyalty points ledger shows the expected points for that submitted sale. Repeat with a cancelled or draft invoice to confirm no points are awarded, and with an ineligible item to confirm it is excluded. You know this step is done when earning matches your worked example for every case, including the cancelled invoice.
Test redemption on invoices and POS
Using the test customer's accumulated points, redeem some of them on a later Sales Invoice and then on a POS invoice, checking the discount, the tax treatment and the posted journal entries against the expense account. Test a return or credit note on a redeemed invoice and confirm how points are reversed or retained according to your policy, and check the expiry behavior if you configured an expiry. You know this step is done when both channels show consistent balances and the ledger postings land in the expected account and cost center.
What happens to points across submit, return and redemption
Points in an ERPNext Loyalty Program are earned from submitted sales, not from drafts. A Sales Invoice that is still saved but not submitted should leave the customer's balance unchanged, and that is the first case to test. Redemption then works in the other direction: when an eligible customer applies points on a later Sales Invoice, the redeemed value reduces the amount the customer pays and the points are deducted from the balance. Build a test customer, submit an invoice that earns points, redeem on a second invoice, and check the Loyalty Point Entry records, the invoice totals and the general ledger postings side by side. Confirm which DocTypes ERPNext creates for each step in your version, since the audit trail depends on them.
Returns and cancellations need their own test cases because they reverse money and points at different times. Test a return against an invoice that earned points, a return against an invoice that redeemed points, and a cancelled invoice that both earned and redeemed. For each, record whether points are reversed, whether the redeemed value is restored, and which account receives the adjustment. Ask your implementation owner to write these expected results down before go-live. Also confirm with the ERPNext loyalty documentation for your version how partial returns are handled, because a partial return may not map cleanly to a whole number of points.
Plan for the cases that fall outside the happy path. A customer may redeem points on an invoice that is later returned after the points have already expired, or may hold points across a change to the tier thresholds. Decide, with finance, who approves manual point adjustments and which role can cancel an invoice that affects a loyalty balance. Document these rules in the same place as your configuration, and reconcile the loyalty expense account against the total outstanding points at each period close. Treat the first reconciliation as a control test, not as a formality.
Access, audit and data risks in loyalty programs
A loyalty program touches customer records, money owed to customers and cashier workflows at the same time. The controls below connect who can change rules, who can spend points at the counter, how manual changes are traced and how personal data is kept limited. Confirm each one in your own ERPNext roles and permissions before go-live.
Who can change program rules
Loyalty Program records define earning rates, collection rules, tiers and the expense account that receives redemption cost. Changing any of these alters the value of every point already issued, so limit write access to a small finance or sales operations group. Check which roles can create, edit and submit Loyalty Program documents, and confirm that day-to-day sales users only have read access. Test the setup on a non-production site first.
Who can adjust point balances
Point balances are the liability your program carries, so any manual change to a customer's balance should be a deliberate, reviewed act rather than a side effect of editing a customer record. Decide which roles may create loyalty point entries by hand, and restrict those roles from also approving them. Ask your ERPNext partner to confirm which DocType holds balances in your version and which permissions apply to it.
Role permissions for POS redemption
Redemption at the point of sale reduces a customer's balance and changes the invoice total, so the cashier role needs enough access to redeem but not enough to alter the program or reverse redemptions. Review the POS profile, the roles assigned to cashiers and any discount permissions that could bypass the redemption amount. Test a cashier account end to end, including a return on a redeemed invoice.
Audit trail for manual adjustments
Every manual correction, goodwill credit or reversal should record who made it, when, why and against which invoice or customer. Use ERPNext version tracking on the relevant documents where it is enabled, and export a periodic report of manual entries for review by someone outside the sales team. Confirm with your partner how long these records are retained and where backups of the database are held.
Personal data on loyalty customers
Loyalty members are linked to customer contacts, contact details, purchase history and often birthdays or preferences, which makes them personal data under most privacy regimes. Limit which fields are visible to cashiers, decide how long lapsed members are kept, and document the lawful basis for marketing messages sent to them. Check whether role-based field restrictions and data export or deletion procedures meet your own policy before enrolling customers at scale.
Segregation between issuing and reconciling
The person who issues points, redeems them and books the loyalty expense should not be the only person who reconciles the liability at period end. Assign reconciliation of outstanding points and the loyalty expense account to finance, and schedule the check before month-end close. Ask for a written list of who holds each role across sales, POS and accounting, and review it whenever staff change.
Questions buyers ask before setting up loyalty points
What drives the cost of setting up loyalty points in ERPNext?
The biggest drivers are the number of tiers, whether points must work at the POS as well as on Sales Invoices, how much customer and sales history needs cleaning, and how much testing returns and expiry require. A single-tier program on invoices is the smallest scope. Each added tier adds rules for cumulative eligible spend, upgrade and downgrade behavior, and reports to check. POS redemption adds device setup and cashier testing. Costs are split between your own staff, who supply the rules and sign off, and any implementation partner, who is paid for the configuration, testing and handover under a written scope. Ask for a quote that lists each of these items separately and marks which parts are one-time and which recur, such as ongoing support.
How long does loyalty program configuration take in ERPNext?
Duration depends on scope rather than on a fixed number. A single-tier program that earns points on submitted Sales Invoices and redeems them on later invoices is the shortest path. Multi-tier programs, POS redemption, data cleanup and returns testing each extend the schedule. The time that most often runs over is not the configuration itself but the business decisions: agreeing point values, tier thresholds and expiry rules, and getting finance to approve the loyalty expense account. Ask any partner for a timeline tied to the written scope, with the decisions and sign-offs they expect from your team listed as dependencies.
What does our business need to provide before setup starts?
Before configuration, your business should provide:
- Written loyalty rules: how points are earned, the conversion value of a point, minimum spend, and any exclusions such as discounted or returned items.
- Tier definitions: cumulative eligible spend thresholds, benefits per tier, and what happens when a customer moves between tiers.
- Expiry and return policy: how long points last and how points are reversed when a sale is returned.
- Customer data: clean customer records and a decision on which existing customers join the program at launch.
- Finance sign-off: an income or expense account for the loyalty cost, approved by the person who owns the ledger.
Without these decisions, the build will stop for rework, so settle them before the scope is fixed.
Which account should we use for the loyalty expense?
The loyalty expense account records the cost of points redeemed, so it must be chosen by your finance team, not by the implementer. Ask your controller which account and cost center fit your chart of accounts and how the expense should be reported against revenue. Confirm the account type, because a wrong choice affects period close and management reporting. Test one earn, one redemption and one return end to end in a non-production site, and have finance review the resulting journal entries before go-live. Check the exact field names and the posting behavior against the ERPNext loyalty program documentation for your version.
Can our team set up a simple single-tier loyalty program alone?
A team with ERPNext administration experience can usually configure a single-tier program that earns points on Sales Invoices and redeems them on later invoices, using the official documentation. The work requires a test site, a clear rules document and careful checks of returns and expiry. Tasks that often need outside help include POS redemption, multi-tier logic, custom reports, and integration with other systems. Be honest about your team's capacity to test and to support the program after launch. If you bring in a partner, ask for a written scope that separates configuration from testing and handover.
What should we test before launching points redemption at the POS?
Test the full path: earning points from a submitted sale, redeeming points on a Sales Invoice, redeeming at the POS, and reversing points when a return is processed. Also test expiry, so you know when points lapse and that they are not reused. Check that tier thresholds are computed from eligible spend only, and that the expense account receives the expected entries. Run these tests on a non-production site with realistic but anonymized data, and repeat them after any change to rules or POS settings. Confirm the POS behavior against the ERPNext loyalty points redemption in POS documentation for your version.
What goes wrong most often with loyalty programs in ERPNext?
The most common failures are unclear rules, which lead to disputed points; returns that do not reverse points; expiry that is set but never tested; and tier thresholds that count ineligible items. Duplicate or messy customer records also split a customer's points across accounts. On the finance side, an unapproved or wrongly typed expense account distorts reporting. Operationally, staff may not know how to redeem points at the POS. Prevent these by writing the rules before build, testing returns and expiry explicitly, cleaning customer data first, and training cashiers and support staff before launch.
Limits to confirm in your ERPNext version and environment
Loyalty programs touch sales, returns, POS and accounting, and each of those behaves differently by version and hosting model. The cards below list the behaviors to test on your own deployment before you commit to a design. Confirm each one against the release you plan to run.
Point expiry behavior
Confirm how expiry is applied to points earned on past invoices, whether it runs from the earn date or from a fixed program date, and when expired points leave a customer's balance. Ask how expiry interacts with partial redemptions and with customers who hold points across several tiers. Test with a short illustrative expiry window on a staging site so the result is visible before go-live.
Reversal of points on returns
Check how a return or credit note reverses points that were earned on the original Sales Invoice, and whether the reversal happens automatically or needs a manual step. Confirm what happens when points were already redeemed on the invoice being returned. Finance and sales teams should agree on who reviews these adjustments, since they change the customer balance and the loyalty expense.
POS support on your deployment
Confirm that redemption at the point of sale works on the POS profile and version you plan to use, including how the customer is identified and how the redeemed amount appears on the receipt. Test offline or intermittent connectivity behavior if your stores run it. Do not assume that a feature described in the English documentation is available in your language or on your hosting tier.
Multi-company handling
Confirm whether a loyalty program can be scoped to one company or shared across several, and whether a customer's points follow them between companies that share a customer record. Check which company's loyalty expense account is debited when a redemption crosses entities. Map each company's accounts and cost centers before you design the program, because a mismatch here is hard to unwind after posting.
Custom scripts on your hosting
Server scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting. Public shared benches on Frappe Cloud do not allow them. If your tier rules depend on custom logic beyond standard rules, confirm with the vendor or your host whether a server script or a custom app is permitted, and who maintains it through upgrades.
Upgrade and version fit
Confirm that the loyalty features you rely on exist in the exact ERPNext version you will run, and check the release notes for changes between minor releases. Ask whether your version is still supported, since Frappe publishes a support schedule per major version. Record the version in your test plan so a later upgrade can be rechecked against the same cases.
When loyalty rules need custom code or integrations
The standard Loyalty Program in ERPNext covers the documented pattern: points are awarded from submitted sales, and eligible customers redeem them on later Sales Invoices, either as a single tier or as several tiers based on cumulative eligible spend. Anything outside that pattern is a design decision, not a settings change. Before the build starts, list every earning or redemption rule the business uses today and mark each one as either covered by the standard configuration or not. Confirm the exact behaviour of each documented option against the current ERPNext loyalty program documentation and your target ERPNext version, since rules and field behaviour can change between releases.
Rules that usually fall outside the standard setup include earning points on non-sales events such as referrals or reviews, bonus multipliers tied to product attributes or campaigns, points that depend on customer segments beyond the program's own tiers, and loyalty balances shared with an external platform or an e-commerce storefront. Each of these needs either a custom app that hooks into document events, a Server Script (which must be enabled on version 15 and later and is not available on Frappe Cloud public shared benches), or an integration that writes Loyalty Point Entry records through an API. Ask your implementation partner to state which mechanism each rule uses, who owns the code, and how a failed sync is detected and corrected.
The main trade-off is between configuration and custom code at upgrade time. Configured programs survive ERPNext minor and major upgrades with the vendor's regression coverage behind them, while custom earning logic has to be retested against each release and may need changes when a DocType or hook moves. Keep custom logic in a version-controlled custom app rather than in database-stored scripts, document every hook it touches, and budget for retesting it on each upgrade. Also decide early who will maintain it after go-live, because a loyalty rule that only one developer understands becomes a liability at the first upgrade.
How DeployOpen scopes and delivers ERPNext loyalty programs
DeployOpen plans, configures, documents and supports ERPNext loyalty programs inside your own infrastructure, starting from the rules your sales and finance teams already run. Each engagement is fixed-scope, so the program design, redemption paths and accounting treatment are agreed in writing before any configuration begins.
How we scope
- Map each loyalty tier to the cumulative eligible spend rules your business actually uses.
- Document which submitted sales earn points, which items or customer groups are excluded, and who approves exceptions.
- Agree in writing where points can be redeemed: Sales Invoices, POS, or both, and at which company.
How we build
- Configure Loyalty Program records, collection rules and tiers in a staging copy of your ERPNext site first.
- Set up the loyalty expense account and cost center treatment with your finance lead before go-live.
- Test earning, redemption, returns and expiry with scripted sales and credit notes against agreed expected results.
How we hand over
- Deliver a configuration record covering tiers, earning rules, expiry settings and the loyalty expense account mapping.
- Provide step-by-step procedures for cashiers and accountants, covering redemption at POS and returns handling.
- Walk your administrators through the change process for future tier or rule changes, with a test checklist for each.
How we support
- Continue support on the program as an ongoing retainer, with changes handled through new written scope.
- Review loyalty postings and expense account balances with your accounting team at agreed intervals.
- Plan retesting of loyalty behavior whenever ERPNext or its companion apps move to a new release.
