The Order That Borrows Its Currency
A purchase order in our system has no currency field. It borrows one from the quotation it was raised against, and where the quotation has none it falls back to your organisation's base currency. A supplier has no currency at all — the column existed once and was removed as unused.
A Singaporean buyer places orders in four currencies before lunch. It is not a complication of the business; it is the business. So the first question worth asking of any purchasing system here is where the currency lives.
In ours it lives on the quotation, and only on the quotation. The order takes it from there. The supplier does not carry one. And the books are kept in one currency that was fixed when the organisation was created.
The chain, precisely
A quotation carries a currency and, alongside it, a snapshot of the financial context at the moment it was raised. When an order is created from that quotation, the order does not copy the currency into a field of its own — it has no such field. Wherever the order needs to display or format a value, it reaches back through the quotation and asks.
The resolution goes in a defined order: the snapshot first, then the quotation's own currency, then the organisation's base currency as a last resort.
A supplier record, meanwhile, holds contact details, addresses, payment rails, preference and blacklist status — and no currency. That is not an oversight in the usual sense: the column was there and a migration removed it, on the grounds that nothing read it.
The currency belongs to the quote, not to the supplier and not to the order. Everything on this page follows from that one decision.
Why that is a defensible design
Worth saying before the consequences, because it is not obviously wrong.
A price is agreed on a quotation. The currency is part of that agreement, along with the amount and the validity. Storing it once, on the document where it was agreed, means it cannot drift — the order cannot say one thing while the quote it came from says another, because there is only one place it is written.
A currency on the supplier would be a standing default, and standing defaults are wrong exactly when it matters: the supplier who normally quotes in one currency and, this once, quoted in another.
And what it costs
| What you want | What happens |
|---|---|
| An order raised without a quotation | Falls back to the organisation's base currency, whatever the supplier actually invoices in |
| A standing currency per supplier | Not available — the supplier record has no currency, and the column was deliberately removed |
| Committed spend by currency | Not directly reportable; each order's currency has to be resolved through its quotation |
| Revaluation of an open order when rates move | Nothing revalues. The figure is what it was |
| Books in more than one currency | One base currency per organisation, fixed at setup |
| A document that shows what was agreed, in the currency it was agreed in | Fully supported, with a financial snapshot at the time |
The last row is the one to hold on to. What this design does well is preserve the agreement. What it does not do is give you a position — an answer to "what am I committed to in US dollars this quarter" that does not involve assembling it yourself.
The specific risk of the fallback
Read the resolution order again and notice the last step. Where nothing supplies a currency, the answer is your base currency.
That is a sensible default in a single-currency business and a hazard in a multi-currency one, because it is silent and plausible. An order that should be in one currency and is displayed in another does not look wrong. It looks like an order. The numbers are the right numbers with the wrong symbol in front of them, and the difference will be discovered by whoever reconciles the supplier invoice — if they are paying attention, and if the two currencies are far enough apart that the total looks odd.
The mitigation is procedural and it is not onerous: raise orders from quotations. The chain is designed to work that way, requisition approval already enforces the discipline upstream, and an order that came from a quote always has a currency somebody stated deliberately.
Five questions about currency in any purchasing system
Where is the currency stored on an order?
A good answer sounds like
A field on the order, or an honest "it is derived".
What it actually means
Derived is fine and it changes how you must work. Ours is derived from the quotation, so the quotation is not optional in practice.
What currency does an order get when nothing supplies one?
A good answer sounds like
A refusal, or a named default.
What it actually means
A silent default to base currency is the failure mode here, and it is the one to test with an actual order rather than a question.
Does a supplier have a default currency?
A good answer sounds like
Yes or no, without hedging.
What it actually means
Ours does not, and the column was removed rather than never written. That is a decision, and it is worth understanding as one.
Show me open commitments by currency.
A good answer sounds like
A report.
What it actually means
If it cannot be produced, your exposure is assembled by hand in a spreadsheet every month for the life of the system.
What happens to an open order when the rate moves?
A good answer sounds like
Nothing, or a revaluation.
What it actually means
Ours is nothing. That is the common answer and it should still be asked, because a vendor claiming otherwise is claiming something substantial.
What AWRA OpsHub does today
- A currency on every quotation, with a snapshot of the financial context at the time it was raised, so an agreed price cannot drift.
- An order that resolves its currency from the quotation it came from, in a defined order, with the organisation's base as a last resort.
- Documents that display and format values in the currency they were agreed in.
- Multiple display currencies, indicative, for reading figures in a familiar unit.
- Supplier payment rails held per vendor — bank details and mobile-money identifiers — so paying in more than one way is supported even though pricing in more than one currency is not held on the supplier.
What it does not do
- A currency field on a purchase order. It has none, and derives one.
- A currency on a supplier. The column existed and was removed as unused.
- A second base currency. One organisation keeps one set of books, fixed at setup.
- Revaluation of open commitments when rates move, or realised and unrealised exchange differences.
- A committed-spend-by-currency report.
Not ours, by choice
- Deriving from the quotation is a real design position and we would argue for it. Its price is that an order raised outside that chain inherits a default rather than a decision.
- The base-currency fallback is the specific risk to manage, and the management is procedural: raise orders from quotations, always.
- Nothing here is Singaporean. It is what a derived currency does; Singapore is where you are most likely to be buying in four currencies at once.
What is not built for Singapore today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Singapore. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If an InvoiceNow access point, a CPF engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
InvoiceNow, Peppol and GST reporting
Sending and receiving structured invoices through a Peppol access point on the InvoiceNow network, invoice data transmitted to IRAS on the schedule your registration date puts you in, and GST returns assembled from the underlying documents rather than from a summary. Worth stating plainly: Peppol is a receiving network as much as a sending one, and the inbound half is the one most implementations leave until last.
PayNow, GIRO and multi-currency banking
PayNow collection matched to the invoice, GIRO files, and multi-currency bank feeds wired into the Payments Register — which is most of the point in a market where the bank account and the operation are usually in different countries.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
CPF contributions by age band and residency status, the Skills Development Levy, IR8A submission and IR21 tax clearance for departing foreign employees, computed on live records rather than assembled at year end.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Raise every order from a quotation and this design does what it should — the price and the currency are recorded once, where they were agreed, and cannot drift apart. Raise orders directly and you are relying on a base-currency fallback that will be wrong silently. If you need an exposure position by currency, plan to assemble it outside the system, and if that is a monthly board requirement rather than a curiosity, tell us before you buy.
Check what your last hundred orders are denominated in
The quickest audit available: list your recent orders, resolve each one's currency, and see how many fell through to base. If the answer is more than none, the fix is a process change rather than a feature.
Run the check with usFrequently asked questions
Can I set a default currency for a supplier?
No. The supplier record has no currency and the column that once existed was removed because nothing read it. The currency is a property of each quotation, which means a supplier who normally quotes in one currency and occasionally in another is handled correctly by construction.
What happens if I edit the quotation after the order exists?
The order resolves its currency through the quotation, so treat a quotation as a record of an agreement rather than a working document. If a price or a currency genuinely changes, the honest thing is a new quotation, which is also what your supplier is doing at their end.
Do we convert foreign-currency purchases into the base currency anywhere?
Values reach the ledger in the organisation's base currency, and there is no revaluation afterwards and no exchange-difference accounting. So the recorded cost is the cost as it was captured, permanently — which is consistent with how the rest of the costing works, and is worth knowing if your rates move materially between order and payment.
