SaaS Revenue Audit Guide 2025: Stripe Reconciliation & Accuracy
Audit SaaS revenue from Stripe: reconcile MRR, verify subscription billing, and ensure accurate revenue recognition. Complete audit checklist.

Ben Callahan
Financial Operations Lead
Ben specializes in financial operations and reporting for subscription businesses, with deep expertise in revenue recognition and compliance.
Based on our analysis of hundreds of SaaS companies, revenue accuracy is the foundation of SaaS financial health, yet 40% of subscription businesses discover significant discrepancies when auditing their Stripe data against reported metrics. These discrepancies range from minor rounding differences to material misstatements affecting investor reporting, tax obligations, and strategic decision-making. A revenue audit isn't just for preparing for fundraising or acquisition—it's an essential operational practice that catches issues before they compound. Common problems include: MRR calculations that don't match invoice totals, recognized revenue that doesn't align with ASC 606 requirements, customer counts that include test accounts, and refund handling that creates phantom revenue. Companies that conduct quarterly revenue audits report 60% fewer financial restatements and significantly higher confidence in board reporting. This comprehensive guide provides a systematic approach to auditing SaaS revenue from Stripe, covering reconciliation procedures, common discrepancy sources, and preventive controls that maintain ongoing accuracy.
Understanding Revenue Audit Fundamentals
What Revenue Audits Verify
A comprehensive SaaS revenue audit verifies multiple dimensions of accuracy. Completeness ensures all revenue-generating transactions are captured—no invoices missing from totals. Accuracy confirms amounts are correct—proper currency handling, discount application, and tax exclusion. Timing verifies revenue is recorded in the correct period—particularly important for ASC 606 compliance. Classification ensures revenue is categorized correctly—new vs. expansion vs. reactivation, subscription vs. one-time. Consistency confirms that the same transactions produce the same metrics across different reports and systems. Each dimension can have independent issues; a complete audit examines all five.
Common Discrepancy Sources
Revenue discrepancies typically originate from several areas. Data extraction errors occur when API queries miss transactions due to pagination limits or filtering logic. Calculation differences arise from inconsistent metric definitions—does MRR include customers in trial? Does it annualize monthly contracts? Timing differences happen when systems use different cutoff times or timezones. Currency conversion introduces variance when exchange rates differ between systems. Test data contamination inflates metrics when sandbox or test transactions aren't properly filtered. Refund handling creates discrepancies when refunds aren't netted from the same period as original revenue. Understanding these sources helps target audit procedures effectively.
Audit Scope and Frequency
Audit scope should match risk and resource constraints. Full audits examining every transaction are resource-intensive but provide complete assurance—typically performed annually or before major events (fundraising, acquisition). Sampling audits verify random transaction subsets and aggregate totals—appropriate for quarterly reviews. Continuous monitoring automates ongoing accuracy checks for key metrics—essential for companies with significant transaction volumes. Most companies benefit from a layered approach: continuous monitoring catches obvious issues immediately, quarterly sampling audits verify aggregate accuracy, and annual full audits provide comprehensive assurance. The right frequency depends on transaction volume, growth rate, and stakeholder requirements.
Stakeholder Requirements
Different stakeholders need different audit outputs. Finance teams need reconciled totals for financial reporting and tax filings. Executives need confidence that board-reported metrics are accurate. Investors (in due diligence) need independent verification of claimed revenue. Auditors need documentation supporting financial statement assertions. Understanding who will use audit results shapes scope and documentation. Investor-facing audits require more rigorous documentation than internal quarterly reviews. External auditors may require specific procedures and evidence formats. Define stakeholder requirements upfront to ensure audit outputs meet needs.
Audit Timing
Schedule major revenue audits before you need them. Companies conducting their first comprehensive audit during fundraising due diligence often discover issues that delay or derail deals. Proactive auditing provides time to investigate and resolve discrepancies.
Stripe Data Extraction for Audit
Essential Data Objects
A comprehensive revenue audit requires data from multiple Stripe objects. Subscriptions provide the recurring relationship basis—plan, price, quantity, status, and timing. Invoices capture billing events—amounts, line items, discounts, and payment status. Charges record actual payment transactions—amounts received, fees, and settlement. Balance Transactions show money movement in your Stripe balance—the source of truth for cash flow. Refunds and Disputes track money returned. Customer objects link transactions to business relationships. Extracting all relevant objects and their relationships enables complete reconciliation.
Extraction Methods and Limitations
Stripe offers several data extraction approaches, each with tradeoffs. The API provides real-time access but requires pagination handling for large datasets—missing pagination logic is a common source of incomplete data. Stripe Sigma enables SQL queries but has data freshness delays. Data Pipeline exports complete datasets but requires warehouse infrastructure. Dashboard exports work for small datasets but have size limits and limited field selection. For audit purposes, API extraction with explicit pagination verification or Data Pipeline exports typically provide the most reliable complete datasets. Whichever method you use, verify row counts against Stripe Dashboard totals to confirm completeness.
Data Completeness Verification
Before auditing data accuracy, verify data completeness. Compare extracted record counts to Stripe Dashboard totals—do you have the same number of subscriptions, invoices, and customers? Check for missing time periods—any gaps in transaction dates? Verify all object types are present—do you have both paid and unpaid invoices? Check relationship integrity—can every charge be linked to an invoice and customer? Data completeness issues are easier to detect and fix than accuracy issues; resolve completeness first. A common trap: extracting "active" subscriptions misses churned subscriptions that contributed revenue earlier in the period.
Handling Test and Sandbox Data
Test mode transactions must be excluded from production audits—obvious but frequently missed. Verify your extraction filters for live mode only (livemode: true in API responses). Beyond test mode, check for test accounts within live mode: demo accounts, employee testing, and QA scenarios that generate real transactions but shouldn't count as revenue. Common indicators of test accounts: recognizable test email domains, unusually round numbers, transactions that are immediately refunded. Establish and document criteria for identifying test transactions, and apply consistently across audit periods.
Data Extraction Reality
Companies auditing for the first time frequently discover their analytics systems have been using incomplete data—pagination errors alone can cause 10-20% undercounting of transactions. Always verify extraction completeness before trusting analytical results.
MRR Reconciliation Procedures
Defining MRR Consistently
Before reconciling MRR, document your definition precisely. What's included: active subscriptions, trials converting this period, customers in dunning? What's excluded: one-time charges, usage overages, non-recurring fees? How are annual contracts handled: spread monthly or counted fully in start month? How are mid-month changes handled: prorated or effective next period? Different definitions are legitimately valid, but the definition must be consistent across time periods and reporting systems. Document your MRR definition and verify that all systems calculating MRR use the same logic.
Bottom-Up MRR Calculation
Calculate MRR from raw subscription data to create an independent baseline. For each active subscription on the period end date, calculate monthly value: annual plans divided by 12, quarterly divided by 3, monthly as-is. Handle quantities and per-seat pricing. Apply any active discounts. Exclude non-recurring components. Sum all subscription values for total MRR. This bottom-up calculation provides a benchmark to compare against reported MRR. Discrepancies indicate either calculation logic differences or data completeness issues. Common sources of variance: treatment of trials, handling of subscriptions created and cancelled within the period, and proration calculations.
MRR Movement Analysis
Beyond point-in-time MRR, reconcile MRR movements: new, expansion, contraction, churn, and reactivation components. Starting MRR plus movements should equal ending MRR—if not, something is miscategorized or missing. Common issues: upgrades counting as both churn and new instead of expansion, reactivations classified as new customers, and contraction from downgrades not captured. Movement reconciliation is more complex than point-in-time but catches categorization errors that affect growth analysis. A company might have accurate total MRR but misleading component breakdown—problematic for understanding growth dynamics.
Currency and Multi-Entity Handling
Multi-currency and multi-entity structures add reconciliation complexity. For multi-currency: document the exchange rate source and timing used for MRR conversion. Rates at transaction time vs. period-end produce different results; either is valid but must be consistent. For multi-entity: determine whether MRR consolidates across entities or reports separately. Intercompany transactions need elimination in consolidated views. These complexities often cause reconciliation difficulties; explicitly documenting your approach prevents confusion and ensures consistent treatment across periods.
MRR Definition Impact
Two equally valid MRR definitions for the same company can differ by 5-15% based solely on treatment of trials, annual contract spreading, and inclusion/exclusion choices. Document your definition; don't assume others calculate MRR the same way.
Cash-to-Revenue Reconciliation
Stripe Balance Transaction Analysis
Balance Transactions are Stripe's source of truth for money movement. Every charge, refund, fee, and payout creates a Balance Transaction. For audit purposes, sum Balance Transactions by type for the audit period: charges (gross receipts), refunds (returned amounts), fees (Stripe's cut), and transfers/payouts (money leaving Stripe to your bank). Net Balance Transactions should reconcile to bank deposits. Start your reconciliation here—if Balance Transactions don't match bank deposits, investigate before proceeding. Common issues: timing differences from payouts in transit, currency conversion fees, and disputes/chargebacks.
Gross Revenue to Net Revenue Bridge
Build a bridge from gross charges to net revenue: Gross Charges minus Refunds minus Discounts (if captured as separate line items) minus Taxes Collected equals Net Revenue. Each step should reconcile to Stripe data sources. Gross charges come from Charge objects. Refunds come from Refund objects linked to original charges. Discounts may be applied at invoice level or as coupon redemptions. Taxes collected should be excluded from revenue and tracked separately. Building this bridge systematically identifies where discrepancies originate rather than just flagging that totals don't match.
Timing Differences Analysis
Revenue recognition timing differs from cash receipt timing, creating legitimate reconciliation differences. Prepaid annual contracts: cash received in month 1, revenue recognized over 12 months. Failed payment retries: invoice dated in month 1, payment received in month 2. Prorations: partial month revenue recognized, but full payment may be collected later. Document expected timing differences between cash and revenue. Large unexplained timing differences warrant investigation—they may indicate recognition errors or unusual transactions requiring review. Build a timing difference schedule that explains variance between cash receipts and recognized revenue.
Fee Reconciliation
Stripe fees reduce cash received but shouldn't reduce revenue. Verify that Stripe fees are properly excluded from revenue calculations and correctly categorized as expense. Fee reconciliation: sum of fees in Balance Transactions should match the expense recorded for Stripe fees. Common issues: volume discounts or negotiated rates not reflected in calculations, currency conversion fees not separately tracked, and dispute fees recorded inconsistently. Fee reconciliation is a secondary audit step but catches issues affecting expense categorization and cash flow analysis.
Bank Reconciliation First
Start revenue audits by reconciling Stripe payouts to bank deposits. If these don't match, you have data extraction or basic calculation issues that will cascade through all other reconciliation. Get this baseline right first.
ASC 606 Revenue Recognition Audit
Performance Obligation Identification
ASC 606 requires identifying distinct performance obligations in each contract. For SaaS, this typically means: software access as a stand-ready service obligation (satisfied over time), implementation services (if separately priced and distinct), and support services (if separately promised). Audit that revenue is recognized consistent with performance obligation completion. Common issues: bundled contracts not properly separated, implementation revenue recognized upfront instead of over service period, and professional services with unclear performance obligations. Document performance obligation analysis for each significant contract type.
Recognition Timing Verification
For subscription software, revenue typically recognizes ratably over the service period. Verify recognition calculations: annual contracts should recognize 1/12 per month, multi-year contracts should recognize over the full term, and month-to-month contracts recognize as service is delivered. Audit samples of different contract types to verify correct recognition. Watch for: annual contracts recognized immediately (incorrect), contracts starting mid-month with incorrect partial-month calculations, and early terminations where recognition continued past cancellation. Recognition errors often compound over time; early detection prevents larger corrections later.
Deferred Revenue Reconciliation
Deferred revenue represents payment received for services not yet delivered. For SaaS, this is typically prepaid subscriptions where cash has been collected but recognition is spread over future periods. Reconcile deferred revenue: beginning balance plus cash collected minus revenue recognized equals ending balance. Verify deferred revenue is complete—every active prepaid subscription should have associated deferred revenue. Common issues: invoices paid but not reflected in deferred revenue, recognized revenue not reducing deferred balance, and currency differences between invoice and deferred revenue amounts.
Contract Modification Handling
Subscription changes (upgrades, downgrades, renewals) create contract modifications under ASC 606. Audit that modifications are treated consistently: does an upgrade create a new contract or modify the existing one? How is remaining deferred revenue from the old arrangement handled? Are prorated amounts calculated correctly? Contract modifications are a common source of recognition complexity and error. Sample significant modifications and trace through their recognition treatment. Document the policy for handling modifications and verify consistent application.
ASC 606 Materiality
For early-stage companies, ASC 606 complexity may exceed practical benefit. However, companies approaching fundraising or acquisition will face increased scrutiny on recognition practices. Establish proper treatment early to avoid retroactive corrections later.
Implementing Audit Controls
Automated Reconciliation
Implement automated checks that run continuously rather than waiting for periodic audits. Daily: verify MRR calculation matches subscription data, check for unusual transactions (large amounts, unusual products), and confirm bank reconciliation. Weekly: reconcile customer counts across systems, verify churn and expansion categorization, and check for stuck or failed transactions. Monthly: full MRR movement reconciliation, deferred revenue balance verification, and cohort-level sanity checks. Automated reconciliation catches issues when they're small and easier to investigate—a single problematic transaction is easier to trace than investigating aggregate discrepancies months later.
Change Control Procedures
Many revenue discrepancies originate from configuration changes. Implement controls around: pricing changes (verify propagation to all systems), product catalog updates (ensure consistent across platforms), discount and coupon creation (document terms and application rules), and calculation logic updates (version control and testing before deployment). Change control doesn't mean preventing changes—it means ensuring changes are documented, tested, and applied consistently. Common issue: a developer updates MRR calculation logic without updating the documented definition, creating hidden discrepancy.
Segregation of Responsibilities
Separate transaction recording from reconciliation responsibilities. The person entering invoice adjustments shouldn't also be the one verifying invoice accuracy. This basic control prevents both errors and fraud. For small teams where strict segregation is impractical, implement compensating controls: detailed transaction logging, required approval for adjustments above thresholds, and third-party reconciliation tools. The goal is ensuring that no single person can create and conceal discrepancies—someone independent should verify transaction accuracy.
QuantLedger Automated Auditing
QuantLedger provides automated revenue reconciliation that eliminates manual audit procedures for most checks. Continuous monitoring compares MRR calculations to Stripe data, alerting on discrepancies immediately rather than waiting for periodic audits. Cash-to-revenue reconciliation runs automatically, flagging timing differences and unexplained variances. Recognition accuracy verification ensures ASC 606 compliance without manual spreadsheet tracking. Audit trail documentation provides evidence for external auditor review. For companies without dedicated finance operations staff, QuantLedger provides audit-grade accuracy verification without the manual effort.
Control ROI
Companies implementing automated revenue reconciliation report 80% reduction in manual audit effort and 90% faster detection of discrepancies. The cost of control implementation is typically recovered within the first audit cycle through time savings and earlier issue detection.
Frequently Asked Questions
How often should I audit SaaS revenue from Stripe?
Audit frequency should match your risk tolerance and transaction volume. At minimum, conduct a thorough revenue audit annually—before year-end close, before fundraising, or before any major transaction. Quarterly sampling audits catch issues before they compound; these don't need to examine every transaction but should verify aggregate totals and reconcile key metrics. High-growth companies or those with complex pricing should consider monthly abbreviated audits. Implement continuous automated monitoring for key metrics regardless of formal audit frequency—catching discrepancies in real-time is always better than discovering them during periodic reviews. The right frequency balances thoroughness against resource constraints.
What should I do when I find a revenue discrepancy?
First, isolate and quantify the discrepancy: what time period, what transactions, and what dollar amount? Then trace the source: is it a data extraction issue (missing transactions), calculation difference (definition variance), timing difference (legitimate recognition differences), or genuine error? Once you understand the source, determine materiality: does this affect financial reporting, investor communication, or tax filings? For material discrepancies, document thoroughly and determine if correction is required. Implement controls to prevent recurrence. Many discrepancies turn out to be definition differences rather than errors—two systems calculating MRR differently but both correctly per their definitions. In such cases, standardize definitions going forward rather than treating past data as incorrect.
How do I reconcile MRR when we have annual contracts?
Annual contract handling is a common source of MRR confusion. The industry-standard approach: divide annual contract value by 12 and include this monthly amount in MRR. An annual contract for $12,000 contributes $1,000 MRR. This represents the monthly recurring value of the relationship. Alternative approach: some companies exclude annual contracts from MRR and report separately. Either approach is valid but must be documented and applied consistently. Reconciliation challenge: ensure all systems use the same treatment. Common discrepancy: billing system shows $12,000 invoice in month 1 while analytics shows $1,000 MRR for 12 months. These are both correct representations of the same transaction from different perspectives. Build a clear bridge between billing (cash) and MRR (normalized monthly value) views.
What documentation do external auditors need for revenue audit?
External auditors typically require: revenue recognition policy documentation (how you apply ASC 606 or your accounting framework), evidence of internal controls over revenue (who does what, what approvals exist), sample transaction testing (they'll select transactions and request full documentation), reconciliations you've prepared (MRR, deferred revenue, cash-to-revenue bridges), and system documentation (how data flows from Stripe to financial statements). Prepare this documentation before auditors arrive—scrambling during the audit delays the process and raises concerns. Auditors also appreciate clean, well-organized data exports and clear explanations of your business model. A well-prepared audit package demonstrates control maturity and typically results in faster, less expensive audit engagements.
How do I handle refunds in revenue audits?
Refund handling depends on your accounting approach and refund timing. If the refund occurs in the same period as the original charge, net the refund against revenue for that period—you never really had that revenue. If the refund occurs in a subsequent period, you have options: reverse the original revenue (more accurate but requires restating prior periods) or record the refund as contra-revenue in the refund period (simpler but less accurate). Document your policy and apply consistently. For audit purposes, verify that refunds are properly tracked and reduce revenue appropriately. Common issues: refunds recorded but original revenue not reduced, refunds double-counted in both periods, and partial refunds not proportionally reducing revenue. Build a refund reconciliation showing all refunds by period and their revenue impact.
Can I audit Stripe revenue without engineering help?
Basic revenue audits are possible without engineering, though capabilities are limited. Stripe Dashboard provides summary reports exportable to spreadsheet—sufficient for small transaction volumes. Stripe Sigma enables SQL queries without API integration—useful if you have SQL skills. Manual reconciliation comparing Dashboard totals to your reporting is possible but tedious. However, comprehensive audits of significant transaction volumes really benefit from engineering support: API extraction with proper pagination, data transformation and validation, automated reconciliation logic, and integration with your financial systems. Alternatively, platforms like QuantLedger provide audit-ready data extraction and reconciliation without requiring engineering resources, making comprehensive audits accessible to finance teams without technical dependencies.
Key Takeaways
Revenue auditing transforms from a dreaded annual exercise into an ongoing accuracy assurance practice when approached systematically. By understanding common discrepancy sources, implementing proper data extraction, and following structured reconciliation procedures, subscription businesses can maintain confidence in their reported metrics throughout the year rather than discovering problems during high-stakes events. The key audit components—MRR reconciliation, cash-to-revenue bridging, and ASC 606 compliance verification—each serve distinct purposes and catch different types of issues. Skipping any component leaves blind spots that may harbor significant discrepancies. Beyond periodic audits, implementing automated controls and continuous monitoring prevents issues from occurring and catches them quickly when they do. The investment in audit infrastructure pays dividends through: higher confidence in decision-making metrics, faster external audits with fewer surprises, and reduced risk of embarrassing corrections to investor or board reporting. Whether you build internal audit capabilities or leverage platforms like QuantLedger that automate reconciliation, the goal remains consistent: maintaining accurate revenue data that supports confident business decisions.
Automate Revenue Reconciliation
QuantLedger continuously audits your Stripe data—catch discrepancies early
Related Articles

Stripe Revenue Tracking 2025: MRR, ARR & Revenue Movements
Track revenue in Stripe: monitor MRR, ARR, new revenue, expansion, and churn. Build real-time revenue dashboards for SaaS metrics.

Revenue Recognition Audit Prep 2025: SaaS Checklist
Prepare for revenue recognition audits: ASC 606 documentation, contract samples, and recognition schedules. Pass audits with minimal findings.

SaaS Revenue Forecasting Guide 2025: Predict MRR Growth
Forecast SaaS revenue from Stripe: build MRR projections, model growth scenarios, and create investor-ready ARR forecasts. Data-driven predictions.