Why finance teams hate Stripe

Disclaimer: Orb is an alternative to Stripe Billing, and integrates with Stripe’s payments and invoicing products. Our perspective is shaped by many of the workflow challenges we’ve helped our customers overcome.

Developers absolutely love Stripe. It’s hard not to like well-typed SDKs, incredibly reliable APIs, and best-in-class developer experience around payments. 

However, Stripe fails to deliver a robust billing workflow for the finance team. It’s not a matter of a handful of missing features. Ranging from the infrastructure to the data model, Stripe is limited and rigid in what it offers outside of simple subscription seat-based billing. This creates significant revenue workflow challenges for growing companies.

Invoices fall apart

The finance team’s key end-user trust surface area is the invoice. When done right, every invoice should be clear and accurate. Every invoice should be interpretable and understandable on its own, containing enough context about the contract to avoid a billing dispute (and an upset customer). Stripe’s invoices fail to meet this standard, leading to either cumbersome workarounds, inaccuracies, or damaged customer trust.

Stripe’s invoice data model is limited in its expressibility and causes the finance team to lose structured reporting data. As a basic example, each invoice line item in Stripe is limited to an integer quantity. This makes sense when selling whole licenses but not when selling fractional gigabytes of storage. To work around this, users resort to using the line item description to describe the true quantity, sacrificing the clarity of the invoice and losing internal reporting accuracy in the process.

This problem repeatedly surfaces as more sophisticated models are rolled out: line-item level minimums, tiered pricing, or included quantity allocations are either entirely hidden on the invoice, not supported, or collapsed to the most basic line-item modeling. Because the semantic modeling of these features is lost on the invoice, finance teams are left to post-process invoices via custom queries and joining in external data to make sense of receivables.

In Stripe, invoices are also not generated until they need to be issued, creating a class of problems interacting with data about the current period. The current period invoice resource is perhaps the most important one in a usage-based business because it’s constantly changing. However, Stripe generates this dynamically when queried via the API. This means that draft invoices do not have a stable identifier and they cannot be filtered, queried in batch, or otherwise aggregated. This blocks finance analytics workflows and the ability to adjust these invoices at will.

No support for prepaid commitments

It’s rare that a single pricing mechanic is a headline pain point, but prepaid commitments and credits are becoming industry standard for several reasons:

• Upfront commitments provide pricing leverage and predictability, allowing vendors to provide larger discounts to enterprise customers
• Commits often simplify the discounting process, centering negotiation around a single discounted “cost basis” for the contract rather than changing individual rates for every SKU
• For smaller, pay-as-you-go customers, a prepaid balance with a top-up model is an effective way to fight fraud and limit credit risk

Whether it’s Perplexity and OpenAI in AI, Vercel in cloud infrastructure, or Alchemy in web3, prepaid models are the rule and not the exception. Unfortunately, Stripe lacks support for this entirely short of building it yourself – an expensive in-house investment.

For the finance team, this means that upfront commitments and negotiated rates are tracked in a spreadsheet (literally!) and the credit burndown done manually based on accrued monthly usage. Since prepayment must be factored into each monthly invoice, Stripe Billing’s invoice automation is no longer valuable; invoices must be generated by hand or with a cobbled-together homegrown script, removing Stripe as the single source of truth. This is merely the tip of the iceberg; the finance spreadsheet has to bear the burden of managing expiration dates, rollovers, and multiple types of credits.

Because this process involves manual work by finance, customers with prepayment lose visibility into their rate of burndown and remaining balance. The finance and accounting team often manages audit requests for billing data and becomes inundated with customer support requests, struggling to maintain an accurate ledger of changes. 

This points at an even larger accounting methodology problem lurking underneath – Stripe’s inability to support revenue recognition for usage-based models.

An outdated paradigm for revenue recognition

Stripe’s revenue recognition was built for subscription seat models, and now supports metered subscriptions. Metered subscriptions provide limited support for usage-based models, where an aggregate value is periodically reported to Stripe.

The basic principle of accrual-based revenue recognition is to recognize revenue when service is delivered (or more precisely: when you’ve fulfilled your performance obligation). For modern businesses, especially those with usage-based billing, this creates the issue that invoices may be issued well after or before usage actually takes place, but revenue must be recognized in real-time.

It’s no surprise that Stripe’s documentation on this topic mentions recognizing in-arrears usage revenue in a new ‘unbilled accounts receivable’ account. After all, the vendor has delivered service without it existing on any issued invoice so it remains unbilled.

Despite having basic support, Stripe’s revenue recognition functionality falls significantly short. Stripe’s revenue recognition inherits all the limitations of its billing system, showing up as large gaps that cannot be patched around:

• Just like in-arrears usage, prepaid credit utilization and expirations must be considered recognized revenue in the month that they happen despite being billed months in advance. Without the billing data model to support this, Stripe cannot recognize revenue for these prepaid models correctly – finance teams must merge different sources of data to handle this.
• Usage-based businesses often have contract clauses like per-SKU minimums or ‘included quantity’ allocations. Since engineering teams resort to workarounds to incorporate this functionality into Stripe Billing, these are completely absent in Stripe’s revenue recognition handling.

Pitfalls in Stripe’s revenue recognition feature set aren’t just a result of gaps in Stripe Billing. They’re also a result of differences in data architecture:

• Stripe’s metered billing doesn’t handle late event reporting and its event ingestion model forces aggregation outside of Stripe. As a result, it’s often the case that metered usage is reported in the incorrect billing period and therefore recognized improperly. Although this is tolerable once in a while, finance organizations at scale cannot tolerate this as a systematic error.
• Without the auditable, event-driven infrastructure to support amending usage from the past or backfilling data, finance teams are left to manually fix historical ledger entries in the case of misreported data.

Conclusion

For strategic finance teams navigating modern pricing models beyond simple subscription seats, a more adaptable billing platform is indispensable to ensure financial integrity and operational effectiveness.