Importing your data
Nobody types three hundred buildings, and nobody types the vendor list twice. So inletAP reads a file you export from whatever you run today — a property management system, an accounting package, or the spreadsheet that has been the real system of record all along — and turns it into properties, units, vendors and ownership entities.
This page walks one import from your own export to a set of records you can see. The columns, the matching rules, the limits and the error messages live in the import reference; come back to this page when you want the order of events.
Two things frame everything below, because they decide what this feature is.
It reads a file you exported. There is no connection to your other system. You produce the file, you upload it, and that is the whole of the arrangement. Nothing is fetched from another product, nothing is sent back to it, and nothing keeps running afterwards. It is a setup job you do once, and repeat later if your list changes.
The preview writes nothing. Uploading a file produces a record of the request and a row-by-row report of what the file would do. No property, unit, vendor or entity is touched by it. The commit is the only phase that writes, and the last step on this page describes what it does when it goes wrong.
Before you start
- You need to be an Admin, a Controller Approver or an AP Specialist. Setting up master data is the AP specialist's job, so it is not reserved for admins. A Viewer cannot import anything, and a member limited to specific buildings may import units for a building they hold but not properties or entities.
- You need a file you exported yourself, as
.csvor.xlsx. A workbook is converted to CSV in your browser before it is sent, because the importer reads CSV. - Import one kind of record per file, and mind the order. If your buildings are owned by more than one legal entity, import the entities first: the properties file can only name an entity that already exists.
- For units, create the building first. A units file is one building's doors, and you choose the building before you choose the file.
- Check the size. 5,000 data rows and 2 MiB per file. In practice the row cap is the one you meet, and the answer is to split the file. The full list of limits is in the import reference.
Nothing here costs you anything against your plan. The allowance counts invoices at extraction; properties, units, vendors and entities are unlimited on every plan, the free one included.
1. Export the list from your own system
Export whatever your system gives you and do not tidy it first. Ten of the twelve property management systems we surveyed export through a report builder, which means two customers on the same product produce two different files: different columns, a different order, a title row above the headings, blank spacer columns. The mapping step in a moment is built for exactly that, so a raw export is a better starting point than a spreadsheet you spent an evening rearranging.
A rent roll that lists every unit of every building is a units file for one building at a time — or a properties file, if what you want out of it is the buildings.
Invoices are not importable, and neither is history. This is master data: the records your invoices get coded to.
2. Open Import and say what you are importing
Import is in the left-hand navigation. There is also an Import button in the header of the Properties and Vendors screens, and an Import properties or Import vendors button when either screen is still empty.
The flow has six steps and the rail at the top names them: What, Source, File, Columns, Preview, Report.
On What, choose properties, units, vendors or entities. Units ask you for the building here, before anything else happens.
3. Choose the template, or bring your own file
The Source step offers two starting points.
Download the template builds an .xlsx workbook with two sheets. Data carries the headings, with the required ones marked and one filled-in example row. Instructions restates the same column list as prose, for anybody who opens the file on a phone or in Google Sheets and never sees a cell note. The workbook is built from the same column list the importer reads, fetched when you press the button, so it cannot drift from what the importer accepts. Delete the example row or leave it: a row that is still byte-for-byte identical to the template's own example is left out of the import, and you are told it was.
Or tell us what exported it. Four layouts are recognized on sight — the inletAP template, and the import templates published by DoorLoop, Rentec Direct and TenantCloud. Everything else goes through "A file of my own", which reads your header row and has you confirm the columns on the next screen. That is the ordinary path rather than a degraded one: AppFolio, Yardi, RealPage, Entrata, MRI, Rent Manager, Propertyware and ResMan all take it, because none of them publishes a layout that could be pinned down. A spreadsheet somebody maintains by hand works exactly as well.
Reading an export is not a connection to the system that produced it. Nothing is sent back to it and nothing there changes.
Then choose the file on the File step. Nothing is saved by that step.
4. Check the columns
This is the part that matters, because most exports do not look like our template.
- inletAP finds the heading row itself, looking down the first fifteen rows of the file for the first one that looks like headings. When they were not on row 1 the screen says which row they were found on and how many rows above it were treated as a title block.
- It proposes a column for each of our fields, and it always shows you what it proposed. Nothing is matched silently.
- Beside each of your columns you get up to three real values out of your own file. That is what tells you that the column called
Descris the building name and the one calledProp Cdis the code. - Your columns that we are not reading are listed. That is information rather than an error: an export carries plenty we have no field for.
- A required field can point at any column in your file. A short code can come from your own property ID, or from the property name. What it cannot be is empty — a code nobody chose is a code nobody can look up.
- If nothing feeds a required field, every row reads as an error naming that field. The file is not rejected; you fix it on the screen in front of you.
Press Apply these columns and the preview is rebuilt from the same uploaded bytes. You do not upload the file again to change a mapping.
If every required column matched on the first attempt — and our own template always does — the wizard takes you straight to the preview. The Columns step stays in the rail, and you can open it to disagree with what we matched.
5. Read the preview
Every data row in the file, in file order, with the line number it came from. Not a sample, and error rows are not filtered out.

