Qonto API Integration Research

Date: 2026-05-13 Product: Qonto (qonto.com) -- Pan-European neobank for SMBs, Paris (FR/DE/IT/ES/AT/BE/PT/NL) Purpose: Evaluate Qonto's API capabilities for Orcha integration -- specifically for a German customer evaluating Qonto as a Pleo alternative for employee credit cards while continuing to use Orcha for AP invoices and DATEV for accounting.

Important Context: What Qonto Actually Is

Qonto is NOT a spend management platform in the Pleo / Payhawk / Moss / Spendesk sense -- it is a licensed neobank (French EMI / payment institution, passported across the EU) that ships expense-management tooling on top of its core current-account product. The category positioning is fundamentally different from Pleo:

Qonto handles:

• Business bank accounts with local IBANs (FR / DE / IT / ES / AT / BE / NL / PT)
• Mastercard debit & prepaid cards (physical + virtual + flash one-time virtuals)
• SEPA / SEPA Instant / SWIFT / international transfers
• SEPA Direct Debit collections + mandates
• Light expense management (receipt capture, expense reimbursements, mileage -- in higher tiers / add-on)
• Light supplier invoice intake (Supplier Invoices module)
• Client invoicing + quotes + credit notes (outgoing AR)
• Payment terminals
• Onboarding-as-a-service (Onboarding API)
• Banking-as-a-service ("Qonto Embed") for partner platforms

Implication for Orcha: Qonto is a different beast than Pleo. The integration question shifts from "can we get clean expense data with full coding?" to "can we get clean card-transaction data with bank-grade fidelity, plus whatever pre-coding the customer has done in Qonto?" The customer is replacing Pleo (a spend platform) with Qonto (a bank), and accepting that some pre-accounting depth (rich approval workflows, AI category coding, mileage automation) downgrades unless they buy the Expense & Spend Management add-on. The DATEV story is what makes this an interesting move: Qonto's DATEV depth is genuinely strong because Qonto is a bank (DATEV RZ-Bankinfo, Belegbilderservice, Rechnungsdatenservice 1.0 are bank-native integrations).

1. Summary -- Capability Matrix

Overall assessment: Qonto has the most operationally-relevant API of any vendor researched so far for the specific Orcha use case of "read card-transaction data into our spend analytics." Three structural advantages over Pleo:

