Skip to main content
Solved

IFS Cloud – Invoice Rounding vs Unit Price

  • March 12, 2026
  • 3 replies
  • 44 views

MelKing
Sidekick (Customer)
Forum|alt.badge.img+4

Looking for advice

We’re starting to see rounding discrepancies on invoices where the line total does not match the displayed unit price × quantity, which is beginning to create issues with customs documentation.

Example:

Stored unit price: 3.46343412
Qty: 50

IFS calculates:
3.46343412 × 50 = 173.171706 → 173.17

However the invoice displays the unit price as 3.46, so a manual calculation shows:

3.46 × 50 = 173.00

Our client is encountering issues when very large quantities are involved, as small rounding differences become magnified in the final totals.

Is this the expected behavior in IFS Cloud for invoice calculations?
Has anyone found a configuration or best practice to avoid these mismatches, especially where customs documentation expects totals to match the displayed unit price?

Best answer by jbush0419

Hi MelKing,

This is expected behavior in IFS Cloud, and it's actually by design... though I completely understand the frustration, especially for customs documentation.

What's happening under the hood: IFS stores the sale unit price at full precision in the database (all 8 decimal places in your example: 3.46343412). The IFS Cloud UI displays this rounded to 2 decimals based on the currency rounding configuration, so you see 3.46. However, when IFS calculates the invoice line total, it multiplies the full-precision stored price × quantity first, then rounds the result to the currency's decimal places. So the calculation is:

3.46343412 × 50 = 173.171706 → rounded to 173.17

Not: 3.46 × 50 = 173.00

This approach is actually more mathematically accurate for the actual agreed price — it avoids accumulating rounding errors at the unit level. The PL/SQL in CustomerOrderInvItem even has a code comment stating that rounding must happen after the line-level calculation, not at the unit price level.

Where to look for configuration: The currency rounding is defined per currency code per company in Currency Codes (page: CurrencyCodes/List). This controls how many decimals amounts are rounded to.

Practical approaches for the customs documentation issue:

  1. Invoice Rounding Line — IFS supports an automatic rounding adjustment line (item 100001 in UBL invoices) that can reconcile small differences. This is configured at the company level for invoice information per currency. Check Invoice Information per Currency (page: InvoiceInformationPerCurrency/List).
  2. Custom report layout — If the printed invoice needs to show the displayed unit price × qty = line total for customs purposes, you could create a custom report layout that rounds the unit price first, then calculates the extended amount. This would be a presentation-layer change only.
  3. Review the source of the pricing — If the original price agreement or sales price list is generating prices with many decimal places (e.g., from a percentage offset or currency conversion), you can configure Rounding on the sales price list lines to limit the precision before the price reaches the order/invoice.

The core principle is: IFS prioritizes precision in the calculation and rounds at the line total level, which can create a visible mismatch against the displayed (rounded) unit price.

Hope that helps

 

-jason

3 replies

jbush0419
Do Gooder (Customer)
Forum|alt.badge.img+3
  • Do Gooder (Customer)
  • Answer
  • March 12, 2026

Hi MelKing,

This is expected behavior in IFS Cloud, and it's actually by design... though I completely understand the frustration, especially for customs documentation.

What's happening under the hood: IFS stores the sale unit price at full precision in the database (all 8 decimal places in your example: 3.46343412). The IFS Cloud UI displays this rounded to 2 decimals based on the currency rounding configuration, so you see 3.46. However, when IFS calculates the invoice line total, it multiplies the full-precision stored price × quantity first, then rounds the result to the currency's decimal places. So the calculation is:

3.46343412 × 50 = 173.171706 → rounded to 173.17

Not: 3.46 × 50 = 173.00

This approach is actually more mathematically accurate for the actual agreed price — it avoids accumulating rounding errors at the unit level. The PL/SQL in CustomerOrderInvItem even has a code comment stating that rounding must happen after the line-level calculation, not at the unit price level.

Where to look for configuration: The currency rounding is defined per currency code per company in Currency Codes (page: CurrencyCodes/List). This controls how many decimals amounts are rounded to.

Practical approaches for the customs documentation issue:

  1. Invoice Rounding Line — IFS supports an automatic rounding adjustment line (item 100001 in UBL invoices) that can reconcile small differences. This is configured at the company level for invoice information per currency. Check Invoice Information per Currency (page: InvoiceInformationPerCurrency/List).
  2. Custom report layout — If the printed invoice needs to show the displayed unit price × qty = line total for customs purposes, you could create a custom report layout that rounds the unit price first, then calculates the extended amount. This would be a presentation-layer change only.
  3. Review the source of the pricing — If the original price agreement or sales price list is generating prices with many decimal places (e.g., from a percentage offset or currency conversion), you can configure Rounding on the sales price list lines to limit the precision before the price reaches the order/invoice.

The core principle is: IFS prioritizes precision in the calculation and rounds at the line total level, which can create a visible mismatch against the displayed (rounded) unit price.

Hope that helps

 

-jason


Forum|alt.badge.img+4
  • Do Gooder (Partner)
  • March 12, 2026

My first question in such case is always “why are the prices stored with that precision?”.

Maybe rounding the prices is the simplest solution?


MelKing
Sidekick (Customer)
Forum|alt.badge.img+4
  • Author
  • Sidekick (Customer)
  • March 13, 2026

Thank you both for your great replies - appreciate the insight!