A successful scan is useful evidence, but it is not a barcode quality certificate or a complete handheld purchasing decision. Before choosing a device, ask for three connected records: what happened in the scan demonstration, what the relevant verification report actually assessed, and what remains to be tested in your working conditions. Each answers a different question. Buying a different scanner does not, by itself, close a gap in label-quality evidence.
This guide is for system integrators, warehouse solution teams and project buyers deciding what to request before a hardware evaluation. It focuses on the evidence behind a supplier's claim that a label is readable, rather than repeating the physical factors covered in barcode label and scanner selection basics.
Start with the decision behind the demonstration
Consider a warehouse receiving project preparing to buy barcode handhelds. A supplier presents a carton carrying a GS1 DataMatrix symbol. The demonstration device reads it, and the supplier also provides a quality report. The buyer now needs to decide whether these materials are sufficient to shortlist a configuration, or whether the label owner must provide more evidence first.
This is an editorial illustration, not a customer case or an AIDC GO test. No grade, reading distance or success rate is assumed.
Begin by asking what the demonstration established. Was the displayed value captured from the physical carton being discussed? Which device and configuration were used? Was the result a decoded string, an application lookup, or a completed receiving operation? These observations should not be combined into one unexplained “pass.”
A practical demonstration record can identify the sample, configuration, operator action and observed output. If the seller used a different sample or an unspecified scanner, record that limitation. The demonstration can still be useful for discussion, but it does not yet identify the configuration you are approving.
What does scanning prove—and what does verification add?
Scanning is a reading observation. GS1's DataMatrix guidance distinguishes a successful read on a particular scanner from verification against relevant requirements. Verification provides diagnostic quality information; a symbol that fails verification may nevertheless decode on some readers. A successful demonstration therefore does not overturn an adverse verification finding. See the GS1 DataMatrix Guideline, section 4.6.4.
Keep the claims attached to their evidence:
- “This configuration decoded this sample under these conditions” describes a scan observation.
- “This report records an assessment of this sample against these requirements” describes the scope of a verification result.
- “This configuration is accepted for this receiving task” is a project decision requiring the agreed evidence and acceptance owner.
Ask what a supplier means by “verified.” A video, an application's green tick and a formal quality report are not interchangeable attachments. If a device displays a score, request the assessment method and scope before treating that number as a standards-based grade. A screen label alone does not establish how the measurement was made.
The useful next question is not simply which device reads the most difficult-looking label. It is whether the evidence supports the particular approval being requested.
Does the report belong to the sample you will use?
Ask the report provider to identify the submitted sample and its condition. Was it finished packaging, an empty pack, a separate label or artwork? GS1's 2D verification guidance records these distinctions and requires unassessed placement to remain identified as unassessed. The same guidance says a grade needs its measurement context, including aperture and illumination, with angle information as applicable. See sections 6.4 and 7.4 of the GS1 2D Barcode Verification Process Implementation Guideline.
For the receiving example, create a simple cross-reference between the carton sample and its report. Give both a project reference. Ask the label supplier to confirm the artwork revision, production or sample batch, and any difference between the assessed item and the item offered for evaluation. Matching the encoded identifier is not enough to establish that two physical print samples are identical.
Request the complete report rather than a cropped grade. Ask its issuer to confirm:
- Which symbol, application requirements and document versions were used?
- Which checks were performed, and which were outside the assessment?
- What equipment and measurement settings produced the result?
- When was the assessment performed, and what equipment-control or calibration information supports it?
- Does the report cover the supplied sample only, or a defined batch under a stated sampling plan?
These are procurement questions, not a replacement verification procedure. Do not fill missing fields with assumed values. A report for a loose label may be relevant, but ask the issuer what further assessment is needed for the carton as used; do not silently extend its scope.
Similarly, a report date is a traceability point, not a universal expiry rule. Ask what changed since that assessment. A new print process or packaging revision calls for an applicability review, not an invented rule that every report expires after the same number of months.
Read the grade in its application context
Avoid reducing the decision to “ask for grade A.” Before requesting a pass/fail conclusion, have the project's label-quality owner identify the applicable symbol and application requirements, including the relevant versions and any customer acceptance specification. Where requirements are unclear, ask the report provider or relevant standards organisation to clarify them.
The GS1 documents cited here include historical DataMatrix and 2D verification guidance. They explain useful distinctions, but this article does not reproduce their numerical thresholds as today's requirement for every warehouse. Nor does it apply retail point-of-sale rules to a receiving operation simply because both use a 2D symbol.
Keep a report's overall result, detailed findings and limitations together. If two reports disagree, ask the issuers to reconcile the sample identity, assessment scope and conditions. Do not select the more favourable result without explaining the difference. A buyer should not change a measurement setting to obtain a preferred grade or infer field throughput from a grade alone.
The project can then assign the next action without prematurely blaming the handheld or the label supplier:
| Evidence available | What remains unresolved | Useful next decision |
|---|---|---|
| A successful supplier scan demonstration | Whether the sample, device configuration and task match the purchase | Define the configuration and samples for a project evaluation |
| A grade without its complete report | Which requirements, sample and measurement conditions the grade represents | Obtain the report and clarification from its issuer |
| A loose-label report for a finished-carton task | Whether placement and the final presentation were assessed | Agree which finished samples or additional assessment are needed |
| A relevant report and a readable sample | Whether the proposed configuration and application meet the receiving task's acceptance criteria | Combine the report with task observations before approval |
This table is a suggested decision aid, not a completed test or a mandatory GS1 purchasing sequence. Its purpose is to identify the missing evidence and the person who can supply it.
What still belongs in the handheld evaluation?
In the illustrative project, retain the report-linked carton and identify other label variants that the receiving team actually encounters. Ask the evaluator to distinguish those samples in the record. A reported sample and an unreported variant should not acquire the same verification status merely because both appeared in a demonstration.
Agree a focused evaluation with the proposed configuration. Record its model and relevant configuration details, the sample reference, the intended presentation and the observed output. Preserve unsuccessful attempts and any adjustments needed to obtain a read. If the operator had to leave the agreed working position or change a setting, that is part of the result, not an invisible setup step.
Let the project owner define the repetitions, permitted adjustments and acceptance criteria before testing. This article supplies no universal read-rate target, distance, sample count or throughput promise. If evidence is limited, the decision may be to proceed to a controlled sample stage rather than approve a wider purchase.
When comparing configurations, use the same identified samples and agreed task conditions where practical. Where a difference is unavoidable, record it instead of presenting the observations as a direct ranking. A disappointing read result should lead to a bounded investigation: what evidence would distinguish a configuration issue, a presentation issue or a label-quality issue?
Keep this exercise focused on the gap between the report and the intended reading task. Use the AIDC pilot validation checklist for the broader project pilot; there is no need to recreate its network, deployment and operational coverage inside a label-evidence review.
Keep data correctness separate from symbol quality
Verification is not limited to an impression that the print looks clean. GS1's retail implementation guidance describes both quality assessment and checks relating to symbol specifications and data structure. The exact checks still depend on the assessment's scope. See its Verification section. This role distinction is useful here; retail-specific acceptance rules are not being adopted for the warehouse example.
Even an assessment of encoded structure does not establish that your application maps the resulting value to the right item, or that the receiving transaction is accepted. Ask the application team to retain its own evidence for those outcomes. If a symbol decodes but the WMS receives unexpected fields, continue with GS1 parsing and WMS data mismatches, rather than diagnosing the problem from the quality grade.
This article stops at that boundary. Transaction recovery and the operator's quantity-entry or confirmation steps require their own checks; they are not additional functions that should be assumed from a barcode verifier or handheld specification.
Send an enquiry that identifies the evidence gap
Use the enquiry to explain what remains undecided, not only to request a stronger scanner. Share the relevant label samples or permitted photographs, their report references, the symbol and application context, the intended presentation, and what has already been observed. Identify information that is confidential before transferring real operational identifiers or reports.
Ask for confirmation of the proposed model and configuration, the available documentation, and the sample-evaluation questions that can be addressed. The barcode data-capture hardware directions provide a starting point for that discussion, not proof that any listed device performs formal verification or will read a particular low-quality sample.
AIDC GO's published hardware evaluation and integration responsibilities distinguish hardware selection, model-dependent documentation discussion and sample coordination from the customer's application and final project decisions. This guide does not offer barcode certification, a verification service or a model-specific reading guarantee. Agree label-quality ownership and the required report with the appropriate project parties.
To prepare an AIDC hardware project brief, include the decision you need next: clarification of a configuration, evaluation of identified samples, or a list of missing documents before a sample can be useful. Keep the report, physical sample and proposed task connected. That gives the next purchasing discussion a clear starting point without asking one successful scan to prove more than it can.