A rent spreadsheet imports well once it has one header row, one row per person per rental, dates in a single format, and money stored as plain numbers rather than text. Split anything that crams two facts into one cell, delete the totals rows sitting inside the data, and keep the original file untouched. If you never kept a sheet, twelve months of bank statements and your signed leases are enough to build one.
Key takeaways
- One header row at the top, one row per person per rental, and nothing merged.
- Totals rows and blank spacer rows inside the data are the most common reason an import looks wrong.
- Store money as numbers. A cell containing a dollar sign and a comma is text.
- Split combined cells: address in one column, unit in another, resident in another.
- Pick one date format and use it in every date cell.
- Keep the original file. Work on a copy, and keep the sheet after you move.
The spreadsheet was not a mistake
A spreadsheet is the right tool for a while, and plenty of landlords run several rentals on one for years without a problem. It is free, it does exactly what you tell it, and nobody has to learn anything. Moving off it is not an admission that you were doing it wrong.
What usually changes is not the number of rentals but the number of people involved. The sheet lives on one laptop, so nobody else can see it. A resident asks what they paid in March and you scroll. A formula quietly breaks and a balance is wrong for two months before anyone notices. Nobody gets a receipt, nobody gets a reminder, and the only record of who agreed to what is a text thread. That is the moment to move, and the sheet you already keep is what makes the move easy.
What software actually needs from you
Importing sounds technical, but the requirement is simple: the file has to look like a table. A row is one thing, a column is one fact about it, and the top row says what each column contains. Everything that goes wrong in an import is a place where the sheet stopped being a table and started being a document that a person reads.
Work on a copy. Save your original untouched, then tidy the copy. If the import goes sideways you want to be able to start over from something you have not already reshaped.
- One header row, at the top, with a short name in every cell
- One row per person per rental
- No merged cells anywhere
- No totals rows or blank spacer rows inside the data
- One tab for the thing you are importing, not four things on one tab
- No colour-coding that carries meaning nothing else records
The four fixes that solve almost everything
First, money. A cell showing $1,250.00 might hold the number 1250 formatted to look like money, or it might hold the text $1,250.00. Software can add up the first and not the second. Strip dollar signs and commas so the cell holds 1250, and put the word rent in the column heading instead.
Second, dates. Pick one format and use it everywhere. A column with 03/01/2026 in some rows, March 1 in others, and 2026-03-01 in the rest will import as three different kinds of thing, and the mistake shows up as a lease that ends in the wrong year.
Third, combined cells. Anything like Unit 2 - John Smith or 2907 Wilson Bedroom 3 holds two or three facts in one place. Split them into their own columns: address, unit, room, resident. This is the single change that makes the biggest difference to how well an import lands.
Fourth, the totals. A row that says TOTAL with a sum in it looks like another resident to any software reading the file. Same for the blank row you left for breathing space, and the second header row halfway down where the sheet started a new property. Delete them from the copy.
The columns worth having
You do not need all of these, and a missing column is not a problem. But every one you fill in now is a question you do not have to answer later, and the first two are the ones that quietly cause the most trouble when they are missing.
Email addresses matter more than anything else on this list. Without them you cannot invite a resident to their own page, email a receipt, or send a rent reminder, so the first thing your new software wants to do is the one thing it cannot. If your sheet never held email addresses, gather them before you import rather than after.
- First name and last name
- Email address and phone number
- Property address, city, state, and ZIP
- Unit, and room or bedroom if you rent by the room
- Monthly rent and the day of the month it is due
- Move-in date and lease end date
- Security deposit held
- Late fee terms, if you charge them
- Notes worth keeping
Three sheets, not one
Most rent trackers are one sheet doing three jobs: who lives where, what came in, and what went out. Software keeps those apart, so it is worth separating them before you import rather than trying to explain one mixed sheet.
The first is the people and rentals list, using the columns above. The second is money received: date, resident, amount, and how they paid. The third is expenses: date, property, category, amount, and who you paid. If your sheet has a column per month with a payment in each cell, that is the one part that genuinely needs reshaping. Each payment wants its own row with its own date, because a column heading is not a date a computer can read.
- People and rentals
- Money received
- Money spent
- Each payment on its own row, with its own date
If you never kept a spreadsheet at all
Plenty of landlords have leases in a drawer and rent arriving in a bank account, and nothing in between. That is workable. Your signed leases give you every resident, the rent, the dates, and the deposit, which is most of the people and rentals sheet. Twelve months of bank statements give you what actually came in and what went out.
You do not have to reconstruct everything. A fair starting point is: every current resident with their real lease terms, the balance each one owes today, and this year's income and expenses. Older history stays in the bank statements and the drawer, which is where the tax rules expect your records to be anyway. The IRS asks you to keep the records supporting income, deductions, or credits until the period of limitations for that return runs out, and a shoebox of statements satisfies that just as well as a spreadsheet does.
Bringing the sheet into RentCaddie
This is the case RentCaddie handles best after a full guided migration. There is a named Excel and Google Sheets path, and a blank starter workbook you can download with the exact columns it expects already across the top. If you are tidying a sheet anyway, paste into that workbook and there is nothing left to guess.
If you would rather bring your own file, drop it in as it is. RentCaddie works out whether each file is people, money owed, money received, or expenses, and it looks up to thirty rows down for the real heading row, so a title, a date range, and a filter line sitting above your columns will not confuse it. It then proposes a match for every column and asks you to confirm on a review screen. Nothing is saved until you approve it, and if a batch lands wrong the whole import can be undone, keeping anything you have edited by hand since.
Two limits. It reads CSV, .xlsx, and .xls, so export a Google Sheet to one of those first. And because files are read in your browser, each is capped at 10 MB and 5,000 rows, so a long payment history should be split by year and dropped in as several files.
Common questions
Can I import a Google Sheet directly?
Export it first. In Google Sheets use File, then Download, and choose either Microsoft Excel or comma-separated values. Both import the same way, so pick whichever you find easier to check afterwards.
Why did my spreadsheet import wrong?
Nine times out of ten it is a totals row, a blank spacer row, or a second header row sitting inside the data, because each of those reads as another resident. Merged cells and money stored as text are the next most common causes.
Do I need to import years of history?
No, and it is often better not to. Current residents with their real lease terms and today's balances, plus this year's income and expenses, is a solid starting point. Keep the old spreadsheet as your record of everything before that.
What if one cell holds both the unit and the resident?
Split it into separate columns before importing. Anything of the shape Unit 2 - John Smith should become a unit column and a resident column, because software cannot reliably guess where one fact ends and the next begins.
Should I delete the spreadsheet once I have moved?
No. Keep it. It is a record of what happened, and record-keeping obligations outlast any software subscription. Put it somewhere safe and stop editing it rather than throwing it away.
What if my sheet has a column for each month?
That is the one layout that needs real reshaping, because a column heading is not a date software can read. Turn it into one row per payment, with a date column, an amount column, and the resident's name, and everything else follows.
Rental language, explained
Every term linked above, with a plain-English definition and a practical property-management example.
Browse the full property management glossarySources and methodology
Written to help independent landlords make an operational decision. Legal and tax topics are educational, not professional advice. Comparison claims use public vendor information; we do not invent hands-on testing.