Spendesk API Integration Research

Date: 2026-05-13 Product: Spendesk (spendesk.com) -- Spend Management Platform, Paris (with Berlin and Hamburg offices) Purpose: Evaluate Spendesk's API capabilities for Orcha integration -- specifically for a German customer evaluating Spendesk as a Pleo alternative for employee credit cards while continuing to use Orcha for AP invoices and DATEV for accounting.

Important Context: What Spendesk Actually Is

Spendesk is NOT an ERP or accounting system. Like Pleo, Payhawk, and Moss, it is a spend management platform that handles:

• Corporate credit cards (physical + virtual, Mastercard-based)
• Supplier invoice capture & AP workflows ("Accounts Payable" add-on module)
• Employee expense claims & reimbursements
• Pre-accounting (AI-powered expense categorization on Premium tier)
• Purchase-to-pay (PO management as a separate add-on)
• Approval flows + budgets

Spendesk sits upstream of the ERP -- it captures, codes, and approves expenses, then exports pre-accounted data to the customer's actual accounting/ERP system (DATEV, NetSuite, Xero, QuickBooks, Sage 100, Exact Online, Business Central, Odoo, ACD).

Implication for Orcha: Spendesk is a peer (spend management) layer, not a target system to push invoices into. For the customer scenario in scope (Orcha = AP, DATEV = accounting, Spendesk = card programme), the integration question is narrower:

1. Can Orcha read card transaction data from Spendesk to provide unified spend analytics alongside its invoice corpus?
2. Can Orcha write reference data (chart of accounts, cost centers, tax codes, suppliers) into Spendesk so the customer's card-coding stays consistent with the AP coding Orcha already drives?

The answer to (1) is YES with caveats around webhook maturity. The answer to (2) is technically YES but operationally heavy because of two gating issues: (a) the Spendesk-DATEV integration is one-way export only -- master data does NOT flow DATEV->Spendesk natively, so Orcha (or someone) has to actively keep Spendesk in sync; (b) API access is gated to the Premium plan or higher, which is the highest published tier short of Enterprise. See section 7.

1. Summary -- Capability Matrix

Overall assessment: Spendesk has a real, OAuth2-backed public API with a coherent data model around Payables + Settlements (the same dual-entry abstraction the platform uses internally). For the read-side use case (Orcha pulls card-transaction data for unified spend analytics), the API is sufficient -- payables, settlements, attachments, suppliers, cost centers, analytical fields, and expense categories are all retrievable, and webhooks (still tagged experimental) exist for real-time notification with HMAC SHA256 signature verification. However, three gaps significantly limit the write-side use case (Orcha pushes reference data into Spendesk):

1. The DATEV integration is one-way export only. Unlike Payhawk's deep bidirectional DATEV Cloud Services integration, Spendesk's DATEV connection uses Rechnungsdatenservice 1.0 strictly for outbound transmission. The Spendesk docs are explicit: "The integration does not support the import of your master data (suppliers, accounts, VAT rates and cost dimensions) into Spendesk." So Spendesk does NOT auto-acquire DATEV master data the way Payhawk does. Reference data must be entered manually in Spendesk, imported via CSV, or pushed via API.

2. API write endpoints for reference data are not enumerated in the public developer portal as we can scrape it. The public docs explicitly list the API as supporting retrieval of suppliers, cost centers, expense categories, and analytical fields; they confirm API credentials can "retrieve and edit" data according to granted permissions, but specific POST /suppliers or POST /cost-centers endpoints are not visible from the public portal. The developer portal is a JS-rendered SPA (ReadMe.com hosted) and WebFetch returns only the chrome -- the actual reference content requires interactive browsing.

3. API access is gated to the Premium plan. Premium is Spendesk's second-highest published tier (Essentials -> Growth -> Scale -> Premium -> Enterprise). The customer must either already be on Premium for AI categorization / NetSuite / Workday / SAP integrations, or upgrade specifically for API access. Pricing is quote-based; no public price point.

