Yokoy API Integration Research

Date: 2026-05-13 Product: Yokoy (yokoy.io / yokoy.ai) -- AI-powered spend management suite, Zurich Purpose: Evaluate Yokoy's API capabilities for Orcha integration -- specifically for a German customer evaluating Yokoy as a Pleo alternative for employee credit cards while continuing to use Orcha for AP invoices and DATEV for accounting.

Important Context: What Yokoy Actually Is, and the TravelPerk (not Sage) Acquisition

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

• Corporate credit cards (physical + virtual, Visa-issued via Transact Payments Malta/UK)
• Supplier invoice capture & AP workflows ("Yokoy Invoice" module)
• Employee expenses & per diems & mileage ("Yokoy Expense" module)
• Pre-accounting (AI-powered expense categorization, in-house ML model)
• Business payments ("Yokoy Pay") and FX

Yokoy sits upstream of the ERP -- it captures, codes, and approves expenses, then exports pre-accounted data to the customer's accounting/ERP system (DATEV, Business Central, Xero, NetSuite, SAP, etc.).

Correction on the customer brief: Yokoy was acquired by TravelPerk, not Sage

The original prompt described Yokoy as "acquired by Sage in 2024." That is incorrect. Yokoy was acquired by TravelPerk on 28 January 2025, as part of a $200M Series E that valued the combined company at ~$2.7B. The parent company has since rebranded from TravelPerk to "Perk" -- the domain yokoy.io now 301-redirects to perk.com for most marketing pages, while help.yokoy.ai, developer.yokoy.ai, app.yokoy.ai and api.yokoy.ai remain operational for product / API / customer surfaces. There is no Sage acquisition or partnership; Sage Intacct only appears in Yokoy's outbound ERP-integration list as a connector target, not as a corporate parent. Perk press release ; Speedinvest case study

Implication for Orcha: The acquisition is recent (15 months old) and the product is in an integration transition -- marketing pages and brand have moved to perk.com, but the product, developer portal, API, and DATEV integration remain branded "Yokoy" and operate from the yokoy.ai domains. There is no public indication that the API surface has changed materially since the acquisition; this should be re-checked at implementation time.

Implication for the customer scenario: Yokoy and Orcha overlap exactly as Pleo/Payhawk/Spendesk do -- both capture, code, and approve expenses, then push to the ERP. Yokoy is a peer (spend management) layer, not a target system to push invoices into. The integration question is narrower:

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

Both directions are feasible -- with significant nuances around export cadence and DATEV depth. See sections 5 and 7.

1. Summary -- Capability Matrix

Overall assessment: Yokoy's API is technically broad -- it covers reference-data CRUD across the four objects we care about (suppliers, chart of accounts/categories, cost objects, tax rates) with OAuth 2.0 auth and an OpenAPI 3.0 spec -- and is free on all plans. But on the critical "realtime" axis that drove this customer's Pleo evaluation, Yokoy is closer to Pleo than to Payhawk: the primary push mechanism for outbound data is the scheduled Export Job (hourly / daily / weekly / monthly), not event-driven webhooks. Webhooks exist (the Business Central connector consumes them for document-status changes) but are not first-class in public documentation -- there is no published POST /webhooks/subscriptions endpoint and no enumerable event catalog. DATEV depth is the weakest area in the comparison: Yokoy's DATEV integration is one-way export-only (Yokoy -> DATEV Buchungsdatenservice + Belege Online), with explicit acknowledgement in Yokoy docs that "DATEV does not expose any endpoints to get master data for Yokoy" -- meaning chart of accounts, KOST1/2, and tax codes must be configured manually in Yokoy first, with no auto-sync from DATEV.

2. API Landscape

API Layers

Note: The developer portal at developer.yokoy.ai is a JavaScript-rendered SPA. WebFetch returns the navigation hub but not the actual rendered endpoint detail pages. The swagger.json at api.yokoy.ai/v1/swagger.json is the authoritative machine-readable source.

Authentication

This is the same security posture as Pleo (OAuth 2.0 client credentials) and stronger than Payhawk (static API keys). Help: Get access credentials

Rate Limits

Not publicly documented. The swagger.json defines an HTTP 429 response shape, confirming rate limiting exists, but no explicit per-second / per-minute ceiling is surfaced in public docs. For comparison: Pleo is 600/min, Payhawk is 15/s, Spendesk and Moss similarly publish their limits. Assume Yokoy enforces limits and plan with backoff; the actual ceiling will need to be confirmed during implementation via 429 testing or partner inquiry.

API Categories

Confirmed via the swagger.json sweep, help center articles, and the unofficial open-source dylanj/yokoy Postgres-sync tool (which targets every endpoint Yokoy exposes for one-way data extraction):

Pagination

