A currency-aware approval test starts with a written policy.
An SGD approval limit needs an explicit conversion rule before it can reliably govern a USD purchase order. Define the amount being tested, the exchange-rate source, the date used and the treatment of amendments. Then prove the boundaries in the configured NetSuite workflow. A successful approval of one ordinary order leaves the most important questions unanswered.
For a Singapore purchasing team buying overseas, the difficult case is often an order whose commercial value barely changes while its SGD approval value crosses a limit. Finance needs to know whether that change sends the order to the correct person and whether the evidence explains why.
Consider this original illustrative policy for a fictional Singapore distributor. All amounts, rates and thresholds below are invented for testing. They are neither market exchange rates nor recommended approval limits.
The procurement manager may approve an order with an approval value of up to and including SGD 13,000. A finance director must approve a higher value. The approval value is the merchandise subtotal after discounts, excluding tax and freight. That amount definition is a deliberate assumption; a real company might include more of its committed spend.
The policy uses SGD per USD, multiplies the USD subtotal by that rate, and rounds the result to two decimal places before comparing it with the limit. The rate is the approved transaction rate captured at submission. Changing the subtotal, currency, rate or transaction date invalidates the prior approval and requires resubmission. On resubmission, the workflow evaluates the current approved inputs.
Finance must approve those choices before testing. Otherwise, a tester cannot tell whether an unexpected result is a software defect or an unresolved policy question. Also define who may override a rate and how the approver sees that override.
At an illustrative rate of SGD 1.3000 per USD, the initial boundary cases are:
Now reuse PO-B in three separate copies of the test case rather than editing the same record repeatedly without a reset.
These are expected results under the proposed policy, not claims about NetSuite's default routing. Record the actual result beside each case after running the account's configured workflow.
Oracle documents that transaction exchange-rate defaults depend on the entity currency and transaction date, with permitted overrides in relevant circumstances. That explains an input to a transaction. It does not establish which amount or currency a particular approval workflow evaluates.
Ask the administrator to identify the approval mechanism actually in use: the configured workflow, relevant purchased capability, any scripts, and any additional fields used by the rule. A procurement capability described in product material does not prove that this account implements the sample SGD policy.
The evidence should show the exact field supplying the approval value. A workflow comparing the raw USD amount with an SGD threshold could produce a plausible approval screen while enforcing the wrong policy. Likewise, a displayed SGD conversion can differ from the amount used in routing if a separate field was captured earlier.
For tax purposes, foreign-currency invoices may require a separately governed SGD conversion. Keep the approval-policy rate distinct from GST conversion rules. Reusing one exchange-rate field for every purpose needs explicit validation rather than a convenient assumption.
The most useful amendment test begins with a genuinely approved record. Record the approving role, approval timestamp and exact financial inputs. Then change only one controlled input and inspect the outcome.
Look beyond the visible status label. Check whether the former approver can still release the changed order, whether the new approver sees the amended amount, and whether the supplier-facing version contains the same currency and subtotal that were approved. Include any integration or import route the business actually uses; a form-only test cannot establish the behavior of another entry path.
A rate change that moves the order below the threshold also deserves a case. Should it return to the manager, remain with the director, or require a fresh submission before either acts? The illustrative policy requires resubmission, but the business must decide the authority rule. Do not leave it to whichever status happens to survive the edit.
Run a separate permission test for an unauthorized rate override. A correct calculation is insufficient if a requester can alter the rate specifically to avoid escalation.
Use one evidence row per test, containing the policy version, record identifier, entry path, transaction currency, subtotal, rate units, rate date, calculated SGD value, expected approver and actual approver. Add the saved record state before and after the amendment, plus the person who reviewed the result.
Classify a failure precisely. “Wrong approver” could mean the threshold operator is incorrect, rounding occurs in a different sequence, the workflow uses an old conversion, or the approval was never invalidated. Repair the responsible rule and rerun both the failed case and neighboring boundaries.
Procurement owns the commercial amount definition. Finance owns approval authority and the conversion policy. The NetSuite administrator owns implementation evidence. An independent business tester confirms that the actual route matches the signed rule. Combining those responsibilities into one unreviewed configuration change weakens the test.
Before accepting the workflow, require all six sample cases to have actual outcomes and explain every difference. Keep unresolved cases out of production use or apply an explicitly approved manual review. Bring the completed boundary pack to a NetSuite implementation review; it turns “multi-currency approvals” into a specific, testable requirement.