Have you ever been counting pennies in your regular daily transactions? If not, you could be missing the millionaire bus 😊 Sounds strange? One of the upscale retailers did a 1-million-dollar write-off as part of their annual financial reconciliation. This write off is in additional to regular write off’s done due to account for fraud, theft, damages or system inaccuracies.
During implementing enterprise order management solutions, we often need to deal with rounding challenges w.r.t financials like order totals, shipment totals, taxes and charges. These occur due to various situations in order fulfillment (like when entire basket doesn’t get fulfilled from single fulfillment location to single destination) and modifications (like partial cancellation and return).
Added to this complexity, the love from mother of all sciences- Mathematics playing her natural game of recurring decimals. Also, any precision beyond 2 decimal digits in financial world doesn’t carry much business value. Moreover, there is a legal perspective driven from federal or local government laws applicable to each region/country and rounding strategies must factor them in solution. Let us understand this from a simple example –
An order basket costing $10 for 80 units and only 3 units are shipped on day 1. Remaining units are backordered. Settlement with bank will happen for 3/80 * 10 = $0.375. Can settlement be rounded off to $0.38 or $0.37?
Can the same strategy be deployed to rounding off during each settlement for remaining units getting fulfilled on subsequent dates?
Say, another 5 units get fulfilled on day 2 and another 72 units on day 3. This will settle $0.625(5/80*10) on day 2 and settle $9 (72/80*10) on day 3. If the strategy is on lower precision, it will account only for $9.99 (0.37+0.62+9) causing a loss of penny!!! If the strategy is on higher precision, it will account only for $10.01 (0.38+0.63+9) causing a penny in suspense!!!
Can settlement be rounded off when 77 units are cancelled before fulfilling 3 units?
Probably not, because these 3 units will be the last invoice and rounding must be done right away since there is not another opportunity to do rounding. During settling for 3 units, if there are valid fulfillments expected in future, rounding can be done later to avoid rounding in each invoice. Rather, do all the rounding in last invoice to decrease error in decimal precision.
What happens when there are unit level charges (such as shipping, value added charges, etc.) and taxes which need to get pro-rated because of partial fulfillment or tax amount changes during settlement?
Rounding strategy is something every business deals with their own ways in line with accounting principles and IBM applications support them accordingly. However, our role as advisors would be to devise a right strategy to reduce financial write-off. Few best practices that I have come across are listed below. Nevertheless, there is a not a single canned solution to tame the rounding animal.
- Multi Decimal management – The accuracy of rounding is directly proportional to the number of decimals considered. This doesn’t imply to use big decimals to reduce rounding errors since currency beyond 2 decimals doesn’t carry much business value. However, recommendation could be to choose at least 4-digit decimals to reduce the error scenarios. This will not solve recurring decimal rounding though. This may also lead to enhancements to the legacy financial systems so that all the systems (in an enterprise solution architecture) follow the same precision.
- First and Last Invoice – An order or each line on order can have potentially ‘n’ number of shipments and hence settling the remaining balance amount on last invoice of the order will eliminate the rounding off error to a large extent. This means round off only during last invoice and not in all intermediate invoices because decimals will cascade at the final settlement and again demand a rounding iteration leading to supersession effect.
Invoice all charges on first invoice of the line and invoice all taxes only on the last invoice of the line will cut down rounding errors to manage differences in tax amount during quote and actual settlement. The flip side of this would be tax increases during last invoice and business passing the benefits to customer doing write-off. In the end, you don’t want customer care to call up customers for keying a tender to get a penny 😊
- Charge Per Unit v/s of Charge Per Line – Having charge per line model will invoice the entire charge during first invoice of line eliminating rounding errors. However, if remaining units of line don’t get fulfilled (need to refund the balance amount) or the fulfilled units are returned (triggering refund), then this brings back rounding calculation to determine accurate refund amount.
Charge per unit model can be used but manage decimal values during every invoice. During last invoice, blindly eat up entire remaining charge on line to settlement. Ex: 10/3 – $ 3.33 settlement 1, $ 3.33 – settlement 2 and final settlement use remaining charge as Total Charge on line – Total Invoiced Amount giving $3.34. This is typically deployed to manage recurring decimals.
- Invoice Adjustments – When entire invoicing is done on first shipment, there will be scenarios when cancellation of all remaining quantity on line after first invoice causing rounding error. In these cases, the already settled invoice cannot be changed and hence rounding adjustments should be handled through credit memos.
This was my experience, what is yours? Please post any of best practices around rounding models deployed for our customers and we will make our customers not loose pennies. Happy rounding!!
This article was co-authored by Raghuveer P Nagar.