Net: Spendesk is materially worse than Payhawk on both critical fronts for this customer (DATEV master-data import + API tier gating), and comparable to or slightly better than Pleo on real-time webhook support, but with a tighter access gate (Premium tier vs Pleo's Advanced).

2. API Landscape

API Layers

Honest gap: The developer portal is a JS-rendered SPA built on ReadMe.com. Public WebFetch cannot retrieve endpoint-level content; pages return only navigation and footer. All endpoint-level details in this document come from (a) public help-center articles, (b) the Spendesk blog post on their API, (c) third-party indexing services like apitracker.io, and (d) Google search snippets that surface fragments of authenticated portal content. Anything below marked "UNCLEAR" needs verification by an authenticated probe against a real Spendesk Premium account.

Authentication

OAuth 2.0 client credentials with scoped tokens places Spendesk between Payhawk (static API keys, no scopes) and Pleo (OAuth 2.0 client credentials with scopes). The 1-year max key TTL is more aggressive than either competitor's default and is a security plus.

Rate Limits

• 250 requests per minute per OAuth2 partner (= ~4.17 requests per second sustained)
• 5 concurrent requests at any given time per API consumer
• Reported via response headers (header names not confirmed from public docs)
• Standard HTTP 429 on exceeded

For comparison:

• Pleo: 600/min = 10 req/s sustained, no concurrency cap publicly stated
• Payhawk: 15 req/s sustained, no concurrency cap publicly stated
• Spendesk: 4.17 req/s sustained, hard cap of 5 concurrent

Spendesk is meaningfully more restrictive than both -- the 5-concurrent cap in particular forces serial processing for bulk syncs and is the lowest in the cohort. For Orcha's incremental sync + webhook-driven reconciliation pattern this is workable, but a full bulk replay on a large account would need careful pagination + serial-mode pipelining.

API Categories

Confirmed via help center + Spendesk's own blog + apitracker.io listing + search snippets from authenticated portal pages:

Experimental Webhooks Status

The webhook system is labeled "experimental" on the developer portal. To use webhooks, you currently must:

1. Request access to experimental features
2. Create a dedicated API key with experimental scopes
3. POST /webhooks to subscribe

Each webhook is bound to one company ID and one or more events. Events arrive with x-spendesk-webhook-signature header containing HMAC SHA256 of the payload, computed with the secret provided at subscription creation (or auto-generated). Webhook secret is recommended at >=32 chars and is displayed once only.

Implication for Orcha: webhook support is real but flagged with the standard "may change" caveat. The Payhawk equivalent (expense.created etc.) is NOT marked experimental and is part of the GA contract; this is a difference in maturity to call out to engineering when prioritizing.

Versioning / Deprecation

No public deprecation schedule surfaced. The Spendesk API was first publicly announced as a "community-designed API" (per Finextra coverage; exact launch date not retrievable from public sources during this research). No explicit version number in the base URL was confirmed.

3. Write Capability Verification

Confidence: LOW-MEDIUM. This is the biggest unverified area in this research. Public sources confirm that:

• API credentials can "retrieve and edit information" according to granted permissions (Spendesk help center, "Build a native integration")
• The use cases pushed by Spendesk's marketing are heavily READ-oriented (transaction retrieval, expense claims, vendor and invoice management, accounting exports)
• WRITE use cases that ARE explicitly named: programmatic virtual card provisioning, automated supplier payments (i.e., paying out)
• Webhook subscription management is full CRUD (POST /webhooks, list, presumably PUT/DELETE)

But specific POST /suppliers, POST /cost-centers, POST /expense-categories, or POST /analytical-fields endpoints are NOT enumerated in any public source we can reach. The reference docs are gated behind a JS SPA.

Confirmed Write Endpoints / Operations

Partial / Workaround Write

Key Limitations

• No invoice push to Spendesk via API. Invoices enter via:
  • Email mailbox (forwarded to Spendesk-provided address)
  • UI / mobile app upload
  • OCR processes the document and creates a payable
• No approval trigger / approve / reject via API. Workflow read-only.
• No public CRUD endpoints for reference data confirmed. Largest gap vs Pleo (which has full CRUD for vendors, accounts, tags, tax codes).
• DATEV does not feed master data into Spendesk. Reference data lives in Spendesk only.

4. iPaaS & Middleware Findings

Tray.io is the only iPaaS path identified, and the connector's actual feature surface could not be enumerated from the public web (404 on the how-it-works detail page). For most no-code orchestration needs, customers will fall back to:

• Direct REST API integration via OAuth 2.0
• Custom HTTP-based connectors in Make.com / n8n / Workato
• Tray.io (if the customer is already on Tray)

This is a notable downgrade vs both Pleo (Zapier with 4 triggers + 8 actions) and Payhawk (Workato with 2 triggers + 3 actions + Make community module).

5. Alternative Channels

DATEV Integration (Native)

This is Spendesk's weakest area for the customer in scope, and the single largest contrast vs Payhawk.

Implication for Orcha-in-customer-stack: Spendesk's DATEV integration is a one-way batch push of pre-coded entries. The customer's accounting reference data (CoA / Sachkonten, KOST1/KOST2, BU codes) lives in DATEV but does NOT flow into Spendesk automatically. This means the customer (or Orcha, if Orcha is the master) must keep Spendesk's expense categories, cost centers, and analytical fields aligned with DATEV manually -- which is exactly the problem the customer is presumably trying to solve. This is the defining structural difference vs Payhawk, where DATEV CoA + tax + KOST flow back into Payhawk natively via DATEV Cloud Services bidirectional sync.

Native ERP/Accounting Integrations

Confirmed via spendesk.com/integrations:

The DATEV connector is conspicuously the only "one-way" connector in this list, while NetSuite, Xero, QuickBooks, etc., do support master-data import into Spendesk. For a DACH-focused customer, this is the wrong asymmetry.

HRIS Integrations (Scale & Premium tiers)

Lucca, HiBob, BambooHR, Personio, Workday, CharlieHR, Payfit, Deel, SAP SuccessFactors, Sage HR, Remote, Officient, BreatheHR, Cezanne HR, Eurecia, Factorial, Humaans, Kenjo. Workday + SAP SuccessFactors require Premium tier.

Webhooks

CSV Exports

• DATEV CSV templates for payments / reimbursements / FX-ATM fees / wallet loads (the data NOT covered by RDS 1.0)
• Generic Bookkeep > Export workflows for non-native ERPs
• Custom CSV builder available

6. Licensing & Access Requirements

API Access by Plan

Per the Spendesk help center: "Access requires either a Premium or Enterprise pricing plan." API features are unavailable for accounts on Essentials, Growth, or Scale.

The four published tiers (per current Spendesk help center "What's included in my subscription plan"):

For comparison:

• Pleo: API on Advanced (mid-tier) -- $109/mo+
• Payhawk: API on entry-level Cards & Expenses module -- $449/mo base, included on every plan
• Spendesk: API on Premium (second-highest tier) -- pricing quote-only

Spendesk has the most restrictive API gating in the cohort. A customer who would have only needed Essentials or Scale must upgrade to Premium specifically for API access (with the side benefits of AI categorization, NetSuite, Workday, SAP HR, and SAML SSO).

Pricing Model

Honest gap: Spendesk does NOT publish their tier prices publicly. Third-party sources (G2, Capterra, GetApp) likewise do not list firm prices. For the customer's evaluation, an actual quote is required. Anecdotally, Spendesk has historically been at the higher end of the spend-management market vs Pleo / Payhawk / Moss.

Customer Setup Checklist

1. Customer needs Premium or Enterprise plan (verify with Spendesk sales).
2. Account Owner role required to provision API credentials.
3. Contact Spendesk sales/support to authorize API access (per help center: "Contact Spendesk sales team or customer support for authorization").
4. Settings > Integrations > API access management > Create new key.
5. Set descriptive name + expiration (max 1 year, shorter recommended).
6. Select specific permission scopes per resource (settlement:read, payable:read, etc.).
7. Capture client secret -- shown once only, store in vault.
8. For webhooks: separately request access to experimental features + create dedicated API key with experimental scopes.
9. (Optional) Set up DATEV DUO export connection -- noting it is one-way push, NOT a master-data sync.

7. Orcha-Specific Deep Dive

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

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

Spendesk and Orcha have overlapping functionality in the AP module of Spendesk -- but the customer scenario in scope assumes Spendesk's Accounts Payable module is not the primary AP system (Orcha is). The split is clean:

So with Spendesk's AP module not in use by this customer, Spendesk's responsibility is cards + reimbursements + their export to DATEV, and Orcha's responsibility is AP invoices + their export to DATEV. Both streams converge in DATEV.

Integration Scenarios for the Customer

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

• Feasibility: MEDIUM-HIGH, conditional on:
  • Customer on Premium plan
  • Webhook system being stable enough despite "experimental" label
  • Receipt attachment access mechanics being verified
• Subscribe webhooks to payable.created and settlement.created -> Orcha endpoint
• On event, GET /payables/{id} and GET /settlements/{id} for full detail
• For receipts, GET payable-attachments (mechanism: stream vs URL TBD by probe)
• Optionally pull bank fees + wallet loads + wallet summary endpoints
• HMAC SHA256 signature verification using webhook secret
• No invoice push back to Spendesk needed

Scenario B: Orcha writes reference data INTO Spendesk for consistent coding (SECONDARY USE CASE)

• Feasibility: LOW-MEDIUM
• This is structurally harder than for Payhawk because Spendesk's DATEV integration does NOT auto-sync master data from DATEV. So if the customer wants Spendesk-coded card transactions to match their DATEV CoA, someone has to push that mapping.
• If write endpoints exist for cost centers / expense categories / analytical fields (unclear from public docs but plausible given "retrieve and edit" language), Orcha could push DATEV reference data into Spendesk on a schedule.
• For suppliers, the fallback is CSV bulk import via UI -- not great for automation.
• Bottom line: this scenario requires either (a) authenticated portal verification that write endpoints exist, OR (b) acceptance of CSV-import workflows for the reference-data sync.

Scenario C: Customer migrates AP from Orcha to Spendesk's AP module

• NOT relevant for this customer scenario. Customer keeps Orcha for AP.

Scenario D: Orcha pushes invoices into Spendesk

• NOT POSSIBLE via API -- no POST /invoices endpoint. Email-to-mailbox or UI upload are the only paths. Irrelevant since customer doesn't need this.

Key API Differences vs Pleo and Payhawk

Spendesk's one positive differentiator is programmatic virtual card issuance -- explicitly listed as a use case in the Spendesk blog. This is a capability neither Pleo nor Payhawk advertise as a public API surface. Not relevant to the customer's scenario in scope, but worth noting.

Receipt Attachment Access -- Action Required

The single most important unverified mechanic for the customer scenario is how payable-attachments actually returns receipt data: stream-via-API (good -- no TTL concerns), or signed URL (which would inherit the Pleo-style TTL question).

Recommendation:

1. Before committing engineering effort, run an authenticated probe against a Spendesk Premium sandbox: fetch a payable, list its attachments, inspect the response schema, attempt fetch of the actual binary, and -- if there's a URL field rather than a stream -- test URL persistence at T+1h, T+24h, T+7d.
2. If stream-based (likely): receipt access is clean; no mirroring required for TTL reasons (though mirroring may still be desirable for resilience).
3. If signed-URL based with short TTL: mirror to Orcha storage at webhook time.

Orcha Integration Capability Summary

8. Recommended Path Forward

Assessment: Spendesk is a Viable but Significantly Weaker Pleo Replacement Than Payhawk for This Customer

For a German company evaluating alternatives to Pleo specifically for cards while keeping Orcha for AP and DATEV for accounting, Spendesk solves the realtime gap (with caveats) but introduces three new structural problems Payhawk does not have:

1. API tier gating to Premium is more restrictive than Pleo's Advanced gating. Customer must verify with Spendesk sales whether their volume/spend justifies the upgrade.
2. DATEV master-data import is not supported. Reference data must flow Orcha -> Spendesk manually or via API (if write endpoints exist), not via the native DATEV connector.
3. Webhooks are marked "experimental." Real-time read-side architecture is technically possible but carries contract-stability risk.

The one Spendesk-positive note worth flagging to the customer is the OAuth 2.0 auth model with scoped tokens and 1-year-max credential TTL, which is materially better security hygiene than Payhawk's static long-lived API keys.

Recommended Architecture (if customer proceeds with Spendesk)

[Card transactions]            [Vendor invoices]
       |                              |
       v                              v
   Spendesk -- experimental webhook -> Orcha (read-side: unified spend analytics)
       |                              |
       v                              v
     DATEV  <----- shared books ----- DATEV
   (one-way export)                 (direct integration)

Read side (Spendesk -> Orcha):

1. Subscribe webhooks to payable.created and settlement.created (plus any others surfaced during portal verification)
2. Implement HMAC SHA256 signature verification with stored webhook secret
3. On event, GET /payables/{id} + GET /settlements/{id} for full detail
4. Retrieve payable attachments via the attachments endpoint
5. Mirror documents to Orcha storage at webhook time (default-safe until attachment access mechanics are verified)
6. Periodic GET /payables?reviewedAt>... reconciliation sweep against missed webhooks (cadence calibrated to 4 req/s rate limit + 5-concurrent cap)
7. Stay alert to "experimental" status changes

Write side (Orcha -> Spendesk):

1. First, verify whether public/partner write endpoints exist for suppliers, expense categories, cost centers, analytical fields. This is the single highest-leverage open question. Status as of this research: unclear from public docs.
2. If write endpoints exist: push reference data from Orcha (DATEV-aligned) on a schedule. Avoid bulk replays inside a single minute due to rate-limit/concurrency caps.
3. If write endpoints do NOT exist: fall back to CSV bulk import via Spendesk UI for suppliers (semi-automated; not great); manual UI configuration for CoA / cost centers / tax codes. This is a significant operational drag and is the main reason to prefer Payhawk for this customer.
4. Do NOT rely on the DATEV connector to fill the gap -- it does not import master data into Spendesk.

When Spendesk Integration Makes Sense

1. Customer is already on Premium for other reasons (NetSuite integration, AI categorization, Workday/SAP HR, SAML SSO): adding API access is a no-cost option.
2. Customer is French-German with strong Paris HQ presence: Spendesk has deeper Paris-side enterprise account management than Pleo/Payhawk.
3. Customer needs programmatic virtual card issuance: Spendesk uniquely exposes this; Pleo and Payhawk do not.

When Spendesk Integration Is the Wrong Choice

1. Customer is purely DACH-focused and wants the deepest DATEV experience: Payhawk wins decisively.
2. Customer wants API access on the entry-level plan: only Payhawk offers this.
3. Customer needs documented full-CRUD write APIs for reference data: Pleo is the only one of the three with publicly enumerated first-class write endpoints for vendors, accounts, tags, tax codes.

What NOT to Build

• Invoice push to Spendesk: Not possible via API; not needed for this customer
• Approval workflow automation in Spendesk: Not API-accessible
• Replacing Spendesk's DATEV connector: Already exists (though weaker than Payhawk's). Better to use it as-is for cards/expenses, push AP-related entries directly from Orcha as today.