• SCIM-style filter syntax (e.g. created ge 2025-01-23 and facilityId eq expense)
• count + cursor parameters, max 100 items/page
• Standard for bulk reads

Versioning / Deprecation

API is on v1. No public deprecation schedule. Third-party SDK (dylanj/yokoy) notes API inconsistencies (country code naming, status as int vs string) suggesting the v1 namespace has evolved without rev-bumps.

3. Write Capability Verification

Confidence: HIGH for reference data (suppliers, categories, cost objects, tax rates, users); LOWER for webhook subscriptions and approval triggers.

Yokoy's API is explicitly designed around an "ERP as source of truth, Yokoy as the consumer" pattern. The Yokoy help center is unambiguous about this:

"The source of truth for supplier data should always be the supplier master data in your company's ERP system. Therefore, it is not possible to manually create new suppliers or edit supplier data in Yokoy." -- Suppliers in Yokoy

This is the inverse of Pleo's design (where suppliers can be created freely in the Pleo UI). For Orcha-as-AP-authority, this is actually more aligned with how Orcha already operates -- write from the system of record, don't expect Yokoy to be the master.

Confirmed Write Endpoints / Operations

Key Limitations

• No documented webhook subscription create / update / delete via public API. The Business Central connector consumes Yokoy webhooks for document-status changes, confirming webhooks exist server-side, but the subscription endpoint is not visible in the public swagger excerpt we could fetch, and no help-center tutorial documents how to subscribe externally. This is the single biggest gap for an Orcha real-time read integration -- see Section 7.
• No approval trigger / approve / reject via API. Read-only on workflow status.
• No card issuance via API. Card lifecycle handled via UI / banking partner (Transact Payments).
• No DATEV-side master data sync. Yokoy's DATEV integration runs Buchungsdatenservice only, which does not expose master data. Master data must be set up in Yokoy first (manually, via CSV, or via API from Orcha/the ERP); DATEV will not push down chart of accounts / KOST1/2 / tax codes to Yokoy.

4. iPaaS & Middleware Findings

No general-purpose iPaaS supports Yokoy. This is worse than Pleo (which has a Zapier app) and roughly equivalent to Payhawk before its Workato listing. The implication: any non-Orcha customer extension would have to be built directly against the Yokoy REST API or via SFTP/CSV. The single Yokoy partner-program perk is "access to API and sandbox tools to develop custom integrations" -- i.e. the API is the official integration path, not an iPaaS layer.

5. Alternative Channels

DATEV Integration (Native)

This is the most important channel for the customer scenario and the weakest area in the Yokoy vs Payhawk comparison.

Implication for Orcha-in-customer-stack: Because Yokoy's DATEV path is one-way, the customer cannot rely on DATEV-as-master to back-fill chart of accounts / cost objects / tax codes into Yokoy. Either:

• The customer configures Yokoy's reference data manually (CSV imports of CoA, cost objects, tax rates) and accepts drift risk vs DATEV/Orcha; OR
• Orcha becomes the sync authority for Yokoy reference data -- pushing chart of accounts, cost objects, tax rates, and suppliers into Yokoy via the Yokoy API, sourced from Orcha's own master / from DATEV (via Orcha's DATEV integration). This is the highest-value Orcha integration role in this scenario.

This is the opposite of how Payhawk handles DATEV (bidirectional via DATEV Cloud Services / RDS 1.0) and is materially weaker.

Native ERP/Accounting Integrations

Confirmed list (non-exhaustive):

HRIS Integrations

Personio (DACH), plus more via the Yokoy API. SCIM-style user sync.

Webhooks

This is the single biggest unverified question for Orcha read-side integration. If Yokoy webhooks are subscriber-managed (like Pleo via Svix or Payhawk's RSA-signed webhooks), Orcha can do real-time reads. If they are partner-only (configured for known ERP connectors via Yokoy's internal setup, with no public subscription API), Orcha will be limited to the Export Job batch cadence (best case: hourly). The Business Central case suggests the latter (Yokoy "notifies Business Central" -- implying a known target), but the answer needs verification with Yokoy/Perk partner-channel contact before committing engineering effort.

Scheduled Export Jobs (the documented primary push mechanism)

This is what Yokoy actually wants you to use for outbound data flows:

This is the same pattern as Pleo's Export Jobs API -- closing-the-loop batch -- and explicitly not the real-time event model that the customer wanted as a Pleo improvement.

CSV / SFTP Exports

• All reference-data objects (suppliers, cost objects, tax rates) support standard CSV templates with UTF-8/UTF-16/Latin1 encoding
• Supplier imports up to 2,000 records per file; tax rates 150 per file; cost objects 2,000 per file
• SFTP option with SSH-key auth for automated transfers
• Many ERP-specific export formats supported alongside the standard Yokoy format

