Supplier names became unreadable after an accounting import

When supplier names or addresses turn into unfamiliar symbols, compare the untouched export with each later version before editing the names manually. Locate the first step where correct text became incorrect. That may be the export, a spreadsheet import, a file conversion or the receiving application. Correcting the conversion at that point can recover the whole affected population. Replacing characters one supplier at a time can conceal the cause and introduce new errors.

The W3C explains that character encodings map stored bytes to characters, while fonts determine how those characters appear. It also notes that changing an encoding declaration does not convert the underlying bytes. Those distinctions help diagnose the problem. A missing font, an incorrectly decoded file and a file saved after damaging conversion require different repairs. The finance team should preserve the evidence and involve the person responsible for the import process.

Keep the supplier's stable source identifier attached to every comparison. A readable name is useful, but it is not enough to prove that the imported vendor is the right legal counterparty. Compare the source record, approved supplier documentation and target identifier. Where a name contains accented characters or a non-Latin script, ask someone competent to verify the actual text. Do not assume that removing unfamiliar characters produces an acceptable legal or commercial name.

Separate a display limitation from a changed value. If one application shows a box for a character but an approved export preserves the intended text, the stored value may still be correct. If the exported value itself contains a replacement character, the information may already have been lost in that copy. Inspect the source bytes and decoding settings with technical support. Avoid repeatedly opening and saving the only remaining original while trying different options.

The same issue can affect addresses, product descriptions, invoice references and payment narratives. Search for the affected pattern across the imported population, then review the actual fields rather than assuming every unusual character is an error. A valid supplier name may contain punctuation that a simplistic cleanup rule deletes. The proposed fix should target the known conversion defect and preserve legitimate text, including names that happen to resemble the damaged pattern.

Confirm the source file's encoding with the exporter or documented format. Configure the receiving tool to interpret that encoding, then save a separate working copy in a format supported by the destination. Record the conversion settings. A file extension such as CSV does not tell the operator everything needed to decode its contents. If the source supports an explicit UTF-8 export, verify that the resulting file and the import settings agree rather than relying on the option's label alone.

Test a small set of known supplier names before repeating the full import. Include the scripts, accented characters and punctuation present in the real population, using appropriately protected records. Compare the resulting values character for character with the approved source. Then export the target records again to confirm that the receiving system preserved them. This catches a workflow that looks correct in the preview but changes text when it stores or re-exports the record.

If the damaged copy has replaced original characters with a generic symbol, the missing information may not be recoverable from that copy alone. Return to a fresh source export or verified supplier documents. Mark uncertain reconstructions for review. Do not guess a business name from a partial match or automatically merge it with the nearest familiar name. Record which values came from source restoration and which required a separate approved correction.

Identify whether the import only changed display text or also changed matching and routing. A vendor-matching rule based on names may have created new records, combined unrelated suppliers or left invoices unassigned. Compare supplier counts and stable identifiers before and after the failed import. Inspect invoices attached to affected suppliers and check whether any automated document or payment process used those records. Keep uncertain routing on hold until the correct relationship is established.

For an illustrative migration, 600 source suppliers become 608 target suppliers because eight damaged names fail an existing-name lookup. Renaming those eight records will not automatically move their invoices onto the intended existing suppliers. First determine the correct target for each source identifier, then use the application's supported duplicate-resolution process. Check balances and attachments afterward. If a payment was already sent, confirm the actual recipient through the payment record and the bank rather than the repaired display name.

Review customer-facing outputs as well. Purchase orders, remittance notices and tax-preparer schedules may have been produced from the corrupted master data. Decide which documents need reissue and keep a record of the correction. Do not silently replace signed or filed documents. The appropriate owner should determine the permitted correction procedure for those records. A technical text repair cannot resolve every legal or accounting consequence of an incorrect document.

Save a non-sensitive encoding test file with the import procedure and use it after exporter, spreadsheet or destination changes. The file should include realistic character patterns without real private supplier information. Add an explicit check for replacement characters introduced during conversion, but treat flagged records as items to investigate rather than automatically deleting symbols. Record the supported file format and encoding where the next operator can find them.

Retain the original export, the corrected conversion and the approved mapping for this repair according to the company's record policy. Close the incident only after the names, supplier identities and dependent records agree. Give the finance owner a concise list of affected records, documents reissued and any unresolved reconstruction. The next import should begin with a verified interpretation of the file instead of a manual cleanup after records have already been created.