Approval graph for Mercury-based startups that turns Slack and spreadsheet finance work into bank-ready, auditable payment decisions.

1. Mercury is teaching startup finance teams to expect finance tasks to be executed from an AI-native banking surface rather than a static portal.
2. Developer-facing tools such as MCP and a CLI make programmable finance workflows newly credible, opening room for software that structures requests before they hit the bank.
3. The cluster explicitly frames spreadsheet-heavy finance work as the pain point, so a control layer that replaces ad hoc approvals can ride an already-funded buyer budget.
4. A $200 million round at a multibillion-dollar valuation signals that AI-native finance operations is becoming foundational infrastructure, which lowers buyer risk for an adjacent workflow product.

Catalyst. Mercury Command and adjacent AI tooling make finance teams newly willing to execute work from a natural-language banking interface, which raises the urgency for a workflow-control layer that can replace ad hoc spreadsheet approvals.

The product sits between request channels such as Slack, invoice inboxes, and lightweight AP tools on one side and Mercury on the other. It assembles each payment or transfer into a structured action packet containing the requestor, vendor or counterparty, budget owner, current cash position, prior approvals, and expected runway effect. Finance leaders can approve from one queue, while embedded agents draft follow-ups for missing context, enforce policy thresholds, and route exceptions to the right owner instead of bouncing them through chat. Over time, the platform becomes the memory layer for who can spend what, under which conditions, and why a payment was approved or blocked.

What's different. Mercury and other fintech products can own the banking destination, but they do not automatically own the messy approval context that lives across chat, budgets, contracts, and informal finance policies. Lightweight AP tools capture bills, yet they still miss the startup-specific decision layer around runway, founder signoff, and exception routing. This company wins by becoming the approval graph that makes bank AI trustworthy, then compounding a dataset of spending norms, policy exceptions, and finance-action outcomes that horizontal copilots or banks would struggle to reconstruct.

Jobs to be done

flowchart LR
  Buyer[Head of Finance] --> Pain[Slack and spreadsheet approvals around bank actions]
  Pain --> Product[Approval graph for bank-ready finance actions]
  Product --> Outcome[Faster payments with policy control and audit trail]

Executive takeaways

• Mercury is turning banking into an execution surface with bill pay, accounting automation, API/CLI access, AI Insights, and a read-only MCP layer, which makes a separate control layer more plausible now than even a year ago [3][5][7][8][12].
• The acute pain is not sending money; it is getting bank-ready approval evidence out of Slack, spreadsheets, invoices, and ad hoc board-level cash scrutiny fast enough for lean Series A-B finance teams [8][15][20][21][22].
• Incumbents already cover pieces of the workflow: Mercury owns the bank destination, Ramp and Brex own broad spend controls, BILL owns deeper AP automation, and Zip owns procurement intake. None defaults to a Mercury-native approval graph tied to runway impact [23][24][25][28][29][30][31][32][33].
• The beachhead is real but focused. Bottom-up sizing supports a roughly $96.0M U.S. TAM and a $28.8M initial SAM if the company stays tightly scoped to Mercury-banked, post-seed startups before ERP adoption [14][20][21][37][38][39].
• The biggest go-to-market leverage is the accountant and fractional-CFO ecosystem around Mercury, because these partners already feel the reporting, audit, and control pain first and can refer accounts at the exact moment manual approvals break [10][11][18][20][21].

Market definition

U.S.-first approval orchestration software for Mercury-centered startup finance teams. The product sits between request channels such as Slack, invoice inboxes, lightweight AP tools, and Mercury itself to turn a messy spend request into a bank-ready action packet with approver identity, policy status, supporting evidence, and runway context. It excludes full ERP replacement, generic procurement suites, and pure bank-core infrastructure [3][5][8][15][23][29][31][33].

Customer and buyer

The daily user is a head of finance, controller, or senior finance manager at a venture-backed software startup that has outgrown founder-memory finance but not yet moved to a heavyweight ERP. The buyer is usually the CFO, finance lead, or founder who owns board reporting, audit readiness, and cash policy. The strongest trigger appears when investor reporting, board meetings, or payment volume expose that the company cannot reliably explain what was approved, why, and what it did to runway [19][20][21][22].

Buying triggers

• A board meeting, fundraise, or audit-prep cycle exposes that the company cannot produce reliable accrual-based reporting or approval evidence quickly. [20][21][22]
• Payment volume rises enough that finance needs structured routing, separation of duties, and faster mobile or Slack approvals instead of ad hoc chasing. [8][15][23][24]
• The startup wants AI-native finance workflows inside banking, but Mercury's current MCP surface is read-only and write actions still need a safer control layer. [3][5][7]

