A contact list can look orderly while containing several records for the same organization and one record that accidentally combines different people. Both problems matter during a property software import. Repeated records can make searches confusing, while an incorrect merge can attach information to the wrong identity. The objective is not simply to reduce the number of rows. It is to understand what each row represents before transferring it.
This guide offers a review method for operational contact data. It does not establish identity for financial, tax, legal, or screening purposes. Use the appropriate verification process for those tasks. Here, the aim is to flag possible duplicates, review them with suitable evidence, and preserve a record of decisions so the import can be explained and checked afterward.
Preserve the source before cleaning
Save the original export unchanged and record where it came from, when it was generated, and which filters were applied. Work on a separate copy. If your software exports vendors, residents, owners, or other contacts through different reports, keep those files identifiable. Combining them immediately can remove context that helps explain why the same name appears in more than one place.
Create a review worksheet that retains the original record identifier. Add fields for possible match, decision, reason, reviewer, and destination reference when known. Do not overwrite the source name with a cleaned name before preserving it. The original value may later explain why a record was matched or why the import produced a result that initially looked unexpected. A clean working file and a traceable decision history serve different purposes.
Define what counts as a duplicate
A duplicate identity is not the same as a repeated relationship. One vendor may serve several properties, and one person may appear in more than one legitimate role. Ask the destination provider whether a single contact can have those relationships or whether its structure uses separate records. Your cleanup should support that model rather than imposing an assumption that every repeated name must become one row.
Buildium's onboarding documentation identifies several data categories, including owners, residents, and vendors, that can be part of migration. That distinction is useful when reviewing apparent repetition across categories. A name in an owner list and a name in a vendor list may require careful handling even when they refer to the same person. Confirm the receiving system's expectations before merging records across roles or deleting one as redundant.
Normalize only for comparison
Create comparison fields that make obvious variations easier to spot while leaving original values intact. You might remove extra spaces, compare names without differences in capitalization, or place phone numbers in a consistent review format. Label these fields as comparison aids. They are not automatically the values you should import, and a match in a normalized field is not proof that two records represent the same entity.
Be cautious with aggressive cleanup. Removing all punctuation or shortening every organization name can make unrelated entries look alike. An abbreviation may be a familiar shorthand for one vendor and part of another vendor's actual name. Use normalization to generate a list of candidates for review, not to make irreversible decisions. The human question remains whether the records refer to the same contact in the operational context you are managing.
Use several clues together
Review identifiers, names, contact details, addresses, and the history or context available to authorized staff. A shared phone number might belong to a company's central office. A shared address might house several businesses. A shared surname may simply reflect unrelated residents. Treat each clue as information with limitations. The strongest review explains why the available details support a particular match rather than relying on a single convenient field.
In a fictional example, Harbor Repair and Harbor Repair Office share a business phone and have notes referring to the same service coordinator. That pair deserves review, but it should not be merged automatically. Another record named Harbor Repair North might be a separate organization or a branch that your destination system needs to represent differently. The invented example illustrates why a candidate list is only the beginning of the decision.
Separate exact repeats from ambiguous matches
An exact repeat across all relevant fields may be simpler to resolve than two records with conflicting details. Still, check whether each record carries different attachments, notes, or relationships before choosing a surviving record. Two identical contact cards can have different operational histories behind them. Removing one without inspecting those connections may leave information stranded or make it harder to understand prior work.
Put ambiguous matches in a separate queue. State the unresolved question precisely, such as whether two trading names belong to the same service provider in your records. Assign the question to someone authorized and knowledgeable. Do not let uncertainty disappear into a generic cleanup status. An explicit unresolved row can be held out of the import or handled through the provider's supported process while the identity question is reviewed.
Review conflicting contact information
When two likely matching records contain different email addresses or phone numbers, determine what each value represents. One may be a general office contact and another a specific coordinator. One may be obsolete, but that cannot be assumed from the order of rows or the date of the export. Record the source and purpose of each value before choosing what belongs in the destination fields.
Use a controlled verification process when contacting a vendor or reviewing internal records. Do not send sensitive information simply to ask whether an address is current. For operational cleanup, a reviewer can document that a contact method was confirmed through an established channel without copying unnecessary private details into the migration worksheet. Keep the review proportional to the task and preserve information only where it has a clear purpose.
Inspect attachments and linked work
Before consolidating a record, identify the documents, work orders, notes, and other relationships attached to it. Ask the software provider whether a supported merge transfers those items and what remains visible afterward. If the product has no merge function, request guidance on the approved migration approach. A manual deletion is not a substitute for understanding how related records will be preserved.
Test the process with fictional contacts in a controlled environment. Give each sample contact a different note and attachment, then perform the supported consolidation procedure. Check whether the result preserves both items and whether the original references remain traceable. Record observed behavior rather than assuming that a feature named merge necessarily includes every type of connected information. That evidence should inform your real cleanup plan.
Prepare an import decision for every reviewed row
Use clear outcomes such as keep separate, consolidate through the supported process, update a specific field, or hold for review. Add a short reason and the identifier of the destination or surviving record when known. Avoid an outcome called fixed that explains nothing. The person preparing the import should be able to follow the decision without repeating the identity investigation or guessing what the reviewer intended.
If a field is intentionally left blank, state why where appropriate. A blank because the information is unknown differs from a blank because the value is not needed in the destination. Do not fill gaps with invented values simply to satisfy a template without consulting the provider. Ask how missing information should be represented and whether the record can be imported safely in its current state.
Validate the prepared file
Compare the cleaned import file with the decision worksheet. Count how many records were retained, consolidated, excluded, or held. Then inspect identities and relationships, because a correct total can still conceal a wrong match. Rentec Direct's export documentation describes distinct lists and report downloads, reminding reviewers to verify which source population a count represents. An active list should not be compared casually with a broader historical inventory.
Check that source identifiers remain available in the crosswalk even if the destination will assign new ones. Confirm that organization names and contact details have not shifted into the wrong columns during spreadsheet editing. Review a sample from each decision category, including records deliberately kept separate despite similar names. Those negative decisions are important evidence that the review did not simply merge everything that looked alike.
Recheck after the trial import
Run a controlled test using the provider's supported method and inspect the resulting contacts. Search for the deliberately similar names and trace their associated properties or work records. Confirm that the expected number of distinct identities remains. If a problem appears, investigate the mapping and import behavior before rerunning the full file. Repeating an import without understanding whether it creates or updates records can make cleanup more difficult.
Preserve the original exports, review worksheet, prepared import file, and trial results together under suitable access controls. Your final record should explain why each consolidation occurred and where the information went. A good duplicate review leaves fewer ambiguities, not merely fewer rows. It gives the next authorized person a dependable contact list and a way to understand the decisions that shaped it.
Review inactive contacts separately
An inactive record is not automatically a duplicate or an error. It may describe a former service relationship that remains relevant to historical work. Decide what the migration should do with inactive records before cleanup begins, and ask how the destination represents them. Keep that scope decision separate from identity matching. If two records represent the same organization but cover different periods, the supported consolidation process must preserve the context you need. A reviewer should be able to explain whether a row was excluded because it was redundant, outside the transfer scope, or awaiting clarification. Those explanations are not interchangeable.
If you plan to evaluate Buildium, bring your anonymized record categories and unresolved mapping questions to the onboarding discussion. Confirm the supported way to handle duplicate candidates and historical relationships before preparing a final import file.
Sources and further reading
Sources checked October 6, 2026. The evaluation exercises are Homzora editorial recommendations, not vendor instructions or guarantees.