Stage one: analysing processes and defining scope
Before any setup in the system, sit with each department and map its current processes: how are purchases requested? How are invoices issued? Who approves what? And which reports are used today? Then decide what must change, because implementation is an opportunity to simplify processes, not to copy them as they are. This stage produces a clear scope document that defines: • The modules to be implemented in the first phase, such as finance, purchasing and inventory. • The companies, branches and warehouses included. • The systems to be integrated, such as payroll, the online store and e-invoicing. • The reports required from day one. Any request that appears later outside this scope is assessed and scheduled, rather than delaying the whole project.
Stage two: design and configuration
In this stage the analysis outputs become settings in the system, the most important being: • The chart of accounts, cost centres and analytical dimensions. • The financial year and accounting periods. • VAT codes and their link to return boxes. • Approval workflows and the authority matrix. • User roles and permissions. • Document templates, such as invoices and purchase orders, in line with e-invoicing requirements. Key design decisions should be approved in writing by the business's decision-maker, because changing them after go-live is much harder and more costly, especially for the chart of accounts and dimensions.
Stage three: cleaning data before migration
The data moving to the new system is of two kinds: master data and balances. Master data includes customers, suppliers, items, assets and employees, and it needs the most cleaning effort. Typical cleaning work includes: • Removing duplicates, such as a customer recorded under two different names. • Completing VAT numbers and national addresses for customers and suppliers. • Standardising item names, units of measure and categories. • Deactivating inactive records instead of migrating them. • Verifying suppliers' bank account details. The golden rule: do not migrate data you do not trust. The new system will not fix it; it will only spread its errors faster.
Opening balances: what to migrate and how to verify it
The most common option is to migrate balances as they stand on the go-live date, not the full transaction history. This usually includes: • The closing trial balance at account level. • Customer and supplier balances at the level of open invoices, not just the total, so that ageing and collections work from day one. • Inventory quantities and cost for each item and warehouse. • The fixed asset register with cost and accumulated depreciation. After migration, reconcile every balance with its source: the trial balance with the old system, customer details with their control account, and inventory with the latest count. Go-live does not start until the finance manager signs off these reconciliations.
Choosing the go-live date
The best go-live date is usually the start of a financial year, because opening balances have been audited and annual reports are not split between two systems. But waiting for the start of the year is not always necessary; the start of any month is a practical option, provided the previous month is fully closed in the old system. As far as possible, avoid: • Going live in the middle of a month. • Going live in the business's busiest season. • Going live a few days before a tax return deadline. • Going live before balance reconciliation is complete. Set a clear plan for the first operating period: who supports users, how issues are logged, and when progress is reviewed. The first weeks shape the team's impression of the system, and an issue solved the same day does not become a reason to go back to the old files.
Testing: rehearse your business before running it
Testing is not checking that screens work, but running your business's real scenarios end to end in a test environment, such as: • A complete purchase cycle from request to payment, including a quantity difference. • A credit sales cycle with a credit note and partial collection. • An inventory transfer between two branches and a count with differences. • Issuing an e-invoice and sharing it according to FATOORA requirements. • Closing a trial month and producing the income statement and the VAT return. Testing should be carried out by the actual users, not only the implementation team, because they are the ones who will spot what does not fit their daily work.
Training and change management
The biggest threat to a new system after go-live is staff returning to side files because they are familiar. To prevent this: • Train each user on their actual role and scenarios, not on every screen in the system. • Prepare short guides with steps and screenshots for every recurring task. • Appoint a proficient user in each department as a go-to person for colleagues. • Retire the old tools on an announced date, because keeping them available means they will keep being used. • Explain to the team why processes changed, and what each of them gains. A system whose benefit staff understand gets used; one imposed without explanation is quietly resisted.
A checklist before go-live day
Before announcing go-live, make sure of the following: • Chart of accounts, tax and permission settings are approved. • Master data cleaning and migration are complete. • Opening balances are reconciled and signed off. • Key test scenarios have passed, including e-invoicing. • All users are trained and have received their accounts. • The last period in the old system is closed, and a copy of it is kept for reference. • There is a clear support plan for the first weeks. If a material item on this list is not complete, delaying go-live by a few days is better than a go-live that takes months to repair.
Frequently asked questions
Should we run the old and new systems in parallel? A short parallel run may help verify results, but it doubles the team's workload, so it is usually better to rely on good testing and a period of intensive support. What do we do with historical data? It is kept in the old system or in a searchable archive, in line with statutory record retention periods, including six years for invoices and tax records according to ZATCA's guidance. What determines implementation cost and duration? The number of modules, companies and branches, the amount of customisation required, the number of systems to be integrated, and above all the quality of current data and how much time the business's team can dedicate to the project. Who leads the project inside the business? The project needs a leader from within the business, usually the finance manager, with decision-making authority and dedicated time for the project.
Conclusion
Successful finance system implementation is built on a clear scope analysis, an approved design, clean data, reconciled opening balances, testing with real scenarios, and training that makes the team embrace the system. Every stage done well saves many times its duration after go-live. At Shams Solutions, we accompany businesses in implementing finance and ERP systems from the start to beyond go-live, from process analysis and configuration design to data cleaning and migration, e-invoicing integration, training and support. Contact us to review your business's setup and agree on the right next steps.