Mercury vs Brex

Close automation

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

   weight 2 · round drawn
   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

   Brex✓fullclaimed7/10

   Brex explicitly documents AI-driven automations aimed at faster month-end close — one-click accrual booking, automated GL coding by entity, AI-powered invoice entry/approval, plus an Accounting API and MCP server for programmatic/AI-assisted access to accounting data. This directly matches the ai-native 'close books faster' story via first-party product documentation. missing for 10: independent/hands-on corroboration that these automations measurably speed up close, no case study or third-party validation of close-time reduction.

   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [claimed-docs] “8 reasons to switch to AI-powered financial operations”

   proof ↗⚑ flag

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

   weight 3 · round to Brex
   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

   Brex✓fullclaimed7/10

   Brex's own marketing explicitly claims automated GL coding by entity globally with one-click accrual booking to close books daily, directly matching the story (brex-docs-8, brex-docs-14), backed by an Accounting API for managing accounting data across entities (brex-docs-1) and AI-powered automation messaging (brex-docs-7, brex-docs-9). Missing for 10: independent/hands-on verification of GL-coding accuracy across entities and no third-party case study confirming close-acceleration outcomes.

   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “8 reasons to switch to AI-powered financial operations”

   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

   Brex✓fullprobed8/10

   Brex documents a dedicated Accounting API ('View and manage accounting data') alongside related APIs (Expenses, Transactions, Payments), and the developer docs are confirmed live via probe. Missing for 10: independent/hands-on corroboration of the Accounting API's functionality and a discoverable OpenAPI schema (404s on standard paths).

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   proof ↗⚑ flag

Erp sync

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

   weight 3 · round to Brex
   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

   Brex✓fullclaimed8/10

   Brex documents automated GL coding, accounting API, thousands of native integrations for syncing across finance tools, and one-click accrual booking to close books daily, directly supporting automated transaction/expense sync with accounting software. Missing for 10: named integrations with specific accounting platforms (e.g. QuickBooks/NetSuite) and independent hands-on verification of sync reliability.

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “All your tools synced in one place.”
   • [claimed-docs] “Simplify every task that finance touches with automatic syncing across 1,000s of native integrations.”
   • [claimed-docs] “Make your financial operations more seamless, from card swipe to month-end close.”

   proof ↗⚑ flag

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

   weight 3 · round to Brex
   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

   Brex~partialclaimed6/10

   Brex documents an Accounting API for viewing/managing accounting data, a Webhooks API for real-time event notifications, automated GL coding by entity, and 'automatic syncing across 1,000s of native integrations' spanning card swipe to month-end close — together implying near-real-time sync that reduces manual journal entry work. However, there is no explicit mention of named ERP systems (e.g., NetSuite, Sage Intacct) or confirmation that sync is truly bidirectional (push AND pull) rather than one-way export/webhook notification, and no independent/hands-on validation of ERP sync reliability. Missing for 10: named major ERP integration specifics, explicit bidirectional sync confirmation, and third-party corroboration of real-time accuracy.

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “Simplify every task that finance touches with automatic syncing across 1,000s of native integrations.”
   • [claimed-docs] “Make your financial operations more seamless, from card swipe to month-end close.”
   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”

   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

   Brex—none0/10

   Evidence pack shows Transactions/Accounting APIs for viewing accounts and statements, but nothing about viewing account/routing numbers or generating a bank verification letter is documented anywhere in the docs or community evidence.

   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Accounting API: View and manage accounting data”

   proof ↗⚑ 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

   Brex—none0/10

   No evidence in the pack of Brex offering multiple checking sub-accounts or auto-allocation of incoming deposits across them; docs cover budgets, expenses, payments, and integrations but nothing about sub-account structuring or deposit-splitting rules.

   ⚑ flag

