Employee Card Tool Selection — German Defense Customer Assessment

Date: 2026-05-14 (updated) Context: A German defense-sector company currently uses Pleo for employee credit cards, DATEV as their accounting system, and is a (prospective) Orcha customer for AP invoice processing. They want to move off Pleo. Purpose: Decide which employee-card / spend tool to recommend, assessed against the customer's updated priorities and the constraints of being a defense company. Includes a cannibalization analysis for Orcha. Inputs: Per-vendor integration research in this directory, each with a ## Addendum 2026-05-14 section covering defense / cannibalization / funding model. Plus dedicated defense-sector vendor-risk research (2026-05-14).

History note: this file began as a Qonto-vs-Pleo assessment. It has been expanded into a full multi-vendor analysis after the customer's priorities were clarified. Filename retained for continuity.

0. Executive Summary

Recommendation: Payhawk is the leading candidate of a flawed field — but it is NOT yet recommendable. Two blockers surfaced in 2026-05-14 verification must be cleared first (see §4.1, §7).

Payhawk is the only vendor that cleanly satisfies all four of the customer's updated priorities (cards-first quality, strong receipt app, good read and write API, non-prepaid funding) and has the best security posture of the field. But adversarial verification found that (a) one of Payhawk's two EEA card issuers, Paynetics AD, publishes an Acceptable Use Policy that explicitly bans "weapons, firearms, munitions of any sort", and (b) Payhawk imposes 3-year contracts with no exit clause and pushed a 22% mid-contract price increase in 2025. The earlier draft's claim of "no exclusion in the issuers' terms" was factually wrong and has been corrected below.

The updated priorities reshuffled the field hard. Two requirements proved decisive:

• "Very good API for read AND write" eliminates Circula and finway outright — neither has any public API.
• "Preferably not prepaid" eliminates Spendesk, Yokoy, and finway — all prepaid-wallet-only.

Cross-cutting lesson: the defense exclusion hides in the card-issuer layer, not the spend-tool's own terms. Paynetics AD bans weapons and sits under both Payhawk and finway. Future vendor checks must trace the BIN/issuer, not just read the vendor's marketing terms.

1. The Brief — Customer Priorities (Updated)

The customer wants the replacement tool to:

1. Handle employee credit cards very well — this is the core need
2. Have a good mobile app for receipt upload / capture
3. Have a very good API so Orcha can both READ and WRITE data
4. Not be prepaid — they prefer a charge card (spend now, settle monthly from their bank account) or a credit line, not a pre-funded wallet they must top up

And the hard constraint underneath everything: they are a German defense-sector company, so any vendor must be able to legally and willingly onboard them.

Funding model definitions used here:

• Prepaid / pre-funded wallet — money must be loaded onto the platform before cards work (what the customer wants to avoid)
• Charge card — spend now, full balance auto-settled monthly from a linked bank account
• Credit line — provider extends actual revolving credit

2. Full Comparison Matrix

✓ = meets priority · ~ = partial / conditional · ✗ = fails

3. Disqualifications — Reasoning

Circula — no public API. Confirmed again: no developer portal, no OpenAPI spec, no API keys, no iPaaS connectors, no webhooks. Orcha can read nothing and write nothing programmatically. This is painful because Circula is otherwise excellent for this customer — GREEN on defense (German hosting, platform ISO 27001, no industry exclusion), a genuine credit card, and a well-reviewed cards + receipt app. But "very good API for read and write" is a load-bearing requirement, and Circula offers zero. Disqualified on that priority alone.

finway — fails on four axes. No public API, prepaid-only ("not a credit or charge card"), a weak/buggy mobile app, and — worst — HIGH cannibalization: finway is an AP-automation product, there is no cards-only SKU, and the €209/mo plan bundles a direct Orcha competitor. Recommending finway-for-cards means paying to install a competitor in the customer's stack. Disqualified comprehensively.

Qonto — defense exclusion. Qonto's published prohibited-activities policy explicitly names "military activities, including the sale of weapons, military vehicles, and their copies," group-wide, with no carve-out or pre-clearance channel. For an actual arms business this is a hard RED — recommending it steers the customer toward near-certain refusal or offboarding. For a defense-adjacent business it is AMBER, but even then the non-prepaid "credit mode" card is eligibility-gated (≈6 months as a Qonto customer first), so a new customer would run on pre-funded debit during migration. Plus MED-HIGH→HIGH cannibalization. Disqualified for arms; only conditionally viable for defense-adjacent customers who also want banking consolidation.

