How to handle ecommerce when you migrate from e-conomic to Business Central

Short answer.

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at keeping the stack you already have, and knowing which one you're facing is worth more than paying twice for the same capability.

Nothing forces a move from e-conomic, because e-conomic and Dynamics 365 Business Central are both on Erhvervsstyrelsen's register of approved digital bookkeeping systems, and e-conomic is cloud SaaS with no version to fall out of support. What brings companies here is everything e-conomic was never asked to hold: no inventory module in any package, no product variants, no stock locations, one sales price per product, and no price group on the customer record. The API isn't the obstacle, because Business Central online is API-only too. The obstacle is direction: e-conomic's web shop pushes the catalogue down into the accounts, and Business Central's ERP pushes the catalogue up into the shop, so every arrow has to be redrawn.

Two routes make Business Central the system of record without turning that redraw into a project: move B2C to Shopify with Microsoft's Shopify Connector, or move B2B into Business Central with Abakion B2B Ecommerce. Keeping the existing app stack and rebuilding only the accounting link is the third route, and several of those apps already support Business Central.

What are the three options, and how do they compare?

There are three real options for ecommerce when you migrate from e-conomic to Business Central, and for an e-conomic company the first comes with unexpected good news.

1. Keep the app stack you have and rebuild only the accounting link. Several of the vendors in your current stack already support Business Central: IEX does, Storebuddy does alongside Billy, Dinero, Zenegy and Uniconta, Rackbeat does through IEX, and Ongoing WMS does. So the subscriptions can follow you across.
2. Move B2C to Shopify and use Microsoft's Shopify Connector.
3. Move B2B into Business Central with the Abakion B2B Ecommerce app.

The question worth asking about the first option is whether you should take it. You assembled that stack because e-conomic couldn't hold stock, variants, locations or customer prices. Business Central holds all four. Keeping every subscription after the constraint disappears is how a business ends up paying twice for the same capability, once to an app and once inside its ERP.

Does the Danish bookkeeping act force a move from e-conomic?

No. Both systems are on Erhvervsstyrelsen's register of approved digital bookkeeping systems, so Danish law is neutral between them.

e-conomic was registered on 19 December 2023 and Dynamics 365 Business Central two days later, on 21 December 2023. e-conomic knows this and uses it in the other direction, running a landing page selling migration from C5, NAV and XAL into e-conomic argued almost entirely on that same register, and notably saying nothing at all about stock, production or order-to-cash.

There's no version to fall out of support either. e-conomic is cloud SaaS, unversioned, and its own API documentation says plainly that it offers no versioning.

So the ledger isn't why you're reading this. What brings companies here is everything e-conomic was never asked to hold.

What does e-conomic not include that a web shop needs?

Inventory, orders on the entry package, variants, stock locations, and customer-specific pricing readable through the API most connectors use.

Look at what e-conomic actually includes, because the shape of the answer is the shape of your project.

There's no inventory module in any package. Stock is an app, sold as Lager af Rackbeat from 349 kroner a month, and e-conomic describes it in its own words as a dedicated system for stock management that talks to your accounting. Rackbeat is itself a Visma company, and what it covers is multiple warehouses, variants, serial and batch numbers, purchasing, production and bills of material. That's the inventory half of an ERP, rented monthly.

Orders and quotes aren't in the entry package. They start at Plus. So does free access to integrations: on Basis you can integrate with a named list of payroll systems and nothing else. Customer special prices, product bundles and language layers are all Plus and above too.

And e-conomic is explicit that this is the strategy rather than a gap. Its own comparison page against Uniconta, Business Central, SAP and NetSuite argues that with e-conomic you assemble your own solution, with no advanced development or deep technical expertise, choosing from more than two hundred industry-specific integrations.

Which means most e-conomic web shops are running an ERP nobody bought. There's a shop, a stock app, a warehouse system, a bookkeeping robot reconciling payment provider payouts, a shipping tool, and e-conomic underneath receiving the accounting.

That's a legitimate way to run a business, and it works. It's also the thing you're actually migrating.

Is the e-conomic REST API a problem for moving to Business Central?

No. The API is fine and Business Central online is the same shape. What changes is the direction the data flows.

e-conomic has a real REST API at `restapi.e-conomic.com`, authenticated with an app secret token and an agreement grant token, with 28 stable resources including products, product groups, customers, orders, quotes and invoices, pagination up to a thousand records a page, and since December 2025 a cost-based rate limit that reports what each call spent in an `X-CallCost` header. There's a newer OpenAPI at `apis.e-conomic.com` that Visma has been migrating resources onto since 2024, including products in August 2024, with webhooks arriving there in May 2026. SOAP has been retired in batches since December 2022.

