Portal Approval Thresholds: Route the Exact Amount, Currency, and Request Version

A purchase request appears below a manager’s approval limit, so the portal routes it to that manager. Before approval, someone adds delivery charges and changes the currency. The visible screen updates, but the routing decision still reflects the old total. The manager approves a request that the current policy would have sent elsewhere.

Approval thresholds are more than a comparison between two numbers. The workflow needs an agreed amount definition, currency handling, boundary rules, policy version, and request version. This article focuses on software design for those rules. The organization must decide its own authority limits and accounting policy; the portal should make those decisions explicit and reproducible.

Define the amount the threshold evaluates

Write down whether the routing amount includes tax, delivery, discounts, recurring charges, and optional items. A label such as “total” is insufficient when different teams use it differently. Include the relevant basis on the approval screen so reviewers know what they are evaluating.

For a hypothetical equipment request, the policy might route on the final requested commitment including delivery and tax. Another workflow might use a pre-tax amount. Either can be implemented, but the portal must not mix them across the form, API, and approval engine.

Describe how changes to quantities or line items affect the total. Recalculate on the server using trusted rules and compare against the approved version. A browser-supplied total can be useful for display, but it should not be the sole authority for routing a consequential request.

Use an exact representation and explicit rounding

Choose a representation appropriate to the values and operations. PostgreSQL documents numeric and decimal as exact numeric types, while floating-point types are inexact. An exact decimal representation or a carefully defined integer-unit model can support threshold comparisons without relying on approximate binary arithmetic.

Specify precision and rounding at the boundaries where they matter. Decide whether line items are rounded before summation or only the final amount is rounded. If a displayed total is rounded differently from the routing total, a reviewer can see an apparently inexplicable decision near a threshold.

Do not assume every currency has the same minor-unit behavior. Store the currency code with the amount and use the organization’s approved currency rules. Parsing a formatted string such as “1,250.00” without locale context can also produce errors. Keep input interpretation separate from the normalized value used for routing.

Decide how different currencies reach a comparable basis

A threshold defined in one currency cannot be compared directly with a request in another. The policy may maintain separate limits per currency or convert to a defined reference currency. Record which approach applies rather than letting the implementation choose an exchange rate opportunistically.

If conversion is used, preserve the original amount, original currency, rate source, rate value, effective time, and converted decision amount. Define whether the rate is fixed at submission, refreshed at approval, or handled through another approved rule. A later rate change should not silently rewrite the explanation for an earlier routing decision.

Show the reviewer the basis in plain language. For example, display the request currency and the reference amount used for routing, with the applicable rate date. If rate data is unavailable or stale under the policy, place the request in an explicit exception state rather than guessing a value that lets it proceed.

Make boundaries and fallback routes unambiguous

Write threshold rules using exact comparisons. Does a manager approve amounts strictly below a limit, or amounts up to and including it? Test the value immediately below, exactly at, and immediately above the boundary using the supported precision. These cases should have documented expected routes.

Ensure every valid request has a destination. Gaps between ranges, overlapping rules, missing department owners, and inactive approvers can leave work stranded. Define rule precedence and an exception queue owned by a real team. A request with no matching approver should not default to automatic approval.

Consider whether multiple approvals are sequential or parallel and what constitutes completion. If both departmental and specialist approval are required, record each decision separately. One approver’s action should not accidentally satisfy a different requirement merely because both roles belong to the same person.

Bind approval to the reviewed request version

An approval should identify the exact request version and policy evaluation that the reviewer saw. Record the decision amount, currency basis, relevant line items or immutable version reference, and the approval rule applied. This gives later reviewers a clear explanation of why the route was valid at the time.

When a meaningful field changes, reevaluate the route and invalidate or supersede affected approvals according to policy. Do not rely on a visual refresh alone. A stale browser tab can submit an approval after another person changes the request, so the server must detect the version mismatch.

Explain the result to the user: “This request changed while you were reviewing it. Review the updated version.” Preserve the previous approval event as history rather than deleting it. The new version can show which decisions still apply, if any, under the organization’s explicit rules.

Review delegation and exceptional decisions

Temporary delegation should carry the appropriate scope, dates, and authority limits. A substitute approver should not inherit unlimited authority simply because the original person is absent. Evaluate the active delegation when the decision is made and record its reference with the approval.

If the organization permits exceptions, implement a distinct exception process with an authorized role and a reason. Avoid a generic administrator toggle that changes the outcome without evidence. The operational team should be able to explain which rule was overridden and who was authorized to do so.

Keep approval controls separate from payment or execution controls. Approval of a request does not necessarily mean an external purchase was placed or a transfer occurred. Show those later states accurately and recheck any conditions the business requires before execution.

Use automation to explain, then verify deterministically

AI can help draft a plain-language explanation of a routing decision from structured facts. It can also suggest test scenarios for boundary values, changed currencies, and absent approvers. It should not invent authority limits or decide which comparison operator the organization intended.

Calculate the route with deterministic rules and retain the input snapshot. If an AI explanation disagrees with that result, correct the explanation rather than treating the generated text as the decision record. Avoid exposing sensitive request details to an assistant that the reviewer is not authorized to use.

Before release, run a matrix covering exact thresholds, adjustments after submission, stale approval tabs, rate changes, missing rates, and expired delegations. Compare the displayed amount, routing amount, assigned reviewers, and recorded approval version in every case. This is where small numerical ambiguities become visible workflow defects.

Conclusion

Reliable threshold approvals connect a defined amount and currency basis to an exact request version and an authorized decision. Specify rounding, boundaries, conversions, and change handling before building the approval screen. Clear evidence and deterministic routing let the portal explain why a request went to a particular reviewer and what that reviewer actually approved.