Separate software charges from implementation work

Start with four budget categories. Keeping them separate helps you see which costs repeat, which relate to the initial project and which depend on future work.

Microsoft’s Canadian Business Central pricing page is a starting point for subscription information. A published user price is not an implementation quote. Ask for a proposal that states the currency, billing term, taxes, inclusions and exclusions.

For a first-year budget, add the subscriptions payable during that year to the implementation services, internal project costs and other charges due in the same period. Identify later recurring costs separately so the second-year commitment is also visible.

Define which parts of the business are included

The project scope should explain what employees will be able to do at launch. List the companies, branches and departments included, then describe the main workflows: accounting, sales, purchasing, inventory, projects or production, as applicable.

Be specific about the result. “Set up finance” could cover anything from a basic account structure to several companies with intercompany transactions and reporting by division. Ask which processes are included and what evidence will show they are working.

Microsoft’s implementation strategy guidance treats the budget as more than a subscription expense. Use your agreed processes to identify the delivery work, people and resources needed, then check that the estimate reflects them.

Also document what stays outside the project. If payroll, a specialist application or a reporting task remains elsewhere, explain whether it needs a connection to Business Central. An exclusion can still create work for someone.

Understand what discovery and configuration cover

Discovery is the work of reviewing requirements, current processes and the proposed approach. Ask what it produces: documented workflows, a list of gaps, migration decisions, a project plan or a revised estimate. Confirm whether it is a separate paid stage.

Configuration then puts the agreed approach into the system. This may include account structures, posting settings, tax setup, approval rules, user permissions and operating records. The amount of work depends on the detail and variation in your processes.

For Canadian operations, identify the tax situations, currencies and reporting requirements the team must test. Your finance team or tax adviser should confirm the applicable treatment. Include representative transactions instead of assuming that selecting a Canadian setup finishes the work.

Ask what happens when discovery identifies something missing from the initial estimate. The proposal should explain how the partner presents options and obtains approval before adding work that changes the fee or schedule.

Make the data migration estimate specific

Migration costs depend on the condition and structure of the records, not just their quantity. Data spread across spreadsheets and old applications may require more preparation than a larger, consistent set of records from one source.

Separate customer, supplier and item records from opening balances, unfinished transactions and historical information. State what will move, what will remain accessible in an archive and who will prepare each category.

Microsoft’s data migration guidance covers preparation, mapping and validation. Ask whether the estimate includes test transfers, corrections and reconciliation before the final move. A migration line item should say more than “import data.”

Assign responsibility for cleanup. If your employees will remove duplicates or correct item codes, allow time for that work. If the partner will do it, confirm the assumptions and how uncertain records will be reviewed with your team.

Price integrations as complete working connections

A connection to CRM, e-commerce, payroll or another application can involve more than installing a connector. The team must agree on which information moves, how records match and what happens when a transfer fails.

Ask the partner to identify the connector or development approach, any subscription charges and the work included in setup. Check whether testing covers both normal transactions and exceptions such as returns, duplicate records or rejected orders.

Consider the other application’s provider too. It may need to supply access, make changes or help investigate errors. Identify those dependencies and any separate fees before treating the integration estimate as complete.

Finally, ask who maintains the connection after launch. Changes to either system can require review or testing. Record which support agreement covers that work and which changes would be quoted separately.

Review reports and custom work individually

Bring examples of the documents and reports your business needs. These may include financial statements, invoices, purchase orders, project summaries or inventory reports. Remove confidential information from samples shared during the review.

Ask which requirements can be met with standard functions or configuration. If custom development is proposed, have the partner explain the business need, expected result and alternatives. Recreating an old screen or report may not be necessary if the new system supports the task differently.

Separate the cost of producing a report from the cost of a reporting tool or additional licence. Include time for your finance or operations team to verify calculations, layouts and access. A report is not ready simply because it displays figures.

Include training, testing and employee availability

Training should reflect the work people will do. Ask which roles are covered, whether sessions use your configured processes and what materials employees will retain. Confirm the approach for people who miss a session or join later.

Testing also requires business participation. Employees need to verify orders, approvals, postings, reports and connected applications with representative records. Allow time to correct issues and repeat the affected checks before launch.

Internal time belongs in the budget even when it does not appear on the partner’s invoice. Estimate the hours needed from process owners and daily users, using your organisation’s own costing method. Avoid counting the same staff expense twice when preparing a financial assessment.

If employees cannot contribute alongside their normal duties, discuss workload cover or a different schedule. A proposal based on prompt decisions and prepared data may need revision when those assumptions are not realistic.

Clarify launch support and the handover

The move to live operation may include a final data transfer, balance checks, access confirmation and support for employees using the new processes. Identify the activities, the people responsible and the working hours assumed in the estimate.

Microsoft’s go-live guidance covers preparation and the transition to ongoing support. Ask how the partner will help with the first transactions and how issues will be recorded, assigned and resolved.

Distinguish help included in the implementation from later support charges. Confirm when one arrangement ends and the next begins. Also ask how the team distinguishes a problem with agreed work from a request for a new feature.

Compare quotations using the same assumptions

Give shortlisted partners the same requirements and request a breakdown by work area. Check migration, reports, integrations, training and launch support line by line. A smaller headline amount may simply cover less work.

Ask whether pricing is fixed, based on time spent or a combination. A fixed fee should identify the included deliverables and change process. An hourly arrangement should identify rates, estimated effort, reporting and approval controls. Neither format replaces a clear scope.

Check the dates when recurring charges begin. Subscriptions, additional applications and support may start at different stages, including before the system is live. Ask how a delayed launch would affect those charges, and include any period when both the old and new systems must remain available. This makes the cash required during the transition easier to plan.

Review payment milestones and acceptance criteria together. Know what must be delivered at each stage and how questions about completion will be resolved. Confirm how long the quotation remains valid and which assumptions could change the estimate.

Manage uncertainty without cutting essential work

Identify unresolved items before approving the budget. Examples include an integration awaiting technical review, historical records that have not been assessed or a report without agreed calculations. Ask for the next step needed to narrow each uncertainty.

Keep an allowance for identified risks, based on their likely effect and the information available. There is no universal contingency percentage that fits every project. Agree on who can authorise its use and how it will be reported.

If the proposed scope exceeds the budget, consider whether some functions can follow later. Confirm that the first phase can operate safely and that deferring work will not create duplicate setup, broken processes or an unplanned second migration.

A phased approach needs its own costs and dependencies. Keep essential migration checks, user training and acceptance testing in the plan. Removing those activities from the quotation transfers the work or risk; it does not necessarily remove the need.