Four things to read here.
The counts above the table — how many rows would be created, updated, left unchanged and refused, out of how many rows in the file. Warnings sit there too.
The outcome on each row. create means nothing in your workspace matches it. update means it matches one existing record and at least one field differs. skip means it matches and changes nothing, or it repeats a record named earlier in the same file. error means it cannot be imported, and the row says why, naming the column and quoting the cell.
The field-level difference on an update row. Open the row and the panel lists the fields that actually differ, each with the stored value beside the new one. A field your file leaves blank is not in that list, because a blank cell means "leave this alone" and never "clear it".
The rows that need attention. The filter above the table opens on them, which matters when twelve rows out of nine hundred are the ones you have to look at.
Errors do not stop the preview and they do not stop the import. They are the rows that do not get written. You can import the rest now and fix them afterwards, or fix them first and upload again.
A preview is kept for seven days. After that it has to be uploaded again, because the file on your disk may have moved on and committing a stale comparison would write the wrong thing.
6. Commit, and read the report
The button reads Import 42 rows, with your own count of creates plus updates in it. It asks you to confirm, naming the same numbers again, and Import them starts the write.
You should now be looking at the Report step: a headline saying what was written, badges reading created, updated, unchanged, not imported and rows in the file, and a line comparing what the preview predicted against what actually happened. A workspace that moved between the two phases shows up there as a difference rather than as a surprise.
Two guards sit on this step. The commit refuses a preview it cannot tie to the bytes you looked at — if the file changed, upload it again and read the new preview. And the commit runs the same matching code the preview ran, which is what makes the two agree.
Check it worked
- Open the screen the records live on. Properties, Vendors or the building's units. The count in the header is the fastest check, and a name you recognize from the bottom of your file is the next one.
- Open one record you know the import updated and confirm the field the preview said would change. The preview's difference panel and the stored record should now agree.
- Read the Audit Log. Every commit writes one
import.committedentry with your name against it, the file name, the object type and the counts. One event per run, never one per row, so "where did these three hundred buildings come from" is answerable months later.
If the import stops part-way
The commit writes row by row and checkpoints every 100 rows. A row that fails does not stop the run: it is recorded with its reason and the rest carries on. So the commit can apply part of a file, and when it does the report says so — the import stopped, N rows were saved before it did.
Nothing is half-written and nothing is lost. The repair is to upload the same file again. The matching runs on the commit exactly as it ran on the preview, so the rows already written are found and updated rather than added a second time, and the rows that never arrived are created. That is what makes the import idempotent: the same file twice is the same result, which is why "upload it again" is a real instruction rather than a hopeful one.
Where to go next
- Import reference — every column and the spellings it answers to, the matching rules, the limits and what each error means.
- Roles and permissions — who may run an import.
- Splitting an invoice across properties — what the door count and square footage you just imported are for.
- Quickstart — the fifteen-minute path from a vendor email to a posted bill.