Skip to main content

​
Introduction

Finnish businesses receive their e-invoices over two networks: the domestic operator network (Finvoice/TEAPPSXML) and Peppol. The Finland app delivers on the domestic network, through Invopop’s partner operator, Apix Messaging. You send a GOBL invoice with the receiver’s e-invoice address, and the receiver gets it in the format its operator expects. If your receiver is only on Peppol, use the Peppol app. To find out which network a receiver is on, look them up at verkkolaskuosoite.fi, which lists both. For onboarding suppliers, see the companion guide: Finvoice supplier registration.

​
Payment data is mandatory

In Finland, an e-invoice doubles as a payment order: the Finvoice format was created by the banks, and receivers approve invoices for payment directly in their bank. The payment order is therefore mandatory on every Finvoice invoice, credit notes included. Since most Finnish receivers get their invoices as Finvoice, every Finnish invoice must carry:
  • An IBAN, in payment.instructions.credit_transfer, with the key credit-transfer.
  • A payment reference, in payment.instructions.ref: a Finnish viitenumero or an ISO 11649 RF reference.
  • A dated due date, in payment.terms.due_dates.
The fi-finvoice-v3 addon enforces these rules when the invoice is validated, so an incomplete invoice is rejected up front. This is deliberate: without the payment data, the invoice would fail on its way to the receiver after leaving the platform, where neither you nor Invopop can see it.

​
Prerequisites

  • A registered supplier: follow the Finvoice supplier registration guide to connect the Finland app and register the party before issuing.
  • The receiver’s e-invoice address on the customer record, as an endpoint: iso6523-actorid-upis::0216: followed by the OVT code (0037 plus the Business ID without its hyphen). A customer record from before endpoints may still carry it as a 0216 inbox, which is read when there is no endpoint. Look receivers up at verkkolaskuosoite.fi. Other forms circulate (IBAN-style addresses, operator-prefixed ones such as TE0037…), but the OVT code is the one to use.
  • The receiver’s operator ID in the customer’s ext.fi-finvoice-operator, whenever you know it. See the receiver’s operator below.
  • The fi-finvoice-v3 addon declared in $addons on every invoice, so the payment data above is validated before signing.
  • Complete payment data on every invoice, as described above.

​
The receiver’s operator

In Finland an e-invoice address is quoted as a pair: the address and the operator that serves it, for example 003711223349 at Apix Messaging, 003723327487. An address can be registered with more than one operator at once, which happens whenever a company changes operator and keeps the old registration alive for a while. The invoice then goes to whichever operator the sender’s operator prefers, and that may not be the one your receiver reads. Set the operator ID your receiver gave you on the customer party, in the fi-finvoice-operator extension, and the invoice is routed to that operator:
The value is the operator’s own OVT code, or a bank’s BIC for addresses served by a bank, as listed beside the address at verkkolaskuosoite.fi. Without the extension, the operator chooses the route itself, which is fine for an address registered with one operator only. An operator ID the address is not registered with is not rejected: the operator accepts the invoice and routes it by its own tables, so check the pair you were given rather than relying on an error. Received invoices carry the sender’s operator in the same extension on the supplier party, so you can route a reply back the same way.

​
Setup

All of the following steps must be carried out from the Invopop Console.
1

Create the send workflow

​
Send an invoice

Upload the invoice as a silo entry and run the send workflow on it.
The recommended approach for running jobs is to perform two steps: first upload the document to the silo, then create a job.
The send step converts the invoice to Finvoice 3.0, checks the receiver is reachable, and submits it. The operator’s synchronous accept or reject is reflected in the job result, along with the channel the invoice was actually delivered on.

​
Refused before sending

Two checks run before anything leaves the platform:
  • Conversion to Finvoice. The invoice is validated under the fi-finvoice-v3 addon and written as Finvoice first, so an invoice the format cannot carry fails the job with the rule it broke: missing payment data, a party without an e-invoice address, an identifier too long for its element. Fix the invoice and run the workflow again.
  • receiver-not-einvoice: the receiver is not set up to receive e-invoices. The error names the channel that would have been used instead: paper, email, or one of the consumer bank channels (e-lasku, suoramaksu, Netposti). Receivers like these are refused up front rather than quietly delivered another way; check the address, or agree on another delivery method with the receiver.

​
After submission

One more state you may meet is send-unconfirmed: the connection failed after the submission may have already been written, so the outcome couldn’t be confirmed. The job reports the attempt and its timestamp rather than retrying, because resubmitting into the unknown could deliver the invoice twice. Check with support before sending again. Once the operator accepts the invoice, that is the final programmatic signal: there is no delivery status to poll afterwards. If a receiving operator later rejects the invoice, the rejection arrives by email in production.

​
Invoicing the Finnish state

