A bakery distributor with 120 trade customers takes most orders by phone and e-mail, and customer service retypes them into Dynamics 365 Finance and Operations. For a B2B ordering portal, there are four realistic routes. They differ less in how the shop looks than in where prices, assortment and orders live.

Why trade customers want to order online

Take customer C-1042, a group of four cafés. Its buyer orders the same twelve lines twice a week, led by Sourdough 800 g. The order arrives as an e-mail: “same as last week, but 40 sourdough instead of 30”. Someone finds last week’s order and hopes the café meant loaves, not trays.

Online ordering fixes three things:

Fewer calls and e-mails. The buyer orders and checks status without calling, and customer service stops retyping.
Fewer entry errors. The buyer picks from their own list, in the unit they buy, so 40 cannot become 400.
Orders outside office hours. An order placed at 10 p.m. is waiting before the first shift starts.

Trade buyers want their list, their prices and a fast way to repeat last week.

Four routes to B2B ordering on Finance and Operations

1. Dynamics 365 Commerce B2B

Commerce is Microsoft’s own option, and for some companies it is the right one. A Commerce B2B site uses the same storefront modules as a consumer site and adds B2B features. Business partners request access, and approval in Commerce headquarters creates their customer records and customer hierarchy.

B2B catalogs decide which products a partner sees. Each catalog is linked to customer hierarchies and price groups, and the trade agreements and discounts linked to those price groups apply. Contract prices can come from sales agreements. Buyers also get quick entry by item number, invoices and their account balance.

Setting it up is a Commerce implementation: enable the B2B feature, set up customer hierarchies, validate, approve and publish catalogs, build the pages in site builder and configure an identity tenant for sign-in. The storefront runs on the Commerce Scale Unit. Commerce fits best when you also want a content-rich site, sell to consumers, or already run Commerce in stores or a call center.

2. A custom portal on Power Pages or on data entities

To let customers order online in Dynamics 365 Finance and Operations without Commerce, the first alternative many teams consider is a custom portal.

Power Pages is Microsoft’s low-code platform for external-facing websites on Dataverse. Finance and Operations data entities are available in Dataverse as virtual entities, so a portal can read and write data that stays in Finance and Operations. Microsoft also publishes a Customer portal template for Supply Chain Management, built on Power Apps portals and dual-write, and says the template by itself isn’t expected to be completely functional. The other path is a web application on the OData endpoint, authenticating as a Microsoft Entra application mapped to a dedicated service account.

Either way, you own the code, hosting, sign-in, price logic and testing after every service update. The portal fits your process exactly, and you now maintain a software product.

3. A third-party storefront with a connector

Established storefront platforms bring mature search, themes, product content and often online payment. A connector copies customers, products and prices into the storefront and sends orders back.

Examine the copy. The storefront usually has its own price model and customer rules, and the connector translates your agreements into them on a schedule. That works when the mapping is simple and someone owns it. Expect separate contracts for the storefront, the connector and its configuration.

4. An ordering store managed inside Finance and Operations

The fourth route turns the model around. The store is a front end, and the rules live in Finance and Operations: which customers are published, which products they see, which prices apply. Orders go back as sales orders, and master data stays with the people who maintain it today.

This route is narrower: built for trade customers who reorder, not for marketing content or consumer sales. Check how its module installs and what security it needs.

The pricing test: trade agreements, sales agreements, base price

Prices are where B2B ordering projects fail quietly. In Finance and Operations, a trade price normally comes from one of three places:

Sales agreements. A customer’s commitment to a quantity or amount over time, in exchange for special prices. Its prices and discounts override trade agreements, and an order qualifies when its requested ship date falls inside the validity period.
Trade agreements. Price lines for one customer (Table), a customer price group (Group) or all customers (All), with quantity breaks and dates.
Base price. The price on the Sell tab of the released product, the fallback when no trade agreement applies.

Run one test with every option. Give C-1042 a sales agreement on Sourdough 800 g, put the café group in a customer price group with a trade agreement, and keep the base price. Ask the store for the price on a delivery date inside the agreement, a date after it expires, and a quantity above a price break. The sales order lines in Finance and Operations must match every time.

A second price list in the store fails this test sooner or later. Every price change is made twice, a trade agreement journal posted on Friday is missing until someone exports it, and order lines not linked to the sales agreement do not count toward its fulfillment. Prices should come from Finance and Operations, which ideally prices the order line itself.

