How to integrate with Spiris: ROT, RUT and who holds the connection

A Swedish integration usually starts with a naming problem rather than a technical one, and the useful thing about this one is that the vendor dated it. The change is a changelog entry from 28 May 2025, not a rumour a prospect repeats.

Two things changed in that entry. The company Visma Spcs became Spiris, and in Sweden the product Visma eEkonomi became Bokföring & Fakturering, or Bookkeeping & Invoicing in English. In every other market the product name stayed eAccounting. The vendor closes the entry with the part that matters to an existing build: “Our API continues to support integrations across borders, and these naming updates will not affect your existing setups.”

So a Swedish customer may say Spiris, Bokföring & Fakturering, eEkonomi or Spcs, and all four resolve to the same target system. The developer portal now carries the Spiris name in its own navigation while the interface underneath it does not: the host is still eaccountingapi.vismaonline.com, the paths are still /v2/… and the target system through Maesn is still vismaeaccounting.

Which objects that connection reaches, and which of them sit on request, is listed object by object on the Spiris API page. The market split, the scopes, the token lifetimes, the paging and the rate limits are the same on every brand and are written up once on the Visma eAccounting API page and its guide. Everything below this line is the part that only applies in Sweden.

In Sweden the party that authenticates is frequently not your customer. Small companies work with an accounting office, and the vendor builds that assumption into its own recommendation rather than leaving it to local knowledge.

The reason is the plan. In the vendor’s words, “the accounting office always has Bookkeeping & Invoicing+, whereas the customer can have any of the other variants”, and the recommendation follows from it: to reach all of the endpoints, a user “from the accounting office, who also has access to the end customer’s Bookkeeping & Invoicing, should perform the authentication”.

That has a consequence for your product before it has one for your code. The person who clicks through the consent screen may be a third party who serves dozens of your customers, so whatever your interface says during connect is read by an accountant rather than by the business whose data it is.

And it comes with a trap that produces a connection to the wrong company rather than an error. The office user has to pick the right company in the selector, and the selector can be missing: an office set to a standard company in Spiris has it overridden. The documented remedy is to send prompt=select_account in the authorisation request, which the vendor recommends anyway, because omitting it “may result in automatic or unpredictable logins with an already selected company”.

Through Maesn this is one flow rather than one per system: unified authentication submits the scope set with the credentials, sends these parameters on every authorisation request and returns one account key for the connection, whoever performed it.

The second Swedish surprise is a restriction, and it is the kind that is cheaper to know than to discover. You cannot decide which accounts an invoice posts to from outside the product.

The vendor answers it as a flat no: “all articles have predefined account codings that determine which accounts are used on the invoice. These can only be added or changed directly in Bookkeeping & Invoicing, not via the API.” The coding is a property of the article, reachable as CodingId and listed on /v2/articleaccountcodings.

So the lever you have is article selection. A row references an article, the article carries the coding and the coding decides the accounts. Building a Swedish invoice therefore means mapping your own product catalogue onto articles that already exist in that tenant, rather than sending accounts along with the amounts.

One rule follows from the same page and is easy to trip over on a first write: an invoice needs at least one row carrying an article id to be valid. Rows without one are text rows, flagged by IsTextRow, and an invoice made only of those is not an invoice.

The chart of accounts itself is addressed per fiscal year, on /v2/accounts/{fiscalyearId}, with a separate standard set on /v2/accounts/standardaccounts. Individual tenants rename, add and remove accounts, so it is a per-customer reference rather than a national constant you can hold in code.

Cost centres are the one place where this system is more generous than it first looks. A tenant can run up to three groups of cost centre, and a row carries an id for each of them, so an allocation your product already tracks has somewhere to land without a custom field.

VAT on this system is a reference rather than a number, and the reason is visible in the shape of the object. A VAT code carries a code, a description and a rate, and it also carries the accounts that rate posts to: AccountNumber1, AccountNumber2 and AccountNumber3.

That is why the same percentage is not interchangeable between two Swedish tenants. The rate may match while the accounts behind it differ, so a VAT code is a per-customer reference to read from /v2/vatcodes, or from /v2/vatcodesrates when you want the rates alongside it.

Two customer-level switches change the calculation before any row does. DeliveryBasedVat makes the delivery address the basis for VAT and OSS, which also makes the delivery city, country code and postal code mandatory. ForceBookkeepVat includes VAT for a non-EU customer and cannot be set for a country inside the EU.

And one flag decides whether a Swedish invoice can carry a deduction at all: IsPrivatePerson. The next section is only reachable for those customers.

This is the part of a Swedish build that has no equivalent in the Norwegian or Dutch markets. ROT and RUT are tax reductions a private customer claims on work done at home, ROT for repair and conversion work on a property, RUT for household services, and both are modelled explicitly in the interface.

Modelled in three places, which is the detail worth planning for. The invoice carries the deduction, the row carries the work and the article carries the trade. Miss one level and the other two produce an invoice that looks complete and reduces nothing.

Three of those fields have rules rather than just types. The property name becomes required as soon as a property type is set, the identity number of the buyer is capped at eleven characters, and the reduction is calculated for you unless you send an amount yourself.

The trade list is longer than it sounds and it is not contiguous. There are 26 values, twelve on the ROT side and thirteen on the RUT side plus one for none of them, running up to 29 with gaps at 8, 11, 16 and 17. A loop over a numeric range therefore produces values the interface does not know, and the same list appears on the article as HouseWorkType and on the row as WorkCostType.

Green technology sits next to it as its own small enum on the row, with solar cells, electric energy storage and a vehicle charging point. It shares the property name field with ROT, so setting either makes that field required.

Everything above is the Swedish surface a direct build has to learn. Through Maesn it arrives as one connection on the same interface as every other accounting system you support, and the objects your use case needs are switched on for it.

Customers and suppliers read on this connection today. The rest of the catalogue is 145 combinations available on request, the highest count of any system we connect, so the productive question is a narrow one: which objects does your Swedish use case touch. Name them and they get switched on for your connection.

Freshness runs on a scheduled read, and the paging behind it is handled on our side, so a read returns the complete set rather than the first fifty records. Everything you read arrives in the same common data model as every other connected system, which is what keeps a Swedish customer from becoming a second shape in your product.

What Maesn takes off your side:

• The whole Swedish surface above. The deduction fields on three levels, the trade list with its gaps, the VAT code that resolves to three accounts and the account coding rules are ours to hold. Your product sends one shape.
• The connection, whoever makes it. An accounting office connecting on a client’s behalf is the normal case here, and the flow, the company selection and the token lifecycle run on our side of it.
• Three markets on one build. Spiris, and eAccounting in Norway and the Netherlands, are one target system. A Swedish customer costs no second implementation.
• Paging and reconnects. Collections are paged for you, and a token that dies without warning surfaces as a connection state rather than as a 401 in your logs.

What stays with you:

• The article mapping. Account coding travels with the article, so matching your catalogue to a tenant’s articles is your model rather than ours.
• Which objects to name. Two read today and the rest is on request, so the list your use case needs belongs in the conversation before a customer commitment rather than after.
• Who authenticates. Whether you route an accounting office or the business itself through connect is a product decision, and it decides what your consent step has to say.