6. Licensing & Access Requirements

API Access

Yokoy's Open API is free across all plans. Per Yokoy's marketing: "Yokoy offers all partners as well as consumers the free 'OpenAPI' platform." This positions Yokoy similarly to Payhawk (free on all plans) and unlike Pleo (Advanced tier $109/mo+ required).

There is no API-tier gating documented. Any paying Yokoy customer with a Developer-role user can issue OAuth credentials in Admin > Developer.

Plan Pricing (Quote-Only)

Yokoy does not publish pricing. Confirmed across G2, Capterra, GetApp, SaaSworthy, SoftwareAdvice, Gartner Peer Insights, Tekpon, SpotSaas -- every third-party listing reports "Contact vendor for pricing" or "No pricing info." There is no public per-user, per-card, or per-transaction-volume price card.

What is publicly known about the pricing structure:

• Module-based: Yokoy Expense (incl. card transactions), Yokoy Invoice, Yokoy Pay are sold as separate modules
• Yokoy Pay requires Yokoy Expense as a prerequisite
• Custom-priced, sized by company size + module set + transaction volume
• Free trial available
• No published per-user rate; some third-party aggregators speculate "$10-$100" but this is unverified

For the customer scenario: Only Yokoy Expense (cards + card transactions + reimbursements) is relevant since Orcha covers AP and DATEV covers accounting. The customer should NOT need Yokoy Invoice or Yokoy Pay. The customer will need to request a quote -- expect a discovery + scoping call rather than a self-serve checkout flow.

Customer Setup Checklist

1. Customer purchases a paying Yokoy plan with Yokoy Expense module (quote-only)
2. Admin assigns a user the Developer role
3. Developer-role user goes to Admin > Developer > Access credentials > Generate credentials > OAuth Credentials
4. Capture Client ID + Client Secret + Organization ID
5. (For DATEV) Tax advisor enables Buchungsdatenservice in DATEV; finance team runs the Yokoy DATEV wizard to map CoA (SKR03/04/07), KOST1/2, tax codes, and booking parameters
6. (For Orcha read-side) Test the Yokoy API via swagger.json; specifically probe whether a public webhook subscription endpoint is exposed in the authenticated portal that wasn't visible in the public spec excerpt
7. If no public webhook endpoint: configure an automatic Export Job to the most frequent supported cadence (hourly) targeting an Orcha-accessible file/API facility; OR contact Perk partner channel to discuss webhook subscriber enablement
8. (For Orcha write-side) Use API or CSV/SFTP to push suppliers (with externalId = DATEV supplier code), categories (CoA), cost objects (with Code (ERP) = KOST1/2 codes), and tax rates (with VAT Code (ERP) = DATEV BU code) into Yokoy

7. Orcha-Specific Deep Dive

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

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

Yokoy and Orcha have overlapping functionality in the Yokoy Invoice module -- but the customer scenario in scope explicitly excludes Yokoy Invoice (and Yokoy Pay). The customer is buying Yokoy Expense only for cards + reimbursements. The split is:

So with Yokoy Invoice off, Yokoy's responsibility is cards + reimbursements + their export to DATEV, and Orcha's responsibility is AP invoices + their export to DATEV. The two streams converge in DATEV, not in either spend tool -- but Orcha may also need to be the reference-data sync authority writing into Yokoy because DATEV doesn't push master data into Yokoy.

Integration Scenarios for the Customer

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

• Feasibility: MEDIUM-HIGH, with the realtime caveat
• Path 1 (preferred if webhooks accessible): Subscribe webhooks for expense.status.changed -> Orcha endpoint. Verify public webhook subscription endpoint exists via authenticated dev portal access; if not, escalate to Perk partner channel.
• Path 2 (fallback, documented): Configure automatic Export Job at hourly cadence to push expense + card-tx data to an Orcha-side endpoint (API facility) or SFTP location. Orcha polls / consumes the drop.
• For full-fidelity detail: GET /expenses/{id}, GET /invoices/{id}, GET /trips/{id} after notification.
• For raw pre-review card tx: GET /card-transactions (catches transactions before user matching, useful for very-early-stage spend analytics).
• For receipts: documents are retrievable via API (confirmed in BC connector docs). Mirror to Orcha S3 at retrieval time as a default-safe approach pending URL-TTL probe.

Scenario B: Orcha writes reference data INTO Yokoy for consistent coding (HIGH-VALUE SECONDARY USE CASE)

