Twelve hundred equipment labels came back from the printer and went onto machines across four sites. Three weeks later a technician reported that the tag on a compressor opened a broken page. Then another did. The count settled at forty-one bad labels, all from the same block of rows in the source spreadsheet, all pointing at a URL that ended one character early.
The cause was a comma. Someone had typed a location note reading "Building 4, Bay 2" into a field, the file was saved as CSV, and the parser on the other end read that comma as the end of a column. Everything after it shifted one place to the left.
Bulk generation is a data problem wearing a graphics costume. Nearly every failure at scale traces back to the sheet.
Design the sheet before you export anything
One row per code, one code per row. No merged cells, no totals row, no blank spacer rows, no notes column full of free-form prose.
Columns worth having:
- An identifier you assign and never change. Not the row number, and not anything that shifts when the sheet is re-sorted. This is the key every other system references, including the print vendor's file names.
- The destination URL, complete, with its scheme.
- A label or name following whatever naming schema you use.
- Metadata you will want later: site, placement, owner, print batch, date.
Give the file a header row with short, machine-friendly names. Avoid spaces and punctuation in headers, because some importers mishandle them and others silently rename them.
The most damaging habit is renumbering. Sort the sheet, regenerate sequential IDs, and every reference in every other system now points at the wrong thing while the labels are already screwed to machines.
The delimiter and quoting traps
CSV has no schema and only weak conventions. What breaks:
- Commas inside field values. A quoted field handles this correctly, but only if whatever wrote the file quoted it. Spreadsheet exports usually do. Hand-edited files and quick scripts often do not.
- Quote characters inside quoted fields, which have to be doubled. A product name with an inch mark is enough to derail a row.
- Line breaks inside a field. Someone pastes a multi-line address into a label cell, one row becomes two, and the second one is missing most of its columns.
- Inconsistent column counts between rows, which importers treat differently and sometimes accept without complaint.
Two defenses. Export from the spreadsheet application rather than composing CSV by hand. And if the tool accepts it, use tab-separated values instead, because tabs almost never appear inside a URL or a label while commas constantly do.
Add a validation column that flags any text field containing a comma, a quote, or a line break, and check it before export. Catching it in the sheet is free. Catching it after a print run is not. That check belongs in the same routine as the bulk generation step itself.
Encoding is the trap nobody looks for
A CSV file carries no declaration of its own encoding, so the reader guesses.
Save as UTF-8. If labels contain accented characters, non-Latin scripts, or currency symbols, a file written in a legacy code page arrives as mojibake, and that mojibake gets encoded into the codes themselves. What ends up inside the symbol depends on byte-level details invisible in the spreadsheet, which is the territory covered in character encoding and ECI.
Watch also for a byte order mark at the start of the file. It shows up as stray characters glued to the first header name, which quietly breaks the mapping for the first column.
If any label or URL contains non-ASCII characters, generate one code, decode it, and read the string back before running the rest. Non-ASCII also consumes more capacity than plain ASCII, which matters on dense codes. The limits are covered in how much data a QR code holds.
What spreadsheets do to your data without asking
This is where quiet corruption lives, because none of it produces an error message.
- Leading zeros disappear. Asset ID 00742 becomes 742 the moment the column is treated as a number.
- Long numbers become scientific notation. A twelve-digit serial displays and exports as 1.23457E+11.
- Numbers past fifteen digits lose their tail to floating point and cannot be recovered.
- Values that look like dates become dates. A code written as 12-3 turns into a date in December or March depending on the locale.
- Autocorrect converts straight quotes and hyphens into typographic ones. A curly apostrophe in a label is cosmetic. A typographic hyphen inside a URL is fatal, and on screen it looks nearly identical to the real thing.
- Copy-paste from a web page carries non-breaking spaces and trailing whitespace along with the text.
Fixes in order of reliability: set the column format to Text before pasting anything into it; on import, explicitly choose Text for ID and URL columns rather than accepting the default; disable autocorrect in any sheet that holds URLs. Reformatting a column afterward does not restore what was lost, it only changes how the damaged value is displayed.
Validate destinations before you generate
Run these against the sheet, not against finished artwork.
- Every URL parses and has a scheme. Rows beginning with "www." are the usual offenders.
- Every URL responds. Record the status and the final address after redirects.
- Flag anything that is not a direct success. A destination that redirects today is a destination that returns 404 eventually.
- Flag duplicate URLs that should be unique, and unique URLs that should have been duplicates.
- Check length. Very long tracking URLs produce dense codes that scan poorly at small sizes, and shortening them now is far easier than after print. A short URL behind the code is the usual route.
- Compare the row count in your sheet against the count the generator reports. A mismatch is the fastest possible signal that parsing went wrong.
The QA pass: decode a sample, compare to the row
After generation and before print, choose the sample deliberately instead of randomly.
Take the first row, the last row, every row containing a non-ASCII character, every row with a comma or quote in any field, and a random five percent of the remainder. Those categories are where errors concentrate.
Decode each selected image with a reader and compare the decoded string against its source row character by character. Do the comparison with a formula or a script rather than by eye. Human proofreading of long URLs with tracking parameters has a poor hit rate, and the failure mode is one wrong character in the middle.
Then print a proof at final size on the real material and scan it off paper. Screen decoding proves the data is right. Paper proves the code is usable, and the two fail for completely different reasons, which is why print testing does not substitute for either.
Keep the sheet as the record of what was printed
When the run is done, freeze the file and store it with the job.
Include the export date, the generator settings used, the print vendor and job number, the quantity produced, and where the material went. Name the file with the batch identifier so it can be found starting from any single label.
Two years from now a technician sends a photo of an unreadable tag with an asset number still visible on it. If the sheet is archived, answering that is a lookup. If it is not, answering it is a guess.
Freeze your next export before it goes to the printer, and add the decode-and-compare step to the job checklist ahead of the approval signature.
