Consumer Invoicing (Norway)
Send invoices to Norwegian consumers via direct debit (AvtaleGiro), netbank and Vipps (eFaktura), Digital postkasse innbygger (DPI, for municipalities only), email, and print. You can force an invoice to a specific route or let Maventa’s routing logic try all routes in a predefined order.
Activation and agreements
Two vendor agreements are required to use both direct debit and eFaktura (netbank and Vipps):
- The main vendor agreement — for eFaktura (and Vipps) and the fallback routes email and print
- The direct debit agreement — for direct debit (AvtaleGiro)
The main vendor agreement
Before you can send consumer invoices through Maventa or enable features like the direct debit solution, the main vendor agreement must be activated. It enables sending eFaktura (netbank and Vipps) and using the fallback routes email and print. A single agreement with Visma gives you access to all banks — no separate agreement with your own bank is needed.
Only a Norwegian company account in Maventa can activate the agreement and send invoices to Norwegian consumers.
When activation is initiated through the API or UI, Maventa queries MPS (Mastercard Payment Services) to check whether your organisation already has an agreement with another service provider. If another agreement exists, the person with signatory rights must sign an agreement through Visma Sign’s electronic signing service to transfer the old agreement to Visma.
It is your responsibility to ensure the old agreement is closed to avoid any conflicts.
If your company does not have an existing consumer agreement, the service is activated immediately — no separate agreement through Visma Sign is required, as you have already approved the Visma Terms of Service.
Activation timeline: MPS creates the agreement immediately, but it usually takes about an hour for the information to update in Maventa, as Maventa fetches new agreements every 30 minutes. For the agreement to activate across all banks, allow up to 24 hours, as each bank fetches agreements from MPS on different schedules. In practice, it usually takes a couple of hours.
API methods for activating the main vendor agreement:
Use the AX REST API POST /v1/company/profiles method. This method returns an error unless the vendor API key is included in the list of allowed signers. Example:
{
"profiles": ["INVOICE"],
"network": "BANK",
"network_settings": {
"name": "Signer name",
"email": "Signer email"
}
}If an agreement already exists, Maventa sends a takeover request to be signed by the signer specified in network_settings.
Use GET /v1/services/b2cno to get the status of the main agreement. Status values:
-
ACTIVE— Agreement is active with Maventa -
FREE— No existing agreement with another supplier. Activation is immediate, based on the Visma Terms of Service. No separate agreement needs to be signed. -
RESERVED— An existing agreement with another supplier exists. You must approve the agreement with Maventa via Visma Sign. The agreement is sent automatically to the email address provided in the activation API call. -
FAULT— Something went wrong. Contact support. -
ERROR— Something went wrong. Contact support.
You can also register a webhook to receive notifications whenever the service status changes.
Yes to All registry (JTTA) and eFaktura identifier
The Yes to All (“Ja takk til alle”, JTTA) registry lets consumers accept e-invoices from all suppliers. When a consumer registers, they are added to the MPS registry and assigned an eFaktura identifier — the same identifier all suppliers use when sending e-invoices to that consumer’s netbank. Unlike the deprecated eFaktura references (CVR), which created a direct link between a specific supplier and consumer, the eFaktura identifier is general and usable by all suppliers.
Once a consumer activates Yes to All from their netbank, they accept e-invoices from all suppliers that support it. No consumer request is needed — the first invoice can be sent directly to the consumer’s netbank.
Maventa does not fetch and store eFaktura identifiers. Instead, Maventa uses the Yes to All registry to look up the consumer’s eFaktura identifier based on the data provided on the invoice. The lookup order is:
- Social security number (SSN)
- Date of birth + phone number + email combination
- If one or two of the above (date of birth, phone number, or email) are missing, name, postal code, and city are used instead. If none of date of birth, phone number, or email are provided, no lookup is performed against the JTTA registry and the invoice is routed to the next available channel.
Some ERPs have their own direct API connection to MPS to perform the JTTA lookup and retrieve the eFaktura identifier, which is then passed to Maventa when sending invoices.
Direct debit agreement for AvtaleGiro
AvtaleGiro is a direct debit payment method used across Norway.
When you send a direct debit invoice through Maventa, MPS automatically creates the deduction file based on the invoice data. You do not need to create the deduction file yourself or send it through a separate channel. Maventa also handles the invoice notification.
This is not to be confused with the combo solution, where Maventa sends the invoice notification but the deduction file must be created separately and sent to MPS — either through a direct integration from the ERP to MPS or through AutoPay.
To get started with AvtaleGiro, you need a direct debit agreement with your bank. This is a manual process handled outside of Visma. In the agreement with your bank, specify customer ID 229221. This identifies the direct debit solution with Visma and authorises Maventa to send deduction files on your behalf and to fetch your mandates.
If you already have an active AvtaleGiro agreement with another service provider, you need to authorise the takeover process using Visma Sign. During activation you must provide an email address for a person within your company with signatory rights. Once the agreement is signed, activation begins and the necessary data is sent to MPS.
If you already have an active agreement and are sending deduction files through another service provider, activating in Maventa does not stop the old route — unlike eFaktura to netbank. This means you could be sending the invoice notification through Maventa and the deduction file through the old channel simultaneously, and it will not be blocked at MPS. However, mandates can only be fetched from MPS by Visma.
If you already have an active agreement with your bank, you can activate direct debit through Maventa and Maventa will configure the agreement with MPS.
Maventa needs the following information from your company:
- Bank account number that the AvtaleGiro agreement is registered on
- Length of KID (number of digits in KID, including the control digit)
- Mandate/reference position in KID (example: 1–6)
The 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 mandate represents 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:
- KID — identifies the payer/payee relationship
- Payer’s account number
- Payee’s account number
- Amount limit — the maximum monthly amount that will be automatically paid to the payee. This limit is set by the payer and remains private; it is not shared with the payee
- Notification setting — indicates whether the payer wishes to receive a notification before each payment
Mandates can be created by the consumer in one of the following ways:
- Directly in their online bank after paying the first invoice
- Through the supplier’s website
- Using a paper form sent by the supplier
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. Maventa first fetches mandates when AvtaleGiro is activated, then updates them four times per day.
| 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 payments, 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 to receive notifications for upcoming payments. Maventa does not support bank-issued notifications. Instead, Maventa supports:
- eFaktura (preferred notification method)
When activating AvtaleGiro, you choose whether email and/or print notifications are offered.
When using eFaktura as the notification channel, Maventa must also locate the recipient in the Y2A registry. Note that an eFaktura used as a notification cannot be paid directly in the bank unless the consumer manually adjusts it.
REST API
- POST /v1/services/atg — Activate a new AvtaleGiro agreement
- GET /v1/services/atg — Get the status of the AvtaleGiro agreement
- PATCH /v1/services/atg/{account_number} — Update an existing AvtaleGiro agreement
- GET /v1/services/atg/{account_number} — Get information about the AvtaleGiro agreement
- GET /v1/services/atg/mandates — Fetch mandates
Sending consumer invoices
Use POST /v1/invoices to send consumer invoices. The following parameters apply to Norwegian consumer invoices:
-
recipient_type— Mandatory for Norwegian consumer invoices. Must be set toconsumerto enable use ofroute_order. -
route_order— Defines which delivery channels to use and in what order they are attempted. If omitted, the default routing order is applied. Note:netbank_cvl,netbank_cvl_hold, andvippsare deprecated. Supported values are:netbank,dpi,email,print,silent_failure. -
recipient_phone_number— Recipient’s phone number in international format. Used for Y2A lookups. -
recipient_date_of_birth— Recipient’s date of birth inYYYY-MM-DDformat. Used for Y2A lookups. -
recipient_ssn— Recipient’s social security number. Used for Y2A lookups. -
recipient_efaktura_id— Recipient’s unique eFaktura ID. Used for routing when provided in the metadata. -
b2cno_document_type— Specifies the B2C document type. Supported values areINVOICE,CREDIT_NOTE,REMINDER, andCOLLECTION_NOTICE. This only affects the document title shown in the customer’s netbank.
Route order and recipient type
Setting recipient_type to consumer is mandatory for B2C invoices. Without it, the invoice is routed to the B2B route instead. If recipient_efaktura_id is provided in the metadata, it is used as the first routing option.
It is recommended to specify route_order when sending consumer invoices. This defines which routes are available and in what priority order. If route_order is empty or omitted, the predefined default route order is used.
Routes available for B2C invoices:
| Route | Value | Note |
|---|---|---|
| Direct debit (AvtaleGiro) | netbank |
Included in the default route order only if direct debit is active on your account |
| eFaktura to netbank | netbank |
eFaktura and Vipps |
email |
If an email address is provided on the invoice data or in the sending API metadata | |
| Digital Postkasse Innbygger (DPI) | dpi |
DPI for municipalities only |
print |
Print does not need to be enabled separately on your account | |
| Silent failure | silent_failure |
The “all routes failed” error is not triggered and no error email is sent — the invoice fails silently |
Default route_order if not specified: netbank (AvtaleGiro, eFaktura), email, print.
Example of sending a consumer invoice with a defined route order:
{ "version": "1.1", "recipient_type": "consumer", "routing": { "route_order": ["netbank", "email", "print"] } }When sending B2C invoices, the print service does not need to be enabled in your Maventa account. The print route is automatically available if specified in the route order or if the default route order is used. The printed invoice always uses the sender’s invoice image if one is provided, regardless of print settings.
In certain situations you may need route order set at the account level rather than per invoice. Contact Maventa support for help with this.
Operator codes
As an alternative to route_order, you can use an operator code to control how an invoice is routed. Maventa highly recommends using route_order instead of operator codes, as it provides more flexibility and control over delivery channels. Three operator codes are available:
| Operator code | Description |
|---|---|
B2CNO |
The invoice is sent using the default route order. |
B2CNO_AGIRO_VIEW |
A direct debit and eFaktura combination. The deduction file must be sent to MPS from the ERP directly. Maventa and MPS create the eFaktura notification based on the e-invoice and deliver it to the consumer’s netbank. |
B2CNO_AGIRO |
A direct debit and eFaktura combination where MPS creates the deduction file based on the e-invoice. No need to send the deduction file separately to MPS from the ERP. |
Operator codes and route_order are mutually exclusive. If both are specified, the API returns an error.
Attachments and invoice image
Attachments are supported through Visma Document Hotel, with the same size and format limitations as print. Maventa sends a link to Visma Document Hotel that shows PDFs only. Attachments in other formats (such as .png) are not passed on to the consumer.
Sending an invoice as direct debit (AvtaleGiro)
When both the main vendor agreement and the direct debit agreement are active, direct debit invoices can be sent.
Instead of creating the deduction file yourself and sending it to MPS, send the invoice through Maventa and the deduction file is created automatically from the invoice data. The notification (eFaktura, email, or print) is also handled by Maventa — there is no need to manage two separate channels.
Prerequisites for you as the supplier:
- An active main vendor agreement with Maventa
- An active direct debit (AvtaleGiro) agreement with your bank, with customer ID
229221 - Direct debit activation completed through Maventa
Prerequisites for the consumer:
- An active direct debit agreement with you (a mandate must exist)
The direct debit route is the first option in Maventa’s default route order if direct debit is activated on your account.
For an invoice to be sent as direct debit, the following conditions must be met:
- The KID and bank account number are provided
- The due date is not in the past and is at least 3 days away
- The invoice is valid XML (correct amounts, etc.)
- An active mandate exists for the consumer
If any of these conditions are not met, or if MPS returns an error indicating the mandate is inactive, the invoice falls through to the next available route (eFaktura, email, or print).
Consumer lookup
Use GET /v1/lookup/consumers to check whether a consumer can receive consumer invoices, and through which channel (eFaktura, DPI, or both).
Providing more consumer information increases the likelihood of a successful match. An exact match can be achieved using an eFaktura ID or SSN; other data points are matched in combination:
- SSN or eFaktura ID
- Date of birth + phone number + email
- If one or two of the above (date of birth, phone number, or email) are missing, name, postal code, and city must be provided in combination
- If none of date of birth, phone number, or email are provided, no lookup is performed against the Y2A registry and the invoice is routed to the next available delivery channel (email or print)
The response indicates whether the consumer was found in the Y2A registry and, if applicable, returns their eFaktura ID for use in the sending API metadata. It also indicates whether the consumer is available as a DPI recipient.
Test consumers
The following test consumers are available in the staging environment for testing the consumer lookup and invoice sending:
| Field | Consumer 1 | Consumer 2 | Consumer 3 |
|---|---|---|---|
| SSN | 13121622259 | 09091816528 | 05111926664 |
| First name | Bjørg | Halgeir | Bodil |
| Last name | Forsøk | Underbakk | Tangen |
| eFaktura ID | 207080383 | 414360222 | 501216659 |
| Phone number | 21622259 | 91816528 | 11926664 |
| trude16@mpstest.no | halgeir18@mpstest.no | bodil99@mpstest.no | |
| Address | Traneveien 204 | Trollstigen 120 | Melkeruta 501 |
| Postal code | 8901 | 6486 | 8901 |
| City | Brønnøysund | Orten | Brønnøysund |
| Y2A enabled | No | Yes | Yes |
- Consumer 1 (Bjørg Forsøk) — Contains special characters (ø) in both name and address, and is not registered in the Y2A registry. Use this consumer to test fallback routing when eFaktura is not available, and to verify correct handling of special characters.
- Consumer 2 (Halgeir Underbakk) — Standard text throughout all fields, registered in Y2A. Use this consumer for a straightforward eFaktura delivery test.
- Consumer 3 (Bodil Tangen) — Registered in Y2A and contains a special character (ø) in the city name. Use this consumer to verify that character encoding is handled correctly in the eFaktura flow.
Consumer notification on upcoming direct debit
Consumers can opt to receive a notification about upcoming direct debits when they enter into a direct debit agreement. The notification is sent as eFaktura if the consumer has activated eFaktura through JTTA. If eFaktura is not active, the notification can be sent via email or print. If the consumer does not want notifications, Maventa sends the invoice as a direct debit only.
You can also disable notifications on your end if needed.
Example AvtaleGiro notification template — this is how a notification sent via email or print will look to consumers.
Notification via eFaktura
If the consumer has eFaktura activated through JTTA, the notification is always sent to netbank. It appears as an invoice with a direct debit indicator and cannot be paid by the consumer directly.
Notification via email
If the consumer wants a notification and does not have eFaktura active, the notification is sent as email if an address is available. The email text specifies that this is a direct debit to prevent accidental double payment.
Example AvtaleGiro notification email body.
Notification via print
If the consumer wants a notification and neither eFaktura nor an email address is available, the notification is sent to print. Maventa adds a cover sheet to the invoice specifying 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, you can start sending invoices. To send as eFaktura, the recipient must be registered in the Yes to All (JTTA) registry with MPS.
eFaktura validation
The following validation rules apply:
- Due date must be at least three days in the future
- Payable amount must be a positive amount
- Bank account number must be 11 digits and pass the MOD 11 check
- KID must be 2–25 digits and pass the MOD 10 check
Sending an invoice as eFaktura to Vipps
eFaktura sends to both netbank and Vipps, as long as the consumer is registered in the JTTA registry and has not disabled receiving in Vipps. What is sent to netbank is also shown in Vipps. The invoice can be paid in either netbank or Vipps, but not both. Receiving invoices in Vipps only is not supported.
For a consumer to receive an invoice in Vipps:
- The consumer has activated Vipps eFaktura in the Vipps application
- The consumer has enabled Y2A in their netbank or Vipps application
The following edge cases apply:
- If the consumer has disabled invoice display in Vipps, the invoice is still sent to Vipps but only visible in netbank
- There is no scenario where an invoice is shown in Vipps only
- Credit notes are not supported in Vipps. Invoices with a total amount of 0 can be sent to Vipps.
- Direct debit invoices are not supported in Vipps
Status: When an invoice is sent to Vipps, it is validated and delivered to the consumer’s application within approximately 15 minutes, where it appears under the payment section. The status in Vipps is then pending; the status in Maventa is sent, which is the final status. The invoice remains in the application until 14 days after the due date, after which it is removed.
ERPs using the invoice_create method cannot send invoices to Vipps because the phone number cannot be stored in the database.
Sending an invoice to Digital Postkasse Innbygger (DPI)
To enable Maventa to send digital post to consumers on your behalf, your organisation must first have an agreement with Digdir for DPI. This is done outside Maventa, directly with Digdir. Then, log in to Altinn and delegate the right to send DPI to Visma Software International AS (contract counterparty for Maventa). Maventa provides the technical delivery. Once this delegation is in place, no further setup is needed.
Detailed instruction on the Altinn side:
- Log in to Altinn: https://www.altinn.no/
- Select the organisation you are representing
- Click “Profile” in the top menu
- Click “Access to the programming interface – API”
- Click “Grant and remove API access”
- Click “Delegate new API”
- Select the API called “Delegate the right to send DPI messages on behalf of the organisation” by searching for “dpi” in the search field
- Click the plus sign to the right of the organisation’s name
- Click “Next”
- Search for the organisation that should be granted the right to send DPI by organisation number (Visma’s organisation number: 980858073)
- Click the plus sign to the right of the organisation’s name and organisation number
- Click “Next”
- Click “Confirm”
When sending to DPI, the payload must contain a social security number (personnummer) either provided in a .aix file or as a parameter in the metadata. The SSN is used to check the consumer against the Kontakt og Reservasjonsregisteret (KRR). The consumer specifies in KRR whether they want to receive digital post and whether their account is in eBoks or DigiPost.