Salary currency period is the smallest unit of a pay record, and it is almost always recorded incompletely. A number is written down, the currency is left to context, and the period is assumed to be whatever the reader expects.
Every one of those omissions is invisible at the point of entry and expensive later. This article covers why the amount alone is meaningless, what the difference between a total package and a base figure actually is, why the currency should be stored as a code rather than a symbol, and what a conversion has to record to be honest.
Why is a number without a currency and a period useless?
Because it can be read in more ways than it can be written. A figure of fifty can mean a monthly amount in one currency, an annual amount in another, and a daily rate in a third, and all three readings are consistent with the data as stored.
The period is the part that gets dropped most often, because the context supplies it silently. Pay is discussed annually in some markets, monthly in others and hourly in others, and each of those conventions assumes itself. When a record moves out of the context it was written in — into a comparison, a filter, an export — the assumption goes with it and is never questioned.
The two halves fail differently. A missing currency makes the amount uninterpretable. A missing period makes it mis-scaled, and a mis-scaled amount is more dangerous than an absent one because it looks like a real figure and sorts into the wrong place. A filter that treats a monthly rate as annual will exclude exactly the candidates it was meant to include, and it will report a plausible result while doing so.
What is the difference between total package and base pay?
They are different quantities that share a name in ordinary speech.
Base pay is the fixed amount exchanged for the work, before anything variable. A total package is base pay plus whatever else the arrangement includes: variable components, allowances, contributions made on the holder’s behalf, and benefits whose value is real but not cash. The two figures can differ substantially, and the difference is a feature of the arrangement rather than an error.
The ambiguity matters because the same word is used for both. When somebody says what they earn, they may be quoting either, and they may not know which. A record that stores a single amount under a bare label therefore cannot say which of the two it represents, and a comparison built on it compares two different quantities without knowing it.
The fix is not to pick one convention and apply it everywhere, because neither is more correct. It is to label which quantity is being recorded, and, where a total is given, to say what it includes. A breakdown is more useful than a single number, and the components of a package are often not additive in the way a reader will assume — some are conditional, some are capped, and some depend on factors outside the arrangement entirely.
Why use a currency code rather than a symbol?
Because symbols are ambiguous and codes are not.
The ambiguity is well known and easy to underestimate. The same symbol is used by several currencies, and a reader resolves it by context that the record itself does not carry. A symbol may also have different conventional meanings in different regions, so that the same glyph signals different things to two readers of the same document. And the symbol generally does not distinguish between the currency as a unit of account and a local variant of it, which can matter.
A code identifies exactly one currency and does so without context. Storing the code alongside the display form gives the reader the familiar glyph and gives the system something unambiguous to compute and compare with. Where the source wrote a symbol, the record should resolve it to a code at the point of entry, while the surrounding context is still available to make the resolution correct — later, that context is gone.
There is one further distinction worth preserving where the source makes it: whether the amount is the currency as written or a converted equivalent. Those are different claims, and merging them destroys the ability to tell a quoted figure from a computed one.
How should a conversion be recorded?
With the date it was made, the rate’s source, and the original figure kept alongside the converted one.
A conversion is an operation, not a fact about the world. It took two amounts that were equal at a particular moment and applied a rate that existed at a particular moment. Without the moment, the converted figure cannot be recomputed, checked or reversed. Without the source of the rate, a reviewer cannot tell whether a difference between two figures is a real difference or a difference between two rate providers.
Three rules follow. Record the date the rate applied to, not the date the conversion was performed. Keep the original amount and currency in the record even after converting, because a conversion is never information-preserving. And never convert for storage as a substitute for storing the currency — conversion is for comparison, and a record that keeps only the converted value has thrown away the thing it was comparing.
Anyone building comparison features should also decide what a comparison means. Comparing converted amounts is a convenience with an error bar, and treating it as exact will produce differences that are artefacts of the rate rather than of the pay.
Is pay information a required part of a record?
It should not be. In most systems pay is optional, and in many it is sensitive enough that treating it as optional is a requirement rather than a preference.
There are good reasons to keep it out of every workflow that does not need it. Pay is often the most sensitive field in a career record, it is the field most likely to be omitted deliberately, and a system that requires it will collect inaccurate values rather than complete ones. Requiring a field that people decline to complete reliably produces placeholder data, and placeholder data in a pay field is worse than an empty one because it is indistinguishable from a real answer.
The practical design is to keep the field optional, to keep it labelled with both halves of its meaning, and to keep the number of places it is displayed small. Where pay is shown, it should be shown with its currency, its period and, where it has been converted, the fact that it has.
For developers: pay fields and safe defaults
Store the amount, the currency code and the period as three fields with no defaults for any of them. A default currency is worse than no currency, because it is silently right often enough to be trusted and wrong exactly when it matters.
Four details prevent most downstream errors. Make the period an enumerated set of values rather than free text, since a period that can be written in six ways cannot be compared with itself. Keep the label that distinguishes a base figure from a total package, and refuse to accept a total without knowing what it contains. Keep original and converted amounts apart, with the rate metadata attached to the conversion rather than to the amount. And treat the whole group as optional, so that a record with no pay information is a complete record.
For test data, the cases worth generating are the ones that catch a careless comparison: the same amount in two currencies, a monthly figure beside an annual one, a converted value whose original has been kept, and a record where the pay section is absent altogether.
The cases worth generating for test data:
- the same amount in two currencies
- a monthly figure beside an annual one
- a converted value whose original has been kept
- a record where the pay section is absent altogether All amounts, currencies and periods appearing in the sample records on this site are demonstration values chosen to exercise these cases, and they describe no real arrangement.
Next steps
Audit one comparison in your product and count how many of the amounts it compares have both a currency code and a period recorded. The number is usually lower than expected. The form branches where a pay field appears are covered in hiring form test cases, and the broader question of how a career record is assembled is set out in career profile test data. The career profile tool generates records whose pay fields can be left empty, which is the case most systems never test.