None of that is hard to leave behind, because Business Central online is API-only too. In Microsoft's words, the only supported option for reading data is using APIs. Tokens, entities, HTTPS, rate limits. The people who built your e-conomic integration will recognise what they're building.

The problem is the direction.

Read how the Danish integrators describe the two systems, because they say it plainly. On e-conomic, products typically transfer from the web shop to the accounting, and orders are fetched from the shop at a given order stage and passed into the accounts. On Business Central, the same vendor describes creating and updating products including all product data and prices going outbound from the ERP, and synchronising customers, products and stock.

Your API isn't the problem. Every arrow in your integration is pointing the wrong way.

That isn't a small change, and it isn't a technical one. Today your shop is the master of the catalogue and e-conomic is the destination. In Business Central the ERP is the master and the shop is the destination. Everybody in the project has to agree on that before anybody writes code, because it decides who owns product data, who owns prices, and who gets blamed when the two disagree.

Why do the arrows point that way today?

Because three things in e-conomic make the current direction the only sensible one, and each of them changes in Business Central.

Stock quantities can't be written through the API. The inventory block on an e-conomic product exposes available, in stock, ordered by customers and ordered from suppliers, and every one of those is read-only. They're a consequence of documents rather than an input. So a shop that needs to publish stock has never been able to tell e-conomic what it holds, which is exactly why Rackbeat or a warehouse system exists in the stack.

There's one sales price per product, plus currency-specific prices. That's the whole native pricing model in the REST API most connectors use, and the customer record has no price group, no price list and no discount field at all. Special prices and price groups do exist as a Plus feature, and they arrived on the new OpenAPI in August 2024 as part of reaching parity with the old SOAP interface, but a connector reading the old REST API can't see customer pricing.

There are no product variants and no stock locations. Not shorter versions of them, none. There's no variant field anywhere in the product schema and no warehouse resource among the 28.

So B2B pricing in an e-conomic shop is normally computed in the shop, in Shopify B2B catalogues or WooCommerce role pricing, and only the resulting line price lands in the accounts. Variants live in Shopify. Stock lives in Rackbeat. All of that is rational, and none of it survives the move unchanged, because Business Central holds all three natively.

Do product numbers and customer numbers change when I move from e-conomic to Business Central?

Product numbers may have to, because e-conomic allows 25 characters and Business Central's item `No.` is 20. Customer numbers go the easy direction, but they'll be renumbered anyway.

Five characters of overhang doesn't sound like much until you remember that those product numbers are your SKUs, often part of your product URLs, and the key your payment provider reconciliation matches on.

Casing is the quieter one, and for e-conomic it's more likely to bite than for most, because e-conomic imposes no case rules on a product number. Business Central's `Code` data type converts to uppercase and strips leading and trailing spaces, so `abc-1` and `ABC-1 ` collapse into the same item. If your catalogue has mixed-case numbers, check for collisions before anybody loads anything.

Text gets shorter. An e-conomic product name allows 300 characters and a description 500. A Business Central item description is `Text[100]` with a second field of `Text[50]`. That's fine, because your real product copy is in the shop, but any process leaning on the e-conomic name field as a description needs somewhere else to go.

Customer numbers go the easy way, which is worth saying. An e-conomic customer number is an integer between 1 and 999,999,999 and Business Central gives you a 20-character code. The catch is that a Business Central number series will renumber them anyway, and every storefront account key, saved payment token and account-page link built on the old integer stops resolving.

And product groups change shape for the better. An e-conomic product group is a flat number with a name, sales accounts and an inventory-enabled switch, with no parent and child hierarchy. Business Central has item categories with a hierarchy and item attributes with inheritance, which Microsoft's documentation names as search terms for customers in integrated web shops. So this is a design opportunity rather than a loss.

What happens to order history and customer logins?

Customer logins survive untouched, because they were never in e-conomic. Order history depends on your package and on where the shop reads it from.

On Basis there are no orders in e-conomic at all, so the shop's order history was never there. On Plus and above, e-conomic holds order documents in three states, drafts, sent and archived, plus quotes, and invoices as drafts and booked.

But look at how your shop's order number actually reaches the accounts. On an e-conomic invoice the durable place for it is the `references.other` field, 250 characters of free text. That's the join between your web shop and your ledger, and it's worth knowing before anybody designs a reconciliation process in Business Central.

There's one decision to take early, and it has no tooling on either side. If your shop shows customers their order history from its own database, nothing changes. If it reads e-conomic, those reads have to exist against Business Central before cutover. And if Shopify is your storefront, know now that Microsoft states you can't import orders that are archived in Shopify, with the documented workaround being to unarchive them in the Shopify admin first. So decide deliberately whether history stays queryable in e-conomic, arrives as opening balances, or gets rebuilt from the shop.

