4 ms·

First off, I appreciate your related comments. Two questions Im curious about: You mention usage and one time charges as being distinct. Ive generally seen the

First off, I appreciate your related comments. Two questions Im curious about: You mention usage and one time charges as being distinct. Ive generally seen them treated as the same thing; “instant”, “action”, or “usage.” Effectively atomic units of metered usage that are aggregated later, and the corollary to recurring usage. Is there some reason to not model “one time charges” as just a another (infrequent) variant of usage. Eg a “service connection” usage with value = 1? I didnt see you discuss pricing in your list. Do you normally treat pricing as part of usage? Ive always see it as a separate value thats joined with usage per customer-billing period.

doctor_eval 4y ago
So as I see it, one time charges are basically SKUs that just pass through the billing system unmodified. The billing process might compute the price (based off a price list, see below), and it will probably apply discounts and tax, but otherwise they pop out the other end - onto an invoice - 1:1 with the input. They aren’t aggregated or otherwise processed. This means that can be generated by some external black box that we don’t know anything about (eg, decline fees from payment processing). For usage, as you say, there is a complex process that’s needed to compute the final value for an invoice - in telco the formal names are mediation, guidance and rating - which isn’t needed for one time charges. A usage charge may be the aggregate of thousands of usage samples (CDRs, charge detail records), processed through a bunch of rules. The CDRs can come from many sources and be formatted differently. Importantly, you don’t want to treat these CDRs as full charges that appear on an invoice, because doing so will overwhelm your billing database for no benefit. Similarly, while you could in theory send a one time charge through the rating process, doing so is probably wasteful, as the processing functionality doesn’t significantly overlap between usage and one time charges. Pricing is very complex! You are absolutely correct, it should be separate, and it should apply to all three types of charge (consider that the actual decline fee charged to an account might be different depending on what plan they are on, or some other factors). So yes, pricing ideally needs to be separate, or at least decoupled from the billing process. That adds another layer of complexity for sure. I hope this makes sense, It’s getting late where I live :)
- donavanm 4y ago
  Thanks! Your details of one time charges passing through to invoice/billing, probably bypassing aggregation, totally makes sense. I’m thinking of that case as something like “incurred line items” now. I haven’t seen that much as I’m more on the Service side of the *aaS space. And yes the variable pricing still makes sense there. I like your example of variable decline fee based on plan as an analogue to my related SKU discounts I mentioned in another comment. Edit: belated additions to your great list of “basics most people miss some of”: pro rating & amendments, especially retrospective prorata! And the classic retrospective amendments after you’ve crossed a billing period. Aka “we’re sorry and here are some fungible credits!”
  - doctor_eval 4y ago
    The interesting thing about one time charges is that they can come from anywhere. Maybe you need to charge for sending an SMS late payment reminder, or even a late fee. In some countries you can even charge a credit card success fee, which needs to appear on the next invoice. One time charges solve all these problems. Pro-rating is a real spanner in the works! If you’re half way through a month and you’ve already charged $100 for the “silver” plan, and the customer wants to upgrade to “gold”, you need to refund the unused half of the month on “silver”, or somehow take that already invoiced amount into account during the upgrade process. The only alternative is to give “gold” away for half a month (which opens a path for gaming) or to wait until the end of the month to change the plan (pisses the customer off). Calculating all this accurately is possible, but very hairy, and the solutions we came up with after many years in the space were non obvious. It’s far from rocket science, of course, but it’s far from straight forward.

doctor_eval 4y ago

So as I see it, one time charges are basically SKUs that just pass through the billing system unmodified. The billing process might compute the price (based off a price list, see below), and it will probably apply discounts and tax, but otherwise they pop out the other end - onto an invoice - 1:1 with the input. They aren’t aggregated or otherwise processed. This means that can be generated by some external black box that we don’t know anything about (eg, decline fees from payment processing). For usage, as you say, there is a complex process that’s needed to compute the final value for an invoice - in telco the formal names are mediation, guidance and rating - which isn’t needed for one time charges. A usage charge may be the aggregate of thousands of usage samples (CDRs, charge detail records), processed through a bunch of rules. The CDRs can come from many sources and be formatted differently. Importantly, you don’t want to treat these CDRs as full charges that appear on an invoice, because doing so will overwhelm your billing database for no benefit. Similarly, while you could in theory send a one time charge through the rating process, doing so is probably wasteful, as the processing functionality doesn’t significantly overlap between usage and one time charges. Pricing is very complex! You are absolutely correct, it should be separate, and it should apply to all three types of charge (consider that the actual decline fee charged to an account might be different depending on what plan they are on, or some other factors). So yes, pricing ideally needs to be separate, or at least decoupled from the billing process. That adds another layer of complexity for sure. I hope this makes sense, It’s getting late where I live :)

donavanm 4y ago
Thanks! Your details of one time charges passing through to invoice/billing, probably bypassing aggregation, totally makes sense. I’m thinking of that case as something like “incurred line items” now. I haven’t seen that much as I’m more on the Service side of the *aaS space. And yes the variable pricing still makes sense there. I like your example of variable decline fee based on plan as an analogue to my related SKU discounts I mentioned in another comment. Edit: belated additions to your great list of “basics most people miss some of”: pro rating & amendments, especially retrospective prorata! And the classic retrospective amendments after you’ve crossed a billing period. Aka “we’re sorry and here are some fungible credits!”
- doctor_eval 4y ago
  The interesting thing about one time charges is that they can come from anywhere. Maybe you need to charge for sending an SMS late payment reminder, or even a late fee. In some countries you can even charge a credit card success fee, which needs to appear on the next invoice. One time charges solve all these problems. Pro-rating is a real spanner in the works! If you’re half way through a month and you’ve already charged $100 for the “silver” plan, and the customer wants to upgrade to “gold”, you need to refund the unused half of the month on “silver”, or somehow take that already invoiced amount into account during the upgrade process. The only alternative is to give “gold” away for half a month (which opens a path for gaming) or to wait until the end of the month to change the plan (pisses the customer off). Calculating all this accurately is possible, but very hairy, and the solutions we came up with after many years in the space were non obvious. It’s far from rocket science, of course, but it’s far from straight forward.