One-Point Selling: Integrating Seller Central and Vendor Central with Dynamics 365

Seller Central (3P) and Vendor Central (1P) are two different commercial relationships with two different technical protocols. SP-API against your own listings. EDI or vendor APIs against Amazon’s purchase orders. Dynamics 365 unifies them by normalising both into the same Sales Order object, tagged by a Channel dimension and driven by a Purchasing Code. Once both channels land as sales orders, one-point selling, including drop shipment where the order flows straight to a supplier or is fulfilled inside the marketplace’s own network, becomes a routing decision, not a separate system.

Most brands end up on both. They start 3P on Seller Central because it is fast and they keep the margin. Then a category manager offers a 1P Vendor Central account, and suddenly there is a second order stream with a different protocol, different chargebacks, and a different definition of “sold.” Add a drop-ship supplier and a Direct Fulfilment programme, and the operations team is now running four mental models with one spreadsheet.

This article covers the commercial difference, the technical mapping into Dynamics 365, and how in-network drop shipment actually posts.

First, get the commercial model right — the tech follows

Almost every failed Amazon ERP integration begins with someone treating a Vendor Central PO as if it were a Seller Central order. They are not the same transaction and they do not post the same way.

Seller Central (3P): you are the seller of record

You own the listing, you set the price, you own the customer relationship and the tax obligation. Amazon takes a referral fee and, if you use FBA, a fulfilment fee. Your revenue is the retail price; the fees are a cost. Financially, this is a B2C sale with a distribution partner.

Vendor Central (1P): Amazon is your customer

Amazon issues a purchase order at a negotiated wholesale cost, takes title, and resells. You never see the end consumer. Your revenue is the wholesale cost, and the deductions (co-op, damage allowance, chargebacks for late or non-compliant shipments) are the margin killers. Financially, this is a B2B wholesale sale to a large, procedurally unforgiving customer.

The integration architecture that holds up

Whether you are on Business Central or Finance and Operations, the shape is the same. Four layers, each with one job. This is the architecture behind a reliable Amazon ERP integration.

Layer 1: Channel adapters

Seller Central: SP-API. Orders API for order retrieval, Feeds API for inventory and price updates, Reports API for settlement, FBA Inventory API for network stock, Merchant Fulfilment for labels. LWA OAuth tokens, restricted-data tokens for PII, and hard rate limits you must respect.

Vendor Central: EDI over AS2 or VAN: 850 (PO in), 855 (acknowledgement out), 856 (ASN out), 810 (invoice out), 997 (functional acknowledgement), or the vendor-facing APIs for orders, shipments, invoices, and direct fulfilment.

Other marketplaces: Walmart, Flipkart, Zalando, Shopify. Same principle: an adapter per channel, never channel logic in the ERP.

See How Rebelution Replaced QuickBooks and Spreadsheets with a Centralized ERP

Layer 2: Middleware and canonical model

Azure Logic Apps, Azure Functions, an iPaaS, or a marketplace ISV. This layer translates every channel into one canonical order shape and owns the ugly parts: retries with exponential backoff, dead-letter queues, throttling, mapping tables, and the audit log. Put channel-specific logic here, not in AL or X++. When Amazon changes an API version, you change one adapter.

Layer 3: Dynamics 365

The ERP receives a normalised order and does what it is good at: pricing validation, availability, costing, posting, and the ledger. It should not know what an ASIN is beyond a cross-reference.

Layer 4: Reconciliation and analytics

Settlement reports, remittance advice, chargeback files. This layer answers the only question that matters: for every order the channel says happened, is there a posted document and a matched cash receipt?

Data mapping: the table that prevents six months of rework

One-point selling and the drop-shipment models

“One-point selling” means the order is captured once, in one place, regardless of who fulfils it. The customer sees one brand. Your ledger sees one document chain. The physical goods may never touch your warehouse, and that is the entire point.

There are three distinct patterns, and they post differently. Confusing them is where inventory and margin reporting goes wrong.

Pattern A: Supplier drop shipment (native D365 drop shipment)

You take the order; your supplier ships directly to the end customer. Goods never enter your warehouse.

Business Central does this natively and it is one of the most underused features in the product:

• On the Sales Line, set Purchasing Code = DROPSHIP (a Purchasing Code with Drop Shipment = Yes).
• Set the Purchasing Code default on the item or the vendor so this is automatic, not remembered.
• Open the Requisition Worksheet, then Drop Shipment, then Get Sales Orders. Or create the PO manually and use Drop Shipment, then Get Sales Order on the purchase order.
• The system creates a Purchase Order linked to the sales line via the Sales Order No. / Sales Order Line No. fields, and stamps the Ship-to as the end customer.
• Posting the Purchase Order receipt posts the sales shipment simultaneously. Cost and revenue land in the same instant. Inventory quantity never increases.

Two things follow that matter for accounting. First, COGS is the actual purchase cost, not an average across your warehouse: margin per drop-ship order is exact. Second, you cannot post the sales shipment independently, which is the control that stops phantom revenue.

Pattern B: In-network drop shipment (the marketplace fulfils)

Here the marketplace’s own logistics network does the shipping, from stock you have already placed inside it. On Amazon this is FBA for 3P and Multi-Channel Fulfilment when an FBA-held unit fulfils an order from your own website or another channel.

The ERP modelling problem is that your stock is real, valued, and yours, but it is not in your building. The correct treatment:

