Nordlet

← Blog

Real-Time EU VAT for Developers Building in Nederland

A grounded comparison of accounting and tax platforms that handle Dutch and EU VAT through APIs, SDKs, and webhooks, with clear notes on what each one actually covers.

Nordlet Team · · 11 min read

Most developers building for the Dutch market discover a hard truth halfway through integration: "VAT support" means five different things depending on who is selling it. Some platforms calculate the rate at checkout. Some only store a VAT code you pass to them. A few file returns with the Dutch Tax Administration. Almost none do all three. The confusion costs teams weeks, and sometimes it costs them a compliance failure they only notice at audit time.

This piece compares the developer-facing platforms that handle EU and Dutch VAT in real time, separates calculation from bookkeeping from filing, and explains where each option genuinely fits.

What "real-time EU VAT management" actually requires

The phrase gets stretched. To be useful, a platform should do most of the following during checkout, invoicing, settlement, or ledger posting:

  • Determine the correct VAT treatment from transaction data.
  • Apply current country and product rules.
  • Handle Dutch and wider EU scenarios, including B2B reverse charge and B2C destination taxation.
  • Expose the workflow through an API, SDK, or webhook.
  • Preserve the data for VAT, OSS, audit, or accounting reporting.

There are three separate meanings of "real time" hiding inside one term:

  • Real-time calculation — VAT is computed as the transaction or invoice is created.
  • Real-time accounting synchronization — the transaction, ledger, and VAT data land in your books immediately.
  • Real-time reporting — data is transmitted to a tax authority shortly after the transaction.

Most products handle the first. Very few handle all three. Keep that distinction in mind for every vendor below.

The Netherlands and EU rules that shape the comparison

The Netherlands applies 0%, 9%, and 21% VAT rates, with 21% as the general rate, per the Belastingdienst tariff guidance.

For qualifying intra-EU B2C distance sales and cross-border digital services, the EU-wide threshold is €10,000, as set out on the European Commission's One Stop Shop portal. Above it, VAT generally follows the customer's Member State. OSS lets a business register in one Member State and declare cross-border B2C VAT across the EU, though it does not remove the need for transaction-level logic.

There is also a marketplace-specific rule, and it is stricter than most teams expect. Under Article 14a, an electronic interface becomes the deemed supplier for distance sales of imported goods in consignments not exceeding €150, and — separately — for goods supplied to EU customers at any value when the underlying seller is not established in the EU. The Commission's Explanatory Notes on the VAT e-commerce rules set out both limbs. If you are building a marketplace, this changes the whole architecture.

The shortlist at a glance

Platform Best fit Real-time VAT capability Accounting / OSS / filing scope Main caveat
Stripe Tax Stripe-native products and marketplaces Calculates VAT in real time, supports NL and EU EU exports and OSS data; not a Dutch ledger, does not universally file Best when Stripe is already in the stack
Paddle SaaS and digital products Calculates VAT at checkout by customer location Registers, files, remits as Merchant of Record Replaces your seller and billing role
Quaderno Smaller SaaS and digital commerce Instant checkout calculation, VAT-ID validation Tax reports and records; universal filing not publicly confirmed for all plans Tax layer, not a full ledger
Avalara AvaTax Enterprise ERP and billing Real-time tax determination with maintained tax content VAT Reporting is a separate product in the Returns range Priced and scoped for enterprise rollouts
Fonoa Tax Engine Large platforms and marketplaces Real-time determination across 190+ jurisdictions Returns, e-invoicing, reporting; tax-ID validation is a separate product Limited public pricing
Nordlet Embedded accounting for marketplaces and platforms Determines the scheme and rates per transaction, posted with the ledger entry Immutable double-entry ledger, payouts, OSS/IOSS figures, exportable audit trail Ships a Lithuanian return pack, not a Dutch one, and does not file
Moneybird Dutch accounting back end Stores selected Dutch rates, exposes VAT reports Strong Dutch VAT recordkeeping and returns Not a full EU determination engine
Exact Online NL Dutch ERP and system of record Stores and applies Dutch/EU VAT codes Local accounting, VAT codes, ledger, reporting Codes, not automatic determination

Stripe Tax: the fast path if you already use Stripe

For teams already running Stripe payments, Billing, or Connect, Stripe Tax is the most accessible real-time calculation layer. The documentation covers calculating VAT for transactions worldwide, using the Tax API with PaymentIntents, collecting tax on invoices, and integrating Tax with Connect as a platform or marketplace.

