This guide covers how to connect Visma.net (Visma.net ERP) to Junipeer and the configuration details specific to Visma.net as an ERP system.
Overview
Visma.net is a cloud-based ERP system widely used in the Nordic region, particularly in Norway and Sweden. It offers strong multi-company and multi-currency support, which makes it popular with brands that operate across multiple markets.
In a Junipeer integration, Visma.net is typically the destination system — orders from the e-commerce platform are synced to Visma.net as invoices, and payment reconciliation data flows into Visma.net to mark invoices as paid.
Connecting Visma.net to Junipeer
Visma.net uses OAuth-based authentication through Visma's identity provider.
Authorization
During the Get Started onboarding wizard (Step 2 — Connect Systems), select Visma.net as your ERP
You will be redirected to Visma's login page to authorize Junipeer's access
Log in with an account that has sufficient permissions (administrator-level access is recommended for initial setup)
Grant the requested permissions
You will be redirected back to Junipeer with the connection established
If the authorization fails, verify that your Visma.net account has the required modules enabled and that the user has administrator permissions.
Required modules
Ensure the following Visma.net modules are active for your company:
Financial — for invoicing and payment handling
Customers — for customer record management
Inventory (if syncing stock levels)
Typical flows
For a Visma.net integration, the most common flows are:
Orders: e-commerce platform → Visma.net (synced as customer invoices)
Customers: e-commerce platform → Visma.net or Visma.net → e-commerce platform
Products/Articles: direction depends on your setup
Stock/Inventory: Visma.net → e-commerce platform
Payouts: payment provider → Visma.net (reconciliation)
Visma.net-specific considerations
Customer classes and VAT handling
Unlike some other ERP systems where OSS VAT mapping is done through explicit per-country sales account assignments, Visma.net uses customer classes and tax zones to control how VAT is calculated and reported. This is an important distinction.
For EU One Stop Shop (OSS) reporting, you typically:
Create customer classes in Visma.net for different VAT scenarios (domestic, EU B2C, EU B2B reverse charge, non-EU)
Assign tax zones and tax categories that correspond to the correct VAT rates
Map these in Junipeer so that orders are assigned to the correct customer class based on the buyer's country and business status
The mapping involves connecting country codes (e.g., FR for France) to the appropriate taxZoneId and taxCategory in Visma.net. This is configured in Junipeer's settings. If you are selling cross-border to EU consumers, this mapping is essential for correct VAT reporting.
Webhook signals
Visma.net supports webhook-like "signal" triggers for certain actions (for example, sending shipment data to a logistics provider like nShift). These signals can be unreliable — they may fail silently without raising an error visible to the user.
Junipeer adds its own webhook listeners as an extra check layer. However, if you notice that actions triggered by Visma.net signals (such as "Send to nShift") are not executing consistently, consider supplementing with a scheduled sync as a fallback. You can run both webhooks and schedules simultaneously for critical flows — the schedule acts as a safety net.
Payout fee write-offs
When processing payouts from payment providers, Visma.net requires a write-off reason code to record the PSP transaction fees. Configure the FeeWriteOffReasonCode in your integration settings. The reason code must match a valid entry in your Visma.net chart of accounts.
See the Payout Reconciliation guide for the full payout flow and fee handling details.
Customer number series
Visma.net uses automatic number series for customer records. When Junipeer creates new customers during order sync, they are assigned numbers from the active customer number series. If the number series runs out or overlaps with manually created customers, sync errors will occur.
Ensure your Visma.net customer number series has sufficient capacity and does not overlap with any manually managed ranges.
Multi-company support
Visma.net's multi-company structure means you may need separate Junipeer integrations for each Visma.net company, even if they share the same e-commerce platform. Each company is treated as a distinct ERP destination.
How Visma.net constructs SKUs for Centra
When syncing products from Visma.net to Centra, Junipeer builds the SKU using a combination of fields from the Visma article record. The default pattern is:
SKU = ProductNrField + Variant + Size
This matches exactly how Centra expects to identify products. The fields used are:
ProductNrField — the product/article number from Visma.net
Variant — mapped from a configured Visma.net field (e.g.
Information5)Size — mapped from a configured Visma.net field (e.g.
Information4)
Important: This SKU construction logic is defined in your integration settings. If you change how the SKU is built (e.g. swap which Visma field maps to Variant or Size), the majority of existing products in Centra will stop matching — causing stock sync failures across the board. Only change this setting if you are prepared to re-import all products in Centra.
If you have products in Centra that were imported via a different method and do not match the current SKU format, those products need to be corrected in Centra rather than changing the integration logic. Contact support@junipeer.io if you need help diagnosing SKU mismatch issues.
Differences from Fortnox
If you are familiar with Junipeer's Fortnox integration, here are the key differences when using Visma.net:
OSS VAT handling: Fortnox uses explicit per-country sales account mapping; Visma.net uses customer classes and tax zones. The bookkeeping result is equivalent, but the configuration approach is different.
Authentication: Fortnox uses API keys; Visma.net uses OAuth. Token refresh is handled automatically by Junipeer.
Fee write-offs: Both systems support fee write-offs, but Visma.net requires an explicit write-off reason code.
Webhook reliability: Fortnox webhooks are generally reliable; Visma.net signals may need a scheduled fallback.
For troubleshooting common errors, see the Error Codes reference or your connector pair's troubleshooting section.