The Business Central consultant role, explained from the inside

What the Business Central consultant role covers

A consultant sits between the business and the software. The first task is to listen. Ask how orders arrive and how stock moves. Then ask who approves invoices, and what finance needs at month end. The second task is to translate those answers into Business Central setup. That means posting groups, dimensions, number series, workflows and permissions.

From there, the role follows the project. The consultant configures a company, prepares data templates and runs workshops. They also write test scenarios, train key users and support the cutover. Afterwards, the work shifts. The consultant answers questions and tunes the setup. The consultant also adds features the business was not ready for at first.

The functional consultant

A functional consultant works in the application, not in code. Typical strengths: finance, trade, stock. Some specialize in warehousing, manufacturing, projects or service. They know what standard Business Central does. They know which settings change its behavior. Also clear to them is where a limit appears and an add-on makes sense.

Much of the value lies in judgment. A team asks for a change. A good functional consultant first asks what problem it solves. Then they show how standard handles it. Only after that do they write a requirement for development. That habit keeps systems simple. So every later update and every new employee's training gets easier.

The technical side of the Business Central consultant role

A developer extends the product. In current Business Central, that means writing AL extensions in Visual Studio Code. It also means building API integrations and report layouts. Setting up environments in the admin center is part of it too. They also look into performance. Telemetry helps them find slow pages and jobs.

The two sides depend on each other. The functional consultant describes what is needed and why. Then the developer decides how to build it, so it survives the two release waves each year. On smaller projects, one experienced person may cover both. Even then, someone other than the author should do the testing.

Skills behind the Business Central consultant role

Accounting knowledge comes first. Almost everything in Business Central ends as a ledger entry. So a consultant must read a trial balance to explain a posting. Operations experience matters next. Purchasing, warehousing and production each have their own logic and vocabulary.

Then come the working skills. A good consultant asks clear questions and explains without jargon. They write short documents that people read, and they handle data carefully in Excel. Knowing the wider Microsoft platform helps too. Power BI, Power Automate, Outlook and Teams all connect to Business Central. Clients expect advice on them.

Where the consultant's role ends and yours begins

A consultant advises and configures, but the business decides. Choosing the chart of accounts is a client decision. So is approving who may post what. So is choosing which history to migrate, and signing off tests. The accuracy of the data is also yours. A consultant can load a customer list but cannot know which address is right.

The projects that go well have an internal owner of the system. This is someone who learns alongside the consultant and becomes the first contact for colleagues. Over time, that person handles everyday questions. The consultant is then called on for changes, updates and new areas. That balance is healthy, and it is worth planning for.

Questions about the Business Central consultant role

What is the difference between a consultant and a developer?

A consultant, in the functional sense, configures the application and advises on process. A developer writes extensions and integrations in AL. Many projects need both. The consultant usually leads, because setup meets most requirements and only some need code. So the Business Central consultant role comes first. Later, a developer joins when a gap appears.

Is a consultant the same thing as a Microsoft partner?

Not exactly. A partner is a company with a reseller or services relationship with Microsoft, often supplying licenses. A consultant is a person who does the advisory and setup work. That person may work for a partner, or independently alongside one. So the two words describe different things, even though they often appear together on one project.

Do we still need a consultant after go-live?

Usually in a lighter way. Release updates need testing, and staff change. The business adds products, sites or companies, and new features arrive twice a year. An occasional session with someone who knows your setup keeps the system from drifting. We can agree a simple rhythm of check-ins with you after go-live.

Can one consultant handle a whole implementation?

For a small, finance-led project, often yes. As scope grows to warehousing, manufacturing, integrations or several companies, a small team is safer. That means a lead consultant, a specialist or two and a developer. Then no single person becomes a bottleneck. We can help you judge how big a team your scope needs.

What should a consultant hand over at the end?

A record of setup decisions and the reasons for them. Also the test scenarios, user instructions, and the source code and documentation for any extension. Admin access should be held in your name. With those items, another competent person can support the system later. Ask for the list in writing before the project starts.

Related pages on the Business Central consultant role

These pages describe the two sides of the Business Central consultant role in more detail. They also show how to choose the right person for your project. Last, they describe the ways our consultants can work with your team remotely. Read the implementation guide next, since it shows where each kind of consultant joins a project. For the product detail, see Business Central documentation on Microsoft Learn.