Want a downloadable PDF version of this post? Click here.

Introduction

Subscription revenue accounting can be complex. While Stripe revenue recognition provides comprehensive data, it is scattered across various sections of the application. This guide aims to streamline the process of accounting for revenue recognition and the order to cash cycle per ASC 606/GAAP and facilitate margin analysis. This guide also includes how to account for Connected Accounts.

Stripe maintains all of the necessary data to record revenue according to ASC 606 correctly, unlike some other billing/payment tools, but extracting these reports is the first step in the accounting process. See above for a summary of accounting that can be achieved from Stripe, compared to other common Billing and Payment systems used in the Subscription/SaaS industry.

Data Extraction

To compile all necessary data for accurate accounting, up to 4 reports need to be downloaded from Stripe (plus 1 additional for Connected Accounts):

1. Balance Transaction Report: Balances>All Activity
   • This report is the most foundational level of Stripe reporting but it only traces the cash side transactions, all the other reports are used to enrich the transactions in this report with the needed data to do rev rec correctly (subscription and billing data for Revenue Deferral, Unbilled AR, Billed AR entries, etc.)
2. Invoices Report: Billing > the Invoices page
   • This report tracks the invoicing from Stripe, which drives your Unbilled and Billed AR entries (and potential deferred revenue) and allows you to analyze payment applications and drive useful reporting. 
3. Payout Reconciliation Report: Balances > Payouts tab
   • This is the report that should tie out to your bank and let you break down what makes up that payout (charges, disputes, refunds, fees, etc.)
4. Cash/Payments Report: Transactions > Payments tab
   • This is used to enrich charge data on the Balance Transaction Report for useful reporting.
5. Application Fees Report (Connected Accounts only): Transactions > Filter for Application Fees
   • This is used to recognize Platform Earning/Application Fee revenue from Connected Account activity.

See below for a functional guide to how these reports and items within the reports relate to one another. 

Key Data Limitations to note:

1. Stripe does not separate the idea of a subscription or contract from invoicing. A Subscription in stripe is simply a billing schedule. As such, Stripe does not allow for complex billing arrangements where billing does not align with subscription terms. So manual workarounds are typically required to facilitate.
2. Manual revenue recognition and order to cash accounting of Stripe is possible, but time consuming - driven by data volume the amount of useful metadata you want to bring in for FP&A reporting. Typically this becomes untenable around $10m-15m ARR. 

Accounting - Journal Entries

Invoices Report

Key Note - while under ASC 606 invoices are not technically what drive the deferred revenue and revenue recognition entries (contracts) do - Stripe does not differentiate and as such is the best (but not correct) source of revenue recognition. For simple billing models - this works, for more complex we recommend discussing how HubiFi can help solve this. 

‍

Journal Entries:

• Revenue Deferral: Dr. Accounts Receivable (AR), Cr. Deferred Revenue 
• Revenue Recognition: Dr. Deferred Revenue, Cr. Revenue 
• Discount Deferral: Dr. Provision for Discount, Cr AR
• Contra-Revenue Recognition: Dr Contra-Revenue, Cr. Provision for Discount
• Sales Tax Accrual: Dr. AR, Cr. Sales Tax Liability

Steps:

1. Pull invoices to determine initial deferral and recognize revenue over time using start and end dates. (Note Stripe stores the start/end dates on the invoice line item level)
2. If volume is manageable, maintain each subscription/invoice line on a line in Excel to create a detailed waterfall report; otherwise, summarize entries to a summarized waterfall.
3. Discounts are presented on the invoice or invoice line item level. These would be treated as separate lines to drive provision for discount and amortization accounting. 
4. Split out the tax portion for the sales tax accrual. Use a VLOOKUP on the payment report (discussed next) for tax jurisdiction if separate Sales Tax Accrual Accounts are maintained.

Cash/Payments Report

Journal Entries:

• Customer Pays: Dr. Cash in Transit (Stripe), Cr. AR
• Payment Processor Fees: Dr. Payment Processor (PSP) Fees, Cr. Cash in Transit (Stripe)

Steps:

1. Use VLOOKUP to link invoice information for product-related fees and sales tax allocation.
2. Connect fees to payments using the Stripe Charge ID and link payments to invoices using the Invoice ID. Note the charge created date is the date that will be used to drive cash in transit entries. Available On date is when it will be released for payout. 

Payout Reconciliation Report

Journal Entries:

• Stripe Payouts: Dr. Cash - Bank, Cr. Cash in Transit (Stripe)

Steps:

1. Stripe settles in large batches and, as such, you will use the Balance Report to reconcile payments, involving VLOOKUP to the Payout Report for details on fees, refunds, and disputes.
2. Entries can be recorded in bulk or detailed for FP&A purposes by using this balance transaction detail enriched by the various reports above. 

Refunds, Disputes, and Credit Reports

