Skip to main content

​
Introduction

Finnish businesses receive their e-invoices over two networks: the domestic operator network, where around 370,000 companies get theirs as Finvoice (or TEAPPSXML, depending on their operator), and Peppol, with roughly 13,000 end users. The Finland app covers both, delivering through the accredited Finnish operator Invopop has partnered with, in the format the receiver’s network expects. You never pick a network. Send one GOBL invoice carrying the receiver’s e-invoice address and the routing is resolved for you. Use this app for every Finnish receiver, including the ones reachable on Peppol. 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 inbox with scheme 0216 and the OVT code (0037 plus the Business ID without its hyphen). 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 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.

​
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 checks the receiver is reachable, generates the e-invoice, 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

Three checks run before anything leaves the platform, each failing the job with its own code:
  • supplier-address-missing: the supplier has no electronic address. Add the OVT inbox to the supplier party.
  • payment-account-missing: the invoice carries no payment bank account. Add the payment block described above.
  • 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 carry their e-invoice address as an inbox with scheme 0216 and an OVT code (0037 followed by the Business ID without its hyphen),
  • 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 rather than Peppol, and the Finland app reaches both: you send one GOBL invoice with the receiver’s e-invoice address, and it is delivered in the format the receiver’s network expects. There is no need to check which network the receiver is on.
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.
Three checks run before anything leaves the platform: the supplier must have an electronic address (supplier-address-missing), the invoice must carry a payment bank account (payment-account-missing), and the receiver must be reachable as a true e-invoice (receiver-not-einvoice). The last one matters most: 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.
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 →