Mercury vs Ramp

Close automation

1. ai-native userUse AI automations to close my books faster each month

   weight 2 · round to Ramp
   Mercury✓fullclaimed7/10

   Mercury explicitly advertises syncing with QuickBooks, Xero, and NetSuite plus AI-powered automations to 'close your books faster' (mercury-docs-6), backed by supporting AI automation features like auto-reading bills, auto-attaching receipts, and API write actions for categorizing transactions/invoices (mercury-docs-3, mercury-docs-5, mercury-docs-29). Missing for 10: independent/hands-on verification that the accounting sync and AI automations actually reduce close time, and no detail on depth of QBO/Xero/NetSuite reconciliation accuracy.

   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Write actions such as making payments, categorizing transactions, creating invoices, and uploading receipts”
   • [claimed-docs] “Generate and send invoices based on CRM, billing, or usage data”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp documents AI-driven auto-coding, auto-categorization, real-time bidirectional ERP sync eliminating manual journal entries, and dedicated AI agents for auto-coding/fraud/approvals/payments, directly targeting faster book closing; broad accounting integration list (NetSuite, QuickBooks, Sage Intacct, etc.) supports this at scale. Missing for 10: independent/hands-on verification of close-time reduction and no specific 'days to close' benchmark or customer-reported close-cycle metric.

   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Accounting: NetSuite, Sage Intacct, QuickBooks Online, QuickBooks Desktop, Xero, Workday Financial Management, Acumatica, Microsoft Dynamics…”

   proof ↗⚑ flag

2. ai-native userHave AI automatically assign GL codes to transactions across entities to accelerate close

   weight 3 · round to Ramp
   Mercury~partialclaimed3/10

   Mercury's docs mention 'AI-powered automations to close your books faster' when syncing with QuickBooks/Xero/NetSuite, and the API exposes a Categories resource plus 'Update transaction metadata' endpoint, suggesting some categorization/GL-code capability. However, there is no concrete evidence of AI automatically assigning GL codes specifically, nor any support for multi-entity operations. Missing for 10: explicit documentation of automated GL-code/category assignment logic, evidence of multi-entity/consolidated close workflows, and any hands-on or independent confirmation of this working in practice.

   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp documents AI-driven auto-coding of transactions (auto-categorization based on transaction details/history/feedback, syncing to ERP) alongside a dedicated 'auto-coding' AI agent, multi-entity support with consolidated reporting, and real-time bidirectional ERP sync that eliminates manual journal entries — directly supporting cross-entity GL coding to accelerate close. Missing for 10: independent/hands-on evidence specifically validating GL-coding accuracy across multiple entities during a close cycle, and no third-party accounting-team testimonial on close-time reduction.

   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”

   proof ↗⚑ flag

Developer accounting access

1. developerView and manage accounting data through a dedicated API

   weight 1 · round to Mercury
   Mercury✓fullprobed9/10

   Mercury publishes a dedicated REST API with extensive accounting-related resources — transactions, categories, statements, invoices, customers/AR, webhooks, treasury — supporting both viewing (list/get) and managing (create/update/delete/cancel) data, backed by OAuth2, scoped tokens, a sandbox environment, versioned docs, an official CLI (verified working via probe), and a Go SDK. Probes independently confirm the CLI installs and lists real resource commands and the sandbox/interactive docs are functional, giving strong first-party plus hands-on corroboration. Missing for 10: independent third-party developer reviews of the core REST API itself (vs. MCP) and a publicly downloadable OpenAPI spec (confirmed internal-only via probe).

   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”
   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [claimed-docs] “OAuth2 API: Start OAuth2 web flow; Obtain an access token — Mercury supports OAuth2 authorization for third-party/programmatic access alongs…”
   • [claimed-docs] “Our Sandbox environment is designed to make it easy for you to test API calls in a safe, simulated version of Mercury — no real money involv…”
   • [claimed-docs] “There are three types of tokens: read-only, read-write, and custom.”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”
   • [claimed-docs] “Every endpoint page on the API Reference hub (docs.mercury.com/reference, ReadMe) embeds a live request runner and generated code samples: "…”
   • [claimed-docs] “API base paths are versioned under /api/v1/ ("get https://api.mercury.com/api/v1/account/{accountId}/cards") and the docs hub nav publishes …”
   • [claimed-docs] “Official Go SDK, MercuryTechnologies/mercury-go: "The Mercury Go library provides convenient access to the Mercury REST API from application…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”

   proof ↗⚑ flag

   Ramp✓fullprobed8/10

   Ramp documents a dedicated Developer API with OpenAPI spec, machine-readable docs (llms.txt, llms-api.txt), and bidirectional ERP sync for accounting data (transactions, coding, GL sync), confirmed by a live probe showing the API docs endpoint is reachable. Missing for 10: no independent developer testimonial or hands-on confirmation of actual accounting-data CRUD via the API, and no detail on specific accounting endpoints/scopes.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”

   proof ↗⚑ flag

Erp sync

1. finance-leadSync transactions and expenses automatically with my accounting software

   weight 3 · round to Ramp
   Mercury~partialclaimed6/10

   Mercury explicitly advertises syncing with QuickBooks, Xero, and NetSuite plus AI-powered receipt/category automation (mercury-docs-6, mercury-docs-5, mercury-docs-28), and its API exposes transaction/category/statement endpoints that could underlie such syncs (mercury-docs-12). However, this is purely first-party marketing copy with no docs detailing sync mechanics, frequency, or field-mapping, and no independent/hands-on confirmation that the QuickBooks/Xero/NetSuite sync works reliably in practice. Missing for 10: technical documentation of the sync mechanism, independent or community verification of accounting-software sync reliability, and detail on which transaction/expense fields are mapped.

   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction.”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”

   proof ↗⚑ flag

   Ramp✓fullcommunity9/10

   Ramp documents real-time bidirectional ERP sync, automatic categorization/coding synced directly to accounting systems, and a broad list of accounting integrations (NetSuite, QuickBooks, Xero, Sage Intacct, etc.), plus community corroboration of the platform working well for expense tracking. missing for 10: independent hands-on verification specifically of accounting-sync accuracy/reconciliation rather than vendor claims.

   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Accounting: NetSuite, Sage Intacct, QuickBooks Online, QuickBooks Desktop, Xero, Workday Financial Management, Acumatica, Microsoft Dynamics…”
   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

2. finance-leadRely on real-time bidirectional sync with my ERP instead of manual journal entries

   weight 3 · round to Ramp
   Mercury~partialclaimed4/10

   Mercury advertises syncing with QuickBooks, Xero, and NetSuite to help close books faster (mercury-docs-6), which addresses the ERP-integration theme, but there is no detail confirming true real-time bidirectional sync (versus periodic export/import) or automated journal-entry creation, and no independent/hands-on evidence validating the sync's reliability or completeness. Missing for 10: documentation of bidirectional data flow direction, real-time sync frequency/latency, automated journal entry mapping, and independent confirmation the integration works as described.

   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp explicitly claims real-time bidirectional sync with ERPs eliminating manual journal entries, backed by auto-categorization and sync to ERP details, plus a broad list of supported ERP integrations (NetSuite, Sage Intacct, QuickBooks, etc.). Missing for 10: independent/hands-on verification of true bidirectional (not just push) sync and any community confirmation of eliminating manual JE work.

   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Accounting: NetSuite, Sage Intacct, QuickBooks Online, QuickBooks Desktop, Xero, Workday Financial Management, Acumatica, Microsoft Dynamics…”

   proof ↗⚑ flag

Account structure

1. finance-leadView account and routing numbers and generate a bank verification letter anytime

   weight 1 · round drawn
   Mercury—none0/10

   The evidence pack covers cards, payments, invoicing, API/MCP tooling, and statement PDF downloads, but nowhere mentions displaying account/routing numbers or generating a bank verification letter — a standard banking feature that a business bank like Mercury could plausibly offer, but no evidence confirms it exists.

   ⚑ flag

   Ramp—none0/10

   No evidence in the pack mentions account/routing numbers, bank verification letters, or any similar account-detail retrieval feature for Ramp accounts.

   ⚑ flag

2. finance-leadOpen multiple checking sub-accounts and auto-allocate incoming deposits across them

   weight 2 · round to Mercury
   Mercury✓fullcommunity7/10

   A long-term hands-on user reports creating 'dozens of purpose-named accounts with auto-funding rules,' directly confirming both multiple checking sub-accounts and automated allocation of funds across them. No first-party Mercury docs in the pack explicitly describe the sub-account/auto-allocation feature or its configuration options, so evidence rests on a single community account rather than documented capability. Missing for 10: first-party docs on creating sub-accounts and configuring auto-allocation rules, and additional independent corroboration.

   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp—none0/10

   Evidence shows only auto top-up from a single linked checking account to Ramp's card account with target-balance automation (ramp-docs-6), not the creation of multiple checking sub-accounts or auto-allocation of incoming deposits across them. Missing for 10: any mention of multiple sub-accounts, deposit-splitting/allocation rules, or treasury account structuring.

   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”

   proof ↗⚑ flag

Bill pay

1. ai-native userHave AI read incoming bills and auto-populate payment details for my review

   weight 3 · round to Ramp
   Mercury~partialprobed6/10

   Mercury explicitly markets an AI bill-pay feature that reads bills, auto-populates payment details, and remembers past recipients for quick approval, directly matching the story (mercury-docs-3). However, this is a single marketing-line claim with no deeper documentation of the review/approval workflow, no independent or hands-on corroboration, and the separate MCP tool inventory confirms only read-only capabilities with no bill-reading or auto-populate tools exposed there. Missing for 10: detailed product documentation of the bill-reading/approval UI, independent user reports confirming accuracy, and API/MCP support for this specific workflow.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp Bill Pay explicitly describes AI reading/matching vendor invoices, auto-coding to GL, PO matching, and routing for approval before payment, directly matching the AP auto-population-for-review story, backed by the four dedicated AI agents (auto-coding, fraud, routing, payment) and ERP sync docs. Missing for 10: independent hands-on verification of invoice-reading accuracy and no third-party review specifically confirming bill-reading AI performance.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”

   proof ↗⚑ flag

