# Reviewing before you finalize

The Review is the last stage of an upload, and the only place you decide whether to accept it. Vintage joins this upload's rows onto your existing portfolio, loan by loan, and shows the result as one statement: what the upload adds, what it lets you model, what it does not yet support, and what to do about it. Nothing reaches your portfolio until you press **Finalize upload** at the bottom.

You do not need every loan to be model-ready to accept an upload. Vintage accepts useful partial data so you can build up value over time. The Review's job is to make sure you know exactly what you are accepting.

## While the Review is being prepared

After you press **Continue to review** on [Column Mapping](/uploading/mapping-columns/), the screen waits in two phases, and says only what it can measure:

1. **Saving your column mapping**: how many files are saved out of how many, with a progress bar.
2. **Reviewing your upload**: the size of the job ("Joining 120,000 rows from 3 files with your existing portfolio.") and a clock showing how long it has been running. There is no progress bar and no time estimate here, because there is no honest measure of how far through the work is.

Reloading the page or closing the tab does not lose the work; returning picks it up again. The Review does start over if another upload in your organization is accepted, deleted, or finishes processing in the meantime, because the portfolio it is joining onto has changed. 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.**

A draft upload's Review is always computed afresh when you continue from Column Mapping, because your mapping is what it is built from. An accepted upload reopens to a prepared Review: its reconciliation is as it stood when you accepted it, while its readiness reflects your portfolio as of its last completed update; see [Upload History](/uploading/upload-history/).

While the Vintage team is setting up your organization's first portfolio, you do not see this step: Column Mapping hands the upload to them instead. See [Your first upload](/uploading/your-first-upload/).

## The verdict

At the top, a banner says whether this upload can be finalized and how complete it is. There are three verdicts.

| Verdict | Banner | Can you finalize? |
|---|---|---|
| **Ready** | **Ready to finalize** | Yes |
| **Ready with gaps** | **Some loans can't be modeled yet** | Yes |
| **Blocked** | **Cannot finalize yet** | No |

The verdict rests only on what your data supports. For each of the three results (credit loss, full payoff, and partial prepayment), Vintage measures the share of this upload's loans that are ready for it:

$$
\text{ready share} = \frac{\text{loans in this upload that are ready for the result}}{\text{all loans in this upload}}
$$

The denominator is every loan this upload touches, new or already in your portfolio, after the join. **If any result's ready share is under 50%, the verdict is Ready with gaps.** The test is strict: a result with exactly half of its loans ready is not a gap. For example, an upload that touches 60 loans, 24 of them ready for partial prepayment, has a partial-prepayment ready share of 40%, so its verdict is Ready with gaps even when every loan is ready for credit loss and payoff. The banner then leads with the largest gap in plain terms: "62% of your loans can't be modeled for Partial prepayment yet", or, when a result has nothing at all, "None of your loans have what Credit loss needs." Finalize stays available; the amber banner matches what the data supports instead of looking done.

**Blocked** means the upload contributes no usable data tied to a loan: no row has a usable Loan ID, or no row carries any value beyond its identifiers. There is nothing to add to your portfolio, so there is nothing to finalize. It is the only verdict that stops you.

## How the rows become loans

The **Reconciliation** block traces your upload from rows to loans:

| Line | What it counts |
|---|---|
| **Rows in upload** | Every row that was imported |
| **Linked to a loan** | Rows with a usable Loan ID, with any that lack one noted ("15 without a Loan ID") |
| **Contributing portfolio data** | Linked rows with at least one usable value in an included column other than the identifiers |
| **Loans in this upload** | Distinct loans, split into **new** and **matched** to your existing portfolio, or **All new to your portfolio** |

A row with no usable Loan ID (a blank, or a placeholder such as `N/A` or `000000`) is kept with your upload but cannot join a loan. (Why a placeholder never becomes an ID is explained in [Removing personal information](/uploading/removing-personal-information/).)

Every figure counts only rows that were imported. When rows were skipped because they had a different number of cells than the header row, the block names how many and explains why, so a total never quietly stands in for a file you believe arrived whole. When a workbook had more than one sheet, it says that only the first sheet was read.

## What you can model

This block has a card for each result: **Credit loss**, **Full payoff**, and **Partial prepayment**. A permanent line under the heading states the figures' basis; see [What these figures are measured against](#what-these-figures-are-measured-against).

### Ready loans, and what your data records

Each card leads with how many loans are ready ("54 of 60 loans ready") and how many still need critical data. Beside that is the **incidence**, what your data says about the event itself, in one of three statements, never a zero Vintage has not counted:

