Diagnosing Invoice-to-Paid State Constraints in a Legacy Billing System

Entity Clarification

This analysis separates three layers:

• Accounts: unique registered users
• Invoices: billing entities created after explicit Pay click
• Retry behavior: inferred from accounts generating more than one invoice

A single account could generate multiple invoices.

Provider-level card authorization attempts were not directly observable in this dataset.

1. Why the Payment Layer Became the Focus

After funnel compression (14 -> 6 steps), users were:

• registering
• selecting licenses
• clicking Pay
• generating invoices

Important clarification:

In self-service, an invoice is created at the exact moment the user clicks Pay.

Invoice creation therefore represents confirmed purchase intent.

At this stage, three demand-side hypotheses were already deprioritized:

• traffic quality
• pricing rejection
• lack of intent

The remaining question was:

Why do users create invoices but fail to transition into a paid state?

The payment layer became the primary diagnostic surface.

2. Aggregate Invoice-to-Paid Pattern

Across the observation period:

• 307 invoices were created after explicit payment intent (Pay click)
• 27 invoices had Amount > 0
• 259 invoices remained in ordered status with Amount = 0
• 63 accounts generated more than one invoice
• 9 eventually reached paid state
• 54 never transitioned to paid

Observed paid execution rate per created invoice:

8.8% (27 / 307)

Important clarification:

We are not observing bank-level failed transactions.

Provider-level authorization attempts were not directly visible in this dataset.

We are observing billing entities created after explicit payment intent and whether they transitioned into a paid state.

3. Retry Behavior: Strong Intent Signal

From attempt-level analysis:

• 63 unique accounts generated multiple invoices
• A subset retried 2-3+ times
• 54 accounts retried but never reached paid state

Retry behavior is a strong intent signal.

Users did not abandon after the first unsuccessful invoice-to-paid transition.

This eliminates:

• accidental clicks
• curiosity traffic
• superficial engagement

Intent was present.

Execution was constrained.

4. Status-Level Breakdown: State Transition Constraint

Invoices clustered heavily in a specific billing status:

• Status ordered -> 0% observable transition to paid
• Statuses active / stopped -> high transition probability

What ordered represents:

• invoice created
• Pay clicked
• invoice remained unresolved
• no observable paid transition recorded in billing

This suggested that UI-level invoice creation did not consistently result in deterministic invoice-to-paid progression.

This is not classic UX friction.

The dominant observable constraint appeared concentrated in invoice state transitions.

5. Payment Method Layer (Interpreted Carefully)

When invoices observably transitioned beyond ordered state:

• Visa / Mastercard -> successful cases
• PayPal -> successful cases
• Crypto -> successful cases
• Skrill -> successful cases

Billing did not expose provider-level approval telemetry.

However, successful payments were observed across multiple providers once invoices progressed beyond unresolved state.

No evidence suggested that a single payment provider was the dominant constraint.

The dominant observable constraint appeared concentrated in invoice-state progression.

6. Time Pattern (Lag Analysis)

From time-based analysis:

• invoice generation often occurred shortly after registration
• retries occurred within short windows
• no prolonged evaluation pattern was observed

Interpretation:

Users repeatedly re-entered monetization flow rather than exhibiting long reconsideration cycles.

This behavior was more consistent with execution friction than pricing hesitation.

7. Segment and Amount Validation

From financial segmentation:

• Average B2C invoice: ~EUR 99
• Multi-year licenses were attempted
• Larger invoices also remained in ordered state
• No correlation between invoice size and transition probability

This excludes:

• price-driven rejection
• low-quality user bias
• small-check failure hypothesis

Transition probability appeared state-dependent rather than price-dependent.

8. Structural Diagnosis

The billing engine relied on legacy state transitions originally designed for sales-assisted workflows.

In the historical model:

• managers manually intervened
• edge cases were operationally corrected
• broken transitions remained partially hidden

Self-service removed that operational buffer.

The system became directly observable.

Key constraint:

Invoice-state architecture was not fully aligned with browser-first monetization flow.

9. Why This Is a Growth Constraint

This was not merely a billing issue.

It was a growth constraint because it:

• blocked monetization despite validated demand
• distorted funnel interpretation
• misled acquisition analysis
• created false negative signals about self-service viability

Without deep instrumentation, teams could incorrectly conclude:

• traffic quality was weak
• pricing was incorrect
• positioning lacked demand
• UX required redesign

While the dominant constraint resided deeper in billing-state architecture.

10. What the Experiment Demonstrated

Deep dive ruled out demand-side issues and validated a structural constraint in invoice-to-paid progression.

11. Strategic Implication

Scaling acquisition amplifies unresolved monetization leakage.

How I approached the organizational and operational side of this problem is discussed in Part III.