This article describes the general flow of how billing and invoicing works at Compliance Publishing, along with factors to consider when deciding how to structure different pricing models.
The Flow
The general process flow for using the Compliance Publishing Invoicing system is:
- Complete a pickup, creating a manifest
- The manifest data from the completed pickup will be transferred to the Approve Data screen. The approve data screen acts as a check for the user to verify that the manifest data is correct before creating an invoice. Note at this step, invoice level fees will not show up.
- Once the manifest data is approved, it is ready to be invoiced. At this step, the user has the ability to verify the invoice data before printing the invoice, emailing the invoice, or both. The difference in the data verification at this step is that the invoice can contain data from multiple manifests and invoice level fees will now appear, and need to be verified.
- Lastly, the invoice data will be billed (emailed, printed, or both depending on the customer invoice settings) and the time clock measuring whether or not the invoice is paid on-time will begin. Note that the default payment terms are net 30, which can be adjusted in the invoice settings.
Billing Structures
Rule classes are created, customers are added to these rule classes based on the structure of how they are to be billed, and then rules are added to the rule classes. If you have a group of customers who are billed using the exact same rule structure, then those customers should be a part of the same rule class.
But what happens when a customer needs to be considered with a slightly different structure (tier differences for instance), or a completely different rule structure or item/container needs? The summed up answer is to create a new rule class for that customer. Then anything you do inside of this new rule class does not have any affect on the established Demo Class. But lets break that decision down.
It is easiest to use an example when trying to illustrate the factors to consider. Lets say we have an established rule class called Demo Class that has rules built for 1 Gal, 2 Gal, and 3 Gal. Then we have a new customer who won't be billing based on any of those three items. This new customer needs to be billed based on All Containers. We could set up a rule in the Demo Class based on All Containers, give that rule a base price of $0 so the already established customers aren't billed based on that rule, and then insert custom pricing per customer who needs to use this new rule.
What are the disadvantages of this approach? If you ever want to add a rule based on All Containers that your established customer base is going to use, you are stuck because you would already have a rule structure in place for All Containers.
Another disadvantage would be that you have to set this rule up with a base price of $0, when every customer who uses this rule may all pay the same price. Which means every customer that needs to follow this new way of billing would have to have a custom customer price added for the rule.
And another disadvantage is those established rules set up for 1 Gal, 2 Gal, and 3 Gal would all need to have a base price of $0 in place. Otherwise these rules would kick in for the new customer who needs to be billed based on All Containers.
The recommended and most flexible approach would be to create a new rule class, assign the appropriate customer to that rule class, and create the new rule inside of that rule class.