Business Central and Dynamics 365 Sales: Connecting ERP and CRM

Almost every organisation I work with runs two systems that both claim to own the customer. The sales team lives in a CRM, where an account is a relationship, a set of contacts, a pipeline of opportunities and a history of conversations. The finance team lives in an ERP, where that same customer is a ledger entry, a credit limit, an open order and an aged receivable. Both are correct. Both are incomplete. And the moment a salesperson closes a deal, the information has to cross from one world into the other, because a quote is a sales artefact but an order is a financial commitment. That crossing point is the quote-to-cash seam, and it is where most of the friction, the duplicate records and the "which number do we trust" arguments come from. Business Central and Dynamics 365 Sales are both Microsoft products, and Microsoft has spent years making that seam smoother through a shared data platform. This guide is about how that actually works in practice, and how to make it work for you.

The message up front: connecting ERP and CRM is not primarily a technical project, it is a data-ownership agreement expressed in software. Before you switch on any sync, you have to decide which system owns the customer, which owns the item, which owns the price, and what happens when the two disagree. Business Central and Dynamics 365 Sales give you a standard, Dataverse-based integration that handles the plumbing well. The plumbing is the easy part. The ownership decisions are the whole game.

1. Why ERP and CRM need to be connected (the quote-to-cash seam)

Start with what each system is genuinely good at, because the case for connecting them falls out of that division of labour. A CRM is built for the front of the business: finding prospects, nurturing relationships, tracking opportunities through a pipeline, forecasting revenue, and giving salespeople a single view of everyone they talk to. An ERP is built for the back of the business: recording what was actually sold, at what price, on what terms, whether it has been delivered, whether it has been paid, and what all of that does to the general ledger. The CRM is about probability and relationship. The ERP is about fact and money.

The quote-to-cash process runs straight across that boundary. A lead becomes an opportunity in the CRM. The opportunity produces a quote. The quote, if accepted, becomes a sales order. The order is picked, shipped and invoiced. The invoice is paid and the cash lands. The first half of that chain is CRM territory and the second half is ERP territory, but they are one continuous process from the customer's point of view. If the two systems are not connected, a human being has to carry the information across the seam by hand: reading a quote out of the CRM and typing an order into the ERP, copying a new customer's details from one system to the other, checking a price in finance and pasting it back into a proposal.

Every one of those manual carries is a place where the two systems drift apart. Someone fat-fingers a quantity. A customer's address is updated in the CRM but not the ERP. A price agreed in a quote is not the price that gets invoiced. Within a few months you have two databases that disagree about basic facts, and the organisation quietly loses trust in both. Connecting them is not about saving a few minutes of typing. It is about maintaining a single, coherent version of the customer and the transaction as it moves from a sales conversation into a financial record. That is why the seam is worth engineering properly rather than papering over with a shared spreadsheet. For the wider picture of how Business Central sits inside the Microsoft stack, see the Business Central and the Microsoft ecosystem pillar.

2. Built-in Business Central CRM features versus full Dynamics 365 Sales

Before anyone reaches for an integration, there is a question that saves a great deal of money if you ask it honestly: do you actually need two systems at all? Business Central ships with a lightweight CRM capability of its own, and for a meaningful share of businesses it is enough. Understanding what that built-in capability covers, and where it runs out, is the first real decision.

Inside Business Central you already have contacts, a basic opportunity and sales-pipeline view, interaction logging, segments for simple marketing, and the ability to turn an opportunity into a quote and then an order without ever leaving the ERP. For a small trading or services business whose sales process is short, whose salespeople are also the people who raise the invoices, and whose relationships are relatively simple, this built-in CRM does the job. You get one system, one customer record, no integration to build or maintain, and no second licence to pay for. That is a genuinely good answer for the right organisation, and I have talked more than one client out of a CRM project they did not need.

Where the built-in capability runs out is in the depth of the sales discipline. Dynamics 365 Sales is a full CRM: richer lead and opportunity management, structured sales processes and stages, playbooks and guidance, deeper forecasting, territory and team management, tighter integration with marketing and customer service, and a user experience designed for salespeople who live in the system all day rather than dip into it to raise a quote. If your sales team is a distinct function from finance, if your pipeline is long and multi-touch, if you need serious forecasting, or if sales and marketing and service all need to share the same customer view, the built-in CRM will feel thin and the full product earns its place.

