Decide which characters belong to the identifier
Start with the authoritative identifier supplied for the inspected item. Depending on the assignment, this may come from a controlled weld register, component marking, drawing or customer asset system. Establish whether zeros, spaces, prefixes, suffixes and punctuation are meaningful parts of that identifier. Do not decide by appearance alone. A short numeric-looking code may be a label whose exact characters distinguish it from another item. The report preparation task is to preserve that agreed label and connect the result to it, not to make every identifier look like a tidy number.
Record the identifier source alongside the local name used in the inspection worksheet. A technician may have a convenient field shorthand that differs from the customer’s permanent reference. Both can be useful when their relationship is confirmed. Keep them in separate labelled fields instead of silently replacing one with the other. If the relationship is unclear, ask the responsible project party before attaching a result. A report with a plausible identifier can be harder to correct than an openly unresolved row because later recipients may assume the association has already been verified.
Recognize spreadsheet conversions that can change identity
Microsoft describes automatic data conversions in Excel, including removal of leading zeros and conversion of some digit strings into numeric representations. Those conveniences suit arithmetic but can be unsuitable for a component label. A value that entered the spreadsheet as 00123 may therefore need careful checking before it is used as an inspection reference. Review the source entry and its stored representation. Do not assume that a cell’s current appearance proves that its original characters have survived every earlier import or paste operation.
Look for patterns that make conversion especially easy to miss. A column may contain mostly ordinary numbers, with one identifier containing a prefix or a long sequence of digits. Another row may resemble a date or use the letter E in a way that a spreadsheet could interpret numerically. Build a small set of representative identifiers from the actual project and check their behavior in the preparation workflow. The purpose is not to explore every spreadsheet feature; it is to protect the specific labels that must remain reliable in the delivered report.
Distinguish a display mask from a preserved text value
A spreadsheet can display extra zeros through formatting even when the underlying stored value is numeric. That may make the source sheet look correct while a table import exposes a shorter value. Microsoft’s guidance on keeping leading zeros and large numbers discusses the distinction between treating identifiers as text and displaying numbers with a chosen format. Check which arrangement the supplied file actually uses. The report importer does not reconstruct every custom number format, so a visually correct source is not sufficient evidence of a faithful imported identifier.
If the agreed identifier is text, prepare and verify it as text in the source workflow before relying on the import. Changing a cell’s display after digits have already been altered does not recover the missing information. Recover the authoritative label from its actual source instead of guessing how many zeros should be added. A fixed-width convention can help only when the project confirms that convention and the underlying identity is otherwise supported. Do not pad an entire column merely because most visible labels happen to have the same length.
Protect long digit strings before they become numbers
Long numeric-looking identifiers deserve a deliberate review because a spreadsheet’s numeric representation may not preserve every digit. The risk is not limited to obvious scientific notation: a rounded numeric value can be displayed as a long sequence that looks convincing. Compare the complete identifier with the authoritative record, including its final characters. A casual check of the first few digits can miss a change that causes two distinct components to appear identical. Treat a suspected alteration as a source-data discrepancy and retain the supplied version while the correct identity is established.
Do not attempt to infer lost digits from neighboring rows or a presumed numbering sequence. Serial systems can contain skipped numbers, check characters and exceptions that are not visible in the inspection file. Ask the record owner for a corrected text extract or another verified reference. Where the physical marking is used as evidence, follow the actual project process for confirming and recording it. The reporting software cannot read a component in the field or independently determine whether a recovered label refers to the item that was examined.
Preserve separators and case until their meaning is agreed
A hyphen, slash or space may divide an identifier into meaningful segments. Removing punctuation to make a report column narrower can collapse two different labels into the same string. Similarly, changing letter case may be harmless in one system and significant in another. Ask the source owner which transformations are permitted and record the answer where the reporting team can use it. Prefer displaying the full agreed identifier, with sensible text wrapping, over inventing a shortened version that the recipient must decode.
Where a separate short label is useful for a sketch or a compact field log, define it as an alias and keep the full reference available. Do not imply that the alias is a new customer identifier. Link the alias to the source through a controlled cross-reference rather than expecting every recipient to recognize it. If the same shorthand is used in two work areas, include enough context to distinguish those areas. The broader asset identity mapping guide can help with that relationship; this worksheet checks whether the chosen characters survive the reporting process.
Check the identifier at each actual transfer point
List the transfers that occur in the real workflow: supplier export, spreadsheet preparation, template import, report editing and PDF delivery, for example. A defect introduced before the upload will not be repaired by a faithful importer. Compare representative values on both sides of each transfer rather than testing only the final appearance. Keep the test set small enough to repeat when the workflow changes, but include the unusual identifiers present in the job. The most common identifier may be the least effective test of whether the transfer is safe.
Use the import preview to inspect complete cell values before adding the table to the digital reporting workspace. Check the beginning and end of long identifiers, embedded spaces and any zero prefixes. After the table is added, verify that the result remains beside the intended identifier. Sorting, inserting or removing rows can create an association error even when the identifier itself is unchanged. The test should therefore cover both character fidelity and the relationship between the label and its examination record.
Separate duplicate labels from repeat examinations
A repeated identifier is not automatically an error. The same component may have an initial examination, a repair and a repeat examination, each with its own event reference. Conversely, two physical items may have been assigned the same local shorthand by mistake. Review the event context before removing duplicate-looking rows. A report that collapses repeated labels can lose legitimate history. Add the examination date, event identity or other agreed discriminator where needed, while keeping the underlying component label unchanged.
If two different items appear to share an identifier, stop the affected association and request clarification. Do not create an unofficial suffix simply to satisfy a spreadsheet’s desire for uniqueness. The responsible project party should confirm the distinguishing reference and how earlier records remain linked. Keep the disputed values and the resolution evidence in the worksheet. This prevents a data-cleanup decision from quietly becoming a physical identification decision, which is outside what a document editor can establish.
Worked example: three labels that should not be normalized
Consider a fictional component register containing 000742, 742 and AX-0742. The receiving coordinator initially assumes that the first two labels represent the same component and that the third is a formatted variation. The customer’s register shows that they identify three separate items. The reporting team retains the labels as supplied and checks the result rows against that register. This example illustrates an identity question only; it does not describe a real customer or establish that every organization treats zero prefixes in the same way.
During preparation, 000742 appears in an imported preview as 742 because its source display depended on formatting. The team does not merge the rows. The source owner provides a corrected text entry for the first component, and the coordinator checks the complete three-item set through import and PDF export. A repeat examination of AX-0742 remains a separate event tied to that same component. The final worksheet records the source reference, the observed transformation and the confirmed representation, making the correction understandable to someone who did not participate in the clarification.
| Observed value | Possible mistake | Required check | Supported treatment |
|---|---|---|---|
| 000742 becomes742 | Treating two labels as equivalent | Customer register and stored source value | Restore verified text; keep records separate |
| AX-0742 is shortened | Removing a meaningful prefix | Agreed identifier convention | Retain the full label or a documented alias |
| AX-0742 appears twice | Deleting a repeat examination | Examination-event references | Keep distinct events linked to the component |
| Long digits differ at the end | Assuming a display issue only | Complete authoritative identifier | Hold the association until resolved |
Keep serial, heat and lot references in their proper roles
A component record may contain several identifiers that answer different questions. A serial reference can identify an individual item, while a heat or lot reference may associate it with a material or production group. Do not move a value between those columns simply because it has the expected number of characters. Check the meaning of the source heading and the project convention. Where one serial reference is meaningful only with a manufacturer, assembly or customer context, retain that context rather than assuming the short label is globally unique.
Keep quantity fields separate from these identity fields. A numeric-looking lot reference should not enter a sum, and a component count should not be used as a substitute serial number. If the source combines several references in one cell, ask whether the report should preserve the combined label or separate confirmed elements into clearly named columns. Document the agreed mapping. This lets the recipient follow both the individual examination record and its related material evidence without mistaking one reference for another.
Use equipment records without creating a second identity system
The equipment tracker can organize instrument identifiers and supporting records used for inspection work. Apply the same character-fidelity check to those references. An instrument serial number copied incorrectly into a report may connect the examination to the wrong history file. Keep manufacturer serial identity distinct from a company asset tag when both exist. The report can include the appropriate reference without pretending that one identifier replaces the other or that a register entry independently proves the instrument was suitable for the examination.
When a corrected identifier affects an equipment record, check the downstream relationships before changing it. A calibration document, shipment record or previous report may still use the older representation. Preserve a supported cross-reference through the organization’s record process rather than renaming files indiscriminately. The serial-number identification guide addresses the equipment-record task in more detail. For the current report, identify the confirmed instrument and the evidence actually relevant to the examination event.
Review the PDF as a recipient would read it
Open the downloaded PDF and inspect the full identifiers in their actual table positions. A long label may wrap over two lines without losing characters; verify that the wrapping does not make it appear to belong to another row. Check the first and last characters and any punctuation near a line break. If the column heading contains part of the identifier convention, ensure that the relationship remains understandable when the table continues onto another page. A recipient may read a single printed page without the source workbook available.
Try locating a few reported items using only the PDF and the agreed reference register. If the reader needs an undocumented transformation to find the item, the handover is incomplete. Resolve that relationship before issue. Do not solve a readability problem by silently changing identity. A separate descriptive column or a clearly defined alias may be appropriate when agreed, but the authoritative label should remain available. The buyer-review guide provides broader questions for checking whether the package can be used as intended.
Respond to an identifier error according to its consequence
An error discovered before issue may be resolved through the draft preparation process once the correct source is confirmed. An error in an issued report requires a controlled assessment of which records and recipients are affected. The change may concern display only, or it may call into question which component the result described. Do not classify it as a minor typo without reviewing that consequence. Preserve the earlier record and use the applicable amendment process when a distributed result must be corrected.
Document what was checked after the correction. Confirm that the affected result, images, dataset references and related summary entries still point to the same intended item. A corrected label in the main table is not enough if a conclusion or attachment retains the wrong reference. Avoid expanding the correction into unrelated renaming. The report amendment guide explains how to preserve the change relationship; the identifier worksheet supplies the specific evidence needed to understand this discrepancy.
Keep a reusable project test set with the reporting instructions
Retain a short approved set of representative identifiers for the project or recurring client format. Include the forms that have caused real problems, such as meaningful zero prefixes, mixed letters and digits, separators and long strings. Use synthetic examples where actual identifiers are unnecessary for a training exercise. State the expected complete output for each example. A future preparer can then test a changed export or import workflow without relying on memory or assumptions about how the previous spreadsheet was configured.
Review the test set when the customer changes its convention or a new data source is introduced. Passing an earlier test does not establish that every future file uses the same representation. The useful outcome is a repeatable fidelity check tied to a defined source convention. It protects the relationship between an examination result and the item it describes while leaving physical identification and technical interpretation with the responsible people. Exact characters matter because they help the next person find the right evidence, not because a report should merely look uniform.
Component identifier fidelity check
Download this editable CSV for the task described above. Replace illustrative prompts with your own supported facts. The worksheet is a planning aid; it does not establish inspection acceptance or approval.
Download the free workflow worksheetQuestions about this workflow
Can I add zeros until every identifier has the same length?
Only use a confirmed source convention. Padding a column without verifying identity can invent labels or merge distinct items.
Will changing a numeric cell to text recover lost digits?
Changing the representation does not recover information already altered. Compare with the authoritative source and obtain a corrected value.
Should repeated component IDs be removed?
Check whether they represent separate examination events on the same component. Repeated labels are not automatically duplicate records.
Does a line break in the PDF mean the identifier changed?
Not necessarily. Check that all characters remain present, in order, and associated with the correct row.
Sources and editorial scope
Primary references support the specific context cited in the guide. Worked examples and suggested workflows are NDT Connect editorial guidance. Confirm the documents and authority applicable to the actual assignment.
More guides: report data integrity
- Reconcile Results Across NDT Inspection Worksheets
The same component can appear on several worksheets for good reasons. Reconcile event identity and source evidence before deciding whether rows are duplicates, follow-up examinations or unresolved contradictions.
- Reconcile Excel Dates Before Issuing an NDT Report
An imported value can be preserved exactly and still need interpretation. Reconcile the source date, its meaning and the event it describes before entering it in a client report.
- Transfer Formula Results into NDT Reports with Evidence
A calculated value needs a clear origin and an appropriate review. Use a transfer record to distinguish the spreadsheet calculation from the value entered in the report.
- Create a Photo Reference Log for an NDT Report
A useful inspection photograph needs a retrievable original and enough context to identify what it shows. Build a photo reference log that connects site views, detail images and report observations without overstating what a picture proves.
