Connect the store you have to Business Central

Business Central is a different product from Dynamics NAV 2018. The store already takes orders. We will tell you whether those orders should become salesOrders on API v2.0, and why a NAV SOAP integration will not get you there.

Australian team. We look at the store and the BC environment before anyone talks about a connector.

Still running a store that needs Business Central?

The store still takes orders. Finance still lives in a Microsoft ERP. That is why the connection has been left as a CSV, a NAV-era SOAP page, or someone re-keying sales orders after checkout.

Dynamics 365 Business Central is Microsoft’s cloud — and on-prem — ERP for SMBs: finance, sales, purchasing, inventory. It is the successor product line to Dynamics NAV. Successor is not the same as “same API”. NAV 2018 and Business Central are different products.

Microsoft ships an Australian localisation: GST posting, BAS business units, withholding tax, ABN, EFT, Peppol PINT A-NZ e-invoicing, and payment-times reporting, with further PTR and TPAR work planned in the 2026 wave 1. Australia (en-AU) is on Microsoft’s country availability list. That is localisation, not an install-base figure, and it is not why you should hire us.

You might recognise one of these:

  • You moved from NAV to Business Central, and the store still talks to the old company
  • Someone said “we already integrate Dynamics” because a NAV 2018 project exists
  • Web orders sit in the store until someone keys a sales order in BC
  • Site stock is a NAV export that nobody refreshed after the upgrade
  • Checkout still assumes NAV payment terms, and BC customers do not match
  • You are not sure whether the store should POST salesOrders or salesInvoices

You do not need a new storefront. You need a clear read on which Microsoft product you actually run.

Why these connections stall

Business Central has a real API. Preferred is the built-in REST API v2.0 at /api/v2.0/, with OAuth 2.0. Microsoft also documents OData V4 on published pages and queries, and SOAP — SOAP “replaced by OData V4”, with support to be removed in a later release. Connect apps are point-to-point using the standard REST API. The stall is rarely “BC has no API”. It is treating NAV as BC.

Not NAV 2018

API v2.0

SOAP is leaving

AU localisation

NESS is NAV 2018, not Business Central.

We published a B2B nopCommerce store for NESS Corporation, fully integrated with Microsoft Dynamics NAV 2018. NAV sent customers, pricing and products to the store. The store sent web orders, line items and freight back. SOAP Page integration moved to Codeunits returning JSON. Checkout used NAV payment terms, billing from NAV, and order history including credit notes. That is NAV 2018. It is not Business Central, not Dynamics 365, and not API v2.0. We will not use it as proof we have delivered BC.

REST API v2.0 is the preferred door.

v2 resources include customers, items, salesOrders, salesOrderLines and salesInvoices. Typical store jobs: sync customers and items; POST salesOrders with the web order as the external document number; POST salesInvoices where the merchant invoices from the store; pull stock from items or locations via the API or custom API pages. Basic auth and access keys were deprecated for BC online from October 2022. A leftover NAV access-key habit will not pass.

SOAP is not the new-build path.

If the current connection is SOAP pages from a NAV-era partner, Microsoft is already telling you to move. OData V4 is the documented replacement for SOAP. New ecommerce work should be REST API v2.0 and OAuth 2.0, not another SOAP page.

Australian localisation is in BC, not in a plugin we invent.

GST, BAS, ABN, EFT and Peppol PINT A-NZ sit in Microsoft’s AU local functionality. The integration has to respect those posting and tax fields. It does not become “we localise Business Central”. We connect the store to the environment you already run.

None of that makes the customer list or the item master worthless. It does mean “point the NAV integration at BC on Monday” is usually the wrong first move.

How we work

We start with which Microsoft product you run, not with “Dynamics”.

1

Look at what you have

Business Central online or on-prem, API v2.0 availability, leftover SOAP or OData pages, AU localisation in use, and the store (nopCommerce, AbleCommerce, Shopify, or another CMS). If you are still on NAV 2018, we will say so — that is a different job.

2

Decide the job

There are three honest outcomes. We recommend one, not all three.

3

Do the work in stages

Customers and items down; salesOrders up with a stable external document number. salesInvoices only when the store owns invoicing. Stock from items or locations when the site must show a number. NAV-era SOAP pages do not get a second life because they still respond.

4

Hand it back so the next person can run it

Source, the Entra app and scopes, a short record of what posts which way, and a connection someone else can understand.

Three honest outcomes

  • Connect the store to Business Central on REST API v2.0 when you are actually on BC: sync customers and items, POST salesOrders (and salesInvoices only if the store invoices), pull stock from items or locations
  • Fix a broken connector when a NAV-era SOAP page, access-key habit, or early-BC job still almost works: move it onto OAuth and v2.0, and stop treating the tenant as NAV 2018
  • Decide not to connect when the live ERP is still NAV 2018 (a different job — that is the NESS-shaped product, not this page), when an AppSource commerce connector already owns posting, or when the store should only read items and orders should stay in BC

We will not tell you NESS is a Business Central case. We will not say we already integrate Dynamics 365. If you already know you want an AppSource ecommerce connector and nothing custom, that marketplace is a better fit. If you want an honest design for the environment and the store you already have, talk to us.

What we need for the first call

A store URL and which Microsoft ERP is enough to start.

  • Which store: nopCommerce, AbleCommerce, Shopify, or another CMS — and a URL
  • NAV 2018, another NAV, or Business Central — online or on-prem
  • Whether API v2.0 is enabled, and whether SOAP or OData pages still exist
  • Whether a web order should become a salesOrder, a salesInvoice, or both
  • Whether AU localisation (GST, BAS, Peppol) is already in the company
  • What already posts, and to which environment
  • What “done” looks like: API v2.0 orders, finish a NAV path, or get a clear picture first

The first call is 30 minutes. You leave with a recommendation you can take to a manager, not a connector estimate pulled from thin air.

Related work

NESS Corporation is a B2B nopCommerce store fully integrated with Microsoft Dynamics NAV 2018. Related Microsoft ERP work. It is not Business Central, not Dynamics 365, and not a case we will retitle. We have not published a named CoSource ecommerce case for Business Central. Windsor is Peach and Xero. A BC environment still starts with its own assessment.

FAQ

Is this the same as the NESS project?
No. NESS is NAV 2018, SOAP pages moved to Codeunits returning JSON. Business Central is a different product and API v2.0.
Can we keep the NAV SOAP integration?
Microsoft recommends migrating off SOAP to OData V4; SOAP support will be removed in a later release. New store work should be REST API v2.0 and OAuth 2.0.
Should the store post invoices or sales orders?
POST salesOrders when ERP invoices. POST salesInvoices when the merchant invoices from the store. Doing both without a design is how documents duplicate.
Do you have a Business Central case study?
No named published ecommerce case for BC. NESS is NAV 2018.
What if we only have the live store and a BC login?
That is common. Bring that.

Talk through the Business Central connection you already need

Thirty minutes. Bring a store URL and which Microsoft product you run. We will tell you whether to build on API v2.0, treat it as NAV 2018, or leave the current path alone for now.

Book a free 30-minute discovery call