Manual Points Adjustments: Stop Staff Loyalty Abuse in Your Online Store

The short version: manual points adjustments — make-goods, missing-points top-ups, corrections — are the seam where staff with loyalty-app admin access can credit their own or a friend's account in an online store. Three reports from your app's export plus a ~20-minute weekly spot check cover it, with no new software.

Key takeaways

• Manual points adjustments are the seam for staff loyalty abuse online: points credited by hand with no order or ticket behind them stay invisible in dashboards because the ledger balances either way.
• Pull three weekly reports from your loyalty app export — adjustment rate per staff member, staff-to-account overlap, and adjustments missing a reference — and read the baselines off your own data, not off benchmarks.
• Prevention beats detection: require an order or ticket reference on every adjustment, block staff accounts from being adjusted by co-workers, and cap adjustments per person.
• A spot check only works if it samples manual adjustments; auditing automatic order awards detects nothing, because those accounts are attached at checkout and cannot be misattributed.

Manual points adjustments are the seam your dashboard can't see

Manual points adjustments are balance changes an admin makes by hand in your loyalty app — a make-good for a late order, a top-up for points that never posted, a service-recovery credit — rather than awards the app grants automatically when an order ships. In an online store that seam is the whole manual surface: orders award points themselves, but every adjustment passes through a person with admin access. A support agent handling a "my points didn't post" ticket can credit the policy make-good to a customer — or to their own account, a partner's, or a rotating family member's. The ledger balances, the ticket is closed, the customer is never shortchanged, and no flag fires. The points came from a real program; they just went to the wrong person, on purpose, by someone you trusted with the button.

This is not program-level fraud like referral stacking or coupon abuse, which the six minimum controls in Loyalty Program Fraud Prevention: Six Minimum Controls are built to catch. Insider abuse defeats those controls because the actor holds legitimate admin access. To size the exposure: one unverified 500-point adjustment books $5 of liability you gave away (worked example: 500 points redeemed at $0.01 each) — small per incident, compounding across a staff and a year. It is the same exposure governed at the account level in Loyalty Points Liability: Build Controls Before Campaigns, just entered by hand instead of by campaign.

Three loyalty-app reports that expose adjustment abuse

Three weekly pulls from your loyalty app's export expose adjustment abuse that no single metric shows: the adjustment rate per staff member, staff-to-account overlap, and adjustments without a reference. Each targets a different step in the chain — the actor, the beneficiary, and the missing paper trail.

Report 1: adjustment rate per staff member. Divide each person's manual adjustments for the week by the work that justifies them — tickets closed, or orders handled, whichever your helpdesk tracks (adjustments ÷ tickets closed). Read the baseline off your own data before judging anyone: pull four weeks as an illustrative starting window, compute each person's usual ratio, and treat a sustained deviation from that person's own normal as the signal. Never compare raw adjustment counts between staff: the agent assigned to a product line with a known points-posting bug will legitimately adjust more. Without that denominator the report can't fire — a low-volume agent making ten adjustments looks worse than a high-volume one making fifty, when the fifty is the anomaly.

Report 2: staff-to-account overlap. For each account that received a manual adjustment, list who adjusted it over the trailing period. The pattern that matters is the same staff member repeatedly adjusting the same account — especially accounts sharing an email, shipping address, or last name with a staff member. One occurrence is a genuine make-good on a real problem; the same person-account pair appearing week after week is a pattern worth a look.

Report 3: adjustments without a reference. If your app requires a note or reason on each adjustment, filter the export for blank notes or generic ones like "correction." An operation with healthy habits produces few of these; a growing pile traced to one login is either a training gap or a holding pattern while someone waits to reuse the account. Both deserve a conversation, and only one is a discipline problem.

The classic failure: pulling report 2 raw and treating any account that shares a surname with a staff member as guilty. People who live together share purchases and share points. Overlap is a reason to check, not a verdict.

Prevention rules that make adjustment abuse hard in the first place

The right prevention rules make adjustment abuse structurally difficult: require an order or ticket reference on every manual adjustment, flag staff accounts so co-workers cannot adjust them, and cap adjustments per person per week. Detection tells you what already happened; prevention shrinks how much of it can happen.

Reference required. Configure the app so a manual adjustment demands an order number or ticket ID before it lands. This kills the "credit it later" path, because there is no later: the adjustment attaches to a real record in real time, and the spot check below has something to verify against.

