How to integrate Mercury with QuickBooks (the right way)

Mercury wins on UI. That is also where most teams stop using it. A founder opens the dashboard once a week, the bookkeeper exports a CSV at month end, and the API token sitting in the admin panel never gets generated.

That is a missed unlock. Mercury is one of the few banking platforms a mid-market B2B company can actually build on. Real REST endpoints. Webhooks. Treasury yields north of 3%. A native MCP server. The gap between using Mercury as a bank account and using it as the financial spine of the company is enormous, and almost nobody crosses it without help.

This is the version of Mercury our $5M to $200M clients run. Treasury sweeps without anyone touching them. Closed deals trigger invoices automatically. Vendor categorisation happens before transactions hit the GL. The finance function stops being a stack of spreadsheets and a portal someone logs into when it is too late.

The shift is mostly cultural. Mercury sold itself as a bank account, so most companies treat it as a bank account. Once the finance lead and the founder agree it is actually infrastructure, the rest is engineering. The plays below are the four we run for almost every mid-market client, in roughly the order we sequence them.

The Pattern Most Mercury Customers Have

We see the same symptoms across companies running Mercury well below its capability:

• Six-figure balances sitting in checking, earning nothing, because nobody set up Treasury or set it up once and forgot.
• Month-end close eats a full week, mostly because someone is hand-categorising transactions in QuickBooks that Mercury could have tagged on the way in.
• AR follow-up is a tab the bookkeeper means to get to. Invoices that should have been chased on day 7 get chased on day 45.
• Card provisioning is a Slack thread. New hire asks for a card, founder approves, ops adds a virtual card, limit is wrong, exception goes to finance, four touches for what should be one.
• Nobody on the leadership team can answer 'how much cash do we have, by entity, right now' without opening three browser tabs.

None of this is Mercury's fault. It is the predictable cost of treating banking software as banking, not as infrastructure. The companies that close the gap usually do it in one of two ways: they hire a finance ops person who knows how to wire APIs together, or they bring in a partner who has done it before.

Automation Plays We Build with Mercury

1. Treasury Auto-Sweep

Trigger: Mercury operating account balance crosses an agreed buffer (typically 90 days of burn). Workflow: an n8n job polls the Mercury API on a schedule, calculates the excess against the buffer, and initiates a transfer into the Treasury account holding the Morgan Stanley Ultra-Short or J.P. Morgan Money Market portfolio. A reverse rule sweeps cash back when the operating balance drops below a floor or AR aging spikes. Outcome: idle cash earns 3.21% to 3.66% depending on tier, with zero finance team intervention. On a $5M operating balance with $3M routinely idle, that lands between $90K and $110K of annual yield that was previously zero. Indicative, not promised.

The detail that matters: the sweep rule is owned by finance, not by code. We expose the buffer threshold and the portfolio split in a small admin view so the CFO can adjust them as rates and runway shift, without filing a ticket.

2. Closed-Deal to Paid-Invoice Loop

Trigger: a deal moves to Closed Won in HubSpot or Salesforce. Workflow: webhook fires into an automation that calls the Mercury invoicing API with deal value, line items, and contact email. Mercury issues the invoice, sends it, and emits webhooks on view, payment intent, and paid. Reminders go out on day 7, 14, and 30 if unpaid, escalation lands in Slack on day 45. Paid status flows back into the CRM as a deal property, and the AR receivable line updates in QuickBooks via the integration. Outcome: AR aging compresses, typically by 10 to 20 days. One client clawed back roughly 12 days of average days-sales-outstanding in the first quarter of running this.

3. Pre-Tagged Transactions into the GL

Trigger: Mercury webhook fires on every new transaction. Workflow: a rules engine matches vendor name, MCC code, and amount pattern against a library of company-specific tags (department, GL account, project, billable vs. overhead). Confident matches push straight into QuickBooks or NetSuite already coded. Low-confidence ones drop into a Slack channel with three quick-pick buttons for the finance lead to clear in seconds. The engine learns from each correction. Outcome: month-end close drops from a full week to two days, sometimes one. The number of transactions a human ever sees lands between 5% and 15% after a few months of training.

