Revenue Verification for SaaS Lenders

Revenue-based financing for SaaS companies is a $15B+ market growing 30% annually, and its underwriting infrastructure is stuck in 2015. Most SaaS lenders still verify revenue using bank statements — a data source that lags by 30+ days, conflates recurring and non-recurring income, and requires manual interpretation by an analyst who may or may not understand SaaS billing mechanics. Meanwhile, the actual source of truth — the billing system — sits untouched, producing real-time, transaction-level revenue data that no one is reading.

The lender's verification problem

SaaS lending depends on a single premise: the borrower has predictable recurring revenue that can service the debt. Verifying that premise is the entire underwriting challenge. And unlike traditional business lending, where revenue verification maps cleanly to financial statements and tax returns, SaaS revenue verification is structurally harder because MRR is not a GAAP concept.

There is no authoritative standard for how to compute MRR. Ask ten SaaS companies and you'll get ten definitions: some include annual prepayments, some don't; some normalize discounted contracts, some count them at face value; some include usage-based components, some exclude them. A lender who accepts a borrower's self-reported MRR is accepting a number computed by a methodology they haven't audited, using definitions they haven't agreed on.

The magnitude of the problem is quantifiable. Across SaaS companies that connect their billing systems, self-reported MRR diverges from billing-verified MRR by a median of 8–15%. The skew is consistently upward — companies overstate, not understate. For a lender sizing a facility as a multiple of MRR, that gap translates directly into credit exposure. A $5M facility sized on $1M self-reported MRR when true MRR is $870K is a facility that is 15% oversized from closing.

Why bank statements aren't enough

Bank statements are the default verification tool for SaaS lenders because they're familiar, universally available, and hard to fabricate. But familiar doesn't mean fit for purpose. Bank statements have four structural limitations that make them unreliable for SaaS revenue verification.

Timing lag — statements reflect the past, not the present

Bank statements close monthly or weekly. The most current statement available is typically 15–30 days old. For a SaaS company experiencing rapid growth or contraction, that lag is material. A borrower who lost 15% of MRR in the last three weeks looks healthy on last month's bank statement. A lender who advances against that statement is advancing against revenue that no longer exists.

Recurring vs non-recurring — deposits don't self-categorize

A bank deposit doesn't carry metadata about whether it's recurring. A $50K deposit could be 50 monthly subscriptions at $1K each (highly recurring) or a single annual prepayment (partially recurring) or a professional services engagement (non-recurring). Stripe processes all three as charges. The bank statement reports all three as deposits. Only the billing system knows which is which.

The classification matters because lenders advance against recurring revenue, not total revenue. A company with $200K in monthly bank deposits might have $160K of recurring subscription revenue and $40K of one-time setup fees and services. A lender who advances 5x against $200K instead of $160K has $200K of excess exposure from day one.

Refunds, disputes, and chargebacks are invisible or delayed

A customer dispute on a $5K charge appears on the bank statement as a debit 30–90 days after the original charge. A refund might net against a future deposit batch rather than appearing as a distinct line item. Failed payment retries create phantom revenue — the first attempt deposits, the reversal nets out days later, and the bank statement shows both as separate events.

In the billing system, all of these events are linked to the original subscription. A refund on invoice #12345 is traceable to customer X's subscription, which shows as active or cancelled. The billing system state is unambiguous. The bank statement state requires interpretation.

Multi-gateway and multi-currency complexity

SaaS companies processing international payments may use multiple payment gateways or receive deposits in multiple currencies. Each gateway settles to the bank on its own schedule, in its own batch format, with its own netting rules. A lender reconciling three bank accounts across two currencies to reconstruct MRR is doing manual work that the billing system already does automatically.

Billing-system verification for underwriting

Billing-system verification reconstructs the borrower's revenue metrics directly from the payment processor — Stripe in most cases for SaaS companies below $100M ARR. Instead of asking the borrower "what is your MRR?" and checking their answer against bank deposits, the lender computes MRR independently from the same billing objects that generate those deposits.

What billing verification produces that bank statements can't

Decomposed MRR. Total MRR broken into new, expansion, reactivation, contraction, and churned components. A lender can see not just the total but the quality of the revenue: is the borrower growing from new business (sustainable) or from expansion of existing accounts (concentrated)? Is churn accelerating under the hood?

Net revenue retention. The percentage of revenue retained from the same customers period-over-period, including expansion and contraction. NRR above 100% means the customer base grows on its own. Below 100% means the borrower must acquire new customers just to maintain revenue. For a lender, NRR below 90% is a structural risk factor that no bank statement reveals.

Customer concentration. What percentage of MRR comes from the top 10 customers? A borrower with 40% concentration in three accounts is one contract loss away from a covenant breach. Bank statements show deposits, not customer-level revenue attribution.

Involuntary churn rate.Failed payments that exceed the retry window represent revenue lost to billing infrastructure, not product problems. High involuntary churn (above 3% monthly) signals a mechanical issue that inflates the lender's credit risk unnecessarily. It's also the most fixable form of churn — modern dunning tools recover 30–50% of failed payments when implemented correctly.

