Most ERP and accounting-software decisions start the same way: a supplier is invited in, shows a demonstration, and the business decides whether it liked what it saw. That is a comparison of presentations, not a comparison of systems, and it is a common reason an implementation ends up being reconfigured not long after going live.
The fix is not a longer demonstration. It is a written requirement, drawn up before any supplier is in the room, against which every answer can be compared on the same terms.
Start with what the business actually needs the system to do
Before anything else, write down what the current system cannot do, and what the business will need it to do in two to three years, not just today. Outlet count, product range, a new line of business, a second currency, a second country — a system sized for the business as it is now will not stay adequate for long.
This brief does not need to be long. It needs to be specific enough that a supplier's answer can be judged against it, rather than against how confident the answer sounded.
What deserves evaluation, module by module
Accounting and financial controls. How the chart of accounts is structured, whether a period can be locked once it is closed, and who can post to it after that. A system that allows a closed period to be reopened without a trace of who did it and when is a control gap dressed up as convenience.
Inventory. Costing method, how stock movements are recorded at the point they happen rather than reconstructed later, and whether the system can handle the business's actual complexity — multiple warehouses, goods in transit, consignment stock, expiry dates where relevant.
Purchasing. Whether a purchase order has to exist before a goods receipt, whether a goods receipt has to exist before an invoice is posted, and whether the system enforces that sequence or merely allows it.
Sales and branch operations. How a multi-outlet business consolidates sales across locations, and whether pricing, discounting and returns are controlled centrally or left to each branch to configure for itself.
User rights and approvals. Who can change a price, approve a purchase above a limit, or post a journal — decided by the system's settings rather than by policy on paper. This is worth testing directly during evaluation: ask the supplier to show you the access-control screen, not describe it.
Audit trail. Whether every material change is logged against a user and a timestamp, and whether that log can be edited or cleared by anyone. A system without a genuine audit trail is a system an auditor, and eventually a court, will trust less.
Tax and localisation. Sales tax on goods and sales tax on services sit with different authorities in Pakistan and are configured differently. Withholding obligations, digital invoicing requirements where they apply, and the treatment of provincial versus federal sales tax all need to be built into the system's configuration, not bolted on afterwards in a spreadsheet.
Reporting. Ask for the actual reports the finance function will need monthly — not a features list, the reports themselves, run against sample data. A system that reports beautifully in a demonstration and requires an export to Excel for the report management actually reads every month has not solved the problem it was bought to solve.
Data migration is a project of its own
Opening balances, stock quantities, price lists and customer and supplier histories all have to move from the old system to the new one, and someone has to decide what is reconciled after the move and what is deliberately left behind in the old system for reference. Migration that is treated as a task inside the implementation, rather than as a project with its own plan and its own sign-off, is where a great many go-live dates slip.
Integration and what happens if the vendor is no longer there
Ask what the system integrates with today — banking, e-commerce, a point-of-sale application — and how. An integration built on a one-off script maintained by a single person at the vendor is a dependency the business does not see until that person leaves.
It is also worth asking, plainly, what happens to the business's data and its ability to keep operating if the vendor stops trading or stops supporting the product. The answer should exist before the contract is signed.
Total cost, not licence price
The licence or subscription fee is usually the smallest figure in the decision. Implementation, data migration, customisation, training, and the internal time spent by the business's own staff during the project are frequently larger, and are the numbers most often left out of the comparison between candidate systems. Ask every supplier for these figures on the same basis, not just the licence quote.
What management should do
- Write the requirement down before any supplier demonstration, and size it for where the business will be in two to three years.
- Compare candidates against that written brief, not against how well each demonstration was delivered.
- Test access controls and the audit trail directly rather than accepting a description of them.
- Confirm the tax and localisation configuration for sales tax on goods, sales tax on services and withholding before the contract is signed.
- Treat data migration as its own project, with a reconciliation and a sign-off step.
- Ask every supplier for the total cost of implementation, migration, customisation and training, not the licence fee alone.
- Get the recommendation, and the reasoning behind it, in writing before committing.
A system chosen this way costs more to compare up front and considerably less to live with afterwards. This is the same written-brief-first approach we use in our ERP advisory work — comparing candidate systems against a requirement rather than against a demonstration, and staying independent of whichever vendor wins. If a system is about to be chosen, or an existing implementation has stalled, tell us what the business does and roughly where it is in the process, and we can set out what a written brief for it should cover.
This note is general information, not advice on your particular circumstances. Tax law and deadlines change — please confirm the position before acting on it.