How 2D barcodes kill expiry-date typing

nobody's best work happens at the receiving bench

Picture the actual scene, because the actual scene is where inventory systems live or die. It's mid-morning, the delivery is late, and somebody — maybe you, maybe whoever drew the short straw — is standing at the back bench with an invoice in one hand and a keyboard under the other. Forty lines on the delivery. For each one: find the product, scan the UPC (that part works fine — the UPC has worked fine since 1974), then squint at the pack or the invoice for the batch number and the expiry date, and type them in. Batch L2417B. Or was it L24I7B — is that an I or a 1? The date says 03/07/27. March 7th, or the 3rd of July? Depends which side of the supplier's export settings you're on. Next line. Thirty-nine to go. The phone rings twice. A customer needs help in aisle three.

This is the data-entry layer that every downstream promise of an expiry-tracking system is built on, and it has two structural problems. The first is time: a per-line ritual of read-squint-type, multiplied across every delivery, every week, forever. The second is worse: it's exactly the kind of task humans are bad at. Repetitive, low-stakes-per-keystroke, done under interruption, full of look-alike characters and ambiguous date formats. Ask anyone who has ever audited their own received-stock data against the physical shelf and they'll tell you what they found — transposed digits, batch codes with a zero where an O should be, dates that landed in the wrong month because of format ambiguity, and lines skipped entirely on the days the bench got busy. Nobody needs a study to confirm what every store owner already knows from their own correction history: hand-keyed batch and expiry data is reliably, persistently dirty.

The usual response is to try harder — laminated date-format reminders, double-entry checks, a stern word at the staff meeting. The better response is to notice that this entire category of work is in the process of being deleted, and to position your store on the right side of the deletion.

what one wrong expiry actually costs downstream

It's tempting to file a typo as a small error. It isn't, because expiry data doesn't sit still — it drives decisions, and a wrong date drives them all wrong simultaneously.

FEFO sorts wrong. First-Expired-First-Out only works if the system's idea of "first expired" matches reality. One yogurt batch keyed as expiring in August instead of June quietly moves to the back of the pick order, sails past its real date on the shelf, and gets discovered by a customer. Meanwhile the system confidently rotates fresher stock out first. You're now running worst-of-both-worlds rotation and paying for software to do it.

Alerts fire wrong — in both directions. A too-early date triggers a markdown on stock with weeks of life left; margin evaporates for no reason. A too-late date keeps the alert silent until the loss is unrecoverable. Either way the alert told a story the shelf contradicts.

And then the quiet killer: staff stop trusting the system. This is the real cost, and it compounds. The first time the expiry report sends someone to pull stock that turns out to be fine, they shrug. The third time, they start re-checking dates by hand — which means you're now paying for the manual process and the system. The fifth time, they stop acting on alerts altogether, and the one alert that was real scrolls past with the rest. Data quality problems don't subtract value from an inventory system; past a threshold, they zero it. The discount your team applies to every record is set by the worst records they've personally caught.

There's a regulatory edge to this too. If you sell food covered by lot-level traceability requirements, the lot number you keyed in is your traceability record — FSMA-style lot-level traceability is only as real as the receiving data underneath it, and a mistyped lot is a recall response pointed at the wrong stock.

the scan that replaces the typing

Now the deletion. A GS1 2D barcode — the DataMatrix square, or its sibling the GS1 Digital Link QR — carries structured fields called Application Identifiers: AI (01) is the GTIN, the product identity; AI (10) is the batch/lot; AI (17) is the expiration date; AI (21) is the serial number; AI (15) is best-before where that applies. All of it in one square, printed by the manufacturer, encoding what the production line actually knew at the moment of packing.

At the receiving bench, that changes the per-line ritual to this: beep.

One scan, and the product, batch, and expiry land in their fields together. No squinting at ink-jet print. No I-versus-1 judgment calls. No date ambiguity — AI (17) is a fixed year-month-day format, so March and July cannot trade places no matter which country the label was printed in. The data isn't a human's transcription of what the pack says; it's the pack saying it directly. Receiving forty lines stops being forty small data-entry tasks and becomes forty beeps, and the error rate on the captured fields drops to, effectively, the barcode misprint rate — which is a rounding error compared to tired thumbs at a busy bench.

Two prerequisites, both cheap. The scanner must be a camera-based 2D imager — 1D laser guns physically cannot see a DataMatrix, though most USB guns sold today are 2D-capable; the full hardware picture, including the buying checklist, is in our guide to QR, DataMatrix, and UPC. And the software has to parse Application Identifiers — split that one long scanned string into its labeled fields — rather than treat it as a forty-character product code. The scanner is a commodity; AI parsing in the software is the part that turns the beep into filled-in batch and expiry fields.

how many packs actually carry a 2D code today (the honest answer)

Here's where most writing on this topic goes soft, so let's be precise: coverage is real, growing, and partial, and the partiality is the whole design problem for your receiving workflow.