4. Live Cash Brief for the CEO

Trigger: 8am daily, or any transaction over a threshold (commonly $25K). Workflow: the automation pulls live balances across every Mercury account and entity, calculates 7-day and 30-day burn, runway at current burn, AR aged 30/60/90, treasury yield earned month-to-date, and any flagged transactions. The brief lands in a private Slack channel for the founder and CFO. Big transactions push an instant alert. Outcome: the CEO stops asking finance 'how much cash do we have' because the answer is already in their phone. Decision speed on hiring, marketing spend, and capital allocation noticeably improves, though that is the kind of gain that compounds quietly rather than showing up in a single chart.

These four plays compound. Treasury sweeps fund themselves once AR compresses. Pre-tagged transactions make the daily brief actually trustworthy. The brief makes the CFO confident enough to lift the Treasury buffer. Done in sequence, the first quarter usually pays for the build several times over.

How Mercury Should Integrate With Your Stack

• Accounting: two-way sync with QuickBooks, Xero, or NetSuite, with transactions arriving pre-tagged via your categorisation engine, not raw.
• CRM: HubSpot or Salesforce deals trigger Mercury invoices, and payment events update deal records and revenue dashboards in real time.
• HRIS: Rippling, Gusto, or Deel events provision Mercury virtual cards with the right policy on the new hire's start date, and offboard automatically on termination.
• Stripe and other PSPs: incoming revenue flows are reconciled against Mercury deposits so revenue recognition matches cash receipt without manual matching.
• Slack: spend approvals, AR escalations, and unusual transactions flow into channels the team actually reads, with action buttons that hit Mercury back via API.
• Notion or a custom dashboard: a single founder-facing view that consolidates Mercury balances, treasury yield, AR, and burn so the banking portal stops being where decisions happen.

What ROI Actually Looks Like

Numbers below are illustrative, not promised. They reflect what we typically see for $5M to $200M B2B companies that run the full set of Mercury plays for at least one quarter.

• Treasury yield on idle cash: usually lands between $40K and $200K per year on $2M to $10M of idle balances, net of management fees.
• Month-end close time: typically drops from 5 to 8 business days to 1 to 3, depending on entity count and the cleanliness of the chart of accounts.
• Days sales outstanding: usually compresses by 7 to 15 days once the dunning loop runs without human prompting.
• Finance team capacity reclaimed: usually 30% to 50% of one finance hire's week comes back, which often pushes a planned controller hire out by 6 to 12 months.
• Subscription waste caught: most companies find $2K to $8K per month of duplicate or zombie SaaS spend in the first sweep.

Where Teams Go Wrong

• Treating Mercury as a destination, not a source. The win is in piping Mercury data into the systems where decisions get made. If your CFO is still opening the Mercury tab to check balances, you have not finished the build.
• Setting up Treasury once and forgetting it. Yields shift with rate environments and your balance tier. If nobody is reviewing the portfolio mix quarterly, you are leaving basis points on the table.
• Building categorisation rules in QuickBooks instead of upstream. By the time a transaction lands in the GL it has already been touched, so corrections compound. Tag at the Mercury layer first.
• Issuing one shared card for the whole company because virtual cards 'feel like overkill'. A 60-person org running 4 cards has no spend governance. The win is granular per-person, per-vendor, per-budget cards with policy enforced at swipe time.
• Skipping webhooks. Polling the Mercury API every five minutes works for a while, then bills you in latency and missed events. The plays above only stay reliable when they are event-driven.

Where Moonira Comes In

We build Mercury as a programmable finance layer for B2B companies between $5M and $200M in revenue. Treasury auto-sweeps, closed-deal-to-invoice loops, pre-tagged GL pipes, HRIS-triggered card provisioning, and the founder dashboard that makes the banking portal optional. The result is a finance function that scales with revenue, not with finance hires.

If your Mercury account is still mostly a place to log in, the next conversation is worth having. We come in for a single scoping call, audit the gap between your current setup and the plays above, and come back with a fixed-scope build plan. No retainer trap, no eight-month implementation. Most engagements ship the first play in week one and the full set inside a quarter.