Microsoft Dynamics 365 and B2B ecommerce: how to sync customers, pricing, orders and invoicing

B2B ecommerce has rules that B2C never needs to solve: each customer can have their own price list, their payment terms, their credit limits and even a different catalogue depending on the commercial agreement. When the company already uses Microsoft Dynamics 365 to manage those terms, the question stops being whether it is worth integrating it with the ecommerce and becomes how to do it without losing the B2B complexity along the way.

This article focuses on that specific case: what data to sync between Dynamics 365 and a B2B store, what to validate at the moment of the order, and how to structure the integration so it scales with the customer base.

Quick summary

• In B2B, price is not a product attribute: it is the result of a commercial relationship. The integration has to reflect that relationship, not copy a number.
• Two validations prevent most problems: the correct price per customer and the credit limit before confirming.
• A shared unique identifier per customer is the basic requirement; without it, commercial history splits in two.
• Querying the current terms in real time scales better than replicating them in the ecommerce.

What makes B2B integration different

In B2C, a product’s price is usually the same for every visitor. In B2B, the same product can have different prices depending on the customer, the purchase volume, the current agreement or the invoicing currency. If that logic lives only in Dynamics 365 and the ecommerce does not reflect it correctly, the customer sees a price they are not entitled to, which generates commercial friction, complaints and orders that later have to be corrected by hand.

There are three additional differences that directly impact the design of the integration:

• The catalogue can differ per customer. Restricted products, regional exclusives or lines only sold under a particular agreement.
• The order does not always end in an immediate payment. It can go against an account, which forces validating available credit before confirming.
• The buyer is not the account holder. Several people from the same company buy under the same commercial account, with different permissions and limits.

What data has to be synced

Data	Origin	Sync moment
Price lists per customer or segment	Dynamics 365	Real-time query or short cache
Volume discounts	Dynamics 365	In the cart calculation
Payment terms and currency	Dynamics 365	At login and at confirmation
Available credit limit	Dynamics 365	Validation before confirming the order
Catalogue visible per customer	Dynamics 365	At login
Customer creation and changes	Bidirectional with rules	Near real time
Orders	Ecommerce → Dynamics 365	Real time
Order and shipment status	Dynamics 365 → ecommerce	Near real time
Tax documents	Dynamics 365 → portal	On issuance

The credit limit is the data point that tolerates staleness the least. An order confirmed against credit that was already consumed creates a problem with no automatic solution: it has to be cancelled or escalated commercially.

Common errors in this integration

Showing a general price. The ecommerce shows the list price instead of the negotiated one. It is the most visible error for the customer and the one that erodes trust in the digital channel fastest.

Not validating credit before confirming. It generates orders that later cannot be invoiced. The real cost is not the order: it is the sales team’s time resolving the exception.

Duplicating customers. Without a shared unique identifier, the same company exists twice and the purchase history splits, with a direct impact on volume discounts and on commercial reports.

Replicating terms in the ecommerce. Manually loading each customer’s price lists into the platform works with twenty accounts and collapses with two hundred. Every renegotiation turns into a data entry task.

Not contemplating multiple users per account. When several people from the same company buy, you need to model who can see prices, who can confirm orders and up to what amount.

Ignoring order status. In B2B, the buyer needs to know what was dispatched, what is pending and what was invoiced. An ecommerce that does not return that information forces the customer to call, which is exactly what the digital channel was meant to avoid.

How to structure the integration so it scales

As the customer base grows, with each customer having their own terms, the integration needs to handle dynamic rules instead of a fixed mapping between customer and price. The practical difference:

Replicated approach. Terms are copied from Dynamics 365 to the ecommerce and kept in sync. It works with few customers and few rules. Maintenance cost grows with every new account and every renegotiation, and there is always a staleness window.

Queried approach. The ecommerce asks Dynamics 365, through the integration layer, what the current terms are for that customer at the moment of showing the price and of confirming the order. Adding a new customer requires no development, and the terms are never out of date.

The queried approach demands attention to performance: a short-lived cache for data that changes rarely, a direct query for available credit, and a defined behaviour if Dynamics does not respond (showing the price from the last valid query and blocking confirmation, for example). That combination is what makes it possible to sustain hundreds of accounts without per-customer development, and it is the same logic behind a unified customer view across CRM, ERP and channels.

Frequently asked questions

What is the difference between integrating Dynamics 365 Business Central and Finance & Operations? Both expose modern APIs, but they differ in the data model and in how commercial entities are structured. The logic of the B2B integration is equivalent; the field mapping and the entities to query change depending on the edition.

Can a personalised price be shown without the customer logging in? Not reliably. The B2B price depends on the commercial relationship, so it requires prior identification. A common practice is to show a list price or request registration to see terms.

How is the credit limit handled in real time? By querying available credit in Dynamics 365 at the moment of confirming the order and blocking confirmation if it is not enough, with a clear message and a commercial escalation path. Validating it only at the start of the session is not enough: the balance can change while the customer builds their order.

Should the ecommerce create new customers in Dynamics 365? Yes, as long as there is a prior validation by tax ID and an approval circuit where appropriate. In B2B, creating an account means defining commercial terms, and that is rarely automatic.

What happens if Dynamics 365 does not respond? It has to be defined in advance. The usual approach is to allow browsing and cart building with the last valid information, but block order confirmation until the terms can be verified. What must not happen is confirming an order with unvalidated data.

Checklist to integrate Dynamics 365 with your B2B ecommerce

• Does each customer see in the ecommerce the price list they are entitled to according to Dynamics 365?
• Is the available credit limit validated before confirming the order?
• Do customers share a unique identifier across both systems, with no duplicates?
• Is the case of several users buying under the same account modelled?
• Is a change in commercial terms reflected without a manual load in the ecommerce?
• Can the customer see the status of their orders and their documents in the portal?
• Does adding a new B2B customer require development, or is it resolved with the existing integration?

You may also be interested in reading:

• “Migrating to the cloud: keys to integrating Microsoft Dynamics with your online store” • “Customer 360 in retail: how to connect CRM, ecommerce, ERP and POS without duplicating customers” With Weavee’s Dynamics 365 integration with your e-commerce, your B2B store queries prices, terms and available credit in real time, so adding a new account does not require custom development.