• Feasibility: HIGH -- and arguably higher-value than in the Payhawk scenario because Yokoy DATEV doesn't auto-sync master data.
• Suppliers: bulk import via API (POST suppliers) or CSV/SFTP. Set externalId = DATEV supplier code. Critical because Yokoy UI doesn't allow manual creation -- Orcha (or DATEV-aware tooling) MUST be the source.
• Categories (CoA): POST/PATCH via API. Map to SKR03/04/07 GL accounts. Critical because DATEV doesn't push these to Yokoy.
• Cost objects (cost centers / projects): POST/PATCH via API. Set Code (ERP) = KOST1/KOST2 code. Hierarchical supported.
• Tax rates: POST/PATCH via API. Set VAT Code (ERP) = DATEV BU code (BU7/8/9 + custom). Country-scoped.
• Users: POST/PATCH via API (or rely on Personio HRIS sync if customer is on Personio).

Scenario C: Customer migrates AP from Orcha to Yokoy Invoice

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

Scenario D: Orcha pushes invoices into Yokoy

• NOT NEEDED -- customer is not using Yokoy Invoice. Even if they were, the primary path is email-to-inbox / UI upload; a POST /invoices endpoint exists in swagger but is not the documented happy path.

Key API Differences vs Pleo and Payhawk

The Real-Time Verification Question -- Action Required

The single most important unverified question for the customer scenario is whether Yokoy exposes a public webhook subscription endpoint that Orcha can register against. Public docs do not surface one; the Business Central connector consumes Yokoy webhooks but is itself a Yokoy-built connector with potentially privileged access.

Recommended verification path before engineering commitment:

1. Authenticated dev portal probe. Get OAuth credentials in a Yokoy sandbox; load https://developer.yokoy.ai/api-reference/ in a browser (it is a JS-rendered SPA that WebFetch cannot read); search the rendered swagger for webhook, subscription, event, notification. Confirm presence/absence of POST /webhooks or similar.
2. Direct partner channel inquiry. Contact Perk partner-program team (partners.yokoy.ai) and ask: "Is your webhook subscription API available to external customer integrators (not only first-party connectors like Business Central), and if so, what is the event catalog and signature scheme?"
3. If no public webhook subscription endpoint exists: Plan the integration around the hourly Export Job as the primary push mechanism. This is materially worse than Payhawk's real-time, but materially better than Pleo's monthly customer-triggered export.

Receipt URL Longevity -- Action Required

Same probe pattern as Payhawk: in a Yokoy sandbox, fetch an expense via API, capture receipt URL from response, attempt re-fetch at T+1h / T+6h / T+24h / T+7d. If TTL is short, mirror documents to Orcha storage at retrieval time; if long, rely on Yokoy URLs.

Orcha Integration Capability Summary

8. Recommended Path Forward

Assessment: Yokoy is a Reasonable Coexistence Partner for Orcha, with Two Important Caveats

Yokoy is broadly comparable to Pleo and somewhat weaker than Payhawk on the specific gaps that motivated this customer evaluation. The strengths are:

• API is free on all plans -- no Advanced-tier gating like Pleo.
• Reference-data write is complete -- 4 of 4 (suppliers, categories, cost objects, tax rates), all with ERP-mapping fields. The supplier flow is API/CSV only (no UI), which is more aligned with how Orcha already operates.
• OAuth 2.0 client credentials auth -- secure, scoped, revocable.
• DACH market focus and German DATEV listing -- the product is built for this customer's market.

The weaknesses are:

• Real-time webhook subscription is undocumented publicly. Webhooks exist server-side (Business Central confirms), but there is no published POST /webhooks/subscriptions and no enumerable event catalog. The fallback (hourly Export Job) is workable but not real-time.
• DATEV integration is one-way (Yokoy -> DATEV). No master-data inbound from DATEV. This increases the case for Orcha being the reference-data sync authority into Yokoy -- but it also means that without Orcha or another upstream tool, the customer would have to maintain Yokoy reference data manually.
• No published rate limits, no published pricing, no iPaaS connectors. Three transparency gaps that complicate scoping.

Recommended Architecture

[Card transactions]            [Vendor invoices]
       |                              |
       v                              v
   Yokoy   <-- ref data sync ---  Orcha (write-side: suppliers, CoA, cost objects, tax rates)
       |                              |
       |  -- hourly export / webhook (TBD) ->  Orcha (read-side: unified spend analytics)
       |                              |
       v                              v
  DATEV (Buchungsdatenservice  <-- shared books ---  DATEV (Orcha direct push)
   + Belege Online, batch)

Write side (Orcha -> Yokoy) -- this is the highest-value Orcha role here:

1. Push suppliers via Yokoy Suppliers API (POST) with externalId = DATEV supplier code. Initial bulk via CSV/SFTP if record count > 2000 needs chunking.
2. Push chart of accounts via Categories API. Map to SKR03/04/07 GL accounts. Set Yokoy account field.
3. Push cost objects via Cost Objects API. Use Code (ERP) for KOST1/KOST2 mapping. Push hierarchies if customer uses parent-child cost centers.
4. Push tax rates via Tax Rates API. Use VAT Code (ERP) for DATEV BU code. Country-scope to DE.
5. Schedule periodic reconciliation sweep (daily) to catch drift.