Refunds

Journal Entries:

• Dr. AR, Cr. Cash in Transit (Stripe) 
• Dr. Revenue/Contra Revenue, Cr. Deferred Revenue
• Dr. Cash in Transit (Stripe), Cr. PSP Fees 

Steps:

1. VLOOKUP refunded payments and related invoices for proper revenue offset recording.

Disputes - Initiated/Lost

Journal Entries:

• Dr. AR, Cr. Cash in Transit (Stripe)
• Dr. Deferred Revenue, Cr. Revenue/Contra Revenue
• Dr. Cash in Transit (Stripe), Cr. PSP Fees

Steps:

1. VLOOKUP disputed payments and related invoices for accurate revenue offset recording.

Disputes - Won

Journal Entries:

• Dr. Cash in Transit (Stripe), Cr. AR
• Dr. Deferred Revenue, Cr. Revenue/Contra Revenue
• Dr. PSP Fees, Cr. Cash in Transit (Stripe)

Steps:

1. You will need to pull several past months for won disputes and VLOOKUP the payments accordingly to offset previous reversals, usually done in summary but necessary for detailed FP&A analysis.

Credit Report

Journal Entries:

• Credit Issuances (Proration IS NOT true): Dr. Deferred Revenue, Cr. Credit Payable
• Credit Applications (Proration = true): Dr. Credit Payable, Cr. AR

Steps:

1. VLOOKUP related invoice IDs to determine which deferred revenue or AR accounts to offset.

Application Fees Report

Journal Entries:

• Dr. Cash In Transit, Cr. Revenue

Steps:

1. Filter for Application fees and download report. This report is the fee revenue.

Note: This is not the cash received for these transactions (that is platform earnings on the balance transaction report).

‍

‍

Key Insights and Best Practices

Complex Billing Arrangements

Stripe stores the start and end dates for subscriptions on invoice line items. As such, fairly common arrangements where a customer pays for a subscription in advance and receives monthly service have to be completed manually. For ways to automate this accurately, I recommend reaching out to HubiFi as we solve this problem. 

‍

Revenue Completeness

The best identifier for revenue lines in Stripe is the invoice_line_items from invoices. To determine revenue segmentation, product is the best method. Each product_id should map to a revenue stream on the GL. Review monthly to ensure all product_ids are accounted for. Another check to complete is the Cash reconciliation. 

‍

Taxes

Stripe allows setup of various product_ids and is treated as invoice_line_items, including local and regulatory taxes. Ensure these are accounted for as tax rather than revenue streams.

‍

Credits

Credits can have their own product_ids. Ensure accurate identification and accounting.

‍

Connected Accounts

Organizations are liable for disputes and refunds in the Connected Accounts if that account does not maintain an appropriate amount. As such, a reserve should be held on the balance sheet when Connected Accounts are offered and steps should be taken operationally to minimize the risk.

‍

Subscription Upgrades and Downgrades

Stripe handles subscription changes by issuing an "unused time credit." Use this data to determine appropriate revenue and deferred revenue offsets. VLOOKUP unused time credits to the related invoice line item to find related revenue/deferred revenue to offset.

‍

Limitations of Stripe's Revenue Recognition Product

Stripe offers a native Revenue Recognition solution, but it is not designed for the rigor or complexity of a fast-growing, dynamic organization. What it provides in simplicity and accessibility often comes at the cost of flexibility, scalability, and compliance.

‍

Limited Data Model

Stripe’s underlying data model does not fully represent the complexities of the order-to-cash cycle, which limits its ability to handle real-world edge cases. The system was originally built to support a product-led growth (PLG) motion centered on self-serve sales. As a result, companies with more complex contracting, billing, or multi-entity arrangements struggle to apply ASC 606 principles accurately.

Finance and accounting teams often find themselves building manual workarounds - both in operations and in Stripe’s revenue reporting - to “fix” incomplete or inaccurate outputs.

‍

‍Gaps in ASC 606 and GAAP Compliance

Stripe Revenue Recognition is primarily a non-GAAP compliant revenue automation tool. While it produces roughly accurate results for simple use cases, it falls short when applying full U.S. GAAP standards. Key gaps appear in areas such as:

-Bad debt (ASC 326, formerly 840)

-Variable consideration (ASC 606)

-Fee and expense classification (ASC 740)

-Customer balance and liability reporting

For organizations preparing for audits, fundraising, or financial statements under scrutiny, Stripe’s compliance level is insufficient. It may serve small businesses needing directional accuracy but not those requiring defensible, audit-ready reporting.

‍

Limited Support for Multi-System Order-to-Cash Processes

Stripe’s revenue recognition engine only considers Stripe-native data. Most businesses, however, have diversified revenue streams - app stores, CRMs, contract databases, enterprise billing tools, or marketplaces. Without this upstream and adjacent data, Stripe cannot perform end-to-end revenue recognition or contract accounting. This makes it better suited to smaller, single-system environments without complex compliance needs.

