A price override at the register is when a cashier or manager manually changes what a customer pays for an item, instead of letting the catalog price ring up as-is. Used well, it's a normal part of running a counter — fixing a mispriced tag, honoring a sale that didn't get activated in the system, or handling a damaged item without voiding the whole transaction. The way to stop it from becoming a quiet hole in your margin isn't to ban overrides; it's to decide in advance who can do them, require a reason, and review what gets overridden and by whom. Retailer OS supports price overrides at checkout the same way it supports discounts, but both sit behind role permissions and show up in the audit log, so every change is tied to a person and a timestamp.
What Counts as a Price Override at the Register?
A price override is a manual change to an item's selling price during a transaction, applied by staff rather than pulled automatically from the catalog, a promotion, or a customer's price tier. That's the one-sentence version worth remembering: it's a human decision made at the moment of sale, not a rule the system applied on its own. Because it's a human decision, it's also the one place at the register where policy and trust matter more than software.
When Is a Price Override the Right Call?
Most legitimate overrides fall into a short list of situations. If a store is seeing overrides outside these patterns regularly, that's worth a closer look.
- The shelf tag or price sticker doesn't match what's actually in the system, and the customer shouldn't pay for a merchandising mistake
- An item has visible damage, a scuff, a missing accessory, or is being sold as a floor model
- A promotion or sale ended in the system but is still posted on the shelf or in-store signage
- Matching a competitor's advertised price for a specific, verifiable item and customer
- Making good on a service problem — a long wait, a wrong item pulled from the back, a mislabeled special order
Price Override vs. Discount: Same Register, Different Control
Overrides and discounts both change what a customer pays, but they're not the same action and shouldn't be treated the same way in your policy. A discount takes a percentage or dollar amount off the catalog price and is usually tied to a reason — a promotion, a loyalty reward, a manager-approved markdown — and it still shows the original price on the receipt. An override replaces the price entirely; the customer's receipt can show a different number with no visible markdown trail unless the register records it as an override specifically. That distinction matters for reporting: discounts roll up into promotion and campaign numbers, so you can see what a sale actually cost you in aggregate. Overrides don't carry that context on their own — which is exactly why they need their own permission and their own review, not just a general "who can give discounts" policy.
Who Should Be Allowed to Override a Price?
The fastest way to lose control of overrides is to leave the permission wide open because it's "easier for the team." A tighter, role-based approach costs almost nothing in speed at the counter and saves real money over a quarter.
- Owners and admins — unrestricted override permission by default; they're accountable for the whole store's margin anyway
- Store managers — override permission tied to the role, matching the same discretion they'd have for voids and refunds
- Shift leads — a narrower override permission if your custom role allows it, often limited to situations like damaged goods
- Cashiers — generally no override permission; they escalate to a manager, which naturally creates a second set of eyes
This is the same logic that governs voids, refunds, and discounts, and it's worth setting up all four together rather than one at a time. See POS user roles and permissions for how to think through the full set.
How Do You Keep Overrides Accountable?
Permissions stop the wrong people from overriding a price. Accountability is what catches the right people doing it too often, or for the wrong reasons. A few concrete steps make the difference:
- 1. Restrict override permission to roles that actually need it — manager and above is a reasonable default for most stores
- 2. Require a note or reason on every override, even a short one; "damaged box" takes three seconds to type and turns a mystery into a record
- 3. Set a fixed cadence to check the audit log — weekly, not just when a number looks off at month-end
- 4. Review overrides against the register and the person signed in, not just the total dollar amount for the day
- 5. Watch for patterns: the same item, the same cashier, the same time of day, or overrides clustering right before a shift change
What Happens When Overrides Go Unchecked?
Unmonitored overrides are a slow leak, not a dramatic loss — which is exactly why they're easy to miss. A $5 override here and there for friends, family, or regulars doesn't look like theft, and often isn't intended as theft. But run that across a busy register for a month and it's a real dent in gross margin that never shows up as a single alarming transaction. It shows up as a trend in the audit log, which is why reviewing it on a schedule matters more than reacting to a bad day. This sits in the same category as other register controls worth having in place together — see preventing employee theft at the register and cash handling procedures for the related pieces.
How Retailer OS Handles Price Overrides
Retailer OS supports price overrides at checkout alongside discounts, price overrides, and tax handling as part of standard point of sale checkout. Whether a given employee can use an override is controlled through roles — the built-in roles (owner, admin, manager, cashier, viewer) or a custom role you build — the same permission system that governs discounts, voids, refunds, and returns. Every price change is recorded in the audit log, which shows who made the change and when, and can be filtered by date range, so a weekly review takes minutes rather than a manual pull of receipts. Because overrides and discounts both feed the same reporting the rest of the store relies on, a manager reviewing margin doesn't have to cross-reference a separate system to find where it moved.
If overrides are frequent enough to move your margin meaningfully, it will also show up in the daily sales journal that reaches QuickBooks Online — reviewing the register-level audit log and the accounting-level trend together catches the pattern faster than either one alone.
Set who can override a price in Setup → Team, under roles and permissions, and check the audit log once a week rather than once a quarter. See how store permissions and the audit log work, or compare plans and pricing if you're still setting up roles for a new store.
Last updated October 3, 2026