Read side (Yokoy -> Orcha):

1. First, verify whether public webhook subscription endpoint exists (authenticated dev portal probe + partner channel inquiry).
2. If webhooks accessible: subscribe to status-change events. On event, GET /expenses/{id} for full detail.
3. If webhooks NOT accessible: configure automatic Export Job at hourly cadence to an Orcha-side facility (API endpoint or SFTP drop). Process the drop incrementally.
4. For each expense: pull amount + FX + merchant + category + cost objects + tax + employee + approver status + card metadata + receipt URLs.
5. Mirror documents to Orcha S3 at retrieval time (default-safe pending TTL probe).

When Yokoy Integration Makes Sense

1. Customer migrates off Pleo for cards/reimbursements onto Yokoy: Most Pleo gaps (API tier, partial real-time via hourly export) are improved. The DATEV gap is not improved (Yokoy is also batch-export, and Yokoy is actually one-way where Pleo at least has one-click DATEV with limited master data; Payhawk wins this lane).
2. Customer values the Yokoy AI model and German-market focus: Yokoy's in-house ML for VAT / category prediction is a real differentiator, especially for multi-country VAT.
3. Customer wants a Zurich-HQ vendor with DACH partner-network coverage: Yokoy's positioning is explicit here.
4. Customer already uses TravelPerk for travel: Now-native trip import from Perk into Yokoy is a meaningful adjacency.

When Yokoy Is NOT the Right Fit

1. Customer requires bidirectional DATEV master data sync. Yokoy explicitly doesn't do this; Payhawk does.
2. Customer requires real-time card-tx push with documented public webhook contract. Yokoy's webhook story is opaque; Payhawk's is documented.
3. Customer wants iPaaS-based low-code orchestration. No Zapier / Make / Workato / Celigo / n8n connector exists.

What NOT to Build

• Invoice push to Yokoy: Not needed for this customer; not the documented happy path.
• Approval workflow automation in Yokoy: Not API-accessible.
• Replacing Yokoy's DATEV integration: It's the only DATEV path Yokoy offers; can't be swapped.

Architecture Decision

Pre-Implementation Verification Needed

Before any engineering commitment:

1. Probe public webhook subscription endpoint in an authenticated Yokoy sandbox session (developer portal SPA + authenticated swagger). Search for webhook, subscription, event resources.
2. Probe receipt URL TTL in a Yokoy sandbox -- same pattern as Payhawk/Pleo probes.
3. Confirm rate limit ceiling by hitting 429 empirically in a sandbox.
4. Confirm expense response shape for the specific fields the customer cares about: card last-4, virtual/physical flag, approver name (vs just status), and per-expense externalId mapping.
5. Confirm pricing for the Yokoy Expense module only (not the full suite) with sales -- this is the customer's actual scope.
6. Confirm post-acquisition API stability commitment. With the TravelPerk/Perk acquisition still recent, confirm there is no plan to merge the Yokoy and Perk API surfaces or deprecate yokoy.ai endpoints in favor of a Perk-unified API.

Recommendation Summary

For the customer scenario (DATEV + Orcha + Pleo replacement with Yokoy for cards): CONDITIONALLY YES, but Payhawk is a stronger technical fit for the exact gaps that motivated the evaluation.

If the customer chooses Yokoy regardless (because of brand, sales relationship, German-market trust, AI model, or TravelPerk adjacency):

• The write-side integration (Orcha -> Yokoy reference data) is clean, well-supported, and high-value because DATEV doesn't push master data to Yokoy. Orcha is the natural authority.
• The read-side integration (Yokoy -> Orcha card-tx) is viable but capped at hourly unless public webhook subscriptions are confirmed available.
• The DATEV integration (Yokoy -> DATEV) is one-way batch via Buchungsdatenservice and won't be improved by Orcha; the customer's accounts converge in DATEV as normal.

Yokoy compared to Pleo on the three critical customer gaps:

1. Realtime: Yokoy is better than Pleo (hourly export beats monthly customer-triggered export; webhooks possibly available pending probe) but not as good as Payhawk (which has documented real-time webhooks).
2. API pricing tier: Yokoy solved this -- free on all plans, same as Payhawk, better than Pleo's Advanced-tier gating.
3. Receipt URLs: TBD -- needs empirical verification, no public claim of a 24h expiry exists, and DATEV-Belege-Online persistence suggests longer durability than Pleo's 24h.

