What the currency parameter does
A number on its own means nothing. An order value sent to analytics without a currency could be rupees, dollars or pounds, and no reporting tool can guess. The currency parameter is the short code that travels with the value — NPR, AUD, GBP, USD — and it is what turns an amount into money.
Analytics uses it in two ways. It stores the original figure in the currency you declared, and it converts that figure into the property’s own reporting currency using the exchange rate held for the day of the transaction. That is why revenue in a multi-currency shop can shift slightly between the shop’s own records and the analytics report even when every order was tracked correctly.
The parameter belongs on any event carrying a value — product views, basket additions and the purchase event that produces revenue — not only on the sale itself.
Why it matters
Without it, values are commonly discarded rather than assumed. Orders keep appearing in reports, the transaction count looks healthy, and revenue sits empty or wrong. That failure mode is nastier than an obvious break, because everything else on the screen looks fine and nobody investigates until a monthly report has to be explained.
It matters more the moment a business sells across borders. A shop taking rupees at home and dollars abroad, without declaring which is which, produces a revenue total that is neither figure and cannot be reconciled with anything. Anyone selling into Australia, the UK or the Gulf from Nepal meets this problem early.
Where it goes wrong
The most common fault is a hard-coded currency. A developer sets one code when the shop launches, a second market is added later, and every order from that market is recorded in the wrong money at the wrong scale. Nothing errors; the numbers are simply wrong.
Formatting causes the rest. A code sent in lower case, a symbol sent instead of a code, or a value sent with a currency symbol or thousands separator embedded in it will all fail. Sending a currency on the purchase but omitting it from earlier events is another common gap, which leaves basket and product reports without values while the sale looks fine.
How to get it right
Read the currency from the same source your checkout uses when charging the customer, and pass it dynamically on every ecommerce event. Never write the code into a tag as a fixed string, however unlikely a second currency seems today.
Check the code is upper case and the value is a plain number with no symbol, comma or space inside it. Then test properly: if the shop supports more than one currency, place an order in each and confirm the declared code changes with it. Finally, set the analytics property’s reporting currency to the one the business actually thinks in, and tell whoever reads the reports that conversion happens at daily rates, so small differences against the accounts are expected rather than a fault to chase.