An invoice run can create a great deal of records with just a little set up. For this reason, planning and testing in a full sandbox is irreplaceable when getting ready to go live or when making changes to Production.
Permissions
The user that creates the invoice run (via the invoice scheduler) will need all the permissions to create and post invoices as noted in this article. Keep in mind that many Billing objects, such as Invoices, are master-detail to Account and share permission settings. This is even more important when using a private sharing model. An alternative is to have a user with the System Administrator user profile create all Invoice Runs. This significantly reduces the amount of testing required for new releases and other changes. If the User who created an Invoice Run must be deactivated, refer to this knowledge article for steps to fix the issue.
Start Small
Use the Invoice Batch field on Order to create and test small runs. Build up to the full size runs you will eventually use. Note that Invoice Runs create apex jobs that are subject to Execution Governors and Limits. This determines how many order products and usage summaries can be picked up for invoicing on one run. The point where this exceeds a governor limit varies based on org design. It is good practice to do scale testing when the total is more than about 200,000. If there is a need to split very large batches into smaller sizes, assigning an invoice batch based on the first letter of the Account name, or Billing Account name is an easy customization that keeps Orders together for consolidating invoices. Note that when the Invoice Batch field is set to null, it only selects Orders that also have null in the Invoice Batch field. There is no way to select all Orders unless they all have null in the Invoice Batch field or none of them do. Null is not a value that can be added to other values in a multi-select picklist.
Initially, do not automatically post invoices. If there is an error, having hundreds or thousands of posted invoices that need to be redone requires the use of Cancel and Rebill one invoice at a time. There is no mass cancel and rebill feature. If the invoices are not posted, they can easily be cancelled and their related order products reset by using the Clean Up feature.
Be mindful of your data model. Roll-up summary fields on the Account that change with invoice creation or posting can trigger some or all of the automation on the Account record and lead to failed invoice creation due to row lock errors or exceeding governor limits.
Automation
Be very mindful when adding triggers to the invoice and/or invoice line objects and test these thoroughly. These can fire multiple times when creating and posting invoices. For example, when using an invoice scheduler to create and post invoices, a simple before update trigger on the Invoice to update a text field will fire 5 times. Best practice would be to use a batch job to perform updates to the invoices after the Invoice Run completes instead of a trigger.
If you do add automation, make sure that it does not fire or update records when any of the following picklist status fields are set to "Queued". Queued means that the record is waiting for an update from an asynchronous process. Updating the record before it completes will create a 'stuck' record with possible incorrect data.
Also, make sure that automation does not fire when Invoice Status or Invoice Line Status have the following values: Initiated, Post in Progress. These are intermediary statuses and are exclusively for the use of the Billing managed package.
Error Correction after an Invoice Run. At the end of an invoice run, to redo some or all of the invoices:
Naming convention for Invoice Schedulers. Choose a name that will readily identify the Apex Job as an Invoice Scheduler to make it easy to find under Setup > Scheduled Jobs in case you have to Cancel Upcoming Invoice Runs.
Dashboard Components or Reports are an excellent way to quickly see what has been created and if any invoices require attention. Here are a few suggestions:
000389310

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.