Yes, a restaurant can schedule time-based prices without surprising check totals, but only if the POS applies the timing rules your team expects. Before buying, ask each vendor to demonstrate what happens when an order opens before a price change, items are added afterward, and the guest pays later.
Give every vendor the same sample schedule and expected results. Then compare item prices, check totals, receipts, and reports—not just whether a screen has a scheduling option. A recurring menu price is different from a server manually changing a price or applying an item discount, so ask how the system handles this specific job.
Write the schedule before comparing systems
Start with one promotion you actually want to run. Write down the days, start and end times, eligible items, sales channels, and exclusions. Specify the restaurant’s local time zone and whether the start and end are inclusive. A phrase like “weekday happy hour” leaves too much room for different interpretations.
The following example is hypothetical. Assume a restaurant wants a weekday dine-in price for one small lemonade. The regular price is $6 and the scheduled price is $4. The offer starts at 3:00 p.m. and ends at 5:00 p.m., Monday through Friday. For the desired rule, 3:00 p.m. is included and 5:00 p.m. is not. Bottled lemonade, takeout, delivery, and modifiers are excluded.
The owner also wants the price determined when each item is added to a check. A lemonade added at 4:59 p.m. should remain $4 even if the guest pays after 5:00 p.m. One added at 5:00 p.m. should be $6. This is the restaurant’s desired behavior, not a claim about any particular POS.
That choice affects more than the owner. Servers need to explain the price before a guest orders. A manager needs to resolve a disputed check. The person reconciling sales needs to know whether the report shows a lower selling price or a discount. If the restaurant uses online ordering, the menu owner must also know whether the offer appears there or remains dine-in only.
Give vendors a requirements sheet that names the item and its regular and scheduled prices. Ask whether eligibility can be limited by day, time, item, and channel. If a modifier is added to the lemonade, ask whether the base item remains eligible and how the modifier is priced. Ask who can change the schedule and how the team can see that a change was made.
Test the moments when the price changes
The critical question is which event determines the price: opening a check, adding an item, sending an order, or closing and paying the check. A vendor may offer a different rule from the one you want. That does not automatically make its system unsuitable, but you need to understand the operational consequences before guests encounter them.
Use the same clock and sample menu for each demonstration. First, open a check before 3:00 p.m. and add the lemonade before and after the start. Next, open a check during the offer, add a lemonade before 5:00 p.m., and simulate closing it after 5:00 p.m. Finally, add an item at the exact end time. Check the price of each item as well as the total.
Keep practice separate from live service. Use a vendor-provided demo or other isolated test environment, with simulated payment and no real card charge, guest message, or courier dispatch. Ask the vendor how to prevent test orders from entering live operations. If a particular situation cannot be simulated safely, ask for a documented demonstration instead.
Also ask what happens when a server moves an item to another check, splits a check, changes a quantity, or reopens a closed check. Does the original item price stay in place, or is it recalculated? Have the vendor show the result and identify any setting that changes it. Record the setting alongside the result; otherwise, a later configuration change can make the demonstration hard to reproduce.
Save the vendor’s written explanation and a screenshot or sample receipt for each important case. Mark the result as demonstrated, documented but not demonstrated, or still unanswered. A verbal “that should work” is not the same evidence as an itemized check produced under the agreed conditions.
Compare receipts, reports, and exclusions
A scheduled $4 selling price and a $6 item with a $2 discount can produce the same $4 item total. They may nevertheless appear differently on a receipt or report. Ask each vendor to show both the guest-facing receipt and the sales report for the sample transaction. Look for the regular price, actual selling price, discount amount if any, and item quantity.
For a separate hypothetical reporting example, assume three eligible lemonades sell for $4 each and one excluded bottled lemonade sells for $6. The item subtotal is $18: $12 for the eligible items plus $6 for the bottle. The subtotal includes item prices only; it excludes modifiers, payment processing fees, and taxes. There are no fixed or other exception costs in this transaction example. It is a sales subtotal, not a profit or an all-in operating cost.
If the report represents the three eligible drinks as $18 in regular-price sales less $6 in discounts, ask how that affects the restaurant’s usual sales review. If it instead records $12 as their selling price, ask whether the report still makes the scheduled period easy to identify. Either presentation may be usable, but the owner and bookkeeper should agree on what they need before choosing.
Exclusions can change the decision. Suppose the vendor cannot keep the scheduled price off takeout orders, but the restaurant intends the offer for dine-in only. A correct dine-in receipt would not resolve that mismatch. The owner must decide whether to change the promotion, use a different setup the vendor can demonstrate, or rule out that option.
Ask about combinations, too: Can the scheduled price combine with a coupon or another promotion? What happens if an eligible item is unavailable? Can an employee change the schedule without approval? Put the answers beside the report samples so the team can judge the whole workflow rather than a single successful check.
Use a boundary-time worksheet to approve a choice
The worksheet below applies the lemonade schedule and the desired per-item timing rule. Prices are item prices before modifiers and taxes. “Owner” names the person responsible for approving the result; that person can delegate the demonstration but should accept or reject the evidence.
| Simulated case | Expected item price | Evidence to keep | Approval owner |
|---|---|---|---|
| Weekday dine-in item added at 2:59 p.m. | $6 | Itemized check with time and price | Owner |
| Weekday dine-in item added at 3:00 p.m. | $4 | Itemized check with time and price | Owner |
| Weekday dine-in item added at 4:59 p.m.; check paid at 5:01 p.m. | $4 | Itemized check and simulated payment time | Owner |
| Weekday dine-in item added at 5:00 p.m. | $6 | Itemized check with time and price | Owner |
| Weekday takeout item added at 4:00 p.m. | $6 | Order type and itemized check | Owner |
| Saturday dine-in item added at 4:00 p.m. | $6 | Order date and itemized check | Owner |
For each vendor, add the actual result to your own copy and note whether it matched. Keep the configuration, receipt, and relevant report together. If the desired behavior depends on a setting, ask who controls that setting and whether changing it affects existing checks.
Compare Fleksa, Toast, and Square against the same requirements rather than assuming they handle scheduled prices alike. Toast and Square offer restaurant POS and related ordering or payment tools; Fleksa offers restaurant POS connected with direct ordering, reservations, and related tools. Ask each vendor to demonstrate the specific schedule, exclusions, and reports you need. For broader buying questions, review these POS questions and consider how the schedule fits your restaurant management software.
Before signing, resolve any failed or unanswered cases in writing. Ask for a current quote covering the setup and ongoing services you need, and clarify any contract or cancellation terms. If the schedule only works with a process your staff cannot reliably follow during service, that is a practical reason to reconsider it.
Take your sample schedule and worksheet to a Fleksa restaurant POS system demo. Ask the vendor to document the outcome for each boundary case, show the receipt and report, and identify any settings or exclusions your team would need to manage.
Frequently asked questions
Does a scheduled price always apply when an order is opened?
No single timing rule should be assumed. Ask whether the price is determined when the check opens, the item is added, the order is sent, or the check closes, and request a demonstration.
Is a scheduled price the same as an item discount?
They can produce the same item total, but the receipt and reports may show them differently. Compare both outputs against the records your restaurant needs.
How should staff practice a price change?
Use an isolated demo or test environment with simulated payment and no real guest message or courier dispatch. If the team later runs a live service pilot, use real orders only under a separately approved operating plan.