The honest framing I use: the built-in CRM is not a stripped-down Dynamics 365 Sales, it is a different tool for a different scale of problem. One is a convenience feature inside an ERP so that a small business does not need a separate system. The other is a dedicated sales platform that happens to connect to an ERP. Choosing between them is choosing how much of your business is really sales-led. Get that judgement right and you avoid both traps: paying for a heavyweight CRM you do not use, and outgrowing a lightweight one that cannot carry your sales process.

3. Dataverse as the shared data foundation

When you do run both Business Central and Dynamics 365 Sales, the thing that makes them talk to each other cleanly is Dataverse. This is the piece that people skip past because it sounds like plumbing, but it is worth understanding because it explains why the integration behaves the way it does.

Dataverse is Microsoft's shared data platform, the common store that sits underneath the Dynamics 365 applications and the Power Platform. Dynamics 365 Sales stores its data in Dataverse natively; accounts, contacts and opportunities are Dataverse tables. Business Central is a separate application with its own database, but it connects to Dataverse through a standard integration layer, and it can project selected records into Dataverse and read others back. So the way the two systems share data is not a direct point-to-point link between ERP and CRM. It is each system meeting at a common table in Dataverse and keeping its own copy in step with that shared table.

This matters for a practical reason. Because the shared ground is Dataverse rather than one system reaching directly into the other, each side keeps its own record and its own rules. Business Central still governs a customer as a financial entity with a credit limit and posting groups. Dynamics 365 Sales still governs an account as a relationship with owners and activities. The integration keeps a defined set of fields aligned between the two through their shared Dataverse representation, and couples the corresponding records so that the ERP customer and the CRM account are understood to be the same real-world entity. Neither system becomes subordinate to the other; they agree on a shared layer and each stays sovereign over its own domain.

The reason Microsoft built it this way, rather than forcing everything into one database, is that ERP and CRM genuinely have different jobs and different data models. Trying to make one be the other has failed every time it has been attempted. Dataverse as a shared foundation lets each system be what it is good at while still presenting a single coherent customer to the business. For a broader treatment of how Business Central exposes and consumes data across these boundaries, the Business Central APIs and integrations pillar goes into the mechanics.

4. What the standard integration syncs (accounts, contacts, items, quotes, orders)

The standard integration between Business Central and Dynamics 365 Sales is not a blank canvas where you wire up whatever you like. It ships with a defined set of couplings that cover the records both systems genuinely need to share, and understanding that default scope tells you most of what you need to know about how the connected pair behaves.

The core objects the standard integration keeps aligned:

• Accounts and customers: a Dynamics 365 Sales account and a Business Central customer are coupled as the same commercial entity. The relationship view in the CRM and the financial view in the ERP describe one real customer, kept in step so that both teams are looking at the same organisation rather than two loosely similar records.
• Contacts: the people you deal with inside those accounts flow across so that the salesperson's contact in the CRM and the contact attached to the customer in the ERP are the same person. This is what stops the two systems from developing separate, conflicting address books.
• Items and products: the things you sell are shared so that the CRM can build quotes and opportunities using the same catalogue the ERP will actually invoice from. Without this, a salesperson could quote a product the ERP does not recognise, and the order would fail at the handoff.
• Sales quotes: quotes can move between the two so that a quotation raised on the sales side and the quote understood by the ERP are consistent, which matters because the quote is the document that carries the agreed lines and prices toward becoming an order.
• Sales orders: an accepted quote becomes a sales order, and the order is where the CRM hands the transaction to the ERP for fulfilment and invoicing. This is the pivotal coupling, the point where a sales artefact becomes a financial commitment that the ERP owns from then on.

Alongside those primary objects, the integration also aligns the supporting reference data that the primary objects depend on, the currencies, units of measure, salespeople and price information that a shared quote or order needs in order to mean the same thing on both sides. The important mental model is that the integration is scoped deliberately: it shares exactly the records that have to be consistent for quote-to-cash to flow, and it leaves each system's private data private. Your general ledger does not appear in the CRM, and your salespeople's activity notes do not clutter the ERP. That restraint is a feature, not a limitation.

