Recover a UK company-number import after leading zeros were lost

Recover a damaged UK company-number import from unchanged source evidence, then test the repaired identifiers through export and re-import. Do not restore missing characters by guessing a familiar length: rows without a reliable original identifier remain quarantined.

Freeze the failed batch and define what was damaged

Stop using the affected batch for account matching while you establish what changed. Save the supplied file, the file actually imported and an export of the resulting records as separate read-only working references. Note their dates, filenames and the affected batch identifier. Do not overwrite the supplier file with a repaired copy. If an account has already acquired activities after the import, record that fact before deciding how to correct its identifier; deleting the batch may destroy unrelated work.

Identify the specific failure rather than labelling the whole list dirty. A source value may have contained leading zeros that disappeared when a spreadsheet treated it as a number. Alternatively, the supplied file may already have been damaged, or a later import mapping may have changed a text field. Compare the earliest available version with the failed output. A change in display alone is different from a change in stored characters, and those cases require different evidence.

Create a repair ledger with a stable source-row reference, the identifier exactly as supplied, the damaged value, the evidence location, the proposed action and a quarantine reason where needed. Keep company name and address as supporting context, not substitute identifiers. The row reference should survive sorting. Otherwise, a technically correct value can be pasted onto the wrong company during repair, creating a harder identity problem than the original loss of zeros.

Find an unchanged original instead of inventing a format

Inspect the source using a method that shows the underlying text, rather than relying only on a formatted spreadsheet cell. For a CSV, a suitable text viewer can show whether the zeros are actually present in the file. For a workbook, inspect the original cell value and its type in an untouched copy. A custom number format may make a short numeric value look padded without proving that those characters existed in the source or will survive export.

Microsoft explains that Excel can remove leading zeros during automatic conversion and describes importing identifier columns as text through its data-import tools. Its guidance distinguishes preserving data from applying a display format. Use the instructions applicable to your installed version and inspect any automatic type-conversion step. This is a prevention measure for the next import, not evidence that a particular damaged value should receive a particular number of zeros. Recovery still depends on a reliable original.

Where the original supplier file is unavailable, a current official company record may contribute independent identity evidence, but do not turn a similar company name into an automatic match. Check the full identifier and the context needed to distinguish entities. Document the source and review decision. If the link remains ambiguous, leave the row on hold. A field that looks complete after padding is not a recovered identifier merely because it resembles a plausible registration format.

Populate the ledger with accepted and unresolved cases

The following cases are entirely fictional and are not records of actual UK companies. In source row R17, an unchanged test CSV contains the illustrative text identifier 00001234, while the failed export contains 1234. The original source-row key, company label and batch reference agree. The ledger records the unchanged CSV as recovery evidence and proposes restoring exactly 00001234. It does not infer the value from the four remaining digits or claim that this illustrative number belongs to the fictional company.

In fictional row R18, only the damaged value 5678 remains and the supplier cannot provide the original. Two supporting labels conflict. The ledger records the original identifier as unavailable, keeps 5678 only as the damaged observation and sets the decision to quarantine pending reliable evidence. It does not manufacture 00005678. A reviewer can see why R17 is repairable and R18 is not, even though both damaged strings could be made to look similar by applying the same display format.

A third fictional row already contains an unchanged alphanumeric identifier. The repair does not remove letters or force it through a numeric-only rule. The original characters are retained and checked against the actual source. These constructed cases demonstrate the decisions the ledger must support; they are not reported test outcomes from a real customer system. In a live batch, every released row needs its own evidence and observed round-trip result rather than borrowing acceptance from the example.

Prepare a repair file without moving account histories

Build the correction file from the stable row or record identifiers supported by your actual import process. Include only the fields required for the authorised correction. Preview which records would be updated and which would be created. If the tool cannot safely target existing records, do not assume that another import will replace the damaged values. Use its documented correction method or ask the responsible administrator to establish one before changing the live account data.

Keep histories, objections and open opportunities attached to their existing records unless a separate reviewed decision establishes that the records themselves are wrong. This task repairs an identifier field; it does not authorise merging companies or resetting contact restrictions. Record any accounts that were incorrectly linked because of the damaged values as separate exceptions. Restoring the source string does not automatically undo those links, and a bulk overwrite could conceal the evidence needed to investigate them.

Ask a second responsible person to compare the proposed correction against the preserved source and the update preview. They should check row alignment, unchanged records and quarantined rows, not simply whether the new column contains zeros. Save the reviewed repair file separately from the source. This guide does not assume an automatic LDM recovery feature or a particular CRM import mode. The correction method must be supported by the actual system and the permissions available to your team.

Check the exported characters through a controlled round trip

Use an isolated copy or the smallest authorised test supported by your process before applying the full correction. Import the evidence-backed repair rows with the identifier field treated as text. Export the resulting identifier values and compare them character for character with the accepted recovery source, keeping the same stable row mapping. Opening the export normally in a spreadsheet can repeat the original conversion, so inspect it without a new unrecorded type inference.

Log the actual result for each tested row. The acceptance condition is exact equality of the intended identifier and exported value, together with the correct destination record. A screenshot showing padded cells is insufficient. Check that quarantined rows stayed out, untouched identifiers stayed unchanged and the importer did not create duplicate accounts. If any of these checks fails, retain the failed output and stop the batch. Changing the display format until it looks right does not resolve the observed failure.

After the authorised correction, repeat the relevant export comparison for the complete released set and record any exceptions. Preserve a route back to the pre-correction values using the original record keys. Whether rollback can be performed safely depends on intervening changes and your system, so rehearse it in the controlled copy rather than promising a universal undo button. A successful field repair is complete only when the intended values survive the actual import path and the affected account links have been reviewed.

Close the batch with evidence rather than a clean-looking column

The handover includes the frozen source, the damaged export, the reviewed repair file, the completed row ledger and the observed round-trip comparison. Give unresolved rows an owner and a specific missing item, such as the original supplier extract. They remain excluded from the repaired release. Report released and quarantined rows separately; do not describe the whole batch as recovered when some identifiers are still unknown. No fabricated completion percentage is needed to make that status useful.

This is a damaged-import recovery task, not a routine deduplication schedule. Its final decision depends on proving the original characters and demonstrating their survival through the failing path. General list cleansing can identify suspicious records, but it cannot supply missing identifier evidence or prove that an importer preserved it. Keep the ledger available to the next person handling the file so that an apparently convenient spreadsheet edit does not recreate the same damage.

Sources, checked 18 October 2026: Microsoft Support, Keeping leading zeros and large numbers, https://support.microsoft.com/en-us/excel/keeping-leading-zeros-and-large-numbers ; GOV.UK, Get information about a company, https://www.gov.uk/get-information-about-a-company . Source claims concern spreadsheet conversion and available company information only. The ledger and fictional cases are editorial recommendations, not real company identities, software guarantees or observed customer results.

You can test this in practice with open email infrastructure statistics for domains on check.live-direct-marketing.online.

FAQ