Enter your credentials to Maventa testing environment, to authenticate and try things out with the Swagger UI. This will fetch a Bearer token using OAuth2 with the endpoint POST https://ax-stage.maventa.com/oauth2/token. The token is stored in your browser's session storage (cleared when you close the tab) and used in Swagger calls done from this documentation website. The token is valid for 1 hour.

Never use your production credentials here. This is only for testing the Maventa test environment in the Swagger UI.
All None
eui global company lookup document:receive document:send invoice:receive invoice:send company:read company:write validate receivables:assignments analysis billing:reports partner:invoice_delivery_actions partner:lookups partner:takeovers partner:lyanthe_scan_service fi_bank_message:send fi_bank_message:receive
Cancel Sign In
Search
Getting started Invoice sending Invoice sending Consumer Invoicing Printing Email Invoicing Invoice Receiving Invoice Receiving Scanning Country Specific Denmark Finland Germany Norway Sweden Document Exchange Document Exchange Peppol Network Invoicing formats Invoicing formats Validation Peppol BIS 3.0 Finvoice 3.0 Account Management Companies and Settings Billing

Consumer Invoicing (Norway)

Norway

Invoices can be sent through Maventa to consumers via direct debit (AvtaleGiro), netbank and Vipps (eFaktura), Digital postkasse innbygger (DPI, only for municipalities), e-mail and print. The invoice can be forced to go to a specific route like eFaktura or it can be specified to try all routes in a predefined order to reach the consumer with the help of our routing logic. Activation comes at no cost, and there are no extra monthly or yearly charges associated with using the service. Your only expense will be for the transactions you make.

Updates regarding the consumer invoicing in Norway:

  1. The creation of new eFaktura references has been discontinued already a few years ago
  2. Agreement capture (Avtalefangst) no longer works, and API method returns error.
  3. The “Yes to All” registry or “Ja takk til alle” registry (JTTA) lookup will no longer be performed using the eFaktura reference but will instead rely on the information provided on the invoice (or in the metadata given in sending API).
  4. Automatic import of existing CV-links during the activation process is discontinued.

Activation and agreements

There are two vendor agreements that needs to be signed in order to use both the direct debit and eFaktura (netbank and Vipps) routes.

The main vendor agreement

Before the company can send consumer invoices through Maventa, or enable any of the extra features like the direct debit solution, the main vendor agreement must be activated. The main vendor agreement enables the sending of eFaktura (netbank and Vipps) and using the fallback routes e-mail and print. To enter into an agreement with Visma is enough to reach all the banks and the company does not need a separate agreement with their own bank to enable the consumer invoicing.

Only a norwegian company account in Maventa can activate the agreement and send invoices to Norwegian consumers.

When activation is initiated either through the API or UI, Maventa does a query to MPS (Mastercard payment services) to check if the given organisation number already has an existing agreement through another service provider. If another agreement exists, the person with signatory rights for the company needs to sign an agreement through Visma Sign’s electronic signing service to give consent for Visma to move the old agreement to Visma. Note! It is the company’s responsibility to make sure that the old agreement is closed, so that they do not come into a conflict with this agreement.

If the company does not have existing consumer agreement, the service is activated immidiately without the need to sign a separate agreement through Visma Sign as the company has already approved the Visma TOS.

Activation timeline: MPS creates the agreement immediately but it usually takes about an hour for the information to get updated on Maventa as we fetch new agreements every 30 minutes. For the agreement to get activated within all the banks, it can take up to 24 hours since each bank fetches agreements from MPS under different timelines. Usually it only takes a couple of hours.

API methods for activating the main vendor agreement:

API Method without e-mail authorization:

Using the AX REST api https://ax-stage.maventa.com/swagger/#!/company/postV1CompanyProfiles method. This method will return error unless the vendor_api key is included in a list of allowed signers. Example:

{ “profiles”:[“INVOICE”], “network”:”BANK”, “network_settings”: { “name”:”Signer name”, “email”:”Signer email”, “agreement_signed”:”true”} }

GET /v1/services/b2cno https://swagger.maventa.com/?urls.primaryName=STAGE%20-%20AutoXChange%20API#/services/getV1ServicesB2cno to get status of the B2CNO/main agreement?

Agreement for B2CNO

Yes to All registry (JTTA) and eFaktura identifier

“Yes to All” registry or “Ja takk til alle” registry (JTTA) is a way for consumers to accept e-invoice from all the suppliers. When doing this the consumer gets added into a MPS registry and gets assigned an eFaktura identifier which is then the same identifier used by all the supplier when sending e-invoices to that particular consumers in their netbank. With the old, already deprecated eFaktura references (CVR) there was a direct connection between the specific supplier and the consumer, but an eFaktura identifier is more general that all suppliers can use. By activating the “Yes to All” from their netbank, consumer accepts e-invoices from all suppliers that are able to send e-invoice. When “Yes to All” is activated there is no need for the supplier to send out any consumer requests and the first invoice can be sent directly to the consumer’s netbank.