Is there a migration tool from e-conomic to Business Central?

No, and there can't be one of Microsoft's new generic kind, because e-conomic has no customer-accessible database.

e-conomic isn't on Microsoft's list of supported cloud migration sources, which covers Business Central on-premises, Dynamics NAV, Dynamics GP 2015 and later, Dynamics SL 2015 and later, and any other SQL source using custom migrations. There's no Microsoft e-conomic migration extension, and the contrast sits on the same page, because QuickBooks has one.

The Generic Custom migration type Microsoft added in 2026 release wave 1, GA on 1 April 2026, doesn't reach it either. Microsoft's wording is that custom migrations let you migrate data from any SQL-based source, and the no-code variant even expects a specific company-name table in the source database. e-conomic is cloud SaaS reached only through its APIs, so it's out of scope by construction.

What that means in practice is more encouraging than it sounds. Your data comes out through an API you already know how to call, and it goes in through configuration packages or the Business Central API. Master data, opening balances and setup are ordinary work with a known shape. Nobody's tooling moves your posted history.

Is Business Central compliant with Danish bookkeeping and e-invoicing requirements?

Yes. Business Central's Danish localisation documents the compliance surface explicitly, and Business Central is on Erhvervsstyrelsen's register.

Microsoft lists compliance with the bookkeeping act in Denmark, five-year data retention, mandatory digital vouchers as attachments, SAF-T export, the standard chart of accounts, OIOUBL electronic invoicing including the OIOUBL extension and document creation, and NemHandel including registration in the Nemhandelsregisteret. All of it listed as available now, with carbon footprint information in the OIOUBL format planned for 2026 release wave 1.

One thing belongs in the integration plan rather than the reassurance email. Business Central is retiring Peppol BIS 2.0 and 2.1 in favour of BIS 3.0, marked obsolete pending in version 26.0 with removal in a later release wave, and Microsoft states that all integrations, mappings and customisations must be updated to Peppol BIS 3.0. If you exchange documents through NemHandel or Peppol, that's a version to confirm rather than assume.

When does the Microsoft Shopify Connector fit?

When you sell to consumers, or to business customers whose pricing works at a single quantity tier, through one storefront rather than several marketplaces.

Architecture. The Shopify Connector is built by Microsoft, ships preinstalled with Business Central online, and runs on the job queue. There's no middleware to licence, no server, and nobody in the middle. It isn't available for on-premises deployments.

Data flow. Item sync is bidirectional and covers variants, images, barcodes, vendor item numbers, tags and metafields, and it exports item attributes, extended and marketing texts and translations. Inventory syncs across the locations you select. Customers and companies sync both ways, with mapping on email, phone or registration number.

Orders. Order import covers the Shopify online store, Shopify POS and Shopify B2B, and brings shipping costs, gift cards, tips, refunds, cancellations and payouts from Shopify Payments. Fulfilment tracking goes back to Shopify, and posted sales invoices are exported.

Tax. If you sell into the US, Shopify calculates sales tax at checkout and an engine such as Avalara sits behind Business Central for posting and filing.

Limits. Prices export at quantity one only, so volume breaks don't travel. A Shopify variant matrix combining two or more options can't be created by the connector, because Business Central has no option matrix and the connector uses the variant code as the only option. Archived Shopify orders can't be imported. Extension points are deliberately few, so Microsoft can follow Shopify's release pace without breaking changes. It's one shop per configuration, so other marketplaces need something else. And you have to stay current on Business Central versions.

For a Danish Shopify shop that already publishes variants and prices from Shopify itself, that variant matrix limitation deserves a proper look before anybody commits, because it's the case where the connector's model and your catalogue's model don't line up.

When does Abakion B2B Ecommerce fit?

When your customers have their own prices and they reorder, and you want the shop to ask the ERP rather than compute the answer itself.

Architecture. Abakion B2B Ecommerce installs as an app in Business Central, the site runs on Azure, and the storefront reads live data from Business Central. There's no synchronisation job, no staging database, no integration to own, and nothing to regression test twice a year.

Data flow. Customer-specific catalogues, prices, agreements and currencies come straight from the ERP, and delivery dates come from Business Central's own availability calculation. Order history and reorder work from actual posted documents.

Product content. The accompanying Master Data Information app handles product content and variant matrices, which for an e-conomic company is the first time product content, price and stock have been able to sit in the same system.

Tax. Avalara is supported for US sales tax.

Commercial shape. Fixed price on the initial project, then a subscription tiered by the number of active customers and the number of items in the shop.

The argument that lands hardest for an e-conomic customer. Today your shop computes the customer's price, because e-conomic's customer record has no price group to read. With a storefront reading Business Central directly, the price comes from the ERP, live, and there's nothing to push out to the shop, because there's no out.