‍

Scalability Challenges at High Volume

Although embedded within Stripe’s infrastructure, the revenue recognition module struggles to scale with the same high-volume demands Stripe Billing can support. At volumes of tens of thousands of invoices per month, users often encounter delayed invoice population, incomplete revenue calculations, and long processing or export times for journal entries and reports.

‍

Limited Financial and Operational Reporting

Stripe’s reporting capabilities meet the bare minimum for automated recognition, but lack the depth required for decision-making or audit support. Available outputs include journal entries, invoice-level accounting, and deferred revenue waterfalls—but these reports are static and lack operational granularity.They cannot fully support management reporting, nexus analysis, or business segmentation needs. In many cases, teams must manually adjust or supplement Stripe’s outputs to achieve usable operational or financial insights.

‍

Integrating Stripe with NetSuite

Common Pitfalls and Best Practices for Mid-Market Companies

Many mid-market companies rely on NetSuite as their ERP. However, because the integration between Stripe and NetSuite is limited, NetSuite often functions primarily as a general ledger rather than a full subledger. As a result, finance teams frequently rely on manual journal entries created from Stripe’s limited native reporting. While there are several approaches to automate entries from Stripe into NetSuite, each comes with significant trade-offs.

Common Integration Methods and Their Pitfalls

1. Stripe Sync (Legacy Integration)

Stripe offers a native sync tool that automatically transfers invoices, credit notes, and payments into NetSuite’s billing module in an attempt to mirror Stripe activity. However, this approach is problematic at scale:

-At high transaction volumes, it can overwhelm and slow down NetSuite.

-NetSuite charges for additional storage and concurrency, as well as on a per-transaction basis - making this method very costly.

-The synced data doesn’t address ASC 606 revenue recognition accurately, leaving teams to perform manual or incomplete calculations using NetSuite’s ARM module.

-Overall, the Stripe Sync integration tends to be expensive, unreliable at scale, and insufficient for GAAP compliance - making it the least effective option.

‍

2. Third-Party Sync Tools (e.g., Synder)

Tools like Synder attempt to replicate Stripe activity inside NetSuite by syncing invoices, credit notes, and payments into the billing module. However, the same limitations apply:

-NetSuite’s transaction-based pricing leads to high costs.

-Performance issues arise at scale, often resulting in breakage or sync failures.

-Revenue recognition remains manual or inaccurate, even with ARM.

-In short, although Synder and similar tools improve ease of setup, they share the same scalability, cost, and compliance issues as Stripe’s legacy sync.

‍

3. Stripe Data Pipeline and iPaaS Tools

Stripe’s Data Pipeline feature enables exporting data to a warehouse for analytics, which works well for high-level reporting - but not for accounting and compliance. Teams that try to transform this data into journal entries using ETL or iPaaS tools (such as Celigo, Alteryx, Boomi, or Workato) encounter several challenges:

-High ongoing costs and complex maintenance for handling edge cases.

-Elevated audit risk, since revenue-to-cash workflows are heavily scrutinized.

-While these tools may seem cost-effective if already in-house, the real cost emerges during audits and maintenance due to the lack of controlled and compliant data flows.

‍

Best Practice: Subledger-Based Integration

To reduce costs, complexity, and audit risk, the most effective approach is to post daily or monthly summary journal entries from Stripe into NetSuite’s general ledger while maintaining detailed transaction data in a dedicated revenue subledger, such as HubiFi.

HubiFi provides:

SOC 1 and SOC 2 Type II certification with built-in completeness and accuracy reporting, ensuring confidence in Stripe reconciliations.

Direct access to all Stripe metadata for granular, on-demand reporting without overengineering your NetSuite GL structure or segment mapping.

Reduced NetSuite transaction volume and simplified revenue accounting under ASC 606.

By decoupling the detailed transaction processing from NetSuite and retaining accuracy through a purpose-built subledger, you achieve a scalable, compliant, and auditable Stripe-to-NetSuite integration.

Conclusion

Accurately accounting for subscription revenue through Stripe requires a comprehensive approach to data extraction and journal entries and is highly manual. By following this guide, finance teams can ensure compliance with ASC 606/GAAP and achieve detailed margin analysis. Working closely with the team managing Stripe to maintain clean product_ids and a clean rev ops process will greatly facilitate the accounting.

Hubifi can significantly simplify this process by automating the data gathering, data cleaning, reconciliation, and eliminating the need for all the manual file creation entirely - automatically generating your journal entries and enrichment needed to analyze the data. Contact us to learn more about automating this process, or schedule a demo with your Stripe data to get started today.

This white paper is designed to serve as a practical guide for accounting professionals navigating subscription revenue accounting.