Maventa does not fetch and store the eFaktura Identifiers, but instead uses the Yes to All registry for lookup to get the consumer’s eFaktura identifier based on the data given on the invoice including email, phone, address, name and SSN. Order and combination of the data used:

  1. Social security number (SSN)
  2. Date of Birth + Phone number + email combination
  3. If one or two of the above is missing (DOB, phone number or email) then name, postalcode and city is used. If there is no DOB, phone number nor email given, there will be no lookup towards Yes to All registry and invoice will be routed to next possible channel

Some ERPs have their own direct API connection to MPS to do the JTTA lookup to get the eFaktura identifier and then use that when sending invoices to Maventa.

Direct debit agreement for AvtaleGiro

AvtaleGiro is a direct debit payment method used throughout the Norway.

Direct debit solution through Maventa means that when the direct debit invoice is sent, the deduction file is created automatically by MPS based on the data from the invoice. By using Maventa solution the supplier does not need to create the deduction file themselves and then sent it through another channel as the direct debit has worked before. Addition to the automatic creation of the deduction file, our solution also handles the invoice notification.

NOTE! This is not to be confused with a current combo solution thorough Maventa where the invoice notification is sent by Maventa but the deduction file must be created elsewhere and sent to MPS either through direct integration from the ERP to MPS or through AutoPay.

To get started the with the AvtaleGiro the supplier needs a direct debit agreement with their bank. This is a manual process today and it is handled outside of Visma. In the agreement with the bank the supplier must specify customer ID as 229221. This is to identify the direct debit solution with Visma and to give consent for Maventa to have an authority to send deduction files on the behalf of the supplier, and to fetch their mandates.

If the supplier already has an active AvtaleGiro agreement with another service provider, they need to authorize the take-over process using Visma sign. During activation the supplier is required to enter an e-mail address to a person within the company that has signatory rights. Once the agreement is signed the activation itself starts and we send the necessary data to MPS.

If another agreement exists, the person with signatory rights for the company needs to sign an agreement through Visma Sign’s electronic signing service to give consent for Visma to move the old agreement to Visma. Company is responsible for making sure the old agreement is closed. Note! If the supplier already has an active agreement and are already sending deduction files through another service provider, activation in Maventa does not stop the old route like it does for eFaktura to netbank. Meaning they can send invoice combo through us and deduction file through old channel and it will not be stopped at MPS. However, the mandates can only be fetched from MPS by Visma.

If the supplier already have an active agreement with their bank they can activate direct debit through Maventa and we configure the agreement with MPS.

Maventa needs the following information from the company:

  1. Bankaccountnumber that the ATG agreement is registered on.
  2. Length of KID (numbers of digits in KID including control digit)
  3. Mandate/Reference position in KID (example 1-6)

Agreement can be activated through the API or UI.

Mandates

Mandates are collected and stored in Maventa.

Once a direct debit agreement is established, a consumer can create one or more payment mandates — each representing an agreement between the consumer and their bank to automatically pay recurring invoices to a specific payee on the due date. Mandates can only be registered with payees that support AvtaleGiro.

Each mandate includes the following details:

Mandates can be created by the consumer in one of the following ways:

Note: As long as the consumer has both an active mandate and an e-invoice agreement, the invoice itself will always serve as the payment notification.

Mandates are visible in the UI and can also be retrieved via the API.

Mandates are first fetched by Maventa when AvtaleGiro is activated, and then updated four times per day, checking for new or modified entries.

Field Type Description
kid string KID reference identifying the payer/payee relationship
account_number string Payer’s account number
notification boolean 1 - consumer wants to be notified of avtalegiro sends, 0 - no notification.
status integer 1 - active, 0 - inactive
updated_timestamp string Timestamp of the last update

When a consumer creates a direct debit mandate in their bank, they can choose whether they want to receive notifications for upcoming payments. They only decide whether to receive notifications — not how they are sent. We do not support bank-issued notifications. Instead, we support:

When using eFaktura as the notification channel, we must also locate the recipient in Y2A. Please note that an eFaktura used as a notification cannot be paid directly in the bank unless the consumer manually adjusts it.

REST API

Sending consumer invoices

Use POST /v1/invoices for sending the invoice. Following parameters apply to consumer invoices in Norway:

Route order and recipient type

When sending consumers invoices it is mandatory to specify the recipient_type as “consumer” on the sending API metadata. Recipient_type identifies that the invoice is going to the B2C route. If “consumer” is not specified, the invoice will go to the B2B route.

It is also recommended that integrators use the route_order when sending consumer invoices. Route_order specifies the available routes the supplier wants to use and the priority of those routes. If the route_order is empty or it is left out completely the invoice will go to the predefined default route order.

Default route order is the following:

Route route_order value Note
Direct debit (AvtaleGiro) netbank Direct debit route is part of the default route order only if the direct debit is active on the supplier’s account
eFaktura to netbank netbank eFaktura and VIPPS
email email if email address is given on the invoice data or in sending API metadata
print print Print service does not need to be enabled separately on the supplier’s account, printing will work anyway