The customer brief mentioned a "Sage acquisition in 2024." That is not factual -- Yokoy was acquired by TravelPerk in January 2025, and the parent has since rebranded to Perk. There is no Sage corporate relationship. If the customer is choosing Yokoy partly because they assume Sage backing, that assumption should be corrected.

9. Sources

Official Documentation

• Yokoy Developer Portal -- interactive API reference (JS SPA; partially accessible from public web)
• Yokoy API Reference
• Yokoy API (Help Center)
• Get access credentials for Yokoy API
• Yokoy OpenAPI / Swagger spec -- machine-readable spec
• User authentication in Yokoy
• Yokoy API on apitracker.io
• Yokoy API on Perk help center (403 to anonymous fetch)
• Yokoy API press release (redirects to perk.com)
• Build Your Own Integrations With Yokoy's API (redirects to perk.com)

DATEV Integration

• DATEV integration for expenses -- export-only, Buchungsdatenservice + DUO Belege Online, manual master-data setup required
• Datev Customers Now Benefit From Yokoy's Automated Spend Management (redirects)
• Digitalisiertes Spesenmanagement -- DATEV magazin

Reference Data & Master Data

• Suppliers in Yokoy -- API/CSV/SFTP write only; no UI create
• Upload suppliers via CSV -- 2000/file, externalId for ERP mapping
• Set up cost objects -- full CRUD via API (GET, POST, DEL, PATCH/PUT)
• About cost objects in Yokoy
• VAT / Tax rates in Yokoy -- manual / CSV / API
• How can I edit supplier data in Yokoy?
• Add a one-time supplier

Card Transactions / Cards

• How do I manage card transactions?
• Smart Corporate Cards (redirects to perk.com)
• Perk Corporate Cards

Export & Workflow

• Export reviewed expenses, trips, transactions, and invoices
• Set up an automatic export job for expenses -- hourly / daily / weekly / monthly schedules
• Set up an automatic export job for invoices
• Generate expense, transaction and invoice reports
• Different statuses in Yokoy -- status taxonomy for webhook event inference
• Spend export file for invoices
• Yokoy standard export file for expenses

ERP Connectors

• About the Yokoy Spend Management Connector for MS Dynamics 365 Business Central -- confirms Yokoy webhooks exist for document-status notifications
• Implement the Yokoy Spend Management Connector for MS Dynamics 365 Business Central

Integrations Overview

• Yokoy Integrations (help center)
• Perk Integrations Marketplace (redirects to perk.com)
• Yokoy + Personio
• Yokoy on Personio Marketplace

Acquisition & Corporate Context

• Perk Press Release: TravelPerk Raises $200M and Acquires Yokoy -- 28 Jan 2025, all-equity, $2.7B valuation
• Globenewswire mirror
• PYMNTS coverage
• Speedinvest case study: How Yokoy Scaled to a TravelPerk Acquisition
• The future of Travel and Expense management is here

Partner & Developer Program

• Yokoy Partner Portal
• Yokoy Partner Program (DACH)
• Partner with us

Status & Infrastructure

• Yokoy Status Page -- Expenses / Invoices / Cards / Imports/Exports / API Availability / Mobile Apps operational components
• Cloudflare Radar: Yokoy Group Webhooks Bot Information

Pricing & Reviews (all confirm quote-only)

• Yokoy on Capterra -- no pricing published, free trial available, 4.5/5 from 50 reviews
• Yokoy on GetApp -- "No pricing info"
• Yokoy on G2
• Yokoy on SaaSworthy
• Yokoy on SaaSworthy Pricing
• Yokoy on SoftwareAdvice
• Yokoy on SourceForge
• Yokoy on Gartner Peer Insights

Third-Party Tooling & References

• GitHub: dylanj/yokoy (unofficial Postgres sync) -- confirms base URL api.yokoy.ai/v1/, OAuth client credentials, sandbox at test.yokoy.ai, swagger.json availability, resource list

Yokoy Product Context

• Yokoy: AI-powered spend management suite (redirects to perk.com)
• Yokoy spend management
• Yokoy Procure-to-Pay
• About Yokoy web and mobile apps

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

Context for this addendum: Supplementary research for a customer-facing assessment. The customer is a German defense-sector company using Pleo (employee cards, to be replaced), DATEV (accounting), and Orcha (AP invoices). Updated customer priorities: (1) the tool must handle employee credit cards very well as the core need, (2) a good mobile app for receipt capture, (3) a strong API that Orcha can both READ and WRITE, and (4) a non-prepaid card funding model — the customer wants a charge card or credit line, not a pre-funded wallet they must top up. This addendum aligns with the methodology and verdict format of the Qonto vs Pleo defense assessment §1.

A1. Defense-Sector Posture — Verdict: AMBER (leaning AMBER-minus)