Architecture Decision

Pre-Implementation Verification Needed

Before any engineering commitment, the Orcha team should obtain access to a Spendesk Premium sandbox and answer:

1. Webhook event catalog: full enumeration beyond payable.created / settlement.created. Are there transaction.created, card.*, member.*, supplier.* events? Are they all real-time or do some still batch?
2. Webhook stability: is the "experimental" label still in place? If yes, what's Spendesk's contract-stability commitment? Get this in writing from Spendesk technical contact.
3. Attachment access mechanic: stream-via-API or signed URL? If signed URL, what's the TTL?
4. Write endpoint coverage: confirm or refute presence of POST /suppliers, POST /expense-categories, POST /cost-centers, POST /analytical-fields, PUT /analytical-fields/{id}/values. This single answer determines whether scenario B above is feasible.
5. Approver/workflow exposure on payables: is approver name + status + approval timestamp surfaced on the payable response? Confirm field-level coverage.
6. Card metadata on settlements: is the issuing card's last-4 / virtual-vs-physical flag exposed on the settlement payload?
7. Rate-limit headers: what's the exact header name and burst behaviour?
8. Sandbox URL: production vs sandbox separation, environment switching.
9. Premium plan pricing: actual quote for the customer's expected card volume.

Recommendation Summary

For the customer scenario (DATEV + Orcha + Pleo replacement with Spendesk for cards): conditional YES, with a strong preference to evaluate Payhawk first. Spendesk's read-side path is workable -- real-time webhooks exist, the data model around Payables + Settlements is coherent, and the field coverage is likely adequate. But the write-side path is unverified, the DATEV master-data direction is wrong for this customer, and the API access gating is the strictest in the cohort.

