2026-11-09 Author : ZCS
Reliable bar POS Happy Hour pricing starts with one written answer for every boundary case. The system should not leave bartenders to decide whether a 17:59 order, an 18:01 modifier or a member discount qualifies during a rush. The complete bar POS guide explains the wider operating system; this article focuses on the price rules that determine one drink's final charge.
The pricing model becomes easier to control when eligibility and price calculation are separated.
Bar POS Happy Hour pricing is a scheduled rule set that decides which items qualify, when they qualify, what promotional price applies and which other discounts may change that price. The POS also needs a stable result for later edits, refunds and reports. A Happy Hour button alone does not define those decisions.
That definition turns a promotional idea into a testable checkout policy.
Item-entry time is the clearest default for most staffed bars. A drink added to the check at 17:59 keeps its Happy Hour price even when the guest pays at 18:05. A new drink added at 18:01 receives the regular price. This approach matches the moment the bartender accepts the order and prevents a delayed closeout from repricing an already agreed sale.
Payment time creates avoidable disputes. A guest can order before the cutoff but lose the promotion because the bartender serves another customer, waits for a card or closes several tabs together. Payment-time eligibility can work only when the offer explicitly says the discount applies at payment and staff can control the queue fairly.
Send time can be useful when an order is not final until it reaches a bar or kitchen printer. The rule should specify whether an unsent item added at 17:59 qualifies after it is sent at 18:01. A venue that treats item entry as a draft may prefer send time, but the POS must show staff which timestamp became authoritative.
| Eligibility timestamp | Operational effect | Main risk |
|---|---|---|
| Item added to check | Price locks when the bartender selects the drink | Accidental early entries need void controls |
| Item sent or fired | Price locks when the order becomes operational | Delayed sending can change the expected price |
| Check opened | Every later item may inherit the original period | Guests can keep promotional pricing too long |
| Check paid | Final clock time determines the discount | Service delay can remove an expected offer |
The POS configuration must be verified rather than assumed. Toast's current menu-specific pricing guidance distinguishes a separate Happy Hour menu from time-specific pricing on an item. Those approaches can look identical to a guest while producing different staff actions, availability rules and edge behavior.
The recommended operating policy is simple: qualifying items keep the price recorded when they were added or sent, later additions use the price active at their own timestamp, and closing the check does not reprice earlier lines. The chosen POS must be able to demonstrate that behavior on an open tab crossing the cutoff.
The end time needs an exact inclusive or exclusive rule. “Happy Hour ends at 18:00” can mean that 18:00:00 is still eligible or that the regular price begins at 18:00:00. A predictable configuration uses a half-open window: the promotion is active from 17:00:00 up to, but not including, 18:00:00.
Under that rule:
An open tab should contain both promotional and regular prices when it crosses the cutoff. The earlier line keeps its recorded selling price. A later round uses the current rule. The POS should not change every drink on the tab merely because the last item was entered after Happy Hour.
Editing an old line needs its own policy. Increasing the quantity of a 17:59 drink after 18:00 can either preserve the original line price or price the additional quantity at the regular rate. The safer rule is to preserve only the original quantity and create a new regular-price line for the added unit. That preserves an audit trail and prevents staff from extending the promotion by editing one old line.
Voiding and re-entering a drink after the cutoff should normally use the current price. A manager can authorize an exception when the re-entry corrects a genuine service mistake, but the POS should record the reason and employee. Silent re-entry at the old price makes discount review difficult.
Device clocks must agree across the venue. A main bar terminal showing 17:59 and a patio handheld showing 18:01 can produce different prices for the same order. The deployment should identify the venue time zone, automatic clock source and behavior when a device is offline. Multi-location groups also need each site's local schedule rather than one head-office clock.
Eligibility should attach to explicit sellable variants, not a broad “drinks” category. A $2 discount intended for a single house spirit can accidentally reduce doubles, premium substitutions, flights or cocktails when the POS targets the whole category.
The bar should decide each layer separately:
| Price component | Rule to define | Example |
|---|---|---|
| Base drink | Eligible item or variant | House gin single qualifies |
| Size or pour | Eligible sizes | Single qualifies; double does not |
| Spirit substitution | Modifier eligibility | Premium gin surcharge remains full price |
| Mixer | Included or charged separately | Soda included; energy drink surcharge remains |
| Add-on | Discounted or excluded | Extra shot stays at regular price |
| Package | Separate bundle price | Beer-and-shot combo has one promotional value |
A fixed promotional price and a percentage discount behave differently. Setting a house margarita to $6 produces the intended final price even when the regular price changes. Applying 25% off follows the regular price automatically but can create unexpected cents, affect premium versions or combine with other discounts.
Size pricing can conflict with other pricing methods. Toast's official bar menu configuration guide states that an item using size pricing cannot also use menu-specific pricing because one item has one pricing strategy. Toast also notes that double-pour prices need manual configuration rather than an automatic multiplier of the single pour. Other POS platforms may implement this differently, so the exact menu model must be tested.
Separate item records can solve one price problem while creating inventory and reporting problems. A duplicate “Happy Hour Margarita” may no longer share the recipe, cost or reporting identity of the regular margarita. Where the POS supports it, one item with a controlled scheduled price usually keeps sales and inventory easier to reconcile.
Modifiers should remain visible on the receipt. A guest should be able to see a $6 promotional drink plus a $2 premium-spirit surcharge rather than one unexplained $8 line. Clear line construction also helps staff identify whether the surcharge was correctly excluded from the promotion.
Discount stacking must be an explicit business rule. The POS should never decide the result from button order, cashier habit or whichever rule happens to calculate first.
Three policies cover most bars:
Exclusive is the safest default for a simple Happy Hour. The advertised price is already promotional, the margin is predictable and staff do not need to explain why two guests received different combinations. Member points can still accrue without reducing the line again if the loyalty policy permits.
Best-price logic is customer-friendly but needs visible evidence. The receipt or order screen should show which offer won and which offer was rejected. Otherwise, a bartender may add a manual discount because the guest cannot see that the system already selected the better price.
Stacking requires an order of operations. Twenty percent off a $10 drink followed by a $2 reduction produces $6. Applying the $2 reduction first and then 20% produces $6.40. Tax, service charge and rounding rules can create further differences. The rule specification should state the sequence, rounding point and maximum discount.
Check-level discounts need special handling. A $10 loyalty reward applied to a mixed check can be allocated across Happy Hour and regular-price lines, or only across eligible regular-price lines. That allocation affects refunds, tax reporting and promotion analysis even when the check total looks correct.
A normal weekly schedule is not enough for a bar with event-driven pricing. Public holidays, match days, private events and ticketed nights may need the promotion paused or replaced with another menu.
The priority should be written from highest to lowest:
A dated exception should beat a repeating schedule. A weekly Friday promotion must not reactivate on New Year's Eve merely because the calendar still says Friday. The POS should show managers the effective schedule before publishing changes.
Toast's platform documentation for discount availability settings allows date ranges, selected weekdays and one or more hourly ranges. That example shows why “4–6 PM weekdays” is not one field: the configuration needs dates, days and times that can interact.
Event pricing should use a separate named rule rather than editing the normal Happy Hour rule. A separate rule preserves the ordinary schedule for the next week and leaves a clearer audit trail. Staff should see “Match Day Menu” or “Private Event Pricing” instead of an unexplained missing discount.
Schedule changes need a publication check on every affected device group. A manager should preview the effective date, location, start and end times before publishing, then verify one production terminal in each service area. The rollback plan should identify which prior rule can be restored without rebuilding the weekly schedule during service.
Multi-bar venues need one publication plan. A main bar, rooftop and VIP room may share item records but use different availability or prices. The multi-bar POS operations guide explains the synchronization problem across stations. The pricing rollout should identify which location, revenue center and device receives each rule.
A price reduction should not change the recipe or quantity depleted. One Happy Hour gin and tonic should deduct the same measured gin, tonic and garnish as the regular-price version when the recipe is identical. Revenue changes; physical consumption does not.
The strongest menu design keeps one inventory identity for the same drink. Toast recommends a shallow-copied menu structure for menu-specific pricing because the underlying item remains linked between regular and Happy Hour menus. A deep copy creates a separate item and can split reporting or inventory behavior.
A different portion needs a different inventory rule. A smaller Happy Hour wine pour, a reduced appetizer size or a promotional cocktail with a different spirit quantity is not merely a price change. The POS or inventory system should use a separate recipe, portion or item so theoretical usage matches what bartenders actually serve.
Paid modifiers must deplete their own ingredients. A premium spirit substitution, extra shot or energy drink surcharge should add the correct stock movement even when its price is excluded from the promotion. A pricing engine that calculates the total correctly but skips the modifier's inventory movement still creates a costly reconciliation error.
Refunds need both financial and stock decisions. The financial refund should normally use the amount originally paid, not today's regular price. The inventory action depends on what happened to the drink: a cancelled unmade drink may restore stock, a served drink refunded for service recovery should not, and a remade drink may require waste plus a new recipe depletion.
The following table should be completed before the promotion goes live. The “expected result” column reflects a practical default, but each bar should adjust it to its published offer and POS capabilities.
| Test case | Rule to define | Recommended expected result |
|---|---|---|
| Drink added at 17:59, check paid at 18:05 | Eligibility timestamp | Happy Hour price remains |
| First drink at 17:59, second at 18:01 | Mixed-price open tab | First promotional; second regular |
| Quantity increased after 18:00 | Treatment of added units | New unit becomes a regular-price line |
| Drink voided and re-entered after 18:00 | Re-entry rule | Current price unless manager-approved correction |
| Check opened before Happy Hour, drink added during it | Check time versus item time | Drink receives promotional price |
| Single house spirit | Eligible variant | Promotional price applies |
| Double pour | Size rule | Regular or separately defined double price |
| Premium-spirit substitution | Modifier rule | Promotional base plus full surcharge |
| Extra shot | Add-on rule | Full add-on price and added inventory depletion |
| Member discount on promotional drink | Stacking policy | Exclusive or best-price result, not button-order result |
| Mixed check with a check-level reward | Allocation rule | Reward allocated only to defined eligible lines |
| Holiday that falls on a normal weekday | Exception priority | Holiday blackout overrides weekly schedule |
| Offline device at the cutoff | Clock source | Same result as connected terminals |
| Refund next day | Historical price | Refund original paid amount |
| Served drink refunded | Inventory restoration | No stock restoration; record service recovery |
| Unmade drink cancelled | Inventory restoration | Restore stock if it was previously depleted |
| Promotion edited but not published | Deployment state | Production terminals keep old rule until publish completes |
| Terminal reconnects after outage | Rule refresh | Downloads current schedule without repricing closed sales |
Every test should record the displayed price, receipt result, discount name, inventory movement and audit entry. A correct total alone can hide an incorrect recipe depletion, missing reason code or inconsistent terminal clock.
A rush-hour rehearsal should use several terminals and one long-running tab. The fast checkout POS guide covers the wider throughput problem. For Happy Hour, the rehearsal should cross the start and end times while bartenders add, modify, transfer, split, void and close checks.
A one-page rule specification is more useful than asking for “Happy Hour support.” The handoff should contain values that a vendor can configure and a manager can approve.
Include:
The developer-facing implementation should be deterministic. The same item, timestamp, location, customer status and active exception should always produce the same price regardless of the terminal or button sequence. A rule engine should also return the applied rule name so the receipt and audit log can explain the result.
Hardware does not create Happy Hour logic. An Android POS supplier such as ZCS can provide terminals on which an integrator deploys its bar application, but the application and its backend must own pricing, inventory, synchronization and audit behavior. Changing hardware cannot repair an undefined discount policy.
Most wrong prices come from missing rules rather than arithmetic errors. The following problems deserve a pre-launch check:
Daily review should focus on exceptions. Managers do not need to inspect every correctly priced drink. A useful report isolates manual discounts, manager overrides, post-cutoff promotional prices, stacked offers, void-and-re-ring activity and refunds whose inventory treatment differs from the financial result.
Item-entry or send time is usually fairer and easier to operate than payment time. The bar should select one timestamp, publish the rule to staff and test an open tab that crosses the cutoff.
The drink should normally keep the promotional price recorded when it was ordered. Later drinks added after the cutoff should use the regular price.
Only when the promotion explicitly includes doubles. Singles, doubles and other sizes should have separate eligibility or promotional prices so a broad discount does not reduce unintended portions.
The bar must choose exclusive, best-price or stacked behavior. Exclusive is the simplest default; stacked discounts require a defined calculation order, rounding rule and maximum reduction.
Create a dated exception with higher priority than the weekly schedule. A separate event rule is safer than editing and later rebuilding the normal promotion.
No, not when the drink and portion are unchanged. The same recipe should deplete the same ingredients at either price. Different promotional portions require separate recipe rules.
The refund should normally use the amount originally paid. Inventory should be restored only when the product was not served or the venue's recorded stock policy requires restoration.
A reliable Happy Hour configuration makes every edge case predictable before the first discounted drink is sold. The bar should lock the eligibility timestamp, cutoff boundary, size and modifier scope, stacking policy, exception priority, refund behavior and inventory treatment in writing.
The rule-and-test table is the real implementation document. A POS vendor can use it to configure the software, a manager can use it to train staff, and an operator can use it to prove that 17:59, 18:00 and 18:01 produce the intended prices on every terminal.
Home 
Square Register Customer Display: Replacement Compatibility and Alternative POS Setups 
