---
title: "Changes to consumer invoicing activation in Norway"
canonical: https://documentation.maventa.com/b2cno-activation-changes/
---

This page is for partners and vendors with Norwegian senders using consumer invoicing (B2CNO) through Maventa.

It describes how consumer invoicing is activated and how eFaktura invoices are sent, and what changes in the activation API responses. This covers eFaktura to netbank and Vipps together with the fallback routes email and print, until now called the main vendor agreement. AvtaleGiro (direct debit), its activation and its mandate handling are not affected.

## The changes take effect 15.11.2026

The short version: activating a sender in Maventa does not take over or replace their existing eFaktura setup, and Visma Sign is not needed for eFaktura. From 15.11.2026 the activation API responses change to match. Your invoice payloads do not change, and senders that are already active need no action.

## How consumer invoicing works

### eFaktura invoices are sent under Maventa's agreement with MPS

Maventa submits eFaktura invoices to MPS (Mastercard Payment Services) under a single Maventa agreement. Each sender's own organisation number travels with every invoice as the legal organisation number, so invoices are attributed to the correct sender. Sending under the service provider's own agreement with MPS is the direction MPS recommends for handling issuer accounts.

Consumers see no difference. The invoice content, the sender name shown in the netbank, and the payment details are the ones the sender sends.

Senders that are already active keep sending without interruption, and there is nothing for you or them to do.

### No takeover, and no Visma Sign for eFaktura

Activating a sender in Maventa does not touch their registration with another service provider. Nothing is transferred and nothing is terminated. A sender can be active with Maventa and with their previous provider at the same time, and MPS does not block this.

