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.

Two things are worth saying before anything else, because they decide whether this page is useful to you.

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. Every import is two phases. The first one reads your file, works out what each row would do to your workspace, and shows you the lot — row by row, field by field. No property, unit, vendor or entity is touched until you press the button on the Preview step, which reads Import 42 rows with your own count in it, and confirm.

What you can import

One kind of record per file, and the order can matter: if your buildings are owned by more than one entity, import the entities before the properties, so the properties file can name them. 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.

Where it lives

Import in the left-hand navigation. There is also an Import button in the header of the Properties and Vendors screens, an "Import with a preview" link on a building's Units screen, and an "Import properties" or "Import vendors" button on an empty Properties or Vendors screen. The flow has six steps and the rail at the top names them: What, Source, File, Columns, Preview, Report.

Admins, Controller Approvers and AP Specialists can all run an import. It is setup work, so it is not reserved for admins.

The template

On the Source step there is a button that builds an .xlsx workbook and downloads it. It has two sheets:

• Data — the headings, with required columns starred and shaded, and one filled-in example row. Hover a heading and you get a note describing that column, its accepted values, and the other spellings the importer will recognize for it.
• Instructions — the same column list as prose, plus what each column is for.

The workbook is built from the same column list the importer reads, fetched when you press the button. It cannot drift from what the importer accepts, because there is no second copy of the list to drift.

Delete the example row or leave it — a row that is byte-for-byte identical to the template's own example is left out of the import, and you are told it was.

When your columns are not our columns

This is the part that matters, because most exports do not look like our template. 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, different order, a title row above the headings, blank spacer columns.

So there is a Columns step between the upload and the preview, and it is a normal part of every import rather than a fallback.

• inletAP finds the heading row itself, looking down the first fifteen rows for the first one that looks like headings. If it picked the wrong row you can point it at the right one.
• 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 Descr is the building name and the one called Prop Cd is the code.
• Your columns that we are not reading are listed. That is information, not an error — an export carries plenty we have no field for.
• If nothing feeds a required field, every row reads as an error naming that field. The file is not rejected; you fix it by choosing the column 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.

The four layouts we recognize on sight

Those four publish a fixed layout, so their headings are already mapped for you. Every other system works through the generic template and the mapping step, and that is the ordinary path rather than the degraded one — including AppFolio, Yardi, RealPage, Entrata, MRI, Rent Manager, Propertyware and ResMan, none of which publishes a layout we could pin down. A spreadsheet somebody maintains by hand works exactly as well.

When your file carries a heading that gives its origin away, the screen says which layout it looks like and offers to read it that way. It is a suggestion, and it changes nothing until you accept it.

What the preview shows

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.

An update row carries the field-level difference: 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".

An error row names the column and quotes the cell — "n/a" is not a whole number for Square feet rather than "row 412 is invalid". Errors do not stop the preview and they do not stop the import; they simply do not get written.

Above the table are the counts: how many rows would be created, updated, skipped and rejected, out of how many rows in the file. Warnings sit there too — a heading row found somewhere other than row 1, repeated records collapsed, postal codes that a spreadsheet may already have turned into numbers.

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. The copy of your file goes at the same moment — see the limits below.

How a row finds an existing record

This is what makes a second import an update rather than a second copy of everything.

Aliases, codes and names are compared without regard to capitalization. A unit label is compared exactly, because 4B and 4b are two doors on a vendor's invoice until a person says otherwise.

A row that matches more than one record is an error, never a guess. It is reported naming both records it found, and nothing is changed until you resolve the duplicate. Two buildings sharing a code is a state your workspace can be in, and picking one of them would file somebody's invoices against the wrong building.

Within a single file, the first row naming a record wins and the later ones are skipped, each saying which line it lost to. That case is not unusual — an export with one row per unit repeats its building on every row, so a 300-door portfolio arrives as 300 rows naming twelve buildings.

Committing, and what happens if it stops

