NetSuite Insights & Guides | CuriousRubik

Foreign-Currency Tax Invoices: SGD Checks in NetSuite

Written by Natasha | May 30, 2026, 4:00:00 PM

Review the document your customer receives, together with the calculation behind it.

Validate the issued tax invoice in its final customer-facing form. For a Singapore sale invoiced in foreign currency, checking the transaction's exchange-rate field alone will not establish that the required SGD amounts appear correctly on the document.

IRAS requires a foreign-currency tax invoice to show SGD totals excluding GST, GST payable and the total including GST, converted using an approved exchange-rate source. Your review therefore needs the invoice calculation, the applicable conversion policy and the generated output. Keep the accounting conversion and any group-reporting translation identifiable as separate purposes.

The following worked example concerns a standard-rated sales tax invoice. Other invoice types and tax treatments need their own approved expectations. It does not establish the correct treatment of an actual sale.

Write the expected answer before opening the template

Consider an illustrative Singapore supplier issuing a USD tax invoice for a standard-rated sale. Every value and exchange rate below is synthetic. The selected test rate is not current market data or evidence of an approved production rate source.

The test inputs are:

  • Sale before GST: USD 10,000.
  • GST at the assumed standard rate of 9%: USD 900.
  • Amount including GST: USD 10,900.
  • Tax-invoice conversion input: SGD 1.36 per USD.

The expected SGD presentation is:

Invoice componentUSD amountTest conversionExpected SGD amount
Before GST10,000.0010,000 × 1.3613,600.00
GST900.00900 × 1.361,224.00
Including GST10,900.0010,900 × 1.3614,824.00

The arithmetic checks in both currencies: USD 10,000 plus USD 900 equals USD 10,900; SGD 13,600 plus SGD 1,224 equals SGD 14,824. State the rate direction in full. “1.36” without units leaves room for an inverted conversion.

Have the tax reviewer approve the expected document treatment before the implementation team changes the template. Otherwise, a technically accurate template can faithfully reproduce an unapproved business assumption.

The example uses a synthetic SGD 1.36 per USD rate solely to test the document calculation.

Check the invoice in the form that is actually issued

Generate the document through the intended production workflow in a suitable test environment. Review the PDF, print layout or other customer-facing version the business will issue. If several output formats are used, test each applicable format rather than assuming they share every field and calculation.

Inspect the currency labels next to the amounts. The reader should be able to distinguish the USD commercial totals from the SGD tax presentation. Check that line descriptions, supplier and customer details, invoice number, invoice date and relevant tax information remain legible after the SGD section is added.

For the applicable tax-invoice type, review the full required information with the tax owner. A correct SGD tax amount does not cure a missing supplier GST registration number or an incorrectly identified customer. Likewise, a familiar document layout is not evidence that the current fields are correctly populated.

Retain the generated document as test evidence. A screen capture of an editable transaction does not show whether the final template hides a field, uses the wrong label or truncates a number.

Distinguish three reasons to convert currency

The transaction may have an accounting exchange rate that serves the books. The tax invoice has a conversion policy governed by the applicable GST requirements. A regional group may also translate subsidiary results for consolidation.

For an additional illustrative comparison, suppose the book-conversion input is SGD 1.34 per USD. Applying that rate to USD 900 produces SGD 1,206, which is SGD 18 below the test invoice's SGD 1,224 GST. That difference is a diagnostic prompt. The controller must determine the appropriate accounting and tax-reporting treatment; it should not be hidden by changing the invoice without an approved basis.

Oracle's OneWorld documentation describes consolidated exchange rates for supported consolidated reporting. That does not make the group's reporting rate the correct rate for an individual Singapore tax invoice. The test pack should identify which rate serves which purpose and who approves it.

Keep the source, rate date, rate direction and policy version with the calculation evidence. In production, the tax owner should confirm the approved source and applicable consistency and update requirements. A manually typed rate with no trace to policy is difficult to review later, even when today's calculation is correct.

Establish which NetSuite components produce the output

Oracle's Singapore Localization SuiteApp documents localised invoice and credit-note templates, including support for non-SGD invoicing. The documented SuiteApp requires SuiteTax and Tax Reporting Framework. Verify the actual account's tax engine, installed SuiteApps, templates and permissions before treating this as the implemented route.

An account using a different tax setup may need different documented configuration. Do not transplant instructions from a SuiteTax-based setup into a legacy-tax account without checking applicability. Equally, a custom PDF template should be identified as maintained custom work, with its data sources and owner recorded.

Ask the implementation team to show where each displayed amount originates. Is the SGD tax figure stored, calculated by the supported tax process or calculated in a template? Who can alter that logic? What happens when an invoice is regenerated after a template update?

These are acceptance questions, not instructions to override tax fields or modify posted transactions. Any proposed adjustment needs review through the account's supported configuration and accounting controls.

Test the variations likely to break the first successful example

A successful simple invoice should be followed by the cases that challenge your actual billing process.

Select variations from the business's real requirements:

  1. Fractional amounts. Test values that exercise the approved rounding policy. Compare line and document calculations, recording any explained rounding difference rather than requiring an unsupported adjustment.
  2. Discounts. Confirm the approved tax base and the displayed net, tax and gross totals for the supported discount configuration.
  3. Credit notes. Review the relevant document rules, original-invoice relationship and supported output separately. Do not assume reversing a sign produces an adequate credit note.
  4. More than one output template. Repeat the checks for each active customer, subsidiary or language-specific layout used by the business.
  5. Rate-policy or template change. Verify how new documents use the approved change and how previously issued evidence remains understandable and retrievable.

For each variation, retain the test input, expected calculation, generated output, reviewer decision and unresolved issue. Assign a billing owner to presentation problems, a tax owner to treatment questions and a configuration owner to the technical remedy.

Settlement creates its own currency questions after the invoice is issued; the foreign-currency settlement guide covers that separate stage. For this validation, the finish line is narrower: a reviewer can read the issued invoice, reproduce its SGD presentation and identify the approved source and policy behind every relevant amount.