Because there is no takeover, there is nothing to authorise, so no signature is required from anyone, regardless of whether the sender is already registered elsewhere. Visma Sign is still used for AvtaleGiro, where it serves a different purpose, described in [What this means for AvtaleGiro](#what-this-means-for-avtalegiro).

Moving a sender from another provider to Maventa needs no coordination:

- No cutover date to agree with the sender or their previous provider.
- No signatory to track down, and no waiting for a signature before a sender can go live.
- Senders can be activated in Maventa while their existing setup keeps running, and moved over at their own pace.
- You can test real sending through Maventa before the sender commits to switching.
- Senders may close their old agreement whenever it suits them. It is not a prerequisite for activating with Maventa, and leaving it open does not cause duplicate invoices. Invoices reach the consumer through whichever provider the sender submits them to.

A sender running two providers in parallel should take care not to submit the same invoice through both.

### There is no separate agreement

Consumer invoicing is not a separate agreement for the sender to accept. When the sender accepted the Maventa or Visma Terms of Service, they authorised Visma to issue and authenticate invoices on their behalf, including towards their banks and their consumer customers.

The main vendor agreement document is replaced by [activation instructions](https://documentation.maventa.com/assets/pages/01-integration-guide/01-invoice-sending/02-consumer-invoicing-no/consumer-invoicing-no-activation-instructions.pdf), which explain the service to the sender's own staff. The same instructions are shown in the Maventa UI when activating, so you can also share them with senders who activate through your integration.

Consumer invoicing has to be active before AvtaleGiro can be activated.

### Activation does not wait on MPS

Activation is processed in the background through Maventa's queue and completes within moments. It is not synchronous with the API call, but you will not be waiting long enough to need a "pending, please wait" screen. If a sender's status has not changed to `ACTIVE` within an hour, contact Maventa support.

Senders are reachable across all banks straight away. Sending happens under Maventa's agreement, which is already established with every bank, so there is no per-bank delay for a newly activated sender.

## What changes in the API on 15.11.2026

The way you activate does not change, on either API. What changes is what comes back.

> [!WARNING]
> If you match on response strings anywhere in your activation flow, this section is the part to read carefully. Success responses change on both APIs, because no agreement is sent for signing and the response that reports one has nothing left to report.

### If you use the REST API

You continue to activate consumer invoicing through the company profiles endpoint with `network: "BANK"`, and the profile subscription remains the record of the sender's registration.

- The signer name and email in `network_settings` are not required fields, and are not used for anything. Integrations that continue to send these values keep working, so no change is forced on you.
- `GET /v1/services/b2cno` reports what MPS knows about the sender's organisation number until 15.11.2026. From 15.11.2026 it reports the status in Maventa:

| Value | Until 15.11.2026 | From 15.11.2026 |
|---|---|---|
| `ACTIVE` | The organisation number is registered as an issuer at MPS under Maventa | Consumer invoicing is active in Maventa and the sender can send |
| `FREE` | The organisation number is not registered as an issuer at MPS by any provider | Consumer invoicing is not active for this company in Maventa |
| `RESERVED` | The organisation number is registered as an issuer at MPS by another service provider | No longer returned |
| `FAULT`, `ERROR` | Something went wrong, please contact support | Unchanged |

`RESERVED` is deprecated and is no longer returned from 15.11.2026. A registration with another service provider does not affect activation in Maventa, so the value has nothing left to report. If your integration branches on `RESERVED`, that branch becomes dead code and can be removed.

- Activating a sender that is already active is still rejected with `422`, but the error becomes `Profile is already registered for given endpoint id` instead of `Agreement is already active`. Only integrations that match on the error itself need updating.
- Deleting the sender's `BANK` network profile is how you turn the service off. The consumer invoicing route is removed from the sender and they can no longer send B2C invoices.

### If you use the SOAP API (v1.1)

Activation continues through `b2c_issuer_agreement_order`.

- A successful activation returns `OK`. The response `OK: Email sent to <signer_email>` is no longer returned from 15.11.2026, because no agreement is sent for signing.
- `signer_name` and `signer_email` remain in the method signature and are not being removed, so the SOAP contract is unchanged. They are not used to send anything. You can keep on passing the values you pass today if you need to, or not.
- Re-ordering an agreement for a sender that is already active returns `OK`.
- `disable_b2c_issuer_agreement` is how you turn the service off. From 15.11.2026 it returns `OK` unless the service was not enabled in the first place, and `ERROR: Cannot disable agreement. Issuer state is ...` is no longer returned. The consumer invoicing route is removed from the sender, and they can no longer send B2C invoices. The method name does not change, even though what it switches off is the service rather than an agreement.

> [!NOTE]
> If you still activate consumer invoicing through SOAP v1.1, this is a good moment to move to the [REST API](https://documentation.maventa.com/api-specification/rest-api/b2cno-api/). SOAP v1.1 remains available for existing integrations at least for now, but the REST API is where new functionality is added. New integrations should use REST.

## What this means for AvtaleGiro

AvtaleGiro activation and mandate handling are not changing:

- AvtaleGiro requires a direct debit agreement between the sender and their bank, tied to the bank account number the agreement is registered on. It is arranged manually with the bank, using customer ID `229221` to identify Visma, and it sits outside Maventa.
- If a sender's mandates are currently held by another service provider, a person with signatory rights authorises a takeover through Visma Sign. This is a different thing from eFaktura activation. It exists so that Maventa can retrieve the sender's existing direct debit mandates through the ATG mandate API. It does not transfer the direct debit agreement, which stays between the sender and their bank.
- Direct debit mandates are fetched by Visma only.
- Activating AvtaleGiro in Maventa does not stop a sender's existing deduction file route. The invoice notification can go through Maventa while the deduction file goes through the previous provider. eFaktura behaves the same way, so the two channels do not differ on this point.

AvtaleGiro invoices travel through the same eFaktura channel, so they are also submitted under Maventa's agreement with MPS. Nothing changes in your payloads, and the sender's own organisation number identifies them on every invoice.

## What you need to do

Very little, but one thing to check before 15.11.2026, and some cleanup you can do whenever it suits you.

### Before 15.11.2026

> [!WARNING]
> On SOAP, check what you match on for a successful activation. If you test for `OK: Email sent to <signer_email>`, that response is no longer returned from 15.11.2026 and your integration will read a successful activation as a failure. Test for `OK` instead.
>
> **This is the only change that will break an integration that works today.**

### Whenever it suits you

- On REST, if your integration matches on the `Agreement is already active` error when activating, update it. From 15.11.2026, activating an already-active sender is rejected with `Profile is already registered for given endpoint id` instead.
- If your integration handles `ERROR: Cannot disable agreement. Issuer state is ...` on SOAP, or a failed profile deletion on REST, those no longer occur from 15.11.2026. Turning the service off always succeeds unless the service is not enabled in the first place.
- If your integration branches on the `RESERVED` status, or handles an agreement signing flow for eFaktura, that code can be retired.
- If your onboarding process treats a move from another provider as a cutover, for example by asking senders to close their old agreement first or by collecting a signatory for Visma Sign, you can simplify it. Neither step is required for eFaktura.
- If your integration shows a "pending, please wait" state during activation, you can remove it.
- No changes are needed to invoice payloads, and no senders need to be re-activated.

## Timeline

| Date | What happens |
| --- | --- |
| Before 15.11.2026 | Check what your SOAP integration matches on for a successful activation, and change it to test for `OK` |
| 15.11.2026 | `RESERVED` is no longer returned, and the activation and disable responses change |
| After 15.11.2026 | Retire any code that branches on `RESERVED` or handles an eFaktura signing flow |

## Questions

For questions about your integration, contact Maventa support.

The activation process is also documented in context in [Consumer Invoicing (Norway)](https://documentation.maventa.com/integration-guide/invoice-sending/consumer-invoicing/no/), with the API methods in the [B2CNO API](https://documentation.maventa.com/api-specification/rest-api/b2cno-api/) and the [B2C Norway SOAP methods](https://documentation.maventa.com/api-specification/soap-api/b2c-norway-api-methods/).