5. The lead-to-order flow across CRM and ERP

The clearest way to understand a connected ERP and CRM is to follow one transaction the whole way through and watch where the boundary sits. The lead-to-order flow crosses from CRM to ERP at a specific, well-defined moment, and knowing exactly where that moment is prevents most of the confusion about which system is responsible for what.

In the first stretch, everything happens in Dynamics 365 Sales. A lead is qualified into an opportunity. The salesperson works the relationship, logs activities, and when the deal is ready, builds a quote. Crucially, that quote is built from the shared item catalogue, so the products on it are real products the ERP recognises, and where price information is shared, the numbers on the quote are numbers the ERP will honour. The customer on the quote is a coupled account, so it corresponds to a real ERP customer with a credit position and terms. Up to this point the ERP has done nothing visible, but it has already lent the CRM its catalogue, its customers and its pricing so that the quote is grounded in financial reality rather than being a free-form proposal.

The seam is the moment the quote is accepted and becomes an order. This is where the transaction crosses into Business Central and the ERP takes ownership. From here the order is a financial commitment: it consumes availability, it is picked and shipped, it is invoiced, and the invoice posts to the general ledger and creates a receivable. The CRM can still see that the deal was won and can report on it, but it no longer drives the transaction. The ERP does, because everything from here is about fact and money rather than probability and relationship.

The discipline this flow enforces is valuable. Because the quote is built on shared master data, the handoff at the seam is clean: the order that lands in the ERP references customers, items and prices the ERP already knows, so it does not have to be re-keyed or reconciled. The salesperson never has to leave the CRM to check stock or pricing, and the finance team never has to retype a quote to turn it into an order. The seam is a single, well-defined crossing rather than a scattered set of manual carries, and that is precisely what makes a connected system worth the effort. For the ERP side of order handling once the transaction has crossed, see the Business Central sales order management pillar.

6. Keeping customer and item master data consistent

Everything above depends on one unglamorous discipline: the master data has to stay consistent across the two systems, and that consistency does not happen by accident. The whole value of a connected ERP and CRM collapses the moment the two disagree about who a customer is or what an item is, so this is the section that decides whether the integration is a help or a liability.

The first and most important decision is ownership. For every shared object you have to name a system of record: the one that is authoritative, the one that creates the master version, and the one that receives updates rather than making its own. For customers, the common and usually correct choice is that finance owns the customer master, because a customer is ultimately a financial entity with credit terms and a ledger position, and the discipline of creating one belongs with the people accountable for the money. The CRM then works with a coupled copy. For items and products, the ERP is almost always the system of record, because the catalogue, costing and inventory live there and a product that finance does not recognise cannot be sold. Whichever way you decide, the point is to decide, explicitly, and to build the process around it so that new records are created in the owning system and flow outward, rather than being created independently in both.

The failure mode when you skip this decision is duplication. A salesperson, keen and unaware of the ERP, creates a new account for a customer that already exists in finance under a slightly different spelling. Now there are two customers where there should be one, the integration couples the wrong pair or none at all, and the aged receivable does not line up with the pipeline. Multiply that across a busy sales team and within a year you have a master data mess that takes a painful cleanup project to untangle. The prevention is entirely procedural: a clear rule about who creates customers and items, a habit of searching before creating, and a coupling discipline so that when a CRM account and an ERP customer genuinely are the same entity, they are linked rather than duplicated.

The honest limitation: an integration synchronises records, it does not clean them. If your Business Central customer list and your CRM account list are already inconsistent before you connect them, switching on the sync does not reconcile the mess, it propagates it, and you end up with the same duplicates now formally coupled to each other. The right sequence is to clean and de-duplicate the master data first, agree the ownership rules, and only then connect the systems. Connecting dirty data is how a promising integration becomes a support ticket generator.

7. Pricing, availability and order promising from CRM

One of the strongest arguments for connecting the CRM to the ERP, rather than running them as islands, is what it does for the quality of a quote. A salesperson quoting in isolation is guessing at two of the most important facts in any deal: what the price should be, and whether the goods can actually be delivered. Connect the systems and both of those stop being guesses.

