What are the most common Business Central implementation mistakes?

Why do Business Central projects struggle even when the software is capable?

An ERP implementation changes how people buy, sell, record stock and explain financial performance. Problems arise when a business treats that change as a software installation. A working demonstration can show a purchase order becoming an invoice. It cannot establish whether your warehouse will record receipts correctly, whether finance agrees the posting rules, or who resolves an exception on a busy Friday.

A successful project starts with the decisions the organisation needs to make and the processes it must operate. That gives your Business Central implementation partner a clear basis for configuration, training and testing. It also makes it easier to identify requests that belong in a later phase rather than stretching the first launch.

The mistakes below are connected. Poor ownership allows weak data to survive; weak data undermines testing; rushed testing creates an unstable launch. Fixing the underlying chain is more useful than looking for one technical fault. Use these questions as a project review, whether you are selecting a partner, preparing to launch, or trying to recover a difficult implementation.

What happens when the project starts without agreed business outcomes?

“Replace the old system” is a reason to start, but it does not define success. A finance director might expect faster month-end reporting, while operations expects dependable stock availability and sales expects less duplicate entry. Unless those expectations become specific requirements, each team can believe it bought a different project.

Write a short outcome statement for each major process. For example: finance can reconcile receivables to the general ledger using an agreed report; purchasing can see who must approve an order; operations can trace a stock adjustment to its cause. Identify the business owner, evidence required and decisions still unresolved.

Agree boundaries as carefully as ambitions. Name the companies, locations, integrations, reporting outputs and transaction types included at launch. Record exclusions and later phases. When someone requests an addition, assess its effect on configuration, data, testing and training together. A small field change can affect an interface, a report and several procedures. This keeps the project plan connected to the actual work.

Why is copying every legacy process a costly mistake?

People often ask for the new system to look exactly like the old one because familiar processes feel safer. Some existing practices do protect important controls. Others are workarounds for limitations that Business Central may remove. Recreating all of them adds complexity before the team understands the standard product.

Start by describing the business need without prescribing the old screen or spreadsheet. “We need a second person to authorise unusual supplier spend” is clearer than “rebuild this email chain”. Ask the partner to demonstrate standard functionality against the requirement, then document any genuine gap.

Evaluate extensions by their continuing ownership as well as their initial usefulness. Who maintains them? How are updates tested? What happens if a supplier stops supporting an app? A tightly justified extension can be sensible; an undocumented collection of customisations creates recurring uncertainty. Where the requirement spans several applications, system integration planning helps distinguish a necessary connection from another manual workaround.

How can poor data preparation undermine the whole implementation?

A migration imports the consequences of earlier data decisions. Duplicate suppliers, inconsistent units of measure and obsolete item records become operational problems when staff begin processing live transactions. More records do not automatically mean a better migration. The aim is usable information with a clear audit trail.

Assign owners for customers, suppliers, items, account mappings, dimensions and opening balances. Decide which historical detail must move, which can remain available in a controlled archive, and how users will retrieve it. Check retention needs with the appropriate advisers rather than assuming every transaction must sit in the new database.

Define measurable data checks before the first rehearsal. Finance should agree how balances and outstanding documents will reconcile. Operations should agree how quantities and values will be checked by location and item. Investigate differences individually instead of accepting a broad total that happens to match. NetMonkeys’ Business Central finance implementation service is relevant when account structures, posting rules and reconciliation requirements need to be designed together.

Why should reporting be designed before the final stages?

Reporting requirements reveal decisions that are difficult to repair after launch. If the board needs profitability by department, project or product group, the relevant information must be captured consistently at the point of entry. A dashboard cannot reliably recreate context that was never recorded.

Choose a small set of essential management reports early. For each measure, agree the definition, source, date basis, currency treatment and person responsible for approving it. “Sales” might mean orders, shipments, posted invoices or recognised revenue. Those are different questions, even when they appear under one familiar label.