Invoicing public bodies is the segment where e-invoicing is mandatory in Finland, and the state applies its own reference conventions: invoices that don’t follow them are rejected by the receiving authority.
  • Order numbers must start with V1. Set them in ordering.purchases on the GOBL invoice.
  • Agreement numbers must start with VSK1. Set them in ordering.contracts.
  • At most one of each per invoice.
Invopop doesn’t validate or normalise these prefixes, so format the references exactly as the contracting authority provided them. Posting references (TK1…) cannot be carried on the invoice yet; if a contracting authority requires one, contact support.

​
Example invoices

In this example, we’re issuing a B2B invoice from a Finnish supplier to another Finnish business.Notice:
  • the $addons field is set to fi-finvoice-v3, which enforces the payment data Finvoice requires on every Finnish invoice,
  • both parties have their e-invoice address as an endpoint: iso6523-actorid-upis::0216: followed by an OVT code (0037 followed by the Business ID without its hyphen), and the customer names its operator in fi-finvoice-operator, so the invoice reaches that operator even if the address is registered with another one too,
  • the payment block carries an IBAN, a payment reference (an ISO 11649 RF reference here), and a dated due date; all three are required,
  • the invoice includes VAT at the standard Finnish rate of 25.5%, and,
  • there are no calculations in some fields; these will be made automatically when uploading.
In this example, we’re invoicing a Finnish public body, the segment where e-invoicing is mandatory.Notice:
  • the ordering.purchases code starts with V1 and the ordering.contracts code starts with VSK1, following the Finnish state’s reference conventions; the state rejects invoices that don’t follow them,
  • there is at most one order number and one agreement number, as the state requires,
  • the payment reference here is a Finnish viitenumero (banking reference number), the domestic alternative to the RF form, and,
  • everything else works exactly like the B2B invoice, payment block included.
In this example, we’re issuing a credit note that corrects a previously issued invoice.Notice:
  • the type is set to credit-note,
  • the preceding array references the original invoice by its series, code, and issue_date, along with a reason,
  • the payment block is still present and complete; Finvoice requires the payment data on credit notes too, unlike most other European formats, and,
  • there are no calculations in some fields; these will be made automatically when uploading.

​
FAQ

Yes. Most Finnish businesses receive e-invoices through the domestic operator network, and the Finland app delivers there. You send one GOBL invoice with the receiver’s e-invoice address, and it arrives in the format the receiver’s operator expects. You can check which network a receiver is on at verkkolaskuosoite.fi. For a receiver only on Peppol, use the Peppol app.
Because in Finland an e-invoice doubles as a payment order. Finvoice was created by the banks (it’s published by Finance Finland, the banking association) and grew out of the bank network, where the receiver approves the invoice for payment directly in their bank. That’s why every Finvoice invoice, credit notes included, must carry the payment order: an IBAN, a payment reference, and a dated due date. Most Finnish receivers get their invoices as Finvoice, and one missing this data would fail on its way to the receiver, where we can’t see it, so the fi-finvoice-v3 addon rejects it up front instead.
Two checks run before anything leaves the platform. The invoice is converted to Finvoice first, so anything the fi-finvoice-v3 addon refuses fails the job with the rule it broke: missing payment data, a party without an e-invoice address, an identifier too long for its element. Then the receiver must be reachable as a true e-invoice (receiver-not-einvoice): receivers only reachable on paper, by email, or through the consumer bank channels (e-lasku, suoramaksu, Netposti) are rejected up front, with the channel the operator would have used named in the error, rather than quietly delivered another way.
The one you name. Set the operator ID the receiver gave you in the customer’s fi-finvoice-operator extension, and the invoice is routed to that operator. Without it, the sending operator picks by its own preference, which may be the receiver’s old operator. The value is the operator’s OVT code (Apix Messaging is 003723327487) or a bank’s BIC, as listed beside the address at verkkolaskuosoite.fi. An operator the address is not registered with is not rejected, so check the pair rather than expecting an error.
If the connection to the operator fails after the request may have already been written, we can’t tell whether the invoice was accepted, and resubmitting could deliver it twice. The job reports the attempt with its timestamp under the send-unconfirmed code instead of retrying. Check with support before sending the invoice again.
Business-to-government is the segment where e-invoicing is mandatory in Finland, and the state applies its own reference conventions: order numbers must start with V1, agreement numbers with VSK1, and posting references with TK1, with at most one of each per invoice. Set the order number in ordering.purchases and the agreement number in ordering.contracts on the GOBL invoice. Invopop doesn’t validate or normalise these prefixes, so format them exactly as the contracting authority provided them, or the state will reject the invoice.
The operator’s synchronous accept is the final programmatic signal: there is no delivery status API to poll afterwards. If a receiving operator later rejects the invoice, that rejection arrives by email in production. No news after acceptance is good news.
More available in our Finland FAQ section

Participate in our community

Ask and answer questions about invoicing in Finland →