Yardi Voyager HOA Data Import Failed: Migration Checks & Fixes

Most Yardi Voyager HOA import failures come from bad file format/mapping, missing required fields, invalid codes (GL, property, charge), date/amount formatting, or security/permission and environment mismatches. Check the import log for the exact row and field that failed, fix the source data to match Voyager’s required setup, then re-run in a small test batch. If everything already looks correct, the issue is usually duplicate keys, hidden characters, wrong import template/version, or a backend validation rule that only Yardi Support can see.

 

 Start with the error output (don’t guess) 

• Open the import job results/log and find the first failed record. One bad row can stop the whole batch.
• Copy the exact error text (example: “Invalid Property”, “GL Account not found”, “Duplicate Code”, “Date out of range”). That message tells you what to fix.
• Confirm the environment: you are importing into the correct database (test vs live). Imports often “fail” because they ran in the wrong place and references don’t exist.

 

 Validate prerequisites inside Voyager (most common miss) 

• Property/HOA entity exists and the import references the exact same ID/code. “Property” is the building/association record Voyager ties everything to.
• Chart of Accounts and GL accounts exist. “GL” is the accounting code list; if the file references an account not set up, Voyager rejects it.
• Charge codes / assessment types exist (dues, special assessment, late fee). If the import uses “MonthlyDues” but Voyager has “DUES”, it fails.
• Resident/owner records exist first if you are importing transactions. Transactions usually require a valid person/unit link.
• Security permissions: the user running the import must have rights to the module and import function. Lack of permission can look like a “system” failure.

 

 Check the file itself (format, mapping, and “invisible” problems) 

• Use the correct Voyager import template for your module and Voyager version. A slightly different column name/order can break mapping.
• Required fields not blank: IDs/codes, dates, amounts, unit, property, and any mandatory status fields.
• Date format: use a consistent format (often MM/DD/YYYY). Mixed formats or Excel auto-conversions cause rejects.
• Amount format: no currency symbols, no commas, use a dot for decimals. Negative amounts only where allowed.
• Trim spaces: leading/trailing spaces in codes (like “DUES ”) create “not found” errors.
• Remove hidden characters: non-breaking spaces, smart quotes, line breaks inside cells. Re-save as clean CSV and re-check.
• Encoding: if names have accents, use UTF-8 CSV; bad encoding can corrupt rows.

 

 Duplicates, keys, and sequencing (when “everything is correct”) 

• Duplicate unique IDs: unit codes, owner IDs, charge codes, invoice numbers. Voyager may require uniqueness even if your old system didn’t.
• Import order: properties and setup tables first, then units, then owners, then balances/transactions. Importing transactions before the master records causes failures.
• Cross-reference mismatches: the file references Unit “101” but Voyager stores “0101” or “101A”. Make the codes match exactly.
• Posting period/lock: accounting periods may be closed. If you import into a closed month, Voyager rejects postings.

 

 How to isolate fast (so you stop burning time) 

• Run a 5–20 row test import containing one of each record type. Fix until it passes, then scale up.
• Binary split: import half the file; if it fails, split again. This quickly finds the bad section.
• Compare one failing row to a known-good record created manually in Voyager and match fields exactly.

 

 When to contact Yardi Support (and what to send) 

• Contact support if the log is vague, the import crashes, or errors persist after clean mapping and test batches.
• Send import name, timestamp, environment, full error text, 5 sample rows (including a failing one), and a screenshot of the import mapping screen.