Jurisdiction-neutral primitives for EU-distribution SaaS

---

title: "Jurisdiction-neutral primitives for EU-distribution SaaS" date: "2026-02" kicker: "Architecture" summary: "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." status: "Published" readTime: "7 min"

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

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 adapter for USt

Not a new idea in computer science

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: speed

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.

Why incumbents cannot do this

The incumbents cannot make this move because it would require rewriting the foundation of their product. Their competitive advantage is deep jurisdictional knowledge. Abstraction would mean discarding that advantage in favour of a platform play — and platform plays take years to pay off.

For a new entrant, there is nothing to discard. You start abstract. You start EU-native. The jurisdiction-specific knowledge becomes a data layer, not a code layer.

The architecture in practice

In Vantnod, the core domain models are deliberately minimal:

1. Transaction — amount, currency, date, counterparty, reference
2. Account — type, currency, balance
3. Reconciliation — transaction-to-bank-line mapping
4. Report template — jurisdiction-agnostic structure

The Finnish adapter adds ALV codes, Oy entity rules, and STEA reporting formats on top. The Estonian adapter adds KM codes and Äriregister integration. The German adapter adds USt codes and GoBD compliance.

The core stays small. The adapters grow. The product scales.