• Model the network as a Location. Create Location AMZ-FBA. It is a real location with real inventory value. It is not a black hole and it is not written off.
• Inbound shipments are Transfer Orders. Your warehouse to AMZ-FBA. In-transit is visible, and the receipt is confirmed from the FBA inventory feed, not assumed.
• Orders ship from that Location. The 3P order posts a shipment out of AMZ-FBA. Inventory decrements where it actually decremented.
• Reconcile the network position on a schedule. The FBA Inventory API against the Item Ledger, daily. Differences are adjustments with a reason code: lost, damaged, reimbursed, not a plug.
• Cross-channel fulfilment is a Location decision. An MCF order (your website, fulfilled by the marketplace) is the same sales order with Location = AMZ-FBA. One order object, different shipping origin.

Pattern C: Direct Fulfilment (1P drop shipment)

The one people miss. Under Amazon’s Direct Fulfilment programme (historically Drop Ship Vendor), Amazon takes the consumer order, but you (the 1P vendor) ship it directly to the consumer under Amazon’s carrier labels and SLA.

Commercially, it is still 1P: Amazon is your customer, you invoice at wholesale cost, the consumer is Amazon’s. Physically, it is a drop shipment from your warehouse. That split is exactly why it breaks naive integrations.

Modelled in Dynamics 365:

• Sales Order to the Amazon Vendor customer, because the money comes from Amazon at wholesale cost.
• Ship-to = the end consumer, populated from the DF order payload, not the customer card.
• A distinct Channel dimension value (Amazon 1P-DF), because its cost-to-serve is nothing like bulk 1P.
• Label and packing-slip retrieval, and shipment confirmation, inside the SLA window: this is where chargebacks are won or lost.
• Invoice posts at wholesale cost, exactly as with a bulk PO.

Read more: Business Central eCommerce Integration: B2B and B2C on One ERP

Reconciliation: where the money is actually lost

Integration teams celebrate at first successful order import. The finance team finds out three months later that nothing ties out. Build these from day one, not after the first bad quarter.

• Order-to-document completeness. A daily job comparing channel order IDs against External Document No. in D365. Any gap is an alert with an owner, not a report nobody opens.
• Settlement to ledger. The 3P deposit is net of fees, refunds, and reserves. Post the gross revenue, the fee lines, and the refunds separately, then apply the deposit. If you post only the net, you have destroyed your own margin analysis.
• Chargeback attribution. Every 1P deduction gets a reason code and a link to the PO. Unattributed deductions become permanent; attributed ones get disputed and often recovered.
• Network stock reconciliation. Item Ledger at AMZ-FBA versus the FBA inventory feed. Reimbursements for lost units are revenue, but only if you notice.
• Drop-ship confirmation. A supplier PO receipted in your system but never shipped by the supplier is revenue you have posted and a customer you have failed. Require tracking-number confirmation before posting.

Read about how Klizer helped Rebelution automate warehouse allocation with Business Central

Six failure modes, and what to do instead

• Treating a 1P PO as a 3P order. Revenue posts at retail, margin looks fictional, and the deductions have nowhere to land. Separate the customers, the posting groups, and the dimension values from the start.
• Renaming your item master to ASINs. Now you cannot sell the same item anywhere else. Use Item References.
• No idempotency key. A retried webhook creates a second sales order, a second shipment, and a very awkward conversation. Unique index on External Document No.
• FBA stock modelled as “gone.” Your balance sheet is wrong and your buyers reorder blind. Model it as a Location.
• Posting only the net settlement. You have hidden your fee structure inside revenue and can never negotiate it. Post gross, fee, and refund separately.
• Channel logic written inside the ERP. The next API version change becomes an ERP release. Keep it in the adapter.

Frequently asked questions

What is the difference between Amazon Seller Central and Vendor Central?

Seller Central (3P) means you are the seller of record: you list, you price, you sell to the consumer, and Amazon takes a referral fee. Vendor Central (1P) means Amazon is your customer: it issues purchase orders at a negotiated wholesale cost and resells to consumers itself. They are different commercial relationships and use different technical protocols.

Can Dynamics 365 handle both Seller Central and Vendor Central at the same time?

Yes. Both normalise into the same Sales Order object, separated by customer, posting group, and Channel dimension. 3P orders arrive via SP-API; 1P orders arrive as EDI 850 purchase orders or vendor APIs. Both are typically brokered through a middleware layer rather than integrated directly.

What is in-network drop shipment?

It is fulfilment performed by the marketplace’s own logistics network from inventory you own but have placed inside that network: Amazon FBA for marketplace orders, and Multi-Channel Fulfilment when the same stock fulfils an order from your own website. In the ERP it is modelled as a separate inventory Location, not as inventory that has left your books.

How does drop shipment work in Business Central?

Set a Purchasing Code flagged as Drop Shipment on the sales line, then create the linked purchase order via the Requisition Worksheet’s Drop Shipment function. Posting the purchase receipt posts the sales shipment at the same time, so inventory never increments and COGS equals the actual purchase cost.

What is the difference between a drop shipment and a special order in Business Central?

A drop shipment goes from your vendor directly to your customer and never enters your warehouse. A special order is purchased against a specific sales order but is received into your warehouse first, then shipped. Use special orders when you consolidate, kit, or re-label.

Do I need EDI for Vendor Central?

You need EDI or the equivalent vendor APIs at any meaningful volume. Manual portal entry works for a handful of POs a week and stops working immediately after that: and manual entry is exactly where SLA chargebacks originate.

How do I stop selling stock twice across channels?

One item ledger, availability calculated centrally, and a published availability figure per channel with a buffer. Overselling is almost always caused by two systems each holding a stock number, not by insufficient stock.

If your Dynamics 365 Amazon integration is still a gap in your architecture, Klizer builds the connected commerce layer between ERP, marketplace channels, and ecommerce storefronts for manufacturers and distributors. Book a free consultation to map your integration requirements.