Commerce prices its channels with its own pricing engine, and Microsoft documents where it differs from Supply Chain Management pricing, for example on pricing by requested ship date. Test those cases too.

Assortment: who sees which products

A distributor rarely shows every product to every customer. Private label is for one chain, catering packs for restaurants, seasonal items for six weeks. Some customers should see prices but keep ordering by phone.

Ask where that rule lives. In Commerce, it is the B2B catalog, and Microsoft notes that once catalogs are enabled, a partner without one finds no products. In a custom portal, it is whatever you build. With a connector, it usually lives in the storefront. In a store managed inside Finance and Operations, it sits on the customer and product records.

When you release a new item on Monday, how many systems does someone touch before C-1042 can order it?

How orders land in Finance and Operations

Every web order should become one sales order with the online order reference, so customer service can tell it from a phone order, and the buyer should see its number and status.

Then ask what happens when Finance and Operations is unreachable. Microsoft runs planned maintenance in each region’s dark hours and describes it as near-zero downtime, with possible brief interruptions. Integrations can also receive a “Too many requests” error when system health is affected. An order placed at 2 a.m. must wait, be sent again, never create a duplicate sales order, and appear in a list your team can see.

Commerce handles this in its own channel layer: online transactions are pulled into headquarters, and a Synchronize orders job creates the sales orders, both as recurring batch jobs. A custom portal needs that logic built. For a connector, ask to see its error queue.

Repeat buying: last order, suggested reorder, standing orders

Most trade orders are repeats. Look for repeat last order, a suggested reorder list, standing orders such as “Tuesday and Friday, the same three products” that the customer can still change, and sales reps ordering on behalf of a customer with a record of who did it.

For customer standing orders in D365, standard Finance and Operations has no standing order schedule. The Subscription order type keeps one order open for repeated invoicing, and it cannot be used with Warehouse management. Staff can create orders from a sales agreement with the Release order action, one at a time. Neither creates dated orders on a weekly pattern, and neither gives the buyer a screen to manage their own schedule.

Commerce B2B sites offer order templates, quick and bulk order entry and reorder from order history, and account managers can order on behalf of a buyer, with those orders prefixed with the account manager’s name. Out of the box, nothing submits an order on a schedule; that would take a custom extension.

Questions to ask before choosing

How many buyers? 120 trade customers with a few buyers each is a different project from thousands of consumer accounts.
What is the cost model? Per order, per user or per customer account, plus implementation and running costs. For the Microsoft side, check licensing with your Microsoft partner.
Where does the admin work live? Who publishes a new item or changes a price, and in which system?
Who maintains the integration? Who tests the store after each service update, and who gets the call at 7 a.m. when orders did not arrive?
What else do you need? Consumer sales, marketing content and card payment point toward Commerce or a storefront. Fast reordering on account points toward a custom portal or a store managed inside Finance and Operations.

Where Modax Online Store fits

Modax Online Store is the fourth option above: an ordering store managed inside Finance and Operations. Finance and Operations is the master for customers, products, prices, payment terms and addresses, and the store keeps no price list of its own. Modax hosts the store; the only install on your side is a module inside Finance and Operations with its own security role, connecting through the standard data entities with a service account you control.

Prices come from the sales agreement, then the trade agreement, then the item price, or the rule you choose for that customer. Publishing is a checkbox on the customer and on the released product. Assortment groups decide which products a customer sees, with exceptions per customer. Each customer can have full ordering or view only, with returns allowed or blocked.

Each order becomes a sales order carrying the online order reference, and if Finance and Operations cannot be reached, orders queue and are sent again. Buyers get repeat last order, a suggested reorder list, standing orders they can edit, for which the store creates the order automatically on the days the buyer picks and sends it straight to Finance and Operations, their balance and invoices with PDFs, and sign in with an e-mail link instead of a password. Sales reps can order as the customer, and the activity log records it. Orders follow the payment terms in Finance and Operations; a payment gateway is a separate project. There is no fee per order and buyers are not counted: plans are sized by the number of customer accounts.

If your trade customers reorder the same products every week, see the Modax Online Store or talk to us.

B2B Ordering Portal for D365 Finance and Operations: 4 Options