On pricing, the value of shared item and price data is that the numbers on a quote are the numbers the ERP will honour. When the salesperson picks a product from the shared catalogue and the applicable price flows from the ERP's pricing structure, the quote reflects the organisation's real, agreed pricing rather than whatever the salesperson remembered or approximated. That protects margin, because it stops well-meaning salespeople from quoting stale or invented prices, and it protects the customer relationship, because the price on the quote is the price on the invoice. A quote that survives contact with finance unchanged is a quote built on shared pricing data.

On availability and order promising, the ERP is the only system that knows the truth: what is in stock, what is on order, what is committed to other customers, and therefore what can realistically be promised. A CRM on its own cannot answer "can we deliver this by month end" because it does not hold inventory or the supply position. When the CRM can draw on the ERP's view of items and availability, the salesperson can shape a deal around what is actually deliverable instead of promising into a vacuum and leaving finance and operations to break the news later. The connected system moves the availability conversation to the front of the sale, where it belongs, rather than the moment of fulfilment, where it hurts.

The practitioner's point: the biggest wins from connecting CRM and ERP are not in the plumbing at all, they are in the quality of the promise the salesperson can make. Real prices and real availability at the point of quote mean fewer margins given away by accident and fewer delivery commitments that operations cannot keep. If you are building a business case for the integration, this is the value to lead with, because it shows up directly in protected margin and reduced broken promises rather than in a vague "efficiency" that nobody can measure.

8. When to use built-in CRM, when to add Dynamics 365 Sales, when to integrate a third-party CRM

The right architecture depends on the shape of your business, and there are really three sensible answers. The mistake is to assume the most capable option is the right one; often it is not.

• Use the built-in Business Central CRM when sales is not a large, distinct function. If the people who close deals are also the people who raise invoices, if the sales cycle is short, and if the pipeline is simple, the CRM features already inside Business Central give you one system, one customer record and nothing to integrate. This is the lowest-cost, lowest-risk answer and it is the correct one for a lot of small trading and services businesses. Do not buy a second system to solve a problem you do not have.
• Add Dynamics 365 Sales when sales is a serious function in its own right. A dedicated sales team, a long multi-touch pipeline, real forecasting needs, territory and team management, or a need to share the customer across sales, marketing and service all point to the full CRM. Because both products are Microsoft and share the Dataverse foundation, the standard integration is the natural path, and the connected pair gives sales its own platform while keeping finance sovereign over the money. This is the sweet spot the standard integration was built for.
• Integrate a third-party CRM when the business already has a CRM it will not give up, or when a specialist industry CRM does something Dynamics 365 Sales does not. Here you do not get the standard, Dataverse-based integration for free; you build and maintain the connection through Business Central's APIs and an integration approach that fits the third-party system. It is entirely doable, and sometimes the right call, but be honest that you are taking on the ongoing cost of a custom integration rather than adopting a supported one.

The judgement running through all three is the same: match the CRM to how sales-led the business actually is, and prefer the option with the least integration surface that still meets the need. Every connection you build is something you then have to own, monitor and maintain. The built-in CRM has none. The Dynamics 365 Sales integration is standard and supported. A third-party integration is custom and yours to keep running. That gradient of ownership cost should weigh heavily in the decision. If you are still deciding whether Business Central is the right ERP foundation at all, the is Business Central right for your organisation pillar is the place to start.

9. Common integration pitfalls (duplicate records, ownership, sync conflicts)

Across ERP and CRM integrations, the problems are remarkably consistent, and almost none of them are caused by the technology failing. They are caused by decisions not made, or made and not enforced. The recurring ones worth naming:

