Earnings to Payments Guidance

The calculation process is separate from the payment process. When you run calculation, the earnings get updated every time you run it.

You can run calculations multiple times before you send the payment amounts to the payment system. The payment process is started at the end of the process flow when you're done with calculations for that payment cycle. In the Payment process, you create and pay a payment batch which consolidates the earnings data for participants and lets you review them before you send it over to the payment system.

In this figure several calculations are run before running the payment process and producing the payment batch.

Earnings to Payment Batch

When you run calculation, it either creates new earning records or it leaves the older earning records intact if there are no updates. When you create a payment batch for a period, it consolidates these earning records, looks at the amount that's already paid, and figures out the current payment amount to be paid for that period. There are no restrictions on running calculation whether the payment batch is paid or not or whether the payment batch even exists, as long as the period is open. This means that you can create or pay a payment batch and yet recalculate again for the same periods.

In this figure the batch takes the earnings from calculations and subtracts paid amounts for the period to determine the payment amounts for the batc

Unpaid Payment Batch

After creating a payment batch, if new earning records are created because of a recalculation and the payment batch is still unpaid, you should run the Refresh Payment Batch process to have the latest earnings reflected in the payment batch. If you don't run this process, the payment data will be based on the older earnings records which were created before you reran calculations. This means that if you pay this unpaid batch without refreshing it, the next payment batch that you create will include the delta between the updated earned amount and already paid amount, whether it's positive or negative.

In this figure Refresh Payment Batch is run because earnings were recalculated while the existing batch was unpaid.

For example, the earnings for a salesperson John Smith for January 2020 are $1000 and you create a payment batch for January 2020. The payment amount reflected in John Smith's unpaid paysheet will be $1000 as well. Now, because of some changes that occur after you create the payment batch, you have had to recalculate. The earnings now for John Smith are $1200 for January 2020. However, the paysheet amount for John Smith will still stay at $1000 unless you run the Refresh Payment Batch process. If you don't refresh the payment batch and pay the batch as is, then the next payment batch that includes John Smith will have the $200 delta that he's owed.

Paid Payment Batch

After paying a payment batch, if new earning records are created because of a recalculation, they won't be reflected in the already paid payment batch. You can't refresh a paid payment batch. The new amounts will only reflect in the next payment batch that's created. So the next payment batch that you create will include the delta between the updated earned amount and already paid amount, whether it's positive or negative.

For example, the earnings for a salesperson John Smith for January 2020 are $1000 and you create and pay a payment batch for January 2020. The payment amount reflected in John Smith's paid paysheet is $1000 as well. Now because of some changes that occur after you pay the payment batch, you have had to recalculate. The earnings now for John Smith are $700 for January 2020. Since the payment batch for January 2020 is already paid, no changes can be done to that payment batch. However, the next payment batch that's created for John Smith , whether it's for January 2020 again or for a subsequent period like February 2020, will reflect the negative $300 delta that he owes.