Staff accounts flagged. Mark employee accounts in your loyalty platform and check whether it can block them from earning on or being adjusted by other admin users — many apps include a flag or exclusion setting for exactly this. If yours doesn't, the reference requirement and the cap still hold, and the flag becomes a manual review rule. Blocking co-worker adjustments is the single highest-leverage rule on this list, and it costs a field, not a purchase.

Per-person adjustment cap. Cap how many manual adjustments one person can make per week — as an illustrative starting point, five, then adjust to whatever your own ticket data says is generous. A genuine missing-points spike after a migration will blow through it; the cap is there to catch a steady drip that outlasts every legitimate reason. Treat a cap-hit as a review trigger, not an automatic block.

The classic failure here: disabling manual adjustments outright. Missing-points tickets are real, and pushing every correction to "we'll look into it" converts a small fraud exposure into ticket volume and churn in your best repeat customers. Keep the lever; gate it.

The ~20-minute weekly spot check (ten adjustments, scaled to volume)

A ~20-minute weekly spot check samples manual adjustments, verifies each against its reference, and logs the result. It is the human layer on top of the reports — the reports find patterns, the spot check confirms them with evidence.

The procedure: pull last week's manual adjustments from the export — as an illustrative starting sample, ten, scaled to your volume — then for each one, open the order or ticket it references. Does the record exist? Does the customer's issue justify the size? Does the account owner match the customer on the ticket, or is it a bare account whose only history is a stream of adjustments from one login? Log each result in a spreadsheet — date, adjustment ID, staff member, account, outcome. Over four to six weeks the log becomes your baseline, and "normal" stops being a guess.

The check-that-can't-fire caveat: sample manual adjustments only. Automatic order awards cannot be misattributed — the customer's account attaches at checkout, before any human touches anything. If your sample drifts toward automatic awards because they are easier to pull, you will produce weeks of clean results that mean nothing. Filter the export to adjustment records or you are auditing a channel that cannot fail.

When the spot check finds something

When the spot check finds a discrepancy, document first, confront with evidence second, and keep the loyalty correction separate from the HR process. Confrontation before documentation turns a controls finding into a he-said exchange, and you lose both the case and the paper trail.

Document the adjustments, the accounts, the staff logins, and the dates in writing before anyone is approached. Confront with the specific pattern, not the accusation — "this account received 14 manual adjustments from your login in three weeks" is a fact; "you're stealing points" is a fight. Then split the response in two: correcting the ledger — clawing back points, adjusting balances — is a program operation you own, while what happens to the employee is an HR matter with its own process and its own people. Mixing them means the ledger correction stalls while HR deliberates, or HR inherits a decision made on loyalty data they never reviewed.

Handle it internally, and document anyway. In the wider retail world, 64% of retailers report less than half of store theft to law enforcement, citing lack of enforcement response as the primary reason [3] — theft handling runs as an internal process, and your ledger correction will too. Whether or not anyone outside the building is ever involved, your written record is what protects you: in the HR conversation, in a dispute, and in proving the control existed if an auditor or insurer ever asks.

Frequently asked questions

How do I flag staff accounts without embarrassing them?

Do it silently in the app configuration — no announcement, no meeting, no exemptions discussed in the team chat. If staff ask, the honest framing is that the rule protects them: an employee account is the first place an auditor looks after any discrepancy, and an exclusion rule means they can never be accused of what the system makes impossible.

What if my loyalty app doesn't log which admin made an adjustment?

Then attribution is your first fix, because every report above depends on it. Check the app's raw export and your platform's admin activity log before assuming the data doesn't exist — the acting user is often recorded even when the reporting view hides it. If it genuinely isn't recorded, run report 3 at the store level and lean on prevention: the reference requirement and staff-account rules don't depend on knowing who clicked. Fix the logging at your next app review; it is a data field, not a feature request.

Is monitoring my staff's adjustments legal?

This article is not legal advice, and employment-monitoring rules vary by state and country — some jurisdictions require notice that employee activity may be monitored, and some regulate how employee data is stored. Before rolling out per-person reporting, check your jurisdiction's requirements with a qualified employment lawyer, and put whatever notice is required in writing where staff can see it. A control that is lawful in one state can be a problem in another.

Sources

1. invue.com, 6 Retail Shrinkage Statistics Every Loss Prevention Leader Should Know | InVue, 2026-06-11. [3]