Rounding and precision are important aspects with any numerical or financial system, and Zuora is no exception. Understanding how rounding and precision are defined within Zuora will give you insight into how Zuora handles precision, rounding and calculations.
Rounding a numeric value is the act of replacing one numeric value with one that is approximately equal but has a shorter, simpler, or more explicit representation. For example, replacing USD $65.8476 with USD $65.85. Rounding in Zuora takes place with units of measure (UOM) and currency values.
Precision of a numeric value describes the number of digits that are used to express that value, including digits to both the left and the right of any decimal point. For example 4.520 has a precision of 4. Zuora supports up to 13 digits to the left of the decimal place, and up to 9 digits to the right.
Currency rounding is defined by the currency itself.
Zuora includes rounding options that you can apply to any individual currency.
Half Up. By default, Zuora uses
Half Uprounding on all currencies (for example, where 3.49 is rounded to 3 and 3.50 is rounded to 4). The
Upoptions are useful if you need to use a different rounding mode for a particular currency (for example, in Japan, it is often the case that currency values are rounded
Downto the nearest Yen).
By default, any currency that has a greater number of decimal places than defined by the currency will be rounded based on the near rule (half up), with values of 5 or greater being rounded up (using the
Half Up setting).
For example, because the Japanese Yen (JPY) does not have a cent in circulation, the lowest value is 1 JPY. When a user enters an amount with decimal places, Zuora will round it to the nearest non-decimal value. For example, if a user enters 15.67, Zuora Billing automatically convert this value to 16.00.
The same is true when activating or editing a currency from within Zuora Billing Settings Customize Currencies: the Decimal Places values are pre-defined based on the decimal places supported by each currency.
Zuora rounds the Invoice Line Item Amount (pre-tax) based on the List Price of the product and on the rounding rules that you have set for the currency. Tax is also rounded off in this manner, but is rounded from the value of the Invoice Line Item Amount (pre-tax).
If you want to use a List Price that has decimal places, you can remove the 0.01 value offset by processing an adjustment when the invoice has been generated.
A value is rounded based on its predefined rounding rule, and each currency and UOM has a rounding rule associated with it. UOM rounding rules are user-defined, while currency rounding rules are defined by the currencies themselves.
Zuora supports three rounding rules:
There are five data types in Zuora that are either currency or UOM values. Each data type has its own rules for when rounding occurs.
|Data Type||Examples||Rounding Based On|
|Price||Also known as rate, unit price from product catalog, unit price||Prices are never rounded, even if precision exceeds currency. For example, a unit price of $3.1235/GB is always stored and calculated as $3.1235.|
|Amount||Extended price (for example, $4.99/user * 4 users), adjustment amount, invoice total, invoice balance, total tax amount.||Rounding is based on currency’s defined rounding rules.|
|Metrics||MRR, TCV||Rounding is based on currency’s defined rounding rules.|
|Tax||"Tax line items", individual taxation items||Tax line items are not rounded. Summed tax line items result in total tax, defined as an amount.|
|Quantity||Default quantity in product catalog, quantity entered on subscription or usage record, quantity displayed on invoices||Rounding is based on unit of measure’s rounding rule|
Rounding can occur in the following cases:
If numbers are not rounded, they are referred to "as is."
The following data types are rounded as is:
|Data Type||Prior to Storage||Prior to Use||After Aggregation||Prior to Display/API||Example|
|Price||As Is||As Is||N/A||As Is||$3.479/Gallon|
|Amount||Rounded||Rounded||Rounded||Rounded||Extended Price of $36.67, Total Tax of $18.29|
|Metrics||As Is||As Is||As Is||Rounded||MRR = $1533.333333333|
|Tax||As Is||As Is||N/A (aggregated tax items are an amount)||As Is||Tax item of $12.1275|
|Quantity (Transaction)||Rounded||Rounded||Rounded||Rounded||7.65 GB, 8 users|
|Quantity (Tier)||Rounded||Rounded||N/A||Rounded||Volume Pricing for 1-100 Units|
|Quantity (Other)||As Is||Rounded||Rounded||As Is||Usage Quantity Entered|
For example, a fictitious SaaS company sells seat licenses to its software and charges for any storage used. It offers the following monthly rate plan for its product:
|Recurring Fee||Usage Fee|
|$59.99/seat license per month||$1/GB per month|
It has defined the following units of measure:
|Unit of measure||Number of decimal places||Rounding rule|
|Seat License||0||Round down|
The company also charges sales tax at the rate of 7.775%. A subscription is then created and a quantity of 4.6 is mistakenly entered for the number of seat licenses. Since seat licenses have 0 decimal places and transaction quantities are rounded prior to being stored, 4.6 is rounded to 4 based on its round down rounding rule, and then stored. Any query via the API or display of this value in the UI will return a value of 4.
The usage is subsequently uploaded into the system with a value of 12.31245 GB. Since usage quantity is stored as is, the value 12.31245 is then stored. Any display in the UI or query via the API will return the value of 12.31245. When the invoice is generated, charges are calculated as defined in the following table:
|Recurring Charge||Unit price * transaction quantity = $59.99/seat license * 4 seat licenses||$239.96|
|Usage Charge||Unit price * usage quantity = $1/GB * Round(12.31245 GB)= $1/GB * 12.32 GB )||$12.32|
|Tax item on recurring charge||Charge * tax rate = $239.96 * 0.0775||$18.5969|
|Tax item on usage charge||UCharge * tax rate = $12.32 * 0.0775||$0.9548|
|Invoice Total||Recurring charge + usage charge + total tax = $239.96 + $12.32 + $19.55||$271.83|
Usage quantities (like GB) are not rounded when stored, while transaction quantities (like seat licenses) are rounded when stored. For example, 12.3124 GB is not rounded, while 4.6 seat licenses are stored as 4 seat licenses. Individual tax items are not rounded. When they are aggregated (added together) for a total tax they are then rounded.