Migrating from Tally or manual register to RetailPOS
Last reviewed 2026-05-27 · by the RetailPOS team
The most common Pakistan retail migration looks nothing like the US/UK Square-to-something move. It's manual cash register + Tally ERP for accounting + Excel for item lists → modern cloud POS like RetailPOS. The shop owner has been running this combination for years; Tally holds the historical sales + customer balances, Excel holds the item catalog, the cash drawer is a physical box with a notebook reconciliation. Moving to a single integrated POS is the goal; the path needs to be careful enough that the migration doesn't disrupt daily operations.
This guide walks through the migration step by step: exporting from Tally (the format, the gotchas), preparing the item catalog CSV, importing customers with opening balances, opening-stock entry, the cutover plan (parallel-run vs hard cutover), FBR e-invoicing switchover for tier-1 retailers, and the common mistakes that cost the first week of operations.
Before you start — what to keep, what to leave behind
Pakistani retailers running Tally typically have years of historical transaction data in the Tally company file. The instinct is to migrate everything; the reality is most of it shouldn't move.
What to move into RetailPOS:
- Current item catalog (active SKUs only)
- Current customer master with outstanding balances
- Current supplier master with outstanding balances
- Opening stock as of cutover date
- Tax classifications + GST registration numbers
What to keep in Tally (or archive):
- Historical sales data older than current FY
- Closed-out customer + supplier balances
- Inactive SKUs
- General-ledger entries (accounting stays in Tally for the financial close)
The point: RetailPOS becomes the source of truth for retail operations going forward; Tally remains the historical-archive and the back-end accounting system (your accountant continues to use Tally for the books). The two integrate via period-end exports rather than real-time sync — simpler, cleaner, and matches how most Pakistani retail accountants want to work.
Exporting items from Tally
Tally's stock-item export is the cleanest source for the catalog migration. From Tally:
- Display → Statements of Inventory → Stock Summary
- F12 Configure: show all detail columns, set period to current year
- Alt+E to export → Format: Excel (or CSV)
- Export the file to a known location
The exported file typically has columns: Stock Item Name, Group, Unit, Opening Stock, Closing Stock, Standard Cost Rate, Standard Selling Rate, GST Rate. Some shops have additional columns for category + sub-category + HSN code.
Clean the file in Excel before importing to RetailPOS:
- Remove inactive items (zero closing stock + no recent sales)
- Standardise the unit column (Tally allows free text; the POS needs consistent values like “PCS”, “KG”, “LTR”)
- Verify the GST rate column matches each item's actual tax class
- Add a barcode column if your shop scans items (manual entry from your scanner or supplier-provided barcodes)
- Add a category column if Tally doesn't carry one (Stationery, Mobile Accessories, etc.)
Aim for 80-90% accuracy at import time; correct the remaining 10-20% in RetailPOS after migration as you see them in daily operation. Trying to get 100% before import delays the migration without proportional benefit.
Importing the catalog into RetailPOS
RetailPOS' CSV import accepts: name, sku, barcode, category, unit, cost_minor, price_minor, tax_class, opening_stock, opening_stock_value. Map the Tally export columns to these via the import preview screen; the import validates row by row and reports errors before committing.
For prices, RetailPOS stores money as integer minor units (paisas for PKR); the import converts your Tally rupee+paisa values automatically. Verify the preview shows your prices correctly (PKR 199.50 imports as 19950 paisa not 1995 or 199500).
Tax-class mapping is the part that needs care. Pakistan's federal + provincial GST + special rates create more tax classes than typical international POS setups. RetailPOS supports the full Pakistan rate set; map each item to its rate carefully (the wrong rate flows through to FBR e-invoicing later — a mistake here is harder to fix once invoices have been submitted).
For multi-shop operations, import once into the master catalog; per-location stock + per-location price overrides set up after the master import. This avoids duplicating the catalog for each shop.
Customers + opening balances
From Tally: export the customer master with outstanding balances. Display → Statements of Accounts → Outstandings → Receivables; Alt+E export to Excel.
Clean the file: remove closed-out customers (zero balance + no recent activity), standardise the phone number format (Pakistan: 03XX-XXXXXXX), add the CNIC if you capture it (important for AML compliance in jewellery + high- value retail, optional elsewhere).
Import customers via the RetailPOS customer-import flow with the outstanding-balance column populated. This creates the customer record with the opening balance pre-set; future sales accrue on top.
For loyalty: Tally typically doesn't track loyalty points (it's an accounting system, not a CRM). If you've been tracking loyalty informally — a notebook, a spreadsheet, customer memory — capture the current balances at cutover and import as opening loyalty points. Customers will appreciate not losing accrued points in the transition.
Opening stock + the inventory reconciliation step
Your Tally closing-stock value as of cutover date is the opening stock for RetailPOS. The catalog import covers the per-SKU opening stock; what's usually missing is the location-level allocation if you operate multiple shops.
The reconciliation step: physical stock count on cutover day, compared against the Tally closing stock + any movements since. Variances are normal (manual register + Tally aren't perfectly synchronised; you'll usually find 2-5% variance). Adjust opening stock to match the physical count rather than to match Tally — the POS' stock from this point forward should reflect reality on the floor.
Variance journal: post the variance to Tally as a stock-adjustment entry for the books; the financial impact lives in Tally, the operational truth lives in RetailPOS going forward.
The cutover — parallel-run vs hard cutover
Two cutover strategies:
Hard cutover — pick a date (typically a Sunday or after close on a low-volume day), do the final Tally closing-balance, import to RetailPOS, start fresh on RetailPOS the next morning. Tally stops accepting new retail entries from that date. Cleanest; fastest; most common for single-shop or small operations. Risk: a missed configuration surfaces on day-one of live operations.
Parallel run — operate both systems simultaneously for 1-2 weeks; ring sales on RetailPOS, also record in Tally (or import from RetailPOS into Tally daily). Verify the two reconcile each evening. Switch off Tally for retail entries at the end of the parallel period. Slower; more operational overhead; safer for larger operations or shops with complex tax/discount setups.
RetailPOS' recommendation: hard cutover for single-shop or 2-3 shops; parallel-run for 4+ shops or complex multi-location pricing. The cost of parallel-run is the duplicate-entry time; the cost of hard-cutover is the on-day-one risk. Pick based on your team's capacity for the duplicate- entry vs your tolerance for live troubleshooting.
FBR e-invoicing switchover for tier-1 retailers
If you're a tier-1 retailer (PKR 1 crore revenue or 1,000+ sqft or mall location), you were already on FBR e-invoicing in some form before the migration (or were supposed to be). The switchover:
- Pause FBR submissions on the old POS or PSI relationship the night before cutover.
- RetailPOS' onboarding pre-registers your tills with FBR using the device-registration flow (3-10 business days lead time before cutover).
- On cutover day, the first sale rings on RetailPOS with FBR integration live; the FBR Invoice Number sequence continues uninterrupted.
- Verify the first 5-10 invoices appear correctly in FBR's portal; if so, the cutover is clean.
Common mistake: forgetting to terminate the old PSI relationship after cutover. The old PSI may continue to bill you for connector access until explicitly cancelled. Cancel within the first week post-cutover.
First-week operational adjustments
The first week post-cutover is the calibration window. Expect:
- Catalog gaps: items missed in the export, items mis-categorised, prices off by a paisa or two due to rounding. Fix as you find them; the POS' bulk edit + CSV update flow handles fast correction.
- Cashier confusion: new till UI takes a week to feel natural. Schedule a quick-reference card next to each till for the first week (mobile money keys, refund flow, manager override). RetailPOS' cashier training videos can be played during slow hours.
- Tax-class corrections: a few items will turn out to be on the wrong tax class; FBR will accept the corrected reporting on the next return cycle.
- Stock variance: another physical count after 1-2 weeks to confirm the opening stock + sales-side decrements + supplier-receiving are flowing correctly.
- Customer-balance questions: regulars asking about their outstanding balance; the customer-search flow on the till surfaces it quickly.
Most shops are running cleanly within 10-14 days. Past 14 days, the daily workflow is faster than the Tally + manual register combination, the FBR integration is invisible, and the multi-shop visibility (if applicable) replaces the previous evening-call-to-each-branch routine.
Frequently asked
- Will RetailPOS replace Tally entirely?
- For retail operations — yes. For full general-ledger accounting — most Pakistani shops keep Tally for the books and integrate via period-end exports. RetailPOS handles the retail side end-to-end; the accountant's journal entries continue in Tally.
- How long does the migration take end to end?
- Typical small-to-mid shop: 1-2 weeks total. Day 1-3 catalog + customer export and cleanup; day 4-7 import + validation; day 8 cutover; day 9-14 calibration. Larger operations or multi-shop: 3-4 weeks with parallel-run.
- Do I lose my historical sales data?
- No — Tally retains the historical data; RetailPOS becomes the source of truth going forward. Pre-cutover historical reports run from Tally; post-cutover reports run from RetailPOS. The two periods don't need to merge for most operational purposes.
- My catalog has 10,000+ SKUs — is import feasible?
- Yes. RetailPOS' CSV import handles tens of thousands of rows per file; validation runs row by row with clear error reporting before commit. Larger catalogs (50,000+) work fine; staging in smaller batches by category often makes troubleshooting easier.
- What about FBR e-invoicing during the transition?
- Pre-register tills with FBR 3-10 business days before cutover. On cutover day, FBR integration is live from the first sale on RetailPOS. Pause submissions on the old POS the night before; verify first invoices in FBR's portal post-cutover.
- Hard cutover or parallel-run?
- Hard cutover for single-shop or 2-3 shops (fastest, cleanest); parallel-run for 4+ shops or complex tax/discount setups (safer, more operational overhead). RetailPOS' onboarding team will recommend based on your specifics.
Open your shop in 30 seconds.
No card. Free until your first 100 sales. Bring your own Stripe; keep your hardware.