Identify the problems the new system needs to address

Start by asking employees to show you how they complete their work. Include finance, operations and IT, along with the people who enter orders, receive goods and prepare reports. Each group will notice different problems.

Look for specific obstacles. Does month-end reporting depend on several spreadsheets? Do stock figures differ between locations? Can project managers see costs already committed through purchase orders? Record what happens, who is affected and why it matters.

Where possible, measure the current process. If closing the books takes eight working days, identify what takes the most time. Then agree on a realistic goal. Distinguish delays caused by software from those caused by missing information, unclear responsibilities or limited staff availability.

Microsoft’s guidance on defining requirements recommends connecting each requirement to a business process. This helps everyone understand the request and gives the team a way to test whether the complete process works.

Agree on what must be ready at launch

Not every request needs to be part of the first release. Give each requirement a priority and explain what would happen if it were left out. An invoicing requirement may be essential for trading; a preferred dashboard layout may be able to wait.

Assign a person responsible for each launch requirement. That person should explain the current process, answer questions during setup and confirm whether the result meets the agreed need. Also state which companies, departments and locations the project includes.

Keep a record of decisions and changes. Note what changed, why it changed and who approved it. Give every provider the same current document so you can compare proposals fairly. When a change affects cost or timing, agree on its impact before adding it to the project.

Define your accounting and Canadian tax requirements

Describe your legal entities, fiscal year-ends, account structure and reporting responsibilities. Explain whether transactions need to be grouped by branch, department, project or another category. Include examples of the financial statements your team uses.

List the sales tax situations your business encounters, including GST/HST, PST or QST where applicable. Have your finance team or tax adviser confirm the treatment you need. Ask providers to demonstrate relevant sales, purchases and credit transactions rather than assuming a Canadian software edition covers every case.

If you trade in more than one currency, explain how you record exchange rates and report foreign-currency balances. Include bank reconciliation, customer collections, supplier payments and transactions between related companies. If payroll remains separate, specify what must reach the general ledger and who will check the totals.

Write requirements in terms of an action and an expected result. For example: “The controller must be able to produce a monthly income statement by branch and open the entries behind each total.” This gives a provider something concrete to demonstrate.

Review orders, purchasing and daily operations

Follow a customer order from quotation through delivery, invoicing and payment. Identify who handles each step and what information they need. Then consider exceptions such as partial shipments, back orders, returns, cancellations and customers on credit hold.

Review purchasing in the same way. Explain how requests become purchase orders, how goods are received and how invoices are checked. Record approval limits and what should happen when an invoice price or quantity differs from the order.

For inventory, document your locations, item types, units of measure and replenishment rules. Note whether you need serial numbers, lot tracking, expiry dates, transfers or barcode scanning. Ask providers which functions are included and which require another application or additional work.

Service businesses should describe project budgets, time entry, expenses and billing. Manufacturers should explain production and planning requirements. Focus on the activities your business performs, including handovers between teams, rather than collecting features that sound useful but have no clear purpose.

Explain what each report needs to tell you

Choose reports that people rely on to make decisions. For each one, identify who prepares it, who uses it, what the figures mean and when it is needed. Provide a sample with confidential information removed.

Be specific about calculations and timing. Instead of asking for “real-time inventory reporting,” explain whether staff need available stock by location after reservations and open orders are taken into account. State how quickly changes need to appear.

Agree on definitions within your business. Finance and sales may calculate margin differently or use different dates to recognise a sale. Decide which definition each report should use before asking a provider to build it.

Ask which reports are included, which need configuration and which require extra licences or development. Confirm who can view, export and investigate the figures. If employees still need spreadsheets, explain why and decide how those files will be checked.

Plan how the ERP will connect to other systems

List the applications that will remain in use, such as customer relationship management (CRM), e-commerce, payroll, banking and shipping software. For each connection, record what information must move, its direction and how often it needs to transfer.

Decide where shared records will be maintained. If both CRM and ERP hold customer details, specify where a new customer is created and how later changes reach the other system. Assign responsibility for resolving conflicting or duplicate records.

Describe what should happen when a transfer fails. Who receives an alert? Can someone retry the transfer without duplicating an order? How will employees continue working while a connected service is unavailable? Include those situations in the demonstration and testing plan.

Ask providers to name the proposed connector, explain any subscription fees and identify who maintains the connection. Confirm responsibility for changes when either application is updated. Test with representative records and transaction volumes before accepting the integration.

Choose which records to move into the new system

Separate the information you need into customer, supplier and item records; opening balances; unfinished transactions; and historical records. Decide which categories belong in the new ERP and which can remain in an accessible archive.

Review duplicates, inactive items, missing details and inconsistent codes before migration. Assign people who understand the records to approve corrections. Agree on how migrated balances and transactions will be checked against the old system, and who will approve the results.

For archived information, confirm who needs access and how they will find it. Discuss retention requirements with the people responsible for accounting, privacy and recordkeeping. Do not assume every type of record has the same retention period.

Joesoftware’s Dynamics GP migration guidance discusses deciding what to migrate and what to archive. Make these decisions before agreeing on the final scope so that extraction, cleanup, transfer and validation work can be included.

Set expectations for access and system performance

Describe what each role should be allowed to do. Purchasing staff, warehouse employees and finance managers usually need different access. Identify who can create suppliers, edit banking details, approve purchases and release payments, including where separate approvals are required.

Use actual business volumes when discussing performance. Include daily orders, invoice batches, stock movements and the number of people working at the same time. Ask providers how they will test busy periods with a workload that reflects your operations.

Record requirements for remote work, devices, sign-in, backups and recovery. Identify any contractual requirements about where data is held. If privacy or industry obligations apply, involve the appropriate adviser and ask the provider to explain how the proposed arrangement meets your specific needs.

Ask providers to demonstrate your actual workflows

Give each shortlisted provider the same business scenarios. Ask them to demonstrate a complete workflow, including an exception. A purchasing demonstration, for example, could cover approval, a partial delivery, an invoice discrepancy and the resulting accounting entries.

For each requirement, record whether the provider proposes a standard function, configuration, an additional application, custom development or a manual step. Microsoft’s implementation guidance recommends assessing standard capabilities against business requirements before adding custom work. Ask what each proposed approach means for cost, maintenance and future updates.

Clarify responsibilities, costs and acceptance

Before signing, confirm who will prepare data, set up reports, connect applications and train employees. State what your team must contribute and when. Allow time for staff to answer questions, review work and practise new tasks alongside their usual responsibilities.

Compare proposals on the same basis. Include subscriptions, implementation, additional applications, migration, training, support and internal staff time. Ask what is excluded and how changes will be priced. A meaningful budget and schedule depend on the agreed work and available resources.

Agree on the evidence needed to accept the system. Microsoft’s test planning guidance covers processes, integrations, security, performance and migrated data. Choose the checks relevant to your business, assign reviewers and agree how unresolved issues will affect the launch decision.

Your finished requirements document should bring together priorities, process descriptions, sample reports, integration needs, data decisions and acceptance criteria. Record unanswered questions openly. Both your team and the provider should be able to explain what is included and what still needs a decision.