Date: 2026-04-29 Product: Pleo (pleo.io) -- Spend Management Platform, Copenhagen/London Purpose: Evaluate Pleo's API capabilities for Orcha integration
Pleo is NOT an ERP or accounting system. Like Moss, it is a spend management platform that handles:
Pleo 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, Xero, NetSuite, QuickBooks, Business Central, etc.).
Implication for Orcha: Same as Moss -- Pleo is not a target system where Orcha would push invoices into. Pleo competes with / complements parts of what Orcha does (invoice capture, OCR, pre-accounting). However, Pleo has a significantly more mature API than Moss, with full CRUD for vendors, chart of accounts, tags, and tax codes.
| Capability | Public API | Via Zapier | Via DATEV | Via CSV | Verdict |
|---|---|---|---|---|---|
| Read expenses (cards, invoices, reimbursements) | YES (Export API) | YES (trigger) | N/A | YES | Available now |
| Read vendors/suppliers | YES (GET /vendors) |
NO | N/A | N/A | Available now |
| Write vendors/suppliers | YES (POST /vendors, PUT) |
NO | N/A | N/A | Available now |
| Read chart of accounts | YES (GET /accounts) |
NO | N/A | N/A | Available now |
| Write chart of accounts | YES (POST /accounts, batch create) |
NO | N/A | N/A | Available now |
| Read/write tags (cost centers) | YES (Tags API, full CRUD) | YES (create tag) | N/A | N/A | Available now |
| Read/write tax codes | YES (Tax Code API, full CRUD) | YES (get tax code) | N/A | N/A | Available now |
| Read employees | YES (GET /employees) |
YES (trigger + get) | N/A | N/A | Available now |
| Write employees | YES (POST /employees) |
YES (create/update/delete) | N/A | N/A | Available now |
| Export accounting entries | YES (Export Jobs API v1/v2/v3) | NO | YES (1-click) | YES | Available now |
| Push invoices into Pleo | Email inbox / UI upload | NO | NO | NO | Not via API |
| Webhooks (event notifications) | YES (v1.export-job.created, v1.vendor.created, more) |
N/A | N/A | N/A | Available now |
| Trigger/manage approvals | NOT via API | NO | N/A | N/A | Not available |
Overall assessment: Pleo has a well-structured REST API with strong read/write capabilities for reference data (vendors, chart of accounts, tags, tax codes) and a robust export pipeline. However, like Moss, invoices enter Pleo via email or UI upload -- not via API. Pleo is a spend management peer, not an ERP target for Orcha.
| API | Base URL | Purpose |
|---|---|---|
| External API | https://external.pleo.io/ |
Main API: vendors, accounts, tags, tax codes, export jobs, webhooks, employees |
| Open API | https://openapi.pleo.io/v1/ |
Additional endpoints (expenses) |
| Developer Portal | https://developers.pleo.io/ |
Documentation hub |
| OpenAPI 3.0 Spec | Available via developer portal | Machine-readable spec for client generation |
| Method | Details |
|---|---|
| OAuth 2.0 Client Credentials | Primary method for server-to-server |
| Token endpoint | POST https://external.pleo.io/v0/auth/headless/token |
| API Keys | Generated in Pleo admin (Key ID + Secret Key) |
| Standalone API Keys | For simpler integrations |
| Integrated API Keys | For deeper ERP integrations |
| Token format | JWT with embedded user and scope info |
| Scopes | Per-resource (e.g., export-jobs:read, export-jobs:write, vendors:read, vendors:write) |
| API | Read | Write | Key Endpoints |
|---|---|---|---|
| Vendors | GET, search | POST create, PUT update, POST archive, POST activate | Full CRUD + states (Active/Draft/Archive) |
| Chart of Accounts | GET list, GET by ID | POST create, POST batch create, PUT update, DELETE | Full CRUD |
| Tags & Tag Groups | GET all, GET by group, search | POST create group, POST create tag, PUT update, DELETE | Full CRUD (max 5 tags per entry) |
| Tax Codes | GET list, GET by ID | POST create, PUT update, DELETE | Full CRUD |
| Export Jobs | GET list, GET by ID, GET items | POST create job, POST events, PATCH update items | Full workflow |
| Employees | GET search | Referenced in docs | Read + limited write |
| Companies | GET search, GET by ID | N/A | Read only |
| Webhooks | GET subscriptions | POST create, PUT update, DELETE | Full CRUD |
Some legacy API endpoints are deprecated and will be completely revoked during 2026. Current endpoints listed above are the active ones.
Confidence: HIGH -- Pleo has extensive write capabilities for reference data and export management.
| Endpoint | Method | Operation | Confidence |
|---|---|---|---|
| Create vendor | POST | New vendor record | HIGH (documented) |
| Update vendor | PUT | Modify vendor | HIGH (documented) |
| Archive vendor | POST/DELETE | Deactivate vendor | HIGH (documented) |
| Create account | POST | New chart of accounts entry | HIGH (documented) |
| Batch create accounts | POST | Multiple accounts at once | HIGH (documented) |
| Update account | PUT | Modify account | HIGH (documented) |
| Delete account | DELETE | Remove account | HIGH (documented) |
| Create tag group | POST | New tag category | HIGH (documented) |
| Create tag | POST | New tag (cost center, project, etc.) | HIGH (documented) |
| Update tag/group | PUT | Modify tag | HIGH (documented) |
| Delete tag/group | DELETE | Remove tag | HIGH (documented) |
| Create tax code | POST | New tax code | HIGH (documented) |
| Update tax code | PUT | Modify tax code | HIGH (documented) |
| Delete tax code | DELETE | Remove tax code | HIGH (documented) |
| Create export job | POST | Trigger accounting export | HIGH (documented) |
| Update export items | PATCH | Modify export entries | HIGH (documented) |
| Create webhook subscription | POST | Subscribe to events | HIGH (documented) |
| Create employee | POST | Add employee to Pleo | HIGH (Zapier confirms) |
Despite the extensive write API, there is no endpoint to push/upload invoices into Pleo. Invoices enter Pleo through:
| Platform | Pleo Connector? | Details |
|---|---|---|
| Zapier | YES | 4 triggers (New Employee, New Expense, New Receipt, New Tag) + 8 actions (Create/Update/Delete Employee, Create Tag, Get Employee/Expense/Receipt/Tax Code) |
| Celigo | NO | Not found in marketplace |
| Workato | NO | Not listed |
| Make.com | NO | Not listed |
| n8n | NO | No native or community node found |
Zapier is the only iPaaS with Pleo support. The connector provides read triggers for expenses and basic write actions for employees and tags. It does NOT support invoice push, vendor management, or chart of accounts operations.
| System | Connection Type | Direction |
|---|---|---|
| Xero | API (direct sync) | Bidirectional |
| Oracle NetSuite | API (Certified SuiteApp) | Bidirectional |
| QuickBooks Online | API (one-click export) | Export |
| Microsoft Business Central | API (v2) | Bidirectional |
| Exact Online | API | Bidirectional |
| Exact Globe | API | Export |
| DATEV | API + CSV | Export |
| Fortnox | API | Export |
| Visma.net | API | Export |
| XLedger | API | Export |
| FreeAgent | CSV | Export |
| Sage 50/200 | CSV | Export |
| SAP R3/ECC | CSV | Export |
| Addison, BMD, Diamant, Lexware, Sesam, Twinfield | CSV | Export |
SAP SuccessFactors, BambooHR (+ others for employee sync)
v1.export-job.created, v1.vendor.createdPOST https://external.pleo.io/v1/subscriptions| Plan | Monthly | Yearly | API Access | Notes |
|---|---|---|---|---|
| Essential | $45/mo | $39/mo | Basic integrations | Accounting integrations included |
| Advanced | $109/mo | $99/mo | Open API access | Explicitly listed as feature |
| Beyond | $219/mo | $199/mo | Full API + concierge | Enterprise tier |
API access requires the Advanced plan or higher (confirmed on legacy pricing page: "open API access for customization" listed under Advanced). Essential plan includes accounting integrations but not the open API.
Like Moss, Pleo and Orcha have overlapping functionality:
| Capability | Pleo | Orcha |
|---|---|---|
| Invoice capture (OCR) | YES (AI-powered) | YES (core product) |
| Invoice data extraction | YES | YES (core product) |
| Pre-accounting (account coding) | YES (AI-powered) | YES (core product) |
| Cost center assignment | YES (tags) | YES |
| Approval workflows | YES (multi-step) | Depends on customer |
| Payment processing | YES (SEPA, international, 70+ currencies) | NO |
| Corporate cards | YES | NO |
| Employee reimbursements | YES (mileage, per diem) | NO |
| Push to ERP | YES (native connectors to 15+ systems) | YES (via integration) |
Scenario A: Orcha pushes reference data INTO Pleo
Scenario B: Orcha reads expense data FROM Pleo
Scenario C: Orcha replaces Pleo for invoice processing
Scenario D: Orcha pushes invoices into Pleo
Pleo's API is significantly more mature than Moss's:
| Orcha Need | Pleo Support | Endpoint(s) | Confidence | Notes |
|---|---|---|---|---|
| Sync chart of accounts | FULL (read + write) | Chart of Accounts API | HIGH | Full CRUD including batch create |
| Sync cost centers | FULL (read + write) | Tags API | HIGH | Up to 5 tags per entry, full CRUD |
| Sync tax codes | FULL (read + write) | Tax Codes API | HIGH | Full CRUD |
| Sync vendors/suppliers | FULL (read + write) | Vendors API | HIGH | Full CRUD + states |
| Push incoming invoices | NO | N/A | HIGH | Not possible via API |
| Attach documents | NO | N/A | HIGH | Not exposed in API |
| Manage approvals | NO | N/A | HIGH | Not exposed in API |
| Read expenses/export data | YES | Export Jobs API | HIGH | Structured export workflow |
| Track status changes | YES (webhooks) | Webhook Subscriptions API | HIGH | v1.export-job.created, v1.vendor.created |
| Read employees | YES | Employees API | HIGH | Search + retrieve |
Like Moss, Pleo sits at the same layer as Orcha in the financial workflow. Both tools capture, code, and approve expenses, then push to ERPs.
Customer uses Pleo for cards/reimbursements + Orcha for AP: Both push independently to ERP. Consider syncing reference data (chart of accounts, tags, vendors) between systems to ensure consistent coding. Pleo's CRUD APIs make this technically feasible.
Unified spend reporting: Use Pleo's Export Jobs API + webhooks to pull card/reimbursement data into Orcha's analytics, providing a complete spend view alongside invoice data.
Reference data synchronization: If a customer has chart of accounts or vendors managed elsewhere, Orcha could write reference data into Pleo via the Vendors, Accounts, Tags, and Tax Codes APIs to keep Pleo aligned.
| Approach | Cost | Complexity | Value | Verdict |
|---|---|---|---|---|
| Read expenses via Export Jobs API | Requires Advanced plan | Medium | Medium | For unified spend analytics |
| Sync reference data via CRUD APIs | Requires Advanced plan | Medium | Medium | For consistent coding across systems |
| Webhook subscriptions | Requires Advanced plan | Low | Medium | For real-time export notifications |
| No integration (coexist independently) | EUR 0 | None | N/A | Most likely scenario |
For most customers: no Pleo-Orcha integration is needed. Both tools push to the customer's ERP independently. If a customer specifically needs unified spend reporting or reference data consistency between Pleo and Orcha, the APIs are mature enough to support it -- but the customer needs the Advanced plan ($109/mo+) for API access.
Context: Supplementary research for a German defense-sector customer who currently uses Pleo (employee credit cards) + DATEV (accounting) + Orcha (AP invoices) and wants to replace Pleo. Pleo is here the incumbent/baseline. Updated customer priorities: (1) must handle employee credit cards very well, (2) good mobile receipt-capture app, (3) very good API that lets Orcha both READ and WRITE, (4) prefers a charge card / credit line over a prepaid load-the-wallet model. Done via WebFetch + WebSearch; every claim cited in §sources below.
Acceptable Use Policy / prohibited business language. There is still no standalone published "Acceptable Use Policy" or restricted-industries list anywhere in Pleo's legal hub (Pleo Legal lists only MSA, DPA, Privacy Policy, Overdraft T&Cs, Complaint Process, Fraud Awareness, Code of Conduct, Whistleblowing — no AUP). The closest binding language is clause 8 of the Pleo Master Service Agreement (EEA/EU, dated 5 March 2026):
So Pleo's posture is silence + broad discretionary "risk appetite" language, not an explicit ban. Silence ≠ permission: a defense customer's eligibility is entirely discretionary and can be revisited at any KYB review.
Mastercard scheme. Pleo issues Mastercard cards directly under its own Danish e-money licence (no partner-bank BIN sponsor). Mastercard scheme rules prohibit illegal transactions but do not categorically ban lawful defense businesses, so the binding constraint is Pleo's own "risk appetite," not the scheme.
Data hosting — now concretely documented. Pleo's primary hosting is AWS eu-west-1 (Ireland), with local backups and secondary backups in AWS eu-central-1 (Frankfurt). Sub-processors page also lists Azure (EU) and GCP (EU) for hosting, Enfuce (Frankfurt) and Saltedge (Frankfurt) for payment/open-banking processing, plus Twilio/Freshworks/Notion (EU) and HubSpot (US, under SCCs). This is a real improvement on the master assessment's "EEA, region not published."
Certifications. Confirmed: PCI-DSS (highest level, annual), Google CASA (annual), HackerOne bug bounty, CAIQ self-assessment, GDPR. Still no ISO 27001, no SOC 2, no BSI C5, no ISAE 3402. For a defense buyer whose own security function may demand ISO 27001 or BSI C5, this is a genuine gap — same as Qonto.
Latent offboarding risk (the customer is ALREADY on Pleo). This is real and worth flagging. (1) Pleo's own help content states its "Transactional Surveillance team closes accounts following routine reviews of activity deemed to fall outside of their internal risk appetite" and that such decisions "are final." (2) Documented cases exist of Pleo rejecting/closing customers citing "internal policies and alignment with Pleo's current business priorities and risk appetite" with no further explanation. (3) Pleo has itself acknowledged offboarding-process problems. Being onboarded is not the same as having a defense-friendly written policy — the customer sits on a discretionary "risk appetite" clause that can be re-evaluated at any periodic KYB review, with no contractual defense carve-out protecting them. The incumbent position is therefore not a safe harbour; if anything it's a reason to move to a vendor with an explicit, written defense-positive stance.
Verdict: AMBER (unchanged). Opaque AUP, broad discretionary risk-appetite clauses, no explicit defense exclusion and no explicit defense permission, thin certifications for a defense buyer, plus a documented pattern of discretionary closures. Confirm Pleo's stance in writing before relying on it.
The original research rated overlap "real but static (invoice OCR, pre-accounting)." That has changed and the rating should move up. As of 2026, "Pleo Invoices" has been rebranded and expanded into "Pleo Accounts Payable" — a full AP workflow: invoice capture + OCR extraction (payment terms, amounts, VAT), purchase-order raise/match/track, multi-step approval/review management, payment execution (pay via existing bank or directly through Pleo, single or bulk, 50+ currencies), and bookkeeping export to DATEV / NetSuite / SAP Business One / Business Central. Critically, Pleo recently launched a "processing-only" version of Pleo Accounts Payable specifically targeted at lean finance teams in Germany — i.e. AP without the cards attached, sold into exactly Orcha's customer profile and Orcha's geography.
That is no longer "static." Pleo is actively building out the AP category. Mitigants keep this at MEDIUM rather than HIGH: Pleo's OCR/extraction is generic spend-tool grade, not deep invoice extraction; there is no evidence of GoBD-grade tax-compliance coding logic comparable to Orcha; Pleo still cannot ingest invoices via API (email/UI only — see §C); and Pleo's core identity remains cards/spend, not AP. But the trajectory is unambiguously toward Orcha's turf, and the German processing-only SKU is a direct shot. Rating: MEDIUM (was implicitly LOW–MEDIUM in the master assessment's §5.3 — the German AP push justifies nudging it up).
Re-verified against the live developer docs; nothing material has changed:
GET /v2/export-jobs for pending jobs, send started/completed events, read items). No realtime expense stream outside this batch flow. Confirmed unchanged.Funding model — this is the key finding for the customer's priority #4. Despite Pleo's 2020-era "credit card" marketing, the MSA confirms the underlying product is still an e-money / pre-funded model: clause 9.1 — "The E-money Account shall be loaded by the Customer prior to use of the Service." Loading is via manual SEPA transfer, auto top-up, or Direct Debit transfer rules into a safeguarded account (J.P. Morgan / Danske Bank). So the default is exactly the load-the-wallet model the customer wants to avoid.
However, Pleo has two credit layers on top that move it toward what the customer wants:
So the honest answer to the customer: Pleo is natively prepaid, but with Pleo Overdraft (available in Germany) it can be operated as a monthly-settled credit line that removes the need to pre-fund — which matches the customer's stated preference. This is subject to Pleo's credit approval and discretionary limits (and the limit "may be adjusted at Pleo's sole discretion at any point without prior notice" — MSA 9.5.2). It is not a true unbundled charge card with a guaranteed line; it's a discretionary overdraft bolted onto an e-money wallet.
Cards & mobile app UX — strong, the customer's priority #1 and #2. This is Pleo's core competency and reviews bear it out: G2 4.7/5 (~1,417 reviews), Trustpilot 3.9/5 (~1,520 reviews), Capterra strongly positive. Most-praised themes: ease of use, intuitive interface, physical + virtual Mastercard cards, and the native mobile app's real-time "take a photo of your receipt" prompt after each purchase with automatic categorisation and receipt-matching. Caveats from reviews: the email-inbox receipt-"fetching" feature is unreliable, occasional app-stability issues, AI receipt recognition sometimes imperfect, and customer support is a recurring complaint (slow responses; multi-week/multi-month delays on frozen-account and offboarding issues). Net: the cards product and receipt-capture app are genuinely good — the customer's two core needs are well served by the incumbent; the weak spots are support and the API read-side, not the cards.