Prepare opening balances, customer-device mappings and a clear cutover when moving a shop’s qist register into a software workflow.
Moving a mobile shop’s installment register into software is an opening-balance exercise before it is a device-enrollment exercise. A neat digital list can still be wrong if it includes a receipt twice or loses the link to a financed phone. Prepare the account records first, and confirm the supported migration process with the chosen provider.
Choose a cutover and preserve the source
Pick a clearly recorded date and time after reconciling that day’s receipts. Keep the original register available for review. Decide where new receipts will be entered after cutover so staff do not update two competing live balances. Do not delete the source simply because records appear in a dashboard.
Prepare one row per agreement
| Field | Why it matters |
|---|---|
| Agreement reference | Distinguishes repeat customers and multiple phones. |
| Customer reference | Connects questions to the correct record. |
| Device identifier | Maps the agreement to the actual handset. |
| Agreed amount and down payment | Explains the starting financed balance. |
| Reconciled receipts to cutover | Prevents duplicate counting of earlier payments. |
| Remaining balance and due schedule | Defines the next collection task. |
| Open exception and owner | Keeps unresolved amounts visible. |
Keep only the information needed for the workflow and restrict access to source records. Ask the provider for the actual import fields and supported transfer method. A spreadsheet prepared for review does not establish that a bulk import, bank connector or automatic migration feature exists.
Check the balance with a PKR example
Illustration only: an agreed phone sale of PKR 60,000 less a received PKR 15,000 down payment leaves PKR 45,000. If another PKR 15,000 has been received and reconciled before cutover, PKR 30,000 remains, assuming no other charges or adjustments. Entering PKR 45,000 as the opening outstanding amount would count those later receipts incorrectly.
If PKR 5,000 is received but its intended agreement is unclear, keep it in the unmatched-payment record rather than guessing. Resolve which account it belongs to and preserve the allocation evidence. The total received and total allocated should be explainable across the migration, not just within each screen.
Separate migration from enrolling existing phones
Creating an account record does not enroll a device already in a customer’s hands. Confirm model compatibility, required customer participation and the agreed device-management terms. Do not assume that adding an IMEI enables remote control. Plan any enrollment with the customer and authorized business owner.
Reconcile a small sample before the full cutover
Include a fully current account, a partial payment, two agreements for one customer, an unmatched receipt and a settled account awaiting release. Compare each prepared balance and due date with the source. Ask a different staff member to follow the evidence so the process does not depend on the person who built the sheet.
Define corrections and closure
Give each migration exception an owner and keep a record of approved corrections. Tell staff which system is authoritative after cutover and how they should answer a customer whose paper receipt differs from the new balance. Confirm final settlement and release separately; a zero opening balance is not proof that a managed device has been released.
Connect the corrected opening records to your ongoing counter routine.Build the retailer handover processarrow_forwardUse the reconciliation guide to resolve receipts before migration.Handle unmatched and partial paymentsarrow_forwardMap the installment ledger and device-management responsibilities before choosing a transfer method.Define system ownershiparrow_forward