Bill pay

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

   weight 3 · round drawn
   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

   Brex~partialcommunity6/10

   Brex explicitly markets 'AI-powered automation of invoice entry, approval, and payments' and bill pay as part of its unified spend platform, and the MCP server lets AI assistants 'track bills' via natural language, suggesting AI can ingest and populate bill data for review. However, there's no detailed documentation of the specific workflow (OCR/reading incoming bills, field extraction, human-in-loop review step), and general community skepticism about AI reliability in financial workflows (hallucinated/missed expenses) raises caution about accuracy, though not a concrete dispute of the bill-pay feature itself. Missing for 10: explicit documentation of bill-reading/OCR extraction pipeline, a described human-review UI step, and independent verification of accuracy for auto-populated payment details.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [community] “This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using 'a non-deterministic model' for production use ca…”

   proof ↗⚑ flag

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

   weight 3 · round to Mercury
   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

   Brex~partialcommunity6/10

   Brex explicitly advertises AI-powered invoice entry, approval, and payment automation (bill pay) plus vendor payments via Payments API and procurement approval flows on cards, supporting the core of the story. However, evidence lacks detail on an explicit bill-upload UI/OCR workflow or configurable multi-step approval chains before vendor payment, and community threads raise concerns about AI reliability in financial workflows (though not a direct dispute of this specific bill-approval feature). Missing for 10: detailed documentation of bill upload/OCR ingestion, explicit multi-tier approval routing configuration, and independent hands-on validation of the bill-pay approval flow.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”
   • [community] “This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using 'a non-deterministic model' for production use ca…”

   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

   Brex~partialclaimed5/10

   Evidence shows Brex has bill-pay/invoice approval automation (brex-docs-7), vendor payment sending via Payments API (brex-docs-12), and procurement approval flows for cards (brex-docs-15), implying approval workflows exist, but there is no direct documentation of configuring designated-teammate approval permissions or a one-click approve-and-send payment action for a finance-lead. Missing for 10: explicit docs on setting approval roles/permissions, evidence of a one-click approve-and-send UX, and independent confirmation this works as described.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”

   proof ↗⚑ flag

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

   weight 2 · round to Brex
   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

   Brex~partialclaimed5/10

   Brex documents AI-powered invoice entry automation, automated GL coding by entity, and payment/vendor APIs (brex-docs-7, brex-docs-8, brex-docs-14, brex-docs-12), which covers invoice coding and routing for payment. However, there is no evidence of purchase-order matching or three-way match capability anywhere in the pack. Missing for 10: explicit PO-to-invoice matching functionality, documentation of approval routing workflow details, and independent/hands-on corroboration of the AI invoice automation working reliably.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”

   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

   Brex—none0/10

   Brex's evidence covers cards, expenses, bill pay, budgets, payments (ACH/wires/checks to vendors), and accounting integrations, but there is no mention of creating or sending branded customer-facing invoices with payment collection (i.e., accounts-receivable invoicing) anywhere in the docs or APIs listed.

   ⚑ flag

Money movement

