Skip to main content

Register suppliers

Supplier registration guide ›

Issue invoices

Issuing guide ›

Receive invoices

Receiving guide ›
Finland has no government clearance system for invoices. Instead, e-invoices travel over two networks that run side by side: the domestic operator network, an unbranded mesh of accredited operators where around 370,000 companies receive their invoices as Finvoice or TEAPPSXML, and Peppol, with roughly 13,000 Finnish end users (about 0.24% of annual volume). Neither network alone covers Finnish receivers.Invopop has partnered with Apix Messaging, an accredited Finnish operator, to cover both networks through one app: you send one GOBL invoice carrying the receiver’s e-invoice address, and it is delivered as a compliant e-invoice in the format the receiver’s network expects.Because the routing is resolved per receiver, you never pick a network. Use this app for every Finnish receiver, including the ones reachable on Peppol. Before anything is sent, the app checks how the receiver would be reached and refuses the invoice unless the answer is a networked e-invoice, naming the channel that would have been used instead.E-invoicing is mandatory for invoices to Finnish public bodies under Act 241/2019, and voluntary between businesses, though businesses above a EUR 10,000 turnover threshold have a statutory right to request e-invoices from their suppliers.

​
Key features

  • Workflow automation: Register parties, issue invoices, and import received ones as steps in your workflows.
  • Both networks through one app: Domestic-network and Peppol receivers are reached through the same action, with routing resolved per receiver.
  • Per-party provisioning: Each registered party gets its own operator account and its own e-invoice address.
  • Finvoice-safe validation: The fi-finvoice-v3 addon requires the payment data Finvoice makes mandatory, so invoices that would fail conversion are rejected before they are sent.
  • Reachability pre-check: Receivers that would get paper, email, or a consumer bank channel are refused up front, never silently delivered another way.
  • Invoice reception: Each registered party’s inbox is polled on a schedule and received invoices are imported automatically.
Check out the guides below to get started:

​
FAQ

Invoicing questions
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.
Registering supplier questions
Upload the supplier as a GOBL party with tax_id.country = FI and the Business ID (y-tunnus), then run the Finland app’s registration workflow. Registration provisions the party its own operator account and allocates its e-invoice address — a party must be registered before it can send or receive anything. See the supplier registration guide.
Scheme 0216, wrapping the party’s OVT code — 0037 followed by the Business ID without its hyphen. Under Finland’s Peppol Authority Specific Requirements, the OVT code is the mandatory participant identifier for Finnish organisations on Peppol. The 0037 at the start of the code itself is a country prefix, not the scheme.
An OVT code: 0037 followed by the party’s Business ID (y-tunnus) without its hyphen, sometimes with a five-character suffix for routing inside large organisations (for example 003726174164). On Peppol, the same code is wrapped in scheme 0216 (0216:003726174164). You can look any counterparty up in the national registry at verkkolaskuosoite.fi: since 2024 it mirrors the Peppol address list too, so one lookup covers both networks.
The OVT code, as an inbox with scheme 0216. Other forms circulate on the Finnish network (IBAN-style addresses from the older bank channel, operator-prefixed ones such as TE0037…), but the OVT code is the canonical form, and it’s what the routing pre-check and the generated e-invoice use.
Registration provisions the party its own account with the operator, and it only completes once every service is in force and the party’s e-invoice address has been allocated on the operator’s side. Until then the registration job stays queued rather than reporting success on an account that can’t yet receive.
Yes. Each party gets its own operator account, its own e-invoice address, and its own reception polling schedule. Register each one separately by running the registration workflow on its party record.
Receiving questions
Reception is polled, not pushed: each registered party’s inbox at the operator is swept on a schedule, every five minutes by default. Add the time the sender’s own operator takes to deliver, and an invoice normally appears within minutes, but not instantly. If you’re testing, allow up to a quarter of an hour before suspecting a problem.
Each received document becomes one entry in your workspace carrying the GOBL invoice, the original XML as received from the network, and a PDF rendering, whatever format the sender issued.
Two things: the Finland app must be configured with a sync workflow and an import workflow, and the party must be registered. Registration checks the workflow configuration first, so set the workflows up before running it. Once registered, polling starts automatically; received invoices simply appear as new entries processed by your import workflow.
More answers in our Finland FAQ section

Participate in our community

Ask and answer questions about the Finland app →