--- title: "Nordic accounting: one region, five integration stacks" description: "Nordic accounting looks like one market. Sweden, Norway, Denmark and Finland run separate software, e-invoicing rules and APIs. A country-by-country guide." author: "GJ" published: "2026-10-08" updated: "2026-10-15T12:03:38.914Z" url: "https://www.apideck.com/blog/nordic-accounting-fragmentation" --- # Nordic accounting: one region, five integration stacks Put a Swede, a Dane, a Norwegian and a Finn in a meeting room and they will reach consensus faster than any group on earth. The Swede proposes a fika break before anything controversial is said. The Dane lights a candle. The Norwegian mentions, unprompted, that the oil fund is doing fine. The Finn stays silent for forty minutes and then delivers the only correct answer. Now ask them to agree on Nordic accounting software. The meeting ends early and politely, and each of them goes home to a different system. (The Icelander sent apologies. Something about a volcano.) I say this with love and from a position of weakness. I'm Belgian. We have three official languages and six governments, so I'm in no position to lecture anyone on fragmentation. But I run a company that builds accounting integrations for a living, and the Nordics are one of the clearest cases I know of a region that looks unified from the outside and splits into separate national stacks the moment you try to connect to it. ## The Nordics look like one market and behave like five From a sales deck, the Nordics are attractive: high digital maturity and small businesses that adopted cloud bookkeeping early. Eurostat data cited in our [Europe Accounting Integration Map 2026](https://www.apideck.com/resources/europe-accounting-integration-map-2026) puts ERP adoption among Danish enterprises at 66%. Businesses here already live in software, which is exactly why a vertical SaaS or fintech product wants to plug into their books. The problem is that every Nordic country wrote its own accounting rules and, in most cases, grew its own national software champion. Bookkeeping law and tax administration sit at the national level, and e-invoicing networks were built country by country before Peppol tied some of them together. The software followed the law, so the software is national too. Our integration radar tracks this market by market. Across the four largest Nordic economies it lists 24 local accounting platforms, and not one of them appears in every country list. The only systems that do are global platforms such as Xero and NetSuite. ![Apideck integration radar: local accounting platforms tracked in Sweden, Norway, Denmark and Finland, with connector status](https://images.ctfassets.net/d6o5ai4eeewt/1nQAVT0EoKDLEZ81pGrQCj/b72970497f2858bac9673e06c810e655/figure-1.png) *Source: the Apideck radar's Danish and Finnish accounting pages and their Swedish and Norwegian counterparts. Snapshot: October 2026.* To make the differences concrete, the sections below take one ordinary event, a sale of 1,000 in local currency plus VAT, and look at what it takes to book it in the leading systems of each country. ## Sweden: one dominant platform and a file format from 1992 Sweden has the closest thing the region has to a default. Fortnox reported 612,000 subscription customers at the end of Q1 2025, up 10% year on year, according to its [Q1 2025 interim report](https://storage.mfn.se/9c3b2995-fd4c-49dc-a5cf-848f3f8e8e04/fortnox-q1-2025-eng.pdf). The same report describes the business as operating only in the Swedish market, with no exports. A few months later, a consortium of EQT and First Kraft took it off the stock exchange after [crossing 90.5% ownership](https://news.cision.com/omega-ii-ab/r/omega-ii-ab-becomes-the-owner-of-90-5-per-cent-of-the-shares-in-fortnox-ab--publ--and-intends-to-ini,c4200619) in July 2025. Sweden's biggest accounting platform has no meaningful presence across the border in Oslo or Copenhagen. The second Swedish heavyweight changed its name in 2025. Visma Spcs [now operates as Spiris](https://www.spiris.se/nyhetsrum/visma-spcs-ar-nu-spiris), which matters for anyone maintaining integration docs or partner listings that still reference the old brand. Our radar entry for Spiris notes that one Spiris integration also reaches Norwegian and Dutch customers, which makes it the rare Nordic platform that crosses a border. Underneath both sits SIE, the Swedish standard for exchanging accounting data. A non-profit group of software vendors and accounting associations created it in 1992, and according to the SIE Group's own figures, cited in this [overview of the SIE format](https://invoicedataextraction.com/blog/sweden-sie-format-accounting), it has close to full coverage across Swedish bookkeeping and tax software. Pair it with the BAS chart of accounts and you get a market where accountants expect data to move in a very specific shape. ### Booking the sale in Fortnox Fortnox speaks JSON over `https://api.fortnox.se/3`, with OAuth 2.0 and a Bearer token. Every payload is wrapped in a singular PascalCase key, and accounts are BAS numbers. Our sale of SEK 1,000 plus 25% VAT lands on accounts receivable (1510), domestic sales at 25% VAT (3001) and output VAT (2611): ```http POST https://api.fortnox.se/3/vouchers Authorization: Bearer Content-Type: application/json { "Voucher": { "Description": "Invoice 1042", "TransactionDate": "2026-10-15", "VoucherSeries": "A", "VoucherRows": [ { "Account": 1510, "Debit": 1250, "Credit": 0 }, { "Account": 3001, "Debit": 0, "Credit": 1000 }, { "Account": 2611, "Debit": 0, "Credit": 250 } ] } } ``` That call fails unless the scaffolding around it already exists. Fortnox's own [voucher best-practice guide](https://fortnox.se/developer/guides-and-good-to-know/best-practices/vouchers) tells you to confirm that a financial year covers the date (`GET /3/financialyears/?date=2026-10-15`) and that the voucher series is valid for that year. It also notes that users often forget to open a new financial year in January, so your integration has to handle that case instead of failing silently. > Gotcha: Fortnox allows 25 requests per 5-second window, and list endpoints return summaries only. Our [Fortnox API guide](https://www.apideck.com/blog/how-to-integrate-with-the-fortnox-api) works through a backfill of 2,500 invoices: five paged list calls plus one detail call per invoice comes to 2,505 requests, which is more than eight minutes of wall-clock time at the rate limit. Refresh tokens last 45 days and rotate on every use, so a sync job that fails to persist the new token breaks the connection. Gotcha: Registering as a Fortnox developer requires a Swedish personal or organisation number, per the same guide. Non-Swedish teams often need a local partner just to get test credentials. If you are building for Swedish SMBs, a Fortnox integration is table stakes. It will not help you in a single other Nordic country. ## Denmark: the state decides which software qualifies Denmark went further than any of its neighbours in regulating the software itself. Under the new Bookkeeping Act, Danish companies must keep their books in a digital bookkeeping system that is either registered with the Danish Business Authority (Erhvervsstyrelsen) or meets its requirements. For companies with a calendar financial year, that obligation effectively started on 1 January 2025, according to [Dinero's FAQ on the act](https://dinero.dk/support/faq-den-nye-bogfoeringslov). Sole proprietorships with turnover above DKK 300,000 two years running come into scope during 2026. The act turns accounting software vendors into regulated suppliers. A registered system has to store vouchers automatically and support standardised e-invoicing. VATupdate reports that SAF-T 2.0 generation becomes required for registered systems from [1 January 2027](https://www.vatupdate.com/2026/06/30/bookkeeping-act-phase-in-complete-nemhandel-by-default-from-july-2026/). From 1 March 2027, under [rules the Danish Business Authority published in September 2026](https://erhvervsstyrelsen.dk/vejledning-nye-krav-til-registrerede-bogfoeringssystemer-effektiv-og-sikker-e-fakturering), providers of registered systems must enrol their customers in NemHandel, the national e-invoicing infrastructure, unless the customer opts out. The vendor side in Denmark is concentrated under one roof. Visma bought e-conomic in 2015. A year later it added Dinero, which had more than 110,000 customer companies when the [acquisition was announced](https://www.mynewsdesk.com/visma/pressreleases/visma-acquires-the-accounting-software-dinero-3120871). Each still runs under its own name and its own API. ### Booking the sale in e-conomic e-conomic skips OAuth bearer tokens entirely. Every request carries two custom headers: one that identifies your app and one that identifies the customer's grant. The [REST docs](https://restdocs.e-conomic.com/) let you try read calls with `demo` in both: ```bash curl https://restapi.e-conomic.com/accounts \ -H "X-AppSecretToken: demo" \ -H "X-AgreementGrantToken: demo" \ -H "Content-Type: application/json" ``` Posting is a two-step affair in the newer [Journals API](https://apis.e-conomic.com/journalsapi/redoc.html). You create draft entries in a journal, then book them. A draft entry looks like this (illustrative; the account numbers come from the customer's own chart of accounts): ```http POST https://apis.e-conomic.com/journalsapi/v16.0.1/draft-entries X-AppSecretToken: X-AgreementGrantToken: Idempotency-Key: 6f1c2b7e-1042 { "journalNumber": 1, "entryTypeNumber": 5, "date": "2026-10-15T00:00:00Z", "accountNumber": 5820, "contraAccountNumber": 1010, "amount": 1000, "currency": "DKK", "text": "Invoice 1042" } ``` > Gotcha: `entryTypeNumber` accepts only five numeric values (2, 3, 4, 5 and 10), each mapping to a different entry type, and the demo tokens are read-only. Drafts stay out of the ledger until a separate booking call runs, so a sync that stops after step one leaves the customer's books looking empty. On the radar, e-conomic shares the Danish list with four other local platforms, each with its own interface. ## Norway: SAF-T first, mandatory e-invoicing next Norway made SAF-T Financial mandatory for accounting periods starting on or after 1 January 2020, per [Skatteetaten](https://www.skatteetaten.no/en/business-and-organisation/start-and-run/best-practices-accounting-and-cash-register-systems/saf-t-financial/questions-and-answers---saf-t-financial/). The file is handed over when a tax auditor asks for it, and companies under NOK 5 million in turnover are exempt unless their books are already electronic. In practice, that pushed every serious Norwegian accounting system to produce a clean, standardised export of the general ledger years before most of Europe thought about it. The bigger change is arriving now. On 29 September 2026, Skatteetaten published final amendments to the Bookkeeping Regulations, summarised by [KPMG](https://kpmg.com/us/en/taxnewsflash/news/2026/10/norway-final-digital-reporting-e-invoicing-regulations.html). From 1 January 2027, bookkeeping-obligated businesses must issue e-invoices for domestic B2B sales whenever the buyer can receive them. From 2028, the buyer's organisation number must appear on sales documents. From 1 January 2030, bookkeeping must happen in an electronic accounting system, and the obligation to receive e-invoices starts to phase in. The approved formats are EHF and Peppol BIS Billing 3.0, and PDF invoices are out wherever the buyer can receive a structured one. ### Authenticating with Tripletex Tripletex, where most Norwegian integration roadmaps start, uses neither OAuth nor static API keys. Our [Tripletex API guide](https://www.apideck.com/blog/how-to-integrate-with-the-tripletex-api) walks through its three-token model. Your app holds a consumer token, the customer generates an employee token in the Tripletex UI, and you trade both for a session token: ```bash # 1. Create a session token (expires at midnight CET on the date you pass) curl -X PUT "https://api-test.tripletex.tech/v2/token/session/:create?consumerToken=$CONSUMER&employeeToken=$EMPLOYEE&expirationDate=2026-10-16" # 2. Use it as the Basic auth password; username "0" means the token owner's own company curl -u "0:$SESSION_TOKEN" "https://api-test.tripletex.tech/v2/ledger/voucher?dateFrom=2026-10-01&dateTo=2026-10-31" ``` > Gotcha: Session tokens expire at midnight CET on the date you specify, whenever you created them, and there is no refresh token. A token minted at 23:50 with that day's date is dead ten minutes later. Accounting firms add another layer: they must call `GET /company/>withLoginAccess` and pass the client's company ID as the username instead of `0`. Production access needs an application form, and approval takes two to three weeks. For a SaaS product touching Norwegian invoices, the 2027 deadline is hard. Anything that creates or reads invoices needs to map to the Norwegian standard chart of accounts (NS 4102) and deliver invoices over Peppol in EHF format. Tripletex shares the Norwegian radar with six other local platforms. ## Finland: e-invoicing before it was fashionable Finland got to e-invoicing early. The Act on Electronic Invoicing (241/2019) has applied to central government bodies since April 2019, and from April 2020 it gave contracting entities and businesses with annual turnover above EUR 10,000 the right to demand an e-invoice from their suppliers, as [PwC Finland](https://www.pwc.fi/en/services/tax/tax-news/e-invoicing-scope-extends-to-b2b-transactions-in-finland.html) explains. Finnish businesses grew up on Finvoice and TEAPPS, two formats that came out of the Finnish banking and operator world. The software market follows its own logic. Procountor, part of the Finago group, serves about 100,000 companies in Finland and Sweden plus 1,400 accounting offices. Visma Netvisor is the other large cloud player. Finnish SMBs often get their software through their accounting firm, so the person who decides whether your integration gets switched on is often the bookkeeper. The two Finnish leaders also show how far apart the APIs of neighbouring products can drift. ### Booking the sale in Visma Netvisor Netvisor's API is XML, one voucher per request, posted to resources with a `.nv` suffix. This sales line is adapted from the [accounting.nv reference](https://support.netvisor.fi/en/articles/766888-import-accounting-data-accounting-nv): ```xml net 2026-10-15 Invoice 1042 Sales invoice -1000.00 3000 25.5 ``` Authentication is where Netvisor stands alone. Each request carries eleven `X-Netvisor-*` headers, and one of them is an HMAC-SHA256 signature over the request URI and nine other values, keyed with your partner key and the customer's user key. The [authentication docs](https://support.netvisor.fi/en/support/solutions/articles/77000557880-api-authentication) spell out the order: ```python import hmac, hashlib def netvisor_mac(uri, sender, customer_id, timestamp, language, org_id, transaction_id, timestamp_unix, user_key, partner_key): message = "&".join([uri, sender, customer_id, timestamp, language, org_id, transaction_id, timestamp_unix, user_key, partner_key]) key = f"{user_key}&{partner_key}" # Netvisor expects ISO-8859-15 when values contain special characters return hmac.new(key.encode("iso-8859-15"), message.encode("iso-8859-15"), hashlib.sha256).hexdigest() ``` > Gotcha: Encode the signed string in ISO-8859-15. A customer name with an "ä" or "ö" in a UTF-8 signature produces a MAC mismatch that only shows up for some customers, which is the worst kind of bug to chase. Check your VAT rates too: Finland's standard rate went to 25.5% in September 2024, and the example in Netvisor's own reference page still uses 24. ### Booking the sale in Procountor Procountor is JSON, but its voucher model has its own conventions. A ledger receipt carries signed amounts (debits positive, credits negative) and a numeric `vatStatus` per line, and it is always created in `UNFINISHED` status. These two lines come from Procountor's [cash sales example](https://help.procountor.fi/en/articles/532398-ledger-receipts-import-cash-sales-to-finago-procountor-as-voucher): ```json { "type": "JOURNAL", "status": "UNFINISHED", "receiptDate": "2025-06-30", "vatProcessing": "FINLAND", "transactions": [ { "transactionType": "ENTRY", "account": "1700", "accountingValue": 195.42, "vatPercent": 0.0, "vatType": "SALES", "vatStatus": 12 }, { "transactionType": "ENTRY", "account": "3001", "accountingValue": -121.30, "vatPercent": 25.5, "vatType": "SALES", "vatStatus": 1 } ] } ``` > Gotcha: A Procountor receipt does nothing for the books until you approve it with a second call, `PUT /ledgerreceipts/{receiptId}/approve`. Valid `vatStatus` codes come from `GET /vats/default`, so hardcoding them from one customer's account is a bug waiting for the next customer. ## The same entry in five dialects Put the four countries side by side and the pattern is hard to miss. Here is what our single sale requires per platform: | | Fortnox (SE) | e-conomic (DK) | Tripletex (NO) | Netvisor (FI) | Procountor (FI) | |---|---|---|---|---|---| | Format | JSON, PascalCase wrapper | JSON | JSON | XML | JSON | | Auth | OAuth 2.0 | Two token headers | Consumer, employee and session tokens | HMAC-SHA256 across 11 headers | OAuth 2.0 | | Credential lifetime | 1 h access, 45-day rotating refresh | Grant token per customer agreement | Until midnight CET | Signed per request | OAuth tokens | | Amounts | Separate `Debit` and `Credit` | `amount` plus contra account | Postings on a voucher | Signed `linesum` | Signed `accountingValue` | | Extra step | Financial year and series must exist | Book the drafts | Renew session daily | One voucher per call | Approve the receipt | ![Five vouchers, five dialects: building five Nordic accounting integrations one by one compared with one unified API](https://images.ctfassets.net/d6o5ai4eeewt/r8YhqPjLoF7FhNAqVv26x/c469cbe0d155e0a5fc29b6243cd65964/figure-2.png) The regulatory side compounds it. Each country moves its rules on its own schedule, and several of the dates that matter most fall in the next 15 months. ![Timeline of Nordic bookkeeping and e-invoicing milestones from 2019 to 2030 for Sweden, Norway, Denmark and Finland](https://images.ctfassets.net/d6o5ai4eeewt/3l2blJ2XnIvU4xoEOsrmzg/6e9fce16ef69ce6ee4d2416aaa249107/figure-3.png) ## One owner does not mean one API A reasonable reaction at this point is that Visma owns a large share of the region, so the fragmentation must be smaller than it looks. Visma reported EUR 2.8 billion in revenue for 2025 and 2.4 million customers, according to [Altaroc's summary of its results](https://www.altaroc.pe/en/resources/news/visma-a-realise-2-8-mds-chiffre-daffaires-en-2025). Its model is [federated](https://www.apideck.com/blog/visma-api-portfolio): it acquires local companies and lets them keep their brands and engineering teams. For an integration team, that federated model is the whole story. e-conomic in Denmark and Netvisor in Finland share a parent company and very little else. One uses two static token headers and JSON. The other signs every request with HMAC and speaks XML. Owning the cap table does not merge the codebases, and I don't expect it to anytime soon, because the local rules that justify separate products keep diverging. ## The cost of selling across the region Take a spend management or invoicing product expanding from Sweden into the rest of the Nordics. In my experience, covering the majority of SMBs in each country takes two or three accounting systems per market. Across four countries, that is eight to twelve connectors before you count the mid-market ERPs that larger customers run. Each connector brings its own auth flow, its own rate limits and its own chart of accounts conventions. Each sits under a national rulebook that changed in the last two years or is about to, with Denmark's registered-system regime and Norway's 2027 to 2030 e-invoicing timeline as the two biggest examples. Teams usually estimate the first build well and badly underestimate the work of keeping every connector compliant through the next regulatory cycle. With a unified API, the sale from the start of this post becomes one request shape for every connector, with the target picked by a header: ```http POST https://unify.apideck.com/accounting/journal-entries Authorization: Bearer x-apideck-app-id: x-apideck-consumer-id: x-apideck-service-id: fortnox { "title": "Invoice 1042", "currency": "SEK", "posted_at": "2026-10-15T00:00:00.000Z", "line_items": [ { "type": "debit", "total_amount": 1250, "ledger_account": { "id": "" } }, { "type": "credit", "total_amount": -1000, "ledger_account": { "id": "" } }, { "type": "credit", "total_amount": -250, "ledger_account": { "id": "" } } ] } ``` > From the docs: line items need at least two entries that sum to zero, with debits positive and credits negative, per the [journal entries reference](https://developers.apideck.com/md/apis/accounting/reference/journal-entries/journalEntriesAdd.md). Point the service ID at `procountor-fi` and use the Finnish customer's ledger account IDs, and the request shape stays the same. Token rotation happens behind it. Build the integration that unlocks your home market yourself if it is core to the product. For everything after that, the economics of building and maintaining a dozen national connectors in-house rarely work for a team whose actual product is something else. ## The open-source route, one vendor at a time The other way to avoid writing every connector from scratch is open source, and there is real activity in this corner of the market. I went looking for a fully open-source unified accounting API with Nordic coverage as of October 2026 and didn't find one. What exists is narrower, and still worth knowing. The open-source unified API that came closest to the classic model, Panora, was archived on 26 October 2025 after its open-source product was sunset, according to its [GitHub repository](https://github.com/panoratech/Panora). Its listed topics centred on CRM, and I found no Nordic accounting connectors in it. The real momentum is in MCP servers that let AI agents work directly in one accounting system. A community [Fortnox MCP server](https://github.com/erp-mafia/fortnox-mcp) exposes 51 tools under the MIT licence and handles the single-use refresh tokens and the 25-requests-per-5-seconds limit for you. A [Tripletex MCP server](https://github.com/cwvedvik/tripletex-mcp), also MIT, exposes 56 tools plus 18 accounting workflows such as year-end closing. Danish and Norwegian equivalents exist for [e-conomic](https://github.com/klausagnoletti/e-conomic-mcp-server) and Fiken. In Sweden, [Accounted](https://github.com/erp-mafia/accounted) goes a step further and rebuilds the accounting system itself as AGPL software with SIE import and export, the BAS 2026 chart of accounts and its own MCP interface. | Project | What it is | Licence | Nordic coverage | |---|---|---|---| | Panora | Unified API | AGPL-3.0, archived October 2025 | None found | | fortnox-mcp | MCP server | MIT | Fortnox, 51 tools | | tripletex-mcp | MCP server | MIT | Tripletex, 56 tools and 18 workflows | | e-conomic-mcp-server | MCP server | MIT | e-conomic customers, products and invoices | | Accounted | Open-source accounting system | AGPL-3.0 | Sweden, with SIE and BAS | These projects are good reading. The Fortnox and Tripletex servers encode the same gotchas covered earlier in this post, and their token-handling code is a fast way to learn how a platform behaves in production. Each one is scoped to a single vendor, usually with a single maintainer and no shared data model. A product that needs one Swedish, one Norwegian and one Finnish system ends up stitching together separate projects with separate schemas, and the fragmentation moves from the vendors' APIs into your dependency tree. ## First, look at your own customers Start with the customers you already have. Pull the accounting systems they use, country by country, and rank them by revenue at stake. Then check each one against the regulatory dates above, because a connector that ignores Norway's 2027 e-invoicing rules or Denmark's registered-system requirements will need rework within a year. The Apideck connector list shows which Nordic platforms are live today and which are coming next. If you would rather connect once and cover the Nordic systems your customers run, the [Apideck Accounting API](https://www.apideck.com/accounting-api/connectors) connects to Nordic platforms in all four countries, plus the major ERPs, through a single integration, with Tripletex coming next. The Swede will approve of the efficiency. The Finn will not say anything, which is the highest compliment available.