• What We Do
  • Our Work
  • Information
  • Smart Solutions for Smarter Business

    Accuracy vs Precision: The Perils of Rounding within Black Box Software Back to blog

    Accuracy and precision in colloquial language can be taken to mean the same thing; I just duckduckgo’d the meaning of accuracy, and the second definition specifies precision; exactness. As a programmer and engineer most of the problems that I tackle on a day to day basis have everything to do with accuracy or precision. In a philosophical way, a bug being considered a feature is a positive outcome of a lack of precision within the functionality of an application.

    In terms of financials there is no leeway within the accuracy of amount to a certain precision value, what this means is that financials need to be accurate to their cent figures. Overcharge by a cent and you end up with fraudulent charges because of micro-gains from each transaction; on the other hand under charging a cent can become a serious problem in a high transaction business with low marginal gains.

    My current project is a point of service application that dynamically shows what a sales order will cost to the client. SAP Business One (B1) is the backbone of the application; this means that the numbers that I calculate in the front end need to be exactly the same as those that are found in B1. The problem with this scenario is that B1’s rounding logic is not made public in its documentation; my only course of action to solve this is to reverse engineer B1’s rounding logic.

     

    Example base configuration of decimal places in SAP Business One

     

    When calculations take place, the precision of the calculation can only be as high as the least common decimal place. Taking the information from the figure as example, if a quantity is multiplied by a rate, the result can only be precise to three decimal places. One problem that arises from this situation is that calculations can be made piecewise. Values may be multiplied rounded, then multiplied again and rounded again to a lower precision. Depending on when the values get rounded the end value can be dramatically different.

    To further complicate things, clients may utilize different methodologies that are not obvious when first encountering their configuration in B1. They may be utilizing add-ons that allow them to cheat how the system performs arithmetic. Most of the times these issues can be found while testing, but it is always important to communicate how the client handles edge cases. As the saying goes, a penny saved is a penny gained.

    By
    David Sanz
    Lead Developer

    By
    David Sanz
    Lead Developer