1. founderSend money abroad that arrives in under a minute

   weight 2 · round to Brex
   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

   Brex~partialclaimed2/10

   Brex markets 'fast global payments' and operations in 120+ countries, and its Payments API sends ACH/domestic wires/checks, but there is no documentation of international wire speed or any sub-minute delivery guarantee for cross-border transfers. missing for 10: explicit international/cross-border payment speed SLA, documentation of same-day or instant global wire capability, independent confirmation of transfer times.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Brex✓fullclaimed7/10

   Brex's Payments API documentation explicitly states it can 'Manage vendors and send ACH, domestic wires, and checks,' and marketing material references bill pay/invoice payment automation, directly matching the finance-lead story of sending domestic ACH and wire payments to vendors. Missing for 10: independent/hands-on verification of successful payment execution and more detail on approval workflows or transaction limits.

   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”

   proof ↗⚑ flag

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

   weight 3 · round to Brex
   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

   Brex~partialclaimed4/10

   Brex references 'fast global payments' and operations 'in 120+ countries,' and its Payments API supports ACH, domestic wires, and checks, but there is no documentation of sending international payments in local currencies or of transparent/disclosed FX fees. Missing for 10: explicit local-currency international payment support, FX conversion mechanics, and transparent fee disclosure/pricing documentation.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”

   proof ↗⚑ 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

   Brex—none0/10

   Evidence shows global card/banking reach in 120+ countries and fast global payments, but nothing describes holding or managing balances in multiple currencies within a single account. Missing for 10: any explicit multi-currency wallet/balance feature, FX conversion mechanics, or account structure supporting simultaneous currency balances.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”

   proof ↗⚑ 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

   Brex—none0/10

   Brex evidence covers corporate cards, spend management, and outbound payments (ACH, wires, checks via the Payments API) but contains no mention of receiving payments via local account details in multiple currencies (e.g., local IBAN/account numbers for USD, EUR, GBP, etc.). The 'fast global payments' and '120+ countries' claims refer to outbound/global card acceptance, not local receiving accounts.

   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”

   proof ↗⚑ 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

   Brex—none0/10

   The evidence pack documents separate APIs (Transactions, Payments, Expenses, Team) and integrations, but nowhere describes a unified 'universal search bar' UI that lets a finance-lead search transactions, vendors, and cards together and jump into initiating a payment. No product screenshots, docs, or community reports confirm such a consolidated search experience.

   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”

   proof ↗⚑ 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

   Brex—none0/10

   Brex's Payments API supports sending ACH, wires, and checks, but no evidence shows a delivery-estimate or ETA feature surfaced to finance leads before confirming a transfer; missing for 10: any documentation of delivery-time estimates, confirmation UI, or timing guarantees for ACH/wire payments.

   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Brex
   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

   Brex✓fullprobed9/10

   A direct probe confirms Brex serves a proper llms.txt file at developer.brex.com/llms.txt (HTTP 200) with a structured table of contents pointing to agent-friendly docs, and Brex also documents an MCP server for agent interaction, reinforcing an agent-oriented docs strategy. Missing for 10: independent third-party confirmation of an agent actually consuming llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “official MCP server documented at https://developer.brex.com/docs/mcp”

   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

   Brex~partialprobed5/10

   Brex exposes REST APIs (Accounting, Payments, Transactions, Team, Webhooks) and webhooks that can be scripted/automated outside a UI, which supports headless/CI-style automation, and Postman/Pipedream/Zapier integration docs further show programmatic, non-interactive usage patterns. However, there is no explicit documentation of a CLI, SDK, service-account/API-key auth flow for CI pipelines, or any first-party guidance on running Brex workflows in automated/headless CI environments. missing for 10: explicit CI/headless automation guidance, CLI or SDK for scripting, service-account/token auth documentation for non-interactive use, independent confirmation of CI usage.

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Postman is a browser or desktop app used for API testing. It gives you a UI to easily test and play around with API calls without having to …”
   • [claimed-docs] “Pipedream is a low-code integration platform that Brex integrates with to enable various use cases including bulk creating users, setting mo…”
   • [claimed-docs] “Monthly Export of Brex Card Transactions to CSV in Google Drive”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Brex✓fullprobed8/10

   Brex documents an official MCP server (developer.brex.com/docs/mcp) that lets AI assistants manage expenses, look up users, check cards, review transactions, and track bills via natural language, confirmed by both docs and a probe. Missing for 10: independent hands-on community corroboration of the MCP server itself (community evidence found is unrelated to MCP) and details on auth/security model.

   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “official MCP server documented at https://developer.brex.com/docs/mcp”

   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

   Brex—none0/10

   No evidence of an official Brex CLI tool; developer docs mention APIs, Postman, Pipedream, Zapier, and an MCP server, but no CLI is documented.

   ⚑ 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

   Brex✓fullprobed8/10

   Brex has an extensive documented public API surface (Accounting, Budgets, Webhooks, Team, Expenses, Payments, Transactions, Onboarding, Travel) with a quickstart guide, llms.txt discovery, Postman support, and even an MCP server for AI-native agentic access, giving strong evidence AI-native users can drive Brex programmatically. missing for 10: no live/verified OpenAPI spec (candidate URLs returned 404), and no independent third-party corroboration of API robustness beyond vendor docs.

   • [claimed-docs] “Check out our quickstart guide to get up and running making your first Brex API call in just a few minutes.”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Onboarding API: Refer your customers and personal contacts to Brex and prefill signup information”
   • [claimed-docs] “Travel API: View trips made in Brex Travel”
   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [claimed-docs] “Postman is a browser or desktop app used for API testing. It gives you a UI to easily test and play around with API calls without having to …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”
   • [probe] “official MCP server documented at https://developer.brex.com/docs/mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   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

   Brex—none0/10

   Brex documents many separate API modules (Accounting, Budgets, Team, Payments, etc.) and an MCP server for AI assistants, but there is no evidence of a mechanism to issue scoped or least-privilege API credentials/tokens specifically for an agent (e.g., OAuth scopes, granular API-key permissions, or agent-specific credential issuance).

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “official MCP server documented at https://developer.brex.com/docs/mcp”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Mercury
   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

   Brex—none0/10

   Evidence shows extensive REST API documentation (Accounting, Budgets, Team, Payments, Transactions, etc.), a quickstart guide, Postman collection, and third-party low-code integrations (Pipedream, Zapier), but no mention anywhere of official client SDKs (e.g., Python/JS/Go libraries). A probe for an OpenAPI spec that could underpin SDK generation also returned 404s across all candidate paths, suggesting no discoverable machine-readable spec for SDK tooling.

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Check out our quickstart guide to get up and running making your first Brex API call in just a few minutes.”
   • [claimed-docs] “Postman is a browser or desktop app used for API testing. It gives you a UI to easily test and play around with API calls without having to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Brex
   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

   Brex✓fullclaimed8/10

   Brex has a dedicated Webhooks API with first-party docs explicitly describing real-time event notifications for account activity, directly matching the story. Missing for 10: independent/hands-on developer corroboration of webhook reliability and no evidence of event-type coverage breadth or payload examples.

   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to Mercury
   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

   Brex!disputedcontradicted4/10

   Brex markets AI-powered features like an 'AI-powered expense assistant' and AI automation for invoices/GL coding, implying AI-generated insights from user financial data (brex-docs-7, brex-docs-16, brex-docs-9). However, hands-on community discussion of Brex's own AI chatbot demo reports concrete factual errors (bot miscounted/misdated receipts) and criticism that the underlying model is non-deterministic and unreliable for financial insight tasks, directly contradicting the polished vendor claims (brex-comm-1, brex-comm-4). Missing for 10: first-party documentation of a concrete insights/suggestions feature (e.g., dashboards with AI commentary), independent verification that current production AI features are accurate, and resolution of the hallucination concerns raised by the community.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”
   • [claimed-docs] “8 reasons to switch to AI-powered financial operations”
   • [community] “This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using 'a non-deterministic model' for production use ca…”
   • [community] “Is it me or is the bot's output in the section 'Give a Bot a Fish' incorrect? It states that the most recent receipt is from Mar 5th, 2023 b…”

   proof ↗⚑ flag

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

   weight 2 · round to Brex
   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

   Brex~partialclaimed6/10

   Brex documents several automation building blocks that can run without manual triggering — auto-enforced budget controls, AI-powered invoice entry/approval/payment automation, automated GL coding/accruals, a Webhooks API for real-time event-driven triggers, and third-party workflow automation via Pipedream/Zapier (e.g., bulk card issuance, scheduled CSV exports) — which together let an AI-native user configure background automations. However, there is no first-party 'agent scheduler' or persistent autonomous-agent runtime; the MCP server (brex-docs-21) is framed as an interactive assistant interface rather than an autonomous background job runner. Missing for 10: a dedicated autonomous-agent/scheduling feature explicitly designed for unattended multi-step AI workflows, and independent confirmation that these automations run reliably without human oversight.

   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”
   • [claimed-docs] “Pipedream is a low-code integration platform that Brex integrates with to enable various use cases including bulk creating users, setting mo…”
   • [claimed-docs] “Monthly Export of Brex Card Transactions to CSV in Google Drive”
   • [claimed-docs] “you can use this integration to create virtual cards for a WFH stipend where the card limit resets every month”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”

   proof ↗⚑ flag

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

   weight 3 · round to Brex
   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

   Brex!disputedcontradicted5/10

   Brex documents an 'AI-powered expense assistant' and AI-driven automation for invoice/GL coding (brex-docs-16, brex-docs-7, brex-docs-9), suggesting a built-in assistant users can delegate tasks to. However, hands-on community discussion of Brex's own AI demo reports factual errors in the assistant's output (misidentifying the most recent receipt date) and skepticism about using a non-deterministic model for production financial tasks (brex-comm-1, brex-comm-2, brex-comm-4), directly contradicting reliability claims. Missing for 10: independent corroboration of the assistant working correctly in production, clear scope/limits of what tasks can be delegated, and resolution of the reported output error.

   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “8 reasons to switch to AI-powered financial operations”
   • [community] “This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using 'a non-deterministic model' for production use ca…”
   • [community] “It seems like they're using OpenAI's API... but they should be crystal clear about this. The expenses example seems like sloppy engineering—…”
   • [community] “Is it me or is the bot's output in the section 'Give a Bot a Fish' incorrect? It states that the most recent receipt is from Mar 5th, 2023 b…”

   proof ↗⚑ flag

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

   weight 2 · round to Brex
   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

   Brex✓fullprobed7/10

   Brex documents an official MCP server that lets AI assistants manage expenses, look up users, check cards, and review transactions 'through natural language,' directly enabling natural-language operation of the product (brex-docs-21, brex-probe-3). However, there's no independent hands-on validation of the MCP server's reliability, and older community commentary raises general skepticism about non-deterministic AI outputs in Brex's financial workflows (brex-comm-1–4), though this pertains to a separate legacy AI feature rather than the MCP server itself. Missing for 10: independent/hands-on corroboration of the MCP server's natural-language commands working reliably in practice, and broader documentation of natural-language support beyond the MCP feature.

   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “official MCP server documented at https://developer.brex.com/docs/mcp”
   • [community] “This reflects astonishingly poorly on Brex. What customer wants to hear that Brex is using 'a non-deterministic model' for production use ca…”

   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

   Brex~partialprobed4/10

   Brex publishes extensive API reference docs (Accounting, Budgets, Team, Webhooks, etc.) and a quickstart guide, and explicitly integrates with Postman so developers can 'test and play around with API calls without having to write code' (brex-docs-22, brex-docs-5). However, a probe found no OpenAPI/Swagger spec at standard endpoints (all 404s), indicating no confirmed built-in interactive/runnable API explorer on the docs site itself—Postman is an external tool rather than embedded runnable examples. Missing for 10: a native in-browser interactive API console with runnable code samples, and independent confirmation of an OpenAPI spec powering such a reference.

   • [claimed-docs] “Check out our quickstart guide to get up and running making your first Brex API call in just a few minutes.”
   • [claimed-docs] “Postman is a browser or desktop app used for API testing. It gives you a UI to easily test and play around with API calls without having to …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”

   proof ↗⚑ flag

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

   weight 2 · round to Mercury
   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

   Brex!disputedcontradicted3/10

   Brex's docs reference an 'openapi' URL structure (e.g. developer.brex.com/openapi/webhooks_api.md) implying spec-based documentation, but a direct probe for standard machine-readable spec files (openapi.json, swagger.json, etc.) returned 404 on all candidate paths, meaning no downloadable OpenAPI spec is actually accessible. missing for 10: a working link to a downloadable OpenAPI/Swagger JSON or YAML file, confirmation that the 'openapi' folder pages are anything more than rendered markdown docs.

   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   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

   Brex—none0/10

   No mention of a sandbox, test environment, or non-production mode anywhere in Brex's developer docs, API listings, or MCP server description; Postman usage is for testing API calls but against real accounts, not a sandbox. Missing for 10: any documented sandbox/test environment, test API keys, or separation from production data.

   • [claimed-docs] “Postman is a browser or desktop app used for API testing. It gives you a UI to easily test and play around with API calls without having to …”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://developer.brex.com/llms.txt # Brex Developer API > APIs to build on top of the Brex financial OS. ## T…”

   proof ↗⚑ 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

   Brex—none0/10

   The evidence pack lists numerous Brex APIs and developer docs but nowhere mentions API versioning schemes or a documented deprecation policy; the OpenAPI spec probe even returned 404s, suggesting limited machine-readable API documentation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Check out our quickstart guide to get up and running making your first Brex API call in just a few minutes.”

   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

   Brex~partialprobed6/10

   Brex documents bulk-style automation primarily through its Pipedream integration, explicitly citing 'bulk creating users, setting monthly limits for users, issuing virtual cards, and sending vendor payments,' and its API surface (Team, Payments, Budgets, Expenses) could support scripted multi-item operations. However, this relies on a third-party low-code platform rather than native bulk endpoints in Brex's own API docs, and there's no probe evidence of a bulk API or batch endpoint in the OpenAPI spec (which 404s). Missing for 10: native/first-party bulk API endpoints, documented batch limits, and independent verification of at-scale bulk operations.

   • [claimed-docs] “Pipedream is a low-code integration platform that Brex integrates with to enable various use cases including bulk creating users, setting mo…”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   Brex~partialclaimed5/10

   Brex has a Webhooks API for event notifications and Budgets API for auto-enforced spend controls, plus Pipedream/Zapier integrations that can chain actions on events, but these require external low-code platforms rather than a native rules engine where users directly define 'if event X then action Y' automations. missing for 10: a native rule-builder/automation engine within Brex itself, documented conditional trigger-action syntax, and independent confirmation that webhook+action chains work reliably in production.

   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”
   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Pipedream is a low-code integration platform that Brex integrates with to enable various use cases including bulk creating users, setting mo…”
   • [claimed-docs] “Monthly Export of Brex Card Transactions to CSV in Google Drive”
   • [claimed-docs] “you can use this integration to create virtual cards for a WFH stipend where the card limit resets every month”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Brex
   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

   Brex~partialclaimed4/10

   Brex has no native cron/scheduling API, but its documented Zapier example ('Monthly Export of Brex Card Transactions to CSV in Google Drive') and Pipedream integration examples imply recurring automated workflows can be built via third-party low-code platforms rather than Brex itself. Missing for 10: a first-party scheduler or recurring-job API, and any evidence of AI-native (MCP/agent) triggered recurring workflows.

   • [claimed-docs] “Pipedream is a low-code integration platform that Brex integrates with to enable various use cases including bulk creating users, setting mo…”
   • [claimed-docs] “Monthly Export of Brex Card Transactions to CSV in Google Drive”
   • [claimed-docs] “you can use this integration to create virtual cards for a WFH stipend where the card limit resets every month”
   • [claimed-docs] “Simplify every task that finance touches with automatic syncing across 1,000s of native integrations.”

   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

   Brex—none0/10

   No evidence of any versioning, review, or rollback mechanism for automations/workflows (e.g., budget rules, approval flows, or webhook configs) — evidence only covers APIs, integrations, and general automation features without any change-history, audit-diff, or rollback capability.

   ⚑ flag