The commit writes row by row, in batches of a hundred. 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 if it does, the report says exactly how much and where it stopped.

The repair is to upload the same file again. The matching above runs on the commit as well as on the preview, so the rows already written are found and updated rather than added a second time. That is what makes the import idempotent: the same file twice is the same result.

Two further guards on the commit:

• It refuses to write a preview it cannot tie to the bytes you looked at. If the file changed, upload it again and read the new preview.
• The report shows what was predicted against what actually happened, so a workspace that moved between the two phases shows up as a difference rather than as a surprise.

Every commit writes an entry to the audit trail with who ran it, the file name, and the counts.

The columns

Required columns are the ones the import cannot identify a record without. Everything else is optional, and a blank cell leaves the stored value alone.

Header spellings are matched loosely — capitalization, spaces, underscores and hyphens do not matter, and a set of common alternatives is accepted for each column. A heading we do not recognize is listed for you on the Columns step, never rejected.

Properties

Which entity owns the building

Entity is optional, and it behaves differently from every other column, because an ownership entity is a legal record with an EIN and a filer address on it.

• The entity has to exist already. An import never creates one from a name in a spreadsheet. A name that matches nothing is an error row telling you to create the entity first; a name that matches two entities is an error row naming both. Neither is guessed.
• If your file names no entity and your workspace has exactly one, every building in the file is attached to that one. You are not asked to take that on trust: the entity appears on each row in the preview like any other field, and the run says in words how many buildings it will attach and to which entity. Reject it by adding an Entity column and uploading again.
• With two or more entities and no Entity column, the field is left alone and you choose. A building can be imported without an entity.
• A building that already belongs to an entity is never moved by that fallback. Only an Entity column you wrote yourself can change an existing building's owner, and when it does, the change appears in that row's field-level difference like any other edit.

That last point is worth knowing: a building's owner is set when the building is created, and the building's own page cannot move it afterwards. An import with an Entity column is the way to correct one.

Five property fields are deliberately not importable: the auto-approve threshold, the primary and backup approvers, the default GL account and the cost center. A file carrying those columns imports everything else and tells you which columns it refused. They are money controls, and they are changed on the building's own page by somebody with permission to change them.

Units

Pick the building before you upload; the file is that building's doors. Importing units does not change the building's door count — the Door count on a property is a separate figure used for splitting costs by unit, and you set it yourself. Re-importing a rent roll also never brings back a unit somebody retired on purpose.

Vendors

Entities

If you are setting a workspace up from nothing and your buildings are owned by more than one entity, do this file first. The Entity column on the properties template can only name an entity that already exists.

Limits and small print

• 5,000 data rows and 2 MiB (2,097,152 bytes) per file. A bigger file is refused with its row count, and splitting it into parts is the answer. In practice the row cap is the one you meet: a 1,500-door portfolio exported with every optional column is well under 100 KB.
• The importer reads CSV. You can choose an .xlsx workbook and your browser converts it to CSV before it is sent; a .csv is sent as it is. There is no reading of PDFs or scans here — this is a spreadsheet, not a document.
• Postal codes are text, always. They are never turned into numbers. If your spreadsheet already dropped a leading zero before you exported, the preview warns you how many look suspect, because by then nobody can recover it but you.
• A malformed quote is refused with its line number rather than guessed at.
• Importing costs nothing against your plan. The allowance counts invoice documents at extraction; properties, units, vendors and entities are unlimited on every plan, including the free one.
• Your uploaded file is held only while the preview is open. inletAP keeps a copy so it can rebuild the preview when you change a column. Committing the import clears it, discarding the preview clears it, and a preview nobody finishes is expired and cleared seven days after the upload. The record of the preview stays — the file name, the counts and what each row would have done — so you can still answer where a set of records came from.

Where to go next

• 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.
• Exports reference — the other direction: getting approved bills out of inletAP.
• Quickstart — the fifteen-minute path from a vendor email to a posted bill.