Keep NDT Report Numbers Stable Across a Year Change

An inspection report can have several relevant dates: when the examination occurred, when the draft was first saved, when a reviewer considered it and when the document was issued. These events may fall on opposite sides of a year change. A useful numbering rule explains which event supplies any date embedded in the identifier. Without that explanation, two people can read the same number differently. One may assume the year describes the examination; another may assume it is the issue year. Neither interpretation should be left to guesswork when the record is being handed to a client or retrieved later.

In the free digital NDT reporting workspace, the first account save assigns the tracked report number. Date tokens use the entered inspection date when available; if the draft has no inspection date, they use the current UTC date at that save. Subsequent draft edits preserve the assigned number. Creating a revision also retains the number while changing the separate revision value. Plan around that behavior. Enter the intended examination date accurately before the first save when it should determine the identifier, and use the report's actual fields to communicate later events.

The default pattern is NDT-{YYYY}-{SEQ:5}. It combines a literal prefix, a four-digit date component and a sequence padded to at least five digits. Other supported date tokens are {YY}, {MM} and {DD}; {METHOD} inserts the selected method at first save. Exactly one sequence token is required, using {SEQ} or a padded form from {SEQ:3} through {SEQ:8}. The pattern accepts ordinary letters, numbers, spaces and supported separators. Keep it short enough that the completed number stays within the tool's length limit and remains readable in a PDF header or a customer's record list.

Add a component only if it helps a real retrieval or communication task. A long identifier that repeats the company, customer, site, method, date and internal department can be harder to use than a short stable reference. Much of that information already belongs in structured report fields. Literal text in the pattern is simply text you enter; the software does not validate a customer code or automatically synchronize it with the client field. If you include a project prefix, document what it means and check it before first save. Avoid unnecessary personal or confidential information in a number that may appear in exported filenames.

The editor shows an example with sequence one so you can inspect the pattern's shape. That display helps catch missing separators, unsupported tokens or an unexpectedly long prefix. It does not promise that your next report will receive that example number. The account assigns the actual sequence when the first save succeeds. Another report may already have used earlier values, or a reserved value may have been skipped. Do not copy the preview into a customer transmittal or a separate project register as if it were an assigned identity. Wait for the saved confirmation and inspect the actual tracked number.

Test a proposed pattern with ordinary and awkward cases before relying on it. Consider an inspection date near year-end, a two-digit month or day, and the longest method name you intend to use. Check how the result looks when pasted into a plain-text message. Also consider whether a slash in the number will be changed when the PDF filename is prepared for download. The human-readable report number and a file-safe download name can have different punctuation without describing different records. Your retrieval process should use the full saved number and revision from the report, rather than assuming that every filename is an exact character-for-character identifier.

The sequence belongs to the account's report creation process. Adding {YYYY} to the visible pattern does not create a separate annual sequence, and changing {METHOD} does not create an independent counter for each method. Treat the year and method components as first-save context embedded in an identifier, not as instructions to reset the allocation system. If a business requires a numbering policy that begins again at one every January, confirm that requirement before choosing this workflow. The current tool should not be described as implementing a reset merely because its identifiers display a year.

Padding is another formatting rule that is easy to mistake for allocation policy. A five-digit sequence format makes short values easier to read consistently; it does not mean the account has exactly one hundred thousand usable report identities or that the counter should wrap when that width is exceeded. The number remains subject to the software's overall validation limits. Choose padding for readability and expected organizational use, and keep the allocation behavior separate from the presentation choice. This distinction prevents a year-end administrator from trying to edit existing numbers to make a list look like a newly restarted register.

Consider a fictional account preparing an examination dated December 31, 2026. The author first saves the report on January 2, 2027, using NDT-{YYYY}-{SEQ:5}. Assume, only for this example, that the allocated account sequence is 148. Because the inspection date was entered before saving, the assigned number is NDT-2026-00148. Its year component follows the examination date; it is not evidence that the report was saved or issued during 2026. The author records the real inspection date in the report and uses the saved record's own status and other project records to explain later review and delivery.

Now consider a different fictional draft saved on January 2 without an inspection date. Its date tokens use the UTC date at first save, so its year component is 2027. Adding the correct December inspection date afterward updates the document but does not retroactively replace the tracked number. Both outcomes can be explained accurately, but they arise from different first-save information. The practical improvement is to decide the date basis before saving, not to force an already assigned identity to change. If a client has a strict numbering expectation, resolve that expectation before the first tracked save or use a separately documented reference field.

A wrong inspection date, misspelled client name or corrected observation does not automatically mean a new report identity is required. First determine whether the author is correcting the same examination record or documenting a genuinely different examination. That is a project and record-control decision. The software offers draft editing and revisions, but it cannot decide whether two sets of observations belong to the same inspection event. Keep that reasoning explicit, especially when several visits concern the same asset. A familiar equipment identifier or project name alone is not enough to merge separate examination events into one report.