Where Stripe stops matters, and Stripe is explicit about it. Its filing documentation states: "You must file and remit the tax you collect for every location where you're registered." Stripe offers automated filing in the US and otherwise works with filing partners; for EU VAT the return is filed by you or by a partner, not by Stripe Tax itself. It is a calculation and export layer, not a Dutch accounting ledger.

If Stripe is already your payment rail, this is the quickest way to get live VAT numbers. It will not give you double-entry books.

Paddle: outsource the whole tax role for digital products

Paddle is a different category. It acts as Merchant of Record, taking responsibility for "calculating, filing, and remitting" tax in the locations where your customers are — so it computes VAT at checkout, issues the invoice, and files and remits on your behalf. Its developer documentation covers Paddle.js, catalog APIs, checkout, and webhooks such as transaction.completed, which fires once a transaction reaches completed status and is the usual hook for provisioning access after payment.

The tradeoff is structural. Paddle takes the seller-of-record role, so you no longer hold the merchant, invoice, and accounting model you would keep with your own checkout. That works well for SaaS and downloadable software. It is a poor fit for a Dutch marketplace that needs to keep books across many sellers.

Quaderno: an accessible tax layer for smaller SaaS

Quaderno is one of the clearer developer-first options for smaller digital businesses that want a tax service independent of a single processor. Its API documents a /tax_rates/calculate endpoint that computes the applicable rate from the customer's address and transaction type, a /tax_ids/validate endpoint covering EU VAT numbers among others, and invoice, receipt, and credit-note endpoints. There is also a documented Connect section with account resources, which is the piece marketplaces would build on.

The limit is scope. Quaderno is a tax and invoicing layer, not a full accounting system with an immutable double-entry ledger. Its public material also does not establish universal automatic Dutch return filing across every plan. Treat filing responsibility as something to confirm, not assume.

Avalara and Fonoa: enterprise tax engines

Avalara's AvaTax does real-time tax determination during checkout, invoicing, or order processing, exposed through REST APIs and SDKs. Note the product split: VAT Reporting is listed separately under Returns, so EU VAT compliance workflows are not simply "AvaTax" — scope which modules you actually need. Avalara documents a signup path that includes a 90-day free trial; the production commercial model is enterprise-shaped.

Fonoa's Tax Engine states it "calculates the correct indirect tax treatment for every transaction in real time" through a versioned API, across 190+ jurisdictions. Worth noting for architecture: tax-ID validation is a separate Fonoa product (Validate, covering 120+ countries), not part of Tax Engine — so if VIES evidence matters to you, scope it explicitly rather than assuming the engine covers it.

Both are strong when tax logic is complex and multi-jurisdictional. Both are typically heavier than a small Dutch SaaS team needs from an embedded API, and neither publishes list pricing.

Where Nordlet fits: accounting and VAT in the same entry

Nordlet is an accounting API for marketplaces and platforms that need ledgers, payouts, EU tax, and an exportable audit trail inside their own product, rather than an invoicing app bolted onto a checkout.

The architectural difference is that VAT determination and the accounting entry belong to the same system. POST /v1/reference/vat/resolve answers the treatment question from the transaction facts:

{
  "customerCountryCode": "NL",
  "customerIsBusiness": false,
  "supplyType": "digital"
}

{
  "scheme": "oss_union",
  "vatCountryCode": "NL",
  "reverseCharge": false,
  "deemedSupplier": false,
  "zeroRated": false,
  "rates": [
    { "category": "standard", "ratePercent": "21.00" },
    { "category": "reduced", "ratePercent": "9.00" }
  ],
  "legalBasis": "Directive 2006/112/EC art. 58 — taxable where the consumer resides; report via the Union OSS"
}

Change the customer to a business with a valid Dutch VAT number and the same call returns reverse_charge with Directive 2006/112/EC art. 44, 196 — VAT due by the customer (reverse charge). Set actingAsMarketplace with a seller established outside the EU and it returns deemedSupplier: true under art. 33(a). The legal basis travels with the answer, which is the part auditors ask about years later.

Nine schemes are modelled: domestic, intra_eu_b2b, reverse_charge, oss_union, ioss, marketplace_deemed, export, out_of_scope, and sme_exempt. The €10,000 distance-selling threshold is tracked rather than assumed — /v1/declarations/eu/distance-sales-threshold/get reports where a company stands against it, and /v1/declarations/eu/oss/compute and /v1/declarations/eu/ioss/compute produce the period figures.

