Sana Commerce vs dvcommerce on Business Central

If your company uses Microsoft Dynamics 365 Business Central and you are evaluating an integrated e-commerce platform, Sana Commerce has very likely appeared on your screen. It is the most visible international player for ERP↔online store integrations. But it isn’t the only option — and, depending on your profile, it may not be the best for your case.

This article compares, without empty promises, Sana Commerce against dvcommerce: two products certified on Microsoft AppSource that integrate B2B and B2C stores with Business Central. The comparison covers technical integration, B2B functionality, localisation for Spain, total cost, support and typical use cases.

Context disclosure: dvcommerce is a Davisa Informática product. We’ve tried to keep the comparison as objective as possible — we cite what Sana Commerce does well and what dvcommerce does better, without caricaturing the competitor. If your case fits Sana, we say so too.

Summary table — what to consider before choosing

Dimension	Sana Commerce	dvcommerce
Supported ERPs	Business Central, NAV, SAP, AX	Only Business Central and NAV
Origin / headquarters	Netherlands (global)	Spain — Davisa Informática
Technical architecture	Separate frontend + sync service with BC	Native AL extension inside BC + connected frontend
B2B (per-customer pricing)	Yes	Yes — reads the BC Price List table directly
ES localisation (VAT, Verifactu)	Via local partner or adjustment	Native — Davisa has 23 years in BC Spain
Spanish payment gateways (Redsys)	Supported via connector	Integrated out of the box (Redsys, PayPal, transfer, invoice)
Multi-language frontend	Yes (several languages)	Yes (ES, EN, FR, DE, CA, EU)
Pricing	Public monthly licence, tiered by channel/users	Annual licence + implementation quote, adjusted to scope
3-year TCO (mid-sized Spain project)	High market reference	~30-50% lower on comparable projects
Support	International, multiple time zones, English primary	Spain, same time zone, Spanish, same team implementing BC
AppSource	Yes	Yes

Integration with Business Central — the detail that decides

The two platforms sell themselves as “integrated with BC”, but the architecture is not the same. And that has very concrete consequences in day-to-day use.

How Sana Commerce does it

Sana runs its frontend on its own stack (ASP.NET on Sana or customer servers). The integration layer with BC is done through a Sana extension + a sync service: BC publishes data (catalogue, stock, prices) that Sana caches/normalises on its side. When a customer buys, the order is returned to BC via API.

Advantages:

• Frontend very decoupled — can scale independently from the ERP.
• The same Sana works with SAP, AX, NAV. Useful if you have several ERPs.

Drawbacks our customers see (those who migrate to dvcommerce):

• Double data layer: catalogue in BC + catalogue in Sana, synced. When something doesn’t match, you have to check both sides.
• Scheduled syncs: prices and stock aren’t always real time. There are customers with jobs every 5 min, every 30 min, every hour. When a job fails, the store shows old prices.
• B2B customisations tied to Sana, not BC: if your discount logic lives in BC, you “duplicate” it in Sana — or you request adjustments from the Sana partner.

How dvcommerce does it

dvcommerce is an AL extension inside Business Central. The catalogue the store sees is the Item table of BC. The price applied to the B2B customer is BC’s Price List. The order coming in from the web is a BC Sales Header from the first moment — it isn’t synced, it is created there.

This means:

• One single truth: there is no parallel catalogue. What you see in BC is what the store sees. You change a price in BC, it is in the store instantly.
• B2B rules without duplication: if in BC you have a 12% discount for customer CL00042 on product family PROD-METAL, that discount applies on the web automatically. It doesn’t need to be recreated.
• Real-time stock: the store queries Item.Inventory at the moment. If stock breaks, it breaks in the store in the same second.

The trade-off is honest: native AL integration ties dvcommerce to Business Central / NAV. If at some point the company migrates to SAP, it doesn’t come along. Sana does. That is why, if your company has several ERPs or a clear plan to migrate away from BC, Sana is the coherent option. If Business Central is going to be your ERP for the next 5-10 years, dvcommerce is the efficient option.

B2B — where the ROI is decided

70% of the online sales integrated with BC are B2B: order portals for distributors, stores for licensed professionals, self-service for account customers. Here both products compete closely, with nuances.

What both do well

• Per-account login — every B2B customer sees their catalogue and their pricing.
• Per-customer / per-segment pricing and discounts.
• Repeat orders (“repeat last month’s order”).
• Online quotes (customer requests a quote, it becomes an order).
• Order history and invoice download.

Where dvcommerce gains ground

• Payment terms inherited from the BC card: the B2B customer with “30 days invoice date” sees that payment method automatically. Without recreating it.
• Real-time available credit: if the customer has assigned risk in BC, dvcommerce shows the remaining credit and can block orders if exceeded (direct query to the Customer.Credit Limit table).
• Associated documents: the BC customer card already has contracts, seasonal discounts, technical datasheets in PDF. Everything is published in their portal without re-uploading.
• BC multi-company: if you have several companies in the same tenant (typical in groups), a single dvcommerce serves both without parallel environments.

Where Sana Commerce gains ground

