Why a Barcode Label Shows the Wrong Price Amount - and How to Fix It

LabelCraft - barcode labels for Shopify that print at exactly the size you set.

EN · FR · DE · ES
The guarantees behind every label
Exact to ±0.1 mm

Every label prints at the size you set - measured, not approximate.

Never a silent failure

Overflow or a missing barcode always raises a visible warning before you print.

Whole-dot barcodes

Modules snap to your printer's dots, so codes stay crisp and scan first time.

Your barcodes, untouched

We never overwrite or reassign a product's existing barcode.

You printed a batch of price labels and the amount is off - a 10.99 that should be a whole-yen price came out at the wrong magnitude, or the price encoded in a GS1-128 barcode scans back wrong at the till. This is almost always a currency magnitude mismatch, and it is one of the few ways a label can quietly lie. Here is exactly why it happens and how LabelCraft stops it before you spend a roll.

The short answer

Every currency has a fixed number of minor units - decimal places. Most use 2 (10.99 = 10 units and 99 cents). A handful use 0: in Japanese yen, Korean won and a few others, 10.99 is not a valid amount at all, because the currency has no sub-unit. Enter a two-decimal price for a zero-decimal currency and the magnitude is wrong. LabelCraft flags this before you print rather than letting the wrong number reach the label.

Why the amount comes out wrong

LabelCraft can embed the price into a GS1-128 barcode using the price application identifier, where the number of decimal places is part of the encoding. Enter 10.99 for a currency with no minor units and the encoded amount cannot represent what you typed - the label shows the wrong magnitude and a scanner reads back a value you never intended. The regular price is what gets embedded in that GS1 amount field; a struck compare-at was price is text-only and is never embedded in a barcode.

Which currencies have no decimal places

LabelCraft treats these currencies as zero-decimal - whole-number amounts only. Enter them with no decimal point:

Every other supported currency uses 2 decimal places. For a currency LabelCraft has no verified minor-unit data for, it stays quiet rather than guess - it never raises a false alarm on a currency it cannot judge.

What counts as a real error - and what does not

LabelCraft warns only on a genuine magnitude error, never on a harmlessly-formatted amount:

How to fix it

  1. Check the currency of the price you are printing and whether it uses decimals.
  2. For a zero-decimal currency (JPY, KRW, CLP, VND, ISK), enter the amount as a whole number - 1099, not 10.99.
  3. Re-open the print preview. The pre-flight check clears once the decimals match the currency.
  4. Print. The label and any embedded GS1 amount now show the correct magnitude, to ±0.1 mm on the label size you picked.

Frequently asked

Why does 10.99 work for dollars but not for yen?

The US dollar has 2 minor units (cents) and the Japanese yen has none. 10.99 is 10 dollars and 99 cents, a real amount; but yen has no sub-unit, so 10.99 yen is not a value the currency can represent, and printing it distorts the magnitude.

Will trailing zeros like 1000.00 trigger a warning?

No. LabelCraft flags only decimals that actually change the amount. 1000.00 in yen rounds cleanly to 1000, so it is left alone - warning there would be a false alarm that erodes trust.

Does this affect the barcode as well as the printed price?

Yes for a regular price, which LabelCraft can embed in a GS1-128 amount field where the decimal count is part of the encoding. A compare-at was price is text-only and never encoded, so it is checked for the printed magnitude but carries no barcode clause.

Install free - 200 labels per month →

Printing prices on your labels? See price tag labels for Shopify and GS1-128 price and weight encoding, or contact LabelCraft support if an amount still looks wrong.

Related guides