A price of 7,903 in a skin-data feed may mean 79.03 currency units, not 7,903. If another interface expresses the amount as 79.03, comparing the two raw numbers creates a hundredfold error before you have evaluated the item, fees or availability.
The unit belongs to the field, not to the marketplace's name. Two interfaces from the same provider can encode money differently. Normalize documented units first, then check whether the normalized amounts describe the same kind of price.
The normalization path removes encoding errors while preserving genuine differences between asks, references and completed sales.
One provider can use two representations
Skinport's live-feed documentation specifies cents, unlike its REST responses. Its Items schema shows decimal price fields and a currency code. These are interface conventions, not evidence of a huge difference in what an item costs.
Here is a hypothetical normalization exercise. It deliberately uses equal numeric amounts to demonstrate representation; it does not claim the two records describe one real item or completed sale.
| Input | Documented unit in this example | Normalized amount |
|---|---|---|
| REST decimal: 79.03 | Currency units | 79.03 EUR |
| Feed integer: 7903 | Hundredths of the currency unit | 79.03 EUR |
| Incorrect raw comparison | 7903 ÷ 79.03 | 100, caused by encoding |
A normalized record should retain the original field name, raw value, currency and applied scale. If the result later looks suspicious, you can trace the conversion rather than wondering whether the source itself supplied the wrong price.
Equal amounts can still describe different things
Correcting units does not complete the comparison. A lowest current asking price, a historical sale amount and a suggested reference can all normalize to 79.03. That coincidence does not make them the same observation.
Keep a price-type label alongside the number: ask, completed sale, reference or another documented measure. Preserve the item identity and observation time too. An aggregate catalogue row cannot be treated as an individually inspected offer merely because its numeric representation matches a feed event.
The catalogue-data guide explains that grouped-versus-individual distinction. Use normalization to remove an encoding difference, while leaving genuine differences in meaning visible. Otherwise a technically tidy spreadsheet can still compare incompatible evidence.
Never infer the scale from the size of the number
A large integer may be a real expensive price, an encoded ordinary price, a quantity or an identifier. Dividing everything above a chosen threshold by 100 will damage some valid data while appearing to fix other rows.
Read the relevant field definition. For another documented convention, CS Deals' API overview identifies integer prices in cents. That does not establish the representation used by an unrelated provider or every future interface version.
Retain a unit rule per source and field. If a schema changes, update that rule and record when it changed. A jump that affects every item by nearly the same factor is a reason to investigate scaling, but it is not enough to decide the correct conversion without documentation.
Formatting adds another source of confusion during import. A decimal comma and a thousands separator can produce similar-looking text with very different numeric meanings. Preserve the source format when reading a file and inspect one converted cell manually. Removing punctuation from every price is not normalization: text representing 79.03 could become 7903 even when the source already expressed full currency units. A successful spreadsheet import is not proof that its numeric interpretation was correct.
Keep quantities out of the money conversion
Suppose a hypothetical record lists three copies at 1,250 cents each. The unit amount is 12.50; the three-copy subtotal is 37.50. Dividing the quantity by 100 as well would shrink the result a second time.
Also establish whether a supplied amount is per copy or already the total for a row. Multiplying an existing three-copy total by three creates a different error. The labels “price,” “amount” and “value” are not universal definitions. The source's schema decides what each one means.
For an inventory, preserve the quantity of each matched group and the count of individually identified items. Repeated names may represent several owned copies, while repeated observations of one listing represent a data-collection problem. Units cannot resolve identity or duplicate records on their own.
Choose and document where rounding happens
A unit conversion that divides integer hundredths by 100 is exact at two decimal places. Later operations, such as an explicitly assumed currency conversion, can introduce additional precision. Avoid repeatedly rounding intermediate results without recording the rule.
For example, imagine three converted unit amounts of 1.234. Rounding each to 1.23 and then adding gives 3.69. Adding first gives 3.702, which rounds to 3.70. Both results follow a specific rounding policy. Neither establishes how a marketplace must round a real checkout.
Use the actual confirmation amounts to reconcile a transaction. For your own analytical table, choose a consistent policy, preserve enough calculation precision and label the displayed rounding. The net-amount guide handles the separate question of deductions already included in a quote.
A compact check before interpreting a big difference
Compare one record manually from raw input to displayed result. Verify its currency code, scale, per-copy or total basis, quantity and price type. Then repeat with a second row whose amount is quite different. That catches a mistaken rule more reliably than checking only a grand total.
If the unit cannot be established, leave the comparison unresolved. Do not use the more attractive interpretation because it produces a discount. A proper comparison begins when both numbers mean a known amount of the same currency on a known basis. Only then can a difference tell you anything about the market.