Understanding Rounding in Nue

nue applies consistent rounding rules across the entire quote to revenue workflow — from the quote and order line editor through billing, invoicing, and downstream integrations such as rightrev this page explains how rounding works, which fields are rounded, and why core principle round only at the final stage nue follows a single governing principle for rounding round only displayed or persisted totals used for reporting, invoicing, or payment do not round intermediate or per unit values used in calculations, rollups, or chained discounts this means intermediate fields (e g , total price, subtotal, sales price, net sales price, discount amount) maintain full calculation precision throughout the pricing engine final customer facing fields (e g , total amount, total amount without tax) are rounded to the currency's smallest unit — typically 2 decimal places for usd, eur, and most currencies by deferring rounding to the last possible step, nue prevents compounding rounding errors that can cause penny discrepancies between quotes, orders, invoices, and downstream systems rounding mode all rounding in nue uses half up (also known as "round half up" or "commercial rounding") if the digit being dropped is less than 5 , round down if the digit being dropped is 5 or greater , round up raw value rounded (2 decimals) 10 254 10 25 10 255 10 26 10 2551 10 26 99 9949 99 99 99 995 100 00 this is the standard rounding mode used across financial systems and is consistent with java's roundingmode half up which fields are rounded line level fields (quote line item / order product) field rounded? rationale total amount yes final customer facing value appears on order forms, invoices, and integrations total amount without tax yes final customer facing value used for revenue recognition and erp integrations tax amount yes tax engine returns values rounded to 2 decimal places total price no used for arr, acv, and other financial metric calculations full precision prevents calculation drift subtotal no intermediate value computed from price tags and discount tags sales price no intermediate value subtotal / quantity / subscription term net sales price no intermediate value total price / quantity / subscription term discount amount no intermediate value rounding here would skew extended totals discount percentage no intermediate value rounding here would skew extended totals list price no source value from price book entry unit price no intermediate calculation value delta arr no financial reporting metric maintains full precision delta cmrr no financial reporting metric maintains full precision delta acv no financial reporting metric maintains full precision delta tcv no financial reporting metric maintains full precision header level fields (quote / order) field rounded? rationale total amount yes sum of rounded line level total amounts always equals the sum of its line items total amount without tax yes sum of rounded line level total amounts without tax subtotal no rolled up from line level subtotals discount amount no rolled up from line level discount amounts total price no rolled up from line level total prices important the header level total amount is the sum of the rounded line level total amounts from regular and ramp line items — it is not rounded independently summary lines and other non aggregating line types are excluded from the rollup this ensures the header always reconciles exactly with the line items shown in the price summary panel how rounding flows through the system step 1 pricing engine calculation the pricing engine computes all fields at full precision (up to 17 significant digits) no rounding is applied during calculation step 2 tax calculation the total price (full precision) is sent to the tax engine the tax engine returns a tax amount already rounded to 2 decimal places step 3 total amount calculation depending on the tax mode tax exclusive mode total amount = round(total price, 2, half up) + tax amount total amount without tax = round(total price, 2, half up) tax inclusive mode total amount = round(total price, 2, half up) total amount without tax = round(total price, 2, half up) − tax amount step 4 order product storage the following values are stored on the order product total price full precision (up to 17 digits), not rounded tax amount already rounded to 2 decimals from the tax engine total amount rounded to 2 decimals (computed in step 3) total amount without tax rounded to 2 decimals (computed in step 3) step 5 invoice generation (billing) billing accepts the total price (full precision) and total amount without tax (rounded, 2 decimals) from the order product the transaction amount on each invoice item is computed from the full precision total price (for proration and splitting accuracy) the transaction amount without tax on each invoice item is rounded to 2 decimal places using half up on the final invoice of a billing schedule, nue applies a penny perfect adjustment the last invoice amount is calculated as total amount without tax − sum(all previous invoice amounts) this guarantees that the total invoiced amount exactly equals the order product's total amount without tax — with zero discrepancy step 6 downstream integrations all integration exports (e g , rightrev, netsuite, erp systems) use the rounded total amount without tax from the order product this ensures order product total amount = sum of all invoice transaction amounts no precision mismatches at integration boundaries worked example a customer creates an order with 3 products using tax exclusive pricing two of the products have prorated terms, resulting in fractional total price values product scenario total price (full precision) crm platform $1,000/year prorated for 4 months $333 3333333333 api access $500/year prorated for 7 months $291 6666666667 support package $250/year, full 12 month term $250 00 line level rounding (tax exclusive, no tax) product total price (stored) round(total price, 2) tax total amount crm platform $333 3333333333 $333 33 $0 00 $333 33 api access $291 6666666667 $291 67 $0 00 $291 67 support package $250 00 $250 00 $0 00 $250 00 header level rollup field value total price $875 00 (sum of full precision line values $333 333… + $291 666… + $250 00) total amount $875 00 (sum of rounded line values $333 33 + $291 67 + $250 00) in this case the two values happen to match however, with many line items, rounding each line independently can cause the sum of rounded lines to diverge from a rounded sum by a penny or more nue always uses the sum of rounded lines approach because it guarantees the header exactly equals the sum of its line items — which is critical for invoice reconciliation currency aware rounding nue rounds currency values to the smallest unit defined by the currency's iso 4217 standard currency code decimal places example us dollar usd 2 $1,234 57 euro eur 2 €1,234 57 japanese yen jpy 0 ¥1,235 kuwaiti dinar kwd 3 kd 1,234 568 (future) note nue currently supports rounding to 2 decimal places for standard currencies and 0 decimal places for zero decimal currencies like jpy support for 3 decimal currencies (e g , kwd, bhd) is planned for a future release self service consistency the same rounding rules apply to self service (api driven) orders total amount and total amount without tax are rounded to 2 decimal places using half up all other financial fields (total price, delta arr, delta cmrr, etc ) maintain full precision self service and salesforce originated orders produce identical rounded values for the same pricing inputs display vs storage nue distinguishes between how values are stored and how they are displayed aspect behavior storage full precision is maintained for intermediate fields only total amount and total amount without tax are stored rounded display all currency values in the line editor, order forms, and pdfs display rounded to the currency's decimal places (e g , 2 for usd) for example, a total price of $8,333 3333333333 is stored with full precision but displayed as $8,333 33 in the line editor this ensures calculations using total price remain accurate while the user interface shows clean, rounded values price builder plugins and rounding if your organization previously deployed a custom rounding plugin via price builder to handle rounding, you should evaluate whether it is still needed nue's built in rounding (available since release 2601) covers the standard rounding behavior described on this page a custom rounding plugin may conflict with nue's built in rounding and produce unexpected results — such as double rounding or overriding values that nue has already rounded if you are experiencing rounding discrepancies and have a custom rounding plugin deployed, we recommend review the plugin logic to confirm it does not duplicate nue's built in rounding test with the plugin deactivated in a sandbox environment to verify that nue's native rounding meets your requirements if the plugin provides custom behavior beyond standard rounding (e g , rounding to the nearest $5 or applying ceiling/floor logic), ensure it operates on the correct fields and does not conflict with total amount or total amount without tax calculations frequently asked questions q why is total price not rounded? total price is used as the basis for financial metric calculations such as arr, acv, cmrr, and tcv rounding total price would introduce drift in these metrics for example, consider a clean $100,000/year deal cmrr = $100,000 / 12 = $8,333 3333… per month if cmrr were computed from a rounded value, it would be $8,333 33, and arr = $8,333 33 × 12 = $99,999 96 — a $0 04 discrepancy on a simple deal by keeping total price at full precision, nue ensures arr reports exactly $100,000 00 q why might the header total amount differ slightly from a rounded total price? the header total amount is the sum of individually rounded line level total amounts in most cases this equals the rounded header total price, but with many line items, small per line rounding differences can accumulate nue always uses the sum of rounded lines approach because it guarantees the header exactly equals the sum of its line items — which is critical for invoice reconciliation q what about subscription term — is it rounded? the subscription term field displays rounded to 2 decimal places in the line editor for readability, but the full precision value is used in all calculations when you click into the field, the full value is shown q how does nue handle rounding for change orders? change orders (add, reduce, cancel, renew, upgrade, downgrade) follow the same rounding rules proration calculations maintain full precision, and only the final total amount and total amount without tax on the change order product are rounded to 2 decimal places q do i need to migrate historical data? orders created before release 2601 may have unrounded total amount values stored in salesforce contact your nue account team or support for guidance on correcting historical data available since release 2601 (february 2026)