Spendesk vs Pleo on the three critical gaps that prompted the evaluation:

1. Realtime: Better than Pleo (real-time webhooks) -- but worse than Payhawk (Spendesk's webhooks are still "experimental"; Payhawk's are GA)
2. API pricing tier: Worse than Pleo. Pleo gates to Advanced (mid-tier); Spendesk gates to Premium (second-highest). Payhawk has no tier gating.
3. Receipt URLs: Likely better than Pleo's 24h expiry because Spendesk appears to expose attachments via an endpoint rather than a pre-signed URL, but the mechanic must be verified by authenticated probe.

If Payhawk is on the customer's shortlist, the recommendation is Payhawk over Spendesk for this specific scenario. If only Spendesk and Pleo are in scope, Spendesk is marginally preferable on the realtime axis but materially worse on the tier-pricing and DATEV-master-data axes.

9. Sources

Official Documentation

• Spendesk Developer Portal -- JS-rendered SPA on ReadMe.com; partial accessibility from public web
• Spendesk API Introduction
• Spendesk Public API on Postman (Spendesk PDE SAS workspace)
• Spendesk Quickstart
• Using Webhooks (experimental)
• What is Spend Data?
• Get Settlements
• Rate Limiting
• Spendesk API on apitracker.io
• Spendesk GitHub organization -- mostly forks; no official SDK

