10 Questions to Ask a Business Central Partner Before Signing a Contract

1. How will you prove that Business Central fits our actual processes?

Ask the partner to demonstrate your important transactions using a short brief supplied by your business. Include the exceptions that create difficulty today: a partial receipt, a customer return, a corrected invoice or an order that crosses two departments. A polished demonstration of a straightforward transaction shows presentation skill, but it does not settle whether the proposed solution supports the work you need to control.

Request a written explanation of how each important requirement will be met. Distinguish standard capability, configuration, a third-party application, bespoke development and a change to your business process. These options have different implications for cost and ownership. You should be able to see where the partner is recommending a different way of working and why.

Look for questions as well as answers. A partner who asks about transaction volumes, approval exceptions and the reason behind an unusual process is gathering evidence. A confident promise without those questions may simply reflect an assumption that has not yet been tested. If uncertainty remains, ask what discovery work would resolve it before committing to a detailed implementation.

Our Business Central partner services provide context for discussing solution fit with NetMonkeys. Use the same scenarios when comparing candidates and record what each one actually demonstrated. The useful output is a decision trail showing how the proposed design meets the business requirement, including any limitations the business will need to accept.

2. Who will deliver the work, and what experience is relevant to our operation?

Ask to meet the people expected to lead the implementation, not only the sales team. Understand who will manage the project, design the solution and handle the specialist areas that matter to you. Request clarity about whether those people are confirmed, provisionally allocated or dependent on a later scheduling decision.

Relevant experience is more specific than a list of industry names. Ask how the team has approached processes comparable to yours and what difficult decisions those projects involved. For a manufacturer, useful discussion might cover the relationship between material movements, production activity and financial control. Our Business Central manufacturing services are relevant to evaluating that type of requirement.

References should help you understand delivery behaviour. With the reference customer's permission, ask whether the proposed team communicated assumptions clearly, escalated problems early and left the business able to operate independently. Respect confidentiality and do not expect another customer's design documents or commercially sensitive information to be disclosed.

Also ask what happens when a key person is unavailable. A credible answer explains cover, documentation and the effect of substitution on the plan. Record whether you will be informed before important roles change. The purpose is not to obtain an impossible guarantee that staff will never move; it is to establish continuity arrangements that reduce reliance on one person's memory and availability.

3. What exactly is in scope, and how will completion be accepted?

Ask the partner to describe the first release in terms of processes, companies, locations, integrations and outputs. A list of software modules leaves room for disagreement about the detail. “Finance included” does not establish which reports, approval arrangements, opening transactions or reconciliation activities the project will deliver.

Each major deliverable needs an acceptance approach. Identify who will review it, what evidence will be produced and how unresolved issues will be handled. Ask how the plan distinguishes a defect against an agreed requirement from a new request. This is particularly important when an apparently small change affects several processes or introduces additional testing.

Microsoft's guidance on defining requirements discusses recording acceptance criteria and business justification. Use that principle when reviewing the proposal: the scope should make it possible to determine whether the promised outcome has been delivered. The document does not need to predict every future preference, but it should explain how uncertainty is resolved.

For financial deliverables, our Business Central finance implementation services provide relevant context. Ask who signs off the chart of accounts, dimensions, reporting and migration reconciliations. Record exclusions alongside inclusions, including work your employees must perform. A clear boundary helps both parties plan honestly and makes a later disagreement easier to resolve against an agreed reference.

4. What is the full commercial model, including assumptions and recurring costs?

Request a breakdown that separates subscription charges, implementation services, third-party applications, migration, training, support and optional work. The aim is to understand the basis of the commitment, not simply to compare the total at the bottom of two proposals. Different assumptions can make an apparently cheaper offer more expensive once the actual requirement is established.

Ask whether each service is fixed price, time and materials, an allowance or an estimate subject to discovery. Clarify what happens when the assumptions change. If an allowance is used, ask how consumption is reported and who must approve additional expenditure. Written approval thresholds are more useful than a general promise to keep the customer informed.

Consider costs that follow from the design. A retailer might need a particular connector or specialist application, with its own renewal and support arrangements. Our Business Central retail services are relevant when assessing those dependencies. Ask whether the proposal includes all required components and which commercial terms come from another supplier.

Review the cost of business participation too. Your employees need time for workshops, data preparation and testing, even when those activities do not appear as partner charges. Do not ask the supplier to guarantee an exact return without a reliable baseline. Instead, establish an understandable total-cost model and a process for updating it when the business makes a new decision.

Check the presentation of charges as well as their amount. Ask which currency applies, whether tax is included and what happens at renewal. Where user numbers or transaction volumes affect the estimate, record the assumed level and how a change would alter the commercial commitment.

5. Who owns data preparation, migration and financial reconciliation?

Ask the partner to separate technical migration work from the business decisions that determine what should be moved. Extracting a file, importing records and resolving duplicate suppliers are different activities. If the proposal says “data migration included”, request a description of the datasets, preparation responsibilities, trial loads and validation evidence that phrase covers.

Agree the treatment of history, open documents, balances and inactive records. The correct choice depends on how the business operates and what information it needs to retain and retrieve. Ask the partner to explain the proposed approach and its limitations, rather than accepting a broad promise that everything will be available exactly as before.

Inventory deserves particular attention when physical stock and accounting records need to agree. Establish who validates quantities, values and the treatment of transactions in progress. Our Business Central supply chain services offer relevant context for discussing those operational dependencies. The team needs a coherent result across warehouses, purchasing and finance.

Ask how trial migrations will be reconciled and who approves the outcome. Record the planned evidence and the steps taken when a total does not match. Avoid making the final cutover the first serious examination of data quality. A strong answer describes a repeatable process with business ownership; a weak one assumes that the import tool will determine which source records are correct.

