...

When dealing with prorated adjustements adjustments which are percentages, the behavior is as follows:

• "By lines" prorated percentage adjustments are split so 10% is split across N invoiceLines such that each gets (10/N)%
• "By amount" prorated percentage adjustments aren't split but rather each invoiceLine gets an adjustment of that percentage... (e.g. if the invoice adjustment is 10%, each invoiceLine gets an adjustment of 10%.)
• "By quantity" prorated percentage adjustments doesn't make sense and the UI should prevent the user from using that combination. We will also need to validate this on the backend and return an error response in the case where someone makes a call directly to the API with the combo.

...

we calculate the effective amount by applying the percentage to the invoice sub-total and then prorate that amount like any other amount-based prorated adjustment.  Given this approach, prorating percentage adjustments by quantity is now possible, whereas it was previously considered not applicable.

Fractional Pennies

When working with prorated adjustments, we need to make sure that the sum of the invoiceLine adjustments is equal to the prorated adjustment for which they represent.  This means special handling of adjustments of amounts/percentages which don't distribute evenly.  

...

POC code demonstrating these calculations:  ProratedAdjustmentsPOC.java  NOTE this code is intended to be illustrative.  It has not been refined or optimized and probably does not meet the quality standards of our production code.

...