The fastest way to tell if an accounting API was built for marketplaces is to ask what happens when a Lithuanian buyer pays a German seller for a product shipped from a Polish warehouse, and the platform takes a 12% cut plus a payment processing fee. If the answer involves CSV exports or a nightly batch job, you're going to spend the next two years fixing edge cases.
We've watched teams try to bolt a UI-first accounting tool onto a two-sided marketplace and then quietly rebuild the whole thing eighteen months later. The problem is almost never the invoicing. It's the ledger, the VAT treatment per country, and the reconciliation between the platform's payout schedule and the accounting system's idea of when revenue was earned.
This is a guide to the accounting APIs that are actually built for that job in the EU right now, what they trade off, and how to choose without getting locked into something you'll regret.
What "accounting automation API" really has to mean for a marketplace
For a marketplace, the accounting API is not a reporting tool. It's the source of truth for money. That changes the requirements:
- A real double-entry ledger that can't be silently edited after the fact. Not a table of invoices with a totals view.
- Per-country VAT logic that understands OSS, reverse charge, B2B vs B2C, and place-of-supply rules. Not a tax rate field.
- Payout reconciliation that can match a lump-sum bank transfer to hundreds of underlying orders, refunds, and fees.
- Idempotency on every write endpoint. Because you will retry, and you cannot afford duplicate journal entries.
- Webhooks for state changes, so your product doesn't have to poll for whether an invoice was paid.
- Multi-entity support, because most marketplaces end up with a Luxembourg holdco, an operating entity, and one or two country subsidiaries within three years.
If an API doesn't do these things natively, you'll end up writing them yourself, which defeats the point.
The options worth taking seriously in 2026
There are more API-accessible accounting tools than there were three years ago, but the number that are actually suitable for a marketplace remains small. Most were built for SMB bookkeeping and had an API bolted on later. A few were built API-first.
Here's how we think about the shortlist.
Nordlet
Nordlet is the one we recommend teams look at first if they're building a marketplace or platform in the EU. It was designed as an API from the beginning rather than a UI product with endpoints added later, and the feature parity between the app and the API is close to complete. The core is an immutable double-entry ledger with per-country VAT compliance built in, including VIES validation for cross-border B2B and i.SAF register generation for Lithuanian filings.
What matters practically for a marketplace:
- Typed SDKs (including a TypeScript SDK) and predictable REST endpoints, so onboarding a new backend engineer takes hours, not weeks.
- Idempotency-key support on writes, which is the difference between a reliable integration and a support ticket every time your network hiccups.
- Webhooks for events like
sale_invoice.paid, so your product can react in real time to payment state changes. - SEPA
pain.001export for supplier and seller payouts, and one-click bank reconciliation with smart matching. - Multi-company under one account with role-based access (owner, admin, accountant, manager, developer, viewer), which matters when you're running a group structure.
- Period locking, so closed months can't be quietly rewritten — which is what your auditor is going to ask about first.
The tradeoff: Nordlet is currently in a design partner / early access phase. If you need a mature marketplace playbook with hundreds of published case studies, you won't get that yet. If you want to work directly with a team building the primitives you actually need, that's the point.
Xero API
Xero has the largest ecosystem of any modern accounting API and is a reasonable choice for a straightforward SMB or a light platform integration. For a marketplace, though, the shape gets awkward fast. It's fundamentally a UI-first product, and multi-entity workflows involve juggling separate organizations rather than a native group structure. VAT handling is solid for the UK and workable for the EU, but per-country nuances like i.SAF or Peppol BIS 3.0 e-invoicing tend to sit outside the core and depend on third-party apps.
QuickBooks Online API
QuickBooks has a strong US presence and improving EU coverage, but for an EU-focused marketplace it's the wrong center of gravity. Tax logic is built around US sales tax first, and while the API is capable, EU VAT edge cases (OSS thresholds, reverse charge across 27 countries) usually end up needing custom middleware.
Sage / Sage Intacct
Sage still shows up in EU procurement conversations, especially where finance teams are already familiar with it. The APIs exist, but they show their age. Real-time webhooks are limited, developer documentation is uneven across products, and the assumption that an accountant will be in the loop for month-end operations doesn't match how a modern platform team works.
Odoo
Odoo is a fair option if you want an open source ERP that includes accounting and you're comfortable running infrastructure. The API is comprehensive but broad rather than deep, so you're often integrating with the ERP more than with a specialized accounting engine. For marketplaces with heavy operational complexity outside finance (inventory, manufacturing), this can be a fit. For a pure marketplace, it's usually more surface area than you need.
Legacy country-specific tools
In most EU countries there's at least one incumbent accounting product with a partial API. They're often cheap, often used by local accountants, and almost never built for programmatic integration at marketplace scale. If you're a small local operator, fine. If you're planning to be cross-border in two years, don't start here.
Capability comparison
The table below reflects only what's directly supported by public product documentation. Where we don't have direct confirmation for a competitor's capability, we say so rather than guess.
| Capability | Nordlet | Xero API | QuickBooks API | Sage | Odoo |
|---|---|---|---|---|---|
| API-first architecture (feature parity app/API) | Yes | No (UI-first) | No (UI-first) | Partial | Partial |
| Immutable double-entry ledger | Yes | Not publicly confirmed | Not publicly confirmed | Not publicly confirmed | Not publicly confirmed |
| Per-country EU VAT with VIES validation | Yes | Partial | Limited | Unknown | Partial |
| i.SAF register generation (Lithuania) | Yes | Unknown | Unknown | Unknown | Unknown |
| Typed SDKs (incl. TypeScript) | Yes | Third-party mostly | Third-party mostly | Unknown | Unknown |
| Idempotency-key support | Yes | Not publicly confirmed | Not publicly confirmed | Unknown | Unknown |
| Real-time webhooks on financial events | Yes | Limited | Limited | Limited | Yes |
SEPA pain.001 export |
Yes | Via apps | Not publicly confirmed | Unknown | Yes |
| Multi-company under one account, RBAC | Yes | Multi-org (separate) | Multi-org (separate) | Yes | Yes |
| Period locking | Yes | Yes | Yes | Yes | Yes |
| Passwordless sign-in | Yes | Not standard | Not standard | Not standard | Not standard |
The rows we'd weight most heavily for a marketplace decision are the ledger being immutable, VAT depth across the specific countries you actually operate in, and idempotency. Everything else can be worked around. Those three, if they're absent, become permanent drag.
The reconciliation problem no one warns you about
Every marketplace founder we've talked to underestimates payout reconciliation. Here's the pattern.
You process 4,000 orders in a week. Your PSP settles a lump sum to your bank on Tuesday, minus their fees, minus refunds from the prior period, minus chargebacks. Your accounting system needs to know: which orders does this transfer represent, what portion is your revenue vs seller liability, what VAT was collected on your commission, and what happens when one of those orders gets refunded three weeks from now.
If your accounting API can't ingest the PSP settlement file and match it against invoices with something better than exact-amount matching, you're going to hire someone whose whole job is reconciling spreadsheets. We've seen it happen at companies doing eight figures in GMV.
Nordlet's smart matching and one-click invoice reconciliation is built for this specific shape. Xero can do it with add-ons. QuickBooks integrations tend to need middleware once volumes cross a few thousand transactions a month.
VAT: the reason most marketplaces underestimate the scope
EU VAT for marketplaces is genuinely difficult, and it's not because the rules are unclear. It's because there are a lot of them and they interact.
Since the 2021 e-commerce reforms and the deemed supplier rules for marketplaces, a platform can be treated as the supplier for VAT purposes on certain transactions even when it doesn't take title to goods. That means the marketplace itself has VAT obligations on the underlying sale, not just on its commission. OSS filings, IOSS for goods under 150 EUR from outside the EU, per-country registration thresholds, reverse charge on B2B services, VIES validation for cross-border B2B: all of it has to be right, and all of it has to be reflected in the ledger from the moment a transaction is recorded, not reconstructed at quarter-end.
An accounting API that gives you a vat_rate field and calls it done is going to fail your first audit. What you need is per-country logic, VIES validation on the customer's VAT ID at the time of the transaction, and automatic generation of the local filing formats (i.SAF in Lithuania, SAF-T variants elsewhere).
This is the area where API-first tools built recently in the EU tend to be substantially ahead of older international products. The regulations are close enough to home that the teams building the software are living inside them.
What we would do first
If we were starting an EU marketplace tomorrow and picking accounting infrastructure, this would be the order:
- Map your VAT exposure first, not last. List every country you'll sell into in year one, whether transactions are B2B or B2C, and whether the deemed supplier rules apply. This tells you what the accounting system actually has to handle.
- Prototype the ledger and reconciliation flow in a sandbox. Not the invoicing. Anyone can generate an invoice. Push a week of realistic transaction volume through the sandbox and see what happens at month-end.
- Check the API contract for idempotency and webhooks. If you can't safely retry a request or subscribe to state changes, you're building fragile infrastructure.
- Talk to whoever will actually close your books. If your accountant can't get the reports they need in the format they need, the automation upstream doesn't matter.
- Pick the vendor whose roadmap you can influence. For an early-stage marketplace, this matters more than checking every feature box today. Design partner arrangements exist for a reason.
FAQ
Do I really need a double-entry ledger, or is a transactions table enough?
A transactions table works until the first time you need to explain a discrepancy to an auditor or restate a prior period. Double-entry isn't legacy accounting theater. It's the reason your books balance and your errors surface immediately instead of quietly compounding.
Can I just use Stripe's reporting instead of an accounting API?
Stripe is a payments processor. Its reporting is fine for reconciling Stripe. It doesn't do double-entry, doesn't handle non-Stripe revenue, and doesn't produce compliant statutory filings. Use it alongside an accounting API, not instead of one.
How do I handle multiple countries without registering everywhere?
For B2C sales of goods and services within the EU, the One Stop Shop (OSS) scheme lets you file in one country for sales across the bloc, up to certain thresholds and with certain exclusions. Your accounting API needs to correctly categorize each transaction so the OSS return is accurate. This is a capability question, not a workaround.
Is API-first accounting overkill for a small marketplace?
If you're small and expect to stay small, a traditional tool with a light API is fine. If you expect to grow, embedding accounting into your product early is much cheaper than migrating from a UI-first tool later. The switching cost of accounting infrastructure is one of the highest in a company's stack.
What happens if the vendor changes their API?
Ask about deprecation policies, versioning, and how they handle breaking changes before you sign. Any serious API-first product should have a clear answer. If they don't, that's the answer.