If your platform operates in one country, tax is manageable. Learn the rules, build the logic, update it once a year. Done.
If your platform operates in five countries, tax is painful. Five sets of rules, five sets of forms, five update cycles.
If your platform operates in thirty countries — which most marketplaces, gig platforms, and contractor management tools do — tax is a nightmare that most teams quietly decide not to touch.
This post explains what multi-jurisdiction tax compliance actually involves, why it breaks every "just build it" plan, and what the architecture of a solution looks like.
What "multi-jurisdiction" actually means
It's not just different tax rates. That's the easy part. It's everything underneath.
Different tax types. In Germany, a freelancer pays income tax (Einkommensteuer), solidarity surcharge (Solidaritätszuschlag), trade tax (Gewerbesteuer) if applicable, and VAT (Umsatzsteuer). In Malta, it's income tax, social security contributions (SSC), and VAT. In the US, it's federal income tax, self-employment tax, and state income tax (which varies by state — California is nothing like Texas). Each country has a different combination of taxes, each with its own rules.
Different classification rules. What counts as a deductible expense in one country doesn't in another. Germany allows a flat-rate home office deduction. The UK requires actual costs. Malta has specific capital allowance categories. The US has Section 179 expensing and bonus depreciation rules that changed in 2025.
Different forms and filing structures. Germany files the UStVA (monthly or quarterly VAT) and an annual Einkommensteuererklärung. The UK files a Self Assessment return. Malta files a TA24. Italy files the Liquidazione IVA Periodica quarterly and a Dichiarazione IVA annually. France has the CA3. Each form has its own line items, its own logic, its own submission format.
Different deadlines. Malta VAT returns are due by the 15th of the month following the quarter end. German UStVA is due by the 10th. UK Self Assessment is due by 31 January. US estimated tax payments are due quarterly on dates that don't align with the calendar quarter end. Miss a deadline and your user gets a penalty — and blames your platform.
Different authorities and submission methods. ELSTER in Germany. HMRC's Making Tax Digital in the UK. CFR online portal in Malta. IRS e-file in the US. Agenzia delle Entrate in Italy. Each has its own API, its own authentication, its own format requirements.
Different languages and currencies. A German VAT return is in German. A French CA3 is in French. The chart of accounts terminology differs. "Cost of goods sold" doesn't translate directly into every accounting framework.
Why "just build it" fails
Most engineering teams that attempt multi-jurisdiction tax follow the same path:
Phase 1: Confidence. "Tax is just rules. We'll codify them." The team picks one country — usually the home market — and builds a working prototype. It takes a few months. It works. The team is optimistic.
Phase 2: Reality. They start the second country. Everything is different. The data model doesn't fit. The assumptions from country one don't hold. The tax types are different. The forms are different. The edge cases multiply. The second country takes longer than the first.
Phase 3: Maintenance hell. Both countries ship. Then a law changes in country one. The team has to update the rules, test them, deploy them, and make sure the change doesn't break country two. Meanwhile, the business wants countries three, four, and five. The team is now spending more time maintaining existing jurisdictions than building new ones.
Phase 4: Abandonment. The team realises they've built a tax product, not a feature. It needs its own team, its own regulatory monitoring, its own accountant review. The company either spins it out, kills it, or stops adding jurisdictions.
This pattern plays out everywhere. It's why most multi-country platforms don't offer tax. It's not that they don't want to — it's that the engineering and regulatory cost is prohibitive.
What the architecture actually needs
A working multi-jurisdiction tax system has a layered architecture:
Layer 1: Common framework. The concepts that exist everywhere — income, expenses, deductions, tax liability, filing period — are modelled once. The data structures, the workflow (classify → compute → review → file), and the API contract are universal.
Layer 2: Regional rules. Groups of countries that share a legal framework get a shared rule layer. EU member states all follow the VAT Directive (2006/112/EC), so the concepts of intra-Community supply, reverse charge, and place of supply rules are modelled once and inherited by each country. Similarly, US states share the federal tax framework but add state-specific rules on top.
Layer 3: Country-specific implementation. Each country fills in its own rates, thresholds, form structures, filing deadlines, and edge cases. Malta's 18% VAT rate, Germany's 19%, Italy's 22% — these are parameters, not hard-coded values. The country-specific rules reference the legislation and are maintained by local accountants who read the law.
Layer 4: Computation engine. The engine takes classified transactions and applies the country-specific rules to produce the numbers. This must be deterministic. It can't be an LLM making predictions. It's arithmetic applied to codified law.
Layer 5: Accountant network. In every jurisdiction, a qualified local accountant reviews the output, verifies the classifications, checks the computation against their knowledge of local law, and carries professional liability for the filing. This is the part that can't be automated and shouldn't be.
This architecture lets you add new countries without rewriting the core. A new EU member state inherits the VAT Directive layer and only needs the country-specific delta. A new US state inherits the federal layer and adds state income tax rules. The common framework, the workflow, and the API stay the same.
What this means for platforms
If you're a platform evaluating how to offer tax compliance to your users across multiple countries, you have three choices:
Option 1: Build it yourself. Hire tax engineers, regulatory monitors, and local accountants in every country. Budget two to three years and seven figures before you have something production-ready in five countries. Then maintain it forever.
Option 2: Integrate country by country. Find a local accounting provider in each country and build a separate integration for each. You'll end up with a patchwork of inconsistent experiences, different data models, and no unified view.
Option 3: Embed accounting infrastructure. Integrate once with a provider that has the layered architecture, the multi-jurisdiction engine, and the accountant network already built. Your users get consistent accounting across every country through a single API.
Option 3 is what accounting infrastructure is for. It's the same decision that platforms made with payments (Stripe instead of building payment processing), identity (Auth0 instead of building authentication), and communications (Twilio instead of building SMS).
Accounting is the next infrastructure layer. The platforms that embed it will serve their users better than the ones that don't.
Accora covers 30+ jurisdictions through a single API. AI classifies, deterministic engines compute, local accountants review and file. Learn more at accora.ai
Michael Cutajar, CPA — Founder of Accora.