The quotation screen shows one total, the exported document another and the accounting import a slightly different amount. Staff may start adjusting figures manually, but that hides the point at which the values diverged. The right first question is where the application calculates, rounds and transfers each amount.

For a UAE business building an order or quotation system, agree calculation rules before accepting the software. This is an application-design review; the business’s finance team must approve the applicable accounting and tax treatment.

Concept illustration of calculation reconciliation, not a financial statement, product screenshot or ITZ client project.

Trace one amount from input to output

Choose a harmless sample transaction and record its original quantities, unit amounts, discounts and any approved additional calculations. Follow the values through the screen, server, database, document generator and receiving integration. Compare stored values as well as displayed values.

A display showing two decimal places does not prove the underlying value was stored or calculated with that scale. Likewise, converting a value to text for an export can introduce another transformation. Ask the developer to identify the first point at which the results differ rather than applying a final adjustment to make the examples look equal.

Separate precision from the business rounding rule

The PostgreSQL numeric-type documentation distinguishes exact decimal types from inexact floating-point types and recommends numeric for monetary amounts where exactness is required. It also explains that a declared column scale can round values on storage. That is a database example, not a complete calculation policy for the whole application.

Ask the development team to document the types used across the browser, server and integrations. An exact database column cannot recover precision already lost before a value reaches it. The system also needs agreed limits and error handling for values outside the supported range.

ITZ’s custom software development service can help translate approved finance rules into an application specification. Request an application calculation-rule review with redacted examples of the mismatch and the systems involved.

Approve the stages explicitly

The business owner and finance reviewer should define the sequence of calculations, the precision retained between steps and where rounding occurs. For example, summing individually rounded line amounts can differ from rounding only after summing more precise values. The correct choice must come from the approved business rule, not whichever output happens to match a spreadsheet.

  • Define the currency and supported amount range for each transaction.
  • Document quantity precision separately from the displayed unit price.
  • Specify how discounts and additional amounts are applied and in what order.
  • Agree how reversals and negative adjustments follow the original calculation.
  • Record the expected output format for documents and receiving systems.

Do not use this checklist to select tax rules. Give the developer approved examples and a responsible person who can resolve policy questions.

Build a reconciliation test set

  1. Include a single line, several small lines, fractional quantities and approved discounts.
  2. Include boundary values that sit close to a rounding decision and a negative adjustment.
  3. For each case, have finance approve the expected intermediate and final values.
  4. Compare the application screen, saved record, generated document and exported data.
  5. Repeat after an edit and after an authorised integration retry, confirming that the amount remains explainable.

The data import reconciliation guide supports checks at the receiving system. The concurrent-edit guide addresses a different cause of unexpected values: an older screen overwriting a newer record. Preserve the distinction when investigating.

Review Your Application Calculation Rules

Bring ITZ the approved calculation examples, affected outputs and integration boundaries. We can discuss precision, rounding stages and a traceable acceptance test. Review Your Application Calculation Rules using the contextual form below.

Primary documentation reviewed on 31 October 2026. Examples describe proposed checks, not client case studies.