In what order should you sequence the two projects?

The accounts first and the shop once, afterwards. And before either, list every subscription in the chain and decide what happens to it.

The most expensive mistake available to you is spending money on the e-conomic integration in the year before you replace e-conomic. Every hour spent extending a connector or adding another app is written off on go-live day, so design any change to the current setup as thin and disposable and let the storefront land once, on the model you intend to keep. Two web projects in two years is the outcome nobody plans for and plenty of companies get.

The e-conomic specific advice is about the stack rather than the shop. Write down every subscription between the shop and the accounts and what it does: stock app, warehouse system, bookkeeping robot, shipping tool, price logic in the shop. Then decide, for each one, whether Business Central replaces it or you keep it. Doing that list after go-live is how companies end up running a stock app alongside Business Central inventory for two years, because nobody wanted to be the person who turned it off.

Nothing is forcing your timing, since both systems are on the register and neither has an end date. Use that, because it's the one advantage in this whole article.

When is neither Shopify nor Abakion B2B Ecommerce enough?

When your shop has to do something both routes deliberately trade away. Neither option fits if you:

• sell configurable products
• run punchout or EDI into your customers' procurement systems
• sell across several marketplaces
• operate a subscription model
• run a design-led consumer brand where the storefront is the marketing
• need volume break pricing published to a Shopify catalogue
• need a Shopify variant matrix with two or more options

Marketplaces are the common one in the Nordics, because selling through your own shop plus a marketplace or two is normal, and one shop per configuration doesn't cover it. If that's you, the honest outcome is that a mid-tier stays and Business Central becomes the financial and stock backbone underneath it, which is a smaller change than the other two routes and a perfectly good place to land.

But plenty of companies assume they're in that group without testing it, keep four subscriptions in sync by hand, and never find out that most of what those subscriptions did was compensate for an accounting package that never claimed to do it.

Where to start

Five questions, and you can answer all of them this week.

1. Which e-conomic package are you on? If it's Basis, you have no orders and no open API access, which tells you where everything actually lives.
2. List every subscription between your shop and your accounts, and what each one does. That list is your project scope.
3. How many product numbers are longer than 20 characters, and do any differ only by case?
4. Where is a B2B customer's price calculated today: in the shop, in an app, or nowhere because you don't have any?
5. Does your shop show customers their order history, and does that come from the shop's own database or from e-conomic?

The answers usually point clearly at Abakion B2B Ecommerce, at Shopify, or at keeping the stack you already have, and knowing which one you're facing is worth more than another year of paying for the same capability twice.

Frequently asked questions

Both apps are on Microsoft Marketplace

• Shopify Connector, published by Microsoft
• Abakion B2B Ecommerce
• Abakion B2B Ecommerce product page

Sources

• Fortegnelse over registrerede bogføringssystemer, Erhvervsstyrelsen
• NemHandel, fælles digital infrastruktur, Erhvervsstyrelsen
• e-conomic priser og pakker, Visma e-conomic
• e-conomic fuld funktionsliste, Visma e-conomic
• Lager af Rackbeat, Visma e-conomic
• e-conomic ERP-sammenligning, Visma e-conomic
• Den nye bogføringslov, Visma e-conomic
• e-conomic REST API documentation
• e-conomic REST API resource index
• e-conomic products resource
• Building a more stable API ecosystem together, e-conomic Tech Talk
• SOAP deprecation and rate limiting, e-conomic Tech Talk
• Products on OpenAPI, e-conomic Tech Talk
• Webhooks API now available in OpenAPI, e-conomic Tech Talk
• e-conomic developer portal, Visma e-conomic
• Rackbeat, Rackbeat
• IEX integration to e-conomic, IEX
• IEX integration to Business Central, IEX
• Storebuddy integrations, Storebuddy
• Migrate on-premises data to Business Central online, Microsoft Learn
• Custom migrations to Business Central online, Microsoft Learn
• Migrate to the cloud from any SQL database, 2026 release wave 1, Microsoft Learn
• Denmark local functionality, Business Central, Microsoft Learn
• Deprecated features in the Business Central application, Microsoft Learn
• Item table reference, Business Central, Microsoft Learn
• Item Variant table reference, Business Central, Microsoft Learn
• Location table reference, Business Central, Microsoft Learn
• Code data type, Business Central, Microsoft Learn
• Record sales price, discount and payment agreements, Microsoft Learn
• Work with item attributes, Microsoft Learn
• Synchronise items with Shopify, Microsoft Learn
• Synchronise orders with Shopify, Microsoft Learn
• Shopify Connector FAQ, Microsoft Learn
• Installing and uninstalling extensions in Business Central, Microsoft Learn