Build ecommerce that fits around Spiris

Why Spiris companies need a clear ecommerce strategy

Spiris (previously Visma eEkonomi and Visma Spcs) is one of Sweden's most widely used finance platforms among small businesses. It handles bookkeeping, invoicing, payroll, and VAT reporting for sole traders, smaller limited companies, and service businesses. When a Spiris company starts selling online, the question is not whether to keep Spiris — it's how ecommerce is built around it without creating parallel systems and duplicate administration.

The rebrand from Visma eEkonomi to Spiris during 2025 is a repackaging of the same product family. The platform is the same but has been developed with more services. For the ecommerce perspective nothing changes technically — but it means many companies still search for and refer to "Visma eEkonomi" or "Visma Spcs" when talking about the same system.

The important thing is what Spiris is actually built for. It's a finance platform, not a commerce ERP. Advanced inventory handling, complex pricing, or large multi-channel flows sit outside the system's core. That makes Spiris perfect for some ecommerce scenarios and a poor match for others. Being honest about that at the start of the project saves a lot of work later.

When Spiris works as an ecommerce foundation

Spiris fits well when ecommerce is an SMB or D2C store with a manageable catalogue and Swedish customers as the primary market. Service businesses starting to sell digital products, subscriptions, or physical products in smaller volumes can often start with Spiris as the finance backbone and Shopify or a similar platform as the storefront.

Spiris quickly becomes a constraint, however, in advanced B2B with customer-specific price lists, with large product catalogues with variants and attributes, with multi-warehouse handling, or with sales across multiple countries with different VAT and currency rules. For those scenarios Visma Business NXT or Visma.net are more likely the right choice.

Swedish market requirements: Swish, BankID and VAT codes

Ecommerce in Sweden has specific requirements at the intersection of storefront and finance system. Swish is used by the majority of Swedish B2C consumers and must route payments correctly back to Spiris reconciliation. BankID is used for login on stores with account-based pricing. On the finance side, Spiris handles Swedish VAT codes 25%, 12% and 6%, and the integration must ensure correct codes flow from the ecommerce platform to Spiris per order line. Errors here show up at VAT filing and become difficult to correct retroactively.

Platform choice for Spiris environments

We work with Norce, Shopware, Shopify, and Magento with Hyvä. For the Spiris segment, Shopify is often the first choice — fast time-to-market, low operational complexity, and a broad app market that suits SMB and D2C merchants.

Shopware can be the right choice when you want more control over content and campaigns, or plan to grow into a larger B2C or mixed B2B/B2C operation. Norce and Magento are typically over-dimensioned for the Spiris segment — if the requirements call for Norce or Magento level, it's also likely time to evaluate whether the ERP should be Spiris or something larger.

Spiris integration via Junipeer

Junipeer provides a live Spiris connector that syncs article data, stock levels, customer records, and orders between Spiris and the ecommerce platform. The connection is bidirectional: order data and customer information are pushed to Spiris, while product and stock data are pulled to the web. The Spiris connector ties into 26 other systems in Junipeer's ecosystem, making it straightforward to grow the stack step by step without replacing the integration.

All four platforms we work with — Shopify, Shopware, Norce, and Magento — are connected to Spiris through Junipeer. That means the platform choice can be made on business model grounds, not on which Spiris connector happens to exist.

What moves between the systems

The integration covers typically four data domains: article and price data from Spiris to the web, stock levels (if they exist in Spiris or in a separate WMS), orders from the web to Spiris with correct VAT codes and account mapping, and customer and invoice data. Subscriptions and recurring billing require several of these flows to be handled every billing cycle — the design is decided during the architecture phase.

We assess existing product data in Spiris before the integration is built. Finance data and product data ready for the web are two different things. Descriptions, images, categories, and variants often need to be worked through before ecommerce is ready.

When a system change should be considered

For some Spiris companies planning significant ecommerce development, it's more reasonable to consider a system change alongside the ecommerce project than to build workarounds around Spiris's limitations. The most common triggers are customer-specific B2B pricing, multiple warehouses, multiple companies or markets, and order volumes that require real-time sync rather than batch. If any of this is within a 12-month horizon, it's reasonable for the ecommerce project to also evaluate whether Business NXT, Visma.net, or Fortnox better matches the way forward. It's always better to know before the build than after.

What a Spiris ecommerce project typically includes

A Spiris project starts with an honest assessment of whether Spiris remains the right ERP for the ecommerce ambition. If the answer is yes, we move on to platform choice and integration design. Discovery and architecture typically takes 2–3 weeks, the build and integration 6–12 weeks depending on platform choice and whether subscriptions are included, QA runs in parallel and intensifies in the final weeks, and launch is phased.

The result is an ecommerce setup that fits the size of the business, with Spiris as the finance backbone and without hidden constraints that surface six months in.