Multiple Credit Pools

"multiple credit pools" is designed to cater to consumption based revenue models if you have a suite of consumption based products like apis, webhook events, computing minutes, and cloud storage, etc, with this feature, your customers can have the flexibility to prepay in either credits or cash, held within each dedicated "credit pool" for different types of consumption for each unique type of consumption or usage, your can create a dedicated credit pool if you are doing business in multiple currencies, they can create one or more for each currency it's a game changer for businesses seeking versatile payment solutions in the dynamic world of consumption based pricing this article requires you to have a general understanding of the credit burndown usage model docid 5wcdjhqecjb81 gcfeld enable multiple credit pools nue provides two types of credit credit and cash you can enable either or both of them the system will generate a default credit pool for each credit type that is enabled you can create multiple credit pools if you need different credit pools for each customer for different purposes go to nue system settings > billing schedules > credit burn down click the + icon next to the default credit pool on the credit pool creation page, select a credit type and set a name for the newly created credit pool the newly created credit pool will be set as the system default credit pool after it is created you can also rename the credit pool on the edit page by clicking the edit icon for credit pools not being used, clicking the icon will allow you to delete them scenarios now let's take a look at a scenario on how a customer can use multiple credit pools to track the expenses for the different subscriptions they purchased example vroom inc , our fictional company, offers a vroom credit package product each credit in this package is priced at $2 customers can get the credits by purchasing the package and utilize their credits for different purchases, such as api calls, transcript storage, and cpu computing minutes vroom also offers another vroom event package product that will top up the cash amount to the customers' accounts, and then can be used to pay for the revenue stream event every time the customers generate a revenue stream report enable credit types to accomplish the above requirements, the administrator needs to enable credit types for both credit and cash navigate to nue system setting → credits, and check both credit and cash for the credit type option a default credit pool will be generated for each of the credit types automatically rename the default credit pools to meaningful names based on your business requirements, in this example, let's call them 'credit account' and 'cash account' you can also use names such as 'points', 'events', etc configure products let's create the following products product name revenue model list price credit pool credit conversion vroom credit package credit burndown $2 credit/year credit account n/a api calls overage usage $0 02 per call credit account vroom cash package credit burndown $200 each/month cash account n/a revenue stream event overage usage $0 1 per event cash account n/a note credit conversion is required for credit type pools only 100 calls = 1 credit for simplicity, we will only create one overage usage product per credit pool, so only one usage product will be consuming the credits in the credit pool however, you can create more than one usage products to consume credits or cash from one credit pool to associate the credit pool for each product, please follow the steps below navigate to price builder → product catalog, and click the edit action icon of the product on the product edit page, specify a credit pool for each product the 'vroom credit package' issues credits to the customers while 'api calls' consumes credits based on the usage, so set the credit pool to 'credit account' the 'vroom cash package' is to top up the balance of the customer's cash account and the customer can pay the 'revenue stream event' by the account directly, so the associated credit pool for these two products will be 'cash account' configure the credit conversion for the usage product that consumes credit type of credits (see how to configure the credit conversion credit burndown usage model docid 5wcdjhqecjb81 gcfeld ) for example, the 'api calls' will consume the credits based on the number of calls made, so you need to set the conversion rate between the number of api calls and the amount of credits consumed accordingly for the 'revenue stream event', since it will get paid directly from the cash account, then the credit conversion won't be needed note for a 'credit burndown' type product, you must specify a credit pool for it, since a customer could have multiple credit pools for different purposes, this will determine where the credits will be issued when they purchase the product for any 'overage usage' type products, assign a credit pool if they need to consume credits or cash from the customer's credit balance if a usage product doesn't have a credit pool configured, it will be rated by dollar amount and billed through the invoices generated by billing schedules create order and subscriptions now the sales reps can place orders for the customers to purchase the credits and top up their accounts let's create an order for the customer 'ruby cloud' in the line editor, search for the products, and drag them to the line editor in this example, let's add and configure the quantities as shown below the customer purchases 1000 credits and top up their cash account for $200/month, and they also subscribe to the api calls and revenue stream event services after activating the order, the credit burndown and usage subscriptions are generated navigate to the lifecycle manager of the customer 'ruby cloud', under the 'credit' tab, you can see the details of the credits and credit flows since the customer has purchased both credit burndown subscriptions, there will be two credit pools displayed credit account and cash account you can switch the credit pool and check the credit flows for each of them in this example, there are 1000 credits issued to the credit account and $200 topped up to the cash account every month you can see see credit burndown and usage subscriptions of this customer under the subscription tab consume credits from different credit pools now let's ingest some raw usage for api calls and revenue stream event subscriptions you can do this by uploading the usage for each subscription separately or together, depending on your business operations in this example, let's ingest the following raw usage subscription subscription number quantity timestamp api calls sub 000009 100 2023 09 01t09 00 06 000z api calls sub 000009 150 2023 09 02t09 00 06 000z revenue stream event sub 000010 20 2023 09 05t09 00 06 000z revenue stream event sub 000010 30 2023 09 12t09 00 06 000z after the raw usage is uploaded, they will be rated immediately you can see the status in the usage list for each usage if you enable both credit types, credit and cash, you will see a switch on the top left corner of the usage list page this switch allows you to view the usage chart and usage records for different credit types let's switch to credit first you can see there are two usage records of subscription api calls that get rated the first one with 100 quantities is rated to 1 credit (rated amount) since the credit conversion rate is set as 100 calls consume 1 credit in the product, and it consumes 1 credit (applied amount) from the customer's credit account directly for the second usage record with 150 quantities, you will see the rated amount is 2 rather than 1 5, this is because when setting up the credit conversion for the product api calls, we set the decimal scale to 0, and rounding mode to up, so 1 5 will be rounded up to 2 you can adjust these settings of credit conversion according to your business requirements the rated credits are deducted from the customer's credit account immediately when you switch to the cash list, you can see the rated cash amount for the usage of 'revenue stream event' subscription these usage are rated based on cash amount since the product is a cash based usage product and associated with a cash credit pool the rated amount for these usage records is a dollar amount, the amount 2 indicates $2 in this case you can also see the numbers in the applied credit column, which indicates the rated dollar amount is deducted from the customer's cash account directly now if you navigate to the lifecycle manager of the customer, under the credit tab, you will see the credit outflows in each credit pool, consuming the credit or cash amount accordingly advanced scenarios credit pools for different billing accounts enabling the billing account hierarchy docid\ isknq1oh0d81vhnqjs7ei allows customers to track budgets and expenses for different departments, sales regions, or financial processes by associating different billing accounts with different subscriptions, credit pools will be generated for each billing account on the customer lifecycle page, users can view the credit flows for each credit pool under different billing accounts credit pools for different currencies enabling multiple currencies in the system will sort cash type credits into different categories based on their respective currencies as a result, separate credit pools will be generated for each currency on the customer lifecycle page, users will be able to see credit flows for each credit pool in different currencies putting it altogether with multiple credit pools, you can effectively manage a diverse suite of consumption based products and services this feature helps you to create different credit pools for each specific type of consumption or usage, whether they are credit based or cash based you can customize pool names to align with your business requirements create and manage products using credit burndown, credit, or overage usage revenue models, associating them with designated credit pools in the case of credit burndown products, when orders containing them are activated, the order amount is added to the assigned credit pool, generating a credit inflow for overage usage products, as usage is processed and rated, the corresponding amount is deducted from the designated credit pool, leading to a credit outflow you may have multiple credit burndown products to contribute to a single credit pool and have multiple overage usage products to draw from a shared credit pool easily access credit statistics, credit inflows, and credit outflows for all available credit pools through the credits tab within the lifecycle manager this feature provides a comprehensive solution for managing diverse consumption based products and their associated financial transactions efficiently and transparently