Spendesk — prepaid, and the write API is unproven. Spendesk is a pre-funded wallet model with no charge-card or credit option anywhere in current materials — a direct miss on priority 4. On top of that, the WRITE side of the API is not publicly enumerated (confirmed writes are limited to card issuance, payment triggers, webhook CRUD), and webhooks are still flagged "experimental." Defense is AMBER with RED-risk: Spendesk's own T&C are silent, but Adyen is woven into the stack and Adyen explicitly bans weapons trading. Disqualified.

Yokoy / Perk — prepaid, and the highest cannibalization risk. Yokoy cards are strictly pre-funded — the customer must bank-transfer funds in before cards work, with no auto-replenish and no charge/credit option. That alone fails priority 4. And Yokoy Invoice is a feature-for-feature description of Orcha's core product — AI line-item extraction, smart coding that learns the team's patterns, VAT/tax compliance, ZUGFeRD/XRechnung, DATEV export — sold under the same brand, one upsell away. Disqualified.

Ramp / Brex — disqualified in earlier research: no DATEV integration of any kind, and no self-serve EU onboarding for a German company in 2026.

4. Shortlist — Detailed

4.1 Payhawk — LEADING CANDIDATE, but blocked pending verification

Payhawk is still the best fit on the customer's four stated priorities. But the 2026-05-14 verification + devil's-advocate pass surfaced two blockers and corrected one factual error in the earlier draft. The honest verdict is "leading candidate of a flawed field, not yet recommendable."

What holds up (verified against primary sources):

• Cards & app (priorities 1–2): G2 4.6/5 (~750+ reviews, G2 Leader + Momentum Leader), Capterra 4.6/5 (92% positive); mobile receipt capture with AI account-code suggestions is a documented core strength. Physical cards ship in ≤5 business days. Minor gripes (scanner accuracy, email-matcher) but clears the bar.
• Read+write API (priority 3): READ covers transactions/expenses, receipts/documents, Fund Accounts (raw bank-statement feed); WRITE covers CRUD on custom fields (cost centers/tax codes), bill creation, webhook CRUD — and Suppliers: create and update is confirmed in the current Help Center API overview (the earlier "no POST /suppliers" caveat was stale — corrected). Real-time webhooks: 22 event types, free on all plans, 15 req/s. Open items: no public OpenAPI spec, sandbox is request-gated, receipt-URL TTL still unverifiable without a probe, and mark-as-exported / CoA-write rest only on Summer-2025 release notes — confirm directly.
• Funding model (priority 4): Payhawk offers a genuine revolving credit line available to EEA companies — monthly billing cycle, utilised credit repaid by the 8th of the following month, gated on €250k turnover + filed Year-1 accounts (max €500k). Cards can switch between prepaid and credit modes post-issuance. Caveats: Payhawk appears to self-underwrite the line (a ~460-person startup mid-fundraise is the counterparty), the help docs are silent on renewal terms and whether Payhawk can cut the line, and the "38-day interest-free" figure is marketing-page language, not in the EEA credit help doc. If Payhawk's risk appetite tightens, the customer falls back to a prepaid wallet — the exact model they rejected.

Defense — AMBER, downgraded to RED-RISK at the issuer layer. (Earlier draft was wrong here.) Payhawk's own Restricted Activities terms carry no defense/arms exclusion — that part holds. But Payhawk's EEA cards run on two issuers: Payhawk Financial Services UAB (Lithuanian EMI) and Paynetics AD (Bulgarian EMI), and Paynetics' published Acceptable Use Policy explicitly bans "weapons, firearms, munitions of any sort" and reserves discretionary termination for "reputational risk." This is corroborated independently (the finway research found the same Paynetics policy). For an actual arms/munitions manufacturer this is a latent RED, not an AMBER. The open question that decides it: can Payhawk issue this customer's cards entirely under its own Lithuanian EMI, keeping Paynetics out of the BIN chain? If yes, the issue is contained; if no, Payhawk is not viable for an arms business. Security posture remains the best of the field — ISO 27001:2022, SOC 1 & 2 Type 2, PCI-DSS L1, DORA, CSA STAR L1, IDW PS 880, German data in Frankfurt — but no BSI C5.

Commercial terms — a newly-surfaced risk. Reviewers (including German customers on GetApp.de) consistently report 3-year contracts with no exit clause, early-termination disputes escalated to debt collection, and a 22% mid-contract price increase pushed in April 2025. Combined with the issuer-offboarding risk this creates a real trap: if Paynetics' KYB review exits the customer in year 2, they are cardless and still contractually bound to Payhawk. The earlier "contained, low-risk change" framing was too comfortable — contract terms (shorter term, exit clause, price-lock) must be negotiated, not assumed.