- **Counted.** When a column of yours records the event per loan (a non-zero charge-off, payoff, or prepayment amount, or an event date), the card says how many loans recorded it, over the same denominator: "8 of 60 loans recorded a charge-off".
- **Carried another way.** When no such column exists but your data does carry the event (through classified flag or status values, a transaction ledger, or actual against scheduled principal or payments), the card names the source instead: "Payoffs come from your Loan Status values, not a per-loan amount or date."
- **Not in the data.** When nothing carries the event: "Nothing in this data reports charge-offs yet."

"54 ready" and "8 recorded a charge-off" are not in conflict. Event fields are recorded only on loans where the event happened, so a loan that never charged off is still ready: its clean history is exactly what the loss curve measures against.

### How each result will be measured

Under **Modeled by**, each card names the method Vintage will use and how many loans use it, with its own denominator ("8 of 60 loans · 13.3%"). The share is left off only when every ready loan uses the one method. Methods are lettered in preference order (A and B, and for credit loss also C) and are listed with the fields each needs in [Modeling methods](/reference/modeling-methods/).

Preference order is not accuracy. Several methods measure the same thing equally well, so Vintage never recommends adding fields only to move loans from one of them to another. It never describes your own reported figures as estimated or inferred, either.

When every ready loan is ready because nothing has happened to it (a performing book), the card says so as a finding, not as an absence: **Modeled as Performing**. On the credit-loss card the explanation reads that no charge-offs are recorded against these loans, that this is a measured zero rather than missing data, and that they still count in the loss curves.

### Coverage detail

Open **Coverage detail** to see, for each method in use, the fields its loans draw from and which of your columns supplies each ("source: your column "NCO_AMT""). Alongside it you may see:

- **What would bring the rest in**: when some loans are not ready, the fields that would make the most of them ready, with a count for each.
- **The one accuracy suggestion.** A book that reports gross charge-offs with no Recovery Amount column anywhere books the whole gross amount as the loss. Only then does Vintage ask for more: adding Recovery Amount, or a Net Charge-Off Amount column, would measure those charge-offs net of recoveries.
- **An all-clear.** When every loan is ready and your data already supports the most accurate measurement available, the panel says nothing needs changing. If an optional field would still sharpen the result (a Payoff Amount, for example), it names that field instead of claiming nothing could improve.

### When a result has a large gap

On a result below the 50% line, the card adds **How to close this gap**. It lists once, at the top, what **every option needs** (Loan ID, Snapshot Month, Current Balance, and a term: Term (Months) or Maturity Date), and then each method as **Option A**, **Option B**, and so on, with every field marked as present (naming your column) or not in your data yet, and the share of loans that carry it. Event fields read as incidence ("31% of loans have one recorded"), never as missing. This guide appears only on a result with a real gap, never on a healthy one.

## How readiness is decided

Readiness is judged **loan by loan, after the join**, not by whether a column exists somewhere in the file.

- **Base and measurement fields must be on the loan itself:** Loan ID, Snapshot Month, Current Balance, a term (Term (Months) or Maturity Date), and, where a method uses them, schedule fields. A loan with no usable term is never ready for anything, because a loan whose life is undefined can never enter the curves.
- **Event fields are portfolio-wide signals.** Charge-off amounts and flags, recoveries, payoff and prepayment flags and amounts, charge-off and payoff dates, and the closure fields only appear on loans where the event happened. So a loan counts as ready when its own base fields are present and the event signal exists **anywhere** in your data: this upload or your accepted portfolio.
- **A charge-off known only from a flag or status, with no amount, makes no loan ready for credit loss.** It names the event but carries no loss to measure. A Net Charge-Off Amount or Charge-Off Amount column does. See [Charge-offs and recoveries](/concepts/charge-offs-and-recoveries/).
- **Partial prepayment also needs a reported schedule** on the loan: Scheduled Principal Due or Scheduled Principal Paid, or a Scheduled Payment Amount paired with an Actual Payment Amount. The card says plainly that loans without one won't receive prepayment speeds. See [Prepayment speeds](/concepts/prepayment-speeds/).
- **A date that doesn't fit its column's declared format** is counted as that specific field to fix, not folded into "missing". See [Declaring formats](/uploading/declaring-formats/).
- **The verdict is stricter than the cards.** For the verdict, a loan counts as ready for a result only when the observations a method needs are reported together in one snapshot month. The ready counts and method shares on the cards also count a loan whose needed observations appear in different months. The two can differ by a few loans, and the verdict is the stricter reading.

## Origination and loan term

The **Origination** block shows where each loan's starting point comes from. Each origination field is either **Provided**, naming your column, or **Estimated**: for a loan Vintage first sees after your earliest snapshot month, it estimates the origination date from that first month and the original balance from the first balance it sees, and flags the loan as estimated. A loan already present in your **earliest** snapshot month with no origination date cannot be aged this way (nothing distinguishes a new loan from a seasoned one), so it is held out of the curves rather than guessed at.