Help Center -- API & Credentials

• Build a native integration using Spendesk API / Create API credentials -- Premium/Enterprise plan requirement, OAuth credentials creation, supported endpoints summary
• What's included in my subscription plan -- Essentials / Growth / Scale / Premium tier breakdown

Help Center -- DATEV

• Overview of DATEV UO native integration -- One-way export, master-data limitation explicitly stated
• Prerequisites to setup the integration with DATEV UO -- RDS 1.0, "Erweitert" mode, permissions configuration
• Export expenses and receipts to DATEV UO -- Manual batch cadence, payables vs CSV-only flows
• Introduction to DATEV Unternehmen Online (Bookkeep 2.0)
• Spendesk on DATEV Marketplace -- Partner since August 2020; RDS 1.0 XML interface

Help Center -- Reference Data & Fields

• Expense Categories and Custom Fields on Spendesk
• Procurement: Analytical Fields
• Split payables across Cost Centers, Expense Categories and Analytical Fields

Help Center -- NetSuite Comparison Reference

• NetSuite native integration: import NetSuite accounts -- Confirms that for NetSuite (but not DATEV), Spendesk imports master data
• NetSuite native integration: connect your Spendesk account to NetSuite
• FAQ: NetSuite Integration and troubleshooting

Help Center -- Other