How verification changes the underwriting timeline

Traditional SaaS underwriting takes 2–4 weeks. The bottleneck is data collection: requesting bank statements, reconciling deposits to reported revenue, asking clarifying questions, waiting for responses. Billing-system verification compresses this to hours. Connect the Stripe account. Compute the metrics. Compare to the borrower's claims. The delta between self-reported and verified is itself a risk signal — a borrower whose self-reported MRR exceeds billing-verified MRR by 20% is either confused about their own metrics or inflating them intentionally.

Speed matters in competitive lending markets. A borrower evaluating three RBF offers will sign with the lender who can provide a term sheet fastest — assuming similar terms. The lender with billing-system verification can issue a provisional term sheet in 48 hours. The lender waiting for bank statement reconciliation is still in the data collection phase.

Ongoing covenant monitoring

Underwriting is a point-in-time decision. Covenant monitoring is continuous. Most SaaS lending facilities include revenue-based covenants: minimum MRR thresholds, maximum churn rates, minimum growth rate requirements. Monitoring compliance with these covenants determines whether the facility remains in good standing, triggers margin calls, or enters default.

With bank statement-based monitoring, covenant compliance is checked monthly at best. The lender receives the statement, an analyst reconciles the deposits, computes an approximate MRR figure, and compares it to the covenant threshold. If the borrower breached the covenant three weeks ago, the lender learns about it four weeks later. That's seven weeks of compounding risk between the breach and the response.

Billing-system monitoring checks covenants daily. If MRR drops below the covenant threshold on Tuesday, the lender's system flags it Wednesday. If the churn rate covenant is breached, the alert is immediate. The lender can initiate a conversation with the borrower while the problem is still small — not after it has metastasized into a 15% revenue decline.

Continuous monitoring also enables smarter covenant structures. Instead of binary thresholds ("MRR must not fall below $X"), lenders can set trend-based covenants: "trailing 3-month MRR growth rate must be non-negative" or "NRR must exceed 95% on a rolling 90-day basis." These are more predictive of credit risk than absolute thresholds and less likely to trigger on temporary noise. But they're only enforceable with real-time billing data — no bank statement supports a rolling 90-day NRR calculation.

The revenue verification workflow

A billing-system verification workflow for SaaS lenders has five stages. Each stage produces a specific output that feeds the underwriting decision and, post-funding, the ongoing monitoring infrastructure.

Stage 1: Connect.The borrower provides a read-only restricted API key from Stripe. The key grants access to subscription, invoice, and charge data. It does not grant write access — the lender cannot modify the borrower's billing. Setup takes under 5 minutes and requires no engineering work from the borrower.

Stage 2: Compute.Raw billing data is normalized to produce billing-verified MRR. Annual subscriptions are divided by 12. Quarterly subscriptions are divided by 3. Multi-currency subscriptions are converted at consistent FX rates. Trials, paused subscriptions, and past-due accounts beyond a grace period are excluded. The output is a clean MRR figure that is independent of the borrower's internal reporting methodology.

Stage 3: Decompose. Total MRR is broken into its movement components. The lender sees how much new revenue was added, how much expansion occurred from existing customers, and how much was lost to voluntary churn, involuntary churn (failed payments), and contraction (downgrades). This decomposition reveals the quality and sustainability of the revenue, not just its magnitude.

Stage 4: Verify.The billing-verified figures are compared to the borrower's self-reported numbers. The size and direction of the delta are both signals. A 5% overstatement might reflect an honest definitional difference (the borrower includes annual prepayments, the verified figure normalizes them). A 20% overstatement requires investigation. A consistent upward bias across multiple metrics suggests systemic overstatement.

Stage 5: Monitor.Post-funding, the billing connection remains active. Covenant compliance is checked daily against the facility terms. Alerts trigger when metrics cross warning thresholds (approaching covenant breach) or hard thresholds (covenant breach). The lender has a continuous, automated view of the borrower's revenue health — not a monthly snapshot reconstructed from bank deposits.

How North Metric supports the lending workflow

North Metric connects directly to a borrower's Stripe account and computes every SaaS metric from the billing data: MRR (decomposed into new, expansion, contraction, and churn), NRR, GRR, customer count, churn by type, concentration analysis, and 25+ additional metrics. Every metric uses the same definition regardless of the borrower's internal reporting choices. The output is borrower-independent, auditable, and refreshed daily.

For underwriting, the platform produces the verification delta — the quantified gap between what the borrower reports and what the billing system shows. That delta, combined with the MRR decomposition and retention trends, gives the credit team the data they need to size a facility accurately and set covenant thresholds that reflect the borrower's actual revenue quality, not their self-assessed version of it.

For ongoing monitoring, the same billing connection that powers underwriting powers daily covenant checks. If MRR drops, churn spikes, or NRR deteriorates, the lender sees it the next day. The shift from monthly manual reconciliation to daily automated monitoring doesn't just save analyst time — it changes the lender's risk profile by compressing the detection-to-response window from weeks to days.