# Classifying values

Every core system has its own words for what happened to a loan. One writes `PIF`, another `PAID`, a third `Closed - Paid`; one flags a charge-off with `Y`, another with `CO`, another with `1`. Vintage does not keep a list of what those words mean. Instead, when you map a column that carries them, Vintage lists each distinct value in it and asks you what each one means. Your answers are what turn a word in your file into a payoff, a charge-off, or an exit in the curves.

You answer once. Your organization's answers are remembered, so the next upload of the same file asks only about values it has never seen.

## The three kinds of column that ask

A column asks to be classified when you map it to one of these Standard fields (the fields Vintage understands). Each kind gets the question that fits it.

| You mapped the column to | The panel asks | The choices |
|---|---|---|
| **Loan Status** or **Closure Reason** | **What does each status mean?** | Open (still active) · Paid off · Charged off · Exited (other) |
| **Charge-Off Flag**, **Payoff Flag**, or **Prepayment Flag** | **What does each value mean?** | Marks the event (a charge-off, a payoff, a full prepayment) · Does not |
| **Transaction Type** | **What does each transaction type mean?** | Charge-off · Recovery · Payoff · Partial prepayment · Regular payment · Not a modeled event |

The panel appears under the column's row on [Column Mapping](/uploading/mapping-columns/). It lists every distinct value with how many rows carry it, and a counter (**3 of 5 classified**) tracks your progress.

### Status values

The four status meanings are a loan's possible states as far as Vintage is concerned:

- **Open (still active)**: the loan is still on your book. This says nothing about whether it is current or delinquent; a 90-days-past-due loan is still open.
- **Paid off**: the loan was repaid in full.
- **Charged off**: the loan was written off as a loss.
- **Exited (other)**: the loan left your book for a reason that is neither a payoff nor a default: sold, participated out, or transferred to another servicer.

There is no separate charge-off status field. A two-state column (blank or `CO`, say) belongs on **Charge-Off Flag**. A column with a richer lifecycle vocabulary belongs on **Loan Status**. **Closure Reason** uses the same four meanings, for a column that explains why a loan closed.

### Flag values

A flag column asks which of its values **mark the event** and which **do not**. For a Charge-Off Flag the choice reads **Marks a charge-off**; for a Payoff Flag, **Marks a payoff**; for a Prepayment Flag, **Marks a full prepayment**. There is no built-in list of "yes" values like `Y`, `1`, or `true`: a flag means an event only because you said so.

### Transaction types

Many cores export a single ledger of transactions where each row carries a **type code** and **one amount column**, rather than a separate column for each kind of amount. Vintage reads that shape directly: map the code column to **Transaction Type** and the amount column to **Transaction Amount**, then tell Vintage what each code means. Each row's amount is then read as the kind its code names:

| You classify a code as | Its rows' amounts are read as |
|---|---|
| Charge-off | a charge-off amount |
| Recovery | a recovery amount |
| Payoff | a payoff amount |
| Partial prepayment | a partial prepayment amount (unscheduled principal) |
| Regular payment | an Actual Payment Amount |
| Not a modeled event | nothing; the row contributes to no measure |

Four rules keep a ledger from being misread:

