Holvi hands over a prepared booking, receipt attached.
Holvi is a business account for the self-employed, founders and small businesses in Finland and Germany, with cards, invoicing and a preparatory bookkeeping layer on top. Everything a booking needs is already in Holvi by the time a card payment is released. The accounting system on the other side is where it either arrives whole or arrives as a line somebody has to complete.
Who Holvi is, and which half is ours
- Website
- holvi.com
- About Holvi
- Founded in Helsinki in 2011, with two offices there and in Berlin, and 35.000+ small business owners on the account. Holvi is a payment institution authorised by the Finnish Financial Supervisory Authority for the European Economic Area, and a Mastercard Principal member issuing its own business card.
- Who it serves
- Sole traders, founders and small businesses across its two core markets, plus teams with company cards. Holvi publishes more than 1.000 customers who work with a tax advisor and run their expenses in the account.
- Use case
- Captured card spend arriving as a booking instead of a bank line. The workflow itself, independent of any one account, is on the expense synchronisation page, and the matching half on payment reconciliation.
- Accounting systems
- DATEV Unternehmen Online, DATEV Rechnungswesen, sevdesk and Lexware Office, the four Holvi names on its own site
- The bank side
- Holvi's own, and it stays that way. DATEV runs over EBICS, the other tools over the PSD2 API, and the Finnish market has nine published bank connections at a fixed monthly price. Those rails deliver the account statement, which is a different object than a booking.
A payment and its receipt arrive by different routes
Holvi already reached DATEV, sevdesk and Lexware Office over its own bank connections. The gap was never the connection, it was what a bank connection carries.
A card payment leaves two things behind: a line on the statement and a piece of paper. The line travels automatically. The receipt is photographed in the Holvi app, sits there with the VAT and the category somebody assigned to it, and then has to find its own way to the same accounting system. Holvi's own page names the old version of that plainly: exchanging paper receipts and statements by post. What comes after it is the tax office asking for whatever is missing, and Holvi names the currency for that too, in billable hours.
So the preparation is finished before accounting sees anything. What has to survive the trip is four things, and each meets a different width on the other side: the document is the narrowest, and the allocation is the one nothing on the other side will create at all.
- take the document itself
- 4of 30+take the document itself
- publish their tax rates
- 12of 30+publish their tax rates
- expose their chart of accounts
- 19of 30+expose their chart of accounts
- create a cost centre
- 0of 30+create a cost centre
Standard writes and reads across the 30+ connected systems. On request is how the documentation marks an object a system supports outside its standard set, and it covers 23 more for the document alone.
One connection, and each system gets its own form
The two forms a booking can take are not a detail on this route, they are what decides which object goes in. Holvi prepares one result, and the connection puts it in as a booking or as a proposal depending on what the system on the other side accepts.
It goes in as a booking where the system takes one and as a proposal where the system expects somebody to confirm it first. Those two are not interchangeable and not evenly available: ten of the 30+ connected systems take a proposal, ten take a journal entry, and only three take either, so together they reach seventeen. One data model is what makes both the same piece of work on Holvi's side, and error handling decides whether a release that fails halfway is visible or silent.
The rails deliver the account statement. The connection delivers the booking, and on four of the 30+ connected systems the receipt travels with it — both DATEV products among them.
Nothing has to be rebuilt after the fact
Holvi did not replace its bank connections. It added the one thing they do not carry, and it did so once rather than once per accounting product.
Holvi was already connected, and that is what makes the decision worth a look: DATEV, sevdesk and Lexware Office were reachable, the statement arrived daily, and by any reasonable reading the integration work was finished. What was missing was one object, and adding it per system across two countries is the arithmetic product and engineering teams weigh every time a second system appears. For the business holding the account, the change is that the receipt is attached where it was taken, the tax rate was set by the person who knew it, and the account was decided while the payment was still fresh — the shape other payment and spend products in B2B fintech run into as well.
Common questions
What runs on Maesn at Holvi?
Why is the bank connection not enough?
Booking or booking proposal, and who decides?
Does the receipt itself travel, or only its data?
Are cost centres created in the accounting system?
Could another business account do the same?
Reads the ledger through Maesn and keeps the bank side on its own connection, then writes the reconciled bookings back.Read the case study
Automates the full accounts payable cycle and posts every payment back into the customer's ERP.Read the case study
Turns tracked project time into draft invoices inside the accounting system the customer already runs.Read the case study