Neobanks have spent the last decade digitising every part of the banking experience. Account opening takes minutes. Payments are instant. Invoicing, expense categorisation, and cash flow forecasting are built into the app. But when a freelancer or sole trader needs to file a tax return, they leave the platform entirely.
They download a CSV, email it to an accountant, or log into government tax software and start entering numbers manually. The banking app that promised to simplify their financial life stops being useful at the exact moment their finances become most complicated.
This is the embedded tax filing gap. And for neobanks serving freelancers, micro-businesses, and self-employed users, it represents both a product gap and a revenue opportunity.
What Embedded Tax Filing Actually Means
Embedded tax filing is the integration of tax computation, professional review, and government submission directly into a platform's existing product. The end user never leaves the app. The platform never has to build tax logic or hire accountants.
In practice, this means a neobank user taps a button inside their banking app that says "File your tax return." Behind the scenes, the neobank's system sends the user's transaction data to a tax filing API. The API classifies the transactions, computes the tax liability according to the relevant jurisdiction's rules, routes the return to a licensed professional for review and sign-off, and then submits the filing to the tax authority. The user sees a progress screen, gets notified when their return is filed, and never opens a separate app or visits an accountant's office.
The key technical distinction is that the neobank does not compute tax or file returns itself. It passes structured financial data to a specialised API and receives back a filed return. The complexity of multi-jurisdiction tax law, professional licensing requirements, and government submission protocols are abstracted away entirely.
The Data Flow
The typical integration follows a straightforward pattern.
The neobank already holds the user's transaction data. Every payment received, every expense paid, every invoice issued. This data is the raw material for a tax return. In most cases, it is already categorised to some degree, either by the user, by the neobank's own machine learning models, or by integration with accounting software.
When the user initiates a filing, the neobank sends this transaction data to the tax API in a structured format. The minimum viable payload includes the transactions themselves with dates, amounts, currencies, counterparties, and categories. It also includes basic taxpayer information such as the user's tax identification number, jurisdiction, and filing status.
The API then runs the data through jurisdiction-specific tax rules engines. These are rules-based computation models, not AI guesswork. For a freelancer in Italy, the system computes IRPEF bands, applies the correct IVA rates, calculates contributi previdenziali, and determines quarterly payment obligations. For a sole trader in the UK, it computes income tax bands, Class 2 and Class 4 National Insurance, and any payments on account due under self-assessment.
The computed return is then routed to a licensed professional in the relevant jurisdiction for review. This is not optional. Tax returns carry legal liability. Someone with professional credentials must review and approve the filing before it goes to the tax authority. In Malta, that is a warranted CPA. In Italy, a commercialista. In Germany, a Steuerberater. In the UK, a chartered accountant or tax agent.
Once the professional approves the return, the API submits it to the government electronically and returns a confirmation to the neobank, which displays it to the user.
Why the Professional Review Layer Matters
The temptation for a technology company is to assume that tax computation is a pure software problem. Given the right rules engine, the right data, and enough testing, why not just compute and submit automatically?
The answer is legal liability. In every jurisdiction where tax returns are filed, there is a person or entity that takes legal responsibility for the accuracy of that return. In most cases, if an agent files on behalf of a taxpayer, that agent must be professionally licensed.
This is not a regulatory detail that can be worked around. It is a structural requirement of the tax system in virtually every developed country. The Malta Financial Services Authority does not grant exemptions. The UK's HMRC agent authorisation process requires a registered tax agent. Italy's Agenzia delle Entrate requires a commercialista. Germany's Finanzverwaltung requires a Steuerberater.
For a neobank considering whether to build this capability in-house versus embedding it via API, this professional licensing requirement is the critical factor. The neobank would need to establish legal entities, hire or contract with licensed professionals, and manage regulatory relationships in every jurisdiction where it offers tax filing. That is not an engineering problem. It is an operational and legal one.
What the Neobank Gets
The commercial case for embedding tax filing is built on three pillars.
The first is retention. Freelancer and sole trader users have a natural churn point when they need to deal with taxes. They go looking for an accountant, discover a competitor platform that offers more financial services, or simply disengage from active financial management because the tax burden feels overwhelming. Keeping the user inside the app through tax season eliminates that churn trigger.
The second is revenue. Tax filing is a service with clear value to the end user. It can be offered as a premium feature, bundled with higher-tier plans, or priced per filing. The unit economics are straightforward because the cost of professional review is per-return, and the neobank takes a margin.
The third is data enrichment. When a user's transactions are classified for tax purposes, the neobank gains a much richer understanding of the user's financial life. A payment to a supplier that was previously just "outgoing payment" becomes "cost of goods sold, deductible." This enriched data improves the neobank's ability to offer relevant financial products, from business loans to insurance to investment products.
Multi-Jurisdiction Complexity
The European market presents a particular challenge and opportunity. A neobank like Qonto operates in France, Germany, Italy, Spain, Austria, Belgium, the Netherlands, and Portugal. A neobank like Revolut operates in 35+ countries. Each of these jurisdictions has different tax rules, different filing deadlines, different government submission formats, and different professional licensing requirements.
Building a tax engine for one country is a significant engineering effort. Building and maintaining tax engines for eight or fifteen or thirty-five countries is not a scaling problem that a neobank's product team should own. The maintenance burden alone, tracking annual rate changes, new deduction categories, updated government APIs, regulatory amendments, is a full-time operation.
This is where the API model becomes compelling. The neobank integrates once. The API provider handles the jurisdiction-specific complexity, maintains the rules engines, manages the professional reviewer network, and deals with government submission protocols. When a new jurisdiction is added, the neobank's users in that country gain access to tax filing without any engineering work on the neobank's side.
The Integration Model
From an engineering perspective, the integration is lightweight. A neobank with a modern API-first architecture can integrate embedded tax filing with a small team in a matter of weeks.
The core integration points are a data export endpoint that sends the user's transaction data to the tax API, a webhook receiver that listens for status updates on the filing process (review started, review complete, filing submitted, filing accepted), and a UI component that displays the filing status and any actions required from the user, such as confirming personal details or answering questions that the transaction data alone cannot resolve (for example, whether a home office is used for business purposes).
The neobank does not need to understand tax law. It does not need to build a rules engine. It does not need to hire accountants. It passes data, receives status updates, and displays results.
Where This Is Heading
The trend is clear. Neobanks are moving from offering banking to offering financial operations. Invoicing was the first step beyond pure banking. Expense management was the second. Accounting integrations were the third.
Tax filing is the logical next step. It is the last major financial obligation that freelancers and sole traders handle outside their banking platform. The platforms that close this gap first will have a meaningful competitive advantage in freelancer retention and lifetime value.
The question for neobank product teams is not whether to offer tax filing. It is whether to build a tax engine from scratch, with all the licensing, compliance, and multi-jurisdiction complexity that entails, or to embed it via a specialised API that abstracts away that complexity.
For most neobanks, the answer will be the API. The build-versus-buy calculus is unusually clear in this case, because the "build" option requires not just engineering investment but professional licensing infrastructure that is fundamentally different from anything a technology company typically operates.
Michael Cutajar, CPA — Founder of Accora.