6. Who will take responsibility for integrations and other suppliers?

Ask for a list of every system involved in the proposed solution and the owner of each connection. Include the source application, destination, data exchanged, expected timing and operational consequence of failure. The business needs to understand the whole transaction journey, especially where several suppliers contribute to one process.

Request clarity about who arranges access, obtains technical information and secures the other supplier's time. Some integration work depends on a third party making a change or providing a suitable test environment. If that dependency is absent from the plan, a delivery date may rely on resources that have never actually been committed.

Our system integration services are relevant when defining these responsibilities. Ask the partner to explain the error process as well as the successful path. How will staff know an order has failed? Who investigates incomplete data? How is a retry checked to prevent an unwanted duplicate? Operational answers matter as much as the choice of connector.

Finally, establish who coordinates a cross-supplier incident after launch. It may be reasonable for different suppliers to fix their own components, but the customer still needs an owner for the overall investigation. Put that coordination role in writing. Otherwise, your employees can end up forwarding contradictory messages between suppliers while the business transaction remains unresolved and nobody controls the next action.

7. How will you prove quality and prepare our employees to use the system?

Ask how the project will test the solution from the business's point of view. The test approach should cover normal work, important exceptions, integrations and the information managers rely on. A technical test can show that a function runs without demonstrating that the business can complete and reconcile an entire process.

Find out who creates test scenarios, who supplies representative data and who performs acceptance testing. Confirm that your employees will test using appropriate roles, rather than judging every process through unrestricted access. Ask how failed tests are recorded and how the partner will help you distinguish a defect, a data issue and a misunderstanding.

Management reporting needs the same discipline. Employees should understand where a number comes from, what filters apply and how it relates to financial or operational records. Our Power BI services are relevant if reporting forms part of the connected solution. Agree a small number of important measures and require evidence that users can interpret them correctly.

Training should be linked to responsibilities. Ask what material will remain available, how new starters will learn and how occasional tasks are covered. A large group demonstration can introduce the system, but it should not be the only evidence that employees can do their jobs. Request a plan for practical exercises, questions and support during the transition to normal work.

Ask to see an example of how a failed test moves towards approval. You want a recorded finding, an owner, a correction and a retest, with the business confirming the final result. An informal statement that an issue has been fixed is weaker evidence than a repeatable check.

8. How will custom development, apps and future updates be controlled?

Ask why each proposed extension is needed and what simpler alternatives were considered. Custom development may be justified, but the business should understand the requirement it satisfies and the ongoing responsibilities it introduces. Avoid treating the number of tailored features as evidence of implementation quality; the better measure is whether the design remains understandable and maintainable.

Establish ownership and access arrangements for development materials, technical documentation and deployment processes. If third-party intellectual property is involved, clarify the relevant licence and support conditions. Your contract should explain what your business can access and what happens if the delivery or support relationship changes, without assuming ownership rights that were never agreed.

Connected workflows can create similar dependencies outside the ERP itself. Our Power Platform consulting services provide relevant context where the design includes additional applications or automation. Ask who owns those components, which environments they use and how their changes will be coordinated with Business Central.

Discuss future product and app updates before launch. Who reviews changes, carries out important business tests and resolves compatibility issues? Which work is included in support and which requires separate approval? The useful answer is an operating process with named responsibilities. A general assurance that the solution is “future-proof” tells you little about how the team will manage the next real change.

9. What support will we receive after go-live, and where are the boundaries?

Ask for the post-launch service to be described separately from the implementation. Confirm how hypercare works, who is available and what must be true before that closer support ends. Then examine the ongoing arrangement: covered processes, operating hours, reporting channels, escalation and any usage allowance should be understandable before signing.

Microsoft's Business Central FAQ explains that customers normally contact their reselling partner for technical problems and the partner can escalate unresolved issues to Microsoft. That route does not define every activity in your chosen partner agreement. Clarify how investigation, training, configuration changes and third-party application issues are treated commercially.

Distinguish response from resolution. An acknowledgement target does not necessarily promise that a difficult defect will be fixed within the same period. Ask for examples of priority classification and how communication works during a serious incident. Check any coverage needed outside normal office hours explicitly rather than inferring it from general marketing language.

Also establish the interface with your wider managed IT support. A user may experience an application problem that involves identity, connectivity or a device. Agree who coordinates the investigation when the cause is unclear. The employee should have a route to help without first deciding which supplier's contract contains the faulty component.

10. How will we govern the relationship and leave it in an orderly way?

Ask how progress, risk and commercial decisions will be reviewed throughout delivery. You need a regular view of completed work, upcoming decisions, unresolved issues and changes to assumptions. The reporting should help the sponsor act, rather than simply confirm that meetings have taken place. Establish the escalation route when the project team cannot resolve a concern.

Check your own obligations as carefully as the supplier's. If the contract assumes that business owners approve decisions promptly, confirm that those people have capacity. Ask what happens when either party misses a dependency and how the resulting impact will be assessed. A working relationship is stronger when responsibility is explicit on both sides.

Review practical exit arrangements before they become urgent. Identify what documentation, access, data exports and development materials should be available, subject to the agreed rights and licences. Clarify how an incoming supplier would receive an orderly handover and how unresolved work would be treated. Obtain appropriate professional review of contractual terms where needed; a content checklist does not replace that review.

Use all ten questions to create a written comparison of candidates. Record the evidence, remaining uncertainty and any change required to the proposal. If you are considering NetMonkeys, contact our team with your scenarios and constraints. The next step should make the proposed responsibilities concrete enough to assess, rather than asking you to commit on the strength of a demonstration alone.

Keep the final agreed documents together and check that sales assurances have not disappeared between the demonstration, proposal and contract. If two documents describe the same responsibility differently, resolve that difference before signing and identify which agreed wording governs the work.