Short answer: most likely yes, at least in part — and the number that should decide the timeline is not a compliance fine. It is the quarters between "capital approved" and "live at every lane." A grocery POS refresh is a nine-to-eighteen-month program once you count procurement, pilot stores, software certification, and a chain-wide rollout across every banner and every lane. If your lanes have to read and process 2D barcodes by the end of December 2027, the decision that lands that capability on time is a decision you make in 2026, not 2027. That is the whole reason this question is worth answering carefully instead of filing it under "IT will handle it."
What Sunrise 2027 actually asks of your lanes
GS1's Sunrise 2027 program sets a single, bounded expectation for retail point-of-sale: be able to scan and process a 2D barcode — a GS1 DataMatrix or a QR Code carrying a GS1 Digital Link URI — and extract the GTIN at the lane, by the end of December 2027. That is the baseline. It is a lane-capability expectation, and it is GS1's own industry program — not a statute, not an FDA rule, not something with a fine attached. Nobody is going to cite you. What happens instead is quieter and more expensive: brands begin printing 2D marks on packs, and a lane that can only decode a 1D UPC starts failing to ring items that a 2D-capable lane rings without a thought.
Two corrections a GS1-literate person on your team will make immediately, because getting them wrong is how a refresh gets scoped as the wrong project:
- The baseline is GTIN extraction — not lot, not expiry. Lot number and expiry date are optional application identifiers a brand may choose to encode in the 2D symbol. Sunrise does not require your lane to capture them, and you should not size a program around receiving them by default. If they arrive, that is a bonus your record layer can use; they are not the bar.
- Sunrise puts nothing on a pack. The brand does, if it chooses. The mark that shows up at your lane, and its form, is the GTIN owner's decision. Your job is to be ready to read whatever they print — which is exactly why "readiness" is the thing you schedule, not "receiving a specific field."
Replace, or upgrade? The honest scan of your fleet
"Do we have to replace" collapses two different answers, and the split matters to the budget:
- Imagers you already own can often just be enabled. Many 2D area-imaging scanners deployed in the last several years can already decode a DataMatrix or QR — the capability is in the hardware and gated by firmware and POS-software configuration. For those lanes the work is a firmware/software pass and a certification cycle, not a hardware buy.
- Legacy 1D laser scanners cannot be upgraded into 2D readers. A single-line or raster laser is physically a 1D device. Those lanes are a hardware replacement, full stop.
- The POS application has to parse what the scanner decodes. This is the step most fleet audits miss. A scanner can hand your POS a GS1 Digital Link URI or an FNC1 element string and the application still has to know how to pull the GTIN out of it for price lookup. Reading the symbol and processing it are two different line items, and Sunrise names both.
So the real 2026 exercise is an inventory, not a purchase order: how many lanes are 2D-capable imagers that need only a config-and-certify pass, how many are lasers that need replacement, and what does the POS software need to parse the Digital Link URI form. Do that inventory now and the capital ask writes itself — and lands on time.
The trap: funding the scanner and forgetting the record
Here is the failure this article exists to prevent, and it is the single most expensive mistake available to a grocery store-systems org in this cycle. You can run a clean, on-time scanner refresh, arrive at December 2027 with every lane reading 2D, and still have gained nothing you can put in front of a food-safety auditor. A lane transaction is not an event record. When the upgraded lane reads a 2D code and extracts the GTIN, it rings a sale. It does not record this item, this lot, from this pallet, received at this dock, by this person. Sunrise makes you a reader of a record-grade mark with nowhere to put what it reads.
That gap is not academic. The same GS1 Digital Link URI your lane reads normalizes to the same GTIN key an EPCIS event record uses — which means a lane scan and a receiving-dock scan can land on one item, with no mapping table between them. The standard already hands you the key that joins the front of the store to the back. What is missing is a record with a witness in it for both scans to write to. Fund only the scanner and you buy the key and throw away the lock.
That is the layer this pillar is about — and it is worth being exact about what you can check.
What actually ships today
Live today, checkable by curl: POST https://epcis.dev/translate, /validate and /hash — the strict-conformance capture spine's stateless doors, with 683/683 spine tests passing. No conformance attestation has ever been issued, and none is claimed. The record layer under your 2D lane — receiving custody, exception dashboards, a query that answers a traceback in one shot — is entry-by-entry in the open P0 ledger. The honest thing to do with this article is to let it change how you scope the scanner refresh — read the richer mark, and leave a place to put what it reads.
The move for 2026
Run the lane inventory now. Separate the config-and-certify lanes from the replace lanes. Schedule the capital so it lands before the December 2027 lane clock, not on it. And scope the program to include the question no scanner spec answers: where does the record go once the lane can finally read it. The parent read — the two clocks, the lane and the dock, separated in writing — is here: GS1 Sunrise 2027 and FSMA 204 for grocery.
Capture workspaces are provisioned from the seat list, in order — one email when your seat is ready, exactly one. That is the whole promise, and it is the only thing to log:
→ Put me on the seat list — pick Retailer or point of sale, the segment that reads the 2D code at the lane.
<!-- slug: