Bring your book across

What this screen is for

Bring your book across turns the spreadsheet your old system exported into client records in Aether. You drop the file in, Aether reads it and matches its columns to fields it knows, you review what it could not match, and nothing is written to your client book until you approve. It is the first thing a new firm does, so this guide is mostly about what happens to a sheet between the drop and the approval.

The screen walks six steps: upload, auto-map, review and fix, readiness, approve, import. Every step before approve is a rehearsal. Approve records who approved and what they decided, and import is the only step that writes households, clients and their records into the shared tables the rest of Aether reads.

Who can run it

Only a firm admin. Migration writes the firm’s whole book in one pass, which is a heavier action than any single screen, so the route admits an adviser whose role is admin and refuses everyone else. A non-admin adviser who opens the page sees that sentence in place of the wizard, with the reason, so they know to ask their admin rather than wonder whether the page is broken.

What the wizard takes

CSV files, one or several in a single drop. Each file is read on its own, and you can add more files to the same run before you move on. A ZIP of data is refused with the reason: Aether reads an archive as one package with one record type per file, so it cannot make the wide-sheet offers described below for anything inside it. Unzip it and drop the CSV files themselves. A ZIP of client documents (PDFs, letters, statements) is different: the wizard asks which kind of ZIP it is, and a documents archive goes into the vault as archive items linked to the households it names.

Every upload passes through one checkpoint that looks at the bytes, not the file name, before anything is stored. A file that is not what its name says is refused there. A file is capped at 75 MiB, a sheet at 100,000 rows or 2,000,000 cells.

One wide sheet, several record types

An export is almost never one tidy file per kind of record. It is one wide sheet: a row per client, and across that row the household name, the client’s own details, a risk profile, sometimes the super balance and the insurance cover, all side by side. Aether does not need you to split it. One file can feed several record types, from the same rows, linked by row.

When a file is read, Aether decides what it is (a client list, say) and extracts that. It then looks at the column headers and works out which other record types the sheet plausibly carries. A record type is offered when every field that is required to identify one of its records is present among the headers, matched with confidence from the header names alone. A header that identifies two different types is evidence for neither. Under “I read your file as”, the wizard lists what it read the file as and then “It also looks like it carries:”, with an unticked box per offered type and the columns that are the evidence for it.

The boxes start unticked on purpose. What Aether read is extracted; what it can see beyond that is a question, and a question you have not answered is not a yes. Tick the types that belong and the file is read again with that set. Nothing is imported at that point, and the columns are matched again for each new type. Two record types are never offered, estate documents and document files, because the columns that would identify them look like too many other things; choose those by hand from the “Add another type” list if a file holds them.

For the types you tick, each row is judged on its own. A row becomes a risk profile record only if its risk-profile cells are filled; a client whose profile cell is empty produces no profile record rather than an empty one you would then have to clear. The type Aether read the file as is not filtered this way, so a client list with a blank column still yields a client per row and the gap is reported later, where you can see it. A row’s child records point back at the client on the same row, which is what “linked by row” means.

There is a ceiling. Rows multiplied by ticked types may not exceed 200,000 records, and the wizard refuses at the moment you tick rather than after you wait. A sheet at the 100,000-row limit can carry two types, not five.

The mapping pass, one per type

Matching a column to an Aether field happens per record type, not per file. The same header is matched once for the client type and again for the risk-profile type, because “Name” means the client’s name on one and the linkage back to that client on the other. The review step still reports one line per column your spreadsheet actually has, not one per type: a six-column sheet ticked to three types is matched eighteen times underneath, and you read it as six columns. A column is called matched when it reached a field on any type, and a decision you make on a column applies to every type’s copy of it.

Each match carries a confidence and a status. Aether matches a header by an exact field name, by a known alias, or loosely by the shape of the values in the column (dates, dollar amounts, email addresses), and it tells you which on the row. A match at the confident tier is suggested; a loose one needs your review. You can confirm a match, change it, or leave the column out. Columns Aether could not place at all are handed to Vesper, who suggests fields for them; if she is unavailable the pass finishes without her and those columns simply stay unmatched.

A match you have settled stays settled. Ticking another type, or reading the file again, re-runs the suggestions for the new type but does not overwrite a match you confirmed or a column you chose to leave out.

Some values never reach the matcher. Any column whose values look like tax file numbers has those values withheld before sampling, and the row says how many were withheld. A column of nothing but withheld values reads “nothing here could be read”, which is why it is unmatched, not a sign the file is broken.

What “unmatched” means

An unmatched column is one Aether found no Aether field for. Its values will not come across. That is often fine: internal ids, empty columns, notes your old system kept for itself. The review step lists them one per line with the reason for each, and “That’s fine, leave those columns out” settles the whole list at once. Leaving a column out applies to every record type’s copy of it, so a column dropped for clients is also dropped for the profile it would have fed.

Unmatched is measured. Coverage is the share of a file’s columns that reached a field, counted over the source columns, and a run whose coverage sits under the threshold is blocked at readiness until you either match more columns or accept the gap. The threshold defaults to 80 per cent.

Readiness and approval

Readiness is a score out of 100 and a status. Each blocker costs 25 points; each remaining error two, each warning one. A blocker is one of: unresolved errors, no valid records, column matches not yet reviewed, possible duplicates not decided, or coverage under the threshold. With no blockers and nothing outstanding the status is ready; with warnings it is review required; with a blocker it is blocked and approve is not offered.

Before you approve, Aether runs the import as a practice, inside a transaction it always rolls back, and shows what it would have written. Approving records the decision on the run: who approved, when, and what was decided about any household already in your book. Import then writes for real and produces an evidence pack, a ZIP of the files, the matches and the outcome per row, which you can download from the last step.

Uploading again

Within one run, a file you upload a second time is read as a second file. Its rows are extracted again and the first reading stays, because Aether keeps what it has read rather than guessing which copy you meant. The file list names a file uploaded more than once, so a repeat is visible before you go on. There is no control to take one file back out of a run. If a file in the run is wrong, use Start this run again before you import: it removes the whole run, with every file it has read and the matches and fixes made so far, and nothing has been imported. Then upload the files you want read into the fresh run. Once a run has imported it cannot be started again or deleted, because it is the record of what came across.

After a run has imported, Start a new migration opens a fresh run for the next upload. If that upload names a household your firm has already brought across, matched on the household name, Aether refuses by default and tells you which households, when they came across and from which file. You choose per household: skip it, or replace it. Replace removes what the earlier import wrote for that household and writes the new rows; it is refused if any of those earlier rows have been edited or removed since, because that is work someone at your firm has done, and the sentence names how many rows. It is also refused if the earlier import filed documents in the vault, since removing the records would leave the files behind. Aether never quietly skips a row because it looks like one it has seen.

Where the records go

Imported households and clients appear in your client book like any others, with the fact-find sections filled from what came across. The run itself, its files, its matches and its evidence pack stay on the migration record for your firm, so a later question about where a figure came from has an answer.