Skip to content

Mapping columns

View as MarkdownOpen in Claude(opens in a new tab)Open in ChatGPT(opens in a new tab)

Column Mapping is the stage where you tell Vintage what each column in your file means. Every column lands somewhere: on a Standard field, a field Vintage understands and can model with (Current Balance, Origination Date, Net Charge-Off Amount), or as a Custom attribute, a column Vintage keeps as it is so you can slice your portfolio by it later. Nothing you map is thrown away.

You map once per file group (Snapshot files, Origination files, or Transaction files), not once per file. Every file in a group shares the same columns, so one mapping applies to all of them. Column Mapping opens only after the whole upload has finished processing, so every group is ready when you arrive.

The screen is headed Review column mapping. When your upload has more than one file group, a tab for each group sits across the top. A group that still has something to fix is marked Needs review; a group you have confirmed carries a check. When a group holds several files, a note says the mapping applies to all of them.

Below that is every column you still have a decision to make about, in the order it appears in your file. Each row shows:

  • your column’s heading, and the kind of values Vintage found in it (numeric, date, text, or categorical);
  • an include switch (see Including and excluding a column);
  • a picker showing what the column is mapped to.

The one set of columns that is not listed is the Loan ID and Tax ID columns you chose on the Remove PII step. You already answered that question, so Vintage does not ask it again. Instead, a read-only note under the list names each one and its role, says its values are scrambled before storage, and confirms it is saved with this mapping. Those columns carry no mapping control and no type. (See Removing personal information for how they were chosen.) A file whose only columns are those identifiers has no loan data to map, and the screen says so.

Open a column’s picker to choose its target. The list has three sections:

SectionWhat it holds
SuggestedUp to four fields Vintage thinks fit this column, best first
CustomCustom attribute, always available whatever you search for
All fieldsEvery other Standard field that can appear on this file type

The search box matches a field’s name and the common names it goes by, so typing ssn finds Tax ID and upb finds Current Balance. The picker only offers Standard fields that belong on the file type you are mapping; the full list, with which file types each field appears on, is in Standard fields.

Choose a Standard field when your column carries something Vintage models with or recognizes. Standard fields are what unlock credit loss, payoff, and prepayment measurement; the Review step tells you which fields each result needs.

Choose Custom attribute for everything else: a branch code, a product name, an officer, a collateral type. A Custom attribute is kept, not dropped. Its spelling can drift between exports (Branch Code, branch code, Branch Code) and Vintage still treats it as the same field. What it describes depends on the file it came from:

  • On a Snapshot or Origination file, a Custom attribute describes the loan itself. When several months report it, the loan’s value is the one from its latest snapshot month. You can slice the portfolio by it in the Segment Builder.
  • On a Transaction file, a Custom attribute describes that one transaction. It is stored with the transaction but is not offered as a filter today.

Vintage pre-fills a target for every column, using automatic recognition of your headings and values. A column whose heading matches a Standard field’s name or a known synonym shows a small Matched by name marker. Vintage does not label any other suggestion with how it was produced: the Suggested section is where its ideas live, and every one of them is yours to accept or change.

Two rules keep suggestions from overruling you:

  • A saved mapping is never overwritten by Vintage’s suggestions. Once you save a file’s mapping, it stands.
  • A recognized file starts from your last answer, not a fresh guess. When a group’s columns match a file you accepted before, Vintage pre-applies that earlier mapping. See Uploading month after month.

Each row has an include switch. Turning it off excludes the column: it stays in your file, but its field is removed from what this upload can model with. Excluding is separate from the target: a column can be a Standard field or a Custom attribute, and included or excluded. It is how you keep a column out of modeling without changing what it is mapped to. An excluded row fades and reads Excluded, won’t be used.

Excluding a column also clears every check on it, because a column that contributes nothing cannot conflict with anything.

Vintage also runs its own check on the uploaded values for any column that still looks like personal information (an email address, a phone number, a Social Security number) that was not removed on the Remove PII step. A column it is confident about is excluded for you, and the screen says so:

Columns “Borrower Email” and “Phone” were dropped during upload. The system detected they may contain personal information. You can re-include them below.

Such a row reads Auto-excluded: values look like PII. Re-include if it’s safe. The reason stays with the upload, so reopening it later shows the same notice. Your Loan ID and Tax ID columns are never flagged this way.

Vintage accepts useful partial data. Loan ID is the only Standard field you must map, because it is the only key that ties a row to a loan. Every other Standard field is your choice; the Review step tells you what leaving one out costs.

A handful of situations stop you from continuing until they are fixed. Others are pointed out but leave the choice to you.