Willingness to pay

Buyers already budget for finance workflow software and advisory support: Mercury tiers run from free to $299 per month, Ramp from $0 to $15 per user per month, Brex from $0 to $12 per user per month, and BILL from $49 to $89 per user per month before enterprise add-ons. That suggests room for a low-five-figure annual control layer if it replaces manual coordination, compresses close/board prep effort, and prevents one incremental finance hire, but the product will still need a sharp ROI sale rather than a loose AI-tools budget [2][10][18][23][28][30]. [2][10][18][23][28][30]

Category dynamics

Growth signal 40% customer growth YoY at Mercury in 2024

Validation signals

• Mercury's CEO explicitly said growing companies want more controls around payments and better accounting-system integration.
• Mercury launched Insights around the explicit pain of exporting CSVs and juggling spreadsheets just to understand runway and spend.
• Pilot's Series A and board-meeting evidence shows founders regularly lack confidence in reporting, runway visibility, and investor-ready finance infrastructure.
• Mercury says it serves 300,000+ companies and one in three U.S. startups, which creates enough ecosystem concentration for a focused partner-led wedge.

Regulatory & technical constraints

• International vendors and certain counterparties require OFAC-aware screening before payment release.
• ACH approvals have to land inside real settlement windows if the product is going to feel operationally reliable.
• Finance buyers will expect segregation of duties, approval hierarchies, and durable audit evidence consistent with internal-control frameworks.
• Mercury's hosted MCP is read-only, so any automated approval-to-payment experience needs a deliberate split between analysis context and write-authorized execution.

The market breaks into four adjacent camps. Mercury is moving upward from banking into bill pay, spend management, accounting automations, Insights, and AI interfaces [3][7][8][12]. Ramp and Brex are broad spend-and-AP suites with sophisticated approval routing and better cross-company controls, but their motion is not Mercury-native and startup banking is not their only center of gravity [23][24][25][27][28][29]. BILL is the AP-depth incumbent with stronger multi-entity, vendor-network, and invoice-volume credentials, but it is less native to startup banking context and more oriented to centralized AP throughput [30][31][32]. Zip is the procurement-orchestration ceiling competitor, strongest before the payment decision, but it is not natively designed around Mercury-based cash execution [17][33].

Why incumbents do not win by default

• Banking platforms. Mercury validates the wedge by proving startups want approvals, bill pay, accounting automation, and AI inside the bank, but Mercury's current agent surface is read-only and its native workflow centers on Mercury rather than cross-system approval context.
• Spend suites. Ramp and Brex win when the buyer wants broad employee spend, cards, AP, and procurement in one suite, but that breadth also makes them less opinionated about Mercury-first runway-aware approval packets.
• AP specialists. BILL is strongest when invoice scale, vendor-network reach, and multi-entity throughput are the primary problem, yet that still does not make BILL the memory layer for founder signoff, Slack exception routing, and bank-native cash context.
• Procurement orchestration. Zip owns intake and approval orchestration at larger organizations, but it starts farther upstream from banking execution and is heavier than the initial 50-250 employee startup wedge needs.

Approval Graph is a Mercury-first finance control layer for U.S. Series A-B software startups that still approve vendor payments, budget exceptions, and cash moves in Slack and spreadsheets. The MVP does not replace the bank, AP tool, or ERP; it turns each request into a bank-ready action packet with approver identity, policy checks, supporting evidence, and projected runway impact before a human releases payment. The initial buyer is the CFO or head of finance at a 50-250 employee startup using Mercury as its primary bank and feeling new pressure from board reporting, audit prep, or a sudden rise in non-payroll payment volume. This beachhead is narrow on purpose because the pain is acute there, Mercury's accountant ecosystem gives a credible distribution path, and broader spend-management categories are already crowded by Mercury, Ramp, Brex, BILL, and Zip. Researched bottom-up sizing supports an initial U.S. TAM of about $96.0M, a beachhead SAM of about $28.8M, and a year-3 SOM of about $2.9M if the company stays tightly focused before expanding. The go-to-market should sell approval evidence and faster decisioning, not generic AI automation, with paid pilots that prove shorter turnaround time and cleaner audit trails before broader rollout. The main strategic risk is that buyers may decide Mercury native tools or broader suites are good enough unless the product shows clear value as a cross-system approval-memory layer. The biggest evidence gaps are direct proof that Mercury-based startups will buy a focused control layer before incumbent-suite expansion and proof that early customer data is clean enough to avoid a services-heavy onboarding model.