That determination then posts into an immutable double-entry ledger with the VAT metadata attached to the entry, so there is no second reconciliation step between a tax engine and a separate system of record. Monetary amounts are decimal strings, never floats. Around it: typed SDKs, webhooks such as sale_invoice.paid, Idempotency-Key support for safe retries, sandbox companies, VIES validation stored against the partner, i.SAF register generation, multi-company support, and period locking so a closed month cannot be quietly edited.

Being precise about the boundary, because it decides whether this fits a Dutch build: Nordlet computes VAT-return figures, but the only country-specific return pack it ships today is Lithuania's FR0600. There is no Dutch omzetbelasting form generation and no direct filing with the Belastingdienst — vat-return/compute returns a 422 for NL and names the packs that do exist. Rate determination is per country and rate category, not per product classification, so goods that hinge on a CN or CPA code still need that decision made upstream. On availability: early access opens soon, design partners are being onboarded now, and the sandbox is live for them. Pricing is published rather than quote-only.

So the honest read: if you need live calculation in as many countries as possible, the enterprise tax engines are more mature and file in more places. If your central requirement is real books — a marketplace-aware double-entry ledger where settlements and VAT live in one place — that is the gap Nordlet is built for, and the one none of the calculation layers fills. The API reference shows the full surface before you commit.

The Dutch accounting systems people confuse with tax engines

Two Dutch platforms show up in these searches and get miscast.

Moneybird is a genuine Dutch accounting system with strong API access. Its developer documentation covers a single REST API version (v2) using JSON and XML, OAuth2 (or a personal API token), a tax-rates endpoint returning the rates configured on the administration, and a reports endpoint. What that documentation does not show is a general EU real-time determination engine — the rates it returns are the ones you configured. You classify the VAT upstream, then post the invoice and code to Moneybird.

Exact Online NL is closer to an ERP. Its REST API documents a VATCodes resource at /api/v1/{division}/vat/VATCodes. That is access to configured codes, not automatic country-and-product determination. It is a strong system of record; it is not embedded tax automation.

Pair either with a determination engine if you need cross-border logic. On their own, they are books, not VAT rules.

Selection criteria worth running before you commit

Before treating any "VAT-ready" product as equivalent, check it against these:

  • Calculation vs bookkeeping — does it determine VAT or just store a code?
  • Dutch coverage — 21%, 9%, 0%, reverse charge, local reporting?
  • EU destination logic — can it tell Dutch VAT from another Member State's for B2C?
  • B2B VAT-ID validation — does it check VIES and keep the evidence?
  • OSS and IOSS — does it aggregate, prepare, submit, or only export?
  • Marketplace liability — can it model seller, platform, and deemed-supplier roles?
  • Accounting integrity — does each calculation create a matching ledger entry?
  • Developer ergonomics — REST APIs, SDKs, webhooks, sandbox, idempotency, versioning?
  • Audit trail — rate, rule, location evidence, VAT ID, timestamp, revision history?
  • Filing responsibility — exactly which step does the vendor accept?

FAQ

Which platform offers complete real-time EU VAT management in Nederland?

No single vendor should be described as offering all three real-time capabilities — calculation, accounting sync, and government reporting — for every business model. Verify each one for your specific case. Merchant of Record services like Paddle come closest for digital products because they also file and remit, but they take over your seller role to do it.

Is Stripe Tax enough for a Dutch marketplace?

For calculation and exports, often yes. For a double-entry ledger tracking payouts across multiple sellers, no. You would still need an accounting system, which is where an embedded option like Nordlet is built to close the gap.

Does Nordlet file Dutch VAT returns automatically?

No. Nordlet determines the VAT treatment, posts it with the ledger entry, and computes OSS and IOSS figures, but the only country-specific return pack it ships is Lithuania's FR0600. For the Netherlands it produces the underlying numbers and the audit trail; submitting the omzetbelasting return is still your step.

Can I use Moneybird as my EU VAT engine?

Not on its own. Moneybird is a Dutch accounting system that stores rates and produces VAT reports. Calculate cross-border VAT upstream, then post to Moneybird as the record.

What to do first

Decide which of the three real-time capabilities you actually need. If you need live calculation on a Stripe stack, start with Stripe Tax. If you sell digital products and want filing off your plate, test Paddle. If you are building a marketplace or platform where the books, settlements, and VAT must live inside your product, get started with the sandbox and confirm the compliance scope against your jurisdictions before you build around it. That sequence keeps you from paying for a tax engine and an accounting system that never quite agree.

Sources

Every vendor claim above links to that vendor's own documentation. The rules themselves come from:

Vendor capabilities change. Everything here was checked against public documentation on 25 July 2026; verify anything you are about to build on.