Skip to main content

​
Compliance questions

Finland
B2G e-invoicing has been mandatory since 1 April 2019 for central government and since 1 April 2020 for all contracting authorities, under Act 241/2019 (implementing EU Directive 2014/55/EU). Since 1 April 2021, public bodies may only accept invoices compliant with EN 16931. B2B e-invoicing remains voluntary. Businesses above the EUR 10,000 turnover threshold have a statutory right to request e-invoices from suppliers, but there is no blanket transmission mandate. There is no B2C mandate.
Businesses with an annual turnover exceeding EUR 10,000 can compel their suppliers to issue e-invoices instead of paper or PDF. It’s a statutory right rather than a default obligation to transmit electronically, and it is one of the reasons Finland has a comparatively high voluntary e-invoicing adoption rate without a blanket mandate.
Standard rate 25.5%, reduced rate 13.5% (food, restaurants, books, transport, accommodation, cultural events, from 2026), and super-reduced rate 10% (newspapers and magazines). Exports outside the EU and intra-EU supplies to VAT-registered buyers are zero-rated.
Under the Kirjanpitolaki (Finnish Accounting Act, 1336/1997), vouchers — invoices included — must be retained for 6 years from the end of the calendar year in which the financial year closed (in practice “6+1”), and financial statements for 10 years, with authenticity, integrity, and readability preserved throughout. Confirm any sector-specific extensions with local counsel before relying on them for edge cases.
Finvoice
Finvoice is the Finnish XML e-invoicing format, published by Finance Finland (Finanssiala), the banking association. Version 3.0 is conformant with the European standard EN 16931, and it is the dominant format on Finland’s domestic operator network. You don’t produce Finvoice documents yourself: send a GOBL invoice, and it is delivered in the format the receiver’s network expects.
No. Finland runs two e-invoicing networks side by side: the domestic operator network, where around 370,000 companies receive their invoices, and Peppol, with roughly 13,000 end users (about 0.24% of annual volume). The Finland app covers receivers on either network: you send one GOBL invoice with the receiver’s e-invoice address, and the routing is resolved for you.
Peppol
Mandatory dates vary by country. Belgium requires structured B2B e-invoicing — Peppol BIS by default — from January 2026. Germany is phasing in B2B e-invoicing between 2025 and 2028. France’s Factur-X via Peppol applies once the PA reform takes effect. Outside mandates, Peppol delivery is voluntary but increasingly expected for B2G and cross-border trade.
Yes. Every document exchanged on Peppol BIS uses a UBL or CII syntax that conforms to the EN16931 European e-invoicing standard, plus the relevant Peppol BIS specification. Invopop generates compliant XML automatically when you use the Peppol app.
Peppol is a federated network — anyone could otherwise register a Participant ID for a company they don’t represent. Proof of ownership ties the Participant ID to a verifiable contact at the company, which is what allows the registration to be published on the SML.
Requirements vary by Authority. In Belgium, for example, the supplier must provide a recent extract from the Banque-Carrefour des Entreprises (KBO/BCE) plus a signed mandate. Invopop walks the registering party through the local requirements during the registration wizard.
Yes — a Peppol BIS document delivered through a certified Access Point is treated as the legal e-invoice in any country that recognises Peppol. The signed UBL or CII XML is the authoritative record; archive it alongside any human-readable rendering you generate.
Retention is set by each country’s tax authority — typically 7 to 10 years in the EU. Invopop preserves the original XML and any generated PDF in the silo entry so you can satisfy local archival requirements wherever you operate.

​
Invoicing questions

Finland
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.
Finvoice
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.
Peppol
In countries where Peppol is the standard but not mandatory, you may still need to issue an e-invoice when the recipient isn’t on the network. Both parties can agree on an alternative transfer method, but the invoice must still be EN16931 compliant.Recommended approach:
  • Set up a separate workflow that generates the XML without the send-Peppol-document step
  • Or reuse your existing workflow without the customer Peppol ID — the send step is automatically skipped
  • Fetch the generated XML and deliver it through the agreed channel, typically email
B2C invoices typically lack the structured customer information required for Peppol delivery, and most consumers don’t have inboxes. Use a conditional workflow:
  1. Add an If/Else step that checks for a customer inbox using count(customer.inboxes, true) > 0.
  2. On the false branch, generate a PDF and email it to the customer, then stop the flow.
This routes B2B invoices through Peppol while keeping a smooth path for consumers.
If a job fails with KO and receiver not found in the peppol network, treat it like an invalid email address — the recipient simply isn’t reachable on Peppol. Add the Lookup Participant ID step (ideally in a separate validation workflow run against customer data) so you catch missing IDs before generating the invoice.
No. The regime is automatically derived from the supplier’s settings, which is the recommended approach for Peppol — leave it unset on the document.
See the eu-en16931-v2017 addon for the field and validation rules Peppol BIS Billing 3.0 builds on, and the Peppol app reference for supported document types and Participant ID schemes.

​
Supplier questions

Finland
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.
Finvoice
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.
Peppol
Upload the company as a party (Console → Parties → Suppliers → + New Supplier, or via the Create an Entry API) with name, tax_id, address, and email. Then run it through the party registration workflow — the contact will receive a registration wizard link to provide proof of ownership.Once approved, the party is registered on the Peppol network (SMP+SML+Peppol visibility by default with the ubl-invoice doc group) and ready to receive invoices.
A supplier with that Participant ID already exists in your workspace. Either reuse the existing party or, if it really is a new entity, check whether it should be registered under an alternative scheme (for example Belgium’s 9925 VAT scheme rather than the default 0208).
Register them through different silo entries, even though they represent the same legal party. The supplier must upload proof of ownership for each inbox.
Unique identifiers for entities on the Peppol network, made up of two parts:
  • Scheme — identifies the type of identifier (e.g. 9920 for Spanish VAT, 0208 for Belgian KBO/BCE)
  • Code — the actual identification number
Participant IDs are usually based on VAT numbers or local business identifiers, and Invopop can derive them automatically from a Tax ID. Some countries support multiple schemes — Belgium, for example, defaults to 0208 but some entities are only registered under 9925 (VAT). If you hit a “receiver not found” error, the recipient may be registered under an alternative scheme.
Peppol Party visibility determines what you can send and receive:
  • smp — SMP only, for testing
  • smp+sml — SMP and SML, useful when you only want to send
  • smp+sml+peppol — SMP, SML, and the Peppol Directory, recommended for both sending and receiving (and for being discoverable in the Directory)
In general, use the highest visibility available.

​
Receiving questions

Finvoice
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.
Peppol
Register the recipient as a Peppol participant with Invopop as their Access Point. Incoming documents are routed through your configured Import workflow, which converts the UBL or CII payload to GOBL and stores the entry in the Expenses folder.
Yes. Either format can be removed based on your needs. The default template includes both for comprehensiveness, but if you’re certain you’ll only receive invoices in one syntax, dropping the other simplifies the workflow and reduces the apps you need to activate.
The Import workflow’s UBL and CII parser steps map the inbound XML into a GOBL invoice. From there you can route it to webhooks, Google Drive, accounting integrations, or any other destination — the GOBL representation is the single source of truth for downstream processing.

Participate in our community

Ask and answer questions about Finland’s regulation →