Problem

• Series A-B startups often approve vendor payments and cash exceptions across Slack threads, spreadsheets, and bank portals, leaving no reliable system of record for who approved what and why.
• When board, audit, or runway scrutiny increases, lean finance teams cannot quickly connect a payment decision to budget status, supporting evidence, and cash impact without manual chasing.

Solution

• Capture requests from Slack, invoice inboxes, and lightweight AP tools, then assemble a single approval packet with requestor, vendor, approver chain, policy status, and runway context.
• Keep execution human-approved on day one while creating an auditable approval graph that can later expand into broader finance controls and treasury workflows.

Why we win

• The product wedges into the gap banks and AP suites do not fully own: cross-system approval context spanning chat, budgets, contracts, invoices, and Mercury-based cash execution.
• A Mercury-centered accountant and fractional-CFO channel can surface buyers at the exact moment manual approvals break, while each deployment compounds proprietary approval, exception, and outcome data.

Milestones

flowchart LR
  Wedge[Mercury-first approval wedge] --> MVP[Approval packet MVP]
  MVP --> Proof[Faster approvals and audit proof]
  Proof --> Expansion[Multi-entity and treasury expansion]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 40% of Mercury-based Series A-B prospects still run non-payroll approvals primarily through Slack, spreadsheets, or lightweight AP tooling.
• CFOs will fund a focused approval-control layer before replacing their bank or buying a broader spend suite.
• The first 3-4 integrations cover a majority of approval evidence needs in the beachhead.
• Paid pilots convert to production above 60% when the product shows faster approvals and cleaner audit evidence.
• The approval graph becomes a defensible data asset before Mercury or suite incumbents close the gap.

Open diligence questions

• How often is the urgent pain approval routing versus evidence retention versus budget visibility?
• What budget line funds this product before ERP adoption: finance systems, audit readiness, or headcount avoidance?
• How many target accounts already use Ramp, Brex, or BILL workflows well enough that the wedge is only incremental?
• Which data sources are consistently missing when a finance lead tries to approve a payment confidently?
• Can accountant and fractional-CFO partners drive repeatable introductions, or is the motion still mostly founder-led outbound?

Model sanity

• Revenue engine. Base-case revenue comes from turning a narrow paid-pilot motion into 50 paying accounts by Q4Y3 at a blended $33K ACV.
• Must go right. Deployment has to stay close to the BP's under-45-day milestone so partner referrals do not turn into a services bottleneck.
• Model breaks if. The model degrades fastest if the sales cycle stretches toward 9 months while gross margin slips into the mid-60s because cash then trends toward the downside low point.
• Next-round proof. The next financing is justified if the company exits Y2 with 10-15 production logos, credible partner-sourced pipeline, and referenceable proof that approval turnaround and evidence quality improved.

Scenarios

Sensitivity

flowchart LR
  Leads[Triggered outbound + accountant partners] --> PaidPilots[Paid pilots]
  PaidPilots --> Production[Production customers]
  Production --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[Gross profit at 70%]
  GrossProfit --> Cash[Ending cash after opex]

Flags: Revenue per FTE stays below mature SaaS benchmarks through Y3 because the model deliberately front-loads integrations and onboarding before broad expansion. · The base case still assumes buyers fund a focused approval-control layer before Mercury, Ramp, Brex, or BILL absorb the same budget line. · If partner-sourced opportunities do not reach about 25% of qualified pipeline by Y2H2, CAC and sales-cycle assumptions likely drift toward the downside case.

• Bank platform encroachment. Mercury or another fintech could extend native workflows from command execution into approval controls and shrink the independent wedge. Mitigation: Own cross-system approval context outside the bank, integrate with multiple finance inputs, and focus on policy memory that is hard for a single bank surface to recreate.
• Thin data exhaust early on. Early-stage customers may not have clean budget, contract, or invoice data, which can limit automation quality and trust. Mitigation: Start with approval capture and evidence logging first, support lightweight file and Slack ingestion, and add deeper policy automation only after clean patterns emerge.
• Budget skepticism. Startup finance leaders may see approval tooling as a nice-to-have until a painful audit, board request, or payment failure forces change. Mitigation: Sell around a concrete trigger, quantify hours saved and risk reduced in the first workflow, and price the product so it is easier to justify than hiring another finance generalist.