Every billing team has lived this. Sales closes a deal with a pricing shape the system can't express — a usage rate with a monthly minimum, a tier that shifts mid-term, a one-off addendum — and suddenly billing the deal is an engineering ticket.
Why it happens
Off-the-shelf billing models a fixed set of plans. The moment a deal steps outside that set, you get two options — and both are projects.
Option one is custom code: a special case in the billing logic for this one deal's shape. It works until the next non-standard deal, and now you maintain a pile of special cases.
Option two is a CPQ layer or an integration project: weeks of configuration and lead time before you can invoice a single dollar of the new deal.
The cost isn't the pricing. It's that the pricing needs a project before it can bill.
What we changed
We made the deal the unit of configuration, not the plan. A contract in Summance holds the actual terms — usage rates, minimums, tiers, and addenda for mid-term changes — as data, with no code path per deal.
Because the contract is data, modeling a new pricing shape is a modeling task, not an integration task. You describe the deal — to Penny in plain language, or through your app's SDK on signup — and it becomes a live contract that meters, invoices, and reconciles on its own.
From contract to cash, without the project
Once the contract exists, the loop runs unattended: usage meters against the terms, an invoice bills the usage on cadence, a payment closes it out and reconciles back. Integrate once, and the next new pricing model is just another contract — not another project.
See how the whole loop runs on the Product page .