1. It's a bank, so transaction events are first-class -- the transactions.created webhook fires when the bank books the transaction (settle / pending-card-auth), not when a user reviews an expense in an app. No monthly-export-job gating.
2. API is available on all paid plans (Basic and above, from EUR 9/mo) -- no Advanced-tier gate like Pleo. Even the entry-level sole-trader Basic plan can issue API keys.
3. DATEV depth is genuinely deeper than any spend-management tool because Qonto is the bank, so RZ-Bankinfo (DATEV's bank-data collective service), Belegbilderservice, and Rechnungsdatenservice 1.0 are all native and bidirectional with DATEV Unternehmen Online and tax-advisor systems.

Three caveats:

1. Qonto is banking-first -- AI-powered expense pre-coding, dedicated approval workflows, mileage automation, and per-diem are weaker / add-on than Pleo/Payhawk. The customer needs to accept this trade-off.
2. Reference-data write parity is N/A -- Qonto has no chart of accounts or tax-code concept; "labels" are the only tagging primitive and are read-only via the public API. Orcha cannot sync CoA into Qonto because Qonto doesn't model CoA. This is a non-issue because DATEV does the heavy lifting anyway.
3. OAuth approval for sensitive scopes can take several days -- if Orcha integrates as an OAuth app for any payment-write or organisation-read scope, sensitive-scope justification is required during app registration.

2. API Landscape

API Surfaces

Authentication

Qonto supports two authentication methods: API Key (per-organisation, primary for own-org integrations) and OAuth 2.0 (delegated, for third-party apps reaching multiple Qonto orgs). Most endpoints accept either; a subset (the sensitive ones) is OAuth-only.

Implication for the customer scenario: the customer can issue an API key from their own Qonto admin, hand it to Orcha (or to themselves via Orcha's connection wizard), and Orcha gets full read of transactions + cards + attachments + supplier-invoice push. No OAuth app registration needed, no PSD2 license needed. This is dramatically simpler than Pleo's OAuth client-credentials + scope-per-resource setup.

Rate Limits

• 1,000 requests per 10 seconds
• 10,000 requests per 10 minutes
• Applied per-IP (not per-key) -- relevant for multi-customer deployments behind a shared egress
• Returns HTTP 429 on exceed
• Additional throttle: more than 200 requests with HTTP 401 within 1 hour also throttled (anti-brute-force)
• Pagination limit: search_limit_reached HTTP 422 when results exceed 10,000 records without sufficient filters

For comparison:

• Pleo: 600/min = 10/s
• Payhawk: 15/s
• Qonto: 100/s (1000/10s) sustained, with a 10000/10min ceiling

Qonto is roughly 7-10x more permissive on the per-second budget than Payhawk and Pleo. This matters for initial bulk sync of historical transactions on a multi-year account.

Idempotency

Qonto supports idempotent requests via the X-Qonto-Idempotency-Key header (client-generated unique value). Server caches the response and returns the cached response for duplicates, even if the body differs -- standard idempotency pattern. Used heavily on transfer creation and supplier invoice creation to avoid double-posting on retry.

API Categories (Business API)

Per the public docs index (docs.qonto.com/llms.txt):

Versioning & Deprecation

API is on v2. Public deprecation notice: legacy /v1 organisation endpoints are sunset on September 15, 2026 -- migrate to the new memberships + organisations split. Active integrations should be on /v2.

3. Write Capability Verification

Confidence: HIGH. Qonto's write surface is genuinely broad -- but it is bank-shaped, not ERP-shaped. There are no chart-of-accounts, cost-center, or tax-code resources to write because Qonto doesn't model those concepts. What Qonto does expose for write is:

Confirmed Write Endpoints

What Cannot Be Written

Key Limitation: Pre-Accounting Depth

Even though POST /v2/transactions/{id}/attachments accepts a receipt and GET /v2/transactions?includes[]=labels,vat_details returns labels and VAT, Qonto's pre-accounting model is intentionally light: a transaction can have one or more labels, VAT details (rate + amount), and attached receipts. That is the full coding surface. There is no concept of:

• Multiple distributions per transaction (split coding)
• Project codes / cost centers as separate first-class objects
• Tax code mapping tables
• Approval-level metadata beyond the request itself

This is by design: Qonto pushes pre-accounted data into DATEV / lexoffice / sevDesk where the customer's actual accounting depth lives.

4. iPaaS & Middleware Findings

Zapier and Make.com both have mature Qonto connectors -- noticeably more than Pleo (Zapier-only, more limited) or Payhawk (Workato + community Make, no Zapier). For a customer who wants no-code orchestration, both Zapier and Make are reasonable starting points. The Make connector is more comprehensive (memberships + clients + teams + invoice listing) while Zapier has slightly more granular transaction-update triggers (separate label / attachment / VAT update events).

Critically: the Zapier Add Attachment and Make Add Attachment actions confirm that the POST /v2/transactions/{id}/attachments endpoint is fully usable for write-side automation -- which is the receipt-mirroring path Orcha would use to push DATEV-archived receipts back into Qonto if needed.

5. Alternative Channels

DATEV Integration (Native, Bank-Grade)

This is Qonto's single biggest differentiator versus any spend-management vendor. Because Qonto is the bank, it plugs into DATEV via DATEV's own bank-data services, not via generic spend-tool export connectors.

Qonto offers four distinct DATEV integrations for the German market, available on all plans except Basic (so: Smart EUR 19/mo and up for sole traders; Essential EUR 49/mo and up for companies):

What this means for the customer: Card transactions captured by Qonto flow into DATEV via RZ-Bankinfo daily as bank statements. Receipts attached to those transactions in Qonto (via Orcha-uploaded webhooks or manual upload) flow into DATEV Belege Online via Belegbilderservice and get auto-matched on the DATEV side. This is bank-native plumbing that Pleo / Payhawk can only approximate.

No CAMT.053 / MT940 export? Qonto does not advertise a direct CAMT.053 or MT940 file export to non-DATEV systems. The "DATEV-Sammelverfahren" channel is DATEV-specific. For non-DATEV banks, EBICS is mentioned as available on enterprise tiers but is not documented as a self-service feature.

Native ERP/Accounting Integrations

Confirmed list (non-exhaustive):

Qonto's marketing claims "2,000+ integrations" -- the vast majority are via Zapier / Make. Native bidirectional integrations are concentrated on the accounting / tax-advisor side, exactly what a German customer needs.

Webhooks (Real-Time Event Delivery)

This is the biggest single advantage over Pleo for the customer's use case. Pleo's expense data is gated behind customer-triggered Export Jobs (typically monthly). Qonto delivers transactions via real-time webhook within seconds of the bank booking the transaction.

PSD2 / Open Banking Dimension

Qonto is a licensed payment institution and is "PSD2-regulated" -- meaning third-party providers (TPPs) holding an AISP or PISP license can access Qonto customer accounts under PSD2 statutory rights with a QSeal eIDAS certificate. However, this is a separate path from the developer-portal Business API.

For Orcha integrating with one customer's Qonto account:

• The customer issues an API key (or grants OAuth) inside their Qonto org
• Orcha uses that credential to access the Business API
• No PSD2 / TPP / AISP / QSeal certificate required
• This is the standard pattern for first-party app integrations and is much simpler than the PSD2 route

PSD2 only becomes relevant if Orcha wanted to access Qonto accounts on behalf of customers without the customer having to register Orcha as a developer app (the "open banking" path). For the customer scenario, this is not relevant.

CSV / Manual Export

Standard bank-statement PDF and CSV export available in the web app for any plan. Useful for backfill / reconciliation but not for an automated integration.

6. Licensing & Access Requirements

API Access by Plan

Qonto's API is available on all paid plans (Basic and above) with no separate API fee. This matches Payhawk's posture and is fundamentally better than Pleo's Advanced-only gating.

For the customer scenario (German company replacing Pleo with Qonto for employee cards): Essential is the realistic entry-point. EUR 49/mo (annual) gets API + DATEV + 1 Mastercard. Additional cards (which they'll need for 30 cardholders) are added per-card -- the Enterprise plan at EUR 199/mo includes 30 cards baseline and is the right tier for a 30-cardholder team. Plus the optional Expense & Spend Management add-on if they want approval workflows + mileage + per-diem to approximate Pleo's depth.

Compared to Pleo: Pleo's Advanced plan (EUR ~109/mo for API) plus per-user fees (EUR 11-18 each) for 30 users = EUR 440-650/mo. Qonto's Enterprise at EUR 199/mo with 30 cards bundled is materially cheaper and includes the bank account itself.

Pricing Model Differences vs Pleo

• Pleo: SaaS per-user + base fee + interchange. Bank account separately, no banking license.
• Qonto: SaaS subscription + interchange + transfer fees + FX. Banking license included.

This is comparing apples and pears -- you're getting a bank account out of Qonto, not just a spend tool. The economics often favour Qonto for DACH SMBs because the savings from consolidating bank + cards + light expense management offset the loss of best-in-class expense pre-coding.

Customer Setup Checklist

1. Customer needs a Qonto Business plan -- Essential or Enterprise (depending on cardholder count) is the relevant tier for replacing Pleo
2. Owner/Admin role required to issue API keys -- navigate to Integrations and Partnerships > API key > Generate
3. Copy login and secret-key; hand to Orcha (or paste into Orcha's connection wizard)
4. Header format: Authorization: <login>:<secret-key> (colon-concatenated, not Base64)
5. (For real-time) Create webhook subscription via POST /v2/webhook_subscriptions pointing at Orcha's webhook endpoint; copy the webhook secret for HMAC-SHA256 verification
6. (For DATEV) Customer's tax advisor enables one or more of: RZ-Bankinfo (transactions to DATEV daily), Belegbilderservice (receipts to DATEV daily), Rechnungsdatenservice 1.0 (structured invoices). Setup via Qonto web app + MyDATEV admin rights.
7. (Optional) If customer wants OAuth instead of API key: Orcha registers OAuth app at developers.qonto.com, customer goes through standard OAuth consent flow. Sensitive scopes need written justification + multi-day approval.

7. Orcha-Specific Deep Dive

Critical Question Comparison: Qonto vs Pleo on the Customer's Pain Points

Critical Question: What Role Does Qonto Play Relative to Orcha?

Qonto and Orcha do not overlap in the way Pleo / Payhawk / Moss do. Qonto's invoice handling is light (a Supplier Invoices module exists but is shallow); Orcha is the customer's AP system. The split for the customer scenario is:

With the customer keeping Orcha for AP and Qonto for cards/banking, the integration value is one-directional: Qonto -> Orcha read of card transaction data for unified spend analytics. Reference-data write is not applicable (Qonto doesn't model CoA). Receipt-attachment write from Orcha -> Qonto is technically feasible (POST /v2/transactions/{id}/attachments) and arguably useful if Orcha holds receipts that should land in Qonto for DATEV-Belegbilderservice forwarding -- but the more direct path is for Orcha to push receipts to DATEV directly.

Integration Scenarios for the Customer

Scenario A: Orcha reads card transaction data FROM Qonto for unified spend analytics (PRIMARY USE CASE)

• Feasibility: HIGH
• Subscribe to webhook events: transactions.created, transactions.updated (transaction lifecycle) + all 10 cards.* events (card lifecycle)
• On transactions.created for operation_type=card: GET /v2/transactions/{id}?includes[]=labels,attachments,vat_details for full detail incl. attachments, labels, VAT
• Join to card details: GET /v2/cards?ids[]={card_ids_from_tx} for masked_pan / last-4 / card_level (virtual vs physical) / holder_id / category restrictions
• Resolve holder: GET /v2/memberships/{holder_id} for employee name + email
• For attachments: GET /v2/attachments/{id} returns the file or URL (probe TTL behaviour empirically)
• Periodic GET /v2/transactions?updated_at_from=... reconciliation sweep to catch missed webhooks (bank-grade reliability is high but not perfect)
• No invoice push back to Qonto needed for this use case

Scenario B: Orcha pushes receipts INTO Qonto for DATEV-Belegbilderservice forwarding (SECONDARY USE CASE)

• Feasibility: HIGH
• If Orcha holds receipts that match Qonto card transactions, POST /v2/transactions/{id}/attachments (multipart, JPEG/PNG/PDF) pushes them in
• Files processed async (not immediately visible) -- Qonto's matcher runs in background
• Receipts then auto-flow to DATEV Belege Online via the customer's Belegbilderservice connection daily
• Caveat: this is only useful if the customer hasn't configured Orcha-to-DATEV direct (which would be the more direct path). For most customers, this is redundant.

Scenario C: Orcha pushes supplier invoices INTO Qonto for payment via card or transfer

• Feasibility: POSSIBLE but typically irrelevant
• POST /v2/supplier_invoices/bulk accepts multipart PDFs with idempotency keys
• Qonto then handles approval + payment via the customer's Qonto bank account
• For the customer scenario (Orcha = AP, DATEV = accounting, Qonto = bank), this would mean Orcha hands off payment execution to Qonto. Unusual workflow; most customers initiate payments directly from DATEV (via DATEV Bankdatenservice PIN/TAN) or from Qonto UI.

Scenario D: Orcha approves expense requests in Qonto

• Feasibility: POSSIBLE (OAuth-only) but typically irrelevant
• POST /v2/requests/{id}/review (approve/decline) with scope request_review.write
• Useful only if Orcha is the approval system of record; uncommon configuration

Key API Differences vs Pleo

Receipt URL Longevity -- Action Required

As with Payhawk, the URL TTL for attachments returned by GET /v2/attachments/{id} is not publicly documented. Before committing engineering effort, probe in sandbox:

1. Upload an attachment via POST /v2/transactions/{id}/attachments
2. Fetch the attachment URL via GET /v2/attachments/{id}
3. Re-fetch at T+1h, T+24h, T+7d, T+30d to determine TTL
4. Likely outcome: long TTL or non-expiring (Qonto stores attachments for DATEV / GoBD compliance, so they need persistent retention)
5. If TTL is short: Orcha should mirror attachments to its own object storage at webhook time
6. If TTL is long / non-expiring: Orcha can rely on Qonto-hosted URLs

Orcha Integration Capability Summary

8. Recommended Path Forward

Assessment: Qonto is the Strongest Read-Side Integration Target of any Spend / Banking Vendor Researched So Far

For the customer scenario (DATEV + Orcha + Pleo replacement with Qonto for cards), Qonto's posture is uniquely well-aligned with how Orcha needs to operate:

• Webhooks fire at bank-booking time -- no monthly export gate.
• API access is included on every paid plan.
• DATEV integration is bank-grade, native, and on four separate channels.
• Rate limits are 7-10x more permissive than Pleo / Payhawk.
• Two iPaaS connectors (Zapier, Make) for customers who prefer no-code orchestration.

The trade-off the customer accepts moving from Pleo to Qonto is shallower expense pre-coding (AI categorisation, approval matrices, mileage). For a customer whose AP coding lives in Orcha and accounting lives in DATEV, this is often a fair trade because the deep coding happens downstream of Qonto anyway.

Recommended Architecture

[Card transactions]                                        [Vendor invoices]
       |                                                          |
       v                                                          v
   Qonto (bank) -- real-time webhook + GET /v2/transactions --> Orcha (read-side: unified spend analytics)
       |                                                          |
       |                                                          |
       v                                                          v
   DATEV  <-- RZ-Bankinfo / Belegbilderservice / RDS 1.0 (Qonto-native)
   DATEV  <----------- direct push (Orcha-native) ----------------+

Read side (Qonto -> Orcha):

1. Subscribe webhook to transactions.created, transactions.updated, and the 10 cards.* events
2. On transactions.created with operation_type=card: GET /v2/transactions/{id}?includes[]=labels,attachments,vat_details -- pull amount, FX, merchant (via clean_counterparty_name), label, VAT, attachment IDs, card_last_digits
3. Resolve cardholder: lazy-load GET /v2/cards/{card_id} (matched by card_last_digits + bank_account_id) -> holder_id -> GET /v2/memberships/{holder_id} for employee identity
4. For attachments: GET /v2/attachments/{id} -- mirror to Orcha storage (default-safe pending TTL probe)
5. Periodic reconciliation: GET /v2/transactions?updated_at_from=<last_sync> to catch missed webhooks
6. Verify HMAC-SHA256 signature on every webhook with the per-subscription secret

Write side (Orcha -> Qonto):

• Default case: write nothing. DATEV is the source of truth for accounting reference data; Qonto delivers bank data + receipts to DATEV via its native services; Orcha delivers invoices to DATEV directly.
• Optional, advanced: if the customer wants Orcha-held receipts to flow into Qonto (for DATEV-Belegbilderservice forwarding rather than direct Orcha-to-DATEV), use POST /v2/transactions/{id}/attachments. Match by IBAN + amount + date + last-4.
• Optional, advanced: if the customer wants Orcha to drive supplier invoice approval through Qonto, use POST /v2/supplier_invoices/bulk. Uncommon configuration.

When Qonto Integration Makes Sense

1. Customer migrates off Pleo for cards + bank account onto Qonto: All the Pleo gaps that drove the move (realtime, API tier, DATEV depth) are resolved by Qonto, with the trade-off of lighter pre-accounting.
2. Unified spend reporting requirement: Webhooks + full-detail GET + cards endpoint give clean read-side ingestion.
3. DACH SMB / Mittelstand with DATEV-using tax advisor: Qonto's four DATEV integrations are class-leading in the German market.
4. Customer wants to consolidate bank + cards in one tool: Qonto is the only researched vendor that is actually a bank.

What NOT to Build

• Chart-of-accounts / cost-center / tax-code sync to Qonto: Qonto doesn't model these. Not possible, not needed.
• Replacing Qonto's DATEV integrations: They are bank-native and operate at a layer below where Orcha would compete. Let them run.
• Receipt-mirroring loops if customer already has Orcha-direct-to-DATEV: Redundant.

Architecture Decision

Pre-Implementation Verification Needed

Before any engineering commitment:

1. Probe attachment URL TTL in a Qonto sandbox -- see section 7
2. Verify webhook signature header name (X-Qonto-Signature per current docs vs older Qonto-SHA256-Signature -- docs reference both in different pages; confirm by triggering a real webhook in sandbox)
3. Confirm card-tx -> card matching reliability: is card_last_digits + bank_account_id enough to uniquely match a transaction to a specific card on the cards endpoint? Or do we need a stronger key (card_id in the transaction response)? Check the transaction response in sandbox for nested card detail or card_id.
4. Confirm enabled DATEV channels: what is the customer's current DATEV setup -- RZ-Bankinfo only? Plus Belegbilderservice? Plus RDS 1.0? This determines whether Orcha needs to push receipts to Qonto (if Belegbilderservice is on) or directly to DATEV.
5. Confirm MCC absence: if MCC is a hard requirement for spend analytics, verify in sandbox there is genuinely no MCC field in the transaction response. If absent, decide whether Orcha can synthesise category from clean_counterparty_name + label.

Recommendation Summary

For the customer scenario (DATEV + Orcha + Pleo replacement with Qonto for cards): YES, integrate. The read-side path is the cleanest of any vendor researched to date -- real-time webhooks, included API, deep field coverage. The customer should be guided into Qonto's Enterprise plan (EUR 199/mo annual) for the 30-card bundle, plus the Expense & Spend Management add-on if they need approval workflows + mileage to approximate Pleo's depth.

Qonto is materially better than Pleo on the three critical gaps that prompted this evaluation:

1. Realtime: solved with bank-booking-time webhooks (better than Pleo's monthly export jobs)
2. API pricing tier: solved (included on all paid plans, including EUR 9/mo Basic for sole traders)
3. Receipt URLs: likely solved given Qonto's GoBD / DATEV-compliant retention obligation, but needs empirical TTL probe

Qonto is materially worse than Pleo on:

1. Spend pre-coding depth: AI categorisation, dedicated approval matrices, mileage, per-diem all weaker (some add-on-gated)
2. MCC code exposure: absent from the public transaction response (Qonto uses MCC internally for category-restricted cards but doesn't surface raw MCC to integrators)
3. Reference-data write surface: N/A (Qonto isn't an ERP) -- a non-issue when DATEV is source of truth, but a real gap if a customer wanted to sync coding into Qonto

Category-equivalent or banking-with-cards play? Banking-with-cards-and-light-expense-tools. Not a category-equivalent to Pleo in the strict spend-management sense. For customers who want banking + cards + DATEV depth and accept lighter pre-accounting, Qonto is the right answer. For customers who want best-in-class expense management with deep approval matrices and AI coding, Payhawk or Pleo remain better fits.

For the specific customer in scope -- who has Orcha for AP coding and DATEV as the books of record -- Qonto is the right answer, and the Qonto-to-Orcha read-side integration is high-value, low-friction, and uniquely well-supported by the bank-native real-time webhook architecture.

9. Sources

Official Documentation

• Qonto API Reference Introduction (docs.qonto.com)
• Qonto Documentation Index (llms.txt) -- full sitemap, primary research source
• API Endpoints & Reference FAQ
• API Keys & Authentication FAQ
• Rate Limitations
• Idempotent Requests
• API Key Authentication Setup
• Where can I find my API login and secret key? (Support)

OAuth 2.0 & Scopes

• OAuth 2.0 Flow
• Available OAuth Scopes
• Token Endpoint
• OAuth 2.0 Postman Flow (qontoteam public collection)

Endpoint References

• List Transactions
• List Cards
• Upload Attachment to Transaction
• List Attachments for a Transaction
• Create Supplier Invoices (Bulk)
• Save Time with Attachment Automation API (blog)

Webhooks

• Webhook Setup Guide (HMAC-SHA256, 1-second ack, retry policy)
• Supported Webhooks Index
• v1/transactions Webhook
• v1/cards Webhook
• v1/memberships Webhook
• v1/payment-links Webhook
• Onboarding API Webhooks

DATEV Integration (Germany)

• Qonto + DATEV Overview (DE)
• DATEV Online Overview (EN-DE)
• DATEV Marketplace Listing -- Qonto Geschäftskonto
• Which options do I have with Qonto and DATEV? (Support DE)
• Setting up DATEV Rechnungsdatenservice 1.0 with Qonto
• Setting up Qonto + DATEV with RZ-Bankinfo
• DATEV Rechnungsdatenservice 1.0 (Qonto integrations page)
• DATEV Belegbilderservice-Rechnungswesen (Qonto integrations page)
• DATEV Bankdatenservice via PIN/TAN (Qonto integrations page)

iPaaS Connectors

• Qonto on Zapier -- 9 triggers + 3 actions
• Qonto on Make.com -- ~20 modules, transactions/transfers/clients/teams/memberships

Addendum 2026-05-14 -- Defense, Cannibalization, Funding Model

Supplementary research for a German defense-sector customer assessment. Customer priorities have been refined since the original doc: (1) the tool must handle employee credit cards very well, (2) needs a strong mobile receipt-capture app, (3) needs a good API for both READ and WRITE, (4) card funding model: customer prefers NOT prepaid -- i.e. wants a charge/deferred-debit facility, not a pre-funded wallet.

A. Defense-sector posture -- CONFIRMED, verdict unchanged

The prohibited-activities exclusion is confirmed from primary sources and is current. Qonto's help center "What activities are prohibited at Qonto?" page lists, verbatim, "military activities, including the sale of weapons, military vehicles, and their copies" among prohibited activities. This identical wording is published consistently across all of Qonto's regional help domains (help.qonto.com, support-fr, support-de, support-it, support-es, support-be) -- it is a group-wide policy, not a regional artifact. The same prohibited list also covers crypto/blockchain activities (mining, staking, NFT creation/marketing, wallet development, decentralised exchange, unregistered PSAN), among others.

No carve-out, exception process, or pre-clearance path is published. The prohibited-activities list is stated as an absolute exclusion. The adjacent "Can any organization open a Qonto account?" pages note only that "in some cases, additional information may be requested" during KYB -- this is routine onboarding diligence, not a defense-sector exception mechanism. There is no documented appeal, waiver, or sector-specific review route. Any defense-adjacent onboarding would therefore depend entirely on (a) the business not falling within "military activities... sale of weapons, military vehicles" as Qonto's KYB team interprets it, and (b) discretionary KYB judgement -- with no written safety net.

Data hosting / certifications -- still current:

• Data residency: AWS (Paris region) plus Outscale (a French sovereign-cloud provider, SecNumCloud-certified). Both ISO 27001-certified at the infrastructure layer. France-domiciled -- unchanged.
• ISO 27001: Qonto's own ISO 27001 certification remains scoped to its e-invoicing solution only (per the DGFiP requirement for e-invoicing platforms), not the banking platform as a whole. Confirmed still the case. No BSI C5, no SOC 2.
• Qonto SA is ACPR-supervised; French banking-licence application still pending (filed July 2025).

Defense verdict: RED for an arms / weapons / military-vehicle business; AMBER (pre-clearance required, no formal pre-clearance path exists) for defense-adjacent non-arms businesses. Unchanged from the master assessment. The absence of any exception process actually hardens the RED edge: there is no documented mechanism by which an arms business could be onboarded compliantly, so recommending Qonto to a confirmed arms manufacturer would be steering them toward near-certain onboarding refusal or mid-contract offboarding.

B. Cannibalization risk vs Orcha -- CONFIRMED MEDIUM-HIGH, arguably hardening

The master assessment's MEDIUM-HIGH rating holds, and the 2025-2026 evidence pushes it toward the top of that band rather than the bottom.

• Regate acquisition (March 2024) is fully absorbed. Qonto took on Regate's ~150-person team as a dedicated business unit building "financial tools for accountants." Regate continues to ship as "Regate by Qonto" (own apps on iOS/Android/Google Play, own marketplace listings) and the capability is being folded into Qonto's core accounting/accountant proposition -- the public framing is now an "Accountant Hub" inside Qonto that lets accounting firms access client data or integrate their existing software. Regate is no longer pitched as a standalone French product; it is the engine behind Qonto's accountant strategy.
• Qonto's own Supplier Invoices product is materially deeper than the original doc credited. Per Qonto's current product pages it now does: auto-import of invoices from Gmail / cloud storage / "11K+ connected sources," AI/OCR extraction of amounts, VAT and due dates, customizable approval workflows and permissions, scheduled and bulk payments, supplier payment notifications, and automatic matching of invoices to bank transactions. Qonto markets that "85% of AI-generated accounting entries need zero manual work." This is no longer a "shallow bulk-PDF-upload module" -- it is a credible AP-automation product encroaching directly on Orcha's core.
• 2025-2026 trajectory is explicitly toward autonomous accounting. A March 2026 update added multi-page supplier-invoice scanning with automatic full-detail extraction. A March 2025 partnership with agent-automation company Twin deploys autonomous agents that extract transactions, identify missing invoices, retrieve them from supplier websites, and upload them into Qonto. Qonto leadership publicly frames the direction as "autonomous accounting" with AI cash-flow forecasting and automated financing suggestions. Qonto integrates with ~80-80+ accounting tools as of late 2025.
• Germany-specific AP push: no Germany-only AP/invoice announcement was found in the 2025-2026 update log -- the AP product is built France-first. But the supplier-invoices feature set is already live in the general product (it is not gated to France), e-invoicing-mandate features are being shipped market-by-market, and Germany is one of Qonto's four core markets with a dedicated accountant strategy. The German rollout is a "when," not "if."

Net: Qonto is the most AP-ambitious vendor in the researched set. It owns an AP-automation platform (Regate), ships an increasingly capable native Supplier Invoices product with AI extraction + approval workflows + payment + auto-matching, and is openly steering toward "autonomous accounting." Every one of those is in Orcha's lane. Rating: MEDIUM-HIGH, leaning HIGH. Recommendation discipline from the master assessment stands -- integrate with Qonto when a customer already uses it; do not make Qonto a default recommendation.

C. API read/write refresh -- CONFIRMED, still holds

No material change since the 2026-05-13 research:

• READ: Real-time transactions.created / transactions.updated webhooks at bank-booking time; 10 cards.* lifecycle events; GET /v2/transactions, /v2/cards, /v2/memberships, /v2/supplier_invoices, /v2/attachments; labels and vat_details read-only. All transactions visible in the Qonto UI are retrievable via API v2. Confirmed current.
• WRITE: Broad but bank-shaped, not ERP-shaped. Full payment-write surface (POST /v2/sepa/transfers, bulk/recurring/internal/external/international, beneficiaries) -- sensitive scopes (payment.write etc.) require regulatory classification (AIS/PIS) + written justification at OAuth app registration, multi-day approval. Write also covers cards (create/limits/lock/discard/bulk), attachments (POST /v2/transactions/{id}/attachments), supplier invoices (POST /v2/supplier_invoices/bulk), client invoices, memberships, teams, webhooks, expense-request review.
• No reference-data write. Qonto still has no chart-of-accounts / cost-center / tax-code concept; labels remain read-only via the public API. So Orcha can READ transactions/cards/receipts richly and WRITE payments/cards/attachments/invoices -- but cannot sync coding reference data into Qonto, because Qonto does not model it. For this customer (DATEV = books of record) that is a non-issue.
• API still free on all paid plans -- "you can access the API and connect integrations on any Qonto plan." No Advanced-tier gate. Confirmed current.

For the customer's "READ and WRITE" requirement: Qonto passes -- the read side is best-in-class (real-time, bank-grade) and the write side is genuinely broad. The only "write" Orcha cannot do is reference-data sync, which is structurally absent and doesn't matter when DATEV is the ledger.

D. Card funding model + cards/app UX

Funding model -- this is the key new finding, and it is favorable to the customer.

Qonto's standard cards are Mastercard debit cards: each payment is "debited directly from your bank account" -- money must be in the Qonto account. By the customer's definition this is effectively the "prepaid-feel" model they dislike (you must pre-fund the account the cards draw on).

BUT -- as of January 2026 Qonto ships a deferred-debit ("credit mode") card on its Plus and X card tiers. Qonto explicitly calls these deferred debit cards: purchases across a calendar month are aggregated and the full amount debits on the 1st of the following month, and "before the debit date, Qonto covers the transaction amount without interest." Limit up to EUR 15,000/month, 0% interest if settled on time (a daily rate applies only if there are insufficient funds at settlement). This is precisely the charge-card / spend-now-settle-monthly model the customer wants -- it is not a prepaid wallet, and during the month Qonto fronts the money.

Important caveat: deferred debit is not automatic -- it is eligibility-gated. Requirements: business operating 6+ months, Qonto customer 6+ months, HQ in FR/DE/NL/ES, stable consistent revenue, clean payment history, KYC/KYB complete, requested by an owner/admin. A brand-new Qonto customer cannot get deferred-debit cards on day one -- they would start on standard debit (pre-funded) and become eligible later. It is also not a true revolving credit line: it is a ~30-day payment deferral, and sufficient funds must be in the account at the monthly settlement date or late-payment interest applies.

So for the customer's "prefers NOT prepaid" priority: Qonto can satisfy it, but only after a 6-month tenure ramp, and only on Plus/X cards. This is a real but conditional win -- worth flagging explicitly to the customer because it materially affects the migration timeline (they'd spend the first ~6 months on pre-funded debit before the deferred-debit facility opens up).

Cards & app UX, per reviews:

• Aggregate ratings are strong: G2 ~4.7/5 (~154 reviews), Capterra ~4.5/5 (~236 reviews, 89% positive, Ease of Use 4.7), Trustpilot ~5/5 across a very large review base (50k+) though Trustpilot also carries a visible minority of severe complaints about frozen funds / blocked transfers / KYB friction -- a known pattern for EU neobanks.
• Cards product: well-regarded -- physical + virtual + instant one-off virtual cards, per-card adjustable limits, real-time monitoring, category restrictions, instant lock/unlock. Solid for an employee-card use case.
• Mobile receipt capture: functional -- employees photograph receipts, categorise, and build expense reports "in a few taps" in the mobile app, with receipts linked to transactions. But reviewers note the mobile app lacks parity with the web app (inconsistent experience), and some report receipt auto-matching/reconciliation is imperfect (manual photo+categorise+upload still needed in cases). It is a competent capture app, not a class-leader -- Pleo and Payhawk remain stronger on pure expense-app polish, consistent with the original doc's "banking-first, expense tooling lighter" framing.

UX verdict: Cards product is genuinely good and fit for the core employee-card need. Mobile receipt-capture app is good-but-not-best -- adequate, but a step down from a dedicated spend-tool's app, and web/mobile parity gaps are a documented irritant.

Addendum sources

• Qonto -- What activities are prohibited at Qonto? (Help Center)
• Qonto -- What activities are prohibited at Qonto? (support-fr)
• Qonto -- Can any organization open a Qonto account? (support-de)
• Qonto -- Is Qonto certified ISO 27001? (Help Center)
• Qonto -- Business credit card / deferred debit
• Qonto -- Credit card vs debit card vs prepaid card (blog)
• Qonto -- How do I know if I am eligible for deferred debit card payments? (Help Center)
• Qonto -- What's new (product updates)
• Qonto -- Supplier invoices (centralization & dematerialization)
• Contrary Research -- Qonto Business Breakdown
• TechCrunch -- Qonto acquires Regate
• Sifted -- Qonto doubles profits, second year in the black
• Qonto -- Integrations (API on any plan)
• Qonto -- API key authentication (docs)
• G2 -- Qonto reviews
• Capterra -- Qonto reviews
• Trustpilot -- Qonto reviews
• How does Qonto x Zapier work? (Support)
• Qonto n8n community node (n8n forum)

Integrations & Embed

• Qonto Integrations (EN) -- 2000+ integrations claim
• Qonto Integrations (DE)
• Qonto Embed (Banking-as-a-Service) -- partner programme

Pricing & Plans

• Qonto Pricing -- Germany (EN-DE) -- Starter / Basic / Smart / Premium for sole traders
• Qonto Pricing (master)
• Qonto Pricing 2026 (OMR Reviews) -- Essential / Business / Enterprise tier detail
• Qonto Pricing 2026 (G2)
• Qonto on Capterra

Reviews, Comparisons & PSD2

• Qonto vs Pleo Comparator (Qonto, DE) -- explicit "banking-first with integrated expense tools" framing
• Pleo Alternative comparison (Qonto blog, DE)
• Qonto on Open Banking Tracker (PSD2 status)
• Qonto Review 2026 (Heropay)
• How Spending Categories Work for Cards (MCC handling)
• Expense & Spend Management add-on (Support)
• Win back time on expense report management (Qonto product page)
• Expense Reimbursements on Qonto (Support DE)

Third-Party API References

• Qonto API on apitracker.io
• Qonto Python source / dltHub
• Qonto Public API Postman Workspace
• Maesn -- How to Integrate Qonto API
• Maesn -- Qonto API Filtering & Pagination
• Qonto MCP Server (Awesome MCP Servers)