The same block shows **Loan term**: **Provided** from a Term (Months) column, **From maturity date**, or **Missing**, flagged amber. The rules behind both are in [Origination and term](/concepts/origination-and-term/).

## Loans held out of the curves

Naming the column a value comes from says nothing about how many loans carry a usable one. A mapped term column still leaves behind every loan whose term reads `0`, or whose maturity date falls on or before origination. So the Review also counts, reason by reason, the loans that will stay out of the modeled curves, and says what would bring them in:

| Reason | What brings the loans in |
|---|---|
| First seen in your earliest month with no origination date | A two-column file of Loan ID and Origination Date |
| No usable term | A Term (Months) column, or a Maturity Date after origination |
| A date that cannot be read under its declared format | Declaring the right date format and uploading the file again (see [Declaring formats](/uploading/declaring-formats/#when-a-date-format-takes-effect)), or re-exporting the column |
| A charge-off marker with no loss amount | A Net Charge-Off Amount column, or Charge-Off Amount with Recovery Amount |
| No status or flag value classified as the event yet | Classifying one of those values as the event, on Column Mapping or later on the [Fields](/portfolio/fields/) page |

These loans still upload and still count in your portfolio. They are the same loans the modeled curves leave out after the upload is processed; the Review shows them before you commit, while you can still act. A loan can appear under more than one reason, so the lines are never added together.

## What these figures are measured against

The readiness figures reflect your portfolio **as of its last completed update, plus this upload**, not a live re-reading of every row you have ever sent. The screen says so permanently, so a percentage is never read as more current than it is.

When a portfolio update is still running (another upload being folded in, or a deleted upload being removed), the screen adds that **A portfolio update is running now. These figures may change when it finishes.** They can move in either direction. In particular, while a deleted upload is still being removed, the figures can read higher than they will end up. The Review refreshes itself onto the final figures as soon as the update finishes, with nothing for you to do.

## What to do next

Below the results, Vintage lists practical notes that catch the most common mistakes, under **Worth a look before you finalize** (or **What to fix** when the upload is blocked):

- rows without a usable Loan ID, which will not join the portfolio;
- an upload with no usable data tied to a Loan ID;
- an upload where none of the loans are ready for any result yet;
- new loans with no origination data: did you mean to include an origination file or origination columns?
- new loans with no credit-loss event data: did you mean to include a transaction file or charge-off columns?
- transaction rows that match no Loan ID: check that the transaction file's Loan ID column is the loan number.

A Loan ID counts as known when it is already in your portfolio **or** arrives on another file in the same upload, so a first upload that brings a snapshot and its transaction file together reads as matched. When there is nothing to flag, the section reads **No issues found. This upload is ready to finalize.**

## Portfolio semantics

One fact about your book cannot be read from any file: whether a charged-off loan leaves your exports or can keep reporting after a partial write-down. Review is where the evidence first appears, so it is where Vintage asks.

When this upload contains loans that **keep reporting a balance after they were charged off**, a **Portfolio semantics** card says how many and asks: **When a loan is charged off, does it leave your exports, or can it survive a partial write-down?** It is pre-filled with the suggested default, **It leaves our exports**. The card never blocks you. Your answer applies to your **whole portfolio**, not only this upload, and you can change it later on the [Fields](/portfolio/fields/) page, its permanent home. The card does not appear when your own classified status values already answer the question. What each answer does to the loss curve is explained in [Charge-offs and recoveries](/concepts/charge-offs-and-recoveries/).

## Finalizing, or going back

**Finalize upload** is available for every verdict except Blocked. **Back to mapping** returns you to Column Mapping to change anything first; the Review is computed afresh when you return.

When you finalize, Vintage checks again that every file has an included Loan ID column, every classifiable value is classified, and every reporting basis (whether an amount column is monthly or a running total) it had to ask about is answered. An upload that fails any check is refused whole. What happens after you finalize is in [Finalizing and what happens next](/uploading/finalizing-and-what-happens-next/).

**Tip:** A Ready with gaps verdict is often the right one to accept. A first snapshot file without charge-off columns still builds your loan history; a later transaction file or a re-export with the missing columns brings those loans into the curves, and each later Review shows the gap closing.

## Related

- [Finalizing and what happens next](/uploading/finalizing-and-what-happens-next/)
- [Modeling methods](/reference/modeling-methods/)
- [Mapping columns](/uploading/mapping-columns/)
- [Origination and term](/concepts/origination-and-term/)
- [Missing and unreported data](/concepts/missing-data/)
- [Preparing your data](/getting-started/preparing-your-data/)