Before buying a restaurant POS, ask to export a small set of fictional records while the account is active. Then compare the files with the same records on screen. A useful export should give the people running your restaurant enough detail to answer their regular questions without asking the vendor to rebuild the data each time.
Do not settle for a promise that you “own your data” or can download a sales report. Ask which records you can retrieve, what each file contains, who can export it, and how often. The answer may be different for menu items, transactions, and staff activity.
Choose records that reflect your restaurant
Start with the work you expect to do while you remain a customer. An owner may want to review discounts by item. A manager may need to check who entered a void. The person maintaining the menu may need to compare current modifiers with an approved menu. Each task calls for different fields.
Use a fictional set of records for the demonstration. Do not send the vendor a real guest list, real staff details, or actual payment information. Agree on the sample records before the demo so that the files can be checked against a known source.
The following hypothetical restaurant sells a sandwich with an optional add-on. Its sample includes one discounted sale and a separate refund. All names, items, and amounts are made up. The figures describe transaction values, not processing fees or the restaurant's operating costs.
- Menu: A $12 sandwich, an optional $2 cheese add-on, a category, and an availability setting. Include a second item that is unavailable so you can see how its status appears.
- Transactions: One sandwich with cheese, a $1 discount, and a $13 final sale amount. Include a separate $4 partial refund linked to that sale.
- Staff: A fictional cashier and manager, with a sample sale attributed to the cashier and the refund attributed to the manager. Use invented IDs rather than real employee details.
The sale is $12 plus $2, less $1, for $13. After the separate $4 refund, the net transaction value is $9. Tax, tips, processing fees, fixed costs, and other exception costs are excluded from this example. Keep the original sale and refund visible as separate events; a net figure alone does not explain what happened.
Make the scenario fit your operation before using it. A restaurant with many customizations might add a modifier group with a required choice. A manager who reviews canceled orders might add a fictional void. Ask for enough examples to cover decisions you actually make, rather than every possible report.
When assessing a restaurant POS system, also decide who will inspect each export. The menu manager can judge whether modifier relationships are useful; the owner or bookkeeper can check transaction detail; a manager can assess staff attribution. One person may not spot every omission.
Get specific answers about access and format
Ask the vendor to show the export from an active sample account, not just a dashboard or a screenshot of a report. Request the resulting sample files and a short explanation of the fields. Open the files in the software your restaurant expects to use. A downloadable file is only useful if someone can read it and connect related records.
Record the answers alongside the demo evidence. Note whether a point was demonstrated, documented in writing, or only discussed. For example, “manager role downloaded transactions during the demo” supports a narrower conclusion than “every manager can export everything.” Ask the vendor to clarify any difference before relying on it.
- Format and structure: What file formats are available for each record type? Are menu items, modifiers, sales, refunds, and staff activity in one file or several? Is there a field guide?
- Detail: Can the export show item-level prices, discounts, refunds, timestamps, and the staff member associated with an action? Are modifier names and prices included, or only the final item total?
- Permissions: Which roles can run each export? Can the owner control access, and can a manager get the records needed for routine work without receiving unnecessary staff information?
- Frequency: Can an authorized user export on demand during an active subscription? Are there date-range, record-count, or historical-access limits? How soon after a transaction does it appear?
- Cost and help: Is the export included in the quoted subscription, or does it require a paid add-on or a support request? Are there charges for larger files, custom fields, or assistance?
Also ask whether related records carry stable identifiers. A sale ID and a reference on its refund make it easier to connect the two. For menus, a modifier may need an identifier or another clear relationship to its item. Readable names help people inspect a file, but names alone can change or repeat.
Keep the comparison focused on routine access during the subscription. If you also want assurances about data after cancellation, ask for those terms separately. Access during an active account should not be assumed to answer every departure question.
Reconcile the file with the screen
Use the same fictional records on screen and in the exported files. The table below shows what to check and why an omission matters. The expected values come from the sample scenario above; they are not claims about any vendor's export.
| Record | On-screen sample | What to find in the export | Decision if missing |
|---|---|---|---|
| Menu item | $12 sandwich; $2 cheese option | Item, option, prices, and their relationship | Menu review may require manual rebuilding. |
| Availability | Second item marked unavailable | Item and recognizable availability status | A menu list may not reflect what can be ordered. |
| Sale | $14 before discount; $1 discount; $13 sale | Item detail, discount, final amount, and sale ID | A total alone cannot explain the discount. |
| Refund and staff | $4 refund by fictional manager | Refund amount, sale reference, and action attribution | Manager cannot reliably trace the adjustment from the file. |
First, check that each record is present. Then check the values and relationships. Does the sandwich appear with its cheese option, or does the file contain only a $14 line? Does the refund refer to the original sale? Can you distinguish the cashier who made the sale from the manager who handled the refund?
Suppose a vendor exports the $9 net value but omits the separate refund and its link to the sale. The arithmetic is still correct, but the file does not meet a requirement to trace adjustments. If that requirement is essential to the owner, the export should fail acceptance unless the vendor demonstrates another usable way to obtain the missing detail. If the restaurant only needs a net summary for this task, the same file may be sufficient; write down that narrower requirement.
Do not assume an unfamiliar column is wrong. Ask for its definition, including how discounts, refunds, and timestamps are represented. Save the vendor's explanation with the fictional file. If the screen and export disagree, record both values and ask which one should be used and why.
Set an acceptance checklist before selecting a POS
Turn the demo into a pass-or-fail checklist based on your own needs. Complete it for each vendor using the same sample and the same required fields. A polished demonstration should not outweigh a missing field that your team needs every week.
- Define the minimum. List the records, fields, relationships, file formats, roles, and export frequency your restaurant requires. Separate must-haves from preferences.
- Run the sample. Ask an authorized demo user to export the fictional menu, sale, refund, and staff actions. This is a simulation: it should not process a real card payment, message a guest, or dispatch a courier.
- Inspect and reconcile. Open each file, match it to the on-screen sample, and check the amounts and links. Record missing fields, unclear labels, and any manual steps.
- Confirm ongoing access. Get written answers on permissions, frequency, history limits, support dependencies, and any export-related charges for the quoted setup.
- Decide and retain only the sample. Mark each requirement passed, failed, or unresolved. Keep fictional files and written answers in a controlled location; do not collect real guest or employee records for the comparison.
An unresolved requirement is not a pass. Ask for a second demonstration or written commitment that addresses it, and decide whether the answer arrives in time for your purchase. If a workaround is acceptable, document who will perform it and how often. A manual weekly download may suit a small operation; it may be a poor fit if several managers need timely detail across multiple locations.
Compare the quoted operating costs as well as the export result. Ask what is included in the subscription and what support or add-on charges could apply. A quoted processing fee is not the same as the all-in cost of operating the system. Use the related buying guide to frame that wider cost discussion.
For a Fleksa evaluation, request a demo with the fictional scenario and ask the team to document the export outcome, permissions, limits, and any relevant charges for your setup. Bring your checklist and compare the returned sample with your requirements before deciding.
Frequently asked questions
Is a sales report the same as a transaction export?
Not necessarily. A report may summarize totals, while a transaction export may provide individual items, discounts, refunds, and identifiers. Ask to inspect both and choose the detail your team needs.
Should I use real orders to check an export?
No. Fictional orders and invented staff IDs are enough to check whether fields and relationships appear. Agree on a simulation that creates no real payment, guest message, or courier dispatch.
What if a vendor says an export is available on request?
Ask who makes the request, how long fulfillment usually takes, what fields and date ranges are available, and whether a charge applies. Decide whether that process meets your routine needs while you remain a customer.
