Jurisdiction-neutral primitives for EU-distribution SaaS
Why the Finnish Procountor / Fennoa / Talenom moat is a jurisdictional one, and why pulling VAT, bookkeeping, and entity kind out of your core domain is the only way to move at EU speed.
Finnish accounting software is good at being Finnish. Procountor, Fennoa, Talenom, Heeros — they know the Finnish ALV codes, the Oy-specific ledger structure, the STEA reporting formats. That is their strength and their prison. When you try to enter Estonia or Germany with the same stack, you discover that 40% of your codebase is Finnish tax law dressed up as business logic.
The insight behind Vantnod was to pull jurisdiction out of the core domain entirely. Instead of a Finnish accounting app that happens to work elsewhere, we built jurisdiction-neutral primitives: transactions, accounts, reconciliations, reporting templates. Each primitive is pure — it knows nothing about Finnish ALV or Estonian KM. Then we layer jurisdiction-specific adapters on top: a Finnish adapter that maps the neutral transaction to ALV codes, an Estonian adapter that maps to KM, a German one for USt.
This is not a new idea in computer science. It is the exact same principle that lets PostgreSQL run on any operating system: abstract the storage engine, plug in the OS-specific file handler. But in fintech, almost nobody does it, because the incumbent players grew up inside one jurisdiction and never had a reason to abstract.
The business consequence is speed. When we launch in Estonia, we do not fork the codebase. We write an Estonian adapter — roughly 3,000 lines of mapping and validation — and the core product stays identical. The same UI, the same LLM pipeline, the same bank reconciliation engine. Only the tax output changes. That is how you move at EU speed: one product, many jurisdictions, zero forks.
Want to discuss this? Write directly.
jami@impactnode.fi