Build sample outputs using representative data while configuration remains flexible. Compare them with finance and operational evidence, then document the reason for any difference. If reporting combines ERP and other systems, consider Power BI services as part of the design. The report should explain its scope and freshness as clearly as it presents the headline number.

What goes wrong when integrations are treated as simple connections?

An interface is a business process with two or more systems involved. A successful transfer proves only that one message arrived. It does not prove that returns, cancellations, price changes and duplicate messages will be handled correctly throughout the order lifecycle.

For every connection, name the system that owns each important field. Decide how records are matched, what happens when an identifier changes, and how failures are detected. A sales platform and Business Central must not continually overwrite each other because ownership was left ambiguous.

Test exceptions deliberately. Disconnect a service, resend a message and submit a record with missing data in a safe test environment. Confirm that failed transactions become visible and that recovery does not create duplicate orders or invoices. Assign responsibility for the interface after launch, including changes made by the external provider. This prevents a familiar support problem in which each supplier can show that its own component works while the customer’s process remains broken.

How can unrealistic testing hide problems until go-live?

A scripted demonstration with perfect sample data is useful during design. Acceptance testing needs ordinary staff to complete real work with representative migrated records, permissions and exceptions. Include the awkward cases people handle every week, such as partial receipts, credit notes, disputed invoices and stock corrections.

For each test, record the expected business result, evidence, tester and outcome. A process is not accepted simply because someone reached the last screen. Can finance explain the postings? Can the next person find the document? Is the correct control enforced? Failed tests need an owner and a decision about whether they block launch.

Microsoft’s Dynamics 365 go-live checklist highlights readiness across testing, migration, dependencies and operational support. Apply that broad readiness principle to your Business Central project. Decide launch criteria before deadline pressure makes every unresolved issue seem negotiable.

Why is training people only just before launch risky?

Training is easier when employees understand how their own tasks fit into the complete process. A warehouse receipt changes information that purchasing and finance depend on. A dimension chosen on an invoice influences management reporting. Showing isolated clicks leaves these relationships invisible.

Build role-based practice into the project. Give people scenarios to complete, short instructions they can use later and a way to raise questions. Include deputies and new starters in the plan. A single expert who remembers every workaround is a business dependency, even if the initial launch appears smooth.

Protect time for staff participation. Asking a finance manager to deliver normal month-end duties and a major implementation without cover creates an avoidable bottleneck. Decide which duties can be reassigned and which decisions require their attention. For collaboration, identity and everyday productivity issues around the rollout, Microsoft 365 support can help keep the surrounding working environment dependable.

How can excessive permissions and weak ownership create control gaps?

It is tempting to give everyone broad access during a busy project so that testing can continue. If those permissions carry into production, the live system may operate very differently from the control design that management approved. Convenience becomes the default security model.

Design roles around responsibilities. Consider who creates suppliers, changes payment details, raises orders, approves spending, posts invoices and administers the environment. Where duties cannot be separated fully in a small business, document a compensating review and make it practical for someone to perform.

Test controls using the intended user accounts and roles. Confirm both that authorised work succeeds and that restricted actions are blocked. Review access when people move jobs or leave. Include privileged accounts and connected applications in that review. A cyber security audit can help assess wider access and security weaknesses that sit around the ERP, including devices and identity administration.

What should a realistic cutover plan include?

Cutover is the controlled move from the old operating position to the new one. It needs more detail than a date and a promise that the partner will handle the import. The business must know when old-system transactions stop, who checks the final balances and when staff may begin live processing.

Write the sequence with named owners, dependencies and verification points. Include data extraction, final migration, reconciliation, access checks, integration activation and communication to users. Define how transactions received during the changeover will be captured and entered without omission or duplication.

Rehearse the sequence using realistic data volumes. Measure how long the work takes and investigate the slow or uncertain steps. Agree the point at which the launch decision is made, who makes it and what happens if acceptance checks fail. A fallback plan must be operationally credible: explain how the business continues trading and how records remain consistent if the intended sequence cannot finish.

