Finland E-Invoicing Requirements: Finvoice, TEAPPSXML, Peppol

Finland e-invoicing requirements are mandatory for parts of the public sector, but Finland does not impose a universal B2B e-invoicing mandate. The key distinction is this: public buyers must be able to receive EN 16931-compliant structured e-invoices, while private-sector companies with annual turnover above EUR 10,000 can request e-invoices from their suppliers under Act 241/2019. In practice, that means many Finnish invoice flows now depend on structured formats such as Finvoice, TEAPPSXML, or Peppol-compatible invoices sent through operator networks rather than PDF attachments sent by email.

For finance teams, that boundary matters more than the headline. If you sell to a Finnish public-sector customer, the question is usually not whether a PDF is acceptable, but which structured route and format the buyer will accept. If you sell to a private company, the workflow depends on what the customer is entitled to request and how its AP process is set up. The European Commission overview of Finland's e-invoicing rules summarizes the core legal position: public-sector e-invoicing is mandatory, and companies above the EUR 10,000 turnover threshold may require suppliers to send e-invoices.

Act 241/2019 is therefore best understood as a rule that sharpened invoice-processing expectations instead of turning every Finnish business invoice into a mandatory B2B e-invoice. It created a clearer right-to-request framework for private-sector companies and reinforced the public-sector shift toward structured, machine-processable invoicing. Public procurement thresholds also matter because they help define when the public-buyer obligations attach to the invoicing relationship you are dealing with. For a close regional comparison, Estonia's buyer-requested e-invoice regime follows a similar logic of strengthening the buyer side without imposing a universal B2B mandate. The practical question is not just "Is Finland mandatory?" but "Which buyer am I invoicing, what are they entitled to demand, and through which structured path do they actually receive invoices?" That is the lens this Finland e-invoicing guide uses.

What Counts as a Compliant Structured E-Invoice in Finland

In Finland, a true e-invoice is a structured, machine-readable invoice, not a PDF that happens to be delivered electronically. That distinction matters because a PDF still requires visual reading or separate data capture, while a structured invoice is designed so AP systems can validate, route, and post the data directly. If a buyer asks for e-invoicing, the supplier needs to confirm the invoice can be received in the format and network the buyer supports, not simply send a prettier attachment.

EN 16931 is the main compliance reference point for public-sector invoicing because it defines the European semantic standard for electronic invoices. In practice, Finland implements that requirement through commonly used formats and exchange networks rather than through one single domestic file type. A receiving organization may accept Finvoice 3.0, TEAPPSXML 3.0, or Peppol BIS Billing 3.0, provided the setup matches its operator or network path and satisfies the buyer's requirements. That is why Finland EN 16931 invoice requirements matter operationally: they shape what the buyer must be able to receive, while local exchange arrangements determine what the supplier should send.

For AP and implementation teams, the practical test is straightforward. Before treating an invoice flow as compliant, confirm that the invoice is structured, that the buyer's receiving setup matches the format you plan to use, and that you are not relying on email PDFs as a substitute for e-invoicing. If you are comparing Finland with another EU rollout that also combines EN 16931 with Peppol-led exchange, Ireland's EN 16931 and Peppol rollout roadmap is a useful point of contrast.

When to Use Finvoice, TEAPPSXML, or Peppol

The most useful way to compare Finland's main formats is to ask who needs to receive the invoice and through which network. Finvoice and TEAPPSXML are both established in Finnish e-invoicing, especially through domestic operator and banking channels, while Peppol becomes relevant when the buyer's receiving setup, procurement workflow, or cross-border connection points to Peppol as the preferred route. The format decision is usually driven by receiver capability, not by what the supplier happens to like using.

In practice, the comparison looks like this:

• Finvoice is widely associated with Finnish bank-led and operator-based invoice exchange and is familiar in many domestic finance workflows.
• TEAPPSXML is another structured Finnish invoice format that may be required by particular operators or receiving systems, so the sender needs to match the recipient's capability rather than assume Finvoice is always enough.
• Peppol is the format and network path to expect when the buyer has aligned its procurement or accounts payable process with Peppol exchange, especially where interoperability beyond one domestic operator relationship is important.

That is the real Finvoice vs TEAPPSXML question: not which standard is abstractly better, but which one your buyer can receive and process without manual intervention. Peppol adds a third path that can simplify interoperability in some cases, but it does not replace the need to check what the Finnish customer actually requires. Teams that want a comparative example of how mandate scope and Peppol adoption can vary by country can look at Australia's Peppol-based e-invoicing setup and mandate scope.