2. finance-leadUpload bills and route them through an approval workflow before paying vendors

   weight 3 · round to Ramp
   Mercury~partialprobed7/10

   Mercury's bill-pay feature explicitly supports uploading/reading bills via AI and an approve-then-pay flow (mercury-docs-3), plus granular permissions letting specific roles (e.g., an accountant) execute payments (mercury-docs-11) and spend/approval controls (mercury-docs-10, mercury-docs-38). The MCP tool inventory also lists dedicated approval-workflow endpoints like listSendMoneyApprovalRequests and getSafeRequest(s) (mercury-probe-5), corroborating a real multi-step approval mechanism for vendor payments. Missing for 10: no first-party documentation detailing the full workflow UI/steps (multi-approver routing rules, thresholds), and no independent/hands-on user report specifically validating the bill-approval process end-to-end.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Built-in permissions means our accountant can easily make payments — literally one click and it’s done.”
   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp✓fullcommunity8/10

   Ramp documents bill upload (drag-and-drop invoices), automatic PO matching and GL coding, dynamic multi-department approval routing, and automated vendor payment (ramp-docs-2, ramp-docs-16, ramp-docs-17), corroborated by a positive hands-on community account of easy approval-to-payment workflows (ramp-comm-2). Missing for 10: independent third-party audit of the full bill-pay approval chain and more granular detail on rejection/exception handling in approvals.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

3. finance-leadSet up approval permissions so designated teammates can approve and send payments with one click

   weight 2 · round to Mercury
   Mercury✓fullcommunity8/10

   Mercury docs explicitly describe granular user permissions and built-in approval permissions that let designated teammates (e.g. an accountant) approve and send payments in one click, and product marketing highlights team spend controls with approvals. Community evidence corroborates real-world use of card/account permission controls, though not specifically the one-click approval flow. Missing for 10: independent/hands-on confirmation of the one-click approval UX itself and detail on how granular approval roles are configured (e.g., approval thresholds, multi-approver workflows).

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Built-in permissions means our accountant can easily make payments — literally one click and it’s done.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialcommunity6/10

   Ramp docs describe dynamic approval routing across departments and one-click, AI-driven payment flows (vendor invoice matched, coded, routed for approval, and paid), plus AI agents that handle approval routing and automatic payment, implying configurable permissions for who can approve/send. Community evidence corroborates a fast, one-click approve-and-fund experience for expenses. However, there's no explicit documentation of granular permission-setting UI/roles specifically for designating which teammates can approve and send payments with one click. Missing for 10: explicit admin-permission configuration screens/roles documentation, and independent confirmation of one-click send-payment permission setup.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

4. ai-native userHave vendor invoices automatically matched to purchase orders, coded, and routed for payment

   weight 2 · round to Ramp
   Mercury~partialclaimed4/10

   Mercury's bill pay AI reads and auto-populates bill details and remembers recipients for quick approval (mercury-docs-3), and permissions allow routing payments to approvers like accountants (mercury-docs-11), but there is no evidence of purchase-order matching or GL/expense coding logic tying invoices to POs — core parts of the described workflow are unevidenced. missing for 10: purchase order matching/reconciliation, explicit invoice coding to GL categories tied to POs, and a documented multi-step approval routing workflow for AP.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Built-in permissions means our accountant can easily make payments — literally one click and it’s done.”
   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp's docs directly describe the exact workflow: invoices dragged in are auto-matched to POs, auto-coded to GL, routed for approval, and paid, with dedicated AI agents for coding, approval routing, and payment execution. This is corroborated by ERP sync and categorization details, though evidence is entirely vendor-sourced with no independent hands-on validation of AP-specific matching accuracy. Missing for 10: independent/community confirmation of invoice-to-PO matching accuracy and edge-case handling.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Real-time bidirectional sync with ERPs eliminates manual journal entries”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”

   proof ↗⚑ flag

Invoicing

1. finance-leadCreate and send branded invoices with built-in payment collection

   weight 2 · round to Mercury
   Mercury✓fullclaimed7/10

   Mercury explicitly supports sending manual/automatic invoices with flexible payment methods and customer management (mercury-docs-4), a dedicated Invoices API (create/list/get/update/cancel, download PDF) (mercury-docs-13), and invoice volume tied to paid plans (mercury-docs-21). However, evidence does not confirm invoice 'branding' customization (logos/colors) or hands-on/community confirmation of the invoicing UX itself. missing for 10: independent/hands-on evidence of invoice branding customization options, and third-party confirmation of the payment-collection experience from a customer's perspective.

   • [claimed-docs] “Send manual and automatic invoices, accept flexible payment methods, and manage customer details right from your Mercury account.”
   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [claimed-docs] “Create up to 500 invoices/month on Mercury Plus, or unlimited invoices with Pro”
   • [claimed-docs] “Generate and send invoices based on CRM, billing, or usage data”

   proof ↗⚑ flag

   Ramp—none0/10

   Ramp's evidence covers expense management, bill pay/AP automation, procurement, and ERP sync, but there is no mention of creating or sending branded customer-facing invoices with payment collection (accounts receivable), which is a distinct capability from bill pay.

   ⚑ flag

Money movement

1. founderSend money abroad that arrives in under a minute

   weight 2 · round drawn
   Mercury—none0/10

   Mercury advertises 'no-fee USD payments around the globe' but nothing in the evidence specifies transfer speed, let alone a sub-minute arrival time for international payments; typical wire/ACH rails imply multi-day settlement, and no probe or doc confirms near-instant delivery abroad.

   • [claimed-docs] “Send no-fee USD payments around the globe”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence in the pack addresses international money transfer or cross-border payment speed; Ramp's evidence covers cards, bill pay, ERP sync, and vendor integrations but nothing about sending money abroad or transfer time guarantees. missing for 10: any mention of international/cross-border wire or transfer capability, evidence of transfer speed, currency/FX support.

   ⚑ flag

2. finance-leadSend domestic ACH and wire payments to vendors

   weight 3 · round to Mercury
   Mercury✓fullcommunity7/10

   Mercury's core banking product supports sending ACH transfers and wires, evidenced by API docs referencing 'initiate ACH transfers' and payment creation (mercury-docs-16, mercury-docs-29, mercury-docs-9), plus independent community corroboration of reliable wire transfers in production use (mercury-comm-1). AI bill-pay features (mercury-docs-3) further support vendor payment workflows for finance leads. missing for 10: dedicated documentation detailing wire vs ACH fees, transfer limits, cutoff times, and a full end-to-end vendor payment approval workflow beyond generic mentions.

   • [claimed-docs] “Pull balances, list transactions, and initiate ACH transfers — all through a single REST API”
   • [claimed-docs] “Write actions such as making payments, categorizing transactions, creating invoices, and uploading receipts”
   • [claimed-docs] “Find any transaction, vendor, or card, or jump straight to creating payments, transfers, and more — all from one universal search bar.”
   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialclaimed4/10

   Ramp's docs describe vendor invoices being routed, approved, and 'paid' automatically via a dedicated payment AI agent, implying built-in bill-pay/payment execution, but no evidence explicitly confirms domestic ACH or wire rail support, transfer limits, or same-day options. Missing for 10: explicit mention of ACH/wire payment methods, processing times, and any independent confirmation that payments are actually disbursed via bank rails rather than just approval routing.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”

   proof ↗⚑ flag

3. finance-leadSend international payments in local currencies with transparent fees

   weight 3 · round drawn
   Mercury—none0/10

   Mercury's documented international payment feature is explicitly USD-only ('Send no-fee USD payments around the globe' — mercury-docs-7), with no evidence of multi-currency/local-currency payment support, FX conversion, or transparent FX fee disclosure anywhere in the API, MCP, or product docs.

   • [claimed-docs] “Send no-fee USD payments around the globe”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence in the pack addresses international payments, local currency support, or FX fee transparency—only US-focused corporate card, expense, and AP automation features are documented.

   ⚑ flag

Multi currency

1. founderHold and manage balances in multiple currencies from one account

   weight 2 · round drawn
   Mercury—none0/10

   Evidence shows Mercury offers USD checking/savings/Treasury accounts and no-fee USD international payments (mercury-docs-7, mercury-docs-39), but nothing indicates the ability to hold or manage balances in foreign currencies (e.g., EUR, GBP) within a single account — all documented balances, cards, and API/MCP tools reference USD only. Missing for 10: any documentation of multi-currency account creation, foreign-currency balance holding, or currency conversion/FX management features.

   • [claimed-docs] “Send no-fee USD payments around the globe”
   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”
   • [claimed-docs] “Track your balance - easy access to account level balances, with ability to download statements as PDFs”

   proof ↗⚑ flag

   Ramp—none0/10

   The evidence pack covers card issuance, expense automation, ERP sync, and integrations, but contains no mention of multi-currency account balances or FX holding capabilities. Multi-currency balance management is a fair axis for a corporate finance/spend platform, so absence of evidence yields 'none'.

   ⚑ flag

2. founderReceive payments using local account details in multiple currencies

   weight 2 · round drawn
   Mercury—none0/10

   Evidence shows Mercury offers USD checking/savings accounts and sending no-fee USD payments globally, but there is no evidence of local currency receiving account details (e.g., local IBAN/EUR, GBP, local clearing numbers) for accepting multi-currency payments — this is a fair question for a business banking product but Mercury's evidence pack is USD-centric throughout.

   • [claimed-docs] “Send no-fee USD payments around the globe”
   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”

   proof ↗⚑ flag

   Ramp—none0/10

   Ramp's evidence pack covers cards, expense management, bill pay, ERP sync, and banking integrations, but nothing describes receiving inbound payments via local account details (e.g., local IBAN/ACH/SWIFT receiving accounts) in multiple currencies — this is a receivables/multi-currency collection capability not mentioned anywhere in the pack. Missing for 10: any mention of local currency receiving accounts, multi-currency invoicing/collections, or global payment-in details.

   ⚑ flag

Operational efficiency