Card controls

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

   weight 2 · round to Brex
   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

   Brex✓fullclaimed7/10

   Brex explicitly markets budgets with auto-enforced spend limits (brex-docs-6) and offers a dedicated Budgets API for managing budgets and budget programs (brex-docs-2), plus Team API for department/user structuring (brex-docs-4). Missing for 10: independent/hands-on verification of enforcement behavior and no detailed docs excerpt showing department-level scoping specifics beyond marketing copy.

   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”

   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

   Brex✓fullclaimed7/10

   Brex explicitly advertises budgets and per-transaction/per-card spend limits with auto-enforced controls (brex-docs-6, brex-docs-15) and exposes a Budgets API and Team API for managing users, departments, and cards (brex-docs-2, brex-docs-4), directly matching the finance-lead's need for granular per-employee card controls. missing for 10: independent/hands-on verification of the granularity of controls in practice and no dedicated documentation excerpt detailing exact limit types (e.g., merchant category, time-based) beyond marketing copy.

   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”

   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

   Brex—none0/10

   The evidence pack mentions a Team API that can 'manage users, locations, departments, and cards' but never describes freezing a lost/stolen card or ordering a replacement. No docs, community, or probe evidence confirms this specific capability. Missing for 10: explicit documentation or UI/API evidence of card freeze and replacement ordering workflow.

   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”

   proof ↗⚑ 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

   Brex—none0/10

   Evidence shows budgets/spend-limit setting and per-transaction limits for cards (brex-docs-6, brex-docs-15) but no mention of a self-service screen for requesting a transaction limit increase or an approval workflow for such requests.

   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”

   proof ↗⚑ 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

   Brex~partialclaimed7/10

   Vendor docs explicitly describe issuing vendor-specific virtual cards with per-transaction limits and procurement approval flows, plus budget-based auto-enforced spend limits and a Team API to manage cards, directly matching the story; a Pipedream example even shows programmatic virtual card creation for a recurring stipend use case. However, all evidence is vendor-authored with no independent/hands-on confirmation of speed ('instantly') or real-world reliability of the scoping controls. Missing for 10: independent or hands-on verification of instant card creation and real customer confirmation of vendor/purpose-scoped limits working as described.

   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “you can use this integration to create virtual cards for a WFH stipend where the card limit resets every month”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Brex~partialclaimed6/10

   Brex's Team API explicitly manages users, departments, and cards, and marketing docs describe issuing vendor/team-specific cards with per-transaction limits and budget-based spend controls, supporting role-based card issuance. However, evidence never explicitly confirms physical (vs. virtual-only) card issuance or details role/permission granularity for card assignment. missing for 10: explicit mention of physical card issuance, detailed role-based permission model, independent corroboration of the physical card program.

   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”

   proof ↗⚑ flag