Pharmacy: effectively done. Under DSCSA, every salable pharmaceutical unit in the US carries a GS1 DataMatrix with the NDC/GTIN, serial, lot, and expiry. This isn't an initiative or a pilot — serialization enforcement is live for manufacturers (since May 2025), wholesalers (August 2025), and large dispensers (November 2025), with small dispensers exempt only until November 27, 2026. A US pharmacy receiving bench is already a 2D environment wall to wall, and the DSCSA compliance checklist shows what receiving looks like when scan-capture of those fields is table stakes rather than a productivity upgrade.

Grocery and general retail: in transition, honestly. The industry's coordination point is GS1 Sunrise 2027 — the ambition that retail POS systems be capable of scanning 2D barcodes by the end of 2027. Note what that is: a capability milestone for scanners and software, not a mandate that every pack carry a 2D code by a date. Brands are adopting at their own pace, fresh and own-label categories are moving earlier because that's where date data pays, and during the transition any pack with a 2D code carries the familiar 1D barcode alongside it. Food traceability regulation adds steady pressure in the same direction — FSMA 204 enforcement is set for July 20, 2028, and lot data printed in a scannable square is the cheapest way to satisfy a lot-level record-keeping rule — but pressure is not coverage. For several years yet, a grocery delivery will be a mixed bag: some lines that scan rich, many that still carry identity-only UPCs.

Which means the right mental model for 2026 is not "the scan replaces typing" but "the scan replaces typing wherever it can, and something other than typing replaces it everywhere else." A receiving workflow that only handles the 2D lines hasn't killed the typing; it's killed some of it and left the rest exactly as error-prone as before.

the fallbacks, ranked

For the packs that don't yet speak AI, there's a hierarchy of ways to get batch and expiry into the system, ordered by data quality per second of human effort:

1. Supplier despatch files. The batch and expiry data you're typing off the invoice already exists digitally — it was in the supplier's system when they picked the order. Distributors increasingly provide despatch or advance-shipment files per delivery: every line, with batch and expiry, as data. Importing that file receipts the whole delivery's date data in one step, no barcodes required, and it covers 1D-only products just as well as 2D ones. If your suppliers can send these files, file-based receiving is the single highest-leverage fallback on this list — for some stores it's not the fallback, it's the main event.

2. OCR on the printed date. The expiry is printed on the pack in human-readable form; a phone camera and text recognition can read that print and propose the date for confirmation. It's a transcription aid rather than a data feed — you're still capturing per-pack — but it removes the typing and the format ambiguity, and it works on any product with a legible date, which is nearly all of them.

3. Shelf-life rules. For fast-moving lines with stable shelf lives, a default does respectable work: received today plus the product's known shelf life equals an estimated expiry, applied automatically at receiving. It's an estimate, and it should be flagged as one, but a systematic estimate beats a blank field — and beats a typo, because it's at least wrong in a predictable direction. Use it for the long tail; correct by exception when the shelf walk finds a date that disagrees.

4. Typing. Still exists, demoted to last resort — for the odd line that arrives with no 2D code, no supplier file, no legible date, and no shelf-life rule. The goal was never zero keystrokes on day one. The goal is moving each product up this hierarchy as its supplier, its packaging, or its data feed allows, until typing is the exception that gets noticed instead of the routine that gets botched.

what this looks like when it's one workflow instead of four

This is the part where the tooling earns its mention, because the hierarchy above is only pleasant if it's invisible. Nobody at a receiving bench wants to decide, per line, which of four capture methods applies today.

ShelfLifePro folds the whole hierarchy into a single receiving flow. Scan a pack: if it's a GS1 DataMatrix or Digital Link QR, the AI parser fills product, batch, and expiry from the code — done. If it's a plain UPC, the line falls through automatically: a supplier despatch file, if one's been imported for the delivery, fills the date fields; otherwise the product's shelf-life rule proposes an expiry, or the camera OCR reads the printed date for one-tap confirmation. The person at the bench does the same thing every time — scan, glance, confirm — and the software routes each line to the best data source available for it. Every captured date, whatever its source, feeds the same FEFO ordering and the same expiry alerts, with estimated dates flagged so the shelf walk knows where to double-check.

The payoff compounds in the direction the industry is already moving. Every supplier that starts printing 2D codes silently upgrades their lines from rule-based estimates to pack-level truth, with zero workflow change at your bench. Pharmacy's there now; grocery is arriving category by category through Sunrise 2027 and beyond. The typing, meanwhile, just quietly disappears — not in one dramatic cutover, but line by line, beep by beep, until one Tuesday you realize nobody has keyed an expiry date in a month and the alerts have been right all month too.

That second part is the prize. The hours saved at the bench are nice. The system your staff actually believe is the thing that pays.

ShelfLifePro captures batch and expiry by 2D scan, supplier file import, OCR, or shelf-life rule — whichever each line supports — and drives FEFO rotation and expiry alerts from data your team can finally trust. The receiving bench keeps the beep and loses the keyboard.