When you collect supplier onboarding requirements, ask for three things up front: the accepted invoice format, the required routing path, and the recipient identifier that makes delivery work. That turns format selection from a compliance guess into a repeatable operating procedure.

How Finnish E-Invoices Are Routed Through Operators and Registries

Creating a compliant file is only half of the job. Finnish e-invoicing also depends on getting that file to the right endpoint through the right exchange path. This is where the four-corner model becomes useful. In plain English, the supplier and buyer each use their own access point, bank, or service provider, and those intermediaries route the invoice between them. That is why the Finnish system is often described as an operator network rather than a direct email workflow.

The Finland e-invoice address registry is the lookup layer that helps participants identify where an invoice should be delivered and which identifiers the receiver uses. If the sender has the wrong address, operator ID, or network endpoint, a valid invoice can still fail operationally because it never reaches the buyer's AP system in the expected way. For implementation teams, this is one of the most important operational details in the entire process.

That is also why routing should be treated as part of compliance, not as a separate IT afterthought. A finance team can spend weeks mapping invoice fields correctly and still run into rejection or delay if the operator setup is incomplete or the registry details are outdated. The better workflow is to validate content format and routing details together: which structured format the buyer accepts, which operator or network it uses, and which address information the sender must use for successful delivery. If you want a contrasting model where the platform record supports VAT deduction but does not replace the source invoice set, this Belarus ESChF portal and source-document workflow guide shows how another market separates the tax-layer record from the underlying commercial documents.

What Foreign Suppliers and State Vendors Need to Know

Foreign suppliers often run into Finland's public-sector rules first, because government buyers usually have firmer receiving requirements than private companies. The first step is to get the customer's exact invoicing instructions, including the accepted format, routing method, and recipient identifiers. A Finnish public buyer may be able to receive through an operator, through Peppol, or through a specified supplier service, but the common thread is that a PDF email attachment is generally not treated as the required structured e-invoice.

For suppliers invoicing the Finnish state, the operational context matters. The State Treasury publishes invoicing requirements, and Palkeet plays a central role in shared state financial administration. Buyers may also refer suppliers to the Handi service or related onboarding instructions, depending on how procurement and invoice handling are organized. The practical takeaway is that public-sector invoicing in Finland is not just a legal requirement on paper. It is a defined receiving workflow, and suppliers need to follow the receiving authority's path rather than improvise one.

This is where fallback options become important for foreign companies that do not maintain their own full Finnish e-invoicing connection. Basware Supplier Portal can provide an achievable route for suppliers that need to submit compliant invoices without building a full operator setup from scratch. That does not remove the need to confirm the customer's instructions, but it can make Finland e-invoicing for foreign companies much more manageable. For a narrower EU public-sector example, Luxembourg's public-sector Peppol and MyGuichet workflow shows how another buyer-side setup combines Peppol with a government portal fallback for occasional or foreign suppliers. The safest operating pattern is to verify format, network, and supplier-access method before the first invoice is issued, not after an invoice is rejected.

A Practical Checklist for Sending or Receiving Finnish E-Invoices

If you need a working process rather than another standards summary, use this checklist:

1. Confirm whether the invoice flow is public-sector or private-sector, because Finland does not apply one universal B2B rule to every invoice.
2. Check whether the buyer is entitled to request e-invoices under the Act 241/2019 framework and whether public procurement rules put the invoice inside the public-sector regime.
3. Verify that the invoice will be sent as a structured e-invoice, not as a PDF attachment presented as e-invoicing.
4. Match the buyer's accepted format before go-live, whether that means Finvoice, TEAPPSXML, or a Peppol-compatible route.
5. Validate routing details, including operator information, recipient identifiers, and the Finland e-invoice address registry entry where relevant.
6. If the supplier is outside Finland or lacks a direct network setup, confirm whether a portal-based path such as Basware Supplier Portal is acceptable.
7. Assign internal ownership for supplier onboarding, format testing, rejection handling, and AP exception management so invoice issues are resolved before payment delays accumulate.

That checklist works for both sending and receiving teams because it separates legal scope, data format, and routing mechanics instead of collapsing them into one vague compliance task. If your Finnish workflow also touches domestic invoice-specific rules, Finland's reverse-charge invoice rules for construction work and this guide to Finland invoice reference numbers are useful adjacent references when reviewing supplier requirements and invoice controls.