When every copy has to be different
Ordinary printing produces a thousand identical items. Variable data printing, on the other hand, creates a thousand unique items in a single run: each with its own serial number, barcode, name, and code that must never be repeated.
It seems like a rare, specialist case until you realize how common it is around you. Every numbered raffle ticket, every unique promotional code, every asset tag on the underside of a laptop, and every batch-coded label on a product is part of a variable data workflow. While the printing itself is straightforward, the data handling is where the real work takes place.
This guide outlines what the process requires from you, common errors that occur, and how to prepare a job to ensure the numbers arrive correctly.
How it works, briefly
A variable data job consists of two main components: a template and a data source. The template is the artwork that holds all the elements that remain constant. The data source, typically a spreadsheet, contains all the elements that change. The template includes designated fields that are populated by pulling a row from the data source for each piece printed.
This is only possible on digital presses. An offset press images a plate once and then prints that same image repeatedly, which is exactly what makes it economical for long runs and exactly what makes it useless here. Digital presses image every sheet independently, so every sheet can differ at no extra cost per change. The wider comparison sits in our note on digital against offset.
What can vary
- Sequential numbers, the simplest and most common case.
- Barcodes and QR codes each encode different types of information.
- Names, addresses, and any other text extracted from a list.
- Different images are used so that various recipients receive different pictures.
- Layout blocks that switch based on a value in the data.
The last one is where it becomes genuinely useful and equally risky. A rule that states, "if the customer is in category A, show this panel," is powerful but can also be wrong in ways that go unnoticed until ten thousand pieces are printed.
Your data is the job
People often underestimate a key aspect of variable data jobs. While printing is relatively straightforward, the data handling is where all the problems originate. These issues tend to be the same ones that recur.
| Data problem | What it produces |
|---|---|
| Trailing spaces in a field | Text that is slightly off-center and inconsistent |
| Numbers stored as text | Leading zeros vanish, 00042 becomes 42 |
| Mixed date formats | Some pieces read 03/04, others 04/03 |
| Duplicate rows | Two pieces with the same unique code |
| Blank fields | Gaps, or a line collapsing upward |
| Special characters | Question marks or boxes appear where an accent should be. |
The leading zero problem is the classic. A spreadsheet helpfully decides your serial column is numeric, strips the zeros, and now 00001 prints as 1 while 10000 prints correctly. It looks fine in the file because the spreadsheet is displaying what it thinks you meant. Format that column as text before you type anything into it.
Clean your list before you send it
- Check for duplicates, particularly in any column that must be unique.
- Verify that the row count matches the quantity you are ordering.
- Examine the longest entry in every field, rather than the first one.
- Confirm that leading zeros have been preserved upon saving.
- Determine how blank fields should be handled before they appear on a proof.
The longest entry point deserves more attention than it gets. Your template was designed around a name like "John Tan". Somewhere in row 4,000 there is a name three times that length, and it will either overflow the space or shrink to something unreadable. Sort each column by length and look at the extremes. That is where the layout breaks.
Barcodes have rules of their own
A barcode is not a picture; it is a machine-readable code with specific tolerances. Printing it in a visually appealing manner can sometimes render it non-functional.
Three factors can reliably disrupt barcodes. First, scaling below the minimum size can cause the bars to blur into one another. Second, removing the quiet zone, the clear margin on either side that indicates to a scanner where the code starts, can also disrupt the barcode. Lastly, low contrast can hinder barcode functionality, as scanners require dark bars on a light background. A barcode printed in a brand color on a dark label may look appealing but is unlikely to function properly.
QR codes are more forgiving because they include error correction. However, they can still fail if printed too small for the amount of data they hold. A QR code containing a long URL has more modules packed into the same square, so it needs more physical space than one containing a short link. Shortening the URL simplifies the code.
Test before you commit. Print one, scan it with an ordinary phone in regular lighting, not under a desk lamp at arm's length. If it takes more than a second to load, something is wrong.
Proofing a job with a thousand versions
You cannot proofread every piece, so the question becomes which pieces to proofread. The answer is not simply "the first three.
Verify the extremes. Identify the longest and shortest names, the first and last records, and any records with unusual characters or blank fields. These five categories can reveal more about your data than a hundred random samples. This is because the failures tend to cluster at the edges of your data rather than in the middle.
Specifically check the last record. If the count is off by one, or the sequence stops early, this is where it will show. This record is also the least likely to be thoroughly examined before a run is approved.
Agree what a mistake costs
Before running the job, it's important to clarify who is responsible for any errors. If the data was incorrect, the print will be wrong, and it will have printed exactly what it was given. This is not merely a printer defending itself; it is why the proofing step is so critical here compared to ordinary work. A misspelled name in an ordinary job is just one mistake. But in a variable data job, it can result in one mistake repeated across a segment of your list.
Where it earns its cost
Variable data involves a setup cost, as someone must build the template, map the fields, and run test records. This cost is fixed, meaning it dissipates over a long run but dominates in a short one.
It earns that cost when uniqueness performs real work: codes that must not be reused, tickets that must be traceable, asset tags that identify one specific item, and batch codes that make a recall possible. If your items do not actually need to differ, do not pay for it. Numbering something merely for the sake of it incurs a cost with no return.
Send us the data early
The single most useful thing you can do is to send your spreadsheet before your artwork is finalized, not after. We will identify the extremes, inform you where the layout will break, and flag duplicates and missing zeros while they are still inexpensive to fix.
We would rather spend twenty minutes on a data file than reprint a run because row 3,742 had a name that did not fit. If your codes must be unique, we will check that they are, and we will tell you if they are not.
You can see the range under business printing, and our guide to durable label materials covers what to print these on. Send your list and your template through the contact page and we will run the checks before anything reaches a press.