Verdict: AMBER. No published defense exclusion anywhere in the Yokoy/Perk stack (better than Qonto's explicit RED-triggering ban; comparable to Pleo's silence). Mitigants: platform-scoped ISO 27001 + EU/Swiss data residency are genuinely strong and the best in the comparison set. But the risk is the three-party discretionary issuer stack (Perk KYB → Modulr → Transact Payments), none of which publishes a defense-friendly policy — that is more offboarding surface than Pleo's single direct-issuance model. As with every vendor in this assessment, the gate is "can the customer hold the account at all," and that must be confirmed in writing with Perk and surfaced to Modulr/Transact before any recommendation. No BSI C5 — if the customer's security function mandates C5, Yokoy fails that bar (so do Pleo and Qonto).

A2. Cannibalization Risk vs Orcha — Rating: HIGH

The main doc treated Yokoy Invoice as out-of-scope because this customer would only buy Yokoy Expense. That keeps the integration scope narrow, but it does not lower the strategic cannibalization risk — and on re-examination that risk is HIGH, the highest of any vendor assessed (Pleo low-medium, Qonto medium-high, Payhawk medium).

• Yokoy Invoice is a direct, full-stack AP competitor — not a shallow add-on. The Perk/Yokoy Invoice product page markets AI OCR header + line-item extraction, AI "smart coding" that learns how your people code invoices, GL coding, VAT/tax compliance checks against ERP and regulatory rules, PO/goods-receipt 2- and 3-way matching, approval-workflow routing, native e-invoice standards (ZUGFeRD, XRechnung, Factur-X, PEPPOL BIS), and DATEV + ERP export. That is a feature-by-feature description of Orcha's core product, including the GoBD/DATEV German-market specifics. This is far more encroaching than Qonto's "shallow Supplier Invoices" or Pleo's invoice OCR.
• It is actively invested in, not dormant. Yokoy Invoice shipped material 2025–2026 updates (smart line-item extraction + PO payment terms Aug 2025; AI document classification Jul 2025; cost-object/category auto-assignment via regex + invoice-preview-URL controls Jan 2026). The roadmap is moving toward Orcha, not away.
• The TravelPerk/Perk ownership makes the trajectory worse, not better. The $200M Series E is explicitly earmarked for "significant investments into product, technology and AI" and US/mid-market expansion, and Perk sells standalone Yokoy Expense, Invoice, and Pay modules under one "intelligent spend management" platform. A customer who adopts Yokoy for cards is one upsell conversation away from Yokoy Invoice — and the vendor is funded and motivated to have that conversation.
• The consolidation pitch is structurally anti-Orcha. Perk's whole narrative is "travel + expense + invoice + cards in one platform." Every customer who buys that story is predisposed to ask "why do we run a separate AP tool?" — and unlike Qonto (a bank that acquired Regate), Yokoy built its AP module in-house and has been selling it for years.

Why HIGH, not MEDIUM: the overlap is not a future possibility (Qonto/Regate) or a static lane (Pleo) — it is a mature, in-market, German-tax-aware, actively-funded AP product sold by the same vendor under the same brand. Recommending Yokoy for cards plants a credible AP competitor directly inside the customer relationship. Mitigant for Orcha's positioning: Orcha's defensible edge remains extraction depth + tax-compliance rigor + GoBD-grade coding; but that is a "depth" argument a naïve buyer may discount when they already see Yokoy → DATEV working for card receipts.

A3. API Read/Write Refresh — Confirmed, with one update

Re-verification confirms the main doc's findings; one item to flag:

• READ: Confirmed. GET across expenses, invoices, trips, company cards, card transactions (raw matched/unmatched feed), suppliers, categories, cost objects, tax rates, users, legal entities. SCIM-style filtering, 100/page cursor pagination. The help center reiterates the API is for "retrieving expenses, trips, and invoices" and exporting journal entries. The authoritative swagger.json sweep again shows the full schema set for these resources.
• WRITE: Confirmed. Full reference-data CRUD (POST/PATCH/DELETE) on categories, cost objects, tax rates, users; POST/PATCH bulk import for suppliers (still API/CSV/SFTP only — no UI create, the ERP-as-source-of-truth pattern that suits Orcha). FX-rate upload, expense/invoice POST, export-job trigger + mark-exported all confirmed.
• Webhooks — slight positive signal, still unconfirmed. The main doc flagged that no public webhook subscription endpoint surfaced. Re-checking: a third-party API directory (apitracker.io) now lists a "Webhooks management API" for Yokoy, and the help center confirms webhooks fire for document-status changes (still described only in the context of the Business Central connector — "Yokoy communicates changes in Yokoy invoice states to Business Central using webhooks"). However, the public swagger.json sweep still shows no webhook/subscription/event paths, and the JS-rendered developer portal still cannot be read by automated fetch. Net: unchanged from the main doc — Export Jobs (hourly minimum) remain the documented, confirmable push mechanism; a usable public webhook subscription API is plausible but still must be verified via an authenticated dev-portal session or Perk partner channel before any engineering commitment.
• No other API changes detected post-acquisition; yokoy.ai API/developer surfaces remain operational and Yokoy-branded.