Why does post-launch support need planning before launch?

The first live period often exposes questions that testing did not anticipate. Staff may need help deciding which document to use, understanding a posting or identifying whether a discrepancy is a data issue. Without an agreed support route, urgent requests spread across email, messaging and informal calls.

Create one visible method for logging issues and assessing their business impact. Distinguish a blocked payment run from a cosmetic report improvement. Give business owners and technical specialists clear responsibilities, and keep a record of fixes that may need retesting elsewhere.

Plan for the first close, first stock review and other important cycles after go-live. These events are part of proving the operation. Include infrastructure and user support through managed IT support, while confirming who owns ERP application issues. If integration services or supporting workloads run in cloud infrastructure, agree their monitoring and recovery arrangements through managed cloud support as appropriate.

How can we recover a Business Central project that is already struggling?

Begin with a shared account of the current position. List the processes that work, those that fail and those that have not been tested. Separate confirmed defects from unresolved design choices and training needs. Otherwise the same issue can move between teams without anyone making the underlying decision.

Stabilise the essential transaction paths before adding more features. Reconcile critical data, resolve the highest-impact control weaknesses and establish a credible issue list. Rebuild the plan around the remaining evidence required for safe operation. A revised date without a revised workload simply repeats the original problem.

Automation can be useful once a process is stable. Bringing in Power Platform consulting too early to work around unresolved ERP design can multiply the number of moving parts. Assess each proposed flow against ownership, error handling and support requirements before introducing it.

What would an evidence-based readiness review look like?

Imagine a growing wholesaler approaching launch. Sales can enter orders and finance can post invoices, so the project dashboard looks positive. During a joint rehearsal, however, the warehouse cannot process a partial receipt with the intended permissions. Purchasing has not decided who resolves the difference, and the expected inventory report excludes one location. The software is available, but the operating process is not yet ready.

A useful readiness meeting starts with this kind of evidence. Walk through the essential transaction paths and ask the responsible business owners to show the accepted result. Record unresolved items as decisions, defects, data issues or training needs. Give each a consequence, owner and next action. This makes the discussion more specific than asking departments whether they feel comfortable.

Separate launch blockers from improvements that can safely follow. A missing decorative report label may be deferred with little consequence; an unreconciled opening balance or a failed payment control requires a different judgement. Document why a risk is accepted, who accepts it and what temporary procedure will operate. That record should be understandable to someone who was not in the meeting.

Use a compact readiness pack containing the agreed scope, reconciliation evidence, critical test results, access review, cutover rehearsal and support arrangements. The pack does not need to be elaborate, but its statements should have evidence behind them. If a check has not been performed, say so rather than treating silence as acceptance.

Finally, review the first important live cycles before declaring the project complete. A successful first day is valuable, yet the first month-end or stock valuation may reveal requirements that daily transactions did not exercise. Keep the appropriate people available and agree how remaining issues transfer into normal support. This preserves accountability through the point at which the new operation has been demonstrated, rather than ending responsibility at the moment the launch button is pressed.

Keep the agreed evidence available to the people responsible for maintaining the process, and revisit it when responsibilities or requirements change.

What should we ask an implementation partner before committing?

Ask how the partner will discover your processes, demonstrate fit, manage changes and evidence readiness. Request examples of the deliverables you will receive, such as a requirements register, data validation approach, test record and support handover. Discuss who supplies the business knowledge and who makes decisions when departments disagree.

Clarify assumptions in the proposal. The number of legal entities, quality of source data, integration complexity and availability of staff all affect effort. Confirm what happens if those assumptions prove wrong. A transparent discussion now is more useful than an attractive headline that leaves difficult work undefined.

The practical starting point is a focused review of the outcome you need, the risks you already know and the evidence required to launch. Speak to NetMonkeys about your Business Central project with your key processes, current systems and unresolved questions. That gives the conversation a concrete basis and helps turn implementation from an open-ended software exercise into an accountable business change.