• More mature visual frontend editor: Sana’s design tool has been around longer. If the priority is for the marketing team to be able to edit homepage blocks without coding, Sana makes it somewhat easier out of the box.
• Pre-configured international templates: if you sell in 6 countries and need templates with per-country flows ready to go, Sana has a catalogue. dvcommerce builds them to order.

Localisation for Spain — where Sana leaks

A Spanish company selling in Spain has specific legal requirements that, in many international products, require local adjustment:

• Verifactu (AEAT verifiable invoicing system, mandatory in 2026).
• Anti-Fraud Law (invoice sealing, record chaining).
• Crea y Crece (mandatory B2B e-invoicing with a gradual roll-out).
• FacturaE / FACe B2G (electronic invoicing for Public Administrations).
• Multi-rate VAT (general, reduced, super-reduced) + IGIC Canary Islands + IPSI Ceuta/Melilla.
• Equivalence surcharge (self-employed retailers).

Sana Commerce does not implement these requirements out of the box — it covers standard European invoicing and leaves the responsibility to extend up to the local partner. This adds project hours and, above all, regulatory risk (the AEAT changes the rules frequently and you have to stay on top of it).

dvcommerce works side by side with dvfactura-e (Davisa’s e-invoicing extension on AppSource) and dvimpuestos (tax compliance): the same company that maintains the web maintains the legal module. When the tax authority publishes a change, it reaches your installation because Davisa prepares it for all BC Spain customers.

Pricing — the calculation that matters, not the one on the homepage

Sana Commerce publishes pricing on its website — a reference that runs around EUR 2,500-7,000/month in licence depending on channel and users, not counting implementation. It is pricing designed for a large international company.

dvcommerce does not publish pricing on the homepage for a simple reason: the scope varies a lot from one project to another. What we can say:

• Annual licence: per tenant, adjusted to the mid-sized Spanish company bracket.
• Implementation: by quote, depending on scope (a typical B2B channel runs 3 to 7 weeks).
• Support: included in the first year, then a maintenance contract.

On comparable projects (1 BC tenant + B2B store + integration with per-customer pricing + 2 languages), customers who have compared the two products report a 3-year TCO between 30% and 50% lower with dvcommerce. The main delta: the consultancy team is in Spain, without international overhead, and there are no royalties per number of products or orders.

If you want a concrete estimate for your case, contact a Davisa adviser — in less than a week you receive a scope and firm price.

Support — the day after go-live

When a B2B order doesn’t enter BC because the pricing changed at midnight, the next day what matters is who picks up the phone and at what time.

• Sana Commerce: international support, several time zones, communication usually in English. For critical issues, escalation to the Netherlands team. For Spanish companies, the first line is usually a local partner with tickets escalating to Sana central.
• dvcommerce: direct support from Davisa, in Spanish, same time zone, same team that implements the customer’s BC. Critical tickets are handled in less than 1 business hour; normal tickets in 4 hours.

This difference, which on an RFP looks minor, is the one that decides operations calm 6 months after go-live.

When to choose Sana and when dvcommerce?

A summary without sugar-coating, in case you have the decision this week:

Choose Sana Commerce if:

• Your company has several ERPs (BC in one subsidiary, SAP in another) and you want to unify the e-commerce layer.
• You operate in many countries outside the EU and need a partner with global coverage.
• You are going to replace BC with SAP in 2-3 years — you don’t want to tie yourself to a BC-native product.
• Your marketing team needs a very mature visual frontend editor.

Choose dvcommerce if:

• Business Central is your ERP and is going to be for years to come.
• Your operation is mainly in Spain (or Spain + EU) with local legal requirements.
• You want B2B order taking with pricing, conditions and credit read directly from BC, without scheduled syncs.
• You value local support, same time zone, same team as the BC partner.
• You want a lower TCO and a 4-8 week implementation, not 4-6 months.

Case study: when migration makes sense

We’ve migrated customers who started with Sana and, after 2-3 years, discovered that the overlap (Sana frontend + syncs to BC + duplicated B2B customisations) cost them more in maintenance than a switch to dvcommerce.

A recent case: industrial distributor, 1 BC Spain, 800 B2B customers, 4,500 SKUs, tiered pricing by family and by customer. They had Sana Commerce with sync every 30 min. We migrated to dvcommerce in 5 weeks with URLs preserved and a final 1-week sprint in parallel (orders entering both systems at the same time to detect differences). Results after 6 months:

• Web response time -42% (no intermediate cache layer).
• B2B orders/day +18% (prices and stock always current, fewer drop-offs from false “zero stock”).
• Operations tickets for “incorrect pricing applied” practically zero (no duplicated pricing to maintain).
• Annual TCO -38%.

Closing — decide on your company’s case, not on the brand

Sana Commerce is a solid product. If your company fits the scenarios where it adds value — multi-ERP, pure multinational, international brand priority — the choice is reasonable.

For all the companies that come with a typical Spanish case — Business Central, B2B with pricing, mandatory e-invoicing, reasonable budget, an appetite to speak Spanish with whoever maintains the ERP — dvcommerce is designed exactly for that case, with no compromises.

Want a firm comparison against your scope? Tell us your case and in less than a week you have a concrete proposal, with numbers, to compare against.