A4. Card Funding Model + Cards/App UX

Funding model — this is a hard mismatch with the customer's stated preference. Yokoy's cards are prepaid / pre-funded, full stop. The account-funding help article is explicit: the company must manually bank-transfer funds into a Modulr-provided account (IBAN/BIC) before cards can be used; "the Card allows Card Users to access available funds that have previously been credited to the Account"; transactions are declined without sufficient balance; funds cannot be withdrawn once transferred; the only "automation" is a low-balance notification, not auto-replenish. Perk's own "Prepaid, Debit or Credit" and corporate-cards guide describe the Yokoy product as prepaid/debit-style ("funds transferred onto the card prior to usage") and nowhere offer a charge-card or credit-line option. The customer explicitly does NOT want prepaid — they want a charge card or credit line. Yokoy cannot meet this requirement. (Note: in Switzerland a UBS co-branded corporate card appears as an option, but that is region-specific and not the standard German offering, which runs on the Modulr/Transact prepaid rails.)

Cards product UX — Verdict: AMBER. Capterra (4.5/5, ~50 reviews) and other review sites give a mixed-to-decent picture: automatic transaction matching and simplified card management are praised, but recurring complaints include the expense-to-card matching being "not intuitive for end users," physical-card delivery being slow / limited-country, cards "limited to the European market," credit-note handling problems, and broken third-party card feeds (a UBS feed "hasn't worked for months"). Trustpilot is harsher (constant bugs, slow/absent support, receipts spontaneously un-matching). Solid but not best-in-class.

Mobile receipt-capture app — Verdict: AMBER-to-GREEN. This is the relative bright spot. Reviewers consistently praise the receipt photo capture and the quality of automatic data recognition ("excellent," "minimal effort," "very easy for employees"). Negatives are real but secondary: occasional iOS crashes/glitches, an Android bug where the bottom line can't be selected, a clunky default login screen, and no email-forwarding option for receipts (users explicitly asked for it). For the customer's "good mobile app for receipt capture" priority, Yokoy is adequate-to-good — the core capture flow is well-regarded, the polish is uneven.

A5. Bottom Line for This Customer

Recommendation: The prepaid funding model is, on its own, a likely disqualifier against the customer's explicit "not prepaid" requirement — this should be raised with the customer before anything else. Even setting that aside, Yokoy carries the highest cannibalization risk of any vendor assessed. If the customer still wants Yokoy for non-funding reasons (AI model, DACH focus, ISO 27001), proceed only with (a) written defense pre-clearance from Perk and visibility to Modulr/Transact Payments, and (b) eyes open that the write-side reference-data integration is the high-value, low-regret part while the read-side real-time path remains unverified. For a customer who wants a charge card specifically, Yokoy is not the answer — that points back toward Payhawk (charge-card model, pending its own defense check) or a true charge/credit product.

A6. Addendum Sources

• Perk Terms of Use — no prohibited-industry list; sanctions clause only
• Perk Cardholder Terms — Modulr (EU partner / UK distributor) + Transact Payments issuer stack
• Yokoy/Perk Legal, Security & Compliance hub
• Modulr Terms & Conditions ; Modulr Prohibited Jurisdictions
• Yokoy ISO 27001 update ; m-q.ch — Yokoy receives ISO 27001/9001/14001/eIDAS-QSeal
• Yokoy Technical & Organizational Measures (TOMs) 2024.09 — EU (Frankfurt; St. Ghislain) + Zurich data storage
• Yokoy Privacy Policy ; Yokoy GoBD compliance
• Perk/Yokoy Invoice Management product page — AI extraction, smart coding, VAT compliance, ZUGFeRD/XRechnung/Factur-X/PEPPOL, DATEV/ERP export
• Perk blog — AI Invoice Management
• Managing account funding for your Yokoy Platinum Visa cards — explicit prepaid/pre-funding model
• Perk blog — Company Cards: Prepaid, Debit or Credit ; Perk — Guide to Corporate Cards
• Yokoy on Capterra — reviews (4.5/5, ~50 reviews) ; Yokoy on Trustpilot ; Yokoy on G2
• apitracker.io — Yokoy API — lists a "Webhooks management API"
• Yokoy API help center article ; Yokoy swagger.json
• Perk press release — TravelPerk raises $200M and acquires Yokoy ; Perk blog — acquisition / next chapter in spend management