> ## Documentation Index
> Fetch the complete documentation index at: https://invopop-dk.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Finland FAQ

> Frequently asked questions about invoicing compliance in Finland

### Compliance questions

**Finland**

<AccordionGroup>
  <Accordion title="Is e-invoicing mandatory in 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.
  </Accordion>

  <Accordion title="What is Finland's B2B 'right to request' e-invoicing?">
    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.
  </Accordion>

  <Accordion title="What VAT rates apply in Finland?">
    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.
  </Accordion>

  <Accordion title="How long must invoices be archived in Finland?">
    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.
  </Accordion>
</AccordionGroup>

**Finvoice**

<AccordionGroup>
  <Accordion title="What is 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.
  </Accordion>

  <Accordion title="Do I need to choose between the domestic network and Peppol?">
    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.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="Is sending invoices via Peppol mandatory?">
    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.
  </Accordion>

  <Accordion title="Does a Peppol invoice need to be EN16931 compliant?">
    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.
  </Accordion>

  <Accordion title="Why does Peppol require proof of ownership?">
    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.
  </Accordion>

  <Accordion title="What documents count as proof of ownership?">
    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.
  </Accordion>

  <Accordion title="Are received Peppol invoices considered legally valid?">
    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.
  </Accordion>

  <Accordion title="How long must I retain received Peppol invoices?">
    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.
  </Accordion>
</AccordionGroup>

### Invoicing questions

**Finland**

<AccordionGroup>
  <Accordion title="Can I invoice a Finnish business that isn't reachable on Peppol?">
    Yes. Most Finnish businesses receive e-invoices through the domestic operator network rather than Peppol, and the [Finland app](/apps/finland) 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.
  </Accordion>
</AccordionGroup>

**Finvoice**

<AccordionGroup>
  <Accordion title="Why does every Finnish invoice need bank account details?">
    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](https://docs.gobl.org/addons/fi-finvoice-v3) rejects it up front instead.
  </Accordion>

  <Accordion title="Why was my invoice refused before it was sent anywhere?">
    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.
  </Accordion>

  <Accordion title="What does a submission with an unknown outcome mean?">
    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.
  </Accordion>

  <Accordion title="How do I invoice the Finnish state?">
    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.
  </Accordion>

  <Accordion title="What happens after the invoice is accepted?">
    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.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="What should we do if the customer doesn't belong to the Peppol network?">
    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
  </Accordion>

  <Accordion title="How do I handle B2C invoices in Peppol?">
    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.
  </Accordion>

  <Accordion title="How do I handle 'Receiver Not Found' errors?">
    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.
  </Accordion>

  <Accordion title="Should I set the `$regime` field when using Peppol?">
    No. The regime is automatically derived from the supplier's settings, which is the recommended approach for Peppol — leave it unset on the document.
  </Accordion>

  <Accordion title="Where do I find Peppol GOBL documentation?">
    See the [`eu-en16931-v2017`](https://docs.gobl.org/addons/eu-en16931-v2017) addon for the field and validation rules Peppol BIS Billing 3.0 builds on, and the [Peppol app reference](/apps/peppol) for supported document types and Participant ID schemes.
  </Accordion>
</AccordionGroup>

### Supplier questions

**Finland**

<AccordionGroup>
  <Accordion title="How do I register a Finnish supplier?">
    Upload the supplier as a GOBL party with `tax_id.country = FI` and the Business ID (y-tunnus), then run the [Finland app](/apps/finland)'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](/guides/fi-finvoice-supplier).
  </Accordion>

  <Accordion title="What Peppol scheme does Finland use for participant IDs?">
    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.
  </Accordion>
</AccordionGroup>

**Finvoice**

<AccordionGroup>
  <Accordion title="What is a Finnish e-invoice address?">
    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](https://verkkolaskuosoite.fi): since 2024 it mirrors the Peppol address list too, so one lookup covers both networks.
  </Accordion>

  <Accordion title="Which address form should I put on a party record?">
    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.
  </Accordion>

  <Accordion title="Why hasn't my party's registration completed yet?">
    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.
  </Accordion>

  <Accordion title="Can I register several Finnish parties in one workspace?">
    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.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="How do I register for a Peppol inbox in Invopop?">
    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.
  </Accordion>

  <Accordion title="I get 'XXXX:XXXXXXXXX is already registered' when registering a supplier — what now?">
    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`).
  </Accordion>

  <Accordion title="How do I assign multiple inboxes to a single supplier?">
    Register them through different silo entries, even though they represent the same legal party. The supplier must upload proof of ownership for each inbox.
  </Accordion>

  <Accordion title="What are Participant IDs?">
    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.
  </Accordion>

  <Accordion title="What visibility level should I set on my Peppol Party?">
    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.
  </Accordion>
</AccordionGroup>

### Receiving questions

**Finvoice**

<AccordionGroup>
  <Accordion title="How quickly do received invoices appear?">
    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.
  </Accordion>

  <Accordion title="What format do received invoices arrive in?">
    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.
  </Accordion>

  <Accordion title="What setup does receiving need?">
    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.
  </Accordion>
</AccordionGroup>

**Peppol**

<AccordionGroup>
  <Accordion title="How do I import received invoices via 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.
  </Accordion>

  <Accordion title="Can I remove UBL or CII from the 'Peppol receive invoice' workflow if I only use one format?">
    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.
  </Accordion>

  <Accordion title="How are incoming Peppol documents converted into GOBL?">
    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.
  </Accordion>
</AccordionGroup>

***

<Card title="Participate in our community" icon="forumbee" href="https://community.invopop.com" arrow="true" horizontal>
  Ask and answer questions about Finland's regulation →
</Card>