The Nordic Integration Stack: Connecting Fortnox, Visma, BankID, and Peppol

If you’re building or maintaining integrations for a Nordic company, you already know: the ecosystem is unlike anything in the US market. Instead of Salesforce-plus-NetSuite-plus-Stripe, you’re dealing with Visma’s fragmented product family, Fortnox’s Swedish-market dominance, BankID for identity, Peppol for e-invoicing, and a half-dozen country-specific standards that don’t exist anywhere else.

This post maps the Nordic integration landscape — what connects to what, where the pain points are, and why generic US-built integration platforms struggle here.

The Core Stack

A typical Nordic mid-market company (100-500 employees) runs some variation of this:

Layer	Sweden	Norway	Denmark	Finland
ERP/Accounting	Fortnox, Visma eAccounting	Tripletex, Visma.net	e-conomic	Procountor, Visma Netvisor
Payroll	Hogia Lon, Visma Lon	Visma.net HRM	e-conomic Payroll	Procountor
E-invoicing	Peppol (voluntary)	Peppol/EHF (mandated 2028)	Peppol/NemHandel	Peppol (Maventa)
Digital ID	BankID (SE)	BankID (NO)	MitID	Suomi.fi
Payments	Swish, Klarna	Vipps, Klarna	MobilePay, Klarna	MobilePay
Tax format	SIE	SAF-T	SAF-T (coming)	—
E-commerce	Shopify, WooCommerce	Shopify, WooCommerce	Shopify	Shopify, WooCommerce

This looks manageable per country. The complexity emerges when you operate across borders — which most Nordic companies do. A Swedish company with Norwegian operations runs Fortnox (SE) + Tripletex (NO), pays via Swish (SE) + Vipps (NO), invoices via Peppol with different country profiles, and reports taxes in SIE (SE) + SAF-T (NO).

The Visma Fragmentation Problem

Visma is the largest software company in the Nordics — 17,500 employees, 2.2 million customers, operating across 33 countries. They’re also the most fragmented.

Visma operates as a federation of semi-autonomous companies. Each acquired product maintains its own:

API paradigm. Visma.net uses REST with Swagger docs. Business NXT uses GraphQL. eAccounting uses REST with OAuth 2.0. Tripletex uses REST with a two-token auth system. Netvisor uses a custom RESTful web service interface.
Rate limits. eAccounting allows 600 requests/minute. Tripletex allows 100 requests per 5 seconds. Business NXT has per-query complexity limits. Netvisor has undocumented limits.
Data models. An “invoice” in e-conomic, Tripletex, and eAccounting has different field names, different required fields, and different status enumerations.
Authentication. All use OAuth 2.0 via Visma Connect — but the scopes, token lifetimes, and refresh flows differ per product.

What this means in practice: a company using three Visma products needs three different integration implementations, three different auth flows, and three different data transformation layers. Being “all Visma” doesn’t simplify integration — it triples it.

# The same "create invoice" operation across Visma products

# Visma.net (REST)
POST /api/v1/invoice
{
  "customerNumber": "C-1001",
  "invoiceLines": [
    {"itemNumber": "SKU-100", "quantity": 2, "unitPrice": 299.00}
  ]
}

# Tripletex (REST, different auth)
POST /v2/invoice
{
  "customer": {"id": 45012},
  "orders": [
    {"product": {"id": 801}, "count": 2, "unitPriceExcludingVatCurrency": 299.00}
  ]
}

# e-conomic (REST, different structure)
POST /invoices/drafts
{
  "customer": {"customerNumber": 1001},
  "lines": [
    {"product": {"productNumber": "SKU-100"}, "quantity": 2, "unitNetPrice": 299.00}
  ]
}

Three different field names for quantity (quantity, count, quantity). Three different price fields (unitPrice, unitPriceExcludingVatCurrency, unitNetPrice). Three different customer references (string, integer ID, integer number). Same company, same vendor family.

Fortnox: The Swedish Standard

Fortnox dominates Swedish SMB/mid-market accounting. Their API (v3, REST, modified OAuth2) is reasonably well-documented but has some notable quirks:

Undocumented endpoints. Some UI features rely on internal API endpoints that aren’t in the public documentation. Developers discover them through browser dev tools and build against them. Fortnox can change these without notice — a recipe for breaking integrations.

Rate limiting. Documented but aggressive for high-volume use cases. Bulk operations require careful batching.

Marketplace lock-in. Fortnox takes a 75% revenue share from marketplace integrations. This shapes the ecosystem — third-party integration vendors must price their Fortnox connectors accordingly.

The most common Fortnox integration scenarios:

Shopify/WooCommerce → Fortnox — Order sync, inventory updates, invoice generation
Fortnox → Bank (SEB, Nordea, Handelsbanken) — Payment matching, bank feed reconciliation
Fortnox → Hogia Lon — Employee data sync for payroll processing
Fortnox → SIE export — Tax reporting and audit trail

BankID: Identity Across Borders

BankID is used by over 8 million people in Sweden alone. Norway has its own BankID implementation. Denmark uses MitID (replaced NemID in 2022). Finland uses Suomi.fi.

