%20A.png)
A signed contract and a first invoice live in different systems. The gap between them creates billing errors, wrong rev rec, and overpaid commissions.
Evelyn Ly
Head of Marketing
A 12-month contract lands in DocuSign. $48,000 ACV, custom pricing. 90-day free pilot. 20% discount if the customer prepays. Usage charges kick in after tier one. The AE gets the signed PDF. Finance gets a Slack message.
What happens next is where you start losing money.
Not because your Finance team is careless. Not because your AE forgot to loop someone in. But because the systems you use to close deals and the systems you use to bill customers don't actually talk to each other. The contract is a PDF. Your billing tool expects structured data. And the gap between those two things creates a failure cascade that touches invoicing, revenue recognition, commissions, and cash flow.
This isn't a theoretical problem. If you're running a fast growing company, it's happening to you right now. You just might not have quantified it yet.
Here's the deal: 12-month term, 90-day free pilot, 20% prepayment discount on months 4–12, usage pricing above 500 events/month at $0.08/unit, commission credited at signing.
Five terms. All completely standard. Your AE closes something like this three or four times a month.
The contract isn't exotic. The failure it causes in your billing infrastructure is.
Let's trace the exact path this contract takes through your stack. Not the happy path your process doc describes. The actual path.
The signed PDF lives in DocuSign. Stripe doesn't know it exists.
Finance gets a Slack message or email from the AE, manually reviews the contract, and creates the subscription in Stripe. Average lag: 3 to 7 business days post-signature. At $4,000 per month in ARR, that's $133 to $311 in delayed cash per deal.
Multiply by 40 deals per year and you have a cash flow problem, not a process annoyance. Here's the tension that actually matters: the contract start date and the Stripe subscription start date are almost never the same. From Day 1, your billing system and your contract disagree on when the relationship began.
The 90-day pilot is a line item in the PDF. It is not a data field in Stripe.
Whoever creates the subscription either adds a future start date (if they remember) or bills from Day 1 (if they don't). The customer gets invoiced during their free period. A dispute gets raised. Finance issues a credit.
Real cost: $4,000 credit plus two hours of back-and-forth plus customer trust erosion before they've even finished onboarding. And this happens quietly. Nobody tracks "invoices sent during pilot periods" as a metric, so it never shows up in a dashboard. It shows up in a frustrated email from a customer success manager.
The 20% prepayment discount is conditional. It applies only if the customer pays the annual invoice upfront, and it covers months 4 through 12. Not months 1 through 3 (the pilot).
In Stripe, discounts are either global coupon codes or one-time adjustments. There's no native concept of "conditional discount applied to a subset of a subscription period."
What actually happens: the discount gets applied globally (overbilling or underbilling), or it's forgotten entirely and the customer calls to complain three months in. The downstream effect is worse than the billing error itself. Your revenue recognition schedule is now wrong. If you're recognizing $48,000 over 12 months and your discount was misapplied, your deferred revenue waterfall is off from month one.
The usage tier lives in the contract. Your billing system knows about API events. These two facts exist in separate systems.
Someone manually configures the tier threshold in Stripe or Chargebee when setting up the subscription. If they get it wrong (wrong tier, wrong unit price, wrong included quantity) you either undercharge (silent revenue leak) or overcharge (customer dispute).
There's no audit trail connecting the billing configuration back to the signed contract language. When the customer disputes the charge, your Finance team reads a PDF and compares it line by line to an invoice. That's not a process. That's a workaround pretending to be a process. For companies with usage-based billing components, this failure compounds every single month.
The AE closes the deal. Commission is calculated at signing. Payroll processes it end of month.
The customer is in a 90-day pilot. They haven't paid a dollar. They might churn.
Commission clawback policies exist, but triggering them requires knowing the deal is non-revenue-generating. That requires Finance to cross-reference the commission run against the billing system against the contract terms. Manually. Common outcome: commission is paid, pilot churns at day 85, clawback is missed or disputed. Your comp plan says one thing. Your billing data says another. And nobody owns the reconciliation.
ASC 606 requires recognizing revenue when performance obligations are satisfied. If your Stripe subscription start date is Day 1 but the performance obligation begins at Day 91 (end of the pilot), the rev rec schedule is wrong from the start.
Your deferred revenue balance is overstated during the pilot period. Your recognized revenue is wrong. Your board deck is wrong. For a $3M to $10M ARR company trying to maintain clean books ahead of a Series B or an audit, this isn't a minor accounting footnote. It's a finding.
The six failures above aren't caused by careless people. They're caused by a structural assumption baked into every point-solution billing stack.
The contract is a document. Billing is a system. And documents don't talk to systems.
Your team isn't failing. Your data flow is.
Here's the honest version of how a contract moves through most $5M ARR SaaS companies:
Count the manual handoffs. Four to six, depending on deal complexity. Each one is a failure point. Each one introduces drift between what the contract says and what the billing system does. This is the billing stack tax that compounds silently every month.
At $1M ARR, one person handles contracts and billing. The gap is invisible because the same person manages both ends.
At $5M ARR, you have an AE team, a Finance hire, and a RevOps generalist. The gap is now an org boundary. The tools (DocuSign, Stripe, HubSpot) were each selected for their individual job. Nobody selected for the handoff between them.
And by the time you realize the handoff is the problem, you've already built process documentation, Zapier automations, and team habits around a broken architecture. Ripping it out feels expensive. Living with it feels manageable. Until it isn't.
One missed pilot period: $4,000 credit. Easy to absorb. Fifteen misapplied discounts over 12 months: $30,000 to $60,000 in revenue impact. Discovered at year-end audit.
Three wrong rev rec start dates: immaterial in isolation, material at scale, catastrophic before a fundraise. Finance leaders in the community cite 10% to 15% ARR leakage. But they discover it in retrospect, not in real time.
The numbers don't show up as a single line item. They show up as a pattern of credits, disputes, and reconciliation hours that nobody's aggregating. That's what makes the gap so durable. The cost is real, but it's distributed across enough incidents that no single one triggers a fix.
Stripe is excellent for simple subscriptions. It was not built for contract-driven B2B billing. It doesn't understand conditional discounts, pilot periods, or usage tiers that reference contract terms.
Maxio was built closer to this problem. But legacy architecture and implementation complexity put it in a different category. And Zuora? It costs $50K or more to implement and assumes a five-person RevOps team.
The gap between "outgrown Stripe" and "not ready for Zuora" is exactly where $3M to $10M ARR SaaS companies live. And it's where the contract-to-billing gap does the most damage.
Before you change any tool or process, run this audit. It takes 30 minutes and tells you whether your problem is structural.
1. Start date alignment. Pull your last 10 contracts. Do the contract start dates match the subscription start dates in your billing system? If not, how many days off?
2. Free period integrity. How many active subscriptions have pilot, trial, or onboarding periods in the contract terms? Are those periods reflected in billing, or did billing start immediately?
3. Discount accuracy. How many subscriptions have conditional discounts (prepay, volume, multi-year)? How was each discount implemented in your billing system? Is there documentation linking the billing config to the contract clause?
4. Usage tier configuration. For every usage-based subscription, who configured the tier thresholds in your billing system, and when? Is there a record connecting that configuration to the signed contract?
5. Commission vs. billing state. In your last commission run, how many paid commissions were on deals where no invoice had yet been paid?
If three or more of your answers reveal gaps, the problem is structural. It won't get fixed by hiring another analyst or adding another Zapier step.
Let's run the same $48,000 contract through a connected workflow.
The contract gets executed. Terms are parsed as structured data automatically. A subscription gets created with the correct start date, the 90-day pilot period flagged as non-billing, and the 20% prepayment discount encoded with its conditions (months 4 through 12 only, triggered by upfront payment).
The usage tier loads from the contract record: 500 events included, $0.08 per event above that, starting when the pilot ends. The first invoice generates on Day 91. It reflects only months 4 through 12 with the prepayment discount applied correctly. Usage charges calculate against the contracted tier every month.
The rev rec schedule builds from the contract terms. Not from invoice history. Not from a spreadsheet. Commission triggers on the first paid invoice, not the PDF signature date.
One contract. One source of truth. Every downstream system (billing, rev rec, commissions) reads from the same data. No Slack messages. No manual subscription creation. No drift. See how it works.
Billing and revenue automation that handles contracts, invoicing, revenue recognition, and commissions in one connected system. Book a demo to see how Measure works.
