You mapped the spreadsheet, exported the template, uploaded it to Yardi Voyager — and three seconds later: rejected, 31 errors found. If you work with Voyager ETL imports, you've lived this. The good news: after enough migrations, the rejections stop looking random. The overwhelming majority trace back to five root causes.
1. Referenced codes that don't exist yet
The symptom: errors about unknown owner codes, property codes, or GL accounts — on data you know is correct.
The cause: Yardi's import modules have a strict dependency order. CommOwners must load before CommProperties. GL accounts must exist before leases reference them. If your batch imports properties before owners, every owner reference fails — not because it's wrong, but because it's early.
The fix: map your batch against the module dependency order before importing anything. If a file references codes created by another file, that other file goes first.
2. Mixed value formats in numeric columns
The symptom: square footage, rent, or unit-count fields rejected on scattered rows.
The cause: humans made the spreadsheet. The same column holds 1,200, 980 sqft, and 1.1k — all obvious to a person, all different to a parser.
The fix: normalise before mapping: strip units and separators, resolve abbreviations, and confirm the convention once for the whole column instead of fixing rows one by one.
3. Free-text where Yardi expects a code
The symptom: floor, status, or type fields failing on values like Ground, GF, or Vacant - Ready.
The cause: Yardi fields frequently accept only enumerated codes (0 for ground floor; specific unit-status codes), while source systems export human-readable labels.
The fix: build a translation table per field from Yardi's allowed values, and apply it consistently — the same label must always map to the same code.
4. Area fields that disagree with your configuration
The symptom: DSQFT0 (or other area fields) rejected even though the numbers look right.
The cause: area columns don't validate in isolation. DSQFT0 is the primary rentable area, and it must align with your CommPropAreaLabels, CommSQFTs, and CommPropConfigs setup. A mismatch anywhere in that triangle rejects the row.
The fix: check the property's area configuration first, then map area columns to the slots your configuration actually defines.
5. Cryptic error codes hiding simple problems
The symptom: ERR_FIELD_042 and friends — messages that name neither the row's real problem nor the fix.
The cause: Voyager's import validation reports at the field-code level. Translating that back to "row 47 references owner OWNER01, which isn't in this batch" is tribal knowledge.
The fix: keep a decode sheet of the codes you've met — or use tooling that translates them for you.
Or: stop the errors before Yardi sees the file
All five causes share a property: they're predictable. The dependency order is known. The allowed values are known. The area-configuration rules are known. Which means they can be checked before upload rather than debugged after rejection.
That's what PropETL does. It validates your file against 5,204 cross-module rules inside Claude — dependency order, value formats, code translations, area alignment — and reports problems in plain English ("Row 47: Owner code OWNER01 not found. Are you uploading CommOwners in this batch?"). You fix the two real issues in chat, and the file that reaches Yardi imports clean.
See your own error list disappear: start the free 24-hour trial and upload the file Yardi just rejected. No credit card, full access to all 306 modules.