What e-invoicing in Finland actually is
An e-invoice is an invoice created and received in a structured electronic format that follows the European standard EN 16931. Structured means a machine reads every field without a human retyping anything: the amounts, the VAT, the reference numbers, the buyer, the seller.
It travels through an invoicing network rather than by email, from your operator to your customer's operator, the way a bank transfer moves between banks. Neither side needs to know what software the other uses.
The rules come from the act on electronic invoicing by contracting entities and traders, number 241/2019, which applied to central government first and was extended to other contracting entities and to traders on the first of April 2020.
When your customer can demand an e-invoice
Any contracting entity or trader can require an invoice from another contracting entity or trader in the electronic form the act defines, and the recipient can require that it complies with the European standard. That covers the public sector and ordinary business to business selling.
In practice the demand arrives from three directions. A municipality or a state agency you have just won work with, a large private customer whose purchase ledger is automated, and an accounting firm taking over a client's books.
Consumers are a separate story and no such right applies to them. What a consumer gets is whatever you send, which for most small companies is still an email with a PDF.
A PDF by email is not an e-invoice
This is the misunderstanding that costs the most time. A PDF is a picture of an invoice, and a person has to read it and type the figures into a system. The State Treasury says it plainly: the state does not receive invoices attached to an email, because that is not an electronic invoice.
Scanning services exist and turn a PDF into structured data with an error rate, which is why large buyers stopped paying for them. If your invoice needs a human at the other end, it goes to the bottom of the pile.
The same applies to an invoice generated by your web shop and emailed as an attachment. It looks modern and it is still a picture.
What you need to send them
Three things, and you probably have one of them already.
An invoicing system that can output the structured format, which today means almost any Finnish accounting or invoicing software. An operator or service provider that moves the invoice onto the network, which is usually sold as part of the same software or as a bolt-on. And your own e-invoice address, which is the identifier the network routes to.
The customer gives you their e-invoice address and operator identifier, usually at the bottom of their order or on their website. Finnish addresses are published in the verkkolaskuosoite.fi directory, so you can look up a buyer rather than emailing to ask.
Your e-invoice address, explained once
The e-invoice address is a routing code, in the same spirit as an IBAN. It is often built from the business ID, and it is paired with an operator identifier so the network knows which service provider holds your mailbox.
Publish yours where suppliers will find it: on your contact page, in the footer if you receive a lot of invoices, and in the directory. A supplier who cannot find it sends a PDF, and then somebody on your side types it in.
If you change operator, the address usually follows you. Tell your regular suppliers anyway, because some of them keep it in a spreadsheet that nobody updates.
The European standard, briefly
EN 16931 defines which fields an invoice has to carry and what they mean, so an invoice written in Finland can be read by a system in Portugal. Finnish practice implements it through the national formats and through Peppol.
What it means for you as a seller is that some fields your customer needs are mandatory. Seller and buyer VAT identifiers and business IDs, names and addresses, the product or service name with the price before tax, and the correct tax code.
What it means when you receive is better. The data arrives clean, so the accounting software can match it against an order without anyone reading it.
Invoicing the Finnish state
The state takes e-invoices only, and it is worth knowing the detail before your first public sector order. Invoices have to meet EN 16931 and carry the reference the buyer gave you, whether that is an order number, an agreement number or a posting reference.
The State Treasury reports that 98 per cent of invoices sent to the state are electronic, while 73 per cent meet the European standard. So the common failure now is a badly formed e-invoice rather than a paper one, and a badly formed invoice comes back.
Routes in include the supplier portals the state offers and the Peppol network. A small supplier with two invoices a year can use a portal and type them by hand.
Operators and Peppol
An operator is the postal service of this system. You have one, your customer has one, and they exchange invoices between them under agreed rules. Peppol is the European network that connects operators across borders and is how a Finnish company invoices a Norwegian or Dutch buyer without a local arrangement.
Choosing an operator is mostly about what your accounting software already supports. Fighting the integration to save a small monthly fee is a bad trade for a company sending a few dozen invoices a month.
Ask one question before signing: can we receive as well as send, and at what volume does the price change.
Connecting your shop or CRM
Connect the systems in one direction and one direction only, from the place where the sale is agreed to the place where the invoice is created. Two systems both allowed to create invoices produce duplicates, and duplicates in a customer's purchase ledger are how a good supplier relationship gets tense.
For a web shop the usual chain is order, then order data into the invoicing system through its interface, then the e-invoice out through the operator. Consumer orders paid by card at the checkout normally need a receipt rather than an invoice, so the e-invoice path exists for the business customers who order on account.
For a CRM that holds the customer and the agreement, the useful connection is the other way as well. Knowing inside the CRM that an invoice was sent, and whether it was paid, saves the weekly conversation with accounting.
What the integration usually involves
Mapping fields, deciding who owns the customer record, and handling the failures. The mapping is dull and quick. The ownership question decides whether the customer's address gets fixed in one place or in three.
Failures are where the work is. An invoice the network rejects has to appear somewhere a human will look, with the reason, rather than disappearing into a log file. A rejected invoice nobody noticed is an unpaid invoice with a long silence in front of it.
Where standard software cannot be bent to fit the way you actually sell, a small custom tool that sits between the two systems is usually cheaper than changing either of them.
Receiving is as valuable as sending
Most of the savings arrive on the inbound side. Supplier invoices that arrive structured can be matched against purchase orders automatically, routed for approval, and posted without retyping, which removes the slowest manual job in a small finance function.
It also removes a class of fraud. An emailed PDF with altered bank details is a familiar scam in Finland, and a structured invoice arriving through the network from a known sender is much harder to fake.
If you do one thing this quarter, publish your e-invoice address and ask your ten biggest suppliers to use it.
What it costs
The cost sits in three places, and no honest article can give you a single figure because it depends on all three.
The invoicing software itself, which you probably already pay for. The operator, usually a monthly fee plus a price per invoice sent and sometimes received, and the per invoice price falls with volume. And the integration work, which is a one-off and depends entirely on whether your systems already speak to each other.
The comparison worth making is against what you pay today. Count the minutes somebody spends creating, emailing, chasing and retyping invoices each month, and put a wage on it. For most small companies that number is larger than the operator's bill, which is the actual argument for doing it.
The mistakes we see
Sending a PDF and calling it an e-invoice. Getting the customer's reference wrong, which sends a technically valid invoice straight back. Setting up sending and forgetting receiving. Letting two systems both create invoices. And leaving the e-invoice address off your own contact page, so suppliers keep emailing.
There is a sixth that only shows up later. Nobody checks the rejection queue, because when it was set up there were no rejections in it.
Put a person's name against that queue on day one.
Where to start if you have none of this
Start with the customers who have asked, since they are the reason the question came up. Ask your accounting software provider what it supports and what the operator costs, because in most cases the answer is that the capability is already in the licence and nobody switched it on.
Then publish your e-invoice address, then connect the shop or the CRM you use to track customers, in that order. The publishing costs nothing and starts the inbound saving immediately.
Leave the full automation for later. A company sending forty invoices a month does not need an integrated pipeline on the first day, and it does need to stop losing public sector orders over a file format.