Card rewards

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

   weight 1 · round to Brex
   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

   Brex~partialclaimed3/10

   Brex advertises global corporate cards and banking usable in 120+ countries with fast global payments, implying international spend capability, but there is no explicit claim of zero foreign transaction fees or fee-free cash withdrawals abroad. Missing for 10: explicit no-foreign-transaction-fee policy, ATM/cash withdrawal terms abroad, and independent confirmation of fee-free international spend.

   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”
   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”

   proof ↗⚑ 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

   Brex~partialclaimed3/10

   Brex marketing mentions cash back as a benefit of the business account, implying it accrues on spend, but there is no documentation describing the mechanism, whether it is automatic, or that no redemption step is required. missing for 10: details on automatic accrual process, redemption mechanics, any confirmation that no manual steps are needed, independent corroboration.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”

   proof ↗⚑ flag

Procurement automation

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

   weight 2 · round drawn
   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

   Brex—none0/10

   No evidence of any vendor contract parsing or AI auto-population of procurement request forms; Brex's AI features cover expense assistant, invoice entry automation, and MCP-based account queries, not contract parsing for procurement. Missing for 10: any contract-ingestion/parsing feature, procurement form auto-population, or vendor document extraction capability.

   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”

   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 Brex
   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

   Brex✓fullclaimed7/10

   Brex's docs describe automated receipt capture/matching (Expenses API 'receipt match and receipt uploads', 'automated receipts' in the expense assistant) and automatic GL coding by entity at close, matching the story of capture+coding without manual entry. missing for 10: independent/hands-on confirmation that receipts are captured at the exact moment of swipe with no manual step, and clearer documentation of the automation trigger mechanism.

   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”
   • [claimed-docs] “automate GL coding by entity globally”
   • [claimed-docs] “Book accruals for incomplete expenses with one click to close the books every day and automate GL coding by entity globally.”

   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

   Brex~partialclaimed6/10

   Brex's docs mention 'automated receipts' and an Expenses API with 'receipt match and receipt uploads', supporting automatic attachment of uploaded receipts to transactions, but there is no explicit mention of emailing receipts in or independent hands-on confirmation of the matching accuracy. Missing for 10: explicit email-to-receipt ingestion documentation, and independent verification that auto-matching works reliably.

   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”

   proof ↗⚑ flag