- **A named column beats a routed one.** If the same row also carries a real Charge-Off Amount column, that column's value wins for the charge-off; the type code only fills a slot the row left empty.
- **Rows you mark Not a modeled event contribute nothing.** Fees, escrow postings, and interest-only entries stay out of every measure rather than being folded into a total.
- **Duplicates are recognized by kind.** When Vintage checks whether two ledger rows are the same transaction, it compares their amounts by the kind each was classified as. (How duplicate transactions are recognized is described in [Uploading month after month](/uploading/uploading-month-after-month/#transactions-are-counted-once).)
- **Changing what a code means re-reads your whole book**, exactly as changing a status or flag does.

## Why Vintage never guesses

A value's meaning is a fact about your institution, not about the word. `CLOSED` might mean paid off at one bank and charged off at another; `C` might be current or charged off. Reading a paid-off loan as charged off changes how that loan ends in every curve. So Vintage holds to one rule: **an unclassified value means nothing.** A flag value or status value nobody has classified is never read as an event and counts toward nothing.

Vintage does help. It **suggests** a meaning for each value, using automatic recognition and plain keyword matching, and pre-fills it, marked **Suggested**. The panel tells you how many are suggestions (**3 suggested. Review before continuing.**). Nothing takes effect until you save the mapping, and pressing **Continue** is how you approve the suggestions you leave in place. Change any you disagree with first.

**Distress is not an ending:** For a **Loan Status** column, a value that names a distress state still being worked (a foreclosure in process such as `FCLS`, a bankruptcy filing such as `BK7` or `BK13`, REO in process) is suggested as **Open (still active)**, not Charged off, unless the value itself says the loan was charged off. The loan is still on your book. A **Closure Reason** is not read that way, because a loan with a closure reason has already closed.

## Every value must be classified before you continue

You cannot continue past Column Mapping while an included classifiable column has a value with no classification at all. A suggested classification counts as an answer; only a value with nothing selected blocks. Vintage checks the same rule again when you finalize, so an unclassified value can never slip through.

If you do not want a column classified, exclude it instead. An excluded column asks nothing.

**A column with too many values.** A genuine status, flag, or type column carries a handful of values. A column with more than 50 distinct values is not offered a list at all: the panel reads **Too many distinct values for a status field** (or flag, or transaction type field) and says the column is probably an ID or a free-text column mapped to the wrong field. It blocks Continue like any other unclassified column; map the column elsewhere, or exclude it.

## Blanks are never classified

A blank cell is not a value. It gets no control, it is left out of the "classified" counter, and it can never be marked as an event or as still open. When a column has blanks, the panel ends with a dimmed **Blank** row showing how many rows are blank and the words *treated as no signal*, with the rule stated plainly: a missing value tells Vintage nothing, and what a blank means for your book is something you tell Vintage, not something it infers. If Vintage can count only some of the blanks, it says **at least** that many rather than presenting a partial count as the total.

## New values on a file Vintage recognizes

The risky case is the one that looks finished. When Vintage recognizes a file's format, the mapping is already filled in from last time, and the file may still carry one unfamiliar status code buried in a list. So whenever a recognized file carries a value your organization has never classified, Column Mapping tells you three times:

1. an amber notice at the top, **Recognized format, with values we haven't seen**, naming each affected column and its new values (up to three per column, then "and N more");
2. a note on each affected column's row naming its new values;
3. a **New** badge on the value itself in the panel.

Newness is judged field by field. A value you classified on a different field still counts as new here; your earlier answer arrives as a pre-filled suggestion, not as a settled fact. On a first upload, or on a format Vintage does not recognize, none of this appears: every value is new there, and the panel already shows them all unclassified.

## What your answers change

Your classifications are what make the event-based modeling methods work:

- A status value marked **Paid off**, or a flag value marking the event on a Payoff Flag or Prepayment Flag, counts as a **payoff**.
- A status value marked **Charged off**, or a flag value marking the event on a Charge-Off Flag, counts as a **charge-off**. A charge-off known only from a flag or status carries no loss amount, so on its own it does not make a loan ready for credit loss; a Net Charge-Off Amount or Charge-Off Amount column does. See [Charge-offs and recoveries](/concepts/charge-offs-and-recoveries/).
- A status value marked **Exited (other)** ends the loan without counting as either. See [Payoffs and exits](/concepts/payoffs-and-exits/).

How these markers combine with dates and amounts to decide when and how each loan ended is explained in [How a loan's ending is decided](/concepts/how-a-loan-ends/).

Your status vocabulary also answers one question about how your book behaves. When it contains both a **Charged off** value and at least one **Open (still active)** value, Vintage can tell whether a loan that keeps reporting after a charge-off is still alive, and it measures partial write-downs that way: a charge-off amount reported on a Snapshot file in a month whose status you classified Open books as a loss in that month, and the loan stays in the curves until a real ending arrives. A month with no status value is never read as alive, and a charge-off that arrives through a transaction ledger still ends the loan at its first charge-off. The timing of losses changes; a loan's lifetime loss does not. Without such a vocabulary, your answer to the **Portfolio semantics** question on the [Review](/uploading/reviewing-before-you-finalize/#portfolio-semantics) decides instead. See [Charge-offs and recoveries](/concepts/charge-offs-and-recoveries/).

## Your vocabulary is durable and editable

Classifications belong to your organization, not to one upload. A re-upload with the same values asks nothing; only new values need an answer.

You can review and change any of them later on the **Standard Fields** tab of the [Fields](/portfolio/fields/) page, which lists every classified value and what it means. Saving a change re-reads your whole portfolio automatically, so loans from every earlier upload reflect the corrected meaning. While that runs, the Portfolio and Modeling screens show that the portfolio is updating.

## Related

- [Mapping columns](/uploading/mapping-columns/)
- [How a loan's ending is decided](/concepts/how-a-loan-ends/)
- [Charge-offs and recoveries](/concepts/charge-offs-and-recoveries/)
- [Payoffs and exits](/concepts/payoffs-and-exits/)
- [Fields](/portfolio/fields/)
- [Modeling methods](/reference/modeling-methods/)