For an existing draft, make the justified content correction and save it under the same tracked identity. For an issued report, preserve the original and create a draft revision through the supported workflow. If the work is a new examination requiring a new report, begin a new draft rather than reusing an old record simply to keep an attractive number. Explain the relationship through appropriate references. Avoid editing narrative fields to pretend that a new report is an old issued revision, or that an old report was never distributed. Stable identity is useful only when the document's history and meaning remain truthful.

A method token records the selected method when the number is assigned. If the author later corrects the method field on a draft, the existing number remains stable. The identifier therefore should not become the only source for understanding the report's current technical scope. Read the method field, procedure reference, examination description and result table together. If the organization chooses a method-bearing numbering pattern, explain this limitation in its internal convention. A prefix can help with recognition, but it should never override the actual evidence or be treated as proof that a particular examination was performed.

The same principle applies to a project or customer code typed as literal text. A customer reference may change while the underlying examination remains the same. Keep the updated reference in the appropriate report field and preserve the saved identity, with a suitable explanation if the change matters to recipients. Do not assume the pattern is a live template that will regenerate every time a field changes. Once the first save assigns a number, the number's main job is reliable identification. If a proposed prefix is likely to change frequently, leave that information out of the identifier and use a searchable descriptive field instead.

Reserved sequence values can have gaps. The reporting workspace states this when explaining first-save numbering. A gap is not, by itself, proof that a report is missing, deleted improperly or issued without authorization. It also is not an invitation to manually reuse a value in a different record. Keep any external register honest about what it tracks: assigned saved reports, issued reports, received customer documents or something else. Those are different populations, and a sequential-looking list can become misleading if users try to force them all into a single uninterrupted count.

If a discrepancy matters, investigate the specific report reference and the relevant saved records rather than editing numbers to hide the visual gap. Record the question in the organization's normal document-control process and keep unrelated client data out of broad emails or shared spreadsheets. The tool's account counter is not a complete replacement for a company's controlled transmittal or issue register. It provides stable saved identities within the account. An organization that needs a separate controlled issue log should define and maintain that log deliberately, with clear links to report number, revision, status and the intended recipient.

Creating a revision of an issued report retains the report number and increments its revision. Restoring an editable JSON backup follows a different path: it opens as a new unsaved draft and receives a new tracked number when first saved. These choices support different intentions. Use the revision workflow when changing the issued record through its preserved identity. Use a restored backup when recovering editable content or intentionally starting a separate draft. Do not assume that a filename containing an old number gives the restored document the old record's issued status or revision history.

This distinction becomes particularly important at year-end, when users may duplicate a December template for January work. Copying a previous report's content can carry stale dates, customer references, conclusions or equipment information into the new draft. Review those fields before first save, because the initial date and method influence the newly assigned number. A backup is not a certification that its contents suit the new examination. Keep reused structure separate from reused factual statements, and replace any old inspection evidence with the actual new record. The saved identifier should then correspond to the new examination's intended identity rather than a convenient historical example.

A report number often leaves the reporting workspace in a filename, customer email or spreadsheet register. Protect its meaning during those handoffs. Microsoft's guidance on leading zeros and large numbers explains that Excel can automatically transform certain numeric-looking values. Store report identifiers as text when maintaining a separate spreadsheet, and verify the result after reopening an exported file. A sequence such as 00148 is an identifier component, not a measured quantity whose leading zeros can be discarded without considering the surrounding reference convention.

Include the separate revision and status where the recipient needs to distinguish versions. NDT-2026-00148 by itself may be insufficient if both revision zero and revision one exist. A human-readable register can also contain the inspection date and client reference without encoding every fact into the number. Check that the exported list refers to actual saved records and that its readers have legitimate access to the underlying documents. A private library URL is not a public customer portal. When a recipient needs the report, choose the intended PDF deliberately and verify its number, revision, status and contents before sending it through the approved communication process.

Before first save, check the intended examination, entered inspection date, selected method and numbering pattern together. Ask whether the number will be understandable without inventing assumptions about issue dates, annual resets or company-wide counters. Save the draft through the verified account, then record the actual assigned identity where your workflow requires it. If a save response is uncertain, preserve the open work and follow the application's recovery messages instead of repeatedly creating fresh drafts. The goal is one understood record identity for the intended examination, with deliberate new records only when the work calls for them.

At year-end, review a few representative scenarios rather than renumbering the archive. Include a late-saved prior-year examination, an undated draft, a correction to an existing record and a revision issued in a later year. Confirm that the team can explain each outcome and retrieve the intended version. Keep the short explanation beside the organization's numbering convention so a future author does not have to infer the rule from filenames. This routine is useful precisely because it deals with identity and interpretation. It does not decide the technical adequacy of the report, authorize inspection personnel or replace the responsible review of examination evidence.