At the end of the day, accountants see PSPs as just another source of revenue transaction data. Another place to go to pull down the reports they need to perform revenue recognition and all the preparation for month-end close (which they usually do all in Excel).
It’s become routine. It’s part of the job. It’s how you were taught to do it.
But it’s a pain. Payment service providers – their platforms and the data they make available – aren’t built for accountants, and it’s not much of a secret.
For accountants at subscription businesses, their routine is built around Stripe. Stripe is the go-to payment provider for subscription businesses (or at least among the most popular and relied upon).
Accountants are not the only users of Stripe data, but they are primary users who rely on Stripe every single month, sometimes daily.
Here are 3 main reasons (and a bunch of examples) that Stripe clearly isn’t built for accountants and their revenue reporting needs.
1. Stripe data isn’t easy for accountants to access and aggregate
Accountants generally don’t have the ability to pull Stripe data directly from Stripe’s API. That requires engineering resources. Instead, Accounting teams download reports that are available from Stripe’s dashboard. These reports are often scattered across different sections, making it cumbersome to gather all necessary data.
Here are some of the top reports accountants need to download separately from Stripe
- Payout Reconciliation Reports: These provide details on the funds paid out to the bank account.
- Subscription Reports: Detailed reports of all active, inactive, and trial subscriptions.
- Invoice Reports: Includes invoice data but often lacks context and additional details needed for complete revenue recognition.
- Balance Transaction Reports: To understand the flow of transactions and how they reconcile with payouts.
In addition to pulling several separate reports from Stripe, Accountants then need to take extra steps to connect the dots between disparate Stripe data, and between Stripe data and data from other third-party and internal finance and business systems.
Here are a few of those tedious, manual steps accountants take to connect the data dots
- Combining reports: Accountants often need to combine various reports to get a full picture. That includes various Stripe reports and also reports from other systems.
- Standardizing data: Aligning the format and structure of different data points is essential.
- Filling gaps: Identifying and retrieving missing details that are crucial for accurate accounting.
Watch out! Here are some specific Stripe data issues that can trip accountants up during the preparation process:
- Dunning and disputes: Disputed transactions and retries can complicate revenue recognition.
- Payout frequency: Different payout schedules can create mismatches between recorded revenue and actual cash flow.
- Data integrity: Inconsistencies and missing data points in Stripe can often require manual intervention.
- Changing data: Transaction statuses may change (e.g. from pending to paid), requiring continuous updates and monitoring.
- Timezone discrepancies: if aggregating data from Stripe and other systems, timestamps in different timezones can cause reconciliation issues.
Tips to help accountants make Stripe data more manageable
- Automate data extraction: Use tools like Leapfin to automate data extraction and transformation, including streamlining the flow of clean journal entry summaries into your ERP.
- Standardize formats: Create standardized templates for importing data into your accounting system.
- Daily downloads: Regularly download reports to track changes and updates in real-time.
- Custom programs: Implement custom scripts (see as: Excel actions, SQL queries, etc.) to automate common data cleaning tasks. Accountants have become pretty skilled at building programs into their workbooks, but if you need help, your engineering, data, or systems team may be able to assist.
2. Stripe data isn’t accounting-ready
Stripe’s transaction data is often incomplete for accounting purposes. It’s not built for immediate revenue reporting or to assist in the revenue recognition (rev rec) process. The good news is that all the data is there (i.e. engineering says you have what you need). The bad news is there’s a bunch of work to do before you can incorporate it into your GL.
Stripe transaction data can be incomplete
Stripe’s reports are essentially dumps of raw transactions, which are problematic because:
- Data changes over time: If you download an invoice report today, the same invoice may have a different status tomorrow. These changes have meaningful accounting impacts.
- Example: An invoice marked as "open" today could be "paid" tomorrow, affecting accounts receivable and revenue recognition.
- Data can be inconsistent: Invoices with multiple line items and discounts aren’t detailed enough in Stripe for proper allocation.
- Example: A discount applied at the invoice level needs to be proportionally re-allocated across all line items for accurate accounting.
Stripe data formats and types can be incompatible and hidden
While Stripe’s report formats are standardized, they’re not designed with Accounting teams' needs in mind. Accountants often have to deal with:
- Mismatched data types: Dates, currency, and text fields that aren’t properly formatted for accounting software.
- Hidden Data: Important details getting buried in metadata or requiring cross-referencing between multiple reports.
Stripe data and reports were built by developers for developers
Stripe data and reports are designed more for software developers and engineers who are pulling data into data warehouses, business intelligence tools, and other systems with similar data structure - but that’s not the same as tools focused on supporting accounting or revenue recognition which have unique and different requirements. Without an engineering background, the complexity of Stripe data and reports makes reconciliation hard, and often requires manual cross-referencing and adjustments.
Some other obvious signs that Stripe wasn’t built for accountants:
- Reports aren’t intuitive or user-friendly for accountants
- Stripe data doesn’t map to easily align with with ERP requirements
- Many stripe reports are large volume data dumps which can overwhelm ERP systems like NetSuite
3. Stripe isn’t built for ERPs like NetSuite
Accounting teams using NetSuite would like to take advantage of its advanced revenue recognition capabilities. Unfortunately, directly importing Stripe data into NetSuite will create two major challenges:
- It will clog NetSuite: Too much transaction data from Stripe will slow NetSuite down.
- It’s a data mapping nightmare: It requires an inordinate amount of custom fields which can increase lag time and add bloat across your system.
- It will increase NetSuite costs: NetSuite charges by API calls and data volume, leading to skyrocketing bills.
Conclusion
Stripe is a powerful tool for managing subscriptions and payments, but it falls short in meeting the specific needs of accountants. For efficient, accurate revenue recognition and month-end close, accountants need accounting-ready data.
Stripe is just the top example for subscription businesses. But other PSPs present equally frustrating challenges for Accounting teams:
- Adyen and Paypal have similar issues with incomplete and unstructured data
- Shopify often requires extensive data cleaning and formatting
- Apple Pay lacks unique identifiers and has non-transactional reports, making reconciliation a nightmare
- Google Pay has similar issues with non-standardized and fragmented data
Leapfin was born because of these PSP shortfalls. It’s the sidekick every accountant needs, automating tedious, manual tasks and transforming Stripe data into accounting-ready information and clean journal entries. By bridging the gap between Stripe and your ERP, Leapfin makes life easier for accountants, ensuring accurate financial reporting and enabling them to focus on more strategic, value-add projects.
If you think you're ready for accounting automation but you need to win over stakeholders, learn the steps to build a successful business case.
