Agreement handling for Norwegian consumer invoicing

This page covers how the main vendor agreement for Norwegian consumer invoicing (B2CNO) is handled, how eFaktura invoices reach MPS (Mastercard Payment Services) for delivery to consumers, and what changes in activation on 26th of October 2026.

It applies to the main vendor agreement only, which covers eFaktura to netbank and Vipps together with the fallback routes email and print. AvtaleGiro (direct debit), its activation and its mandate handling are not affected.

The short version: eFaktura invoices are sent under Maventa’s agreement with MPS, so moving a sender to Maventa does not take over or replace their existing eFaktura setup. From 26th of October 2026, Visma Sign is no longer needed for eFaktura and the activation responses change. Your invoice payloads do not change, and senders that are already active need no action.

eFaktura invoices are sent under Maventa’s agreement with MPS

Rather than each sender holding an individual issuer registration at MPS, Maventa submits eFaktura invoices under a single Maventa agreement. Sending under the service provider’s own agreement with MPS is the direction MPS recommends for handling issuer accounts, and it is how Maventa handles Norwegian senders.

Each sender’s own organisation number travels with every invoice as the legal organisation number, so invoices are attributed to the correct sender exactly as before.

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

A small number of senders hold their own billing account with MPS. They are left untouched and continue to send under their own organisation number.

AvtaleGiro invoices travel through the same eFaktura channel, so all of this applies to them too. Nothing changes in your payloads, and the sender’s own organisation number still identifies them on every invoice.

Because a sender’s invoices do not depend on a registration of their own at MPS, there is nothing to take over from another service provider. That is what changes in activation on 26th of October 2026.

Activation does not wait on MPS

There is no registration at MPS for a sender and nothing to poll, so activation does not depend on anything outside Maventa. It is processed in the background through Maventa’s queue, so it completes within moments rather than hours. 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. Each bank fetches new agreements from MPS on its own schedule, which is what makes a per-sender registration slow to take effect everywhere. Sending happens under Maventa’s agreement, which is already established with every bank, so there is no per-bank propagation delay for a newly activated sender.

The one thing that breaks

If you activate through the SOAP API and your integration matches on OK: Email sent to <signer_email> to detect a successful activation, that response will no longer be returned. Your integration would read a successful activation as a failure.

What changes in your integration

The way you activate does not change, on either API. What changes is what comes back, because the response that today reports that an agreement has been sent for signing no longer has anything to report.

Each change in detail

The takeover process will disappear, and so will Visma Sign for eFaktura

This is the change that matters most for onboarding.

Today, activating the main vendor agreement means transferring a sender’s existing agreement to Maventa. If MPS reports that the sender’s organisation number is already registered by another service provider, a person with signatory rights has to sign through Visma Sign to authorise the takeover, and the old agreement has to be terminated before activation can complete. Every move from another provider has to be planned as a cutover, coordinated between the sender, their previous provider and Maventa.

From 26th of October 2026, none of that applies. Maventa sends under its own agreement with MPS and will not touch a sender’s registration with another 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.

Visma Sign will no longer be used for eFaktura activation at all. Because there is no takeover, there is nothing left 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 AvtaleGiro is not affected.

RESERVED is deprecated

GET /v1/services/b2cno returns today what MPS knows about the sender’s organisation number. From 26th of October 2026 it reports the status in Maventa instead.

RESERVED exists today to signal that another service provider holds the sender’s registration and that a signature is needed. Since neither the takeover nor the signature remains, the value has nothing left to report. If your integration branches on RESERVED, that branch becomes dead code and can be removed.

Activation responses change

• REST — 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 text itself need updating.
• SOAP — a successful activation returns OK. OK: Email sent to <signer_email> is no longer returned, because no agreement is sent for signing. Re-ordering an agreement for a sender that is already active also returns OK.
• SOAP — signer_name and signer_email remain in the method signature and are not being removed. They are simply no longer used to send anything, and blank values are accepted. You can keep passing the values you pass today, or not.
• REST — the name and email in network_settings are not required fields, and are no longer used. With no signature to send, there is nobody to address it to. Integrations that continue to send them keep working, so no change is forced on you.

Turning the service off

Nothing is checked at MPS when the service is switched off, so turning it off succeeds unless the service was not enabled in the first place.

• REST — delete the sender’s BANK network profile. The consumer invoicing route is removed and the sender can no longer send B2C invoices. Deletion no longer depends on what MPS reports about the sender.
• SOAP — disable_b2c_issuer_agreement returns OK. ERROR: Cannot disable agreement. Issuer state is ... is no longer returned. The method name does not change, even though what it switches off is now the service rather than an agreement.

What stays the same

• Invoice payloads. Nothing changes in what you send, on either API.
• Senders that are already active. They keep sending without interruption. There is nothing for you or them to do, and no sender needs to be re-activated.
• How senders are identified. Each sender’s own organisation number travels with every invoice as the legal organisation number, so invoices are attributed to the correct sender.
• What consumers see. The invoice content, the sender name shown in the netbank, and the payment details are unchanged.
• How you activate. The same endpoint and the same method, with the same parameters.

AvtaleGiro is not affected

AvtaleGiro activation and mandate handling work exactly as before, including the parts that involve Visma Sign. It is easy to read “Visma Sign is no longer used for eFaktura” as “Visma Sign is gone”, and that is not the case.

• 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 still authorises a takeover through Visma Sign. This 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 continue to be 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. This has always been true for AvtaleGiro, and eFaktura behaves the same way, so the two channels no longer differ on this point.

Timeline

What you can clean up afterwards

None of this is urgent, and none of it breaks if you leave it alone.

• If your integration matches on the Agreement is already active error on REST, update it to the new message.
• If your integration handles ERROR: Cannot disable agreement. Issuer state is ... on SOAP, or a failed profile deletion on REST, those cases no longer occur.
• If your integration branches on RESERVED, or handles the agreement signing flow for eFaktura, that code can be retired.
• If your onboarding process treats a move from another provider as a cutover — 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.

Questions?

Maventa’s support team is happy to help with anything about this change.