SituationWhat the row or screen saysBlocks Continue
No included column is mapped to Loan IDMap one of your columns to Loan ID to continue.Yes
The column mapped to Loan ID is excludedYour Loan ID column … is excluded. Include it again to continue.Yes
The column’s values don’t fit the Standard field’s type“Current Balance” needs a numeric column, but this column is text. with a one-click Mark as Custom AttributeYes
A Custom attribute matches an existing field of a different type, and some values would not fit12 of 400 values in this file won’t fit this type and will become empty. with Change type and Exclude columnYes
A status, flag, or transaction-type column has values nobody has classifiedThe classification panel under the row; see Classifying valuesYes
A status, flag, or transaction-type column has more than 50 distinct valuesToo many distinct values for a status field (or flag, or transaction type field): it is probably an ID or free-text column; map it elsewhere or exclude itYes
An amount column could be monthly or a running total, and the data can’t tellThe Reporting basis question under the row (whether the column reports each month’s activity or a total to date); see Declaring formatsYes
A file has no data rows, or only identifier columnsThere are no columns to mapYes
A Custom attribute matches an existing field of a different type, and every value still fitsThis field already exists, stored as Text.No
Two included columns are mapped to the same Standard fieldAnother column also maps to this standard field. Review to resolve.No

Next to Continue, a summary counts what still needs your attention: Resolve 2 mapping issues to continue. The count is one per column, however many things are wrong with that column, so it never sends you hunting for problems that are not there. Different kinds of blocker stay on their own lines, and a blocker in a group you have not opened yet is named as that group’s problem (“Also finish the mapping for Transaction Files.”) rather than added to the number on the screen in front of you.

Vintage checks the same rules again when you finalize. An upload containing any file whose saved mapping has no included Loan ID is refused whole, and nothing in it is accepted.

Vintage works out each column’s type from the cells that carry data, not from its blanks, so a charge-off amount that is blank on every loan that never charged off still reads as numeric. There are four types: Numeric, Date, Categorical, and Text. There is no yes/no type; a Y/N column is categorical. Once a field exists in your organization, its type holds across every upload, so a field means the same thing every time you slice by it.

How the type appears depends on whether the field is new:

  • A new Custom attribute shows Type and, for numeric columns, Format controls (Number, Currency, Decimal fraction, Percent points). They start on Vintage’s reading of your data; change them before you continue if it is wrong. The two percent formats change how every value is read, not only how it looks; see Declaring formats.
  • An existing field, one an earlier upload already created, shows Existing field and its registered type, with a Change type action. Changing a type applies to every upload of that field your organization has made, so Vintage shows how many stored values would no longer fit and become empty before you commit. The Fields page is the home of that change.
  • A Standard field always uses the type Vintage defines for it, so it shows no type control. The exception is Interest Rate, whose row carries a Rate format (applies to all uploads) control; see Declaring formats. Date and amount columns also carry the Date format and Reporting basis questions described on that page.

When a numeric column has cells Vintage cannot read as a number, a small N values treated as empty button appears on its row; open it to see examples. Those cells are kept in your uploaded data but count as no value for that field, never as zero. The full number and date grammar is in File requirements and parsing rules.

The mapping screen is the first place Vintage can report on the file as a whole, so it does:

  • Rows with the wrong number of cells are skipped. In a CSV, a value containing an unquoted comma (Smith, John) splits into two cells and pushes every later value one column to the right, including the Loan ID. Vintage cannot tell which value belongs where, so it imports none of that row (never trimmed, padded, or partly kept) and says how many rows it skipped and how to fix it: correct the export and upload the file again. The Review repeats the count, and every row figure Vintage shows counts only rows that were imported. (Excel files address cells by position, so this cannot happen to them.)
  • Formatting issues found while reading the file are counted. The affected rows were still read.
  • Numbers too large to store faithfully (15 digits or more in a numeric field) are counted and treated as empty, never rounded into a different number. They stay unchanged in your uploaded data. A long account number mapped as a Custom attribute or text keeps every digit.

None of these notices blocks you. They tell you what Vintage could not read cleanly so you can decide whether to fix the export or carry on.

Continue confirms the group on screen and takes you to the next group that still needs review. Its label names that group, as in Continue to Transaction Files. A group is confirmed only by pressing Continue on it, never by opening its tab. After each press the button is briefly unavailable, so a double-click cannot confirm a group you have not looked at. If the next group needing review is one you skipped past, the screen says so: You still need to confirm Loan Snapshots.

On the last group, the button reads Continue to review. Vintage saves your mapping, showing how many files are saved out of how many, and then prepares the Review. If the Review cannot be prepared, you are returned to Column Mapping with the message We could not prepare your review. Your column mapping was saved. Please try again.

While the Vintage team is setting up your organization’s first portfolio, this last Continue hands the upload to them instead of opening the Review, and if they return an upload to you, their note appears above the mapping, quoted exactly. See Your first upload.