• Add your supplier accounts and review your invoices
• Spendesk's native HR tools integrations
• Download your payments and/or receipts
• What kind of cards do we use?

Spendesk Marketing & Blog

• The key benefits of a public API for spend management tools -- Confirms OAuth2, real-time webhooks, sandbox environment, programmatic virtual card provisioning
• Spendesk debuts community-designed API (Finextra) -- Press coverage of API launch
• Spendesk Integrations -- ERP / accounting / HR catalog
• Spendesk Pricing -- Quote-only; modular pricing description
• Invoice Processing and Accounts Payable Tools
• Spendesk Virtual Debit Cards
• Spendesk Physical Cards glossary

iPaaS Connectors

• Spendesk on Tray.io -- Connector exists but how-it-works detail page returned 404 during research

Reviews & Comparisons

• Pleo vs Spendesk (Software Advice 2026)
• Spendesk vs Pleo (Capterra Germany 2026)
• Spendesk vs Pleo (GetApp 2026)
• Spendesk vs Pleo: lequel choisir en 2026
• Pleo vs Spendesk (SaaS Battle 2026)
• Spendesk 2026 Pricing & Features (GetApp)
• Spendesk Pricing (G2 2026)
• Spendesk Features (G2)
• Spendesk Alternatives (Capterra)
• Die besten Spendesk Alternativen 2026 (OMR Reviews)
• Die 6 besten Tools mit DATEV-Anbindung 2026 (Pleo Blog)
• Spendesk Software Pricing 2025 (Vendr buyer guide)
• Spendesk Pricing & Plans 2023 (Upendra Varma)

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