Cannibalization — MEDIUM-HIGH (upgraded from MEDIUM). The earlier rating assumed Payhawk's AP capability was a separate paid module the customer wouldn't buy. That assumption is now weak: in March 2026 Payhawk shipped AI "Financial Controller" agents that retrieve, code, and submit invoices, going GA later in 2026 "at no additional cost" — i.e. the AP-automation layer is being folded into the core platform, with DATEV export already wired. Recommending Payhawk hands a warm, pre-integrated AP-automation capability into Orcha's own customer. Still not HIGH (no AP acquisition; extraction is shallower than Orcha's GoBD-grade coding), but the trajectory is clearly into Orcha's lane.

4.2 Moss — viable backup, but two real flaws

Strengths: best German data residency of the field (GCP Frankfurt exclusively), own BaFin e-money licence and own Mastercard BIN (no stacked third-party issuer policy), platform-wide ISO 27001, funds safeguarded at Deutsche Bank. Moss Credit is a true revolving credit line (0% interest, 30–60 day terms) — matches priority 4. Cards and the receipt app are a genuine core strength.

Flaw 1 — no card API. Moss's API has improved (suppliers and dimensions now support create/update) but there is no card API at all and no webhooks (polling only). The customer's #1 priority is employee cards, and Orcha's whole reason to integrate is to read card-transaction data — Moss cannot expose that programmatically. This is a functional disqualifier for the specific use case, not just a strategic nit.

Flaw 2 — HIGH cannibalization. Moss is the most directly competitive vendor in the field. Its AP/invoice module is first-class, and the 2026 roadmap moves straight into Orcha's territory: purchase orders, goods-receipt notes (3-way match), and an enhanced DATEV integration with two-way master-data sync. Moss sells the "all-in-one" consolidation pitch — structurally anti-Orcha. Recommending Moss means inviting Orcha's most direct competitor into the customer.

Verdict: only consider Moss if Payhawk fails defense pre-clearance and the customer can live without programmatic card-data access. The cannibalization risk should give Orcha pause regardless.

4.3 Pleo — the incumbent, and the reason to move

Defense — AMBER, with a real catch. No published Acceptable Use Policy or restricted-industries list; the only binding language is a broad "sole discretion" clause in the MSA. No explicit defense exclusion — but no permission either. Latent offboarding risk is real: Pleo's surveillance team closes accounts "outside risk appetite" and calls such decisions "final"; the customer sits on a discretionary clause re-evaluated at every KYB review with no defense carve-out. Being on Pleo today is not a safe harbour — it is arguably a reason to move to a vendor with a clearer stance.

API — the original problem persists. WRITE is strong (full CRUD on vendors, CoA, tags, tax codes). READ is the weak point: expense data is gated behind customer-triggered export jobs in the Pleo UI — the API cannot trigger them, so there is no real-time pull. 24h receipt URLs. API needs the Advanced plan (~€109/mo). This READ limitation is what started the whole evaluation.

Funding & UX: natively pre-funded, but Pleo Overdraft (HSBC-backed revolving line, interest-free if repaid by month-end, confirmed available in Germany) makes it operable as a charge-card-like product. Cards and the receipt app are genuinely good; support quality and the READ API are the weak spots.

Cannibalization — MEDIUM, rising: "Pleo Invoices" is now "Pleo Accounts Payable," and Pleo recently launched a processing-only AP version aimed at lean German finance teams — squarely Orcha's profile and geography.

5. Cannibalization — Cross-Vendor View

The ranking, worst to best for Orcha:

The strategic point. Every modern spend tool now has some AP capability — there is no zero-risk choice. What separates them is structure and trajectory. finway, Moss, Yokoy and Qonto either are AP products or are visibly converging on becoming one. Payhawk was previously rated lower on the assumption its AP was an unbundled module — the March-2026 "Financial Controller" agents at no extra cost weaken that assumption and move Payhawk up. Pleo keeps AP as a still-separable module with shallower extraction than Orcha's. The uncomfortable truth: there is no viable card vendor for this customer that is also clearly safe from a cannibalization standpoint — Payhawk is now MED-HIGH, the alternatives (Moss, Qonto) are HIGH. The choice is least-bad, not safe.

Policy implication: treat "is this vendor structurally an AP competitor?" as a standing filter in vendor recommendations — not just "does it have an API."

6. Recommendation

Payhawk is the leading candidate, but do NOT recommend it to the customer yet. Three things must be cleared first — and the first two are potential hard stops, not formalities:

Blockers to clear before recommending (see §7):

