What Should Be Included in a Business Central Implementation Proposal?
Understand what a Business Central proposal should cover, including scope, migration, integrations, costs, testing, responsibilities and support.
What is the quick answer?
A Business Central implementation proposal should define the business outcomes, scope, solution approach, deliverables, responsibilities, assumptions, commercial terms and acceptance criteria. It should explain migration, integrations, testing, training, cutover and support, including what is excluded. Compare proposals against the same business scenarios and resolve important uncertainties before relying on a headline price or go-live date.
What is the purpose of a Business Central implementation proposal?
A proposal should turn an initial conversation into a shared description of the work the customer and partner expect to undertake. It connects business needs to deliverables, responsibilities and a commercial approach. A list of software modules and a total price leaves too much unexplained for a project that changes how the organisation records and controls daily activity.
Read it as a decision document. Can the sponsor understand what success means? Can process owners identify what they must contribute? Can finance see which costs are committed and which remain uncertain? The proposal should help these people reach the same understanding before the project team starts making detailed design decisions.
Our Business Central implementation consultancy provides a relevant starting point for discussing requirements and delivery scope. Ask for important assumptions in writing. A proposal need not pretend that discovery has answered every question, but it should make the remaining questions visible and explain how they will be resolved, priced and approved.
↑ Back to contentsWhich business outcomes and success measures should it define?
State the operational result the business wants to achieve. Examples might include producing a dependable management pack, controlling stock across locations or reducing duplicate order entry. These are objectives to define for your own organisation, rather than guaranteed outcomes of installing a product. Each should have an owner who can judge whether the delivered process is useful.
Separate implementation acceptance from longer-term benefits. A reconciled opening balance can be tested at cutover. Improved working capital may require months of operational change after launch. Mixing the two can create confusion about whether the partner has completed its deliverables and whether the business has adopted the new way of working.
Microsoft’s Success by Design guidance emphasises proactive consideration of implementation risks. For your proposal, translate that principle into practical evidence: a baseline, a target outcome, a responsible owner and an agreed review point. Avoid accepting a benefit statement that sounds attractive but cannot be connected to a specific process or measured sensibly.
↑ Back to contentsHow detailed should the functional scope be?
Functional scope should identify the companies, locations, processes and transaction types included in the proposed phase. Finance, purchasing and inventory are broad labels. Ask which specific activities and exceptions are covered: partial receipts, returns, intercompany transactions, approval limits or project billing, for example. A representative scenario often reveals more than a long generic feature list.
Record the boundaries between phases. If a warehouse function is deferred, explain how stock will be controlled in the interim and how finance will reconcile the result. A later phase is not a solution to an immediate dependency unless a workable temporary process is included. Make exclusions explicit enough that operational managers can understand their consequences.
Our Business Central supply chain services are relevant when assessing order, purchasing and inventory requirements. Give each important requirement a reference and an acceptance approach. This allows changes to be discussed consistently and reduces the chance that different teams assume the same phrase includes different work. Scope clarity protects both the customer and the implementation team.
↑ Back to contentsWhat should the proposal say about finance and reporting design?
The proposal should describe how the project will establish the financial structure and reporting requirements. This includes the decisions that need business input, such as accounts, dimensions, posting conventions and management reporting definitions. It should identify who approves those decisions and when they must be settled to avoid delaying configuration or migration.
Specify the reports included in the work. A statement such as reporting provided may mean standard product reports, a configured management pack or a separate analytics project. Ask for named outputs, source data, cut-off rules and reconciliation expectations. Distinguish operational visibility from statutory, tax or specialist reporting requirements that need separate validation.
Our Business Central finance implementation services provide a relevant route for discussing these requirements. Include examples of the current management pack and explain which weaknesses must be addressed. The proposal should make clear who verifies that the new figures are complete and consistent. Attractive dashboards cannot compensate for unresolved posting rules or disagreement about the meaning of a financial measure.
↑ Back to contentsWhat data migration information should be included?
Data migration scope should name the source systems, record types, historical periods and open transactions involved. Clarify whether the plan includes master data, opening balances, outstanding documents, detailed history or an accessible archive. Do not assume that the phrase migrate existing data includes every record currently stored in the old system.
Allocate responsibility for extraction, cleansing, mapping, loading and reconciliation. These activities require different skills and can involve substantial customer effort. Set expectations for the format and quality of source files, the number of trial migrations and the date by which corrected data must be supplied. Identify who signs off the results.
Ask how the project will handle transactions created between the final extraction and go-live. There should be a clear cut-off and catch-up approach, with controls against omissions and duplicates. Define reconciliation evidence for finance and operational balances. The migration plan should make it possible to explain where the opening position came from, rather than merely confirming that a file loaded without a technical error.
↑ Back to contentsHow should integrations and third-party applications be described?
List every system that must exchange information with Business Central, along with the data and direction of transfer. Identify the owner of each interface and the application that holds the authoritative record. Include operational dependencies such as order identifiers, error queues and reconciliation. A connector being available does not establish that the required business process is already designed.
For each third-party application, identify the supplier, licensing arrangement, implementation responsibility and support route. Clarify whether the proposal includes purchase, configuration, testing and ongoing upgrades. Ask what happens if the application cannot support an important requirement or if a necessary feature changes during the project.
Our system integration services are relevant when reviewing those connections. Require end-to-end tests covering failure and recovery, not only a successful data transfer. An integration should have an agreed response to duplicates, unavailable systems and partially completed work. Those requirements affect effort and risk, so they belong in the proposal rather than being discovered after a fixed budget has been approved.
↑ Back to contentsWhat should it explain about standard configuration and custom development?
Ask the partner to distinguish standard functionality, configuration, extensions and bespoke development. These choices have different implications for cost, testing, ownership and future maintenance. A requirement may be met through a process change rather than code, but that change should be described and accepted by the relevant business owner.
For proposed custom work, define the behaviour, acceptance criteria and dependencies. Clarify who owns the deliverable, where the source and documentation are kept, how it is deployed and who supports it. Ensure the commercial arrangement explains future changes and compatibility work. Avoid assuming that development effort includes unlimited redesign as the team learns more.
For a manufacturing requirement, for example, our Business Central manufacturing services provide a relevant point of discussion. A demonstration should use representative transactions and practical exceptions. Ask how the proposed design will be tested through purchasing, production, stock and finance. A custom screen can appear satisfactory while its effect on the wider process remains unproven.
↑ Back to contentsHow should Copilot, AI and automation be scoped in the proposal?
Treat AI requirements as named use cases rather than a general statement that AI is included. Identify the proposed capability, its current status, the task it supports and the human review required. Clarify whether the work uses standard product functionality, a third-party service or custom development. A roadmap item should not be presented as an available committed deliverable.
Separate setup from ongoing operation. The proposal should identify any additional consumption charges, supervision, monitoring and support arrangements, together with responsibility for checking availability in the intended environment. Acceptance should include representative exceptions and a fallback. A successful demonstration is not sufficient evidence that a process is ready for unrestricted live use.
Our AI consultancy services are relevant when evaluating those use cases. Where conventional rules meet the need, ask whether a simpler workflow would be more suitable. The proposal should explain why each chosen approach solves the business problem. Avoid buying complexity under an AI label when the underlying requirement is an approval rule, a data correction or a reliable integration.
↑ Back to contentsWhat project plan and customer responsibilities should be visible?
The plan should show phases, deliverables, dependencies and decision points. A date alone is not a delivery method. Ask which activities determine the earliest credible go-live and which customer inputs are needed. Busy periods, stock counts, audits, holidays and other projects can materially affect the team’s ability to participate.
Name the sponsor, project manager, process owners and data owners. Estimate the internal effort required for workshops, decisions, cleansing, testing and training. A proposal that lists only partner days can conceal a significant demand on customer staff. Confirm who has authority to resolve competing departmental requirements and who approves changes to scope or schedule.
Agree the governance routine: progress reporting, risk review, issue escalation and decision recording. Identify what happens when a dependency is late. A realistic plan makes trade-offs visible while there is still time to act. It should not rely on every customer decision being immediate or every data file arriving correct the first time. Those assumptions deserve explicit review before commitment.
↑ Back to contentsWhat testing and acceptance criteria should the proposal contain?
Testing scope should cover the configured process, integrations, migrated data, permissions and practical exceptions. Distinguish partner testing from customer user acceptance testing. Define who prepares scenarios, who executes them and what evidence is retained. A checklist of screens visited does not establish that a complete business process works.
Specify the conditions for accepting a deliverable and the process for recording and resolving defects. Agree how issues are prioritised and which can remain open at go-live. The business should understand the consequences of each outstanding item and any temporary control required. Avoid a vague acceptance step that nobody knows how to complete.
Our Power Platform consultancy is relevant where workflows or connected applications form part of the solution. Include those components in end-to-end acceptance rather than treating them as separate successes. A purchase request, for instance, should be tested from initiation through approval and the resulting ERP record. The proposal should define the evidence needed for that joined-up outcome.
↑ Back to contentsWhat training and change management should be included?
Training should be organised around roles and real work. Clarify who receives it, which processes are covered, how sessions are delivered and what supporting materials remain available. A single general demonstration rarely answers the needs of finance, purchasing, warehouse staff and managers. Include arrangements for people who cannot attend the original session.
Identify the customer’s responsibility for explaining process changes and confirming readiness. Employees need to understand new controls, cut-off dates and escalation routes as well as software navigation. Superusers can help sustain knowledge, but the proposal should make their expected contribution and time commitment clear.
Ask how training will use the configured solution and realistic data without exposing unnecessary sensitive information. Decide how learning is assessed: a user completing representative tasks provides more useful evidence than attendance alone. Include the route for questions discovered during early live use. Training should support a reliable handover into operations, not end at the point where a presentation file has been delivered.
↑ Back to contentsWhat should the commercial breakdown and assumptions explain?
Separate software subscriptions, implementation services, third-party applications and ongoing support. For each service element, identify whether the charge is fixed, estimated or based on time used. Explain taxes, expenses and payment milestones where applicable. Compare proposals on the work and risk they include rather than treating a headline total as a like-for-like comparison.
Review assumptions carefully. Limits on companies, users, interfaces, migration iterations, report numbers or training sessions can materially affect the eventual cost. Ask which unresolved decisions could change the estimate. A transparent range supported by assumptions may be more useful than apparent certainty based on requirements that have not yet been investigated.
If reporting is included, for example, clarify whether Power BI implementation services form a separate workstream and whether any additional licensing or data preparation is required. Ask for a change-control approach that records the reason, impact and approval before extra work proceeds. Have appropriate commercial or legal advisers review contractual obligations where your business needs that assurance.
↑ Back to contentsWhat cutover, rollback and early-life support should be described?
Cutover needs a coordinated sequence for final data, access, communications and the start of live processing. Identify who owns each task and who makes the go/no-go decision. Specify the evidence required: reconciled balances, completed tests, available staff and workable handling of outstanding issues. A planned date should not silently replace readiness criteria.
Ask what happens if the business cannot proceed safely. A rollback or contingency approach should consider the systems and transactions involved, rather than promising that a complex migration can always be reversed instantly. Clarify decision deadlines and how the business will communicate delays to affected teams or trading partners.
Our managed IT support services are relevant to the wider access and infrastructure dependencies around a launch. Define early-life support coverage, contact routes and the handover into routine support. State what counts as a defect, a new requirement or a user question, and how each is handled. These distinctions help prevent a gap when the implementation team finishes its planned work.
↑ Back to contentsWhat security and long-term ownership questions should we ask?
The proposal should identify responsibility for access design, administrative accounts, environment management and protection of project data. Customer and supplier teams need enough access to deliver the work, with a process for reviewing and removing it. Clarify how sensitive extracts and test files are transferred, retained and disposed of under agreed arrangements.
Discuss continuity beyond the first launch. Who maintains documentation, integrations and custom extensions? How are product updates assessed and tested? What records will another authorised partner need if you change provider? These are practical ownership questions, and they should have answers before your business becomes dependent on a poorly documented solution.
Our managed cyber security services provide a relevant starting point for reviewing the surrounding protection requirements. Keep implementation security separate from any claim that installing an ERP system makes the company compliant. The business still needs appropriate governance and operating controls. Record the responsibilities that belong to the customer and those explicitly included in the partner’s service.
↑ Back to contentsHow should we compare competing proposals before choosing a partner?
Give each partner the same brief and ask them to walk through the same representative scenarios. Compare scope, assumptions, evidence and customer effort alongside price. Where a proposal uses a different delivery approach, ask the partner to explain the trade-off. A lower total may be sensible, or it may simply omit work that your business still has to perform.
Create a short decision record covering essential requirements, unresolved questions, commercial exposure and the reasons for your choice. Ask process owners to confirm that the proposed scope supports a workable first phase. Ensure the sponsor understands which benefits depend on internal action after implementation, rather than assuming the supplier alone can deliver organisational change.
Before signing, resolve material ambiguity or agree a defined discovery stage that will resolve it before the full commitment. Seek appropriate advice on contractual terms rather than relying on an article to interpret them. The strongest proposal creates a shared, realistic basis for delivery. It makes responsibilities and uncertainty visible enough for both parties to act on them constructively.
↑ Back to contentsWhat else do businesses ask?
Should a Business Central proposal always offer a fixed price?
Not necessarily. Fixed pricing depends on a sufficiently defined scope and assumptions. Discovery, configuration and uncertain integrations may need different commercial approaches. Ask what is included, what could change and how additional work is approved.
Is an implementation proposal the same as a contract?
A proposal may form part of a contractual arrangement, but its legal effect depends on the documents and terms agreed. Have an appropriate adviser review the arrangement where needed. Ensure scope, responsibilities and acceptance criteria are consistent across the documents.
What is the biggest warning sign in a proposal?
Material ambiguity is a concern: a price or date without a clear scope, assumptions, customer responsibilities and acceptance method. Ask the partner to make important boundaries and uncertainties explicit before relying on the offer.
Who wrote this guide, and how was it checked?
Written by Caleb Adoh, Growth Marketing Manager at NetMonkeys. Microsoft implementation guidance was checked on 28 October 2026. Proposal evaluation questions and examples are original editorial guidance, not legal advice or a promise of delivery terms. Confirm the solution, scope and commercial arrangements with the proposed partner.
How can NetMonkeys help your business?
Talk to our team about your priorities and agree a practical next step.
Speak to NetMonkeys