Context update: The customer is a German defense-sector company (Pleo for cards, DATEV for accounting, Orcha for AP). Updated priorities: (1) the tool must handle employee credit cards very well as the core need; (2) a strong mobile receipt-capture app; (3) a good API for Orcha to both READ and WRITE; (4) card funding model — the customer prefers NOT prepaid (wants a charge card / monthly settlement or credit line, not a top-up wallet). This addendum covers four supplementary questions; methodology and comparison-table format follow the Qonto-vs-Pleo master assessment §1.

1. Defense-Sector Posture — Verdict: AMBER (leaning RED for an actual arms manufacturer)

Verdict: AMBER, leaning RED for an actual arms/weapons/military-goods manufacturer. Spendesk's own T&C are silent on defense (silence ≠ permission — same posture as Pleo). The EUR issuer SFS SAS has no published exclusion but a discretionary, ACPR-supervised KYB process. The complication unique to Spendesk: Adyen is woven into the stack (GBP issuer + BaaS partner) and Adyen has an explicit absolute ban on weapons/military arms trade. If the customer is a true arms manufacturer, that Adyen exposure plus the unpublished SFS stance makes this RED-risk; if defense-adjacent (software, components, services), AMBER with mandatory written pre-clearance from Spendesk/SFS compliance before any recommendation. ISO 27001:2022 is a genuine plus over both Qonto and Pleo; the absence of BSI C5 remains a gap if the customer's security function requires it.

2. Cannibalization Risk vs Orcha — Rating: MEDIUM-HIGH (and rising)

Spendesk is materially more AP-encroaching than Pleo or Qonto, and the trend line is clearly toward Orcha's territory:

• Spendesk runs a dedicated Accounts Payable / invoice-management module that does AI invoice data extraction (supplier, amount, dates, purchase details), duplicate detection, three-way matching (PO ↔ delivery note ↔ invoice, marketed as cutting manual review "up to 80%"), approval flows, and payment execution in 100+ countries. (Spendesk invoice management)
• 2025 release cadence is pointed straight at AP automation: Summer 2025 added three-way matching, delivery-note tracking, AI quote→PO processing, credit-note routing, and Wise-backed international payments in 30+ currencies. (Summer updates 2025)
• E-invoicing compliance is a stated roadmap priority — Spendesk is building toward the France Sept-2026 and Belgium Jan-2026 e-invoicing mandates, positioning itself as the system that "centralizes all invoices." That is a direct move into the compliance/coding layer Orcha sells.
• Spendesk explicitly markets a standalone "Accounts Payable Software" page and "Invoice Automation Software" page — it is selling AP as a product, not just a card add-on.

The one mitigating factor: Spendesk's invoice extraction is shallow on the dimensions Orcha is deep — no evidence of line-item extraction, GoBD-grade German tax-code coding, or native bidirectional DATEV master-data sync (its DATEV connector remains one-way export only, per §5 of the main doc). Orcha's moat (deep extraction + tax compliance + GoBD coding) is intact today. But unlike Pleo (flat, stays in its lane) or Qonto (rising via the Regate acquisition but banking-first), Spendesk is organically building AP automation as a first-class product and shipping into it every release. That makes it MEDIUM-HIGH: every customer who adopts Spendesk's AP module is a customer being actively taught they may not need a separate AP tool.