Key integration challenge: these are four completely different identity systems with different APIs, different integration patterns, and different security requirements. A SaaS application serving all Nordic markets needs to integrate with all four.

System	Technology	Integration
BankID (SE)	PKCS#11, REST	Intermediaries (Curity, IN Groupe)
BankID (NO)	OIDC-based	Direct API or intermediaries
MitID (DK)	OIDC/OAuth 2.0	Via NemLog-in broker
Suomi.fi (FI)	SAML 2.0	Via DVV broker

Most companies use an intermediary like Scrive eID Hub or Curity that provides a unified interface. But the underlying complexity leaks through — different user flows, different certificate requirements, different regulatory obligations per country.

Peppol and E-Invoicing: The Compliance Layer

Peppol (Pan-European Public Procurement Online) is the standard for electronic invoicing in the Nordics. The format is UBL (Universal Business Language) XML, transmitted via access points.

Norway is furthest ahead. EHF (Elektronisk Handelsformat) 3.0, aligned with Peppol BIS 3.0, is widely adopted. From January 2028, all affected businesses must send structured e-invoices via Peppol.

Denmark has mandated e-invoicing compliance by January 2026 for companies using external accounting systems.

Sweden uses Peppol voluntarily today but is investigating legislative mandates following EU directives.

Finland has strong Peppol adoption through Maventa (Visma-owned), which acts as a major Nordic access point.

The integration challenge: your ERP needs to generate UBL-formatted XML, transmit it through a Peppol access point (Qvalia, InExchange, Pagero, Maventa), and handle acknowledgments and error responses. Most ERPs don’t do this natively — you need middleware.

<!-- Simplified Peppol BIS Billing 3.0 invoice -->
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <ID>INV-2026-001</ID>
  <IssueDate>2026-01-28</IssueDate>
  <InvoiceTypeCode>380</InvoiceTypeCode>
  <DocumentCurrencyCode>NOK</DocumentCurrencyCode>
  <AccountingSupplierParty>
    <Party>
      <EndpointID schemeID="0192">987654325</EndpointID>
    </Party>
  </AccountingSupplierParty>
  <LegalMonetaryTotal>
    <PayableAmount currencyID="NOK">2990.00</PayableAmount>
  </LegalMonetaryTotal>
</Invoice>

Where Generic iPaaS Platforms Fall Short

US-built integration platforms (MuleSoft, Boomi, Workato) struggle in the Nordics for specific reasons:

No native connectors for Nordic systems. These platforms have connectors for Salesforce, HubSpot, NetSuite — not for Fortnox, Tripletex, or e-conomic. You’re building custom connectors on top of an enterprise platform, paying enterprise prices for what amounts to an HTTP client with a GUI.

No understanding of Nordic standards. SIE, SAF-T, EHF/Peppol, BankID — none of these exist in the US market. The platforms don’t have templates, validators, or guides for these standards. You’re on your own.

EU data residency gaps. MuleSoft’s primary infrastructure runs on AWS US regions. EU hosting is available but often as an add-on with limitations. For companies handling Norwegian or Swedish personal data, this matters.

Pricing mismatch. A MuleSoft Enterprise license costs $150K+/year. For a 200-person Norwegian company running 20 integrations, this is economically irrational — especially when 80% of the platform’s value (the connector catalog) doesn’t cover the systems you actually use.

The Nordic-Specific Integration Vendors

A few platforms have emerged to fill the gap:

Zwapgrid (Swedish) — A unified API that normalizes data from Fortnox, Visma eAccounting, e-conomic, Tripletex, Bjorn Lunden, Procountor, Netvisor, and Dinero into one schema. Excellent for read/write accounting data across Nordic systems. Limited to accounting — doesn’t cover CRM, e-commerce, or custom APIs.

Frends (Finnish) — Enterprise iPaaS with European DNA. GDPR-compliant, hybrid deployment, BPMN 2.0 low-code. One of only two European vendors in Gartner’s iPaaS Magic Quadrant. Strong but enterprise-priced and traditional (visual builder model).

LogCore (Swedish) — Low-code iPaaS with deep Swedish market connectors (Visma, Fortnox, Specter). Focused on the Swedish market specifically.

What’s Needed

The Nordic market needs an integration platform that:

Understands Nordic APIs natively — not generic HTTP connectors, but first-class support for the Visma product family, Fortnox, Tripletex, e-conomic, and Procountor with their specific auth flows, rate limits, and data models.
Handles cross-country complexity — a company operating in all four Nordic countries shouldn’t need four separate integration implementations for what is conceptually the same workflow (order → invoice → payment → accounting).
Supports Nordic compliance standards — SIE generation, SAF-T export, Peppol/EHF formatting, BankID verification. These aren’t edge cases — they’re table stakes.
Prices for mid-market Nordic companies — not for Fortune 500 enterprises with $200K integration budgets.
Keeps data in the EU — not as an afterthought add-on, but as the default.

The Nordic tech ecosystem is world-class at building software. The integration layer connecting it all has been underserved for too long.