1. finance-leadSearch across all transactions, vendors, and cards from one universal search bar and jump straight into initiating a payment

   weight 1 · round to Mercury
   Mercury✓fullclaimed7/10

   Mercury's own marketing docs explicitly describe a universal search bar to find any transaction, vendor, or card and jump straight into creating payments/transfers, directly matching the story. missing for 10: no independent/hands-on verification or screenshots of the search UI in action, and no community corroboration of this specific feature.

   • [claimed-docs] “Find any transaction, vendor, or card, or jump straight to creating payments, transfers, and more — all from one universal search bar.”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence pack item describes a universal/global search bar spanning transactions, vendors, and cards, nor any 'jump straight into initiating a payment' from search results. The evidence covers auto-categorization, invoice matching, approval routing, and integrations, but nothing about a unified search UX.

   ⚑ flag

Payment transparency

1. finance-leadSee the exact delivery estimate for an ACH or wire transfer before confirming it

   weight 2 · round drawn
   Mercury—none0/10

   The evidence pack covers cards, invoicing, API/MCP/CLI tooling, and sandbox testing, but nothing describes a transfer confirmation UI showing an estimated delivery date/time for ACH or wire payments before the user confirms.

   ⚑ flag

   Ramp—none0/10

   No evidence pack item mentions ACH/wire delivery time estimates or any pre-confirmation display of settlement dates for payments; evidence covers card capture, invoice matching, ERP sync, integrations, and dev tools, none of which touch payment delivery estimates.

   ⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Ramp
   Mercury✓fullprobed8/10

   Mercury explicitly documents an llms.txt endpoint for AI agents ('For AI agents: visit https://docs.mercury.com/llms.txt for an index of all pages formatted in Markdown and endpoints in OpenAPI. Append .md to any documentation page URL...'), and a live probe confirms llms.txt returns HTTP 200 with the expected markdown index content. This directly satisfies the story of pointing an agent at agent-oriented docs. Missing for 10: the OpenAPI spec referenced by llms.txt is not actually publicly downloadable (404s on all conventional paths, openapiVisibility set to admin-only), a minor inconsistency between the llms.txt promise and reality.

   • [claimed-docs] “Mercury API docs state: 'For AI agents: visit https://docs.mercury.com/llms.txt for an index of all pages formatted in Markdown and endpoint…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.mercury.com/llms.txt # Mercury API Documentation > Documentation for Mercury API Append .md to an…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.mercury.com/openapi.json, https://docs.mercury.com/swagger.json, https://docs.mercury.c…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”

   proof ↗⚑ flag

   Ramp✓fullprobed9/10

   Ramp publishes a documented llms.txt indexing structure (llms.txt, llms-guides.txt, llms-api.txt, llms-full.txt, OpenAPI spec) explicitly designed for LLM/agent consumption, and a live probe confirms HTTP 200 with machine-readable usage instructions. Missing for 10: independent third-party corroboration of an agent actually consuming these files in a real workflow.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [claimed-docs] “If the URL is under /developer-api/v1/rate-limiting -> /llms-guides/rate-limiting.txt”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Mercury
   Mercury✓fullprobed8/10

   Mercury ships an official CLI (mercury-cli, verified via probe: install, version, full command tree) explicitly runnable from terminal, script, or CI pipeline, plus a REST API with scoped API tokens, an OAuth2 flow, a sandbox environment, and an official Go SDK — all suitable for headless/CI automation. Docs explicitly state 'Run Mercury operations from your terminal, a script, or a CI pipeline' and provide sandbox base URLs for safe automated testing. missing for 10: no independent third-party report of the CLI actually running inside a CI pipeline end-to-end, no official npm/PyPI SDK (only Go), and no public OpenAPI spec download for tooling generation.

   • [claimed-docs] “Run Mercury operations from your terminal, a script, or a CI pipeline”
   • [claimed-docs] “Issue scoped API tokens with fine-grained permissions”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [claimed-docs] “Our Sandbox environment is designed to make it easy for you to test API calls in a safe, simulated version of Mercury — no real money involv…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”
   • [claimed-docs] “Official Go SDK, MercuryTechnologies/mercury-go: "The Mercury Go library provides convenient access to the Mercury REST API from application…”
   • [claimed-docs] “Test safely in the sandbox, then swap one URL for production”

   proof ↗⚑ flag

   Ramp~partialprobed6/10

   Ramp provides a documented official CLI (ramp-cli) and a full REST/OpenAPI developer API plus machine-readable docs (llms.txt, llms-api.txt, openapi/developer-api.json), which together enable scripted/headless automation suitable for CI pipelines. However, there is no first-party or community evidence of actual CI usage, rate-limit guidance for automated pipelines, or examples of running the CLI unattended. Missing for 10: documented CI/CD integration examples, independent confirmation of headless CLI use in production pipelines, and details on authentication/rate limits for automated batch jobs.

   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [claimed-docs] “If the URL is under /developer-api/v1/rate-limiting -> /llms-guides/rate-limiting.txt”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Mercury
   Mercury✓fullprobed8/10

   Mercury ships an official, hosted MCP server at https://mcp.mercury.com/mcp, documented and independently verified live via probes showing OAuth2-gated (PKCE, dynamic client registration) access and a concrete inventory of 31 read-only tools (balances, transactions, cards, invoices, etc.), matching the docs' description of connecting agents to financial context. Missing for 10: write/action capabilities via MCP (currently read-only by design) and independent community corroboration of real-world agent usage beyond vendor docs/probes.

   • [claimed-docs] “Set the MCP server URL to `https://mcp.mercury.com/mcp`.”
   • [claimed-docs] “What's my balance today?”
   • [claimed-docs] “Track your balance - easy access to account level balances, with ability to download statements as PDFs”
   • [claimed-docs] “The ability to revoke access at any time from your Mercury dashboard”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp✓fullprobed7/10

   Ramp is a finance SaaS platform (not itself an agent), so shipping an official MCP server is a fair, applicable axis, and evidence confirms one exists at support.ramp.com/ramp-mcp alongside machine-readable LLM/API docs and an open API for connectivity. Missing for 10: detailed documentation of MCP server capabilities/tools, and independent/hands-on confirmation that the MCP server works as advertised.

   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Mercury
   Mercury✓fullprobed9/10

   Mercury ships an official, actively maintained CLI (mercury-cli, Mercury's own GitHub org) with a documented installer, verified working `--version`/`--help`, full resource command tree (accounts, cards, payments, invoices, treasury, etc.), auth flows, sandbox/production environments, and even an official agent-skills repo built specifically to drive the CLI for AI-native workflows. missing for 10: independent third-party (non-Mercury) reviews or adoption reports of the CLI specifically, and confirmation of write-action success beyond documented help output.

   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”
   • [claimed-docs] “Run Mercury operations from your terminal, a script, or a CI pipeline”

   proof ↗⚑ flag

   Ramp✓fullprobed7/10

   A probe confirms an official CLI repo at github.com/ramp-public/ramp-cli, satisfying the core ask for an AI-native official CLI. Missing for 10: no first-party docs describing CLI features/usage in depth, no independent hands-on review or community corroboration of the CLI's capabilities.

   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Mercury
   Mercury✓fullprobed9/10

   Mercury publishes a comprehensive, versioned REST API (accounts, cards, transactions, invoices, payments, treasury) with interactive docs, OAuth2 and scoped API tokens, a sandbox environment, an official Go SDK, and an official CLI (verified via probe) covering the full resource surface — clearly documented and independently confirmed as working. It also explicitly caters to AI agents via llms.txt, agent skills repo, and a hosted MCP server. missing for 10: no publicly downloadable OpenAPI spec (confirmed gated to admin-only) and no official Python/Node SDKs, only community packages.

   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”
   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [claimed-docs] “Mercury API docs state: 'For AI agents: visit https://docs.mercury.com/llms.txt for an index of all pages formatted in Markdown and endpoint…”
   • [claimed-docs] “OAuth2 API: Start OAuth2 web flow; Obtain an access token — Mercury supports OAuth2 authorization for third-party/programmatic access alongs…”
   • [claimed-docs] “Issue scoped API tokens with fine-grained permissions”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”
   • [claimed-docs] “Every endpoint page on the API Reference hub (docs.mercury.com/reference, ReadMe) embeds a live request runner and generated code samples: "…”
   • [claimed-docs] “Official Go SDK, MercuryTechnologies/mercury-go: "The Mercury Go library provides convenient access to the Mercury REST API from application…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”

   proof ↗⚑ flag

   Ramp✓fullprobed8/10

   Ramp publishes a documented public Developer API with OpenAPI spec, LLM-readable docs (/llms.txt, /llms-api.txt), and rate-limiting guides, confirmed by direct probes (200 OK) plus an official MCP server and CLI extending programmatic/AI-native access. Missing for 10: independent third-party developer reports of building against the API, and more detail on auth/scopes beyond the doc index.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [claimed-docs] “If the URL is under /developer-api/v1/rate-limiting -> /llms-guides/rate-limiting.txt”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Mercury
   Mercury✓fullprobed8/10

   Mercury documents scoped/least-privilege credential issuance for agents: read-only, read-write, and custom API tokens (mercury-docs-35), 'Issue scoped API tokens with fine-grained permissions' (mercury-docs-20), OAuth2 authorization flows (mercury-docs-15), and dashboard-based revocation (mercury-docs-25). This is independently corroborated by a live probe of the hosted MCP server showing OAuth2/PKCE-gated access with explicit granular scopes (read, offline_access) and a read-only-only tool inventory (mercury-probe-4, mercury-probe-5), confirming scoped agent credentials work in practice. Missing for 10: independent hands-on verification of actually minting a 'custom' scoped token end-to-end and assigning it to a live agent workflow.

   • [claimed-docs] “Issue scoped API tokens with fine-grained permissions”
   • [claimed-docs] “There are three types of tokens: read-only, read-write, and custom.”
   • [claimed-docs] “The ability to revoke access at any time from your Mercury dashboard”
   • [claimed-docs] “OAuth2 API: Start OAuth2 web flow; Obtain an access token — Mercury supports OAuth2 authorization for third-party/programmatic access alongs…”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp—none0/10

   Ramp has a developer API, OpenAPI spec, and an official MCP server, so scoped credentialing is a fair capability to ask about for an API/agentic platform — but the evidence pack contains no mention of API keys, OAuth scopes, role-based permissions, or any mechanism to issue least-privilege credentials specifically for an AI agent.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Ramp
   Mercury~partialprobed5/10

   Mercury ships one official SDK (Go, generated via Stainless) plus a public REST API, official CLI, and MCP server, giving AI-native builders real programmatic surface area, but there is no official JS/TypeScript or Python SDK — only community packages (e.g. n8n-nodes-mercury) — and the OpenAPI spec is deliberately kept non-public (openapiVisibility:'admin'), limiting SDK-generation/tooling for other languages. missing for 10: official SDKs in mainstream AI-stack languages (JS/Python), publicly downloadable OpenAPI spec, independent hands-on confirmation of SDK usage beyond docs.

   • [claimed-docs] “Official Go SDK, MercuryTechnologies/mercury-go: "The Mercury Go library provides convenient access to the Mercury REST API from application…”
   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”
   • [claimed-docs] “Pull balances, list transactions, and initiate ACH transfers — all through a single REST API”
   • [claimed-docs] “Test safely in the sandbox, then swap one URL for production”

   proof ↗⚑ flag

   Ramp~partialprobed7/10

   Ramp provides a public developer API with OpenAPI spec, LLM-friendly docs (llms.txt/llms-api.txt), an official CLI, and an official MCP server, all of which let AI-native developers build against Ramp programmatically. However, no evidence of dedicated language SDKs (e.g. Python/Node client libraries) is present—only raw API/OpenAPI access plus CLI/MCP tooling. Missing for 10: official first-party SDK packages in specific languages, independent developer corroboration of SDK usage.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [claimed-docs] “If the URL is under /developer-api/v1/rate-limiting -> /llms-guides/rate-limiting.txt”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Mercury
   Mercury✓fullprobed7/10

   Mercury's Accounts Receivable API explicitly documents webhook endpoint management (Create/Update/Verify/Get/Delete) and an Events API to retrieve emitted events, and the CLI also exposes a dedicated 'webhooks' resource command, confirming first-class webhook subscription support. Missing for 10: independent/hands-on confirmation of actually receiving a webhook payload, and documentation of supported event types/payload schemas.

   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”

   proof ↗⚑ flag

   Ramp—none0/10

   The evidence pack details Ramp's developer API, OpenAPI spec, MCP server, and CLI, but never mentions webhook subscriptions or event notifications anywhere. Webhooks are a plausible capability for a platform with a full developer API, so absence of evidence means this axis is unmet rather than inapplicable.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Ramp
   Mercury~partialprobed5/10

   Mercury offers AI-driven automation for specific workflows (auto-reading bills, auto-attaching receipts, AI-powered bookkeeping close) and an MCP server plus agent skills like mercury-analyze-spend and mercury-detect-anomaly that let AI query balances/transactions in natural language and surface anomalies. However, there's no evidence of proactive, in-product generated insights/dashboards (e.g., spend trend analysis, cash-flow forecasting, or automatic suggestions surfaced in the UI) — the MCP tools are read-only query/retrieval, not generative insight/suggestion features, and the skills repo is a separate CLI-driven agent toolkit rather than an in-product experience. missing for 10: proactive/native in-app AI insights or suggestions dashboard, evidence of forecasting or recommendation generation, independent confirmation these AI features produce actionable suggestions beyond data retrieval.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”
   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”
   • [claimed-docs] “you can ask natural language questions like \`What's my balance today?\` and \`Graph my last 6 months of transactions\`”

   proof ↗⚑ flag

   Ramp✓fullcommunity7/10

   Ramp documents multiple AI-generated insights/suggestions embedded in the product itself: auto-filled memos/categories at swipe, AI-driven invoice coding and matching, hotel rebooking suggestions, contract/screenshot parsing for intake, and dedicated AI agents for coding, fraud, approvals and payments. These are first-party claims with some corroboration via community praise of smooth automated workflows (e.g., instant card issuance and approval flows), though independent verification of the 'AI-generated insight' quality specifically is thin. Missing for 10: independent hands-on evaluation of AI insight accuracy/usefulness, and clearer distinction between rule-based automation vs. true generative insights.

   • [claimed-docs] “Auto-receipt capture at the moment of card swipe with AI-filled memos and categories”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Hotel rate monitoring with automatic rebooking when prices drop $50+”
   • [claimed-docs] “AI-powered intake parses contracts and screenshots to auto-populate request forms”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Ramp
   Mercury~partialprobed5/10

   Mercury ships several automation primitives that can run in the background — webhooks/events API for reactive automation, auto-invoicing, AI-driven receipt matching and bookkeeping sync, plus an official CLI/API usable from scripts or CI pipelines and an 'agent skills' repo for CLI-driven automations. However, the flagship agent-facing surface (the hosted MCP server) is explicitly read-only (31 get/list tools, no write actions), so autonomous write-side actions (payments, invoices) would have to go through the API/CLI/webhooks rather than a persistent scheduled agent runtime, and no dedicated scheduler/cron/'run this automation on a trigger' product feature is documented. Missing for 10: a first-party scheduling/trigger engine for autonomous multi-step workflows, evidence of write-capable autonomous agent execution, and independent confirmation that background automations run reliably unattended.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Send manual and automatic invoices, accept flexible payment methods, and manage customer details right from your Mercury account.”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Run Mercury operations from your terminal, a script, or a CI pipeline”
   • [claimed-docs] “Write actions such as making payments, categorizing transactions, creating invoices, and uploading receipts”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”
   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”

   proof ↗⚑ flag

   Ramp✓fullclaimed8/10

   Ramp's docs describe multiple autonomous background automations — auto-receipt capture, invoice matching/coding/approval/payment, hotel rate monitoring with auto-rebooking, auto top-up with balance targets, and four dedicated AI agents handling coding, fraud, approvals, and payment end-to-end without manual triggering. This directly matches the story of AI-native background automation. Missing for 10: independent/hands-on verification that these automations run fully autonomously in production (community evidence only confirms manual card/expense workflows, not the autonomous agent features).

   • [claimed-docs] “Auto-receipt capture at the moment of card swipe with AI-filled memos and categories”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Hotel rate monitoring with automatic rebooking when prices drop $50+”
   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Ramp
   Mercury—none0/10

   Mercury exposes narrow AI-powered automations (bill scanning, receipt auto-attach, bookkeeping sync) and offers external interfaces (API, CLI, MCP server) for other agents/tools to connect to Mercury data, but there is no evidence of a built-in conversational AI assistant inside the Mercury product itself that a user can delegate tasks to.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp~partialclaimed6/10

   Ramp documents built-in AI agents that autonomously handle auto-coding, fraud prevention, approval routing, and payment, plus AI-powered intake and auto-categorization — evidence of task delegation to embedded AI. However, all evidence is vendor-sourced marketing copy with no independent/hands-on corroboration of an interactive assistant experience or how a user explicitly 'delegates' vs. the AI running fully automatically in the background. Missing for 10: independent user reports of interacting with/delegating to the assistant, detail on the assistant's conversational/task-delegation UX rather than automated background agents.

   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “AI-powered intake parses contracts and screenshots to auto-populate request forms”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Ramp
   Mercury~partialprobed7/10

   Mercury ships a live, OAuth-gated hosted MCP server confirmed via probe to support natural-language queries like 'What's my balance today?' and 'Graph my last 6 months of transactions' (mercury-docs-23, mercury-docs-32, mercury-probe-4). However, independent tool-inventory verification shows all 31 MCP tools are read-only (get*/list*) with zero write/send/create actions, so natural-language commands can query data but cannot execute operations like payments or invoice creation. missing for 10: natural-language-driven write/action capability (payments, transfers, invoice creation) via MCP, and broader hands-on confirmation beyond query examples.

   • [claimed-docs] “What's my balance today?”
   • [claimed-docs] “you can ask natural language questions like \`What's my balance today?\` and \`Graph my last 6 months of transactions\`”
   • [claimed-docs] “Give your agents the same financial context you have — no code required”
   • [claimed-docs] “Query balances, transaction history, and account data in natural language”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp✓fullprobed7/10

   Ramp publishes an official MCP server (support.ramp.com/ramp-mcp) plus llms.txt/CLI docs, which directly enables AI agents/assistants to operate Ramp via natural-language commands, and it also ships internal AI agents for coding/approval/payment automation. missing for 10: hands-on/independent evidence of a user actually issuing natural-language commands through the MCP server, and detail on what actions/scopes the MCP server exposes.

   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Mercury
   Mercury✓fullprobed8/10

   Mercury's docs.mercury.com/reference hub is a ReadMe-based interactive API reference with a live 'Try It!' request runner, language-specific code samples (Shell, Node, Ruby, PHP, Python), Bearer auth field, and real endpoint schemas, backed by a sandbox environment for safe testing. This is corroborated by probes confirming the reference page loads and the sandbox base URLs work. Missing for 10: publicly downloadable OpenAPI spec (confirmed 404/admin-only via probes), and no independent hands-on account of actually running examples through the 'Try It' button.

   • [claimed-docs] “Every endpoint page on the API Reference hub (docs.mercury.com/reference, ReadMe) embeds a live request runner and generated code samples: "…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”
   • [claimed-docs] “Our Sandbox environment is designed to make it easy for you to test API calls in a safe, simulated version of Mercury — no real money involv…”

   proof ↗⚑ flag

   Ramp—none0/10

   Evidence confirms Ramp has an OpenAPI spec and machine-readable llms.txt/API docs for developers, but nothing indicates an interactive reference with runnable/try-it-now examples (e.g., a Swagger/Redoc-style console). Missing for 10: any mention of an interactive API console, live request execution, or embedded runnable code samples.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Ramp
   Mercury!disputedcontradicted4/10

   Mercury's llms.txt claims endpoints are documented 'in OpenAPI' format for AI agents (mercury-docs-14), and the docs hub has an interactive API reference, but direct probes of all standard OpenAPI spec paths return 404, and the reverify probe confirms the OpenAPI 3.0 definitions exist internally but are deliberately hidden from public download (showOpenAPIDownload:false, openapiVisibility:admin). So the claimed machine-readable spec is not actually obtainable by an AI-native user. Missing for 10: a publicly downloadable OpenAPI/JSON spec file, confirmation the llms.txt claim resolves to an actual retrievable machine-readable spec.

   • [claimed-docs] “Mercury API docs state: 'For AI agents: visit https://docs.mercury.com/llms.txt for an index of all pages formatted in Markdown and endpoint…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.mercury.com/openapi.json, https://docs.mercury.com/swagger.json, https://docs.mercury.c…”
   • [probe] “PROBE openapi-reverify (2026-09-14): all conventional public spec paths still 404 (https://docs.mercury.com/openapi.json -> 404, https://doc…”

   proof ↗⚑ flag

   Ramp✓fullprobed9/10

   Ramp's developer docs explicitly expose a downloadable OpenAPI spec at /openapi/developer-api.json, confirmed by both documentation references and a live probe returning HTTP 200 at the llms.txt index that lists this spec alongside other machine-readable formats. Missing for 10: independent third-party confirmation that the OpenAPI file itself is complete/valid beyond the vendor's own docs.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference)... or…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Mercury
   Mercury✓fullprobed9/10

   Mercury documents a dedicated sandbox environment (sandbox.mercury.com/signup, api-sandbox.mercury.com base URL, oauth2-sandbox base URL) explicitly stated to use 'dummy data' with 'no real money involved,' and production tokens are rejected in sandbox, enforcing isolation; the API docs and CLI also expose an --environment sandbox|production flag confirming first-class sandbox support across API and CLI. missing for 10: no independent/hands-on community report of actually using the sandbox (only vendor docs and a CLI probe showing the flag exists, not an end-to-end sandbox test transcript).

   • [claimed-docs] “Test safely in the sandbox, then swap one URL for production”
   • [claimed-docs] “Our Sandbox environment is designed to make it easy for you to test API calls in a safe, simulated version of Mercury — no real money involv…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence of a sandbox/test environment for developers or AI agents to safely test API/MCP calls without touching production financial data; docs only reference production API/MCP/CLI endpoints. Missing for 10: any mention of sandbox mode, test API keys, staging environment, or synthetic data support.

   ⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Mercury
   Mercury~partialclaimed6/10

   Mercury's API is clearly versioned (/api/v1/, with a v1-pre/v1/v2 version picker) and Mercury publishes a dated public changelog with migration guidance for breaking changes (e.g. the credit statement sign-convention change), showing real practice around versioning and change management. However, the evidence explicitly states no written deprecation/sunset policy page exists anywhere on docs.mercury.com, so there is no formal documented policy an AI-native integrator could point to for guarantees on deprecation timelines. missing for 10: a published formal deprecation/sunset policy document, explicit version-lifecycle/support-window commitments, and independent confirmation that breaking changes are always preceded by adequate notice.

   • [claimed-docs] “API base paths are versioned under /api/v1/ ("get https://api.mercury.com/api/v1/account/{accountId}/cards") and the docs hub nav publishes …”
   • [claimed-docs] “Mercury publishes a public API changelog (docs.mercury.com/changelog) with dated change notices and migration guidance, e.g. "Credit Stateme…”
   • [claimed-docs] “Every endpoint page on the API Reference hub (docs.mercury.com/reference, ReadMe) embeds a live request runner and generated code samples: "…”

   proof ↗⚑ flag

   Ramp—none0/10

   Evidence shows Ramp has a documented Developer API (OpenAPI spec, guides, rate-limiting docs) with a 'v1' path in the URL, but nowhere is there mention of a versioning scheme or a documented deprecation/sunset policy for API versions.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “If the URL is under /developer-api/v1/rate-limiting -> /llms-guides/rate-limiting.txt”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Mercury~partialprobed6/10

   Mercury exposes per-resource CRUD endpoints (cards, invoices, transactions, categories) and a CLI/API that let scripts loop to create many cards or invoices, and a real customer reports creating 'hundreds of virtual debit cards' and 'dozens of purpose-named accounts' this way. However there's no documented native bulk/batch endpoint (e.g. batch-create invoices/cards in one call), and the MCP server is entirely read-only (list/get only, no write tools), so bulk write actions must be hand-scripted item-by-item via the REST API or CLI rather than a first-class bulk operation feature. Missing for 10: a documented batch/bulk-create API endpoint, bulk operations support in the MCP/agent surface, and vendor documentation explicitly describing bulk workflows.

   • [claimed-docs] “Instantly spin up as many virtual cards as you need. Create cards for any purpose — ad spend, contractors, you name it.”
   • [claimed-docs] “Create up to 500 invoices/month on Mercury Plus, or unlimited invoices with Pro”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”
   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”

   proof ↗⚑ flag

   Ramp~partialprobed6/10

   Ramp exposes a public API, official CLI, and MCP server (ramp-probe-1/2/3) plus CSV export/import (ramp-docs-12) that would let an AI-native user script bulk actions, and AI agents already auto-code/categorize transactions at scale across the platform (ramp-docs-15, ramp-docs-17). However there's no direct evidence of a dedicated bulk-edit/bulk-approve UI or documented batch endpoints for acting on many items simultaneously. Missing for 10: explicit bulk-operation API endpoints or UI (bulk approve, bulk export, batch transaction updates) and independent confirmation these programmatic paths work for large-scale bulk actions.

   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Ramp
   Mercury~partialprobed5/10

   Mercury exposes an Events/Webhooks API (create/update/verify webhook endpoints, get events) that lets external systems react to account events, and ships some built-in automatic behaviors (auto-attach receipts, automatic cashback deposit, AI bill-reading automations). However there is no evidence of a native in-product 'if event X then action Y' rule-builder that AI-native users can configure themselves — webhooks require the user to build their own listener/automation logic outside Mercury, and MCP tools are read-only so agents cannot trigger write actions from natural-language rules. Missing for 10: a documented rules/automation engine or trigger-action builder inside Mercury, and evidence that MCP/agent tooling can autonomously execute rule-based actions.

   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Earn unlimited cashback automatically deposited into your account — no manual redemption or confusing points.”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp~partialprobed6/10

   Ramp ships several built-in automations that fire actions on events—auto top-up triggered by low balance, hotel rate rebooking on price drops, dynamic approval routing, and AI agents auto-coding/paying invoices—showing real automation depth, and its public API/MCP/CLI let developers extend this. However these are largely preset, product-specific automations rather than a general user-defined rule engine (arbitrary trigger→condition→action authoring), and there's no evidence of a configurable rules/webhooks builder for custom event handling. Missing for 10: a documented custom rule-builder UI or webhook/event API for arbitrary automations, and independent confirmation of rule flexibility beyond the shipped presets.

   • [claimed-docs] “Hotel rate monitoring with automatic rebooking when prices drop $50+”
   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Ramp
   Mercury~partialprobed3/10

   Mercury offers some recurring, automation-like features (automatic invoices, AI-powered bill-pay automations, auto-funding rules for accounts) but there is no evidence of a general-purpose scheduler or 'recurring job/workflow' API, CLI command, or MCP tool that an AI-native user could invoke to schedule arbitrary tasks. The MCP server is explicitly read-only (31 get/list tools) and the CLI/API expose transactional resources, not job scheduling. Missing for 10: dedicated recurring-job/cron API or MCP tool, evidence of scheduling arbitrary workflows beyond built-in invoice/bill automations, and any documentation of a scheduler for AI agents.

   • [claimed-docs] “Send manual and automatic invoices, accept flexible payment methods, and manage customer details right from your Mercury account.”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp~partialprobed4/10

   Ramp ships specific built-in recurring automations (auto top-up with target-balance thresholds, hotel rate monitoring/rebooking, dynamic approval routing) that run continuously without user re-triggering, and exposes an API/MCP server/CLI that could be used to build custom scheduled jobs. However there's no evidence of a general-purpose workflow/job scheduler (e.g., cron-style triggers, custom recurring automation builder) that an AI-native user could configure via the API or MCP server themselves — the cited automations are fixed product features, not user-defined scheduled workflows. Missing for 10: documentation of a programmable scheduling/trigger API for arbitrary recurring jobs, evidence the MCP server or CLI supports defining custom recurring workflows, and independent confirmation of these automations working as advertised.

   • [claimed-docs] “Hotel rate monitoring with automatic rebooking when prices drop $50+”
   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Mercury—none0/10

   Evidence shows Mercury's API, CLI, MCP server, and sandbox for building integrations/automations, plus an API changelog for endpoint version history, but nothing about versioning, reviewing, or rolling back user-created automations themselves (e.g., no workflow/rule history, diff, or undo mechanism for automations built on top of Mercury).

   ⚑ flag

   Ramp—none0/10

   No evidence of version history, review workflows, or rollback capability for Ramp's automations (approval rules, agent actions, categorization rules, etc.). The evidence covers what the automations do, but nothing about auditing, versioning, or reverting automation configurations/agent decisions.

   ⚑ flag

Card controls

1. finance-leadSet department or program budgets with automatically enforced spend limits

   weight 2 · round drawn
   Mercury~partialclaimed6/10

   Mercury supports per-card spending limits, spend controls, and granular user permissions (mercury-docs-10, mercury-docs-38), and the Cards API lets you 'manage spending limits' programmatically (mercury-docs-36), which enforces spend caps at the card/user level. However, there is no evidence of a dedicated department- or program-level 'budget' object that aggregates multiple cards/users under one enforced ceiling — only individual card limits and role-based permissions are documented. Missing for 10: explicit department/program budget creation, budget rollup/aggregation across multiple cards or cost centers, and automatic alerts/enforcement tied to a program-level allocation rather than per-card limits.

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [claimed-docs] “Built-in permissions means our accountant can easily make payments — literally one click and it’s done.”

   proof ↗⚑ flag

   Ramp~partialcommunity6/10

   Ramp docs reference multi-entity support with entity-level restrictions, dynamic approval routing, and card issuance controls, implying budget/spend-limit enforcement by department, but there is no explicit first-party documentation of setting a hard department/program budget cap with automatic enforcement (e.g., blocking spend once a budget threshold is reached) nor independent confirmation of this specific behavior. missing for 10: explicit documentation of budget-setting UI/API tying spend limits to departments/programs, evidence of automatic blocking/alerts when budgets are exceeded, and independent/hands-on confirmation of enforcement in practice.

   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

2. finance-leadSet per-card spend limits and granular controls for each employee

   weight 3 · round to Mercury
   Mercury✓fullcommunity8/10

   Mercury explicitly markets per-card spend limits and granular permissions ('Curb team spend with card limits, spend controls, and granular user permissions'), backed by virtual card creation, card lifecycle/limit management via API, and independent community confirmation of creating hundreds of virtual cards with individual limits. missing for 10: no hands-on walkthrough of setting a specific per-employee limit in the UI, and no detail on the granularity of permission types available to finance leads beyond marketing copy.

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Instantly spin up as many virtual cards as you need. Create cards for any purpose — ad spend, contractors, you name it.”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialcommunity5/10

   Evidence shows employees can quickly spin up new cards with approval workflows (ramp-comm-2) and that Ramp supports entity-level restrictions and dynamic approval routing (ramp-docs-14, ramp-docs-16), implying some granular control, but there is no explicit documentation of setting per-card numeric spend limits or category/merchant-level restrictions per employee. missing for 10: explicit docs on per-card spend limit configuration, merchant/category-level card controls, and independent verification of granularity.

   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

3. finance-leadInstantly freeze a lost or stolen card and order a replacement

   weight 2 · round to Mercury
   Mercury~partialclaimed3/10

   Mercury lets you retrieve cards and, via the Cards API, 'manage spending limits and control card lifecycle states' (mercury-docs-1, mercury-docs-36), which plausibly covers freezing/deactivating a card, but there is no explicit documentation of a 'freeze card' action or of ordering a physical replacement card for a lost/stolen card. missing for 10: explicit freeze/lock card documentation, explicit lost/stolen card replacement flow, UI or API evidence of the finance-lead-facing freeze button.

   • [claimed-docs] “Retrieve all debit and credit cards associated with a specific account.”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [claimed-docs] “Instantly spin up as many virtual cards as you need. Create cards for any purpose — ad spend, contractors, you name it.”

   proof ↗⚑ flag

   Ramp—none0/10

   Ramp is a corporate card platform where freezing/replacing lost cards is a standard, expected capability, but no evidence item describes card freezing or replacement workflows — only card issuance speed (ramp-comm-2) and unrelated features (receipts, AP automation, bill pay, ERP sync) are covered. Missing for 10: any documentation or community mention of freezing a lost/stolen card, ordering a replacement, or related self-service card controls.

   ⚑ flag

4. finance-leadRequest a transaction limit increase directly from a self-service screen

   weight 1 · round to Mercury
   Mercury~partialclaimed4/10

   Mercury documents self-service control over card spend limits ("Curb team spend with card limits, spend controls" and API support to "manage spending limits"), which lets an admin set/adjust limits directly rather than submit a request for approval. There is no explicit evidence of a dedicated 'request a transaction/credit limit increase' self-service screen or approval workflow. Missing for 10: explicit UI/flow for submitting and approving a limit-increase request, confirmation this applies to overall account/credit limits (not just per-card spend caps), and independent/hands-on verification of the flow.

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”

   proof ↗⚑ flag

   Ramp—none0/10

   The evidence pack contains no mention of a self-service screen for requesting card/transaction limit increases; only general card issuance and expense-tracking mentions appear (ramp-comm-2) but nothing about limit-increase requests.

   ⚑ flag

Card issuance

1. finance-leadInstantly create virtual cards scoped to a specific purpose like ad spend or a single vendor

   weight 3 · round to Mercury
   Mercury✓fullcommunity8/10

   Mercury's docs explicitly market instant virtual card creation scoped to purposes like ad spend or vendor use, backed by spend controls/limits and an API for issuing/managing card lifecycle, and a 5-year customer corroborates creating hundreds of individually-limited virtual cards in practice. Missing for 10: explicit documentation of merchant-lock/single-vendor restriction mechanics beyond naming and limits, and independent confirmation specifically of 'purpose-scoped' (vs just limited) cards.

   • [claimed-docs] “Instantly spin up as many virtual cards as you need. Create cards for any purpose — ad spend, contractors, you name it.”
   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialcommunity6/10

   Community evidence confirms Ramp lets users spin up a new virtual/business expense card in under a minute for a specific purchase, supporting instant, purpose-scoped card creation. However, there's no direct first-party documentation explicitly describing vendor- or category-locked virtual card controls (e.g., merchant-lock, spend-category restrictions) beyond general references to approvals and multi-entity restrictions. Missing for 10: explicit docs on merchant/category-locking rules for virtual cards, admin UI screenshots/workflow for scoping a card to a single vendor or ad-spend category, and independent verification of that specific control granularity.

   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”

   proof ↗⚑ flag

2. finance-leadIssue physical debit or credit cards to employees with defined roles

   weight 2 · round to Mercury
   Mercury~partialcommunity6/10

   Mercury documents issuing business debit/credit cards to employees with spend limits and granular permissions (mercury-docs-10, mercury-docs-27, mercury-docs-38, mercury-docs-1), and a community user confirms creating many cards with individual limits (mercury-comm-1). However most product copy emphasizes virtual cards (mercury-docs-2) and no evidence explicitly details a physical-card issuance workflow tied to defined employee roles. Missing for 10: explicit documentation of physical card ordering/shipping process, and role-based (not just limit-based) card issuance controls.

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Access business credit cards as soon as day one — no minimums, credit checks, or personal guarantees.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [claimed-docs] “Retrieve all debit and credit cards associated with a specific account.”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialcommunity4/10

   Community evidence confirms Ramp lets a finance user quickly spin up a company card with approval and fund transfer, and docs mention entity-level restrictions and approval routing that imply role-based controls, but nothing explicitly confirms physical (vs. virtual) card issuance or granular role-based card permissions. Missing for 10: explicit mention of physical card issuance, and documentation of role-based spend controls/limits tied to employee roles.

   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”
   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”

   proof ↗⚑ flag

Card rewards

1. founderSpend and withdraw cash abroad on a company card without hidden foreign fees

   weight 1 · round drawn
   Mercury—none0/10

   The evidence pack covers card issuance, virtual cards, cashback, and no-fee USD payments/transfers, but nothing addresses foreign transaction fees, currency conversion fees, or ATM cash withdrawal abroad on a Mercury card. 'No-fee USD payments around the globe' (mercury-docs-7) refers to outbound payments, not card spend/withdrawal abroad, so it does not substantiate this specific claim.

   ⚑ flag

   Ramp—none0/10

   The evidence pack contains no mention of foreign transaction fees, international card usage, currency conversion, or cash withdrawal abroad — only receipt capture, AP automation, ERP sync, and integrations are covered. Axis applies to a corporate card product, but nothing in the pack supports the specific claim about fee-free international spend/withdrawal.

   ⚑ flag

2. founderEarn automatic cashback on card spend without manual redemption steps

   weight 2 · round to Mercury
   Mercury✓fullclaimed8/10

   Mercury explicitly advertises automatic, unlimited cashback deposited directly into the account with no manual redemption or points system, and separately states a concrete 1.5% cashback rate on credit card spend, directly matching the founder story. Missing for 10: independent/community corroboration that the cashback mechanic works as described in practice, and clarity on whether it applies uniformly to debit vs credit cards.

   • [claimed-docs] “Earn unlimited cashback automatically deposited into your account — no manual redemption or confusing points.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”

   proof ↗⚑ flag

   Ramp—none0/10

   The evidence pack covers expense automation, receipt capture, ERP sync, approvals, and AI agents, but contains no mention of cashback rewards or automatic cashback redemption on card spend anywhere in the docs or community evidence.

   ⚑ flag

Procurement automation

1. ai-native userHave vendor contracts parsed by AI to auto-populate procurement request forms

   weight 2 · round to Ramp
   Mercury—none0/10

   Mercury's AI document-reading is limited to bills for bill-pay (auto-populating bill details) and receipt auto-attach; there is no evidence of parsing vendor contracts or auto-populating procurement request forms, which is a distinct workflow not covered in any docs, API, or MCP tool inventory.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”

   proof ↗⚑ flag

   Ramp✓fullclaimed7/10

   Ramp's docs explicitly state AI-powered intake parses contracts and screenshots to auto-populate procurement request forms, directly matching the story. Missing for 10: independent/hands-on corroboration of this specific contract-parsing feature and detail on accuracy/edge cases.

   • [claimed-docs] “AI-powered intake parses contracts and screenshots to auto-populate request forms”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”

   proof ↗⚑ flag

Receipt management

1. ai-native userHave receipts automatically captured and coded the moment a card is used, without manual entry

   weight 3 · round to Ramp
   Mercury~partialclaimed6/10

   Mercury lets users email or upload receipts and auto-attaches them to the matching card transaction (mercury-docs-5/28), and there's a mercury-receipt-upload agent skill for automating this (mercury-supp-agent-skills), plus a transaction-attachment API endpoint (mercury-docs-12). However, this is not truly automatic capture 'the moment a card is used' — it requires the user to email/upload the receipt themselves rather than passive/automatic capture at time of swipe, and there's no OCR/auto-coding of receipt line items into categories mentioned, only attachment matching. Missing for 10: evidence of automatic receipt capture without any manual send/upload step (e.g., via merchant integration or physical receipt scanning at point of sale), evidence of automatic line-item categorization/coding from receipt contents, and independent/hands-on confirmation this works reliably in practice.

   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction.”
   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”

   proof ↗⚑ flag

   Ramp✓fullcommunity8/10

   Ramp's own docs claim auto-receipt capture at the moment of card swipe with AI-filled memos/categories, plus automatic categorization based on transaction details, history, and team feedback that syncs coded transactions to ERP — directly matching the story. Community evidence corroborates general ease-of-use of card issuance/expense flow, though no independent hands-on confirmation specifically of receipt auto-capture accuracy exists. Missing for 10: independent/hands-on verification of receipt-matching accuracy and edge cases (e.g., lost receipts, disputes).

   • [claimed-docs] “Auto-receipt capture at the moment of card swipe with AI-filled memos and categories”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

2. finance-leadHave receipts automatically attached to the right transaction by emailing or uploading them

   weight 2 · round to Mercury
   Mercury✓fullclaimed8/10

   Mercury's docs explicitly state receipts can be emailed or uploaded and are auto-attached to the correct card transaction, directly matching the story, with API support for uploading transaction attachments. missing for 10: independent/hands-on confirmation (e.g. community report) that auto-attach matching works reliably in practice, and no detail on edge cases (mismatched/ambiguous receipts).

   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction.”
   • [claimed-docs] “Write actions such as making payments, categorizing transactions, creating invoices, and uploading receipts”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”

   proof ↗⚑ flag

   Ramp✓fullclaimed7/10

   Ramp's docs claim auto-receipt capture at swipe with AI-filled memos/categories, and automated matching/coding for vendor invoices dragged into the platform, which covers the core of automatic receipt-to-transaction matching via upload or email-based capture. Missing for 10: explicit documentation of the email-forwarding-to-transaction workflow specifically, and independent/hands-on confirmation of matching accuracy beyond vendor claims.

   • [claimed-docs] “Auto-receipt capture at the moment of card swipe with AI-filled memos and categories”
   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”

   proof ↗⚑ flag

Signup flow

1. founderCheck my account application status while it's under review

   weight 1 · round drawn
   Mercury—none0/10

   Evidence shows Mercury's onboarding application flow (apply online, CLI 'Onboarding (apply)' command) but nothing about being able to check or track the status of an application while it's under review — no dashboard, CLI, or API endpoint for application/review status is documented anywhere in the pack.

   • [claimed-docs] “Apply online in 10 minutes to experience banking unlike anything that’s come before.”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence in the pack describes an account application, review process, or status-tracking feature for founders during onboarding; all onboarding evidence relates to time-to-deploy after approval (e.g., ramp-docs-8), not application status tracking.

   ⚑ flag

Switching

1. founderReplace multiple point solutions for spend, bill pay, and banking with one consolidated platform

   weight 2 · round drawn
   Mercury✓fullcommunity8/10

   Mercury documents a unified platform covering banking, virtual/physical cards with spend controls, bill pay with AI-assisted invoice reading, AR/invoicing, receipt auto-attachment, accounting sync (QuickBooks/Xero/NetSuite), Treasury yield, and FX/international payments, all inside one account — directly consolidating spend, bill pay, and banking tools. Independent community evidence (5-year customer) corroborates real-world use across cards, wires, and multi-account structures replacing other tools. missing for 10: no independent evidence of replacing named specific competitor point-solutions (e.g., Expensify/Bill.com) or third-party case studies quantifying tool consolidation.

   • [claimed-docs] “Instantly spin up as many virtual cards as you need. Create cards for any purpose — ad spend, contractors, you name it.”
   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Send manual and automatic invoices, accept flexible payment methods, and manage customer details right from your Mercury account.”
   • [claimed-docs] “Email or upload receipts and we’ll auto-attach them to the right card transaction. You don’t lift a finger.”
   • [claimed-docs] “Sync with Quickbooks, Xero or NetSuite, and save hours with AI-powered automations to close your books faster.”
   • [claimed-docs] “Send no-fee USD payments around the globe”
   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Earn 1.5% cashback on credit card spend, and control team expenses with cards, reimbursements, limits, and approvals all in one place.”
   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp✓fullcommunity8/10

   Ramp's docs and case studies directly support the story: unified spend/card, bill pay/AP automation, banking/treasury (auto top-up, balances), multi-entity consolidation, and explicit customer proof of consolidating tools (Studs replacing 4 tools, AIRCO fast onboarding vs 6 months). Community evidence corroborates real-world use for expense/card issuance and approvals, reinforcing the platform's breadth beyond marketing claims. Missing for 10: independent case studies verifying bill-pay/banking consolidation claims (not just card/expense), and more third-party evidence on multi-entity/ERP sync accuracy.

   • [claimed-docs] “A vendor invoice is dragged into Ramp, automatically matched to its PO, coded to the right GL account, routed for approval, and paid — 7x fe…”
   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”
   • [claimed-docs] “Studs: Replaced 4 separate tools with Ramp's all-in-one platform”
   • [claimed-docs] “AIRCO: Full onboarding in 1 week vs. 6 months on prior platform”
   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

2. founderFully onboard onto a new banking platform in about a week instead of months

   weight 2 · round to Ramp
   Mercury~partialclaimed6/10

   Mercury explicitly advertises rapid onboarding ("Apply online in 10 minutes") and near-instant account usability ("business credit cards as soon as day one — no minimums, credit checks, or personal guarantees"), directly supporting a week-vs-months onboarding claim. However, this is vendor marketing copy only — no independent/community account of an actual end-to-end onboarding timeline, KYC/compliance steps, or founder testimonials confirming real-world speed. Missing for 10: independent or hands-on confirmation of onboarding duration, detail on KYC/compliance steps, and founder testimonials specifically about onboarding speed.

   • [claimed-docs] “Apply online in 10 minutes to experience banking unlike anything that’s come before.”
   • [claimed-docs] “Access business credit cards as soon as day one — no minimums, credit checks, or personal guarantees.”

   proof ↗⚑ flag

   Ramp✓fullcommunity8/10

   Ramp provides a concrete customer proof point (AIRCO: full onboarding in 1 week vs 6 months on prior platform) directly matching the story, plus general positive hands-on feedback about quick setup of cards/expenses. Missing for 10: independent third-party verification of onboarding timelines beyond vendor case studies, and detail on the actual onboarding process/steps for a new customer.

   • [claimed-docs] “AIRCO: Full onboarding in 1 week vs. 6 months on prior platform”
   • [community] “It's what we use for tracking expenses and getting comped for travel, meals, software licenses etc - works great in my experience. I can cli…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Mercury
   Mercury~partialprobed7/10

   Mercury's REST API, CLI, and SDK expose most core UI actions—accounts, transactions, card issuance/lifecycle, invoices/customers, categories, statements, webhooks, ACH payments, and even Vault agent-card credentials (mercury-docs-12,13,36,37; mercury-probe-3)—with sandbox, versioning, and changelog support. However parity is incomplete: the AI bill-reading/bill-pay flow (mercury-docs-3) has no documented API equivalent, and the hosted MCP surface is explicitly read-only (31 get/list tools, zero write actions per mercury-probe-5), meaning an AI agent using MCP cannot perform actions like payments or invoice creation that a human can in the UI. Missing for 10: documented API/CLI parity for bill-pay AI feature, write-capable MCP tools matching UI actions, and confirmation that all UI-only conveniences (universal search, cashback redemption) have functional API analogs.

   • [claimed-docs] “AI reads bills, populates details automatically, and remembers past recipients — so you can approve and pay in seconds.”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”
   • [claimed-docs] “Accounts Receivable API: Customers (List/Create/Get/Update/Delete a customer); Invoices (List/Create/Get/Update/Cancel an invoice, Download …”
   • [claimed-docs] “Write actions such as making payments, categorizing transactions, creating invoices, and uploading receipts”
   • [claimed-docs] “You can now issue virtual cards, manage spending limits, and control card lifecycle states — all through the API.”
   • [claimed-docs] “Agents can now pull full card credentials - number, expiry, and CVC - for agent cards through the new Vault API”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [probe] “PROBE mcp-tool-inventory: documented Mercury MCP tool list totals 31 tools, all read-only (get*/list*, zero write/send/create actions): getA…”
   • [probe] “PROBE mcp-runtime: Mercury's MCP is a remote, hosted, streamable-HTTP server (per docs, no stdio/npx variant exists — "Mercury does not offe…”

   proof ↗⚑ flag

   Ramp~partialprobed6/10

   Ramp exposes a documented Developer API with OpenAPI spec, LLM-readable docs, an official MCP server, and even a public CLI, indicating broad programmatic access aligned with AI-native workflows. However, there is no explicit claim or evidence that every UI capability (e.g., hotel rebooking automation, contract intake AI, dynamic approval routing) is fully exposed via the API — only general API/ERP sync and CSV export mentions. Missing for 10: an explicit statement or independent verification of full feature parity between API and UI, and evidence covering advanced workflow features (approvals, travel, intake) being API-accessible.

   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”
   • [probe] “official MCP server documented at https://support.ramp.com/ramp-mcp”
   • [probe] “official CLI documented at https://github.com/ramp-public/ramp-cli”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Mercury~partialprobed5/10

   Mercury exposes transactions, statements (PDF), categories, invoices, and account data via a documented REST API and CLI, which provides a path to programmatically export financial data in standard formats (JSON, PDF). However, there is no evidence of a dedicated 'export all my data' bulk-export feature, no mention of CSV/standard banking export formats beyond PDF statements, and no documentation addressing account closure or leaving with full data portability guarantees. missing for 10: a documented full-account data export/closure workflow, explicit open standard formats (e.g., CSV/OFX) beyond PDF, and any guarantee of data portability upon account closure.

   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”
   • [claimed-docs] “Pull balances, list transactions, and initiate ACH transfers — all through a single REST API”
   • [probe] “PROBE official-cli: github.com/MercuryTechnologies/mercury-cli (Mercury's own GitHub org, 171 stars, last push 2026-08-12, README: 'The offi…”
   • [claimed-docs] “Docs, "Using the Mercury Sandbox for Testing": sign up for a sandbox account at https://sandbox.mercury.com/signup; "When making API request…”

   proof ↗⚑ flag

   Ramp~partialprobed5/10

   Ramp explicitly supports custom CSV exports and an open API for connectivity, plus a documented OpenAPI spec and developer API, which gives users a path to extract their data in open formats. However, there is no evidence of a full data-portability/export-everything guarantee, no mention of standardized bulk export tooling for account closure, and no independent confirmation of completeness of exports. missing for 10: dedicated 'export all data and leave' documentation, evidence of open/standard format for full account export (not just transactions via API/CSV), independent verification of export completeness.

   • [claimed-docs] “Ramp also supports custom CSV exports and an open API for flexible connectivity.”
   • [claimed-docs] “fetch: /llms.txt (LLM index), /llms-guides.txt (guides index), /llms-guides/<slug>.txt (specific guide), /llms-api.txt (API reference), /llm…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.ramp.com/llms.txt # Ramp Developer API Machine-readable index for Ramp's Developer API documentati…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Mercury—none0/10

   No evidence anywhere in the pack addresses data residency, regional storage options, or geographic control over where account/API/MCP data is stored; Mercury's docs, API, and MCP materials are silent on this axis despite it being a fair question for a financial data platform serving international customers. Missing for 10: any mention of data region selection, residency guarantees, or geo-specific storage/compliance options.

   ⚑ flag

   Ramp—none0/10

   No evidence in the pack addresses data residency, regional storage options, or compliance controls for choosing where data is stored; the evidence covers AI features, integrations, and MCP/API tooling only.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Mercury—none0/10

   Evidence shows only the ability to revoke MCP/API access (mercury-docs-25), but nothing about controlling data retention periods or deleting stored/processed data for AI-native usage; banking retention requirements make this a fair question but no capability is documented.

   • [claimed-docs] “The ability to revoke access at any time from your Mercury dashboard”

   proof ↗⚑ flag

   Ramp—none0/10

   Ramp's evidence pack covers expense automation, AI agents, integrations, and MCP/API access, but there is no mention of data retention policies, deletion controls, or privacy configuration relevant to AI-native users. Nothing addresses how long data/prompts are stored or how users can delete data.

   ⚑ flag

Access control

1. finance-leadDefine granular user roles and permissions across team members, locations, and departments

   weight 3 · round drawn
   Mercury~partialclaimed5/10

   Mercury explicitly advertises 'granular user permissions' and 'built-in permissions' allowing role-differentiated access (e.g., accountant given payment-only access) plus scoped/read-only/read-write/custom API tokens, which supports role-based access control for a finance lead. However, there is no evidence of permission structuring specifically by location or department, or of a full admin UI showing role/permission matrix management. Missing for 10: documentation of location- or department-level permission scoping, a detailed permissions matrix/UI walkthrough, and independent confirmation of granular role management beyond marketing claims.

   • [claimed-docs] “Curb team spend with card limits, spend controls, and granular user permissions.”
   • [claimed-docs] “Built-in permissions means our accountant can easily make payments — literally one click and it’s done.”
   • [claimed-docs] “Issue scoped API tokens with fine-grained permissions”
   • [claimed-docs] “There are three types of tokens: read-only, read-write, and custom.”

   proof ↗⚑ flag

   Ramp~partialclaimed5/10

   Ramp docs mention multi-entity support with entity-level restrictions and dynamic approval routing across finance, IT, legal, and security, which implies some role/permission granularity across entities and departments, but there is no explicit documentation of a granular role/permission system covering locations and individual team members. missing for 10: dedicated documentation of role-based access control, granular permission settings per user/location/department, and independent corroboration of these controls.

   • [claimed-docs] “Multi-entity support with entity-level restrictions and consolidated reporting”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”

   proof ↗⚑ flag

Fraud detection

1. ai-native userHave AI flag anomalous or out-of-policy transactions automatically for review

   weight 2 · round to Ramp
   Mercury~partialclaimed3/10

   The official mercury-skills repo lists a 'mercury-detect-anomaly' skill for the Mercury CLI, indicating an AI-driven anomaly-detection capability exists, but there is no documentation of how it works, whether it flags out-of-policy transactions specifically, or how review/approval is triggered. Missing for 10: detailed docs on anomaly/policy-violation detection logic, automatic flagging-for-review workflow, and independent confirmation the skill functions as described.

   • [claimed-docs] “Official MercuryTechnologies/mercury-skills repo, "Mercury Skills Directory": "Agent skills that drive the Mercury CLI. Each skill is a self…”

   proof ↗⚑ flag

   Ramp~partialclaimed5/10

   Ramp claims a dedicated AI 'fraud prevention' agent alongside auto-coding and dynamic, multi-department approval routing, which implies automated flagging of anomalous or out-of-policy transactions for review (ramp-docs-17, ramp-docs-16). However, there is no detailed documentation of how anomaly detection thresholds work, no explicit 'flag for review' workflow description, and no independent/hands-on evidence corroborating this specific capability. Missing for 10: detailed docs on anomaly/policy-violation detection logic, explicit reviewer workflow, and independent verification of fraud-flagging accuracy.

   • [claimed-docs] “Four AI agents handle auto-coding, fraud prevention, approval routing, and automatic payment”
   • [claimed-docs] “Dynamic approval routing with parallel workflows across finance, IT, legal, and security”
   • [claimed-docs] “Ramp automatically categorizes transactions based on transaction details, historical information, and your team's direct feedback, then sync…”

   proof ↗⚑ flag

Customer support

1. founderReach live customer support at any time for urgent account issues

   weight 2 · round drawn
   Mercury—none0/10

   The evidence pack contains no mention of live customer support, phone/chat support hours, or urgent account-issue escalation channels; all evidence covers API/product/banking features and MCP/CLI tooling. Missing for 10: any documentation or claim about support channels, live/24-7 availability, or response times for urgent issues.

   ⚑ flag

   Ramp—none0/10

   No evidence in the pack mentions live customer support, support channels, response times, or availability guarantees; the pack only covers product features, integrations, and general community sentiment unrelated to support access.

   ⚑ flag

Deposit protection

1. finance-leadHave deposits automatically swept across partner banks to maximize FDIC insurance coverage

   weight 2 · round drawn
   Mercury—none0/10

   Mercury markets Treasury sweep accounts (mercury-docs-39 mentions 'Treasury by Mercury Advisory' yield) but no evidence describes automatic sweeping of deposits across multiple partner banks specifically to maximize FDIC coverage — the docs focus on cards, invoicing, API/MCP tooling, and yield, not multi-bank FDIC sweep networks.

   ⚑ flag

   Ramp—none0/10

   Evidence shows only auto top-up from a linked checking account with balance targets (ramp-docs-6), not a multi-bank sweep program for maximizing FDIC coverage; no mention of partner-bank sweep networks or FDIC insurance expansion anywhere in the pack.

   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”

   proof ↗⚑ flag

Cash automation

1. finance-leadAutomate cash management with auto top-up between accounts and low-balance alerts

   weight 2 · round to Ramp
   Mercury~partialcommunity4/10

   A long-time customer describes creating 'dozens of purpose-named accounts with auto-funding rules' (mercury-comm-1), which is real-world evidence of auto top-up/fund-transfer automation between accounts, and Mercury's Treasury product (mercury-docs-39) supports the treasury-yield angle. However, there is no vendor documentation describing configurable auto top-up rules or low-balance alert features anywhere in the docs/API/MCP evidence. missing for 10: first-party docs on auto top-up configuration, explicit low-balance alert/notification feature, and any API/webhook evidence for balance threshold alerts.

   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”
   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”

   proof ↗⚑ flag

   Ramp~partialclaimed6/10

   Ramp explicitly documents auto top-up from linked checking accounts with target balance automation and low-balance alerts, directly matching the story, but this rests on a single vendor claim with no independent/hands-on corroboration and no detail on multi-account 'treasury-yield' style cash optimization or yield features. missing for 10: independent verification of auto top-up working in practice, detail on interest/yield optimization across accounts, and community evidence confirming alert reliability.

   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”

   proof ↗⚑ flag

Yield generation

1. finance-leadEarn yield on operating cash balances without moving funds to a separate institution

   weight 3 · round to Mercury
   Mercury✓fullclaimed7/10

   Mercury explicitly offers 'Treasury by Mercury Advisory' with yield up to 3.89% directly within the Mercury account/dashboard, alongside free checking/savings, so operating cash can earn yield without moving funds to a separate institution. Missing for 10: independent/hands-on verification of the yield product's mechanics (e.g., sweep structure, FDIC coverage details) and community corroboration of actual yield experience beyond the vendor claim.

   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”

   proof ↗⚑ flag

   Ramp—none0/10

   The evidence pack mentions auto top-up from linked checking accounts and target balance automation, but there is no mention of Ramp offering interest/yield on operating cash balances held within Ramp itself, nor any treasury/yield product distinct from moving funds elsewhere.

   ⚑ flag

2. finance-leadBuild a cash cushion in a high-yield savings sub-account with automated transfer rules

   weight 2 · round to Mercury
   Mercury~partialcommunity6/10

   Mercury offers a high-yield Treasury product (up to 3.89% yield) and supports multiple purpose-named sub-accounts, and a long-tenure customer reports using 'auto-funding rules' across dozens of these accounts, supporting the described workflow. However, there is no official documentation describing a dedicated 'automated transfer rule' feature or explicit high-yield savings sub-account mechanics — this evidence comes only from a single community anecdote, not vendor docs or API endpoints. Missing for 10: official docs on automated/recurring transfer rule configuration, explicit sub-account-to-Treasury auto-sweep feature documentation, and independent verification beyond one HN comment.

   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”
   • [claimed-docs] “Mercury API endpoint catalog: List all transactions, Get a transaction by ID, Update transaction metadata, Upload a transaction attachment; …”
   • [community] “5-year Mercury customer: wire transfers never disappear, created hundreds of virtual debit cards with individual limits, dozens of purpose-n…”

   proof ↗⚑ flag

   Ramp~partialclaimed3/10

   Ramp documents auto top-up and target-balance automation with low-balance alerts (ramp-docs-6), which supports the 'automated transfer rules' part of the story, but no evidence explicitly confirms a high-yield savings sub-account or yield-bearing cash cushion feature. missing for 10: explicit high-yield/interest-bearing savings sub-account documentation, evidence of yield rates, and independent corroboration of treasury cash-cushion use case.

   • [claimed-docs] “Auto top-up from linked checking accounts with target balance automation and low balance alerts”

   proof ↗⚑ flag

3. founderEarn interest on balances held in multiple currencies

   weight 1 · round drawn
   Mercury—none0/10

   Evidence shows Mercury offers yield via 'Treasury by Mercury Advisory' (up to 3.89%) but this and all cash/banking references are USD-only — there is no mention of interest-bearing balances in multiple currencies, multi-currency accounts, or FX-denominated yield anywhere in the pack. Missing for 10: any documentation of multi-currency account holding, multi-currency interest rates, or FX yield products.

   • [claimed-docs] “Apply for free checking and savings accounts with zero minimums, earn up to 3.89% yield with Treasury by Mercury Advisory”
   • [claimed-docs] “Send no-fee USD payments around the globe”

   proof ↗⚑ flag

   Ramp—none0/10

   No evidence in the pack mentions multi-currency accounts, FX holding, or interest/yield on non-USD balances; Ramp evidence covers cards, expense automation, integrations and AI agents but nothing about earning interest on multi-currency balances. Missing for 10: any mention of multi-currency account support, interest/yield rates, or treasury/FX yield features.

   ⚑ flag