Embedded finance

1. developerOffer embedded banking accounts to my customers without holding my own financial license

   weight 1 · round drawn
   Mercury—none0/10

   Mercury's evidence describes a business bank account plus an API/MCP/CLI for managing that single business's own accounts, cards, invoices, and payments — not a banking-as-a-service platform for issuing white-labeled accounts to a developer's end customers under Mercury's charter. Nothing in the docs, changelog, SDKs, or API catalog mentions account issuance for third-party end users, program management, or BaaS partnership terms.

   • [claimed-docs] “Pull balances, list transactions, and initiate ACH transfers — all through a single REST API”
   • [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”
   • [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…”

   proof ↗⚑ flag

   Brex—none0/10

   Brex's developer APIs (Team, Payments, Transactions, Onboarding) are for managing a company's own Brex account or referring customers to sign up for Brex directly — there is no evidence of a BaaS/embedded-banking program letting developers white-label bank accounts for their own end customers without a license. The Onboarding API only prefills signup info for referrals, not embedded account issuance.

   • [claimed-docs] “Onboarding API: Refer your customers and personal contacts to Brex and prefill signup information”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”

   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

   Brex—none0/10

   No evidence of an application-status tracking feature for founders during onboarding review; the Onboarding API only covers referral/prefill signup, and community threads discuss rejections/closures but not a status-check capability.

   ⚑ flag

Switching

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

   weight 2 · round to Mercury
   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

   Brex✓fullclaimed7/10

   Brex explicitly markets itself as a unified spend platform combining cards, banking, expense management, bill pay, accounting, and travel booking, directly matching the founder's need to consolidate point solutions (brex-docs-26, brex-docs-27, brex-docs-7, brex-docs-15, brex-docs-16). Rich API and integration documentation (Accounting, Payments, Expenses, Team, Travel APIs) supports this being a functioning single platform rather than marketing-only claims. missing for 10: independent/hands-on case studies confirming founders actually consolidated multiple tools onto Brex, and no third-party corroboration of the 'fully unified' claim beyond vendor docs.

   • [claimed-docs] “Brex is the first fully unified spend platform — with global corporate cards, expense management, reimbursements, travel, and bill pay.”
   • [claimed-docs] “Modern cards, banking, expenses, accounting, and more — in 120+ countries.”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”
   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “All your tools synced in one place.”

   proof ↗⚑ flag

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

   weight 2 · round to Mercury
   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

   Brex!disputedcontradicted3/10

   Brex offers an Onboarding API and quickstart docs implying fast signup (brex-docs-18, brex-docs-5), but multiple firsthand founder accounts describe painful, rejected, or abruptly terminated onboarding—requiring $1MM minimum balances for non-VC-backed startups, multi-attempt rejections, and being told to leave with 6 weeks notice—directly contradicting a quick, smooth week-long onboarding experience. missing for 10: any documented end-to-end onboarding timeline, first-party case studies showing 'week not months' onboarding, and resolution of the negative hands-on reports.

   • [claimed-docs] “Onboarding API: Refer your customers and personal contacts to Brex and prefill signup information”
   • [claimed-docs] “Check out our quickstart guide to get up and running making your first Brex API call in just a few minutes.”
   • [community] “They refused my business because I didn't have SV VC money. Chase got it instead, but they are losing it next month because of their shenani…”
   • [community] “Brex literally came to us one day in 2022 and notified us that 'We have 6 weeks to move everything off their service,' refocusing on enterpr…”
   • [community] “Brex rejected my application to open a bank account on 3 different occasions. mercury.com provided me the B2B account within the day and the…”
   • [community] “Brex founder here. We've made the difficult decision to no longer offer services to the small business market, putting the full weight of Br…”
   • [community] “This decision cannot be either changed or delayed. Your account will be closed by August 15. We've appreciated your business and wish you al…”
   • [community] “I had a terrible experience 'onboarding' with Brex last year. They approved my bootstrapped startup and sent a physical card only to rescind…”
   • [community] “(Web3 startup founder) Tried signing up for Brex and after a long and painful signup process they actually needed me to connect a different …”

   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

   Brex~partialprobed6/10

   Brex documents a broad first-party API surface (accounting, budgets, team, expenses, payments, transactions, travel, onboarding, webhooks) covering most core UI workflows, plus an MCP server for natural-language access, suggesting strong but not confirmed full parity. There is no explicit vendor claim of 1:1 UI/API parity, no independent corroboration that every UI action is API-accessible, and a probe for a public OpenAPI spec returned 404s, limiting verifiability. Missing for 10: explicit parity statement, independent verification of completeness, discoverable OpenAPI schema.

   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Webhooks API: Send real-time notifications based on events”
   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Payments API: Manage vendors and send ACH, domestic wires, and checks”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Onboarding API: Refer your customers and personal contacts to Brex and prefill signup information”
   • [claimed-docs] “Travel API: View trips made in Brex Travel”
   • [claimed-docs] “The Brex MCP server lets AI assistants interact directly with your Brex account: manage expenses, look up users, check cards, review banking…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developer.brex.com/openapi.json, https://developer.brex.com/swagger.json, https://developer.…”

   proof ↗⚑ flag

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

   weight 3 · round to Mercury
   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

   Brex~partialcommunity4/10

   Brex exposes Transactions, Expenses, Accounting, and Team APIs that let users pull data out programmatically, and a documented Zapier example shows exporting card transactions to CSV — both are open, non-proprietary formats. However, there is no documented single 'export everything and leave' feature, no full account-data portability/archive tool, and community threads describe abrupt account closures with no mention of a clean data-export path. Missing for 10: a dedicated full-account data export/portability feature, confirmation that all data categories (not just transactions/expenses) are exportable, and independent evidence of successful full data migration on account closure.

   • [claimed-docs] “Expenses API: View and manage card expenses data, receipt match and receipt uploads”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Accounting API: View and manage accounting data”
   • [claimed-docs] “Monthly Export of Brex Card Transactions to CSV in Google Drive”
   • [community] “This decision cannot be either changed or delayed. Your account will be closed by August 15. We've appreciated your business and wish you al…”

   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

   Brex—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic controls for where Brex stores customer data; all docs focus on APIs, integrations, and product features. Missing for 10: any documentation of region/residency selection, data center locations, or compliance certifications tied to data storage location.

   ⚑ 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

   Brex—none0/10

   No evidence pack items address data retention, deletion controls, or privacy/data lifecycle policies for AI-native usage (e.g., MCP server or API data handling); the docs cover API capabilities and integrations but nothing about controlling or deleting stored 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

   Brex~partialclaimed5/10

   Brex's Team API explicitly manages 'users, locations, departments, and cards,' suggesting structural support for organizing teams by location/department, and Budgets API allows spend controls tied to programs/teams. However, no evidence details specific role definitions (e.g., admin, bookkeeper, approver), permission granularity, or an admin console for configuring access levels. Missing for 10: explicit role/permission documentation, UI screenshots of role management, and independent confirmation of granular access control enforcement.

   • [claimed-docs] “Team API: Manage users, locations, departments, and cards”
   • [claimed-docs] “Budgets API: Manage budgets and budget programs”
   • [claimed-docs] “Issue vendor-specific cards for any teams with per-transaction limits and procurement approval flows.”

   proof ↗⚑ flag

Fraud detection

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

   weight 2 · round to Mercury
   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

   Brex—none0/10

   Evidence shows rule-based auto-enforced budget controls (brex-docs-6) and a general AI-powered expense assistant (brex-docs-16), but nothing describes AI automatically detecting or flagging anomalous/out-of-policy transactions for review. Community threads discuss AI reliability concerns generally but don't confirm or deny this specific capability.

   • [claimed-docs] “Set budgets and allocate spend limits with auto-enforced controls that empower employees to spend wisely.”
   • [claimed-docs] “Make expenses a breeze for employees and managers with automated receipts, an AI-powered expense assistant, in-app travel bookings and itine…”
   • [claimed-docs] “Save time with AI-powered automation of invoice entry, approval, and payments.”

   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

   Brex—none0/10

   The evidence pack contains no documentation or claims about live customer support availability, support channels, or response times for urgent account issues. Community evidence instead discusses account closures and rejections, which is unrelated to support-reliability as described in the story.

   ⚑ 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

   Brex—none0/10

   No evidence in the pack mentions FDIC sweep networks or multi-bank deposit insurance maximization; Brex's documentation covers cards, expenses, APIs, and integrations but nothing about deposit sweep programs.

   ⚑ flag

Cash automation

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

   weight 2 · round to Mercury
   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

   Brex—none0/10

   The evidence pack covers Brex's cards, expenses, budgets, payments, and webhooks APIs but contains no mention of auto top-up between accounts or low-balance alert functionality, which is a fair capability to expect from a business banking/treasury platform. Missing for 10: any documentation of auto-transfer/sweep rules between accounts, low-balance threshold alerts, or treasury automation features.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”
   • [claimed-docs] “Transactions API: View your transactions, accounts, and statements”
   • [claimed-docs] “Brex uses webhooks to send real-time notifications when events happen in the accounts that you manage.”

   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

   Brex~partialclaimed5/10

   Brex's marketing explicitly advertises 'up to 3.70%' yield on funds held directly in a Brex business account, indicating cash held with Brex (not moved to a separate institution) can earn yield. However, evidence is limited to a single marketing line with no detail on mechanism, eligibility, or independent verification. Missing for 10: documentation on how yield is generated (program banks/money-market sweep), terms/limits, and independent/hands-on confirmation of the yield actually being credited.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”

   proof ↗⚑ 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

   Brex—none0/10

   Evidence shows Brex offers a yield on cash ("Unlock up to 3.70%") but there is no mention of a distinct high-yield savings sub-account or of automated transfer rules to move cash into/out of such a sub-account.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”

   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

   Brex—none0/10

   Brex advertises up to 3.70% yield on cash balances (brex-docs-10), but there is no evidence of interest being earned specifically on balances held in multiple currencies—Brex's offering appears to be a single (USD) yield-bearing cash account with no multi-currency treasury/interest feature documented.

   • [claimed-docs] “Unlock up to 3.70%†, fast global payments, up to 30x higher credit limits, and cash back with a Brex business account.”

   proof ↗⚑ flag