• Duplicate records. The single most common failure. A customer or item gets created independently in both systems, the coupling links the wrong pair or leaves both orphaned, and the two databases quietly diverge. The cause is always the same: no clear rule about which system creates the master and no habit of searching before creating.
• Undefined ownership. When nobody has decided which system is authoritative for a given field, both edit it, and every edit in one system fights the sync from the other. The record flickers between two values and neither team trusts it. Ownership has to be decided field by field for the contested attributes, not left to chance.
• Sync conflicts. The same record is changed on both sides between synchronisations, and the integration has to decide whose change wins. If you have not thought about conflict resolution in advance, the outcome is effectively random and someone's edit is silently lost. Deciding the direction of authority up front is what turns a conflict into a predictable outcome.
• Over-scoping the sync. The temptation to synchronise everything, on the theory that more shared data is better, backfires. Every extra coupled field is another surface for conflict and another thing to maintain. Sharing only what quote-to-cash genuinely needs is more robust than sharing everything just because you can.
• Connecting dirty data. Switching on the integration before cleaning the existing records propagates the mess and formalises it. The de-duplication and reconciliation work has to come before the connection, not after, because afterwards the two systems are actively keeping the duplicates in step.

Notice that every one of these is a governance problem rather than a software problem, which is good news, because it means the fix is within your control and does not depend on a vendor. The standard integration will do exactly what you configure it to do. Whether that produces a clean, trusted, connected customer or a formally-synchronised mess depends entirely on the ownership rules and data discipline you put around it. The technology is neutral; the governance is decisive.

10. A practical path to a connected CRM and ERP

If connecting Business Central and Dynamics 365 Sales is on your agenda, the sequence matters far more than the configuration screens. The path I would advise any organisation to follow:

• Step 1: decide whether you need two systems at all. Look hard at the built-in Business Central CRM first. If it covers your sales process, stop here and save yourself an integration you would only have to maintain. Only move on if the built-in capability genuinely runs out.
• Step 2: agree ownership before anything else. Name the system of record for customers, for items, for prices, and for each contested field. Write it down. This agreement is the foundation everything else rests on, and it is a business decision, not a technical one.
• Step 3: clean and de-duplicate the master data. Reconcile the customer and item lists across both systems before connecting them. This is the unglamorous, essential work that determines whether the integration starts clean or starts broken.
• Step 4: scope the sync to what quote-to-cash needs. Enable the standard couplings for accounts, contacts, items, quotes and orders, plus the reference data they depend on, and resist the urge to synchronise more than the process requires.
• Step 5: pilot on a controlled slice. Connect a limited set of customers and items, run real quotes through to real orders, and watch the seam behave before you scale. Prove the handoff is clean and the master data stays consistent on a small scale first.
• Step 6: operationalise the governance. Put the "search before you create" habit, the coupling discipline and the ownership rules into everyday practice, and monitor for the duplicates and conflicts that creep in over time. The integration is not a one-off project; it is an ongoing discipline that keeps two systems agreeing.

The pattern across all six steps is that the decisions come before the configuration. The Dataverse plumbing is well-built and Microsoft maintains it; you do not need to be a systems integrator to switch it on. What you do need is to have made the ownership calls, cleaned the data, and agreed the governance, because those are the things the software cannot decide for you and the things that determine whether the connected pair is trustworthy. For professional-services businesses in particular, where projects, contacts and billing all revolve around the same client, the Business Central for professional services pillar shows how this connected-customer discipline pays off across the whole engagement lifecycle.

Final thoughts

Sales lives in the CRM and money lives in the ERP, and the connection between them is not really about moving data, it is about maintaining one coherent customer as they travel from a first conversation to a settled invoice. Business Central and Dynamics 365 Sales give you a standard, Dataverse-based integration that handles that journey well: shared accounts, contacts, items, quotes and orders, a clean seam where an accepted quote becomes a financial commitment, and each system left sovereign over what it does best. The plumbing is genuinely good, and for the right organisation the connected pair removes an enormous amount of re-keying, reconciliation and quiet distrust between the sales and finance teams.

But the plumbing was never the hard part. The hard part is the set of decisions the software cannot make for you: whether you need two systems at all rather than the built-in CRM, which system owns the customer and the item and the price, how you clean the data before you connect it, and how you keep the two agreeing over time. Get those right and the integration is a quiet, reliable backbone that nobody has to think about. Get them wrong and you have two formally-synchronised versions of the truth that agree on nothing important. The technology is ready and supported. The judgement about ownership and discipline is the practitioner's contribution, and it is the difference between a connected business and a synchronised mess.

Related reading: Business Central and the Microsoft ecosystem, Business Central APIs and integrations, Business Central sales order management, Business Central for professional services, Is Business Central right for your organisation?.