Before choosing restaurant software, get a written answer to one exit question: after your subscription ends, what records can you still see, download, and recover—and for how long? A vendor keeping data on its servers does not necessarily mean you can open your dashboard or export a usable file.
Compare the restaurant software vendor data retention policy alongside the contract and any exit quote. Ask for specific deadlines, file formats, fees, and restrictions. Then test a sample export while your account is active. Your goal is a record you can find and use later, not merely a promise that data is retained.
List the records you need after exit
Start with the questions someone at your restaurant may need to answer after the old system is gone. Can you trace an order that a guest disputes? Explain a sales total to your bookkeeper? Find the reservation history needed to resolve a question? The answers determine which records and fields matter.
Make an inventory by workflow, rather than assuming one sales report covers everything:
- Orders: order ID, date and time, channel, items, adjustments, status, and payment status where available. Ask whether canceled and refunded orders are included.
- Reports: daily and shift summaries, the definitions behind their totals, and any saved report settings you rely on. A PDF summary and a row-level export serve different purposes.
- Guest and reservation data: contact details, reservation dates and status, and any notes you have a legitimate reason to retain. Check whether the export includes notes or only basic fields.
- Configuration: menu items, prices, modifiers, and location settings that could help you rebuild a setup or understand an old order.
Keep order source separate from dining option. A direct online order, for example, might be for pickup or dine-in; those fields answer different questions. Likewise, a deposit is not automatically the same measure as a sale. Ask the vendor to define each field and total before comparing reports.
Fleksa's partner portal provides dashboard, order, menu, and reservation views, with available views and configuration varying. If those workflows matter to you, include them in your restaurant management software review. Ask which records and exports are available for your setup and what happens to them at cancellation.
Also map records held elsewhere. A restaurant POS system, payment provider, reservation tool, and accounting system may each hold different parts of a transaction. An export from one does not necessarily replace records from the others. Assign an owner to collect each set before access changes.
Compare deadlines, formats, and retrieval costs
Ask for dates tied to a clear event: notice of cancellation, the subscription end date, or account closure. These are not always the same day. Record the last date for normal dashboard access, the last date for self-service export, and the point after which the vendor may delete or anonymize records. Ask whether backups follow a different schedule.
Then separate three kinds of access. Viewing lets you inspect a report. Exporting gives you a file to keep. Retrieval means asking the vendor to recover or provide data after ordinary access ends. A long retention period is less useful if retrieval is slow, expensive, or limited to a format you cannot use.
For each option, ask whether exports are CSV, spreadsheet, PDF, or another format; whether they include field names and definitions; and whether you can download all locations and date ranges. Check if attachments, report filters, and deleted or amended records are included. Ask who can request a copy and how the vendor verifies that person's authority.
The following worksheet compares two hypothetical quotes for the same restaurant. The owner needs order-level records for two locations and wants time to check them after cancellation. Both vendors offer an export during the subscription; neither quote should be treated as a claim about a named product.
| Decision item | Option A | Option B | Owner's assessment |
|---|---|---|---|
| Post-end access | Read-only dashboard for 30 days; export available | Dashboard closes at end; request a file within 60 days | A gives staff time to compare a file with the dashboard |
| Export format | CSV order rows and PDF summaries | CSV order rows on request | Confirm fields and both locations in either sample |
| Quoted exit cost | $40 fixed export charge; no quoted variable or exception charge | $0 fixed charge plus $15 per location; $25 exception retrieval charge | For two locations and one exception, A is $40; B is $55 |
| Acceptance condition | Sample totals reconcile and files open | Sample totals reconcile and delivery deadline is written down | Choose only after the sample and terms meet the requirement |
In this example, Option B's calculation is $0 + (2 × $15) + $25 = $55. The comparison includes the quoted fixed, per-location variable, and one exception charge. It excludes subscription charges, staff time, storage, and any unquoted costs. On these assumptions, A has the lower quoted exit cost and provides a useful checking window. That is a reason to prefer A for this requirement, not proof that it is the cheaper system overall.
Get the fee schedule in writing. Ask what triggers an exception charge, whether a second request costs more, and how long delivery takes. If a quote says access is included, confirm whether that means a usable export or only continued viewing.
Test an export against a dashboard total
Make the acceptance test a condition of your buying decision or onboarding plan. Use a sample file or a vendor-provided demonstration dataset. For practice, do not place a real order, charge a card, message a guest, or dispatch a courier. A simulated check tells you whether you understand the fields and arithmetic; it does not prove what will happen during a live cancellation.
- Set the scope. Pick one location, one date range, and one order status. Write down the dashboard filters, time zone, and definition of the total.
- Get the matching rows. Export or request the same scope. Open the file in a tool your team can use without the vendor's dashboard.
- Check the fields. Confirm that order IDs, dates, statuses, amounts, and adjustments are readable. Look for missing columns, duplicate IDs, and unexpected blank values.
- Reconcile the measure. Sum the relevant rows using the same definition as the dashboard. Investigate differences before treating either number as the final record.
- Save the evidence. Keep the file, a copy of the report, the filters, field definitions, and a short note explaining the result in a secure location.
For a separate hypothetical sample, suppose the dashboard shows $240 in completed order sales for one day. The export has three matching completed orders of $80, $95, and $65: $80 + $95 + $65 = $240. A fourth row is a canceled $20 order and is excluded from both sides. The acceptance result is a match only if the dashboard uses the same status, date range, and sales definition. These figures are sales measures, not deposits, processing fees, or operating costs.
If the totals do not match, check filters and definitions first. Does the report use order time while the file uses completion time? Are refunds shown as separate rows? Are amounts gross or net of discounts? Ask the vendor to explain the difference and provide a corrected sample or documented calculation. Do not mark the export acceptable simply because the file downloaded.
Write a pass or fail rule your manager can apply: for example, “The file opens without the old system, contains the agreed fields for both locations, and reconciles to the defined dashboard total.” Name the person responsible and set a deadline for resolving gaps. A later live service pilot can check actual operating workflows under agreed conditions, but keep it distinct from this simulated export exercise.
Set a retention and exit plan
Decide where the files will live, who can access them, and how the team will locate them. Use consistent file names with the location, date range, and export date. Store field definitions and report settings beside the data. Test that an authorized person can open the files from the chosen storage location, not just from the laptop that created them.
Guest records deserve particular care. Collect only what you need for a defined purpose, restrict access, and document when the restaurant intends to remove it. Ask the vendor how deletion requests, backups, and any vendor-held copies are handled after termination. Avoid assuming that deleting a local export also deletes the vendor's copy, or vice versa.
Retention obligations can depend on the record and your circumstances. Ask qualified local legal, tax, or accounting advisers which records to keep, for how long, and how to handle guest information. Record their guidance separately from the vendor's technical retention schedule: the vendor's deadline and your restaurant's obligations may not match.
Before giving notice, put the exit dates on a calendar with a buffer for failed downloads or corrections. Assign one person to request the data, another to verify the totals, and a final owner to confirm secure storage. Ask the vendor what support remains available after closure and who can authorize a retrieval. If you are also reviewing operating reports, the guide to comparing labor hours with sales by shift can help you identify definitions worth preserving.
Next step: Take your record inventory and acceptance rule to a vendor discussion. Compare your management requirements with Fleksa's available workflows, and request written answers on exports and post-subscription access for your setup.
Frequently asked questions
Does data retention mean I can still use the dashboard?
Not necessarily. Ask separately when dashboard access ends, when exports stop being available, and whether the vendor can retrieve a copy afterward.
Is a PDF report enough for an exit?
It may be useful for preserving a summary, but it may not contain the individual order rows or fields needed to investigate a discrepancy. Compare the PDF and a structured export against your record inventory.
When should I test an export?
Test a sample before committing where possible, then verify your actual records while the subscription is active and before any export deadline. Leave time to investigate mismatches and request corrections.
