POS data export checklist: prove you can use the files

Ask for a file set, not a promise about “all data”

Start with the records your shop needs to operate and explain its history. Mark each as needed in the new POS, needed only as a readable archive, or not required for the move. Those outcomes are different: an old receipt can remain searchable in an archive even when it cannot become an editable transaction in the replacement system.

Prove the identifiers survive a small rehearsal

Use a copy of a small representative dataset and the intended import template. Include a barcode with leading zeros, two variants with similar names, an accented product name and an item stocked at two locations. Compare the identifiers and quantities after import. A file that opens without an error can still map two different items to the wrong record.

Shopify’s product CSV documentation identifies a separate inventory CSV for multi-location quantities. Square’s item-library export distinguishes all items from items matching selected filters. These documented examples show why the words “product export” are not enough: inspect the scope and columns of the exact file you receive.

Reconcile a known day before accepting the export

Choose one trading day that contains an ordinary sale, a discount and a return. Write down the expected count and totals from the original report, along with its time zone and day boundary. Rebuild that small result from the exported records. Ask the provider to explain any difference between a sales total, a payment total and a refund total rather than assuming they measure the same thing.

Keep a record count as well as a money total. Two missing sales and an unrelated duplicate could produce a plausible-looking sum. Check a few receipt identifiers back to the source and confirm how voided or canceled transactions appear. Use this as an acceptance test for your files, not a claim that every provider exports the same format.

Keep the historical archive separate from opening balances

Decide how much history the new system truly needs. Product setup, current stock and outstanding customer obligations may need an operational import, while older sales may need a separate archive. Avoid importing historical sales in a way that unexpectedly changes today’s stock or re-creates amounts already paid. Have the destination provider explain what each import creates.

Save an untouched copy of every original export, a separate working copy and a short mapping document. Limit access to people who need the customer or staff information in those files. Confirm the records and retention arrangements your own business requires before closing the old account.

Agree the final handoff and the exit conditions

Record who creates the last export, when staff stop editing the old catalog, who checks the imported totals and where unresolved items are listed. Ask whether archive access remains after cancellation, what export options remain available and what must be saved first. VoVi’s terms describe data ownership and CSV export; the same practical sample-file test still belongs in a VoVi evaluation.

The outcome is a short acceptance record: files received, fields understood, sample records matched, totals explained, opening balances approved and an archive that opens independently. That record is more useful on moving day than a broad assurance that migration is easy.