Occurly and Chargebee
Teams comparing Occurly with Chargebee want one platform for subscriptions, usage-based billing and revenue analytics, with a developer experience that keeps up.
written for people who already use it
Side by side
Two approaches, stated plainly.
Not a scorecard. Both columns describe how each platform chooses to solve the job, including where Chargebee goes further than Occurly does today.
| The job | Chargebee | Occurly |
|---|---|---|
| Usage-based pricing | Supported alongside the subscription catalog, configured as its own layer. | Metering is a first-class part of the same platform, so usage and subscription lines rate onto one invoice. |
| Revenue analytics | Reporting in-product, with deeper analysis usually done in a warehouse or a second tool. | MRR, retention and cohorts computed from live billing data, in the same system that produced the invoice. |
| Cost as you grow | Platform fee plus an overage rate on billed volume, with flat pricing at the enterprise tier. | Platform fee with a lower overage rate, moving to a flat annual fee earlier rather than only at the top. |
| Breadth today | Mature across a very wide surface, with reference customers in most sectors. | Newer, narrower in the long tail, and honest about which edge cases are still being earned. |
Why teams look at Occurly
Usually when pricing gets hybrid, or a second entity appears.
The evaluations that end in a move tend to start with the same four requirements.
- Usage-based and hybrid pricing handled natively, on the same invoice
- Revenue analytics computed from live billing data, not a separate tool
- Pricing that moves to a flat fee rather than a percentage at scale
- Guided migration with plan, customer and invoice history import
Migration
Moving without skipping a cycle.
Chargebee exports plans, customers, subscriptions and invoice history in full, which is the part that usually decides whether a migration is a weekend or a quarter. Occurly imports all four and reconciles the open receivables before cutover.
- Week one
We map what you have.
Your catalog, entities, currencies and contract structures, against how they would be modelled in Occurly. You get the map whether or not you go ahead, including anything that has no clean equivalent.
- Weeks two and three
Everything imports into a sandbox.
Plans, customers, subscriptions and invoice history load into an environment that mirrors production. We run parallel cycles against it and reconcile them line by line with your current system.
- Cutover
One cycle boundary, and you are on.
The switch happens on a cycle boundary, not mid-period. Payment methods stay with your existing processor, so no customer is asked to re-enter a card and no invoice is missed.
What comes across
Nothing is left behind on purpose.
The parts of a migration that go wrong are almost always the unglamorous ones: open receivables, part payments and the invoice history reporting depends on. Those are the parts we reconcile first.
- Plans, add-ons and price points import as a catalog
- Customers, subscriptions and their full history come across
- Historical invoices import, so reporting stays continuous
- Open receivables and part payments are reconciled before cutover
- Payment methods stay with your processor, untouched
- Parallel cycles run until the numbers agree
FAQ
Moving from Chargebee
Can we keep our current payment processor?
Yes. Occurly is processor-agnostic and routes to the gateway you already use, so stored payment methods do not need to be re-collected from your customers.
Do we lose our invoice history?
No. Historical invoices import alongside customers and subscriptions, so revenue reporting spans the period before the move rather than starting from zero.
Bring us your current setup.
We will map it against Occurly and tell you what a move would take, in writing, including the parts that would not be an improvement.
Other comparisons