3. API Read/Write Refresh — No material change since 2026-05-13

Re-verification confirms the original findings stand:

• READ — confirmed and broad. The API retrieves: payables, payable attachments, settlements, bank fees, wallet loads/summary, members, suppliers, analytical fields + values, cost centers, expense categories. For Orcha's primary use case (pull card-transaction + receipt data for unified spend analytics) the read surface is sufficient. (Build a native integration)
• WRITE — still unverified from public sources. No public source enumerates POST/PUT endpoints for suppliers, cost centers, expense categories, or analytical fields. The help center lists only retrieval. Confirmed writes remain limited to programmatic card issuance, supplier-payment triggers, and webhook-subscription CRUD. For the customer's "Orcha must WRITE" requirement, this is the key open risk — write-back of DATEV-aligned reference data is unproven and may fall back to CSV import. Requires an authenticated Premium-sandbox probe to resolve.
• Webhooks — still "experimental." The developer-portal page is still titled "Using webhooks (experimental)" (last updated ~8 months ago); access still requires requesting experimental-feature access from a CSM and creating an API key with experimental scopes. HMAC SHA256 signing unchanged. No promotion to GA.
• API tier gating — still Premium+. API access still requires the Premium or Enterprise plan (second-highest published tier). No change.

Net: nothing has improved on the write side or the webhook-maturity side since the original research. The READ path is solid; the WRITE path the customer now explicitly needs is the single biggest unverified gap.

4. Card Funding Model + Cards/App UX

Funding model — PREPAID. This is a direct conflict with the customer's stated preference. Spendesk operates a pre-funded wallet model: the company loads funds into a central Spendesk wallet, and physical/virtual cards are topped up from that balance ("you cannot spend more than what is on the card/entity's account"). Cards reload automatically on the 1st of the month or via on-demand top-up. Wallet transfers take 1–3 business days to appear. Reviewers explicitly flag the downside the customer is trying to avoid: "Each card's limit must be backed by pre-loaded funds, effectively tying up working capital and potentially impacting cash flow." The Summer-2025 "flexible payment features" are Google Pay + multi-use virtual cards — not a funding-model change; no charge card, no deferred/monthly settlement, no credit line was found anywhere in current Spendesk materials. (What kind of cards do we use?; Add funds to your wallet; Capterra reviews)

Cards product UX — good but not differentiated; carries a working-capital tax and acceptance niggles. Easy issuance of personalized physical + virtual cards, per-card and per-department budgets, single-use and recurring cards, Apple/Google Pay. EUR cards run on Visa (issued by SFS). Recurring complaints: some merchants don't accept the cards (especially virtual; occasional declines needing terminal/3DS configuration), and the prepaid model ties up cash. More serious: multiple reviewers report funds stuck in the wallet, slow fund returns, and poor support when closing accounts.

Mobile receipt-capture app — a genuine strength. Consistently the most-praised part of the product across G2/Capterra: smart receipt detection, photo-a-receipt-on-the-go capture, automatic reminders if a receipt is missing, intuitive and clean UI. Main app-side gripe: OCR doesn't always auto-fill every expense field. For the customer's "needs a good mobile app for receipt capture" priority, Spendesk delivers.

Addendum Verdict Summary

Addendum Sources

• Spendesk General T&C (customers)
• Spendesk — Payment service provider (EEA customers)
• Spendesk officially launches its own Payment Institution: Spendesk Financial Services
• Spendesk partners Adyen (FinTech Futures)
• Adyen — list of restricted and prohibited products & services
• Spendesk Security
• Spendesk — Accounts payable / invoice management
• Spendesk — Summer updates 2025
• Spendesk — Build a native integration using Spendesk API
• Spendesk — Using webhooks (experimental)
• Spendesk — What kind of cards do we use?
• Spendesk — Add funds to your wallet
• Spendesk Reviews (Capterra 2026)
• Spendesk Reviews (G2 2026)