Example of sending a consumer invoice to a defined route order:

{
{ "version":"1.1", "recipient_type": "consumer", "routing": { "route_order":["netbank", "email", "print"] } }
}

When sending B2C invoices, the print service doesn’t need to be enabled in the supplier’s Maventa account. The print route is automatically enabled if it’s specified in the route order or if the default route order settings are used. The printed invoice will always use the sender’s invoice image, if provided, regardless of the print settings.

In certain situations, companies may have a specific need to have the route order set per supplier account not per invoice. In such cases, Maventa can assist in making this change. Please reach out to the Maventa support for further information and guidance on how to proceed with this request.

Attachments and invoice image

Attachments are supported through Visma Document Hotel. Limitations are the same as for print. Maventa send a link to Visma Document Hotel where we show only PDFs. If the invoice contains other attachment formats like .png we do not pass these on to consumer.

Sending an invoice as direct debit (AvtaleGiro)

When the main vendor agreement and direct debit agreement are both active, direct debit invoices can be sent.

Instead supplier creating the deduction file and sending it to MPS themselves, the supplier can send the invoice via Maventa and the deduction file is created automatically based on that data on the invoice. The notification (eFaktura, e-mail or print) is also handled and sent out by Maventa. Meaning the supplier does not have to relate to two different channels.

Prerequisites for the supplier:

Prerequisites for the consumer:

The direct debit route is the first option in our default route order if the supplier has the direct debit activated.

Prerequisites towards the direct debit invoice:

If above mentioned prerequisites are not met or MPS returns an error that the mandate is not active, invoice will go to the next possible route (eFaktura, or email/print).

Consumer notification on upcoming Direct Debit

Consumers have the option to receive notifications about upcoming direct debits when they enter into a direct debit agreement with their supplier. The notification will primarily be sent as an eFaktura if the consumer has activated eFaktura through JTTA. If eFaktura is not activated, the notification can be sent via email or in print. If the consumer does not want to receive notifications, Maventa will only send the invoice as a direct debit without notification.

It is also possible for the supplier to disable notifications if they choose to do so.

Notification via eFaktura

If the consumer has eFaktura activated through JTTA notification will always be sent to netbank. It will be shown as an invoice with a direct debit and will not be possible for the consumer to pay.

Notification via email

If the consumer wants to be notified, and does not have eFaktura active, then the notification will be sent as email as long as there is an address available. The text in the e-mail specifies that this is a direct debit agreement to eliminate the risk of it getting paid twice.

Notification via print

If the consumer wants to be notified, and does not have eFaktura or e-mail address given, then the notification will be sent to print. Maventa will add a cover sheet to the invoice where it specifies that this is a direct debit and should not be paid.### Sending an invoice as eFaktura to MPS

When the main vendor agreement is active the first invoice can be sent. In order to send an invoice as eFaktura the receiver must be registered in in the “Yes to all” registry with MPS (JTTA).

validation on eFaktura:

Send an invoice as eFaktura to Vipps

eFaktura means both sending to Netbank and Vipps as long as the consumer is part of the “Yes to all” registry (JTTA) and has not disabled receiving in their Vipps application. What is sent to netbank is also shown in the Vipps application. Invoice is visible, and it can be paid in both netbank or Vipps, but cannot be paid twice. It is not possible anymore to only receive in Vipps.

Requirements on consumer to receive an invoice in Vipps:

  1. Consumer has activated Vipps eFaktura in Vipps application.
  2. Consumer has enabled Y2A in their nettbank or in their vipps application.

However the following scenarios need to be taken into account:

  1. If the consumer does not want to show the invoice in vipps, there is a toggle for this in vipps, the invoice will still be sent to vipps but visible only in netbank
  2. There is no scenario anymore where the invoice is only shown in vipps
  3. Creditnotes are not supported in VIPPS. Invoices can be sent to Vipps with total amount = 0.
  4. Direct debit invoices are not supported in VIPPS.

Status:

When sending an invoice to Vipps the invoice is then validated and been sent to the consumers application and is visible under the payment section in the application. This is done in about 15 minutes. Status with Vipps is then pending and status with Maventa is sent. Sent status is the final status of this invoice. There it will stay until 14 days after due date then it is removed from the application.

Note: ERPs that use invoice_create method can not send invoices to VIPPS because the phone number could not be saved to Database

Send an invoice to Digital Postkasse Innbygger (DPI)

Maventa can route an invoice to the Digital Postkasse Innbygger (DPI), which is used only by municipalities (Visma Enterprise). When sending to DPI the payload must contain a social security number (personnummer) in a .aix file. The SSN will be used to check the consumer against the Kontakt og Reservasjonsregistret (KRR). In KRR the consumer has chosen if they want to receive invoices or not to their DPI account, and if that account is in either eBoks och DigiPost.

In order to send to DPI or send with SSN contact Maventa support.

Back to top