Evaluate a computerised accounting conversion
Recommend whether a conversion is ready by weighing accuracy evidence, continuity, cost, control and the needs of system users.
Exam scope and assessment notes
Cambridge International AS & A Level Accounting 9706, 2026–2028 syllabus, Version 2. These lessons cover the process of transferring business accounts to a computerised accounting system and ways to maintain data integrity during conversion. No specific accounting application is required. Practice is self-checked, not an official Cambridge grade. Full timed Papers 1–4 and human subject-teacher review remain outstanding.
Before you begin
- Use the Topic 1.2 accounting-system skills: understand double entry, trial balances, control accounts, source documents and why complete records matter.
Work on paper. Try each question before revealing help, and explain why your method works.
Quick readiness check
Which is evidence that a conversion is ready?
What you will learn
- Assess conversion benefits and risks using evidence
- Apply stop/go criteria to unresolved issues
- Recommend proportionate safeguards and post-go-live measures
Assess readiness from controls, not optimism
A computerised system may improve processing speed, search, reporting and access to current information, but those benefits depend on accurate migration, suitable configuration, trained users and reliable controls. A conversion creates risk of data loss, misclassification, duplicate or missing entries, service interruption and unauthorised access.
Before go-live, examine reconciliation results, test evidence, exception severity, staff readiness, backup restoration and fallback arrangements. A critical unexplained balance, failed access control or untested recovery route may justify delay even when the project is over budget or near its deadline.
Set measures for the first period
After go-live, monitor rejected records, reconciliation differences, correction journals, delayed payments, customer disputes and close time. Compare results with the source system or pre-conversion baseline where possible. Assign owners and dates to resolve recurring issues.
A proportionate recommendation distinguishes a critical go-live blocker from a low-risk formatting issue, explains the cost of delay and names safeguards. State what must be true before launch and how remaining risks will be monitored; do not promise that software removes accounting errors.
Pause and explain
What should be monitored after go-live?
Worked example
A conversion has reconciled balances, but staff have not been trained and backup restoration has not been tested. Make a reasoned go/no-go recommendation.
Show the worked solution
- Balanced balances are positive evidence, but users may create errors if they cannot follow the new workflow.
- An untested backup leaves continuity uncertain if data is damaged or the system fails.
- Delay or limit go-live until essential user training and a restore test pass; then monitor the first close.
Answer Do not fully go live yet. Complete essential training and test recovery, confirm approval and then monitor the first close under an agreed plan.
Try a topic test
Choose Easy, Normal or Difficult. Save your answers and open worked review after finishing.
Test this topic →From guided practice to a new situation
Write your answer and reasoning first. Use a hint only if you are stuck. The model solution is for self-checking; your written work is not automatically marked.
The migration passes trial-balance checks but the source backup cannot be restored. State a decision and a practical next step.
Give me a hint
The records may balance, but the recovery plan is unproven.
Compare my reasoning
- Do not approve unrestricted go-live while recovery capability is unknown.
- Test restoration to a controlled environment and confirm the restored copy is complete and readable.
- Record the result, retain an alternate source copy and obtain authorised approval before relying on the new system.
Delay full go-live until a restore test passes or a verified alternative recovery plan is approved.
Look for these in your work
- Do not approve unrestricted go-live while recovery capability is unknown.
- Test restoration to a controlled environment and confirm the restored copy is complete and readable.
- Record the result, retain an alternate source copy and obtain authorised approval before relying on the new system.
Compare these proposals: A delays go-live one week for reconciliation and training costing $8,000; B launches now but has a 1-in-5 chance of a $60,000 disruption. Calculate B's simple expected disruption cost and explain one limitation.
Give me a hint
Multiply probability by loss, then compare with delay cost cautiously.
Compare my reasoning
- Expected disruption cost = 1/5 × $60,000 = $12,000.
- The simple expected cost exceeds the $8,000 delay cost by $4,000.
- The estimate ignores non-financial effects, risk severity, probability uncertainty and any benefits from launching sooner.
Simple expected disruption cost is $12,000, $4,000 above the one-week delay cost. The probability estimate and non-financial impact still need review.
Look for these in your work
- Expected disruption cost = 1/5 × $60,000 = $12,000.
- The simple expected cost exceeds the $8,000 delay cost by $4,000.
- The estimate ignores non-financial effects, risk severity, probability uncertainty and any benefits from launching sooner.
A small firm cannot fund a long parallel run. Recommend a proportionate conversion-control package that protects integrity without assuming unlimited staff or budget.
Give me a hint
Prioritise backups, risk-based testing, complete reconciliations, independent sign-off and close monitoring.
Compare my reasoning
- Secure and verify a source backup; define a documented cutover and fallback plan.
- Run a test import, reconcile all control totals and high-risk subledgers, and trace a risk-based sample of transactions.
- Use independent approval, retain exception logs and monitor the first close; extend parallel comparison only for the highest-risk processes if a full run is unaffordable.
Use a verified backup and fallback, a controlled test import, full key-balance reconciliations, risk-based record testing, independent approval and first-close monitoring. Target parallel testing at high-risk processes if resources are limited.
Look for these in your work
- Secure and verify a source backup; define a documented cutover and fallback plan.
- Run a test import, reconcile all control totals and high-risk subledgers, and trace a risk-based sample of transactions.
- Use independent approval, retain exception logs and monitor the first close; extend parallel comparison only for the highest-risk processes if a full run is unaffordable.
Common mistakes
- Treating software purchase as proof of improved accounting quality
- Ignoring training, backup restoration or user access
- Failing to distinguish a launch blocker from a manageable exception
What can you explain now?
What is a sound basis for a go-live decision?
Compare with the explanation
Pre-agreed controls, reconciliations, user readiness and recovery evidence
A date or vendor assurance cannot replace evidence that records, people and recovery procedures are ready.
After trying it yourself, choose your next review. This is your self-assessment.
Your review choice appears on Today. Sign in to sync it across devices.
Make it stick
What evidence and safeguards should appear in a brief conversion go/no-go recommendation?
If you needed the solution, close it and solve the problem again from a blank page. A correct answer is stronger when you can explain the reason for each step.