Software Version Used
- Installed product version: 10.0.10 (10.0.420.10041)
- Installed platform version: Update 34 (7.0.5600.35546)
Introduction
The royalty functionality in Dynamics 365 for Finance and Operations (D365FO) allows for calculating, accruing, and invoicing of automatically created royalty claims. Royalty claims are created when sales order invoices are posted for item numbers that have been included on one or more royalty contracts/royalty codes. This allows for some automation to be introduced into your royalty processes when maintained in D365FO.
Calculating Royalties in D365FO
The steps below follow the most basic linear processing of calculating royalties in D365FO. This assumes that all royalty claims are created before they are cumulated, cumulated before they are approved, and approved before they are processed. This is all straightforward and the calculations make sense without having to do too much digging.
- Post sales order invoices.
- This will create royalty claims.
- The status will be “To be calculated” when first created.
- Cumulate royalty claims.
- This will first summarize by time period and item number.
- Notice that the Value field has been updated on both royalty claims.
- The status will be updated to “Calculated” when this is complete.
- Approve royalty claims. (Optional)
- This will create accrual journal entries.
- The status will be updated to “Approved” when this is complete.
- Process royalty claims.
- This will create reversing accrual journal entries.
- This will also create payables invoice journals.
- The status will be updated to “Completed” when this is complete.
Additional Transactions
The processing of royalty claims is not always going to be straightforward, however. There will almost certainly be times where some royalty claims are approved (so monthly accrual journal entries can be created) before other royalty claims are even created. There will most likely be times where some royalty claims are completely processed (creating payables invoices) before other royalty claims are created.
The steps below outline what corrective actions D365FO will take when some royalty claims have been completely processed and then additional royalty claims are created and processed as well. Continuing with our simple example from above this is still relatively straightforward, but with any kind of normal volume this could get complex quickly.
- Post additional sales order invoices.
- This will create additional royalty claims.
- Cumulate the additional royalty claims.
- This will again summarize by time period and item number.
- This will recalculate royalty claims that can be recalculated.
- This will then create a new royalty claim line to account for those that cannot be recalculated.
- Approve the additional royalty claims. (Optional)
- This will create additional accrual journal entries.
- Process the additional royalty claims.
- This will create additional reversing accrual journal entries.
- This will create additional payables invoice journals.
Recalculating Royalties in D365FO
The key point in the Additional Transactions section above is step number two—cumulating the additional royalty claims. All the other steps follow the same flow as processing royalty claims all together each step of the way. To dig deeper into what happens when cumulating additional royalty claims, we must first look back at the royalty code that these royalty claims are associated with. Specifically, we care about the line breaks of the royalty amounts.
Our example is paying 2.5% of sales amount when up to 10 units are sold, 5% when up to 20 units are sold, 7.5% when up to 30 units are sold, 10% when up to 50 units are sold, and 12.5% when more than 50 units are sold.
When the new royalty claim is first created as part of the sales order invoicing process, it is classified in the first tier, because the sales invoice line is for a quantity of 8. When all three royalty claims are cumulated together, the total quantity is now 32, which should classify all three royalty claims in the fourth tier. The two royalty claims that have already been processed cannot be changed, so a new royalty claim is created to account for the difference.
Notice that a similar set of calculations were done during the processing of royalty claims all together. Each royalty claim was assigned a percentage value based on the quantity of that specific sales order invoice line. When they were cumulated together the total quantity resulted in a new percentage value that should have been assigned. However, those royalty claims were still able to be changed because they had not yet been approved or processed.
Conclusion
The royalty functionality in D365FO is a good starting point for automating a task and calculations that might normally need to be outside of your ERP solution. Recalculating previously processed royalty claims to ensure the total amount due back to your royalty vendor is correct is one example why.
The adjusting royalty claims, however, are not associated to specific royalty claims that were previously processed, which can leave some guesswork to be done. The calculations are also done assuming the first-dollar inclusion in the final tier rate, possibly preventing some more complex royalty calculations from having an obvious box to fit in to within D365FO.
This publication contains general information only and Sikich is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or any other professional advice or services. This publication is not a substitute for such professional advice or services, nor should you use it as a basis for any decision, action or omission that may affect you or your business. Before making any decision, taking any action or omitting an action that may affect you or your business, you should consult a qualified professional advisor. In addition, this publication may contain certain content generated by an artificial intelligence (AI) language model. You acknowledge that Sikich shall not be responsible for any loss sustained by you or any person who relies on this publication.