Concept · stack · in production
Mercury as Runway Source of Truth
Mercury's read-only API provides a structured, daily feed of banking transactions, serving as the definitive source for Total Ventures' financial runway and spend analysis.
Integrating Mercury's read-only API directly into our internal tooling transforms raw banking data into a structured, auditable source of truth for financial operations, enabling automated runway projections and spend categorization across the Total Ventures portfolio.
What it is
Mercury provides a robust, read-only API that allows programmatic access to account balances, transaction histories, and statements. For a portfolio of products like Total Ventures, this means moving beyond manual bank statement reconciliation or relying on third-party aggregators that often introduce latency or data formatting inconsistencies. The core concept is to treat the bank's ledger as a primary, immutable data stream. Each transaction, whether an incoming payment or an outgoing expense, is represented as a structured data object. This includes details like amount, date, description, and the associated account. Critically, Mercury's API allows for per-account routing, which is essential for Total Ventures given our structure where individual portfolio companies might have distinct operating accounts under the main LLC. This capability ensures that financial data can be pulled and attributed precisely to the correct entity, facilitating clear separation of concerns and accurate reporting for each product.
Why it matters
The ability to programmatically access and process banking data fundamentally changes how a small team manages its finances. It eliminates the tedious, error-prone task of manually entering or categorizing transactions, which is a significant time sink for founders. Instead, we gain near real-time visibility into our cash position and burn rate across all portfolio entities. This granular, up-to-date financial picture is indispensable for accurate runway projections, a critical metric for any founder building in public. By automating the data ingestion, we can focus on analysis and strategic decision-making rather than data collection. Furthermore, it lays the groundwork for more sophisticated financial automation, such as automated expense categorization, flagging unusual transactions, and streamlining tax preparation by providing clean, structured data directly from the source. This shifts financial operations from reactive bookkeeping to proactive financial intelligence.
How TV applies it
At Total Ventures, Mercury serves as the definitive source for our operational finances. We run a daily cron job, `tv:refresh`, which queries the Mercury API for new transactions across all linked accounts. This script, part of our core backend services within our pnpm Workspaces monorepo, fetches transactions and ingests them directly into a dedicated Firebase Firestore collection. Each transaction is then processed by custom logic, written using Claude Code in a Monorepo, which attempts to categorize expenses based on keywords in the description, payee information, and transaction amount. For instance, payments to Vercel, Resend, or specific contractors are automatically tagged. This structured data feeds into an internal dashboard, providing a clear, aggregated view of our current runway, historical spend patterns, and projected burn rate. This granular visibility is crucial for managing the distinct financial profiles of products like PPH or F1, and for reconciling against revenue streams from platforms like Stripe Multi-Account. The daily refresh ensures that our financial reporting is always current, informing product development priorities and resource allocation decisions with factual, up-to-date data.
Common failure modes
While powerful, relying on an external API for financial data introduces specific challenges. API rate limits are a common hurdle; aggressive polling without proper backoff strategies can lead to temporary blocks or missed data. Transaction descriptions can sometimes be vague or inconsistent, making automated categorization challenging and requiring ongoing refinement of our parsing logic or occasional manual tagging. Account access issues, such as expired API tokens or changes in permissions, can interrupt the data flow, necessitating robust error handling and alerting. Another potential pitfall is over-reliance on automation without human oversight; anomalies or miscategorized transactions can skew financial projections if not periodically reviewed. Finally, if Mercury isn't the sole financial institution used (e.g., if credit cards or other payment processors are used outside of Mercury), the "source of truth" becomes fragmented, requiring additional integration points to achieve a complete financial picture.
FAQs
- How does this differ from using accounting software like QuickBooks or Xero?
- This approach focuses on raw data ingestion for internal analysis and custom dashboards, offering more granular control than off-the-shelf accounting software. It's a foundational layer that can feed into those systems, not replace them.
- What if Mercury isn't your only bank account?
- For a complete picture, all financial accounts (banks, credit cards, payment processors) need integration. Mercury serves as *a* source of truth for its accounts, but the principle extends to other financial APIs.
Want to see how Total Ventures applies this in production?
See the brand portfolio →
