A restaurant POS can show the right total and tax for your approved price model only if its configuration supports the way you sell and produces the results your restaurant expects. Ask the vendor to demonstrate that with your own items, not just a single standard sale.
The useful test is a mixed cart: include a price that already contains tax, a price with tax added, and an applicable exemption if your operation uses one. Compare the expected amounts with the checkout screen, receipt, and report. If the results do not match, resolve the difference before signing or changing a live setup.
Define what the POS needs to show
Start with the restaurant's approved pricing rules. For a tax-included item, the displayed price already contains the specified tax amount. For a tax-added item, the POS adds the applicable amount to the displayed price. Your menu may use one approach throughout or require different treatment for different items.
Write down the expected treatment for each relevant item and service scenario. Include any different tax treatments, approved exemptions, discounts, modifiers, and rounding rules that matter to your operation. A qualified tax adviser can help determine the rules and expected amounts; the POS demonstration should establish whether the software can apply and display those instructions.
Then identify who needs the result and when. A cashier needs a clear total before asking for payment. A manager may need to approve an exemption or correct an item. The guest needs a receipt they can understand. Whoever reconciles sales needs a report that separates the amounts your restaurant expects to track.
Decide which displays must show the item price, tax, and final total. For example, a receipt might show tax as a separate line, but you should also decide how it must represent tax already included in a menu price. Ask whether the POS can produce that presentation rather than assuming a correct checkout total means every other display will be correct.
Bring this requirements sheet to a restaurant POS system demonstration. Include the order types and devices you actually use. A counter-only test may not answer what happens when staff enter the same items elsewhere.
Compare the workflow, not just the total
Ask each vendor to build the same cart with your approved test items and show the calculation before any payment. Have the person demonstrating identify which settings control each item's treatment and who can change them. If an exemption requires a manager, ask to see the staff and manager steps separately.
Check the states that matter to your restaurant:
- Item entry: Does each item retain its intended included or added treatment when entered alongside the others?
- Changes: What happens when staff change a quantity, add a modifier, remove an item, or apply an approved discount?
- Exceptions: How does an authorized user apply and remove an exemption? Is the resulting total clear before payment?
- Receipt and report: Are the amounts and labels understandable, and do the reported totals match the approved expectation?
- Channels and roles: Where relevant, can staff repeat the check on each device and order flow they use, with the permissions they normally have?
Use the same worksheet for Toast, Square, Fleksa, or another vendor on your shortlist. Toast lists restaurant POS, hardware, online ordering, payments, kitchen display systems, and integrations. Square offers restaurant point of sale and related payment and order tools. Fleksa offers restaurant POS connected with direct ordering, reservations, and related tools. Those descriptions do not establish how any particular tax configuration will behave.
Record a result as available, unavailable, or needing confirmation. Also record whether the demonstrated workflow requires a particular plan, processor, device, integration, or extra configuration. Ask for those dependencies in writing with the quote. Review the proposed POS hardware alongside the software workflow, rather than assuming every device will show the same information.
Ask what happens if a setting is changed after the menu is built: who can make the change, how will staff know, and what should be checked again? If a required receipt or report cannot be shown, do not mark it as passed because the checkout screen looked right.
Work through a mixed cart in cents
The following is a hypothetical demonstration, not a tax rule. Assume the restaurant's adviser has approved the expected amounts below for these specific items and circumstances. The example covers sale and tax amounts only. It excludes fixed operating costs, variable costs such as processing fees, and exception costs such as refunds or corrections; none are included in the order total.
The first price includes its tax. The second has tax added. The third is an item for which the restaurant has approved an exemption in this scenario. The expected total is the sum of the three amounts payable, not the sum of menu prices plus all displayed tax.
| Test item | Price shown | Expected tax | Amount payable |
|---|---|---|---|
| Included-tax item | 1,000 cents | 100 cents included | 1,000 cents |
| Added-tax item | 600 cents | 30 cents added | 630 cents |
| Exempt item | 400 cents | 0 cents | 400 cents |
| Cart total | 2,000 cents | 130 cents total tax | 2,030 cents |
Read the last row carefully: 100 cents of the total tax is already inside the first item's 1,000-cent price. Adding the full 130 cents to the displayed prices would count that portion twice. The expected amount payable is 1,000 + 630 + 400 = 2,030 cents. Of that, 130 cents is tax and 1,900 cents is the amount before tax: 900 + 600 + 400.
For this test, the checkout screen should show 2,030 cents as the amount due. Check that the receipt represents the 130 cents of total tax in the restaurant's approved format and does not imply the included 100 cents was added again. Check that the relevant report records 2,030 cents in the sale and 130 cents in tax, using the labels and breakdown your restaurant requires.
Keep separate columns in your working notes for expected and actual results. An expected result comes from the approved calculation; an actual result is what an authorized test shows. If a screen displays the right total but the receipt or report differs, record the mismatch rather than calling the whole cart a pass.
Run the initial check in a vendor-approved simulation or training environment. Do not use a real card payment, send a guest message, or dispatch a courier for practice. Confirm with the vendor that the test environment prevents those actions. If the receipt or report cannot be previewed without completing an order, ask for a safe demonstration method before proceeding.
Set an acceptance rule and a fallback
Assign one person to own the worksheet and collect the results. That person should coordinate the approved expected amounts with the restaurant's adviser and have a manager or trained staff member repeat the workflow. Give the vendor the same inputs and ask them to identify any configuration they changed during the demonstration.
A practical acceptance rule for the example is: the authorized user can enter all three items, apply the approved exemption, and see 2,030 cents due; the receipt and report show the approved treatment of 130 cents in total tax. The result must hold in each required order flow and device you have agreed to test. If your requirements include other quantities, discounts, or modifiers, add those as separate cases rather than treating one cart as proof of every combination.
Set a fallback before moving on. If the total or breakdown fails, stop the change or purchase decision for that workflow, document the screen or report result, and ask the vendor to explain the setting or limitation. Have your adviser review any disagreement about the expected tax treatment. Do not ask staff to invent a manual adjustment at checkout to make a demonstration pass.
A simulated check is not the same as a live service pilot. If you later run an authorized live pilot, agree on its scope, staff responsibilities, monitoring, and stop procedure first. Use actual service transactions only under your restaurant's normal controls, not as practice charges. Recheck the results after a configuration change and before expanding the workflow.
Compare the written quotes as well as the demonstrations. Ask about required plans, processing arrangements, contract duration, cancellation terms, support, and any costs to configure or change the setup. Quoted processing fees alone are not the all-in operating cost. Use the guide to payments, processing cost, cash close and POS reports to frame that broader review, and consult qualified advisers where contract, legal, or tax treatment needs interpretation.
Next step: Request a demo of Fleksa's restaurant POS with your approved mixed cart. Send the expected totals, required receipt and report views, user roles, and acceptance rule in advance, then record the demonstrated results against them.
Frequently asked questions
Can one order contain tax-included and tax-added prices?
That depends on the POS configuration and the restaurant's approved rules. Ask the vendor to demonstrate both treatments in the same cart and show the resulting checkout, receipt, and report.
Does a correct amount due mean the tax setup passed?
No. Also compare the tax breakdown, receipt presentation, and report with your approved expectations. A correct final total can still hide a breakdown or display problem.
Should staff use a real payment to practice?
No. Use a vendor-approved simulation or training environment that does not create a real payment, guest message, or courier dispatch. Plan any later live service pilot separately.
