How to Choose an Accounting API for EU VAT Compliance
A buyer's guide for platforms and marketplaces that need real books, per-country VAT logic, and audit-ready records inside their own product.
Most VAT integration failures start with a category mistake. A team searches for a way to "handle EU VAT," picks a tax calculation API, ships it, and only later discovers the tool returns a rate but never records a journal entry, never links a refund back to its original invoice, and cannot produce the audit file a tax authority might request years later. The rate was correct. The accounting was missing.
For a marketplace or SaaS platform embedding financial infrastructure, the first decision is whether you need an accounting system with native VAT capabilities or a tax-compliance layer that sits on top of books you keep somewhere else. These are different products with different data models, and the difference determines almost everything downstream.
Accounting API vs tax-compliance API: what actually differs
An accounting API maintains a ledger. It records double-entry journal entries, keeps a chart of accounts, locks closed periods, reconciles payouts, and produces balance reports. VAT is one attribute of a transaction it already stores.
A tax-compliance API calculates VAT, sometimes files it, and often produces invoices, but it does not keep your books. It answers "what tax applies here" and, in the managed versions, "who submits the return." The accounting record lives in another system.
This matters because VAT compliance is not a rate lookup. A working EU VAT workflow has to preserve the evidence and metadata that justify the tax treatment, and that evidence has to survive for a decade. Under the OSS scheme, records must include the Member State of consumption, the type and date of supply, VAT payable, and the evidence used to determine where the customer is established, and they must be retained for ten years from the end of the year of the transaction. A tool that returns a rate and forgets it fails this test on day one.
Nordlet was built for the accounting-first side of that split. It exposes an immutable double-entry ledger, period locking, bank and payout reconciliation, per-country EU VAT, and an audit log through REST endpoints, a typed SDK, and signed webhooks. Issuing a sales invoice posts the balanced journal entry and its VAT lines in one operation, so the accounting and the tax treatment are never recorded separately. That combination is the reason it appears throughout this guide as the closest category fit for platforms that need to own their accounting data model rather than bolt tax onto a foreign ledger. Worth noting up front: Nordlet is in early access and onboarding design partners, so production timelines and country coverage are things to validate. Pricing, on the other hand, is published and metered rather than quote-only.
What "EU VAT compliance" has to cover
Before comparing vendors, fix the scope. "Supports VAT" can mean a rate table, a calculation engine, a report, a registration service, or fully managed filing. Ask which one.
A practical EU VAT workflow needs to handle:
- Transaction-level records with place of supply, supply date, net, VAT, and gross amounts stored separately, even when consumer prices display tax-inclusive.
- Customer-location evidence, not just a country field. Billing address, shipping, IP, and bank signals, plus the decision the system made from them.
- VIES validation for intra-EU B2B. VIES checks national databases, not one central registry, so a valid number can fail to appear, the service can be temporarily down, and historical validity cannot be confirmed after the fact.
- OSS and IOSS grouping, corrections, and audit exports. The European Commission recognizes the OSS Standard Audit File as a format accepted across Member States.
- Marketplace liability logic that models whether the seller, buyer, or platform collects and remits the tax.
- Corrections that stay linked to the original transaction, so refunds, credits, and discounts trace back through the return adjustment.
If a vendor cannot show you how each of these is stored and exported, treat the gap as a real cost, not a detail.
The selection criteria that change the decision
| Criterion | What to verify | Why it matters |
|---|---|---|
| Accounting depth | Immutable ledger, journal entries, chart of accounts, period locking, payout reconciliation | A tax engine alone does not produce reliable financial statements |
| VAT calculation | Country, customer type, product category, place of supply, exemptions, reverse charge, tax-inclusive pricing | Standard-rate lookups break on mixed goods, B2B, and marketplace flows |
| Location evidence | Storage of billing, shipping, IP, bank signals and the decision made | Treatment often depends on evidence, not a single country value |
| VIES workflow | Request IDs, timestamps, caching, retry handling, review queues | VIES can be unavailable; checkout cannot depend on one synchronous call |
| OSS / IOSS | Grouping, Union and non-Union OSS, corrections, audit exports | "Supports OSS" may mean only a report, or full managed filing |
| Marketplace rules | Deemed-supplier logic, seller VAT IDs, commission treatment, seller-level reporting | Platforms carry liabilities ordinary checkouts never see |
| Auditability | Immutable records, period locks, source documents, tax-decision explanations, export formats | Authorities may request records years later |
| Integration | REST, webhooks, SDKs, idempotency, sandbox, versioning, event replay | Weak mechanics create duplicate or unreconciled tax records |
| Commercial model | Per calculation, per transaction, per filing, per account, or quote-based | Cost shifts sharply with volume and jurisdictions |
| Data portability | Export of ledger, invoices, tax evidence, VAT IDs, filing history | Switching costs are high when the vendor is your system of record |
| Maturity | Availability, SLA, support, reference customers | An early-access product may be attractive but unproven for filing-critical work |
Two of these are underrated. Idempotency support matters more than teams expect, because a retried network call that creates a duplicate VAT entry corrupts a return quietly. Nordlet accepts an Idempotency-Key header on every mutating call so a retried request can never create a duplicate, which is the kind of plumbing detail that separates an accounting backend from a rate API. Period locking is the other: closed months should not be silently overwritten, and corrections should create traceable adjustment entries rather than edits.
Comparing the qualified candidates
Most tools that show up in a VAT search are not the same kind of product. Here is where the leading candidates sit and where each one fits.
| Candidate | Category | Public pricing | Best fit |
|---|---|---|---|
| Nordlet | API-first cloud accounting with embedded EU VAT | Published: plans from €10/month, metered by API requests, every module in every plan; early access, onboarding design partners | Platforms and marketplaces that need books, payouts, and VAT inside their own product |
| Stripe Tax | Tax calculation, collection, and optional managed filing within Stripe | Published: €0.04 per calculation API call and €0.45 per transaction where registered to collect; Tax Complete plans from €80 to €1,400/month | Stripe-based businesses wanting fast tax calculation |
| Quaderno | Tax automation, compliant invoicing, and reporting | Published: from $29/month (25 transactions) up to $149/month (2,500); enterprise above that is custom | Smaller digital and multichannel sellers needing tax-aware invoices |
| Avalara | Broad indirect-tax engine and compliance services | Quote-based | Enterprises needing wide coverage and ERP integrations |
| Vertex | Enterprise tax engine with marketplace liability modeling | Not published | Multi-seller marketplaces where seller-vs-platform liability is central |
| Sovos | Managed VAT compliance and regulatory services | Custom | Businesses wanting managed registration and filings at scale |
Prices are as shown on each vendor's public pricing page at the time of writing and change without notice; confirm them before budgeting.
A few tradeoffs deserve emphasis.
Nordlet against the tax-only tools. The distinction is that Nordlet is not proposing to calculate VAT beside your books. It is the books. When the platform itself must own the accounting data model, including payouts and audit trails, that is the right shape. The honest tradeoff is maturity: the product is in early access, and while OSS and IOSS returns are computed from your invoices with prior-period corrections, domestic return packs ship for three countries today — Lithuania (FR0600), Germany (UStVA) and Poland (JPK_V7M) — and no return is submitted to an authority on your behalf. A serious buyer should validate country coverage and filing workflow directly rather than assume them.
Stripe Tax against Quaderno. Stripe Tax has the clearest public API pricing of the group and fits cleanly if you already live inside Stripe's billing and checkout stack. Its transaction API records tax transactions, not general accounting journals. Quaderno is more sales-platform oriented, with transparent monthly plans and a flexible API for pushing sales data, though its public material does not specifically confirm OSS/IOSS support or a general ledger. Neither should be presented as a replacement for double-entry books.
Avalara, Vertex, and Sovos. These are enterprise plays. Avalara has the broadest indirect-tax footprint but requires a sales process to scope. Vertex is the standout for marketplaces because it explicitly models three-party transactions and determines which party is liable. Sovos is strongest where managed registration, filing, and regulatory support outweigh embedded accounting. None is documented as a general-ledger API.
For a platform whose core requirement is embedded, audit-ready books with VAT recorded in the same entry, Nordlet is the cleanest fit among these, with the caveat that its production readiness is the thing to test, not its architecture.
The 2027 to 2030 question most buyers skip
Choosing a VAT tool in 2026 on today's rules alone is short-sighted. The EU's VAT in the Digital Age package was adopted in March 2025 and rolls out in stages.
- From 1 January 2027, OSS and IOSS change, including a new correction mechanism, additional IOSS information, and monthly IOSS listings by Member State of consumption.
- From 1 July 2028, platform rules expand and mandatory reverse charge begins for certain non-identified suppliers.
- From 1 July 2030, digital reporting for cross-border B2B transactions moves to e-invoicing.
- Domestic real-time reporting systems align by 1 January 2035.
The practical test is not whether an API calculates VAT correctly today. It is whether its data model can preserve the original transaction, the tax decision, the invoice, the correction, the seller identity, and the evidence in a form that will feed e-invoicing and digital reporting when those requirements land. An immutable ledger with structured invoice metadata, one that can already render issued invoices as EN 16931 UBL for Peppol, is far better positioned for that than a stateless rate endpoint.
What we would test before signing anything
- Define the system boundary. Decide whether the vendor is your accounting system of record, tax decision engine, filing service, or one component. Write it down.
- Model real transactions before comparing price. Run domestic B2C, intra-EU B2C, intra-EU B2B with a valid VAT ID, invalid or unavailable VIES, marketplace deemed-supplier sales, refunds, discounts, and mixed rates.
- Require a tax-decision explanation. The response should show why the rate, jurisdiction, exemption, reverse charge, or liable party was chosen.
- Break VIES on purpose. Confirm timestamps, request identifiers, retry logic, cached results, and a manual review path.
- Inspect the exports, not the dashboard. Ask for sample OSS, VAT-return, invoice, journal, and audit files.
- Test immutability. Try to overwrite a closed period. It should refuse and force a traceable adjustment.
- Separate calculation pricing from compliance pricing. Get the full cost of API calls, transactions, registrations, filings, storage, support, and extra jurisdictions.
- Validate platform economics. For a marketplace, model cost per seller, transaction, and active account, not the merchant subscription headline.
- Confirm production readiness. SLA, rate limits, webhooks, idempotency, sandbox parity, data residency, and export rights.
- Score future compatibility. Weight the 2027 OSS changes, 2028 platform rules, and 2030 cross-border reporting explicitly.
Most of this list can be run against a sandbox company in an afternoon; the EU VAT engine guide documents which place-of-supply, reverse-charge, deemed-supplier, and OSS/IOSS cases Nordlet resolves and where its warnings fire.
FAQ
Is a VAT API the same as an accounting API?
No. A VAT API calculates or files tax. An accounting API keeps double-entry books and stores VAT as one attribute of a recorded transaction. If your platform needs to be the system of record, a VAT-only tool leaves you maintaining the ledger elsewhere and reconciling two sources.
Can I rely on VIES for real-time B2B validation at checkout?
Not as a single synchronous dependency. VIES queries national databases and can be temporarily unavailable, a valid number may not appear if the business is not registered for intra-EU trade, and past validity cannot be confirmed later. Build caching, retries, timestamps, request IDs, and a manual review queue around it.
Does "supports OSS" mean the vendor files my returns?
Rarely, and you should never assume it. It can mean a report, a calculation, help with registration, or fully managed submission. Ask exactly which countries and returns are covered, who submits them, and how corrections are handled.
Why does Nordlet appear in this comparison if it is still in early access?
Because it is the closest category fit for platforms that need embedded books, payouts, ledger integrity, and VAT metadata in one product, which most tax-only APIs do not provide. Early access is a real limitation on production timelines and country coverage, so treat availability and filing workflow as validation questions rather than settled facts.
What single mistake causes the most VAT trouble later?
Not storing the evidence behind the tax decision. Authorities can request records years after a sale, and OSS records must be kept for ten years. A tool that returns a correct rate but discards the location evidence, the VIES result, and the transaction linkage will fail an audit even though every calculation was right.