
Balancing Accrual and Cash Dates in Your B2B SaaS Data Model
Oct 23, 2024
2 min read
2
16
0
If you’re managing contract data for a B2B SaaS business, one of the big questions is how to handle revenue in your data model. While small businesses might rely on simple cash accounting, larger B2B SaaS companies often need a more nuanced approach. This is where you have to juggle two key dates: accrual dates and cash dates.
Accrual Date: tells you when a service is delivered or a contract is signed. It follows the principle of recognizing revenue when it’s earned, regardless of when the payment comes in. For product analysts, this date is golden—it aligns perfectly with business performance, customer behavior, and product usage, offering insights into what's really happening within the product and the usage behind the contract.
Cash Date: tells you about when a payment actually hits the bank. This is crucial for the finance team, as it helps them understand the company’s liquidity, day-to-day cash flow, and ability to meet financial obligations.
Why You Need Both
Both dates matter, but they serve different teams. The finance team needs to roll things up by cash date to check progress against budget and understand cash health. Meanwhile, the product and sales teams focus on contract start and end dates. Sales teams use it to perform pipeline management, onboarding, and of course, that little thing call commission. While product teams use contract start and end dates to perform cohort analyses, estimate lifetime value (LTV), and forecast renewals.
So, how do you structure your data model to satisfy each team's needs? There’s no one-size-fits-all answer. It really comes down to your business needs, data volume, and performance considerations.
When to Use One Fact Table
You might opt for a single fact table that includes both dates, leaving it up to the end user to decide which one to use for reporting, if:
Your reporting needs aren’t overly complex, and you have an embedded analyst within the business teams who prefers the flexibility of one table.
Your end users are data-savvy and understand the differences between accrual and cash dates.
You need a simpler model that’s easier to maintain for basic analysis.
Your data volume is manageable, so performance isn't a big concern.
When to Go with Two Separate Fact Tables
On the other hand, you might choose two separate fact tables if:
You need to support complex financial analyses or comply with specific accounting rules.
Your end users just want the right numbers, without worrying about flexibility.
You’re dealing with large data volumes, making performance a priority.
You want clear separation between revenue recognition and cash receipt to ensure accurate calculations and data integrity.
The Real-World Call
Most businesses that require both accrual and cash calculations will likely need separate tables. While this setup demands more from the data modeler, it’s usually better for scalability. And truthfully, most stakeholders just want answers, not a deep dive into how the data sausage was made. Only a few technically curious users will want to peek behind the curtain.
Ultimately, the right approach is the one that meets your business goals and keeps both the finance, product, and sales teams happy!