1. Issuer / BIN question. Confirm in writing whether Payhawk can issue this customer's cards entirely under its own Lithuanian EMI, keeping Paynetics AD — whose AUP bans "weapons, firearms, munitions of any sort" — out of the chain. If Paynetics is unavoidable and the customer is an arms/munitions business, Payhawk is not viable.
2. Contract terms. The 3-year lock-in + no exit clause + 22% mid-contract price-hike precedent must be renegotiated (shorter term, exit clause, price-lock) — or the customer goes in fully eyes-open to the trap.
3. What the customer actually does. Arms/munitions manufacturing makes blocker 1 severe; defense-adjacent software/services may make the Paynetics AUP irrelevant. This single fact gates the whole recommendation.

Why Payhawk still leads despite the blockers:

• It is the only vendor that satisfies all four customer priorities — genuine credit line, real-time read + write API (supplier-write now confirmed), strong cards, strong receipt app.
• Best security posture of the field — ISO 27001 + SOC 1/2 Type 2 + DORA + Frankfurt hosting. (BSI C5 is the gap — no vendor in the field holds it.)
• The alternatives are worse: Moss (HIGH cannibalization, no card API), Qonto (RED for arms), staying on Pleo (offboarding risk + weak READ API). There is no clean option — Payhawk is least-bad, not safe.

If Payhawk fails blocker 1 or 2: do not fall through to a weak alternative by default. Escalate — the realistic outcomes are (a) negotiate Payhawk onto its own EMI + acceptable contract terms, (b) stay on Pleo and accept the offboarding/READ-API risk, or (c) widen the search to a different category of provider (e.g. a German Hausbank card programme) outside this spend-tool field.

Do not recommend Qonto, Spendesk, Yokoy, Circula, or finway for this customer, for the reasons in §3.

7. Open Questions / To Verify Before Acting

Hard gates (a "wrong" answer changes the recommendation):

1. What does the customer actually do — arms/weapons/munitions/military-vehicle manufacturing vs defense-adjacent (software, components, services, logistics)? The highest-leverage unknown; sets how hard every defense gate bites.
2. Payhawk issuer / BIN routing — get written confirmation whether the customer's cards can be issued solely under Payhawk Financial Services UAB (Lithuanian EMI), with Paynetics AD excluded from the chain. Paynetics' AUP bans weapons/firearms/munitions. If Paynetics is unavoidable + customer is an arms business → Payhawk not viable.
3. Payhawk defense pre-clearance — written confirmation from Payhawk compliance that they will onboard and retain this customer. Not a formality given the issuer-layer exclusion.
4. Payhawk contract terms — confirm whether the 3-year lock-in, exit clause, and price-lock can be renegotiated. The April-2025 22% mid-contract hike is documented precedent.
5. BSI C5 — does the customer's own security mandate require it? If yes, no vendor in the field holds it — reshapes the shortlist, may force a different provider category.

Verification items (unlikely to change the recommendation, but confirm before build): 6. Payhawk credit-line terms — renewal conditions, what happens if turnover dips, whether Payhawk can unilaterally cut the line, and whether the credit sits on Payhawk's balance sheet or a partner's. Docs are currently silent. 7. Payhawk API gaps — confirm mark-as-exported and CoA-write endpoints still exist (currently only in Summer-2025 release notes); note there is no public OpenAPI spec and the sandbox is request-gated. 8. Payhawk receipt-URL TTL — empirical sandbox probe (carried over from original research). 9. Payhawk DATEV edge cases — documented limitations: image compression on export, exported expenses can't be corrected (manual DATEV delete), no KOST1/KOST2 auto-pull, double FX translation when card currency ≠ DATEV base currency, line-item-sum mismatches hard-fail the export. Scope these against the customer's DATEV setup. 10. Payhawk Lithuanian EMI licence number — cited inconsistently across sources (LB002199 / LB002200 / "No. 95"); confirm before putting in writing to the customer.

Status-quo risk to surface to the customer: 11. Pleo offboarding exposure — their current setup sits on a broad discretionary clause with no defense carve-out. This is a risk on staying put, not just on moving.

8. Sources & Linked Research

Per-vendor integration research (each now carries a ## Addendum 2026-05-14 section):

• Payhawk
• Spendesk
• Yokoy
• Circula
• Qonto
• finway
• Pleo
• Moss
• Ramp · Brex (disqualified earlier — no DATEV, no EU onboarding)

Defense-sector context:

• Qonto — prohibited activities
• Defense financing & EU rearmament — ECOFACT
• Banking on Defence — European Policy Centre