Uploading month after month
Most uploads after the first are the same file, a month later. Vintage is built for that rhythm: it remembers your decisions, recognizes a file it has seen before, and asks only about what changed. A routine monthly upload is a few confirmations, not a fresh setup.
Further down is what happens when two uploads overlap or disagree about a loan (which value wins, how a month is matched, how a transaction is counted once) and how to correct a month you already accepted.
What Vintage remembers
Section titled “What Vintage remembers”| What you decided | Remembered for | What the next upload does |
|---|---|---|
| Which columns are the Loan ID and Tax ID, and which columns to remove | Each file type | Pre-fills the Remove PII step, with a banner naming the earlier file |
| How each column is mapped, and which columns you excluded | Each file format | Pre-fills Column Mapping |
| What each status, flag, and transaction-type value means | Your organization | Asks only about values it has never seen |
| Date formats, percent formats, and reporting bases (whether an amount column is each month’s activity or a total to date) | Your organization’s fields | Asks nothing for a column you answered yourself; a suggestion you left in place is checked again against the new file and re-suggested if the data contradicts it |
| Each field’s type | Your organization’s fields | Shows the column as an Existing field |
Everything remembered is still yours to change on the next upload. What Remove PII remembers is column names and choices only, never a cell value; how that works, and why its automatic scan can add columns to remove but never take one away, is in Removing personal information.
How Vintage recognizes a file
Section titled “How Vintage recognizes a file”For each file group in an upload, Vintage compares the columns with your earlier accepted uploads of the same file type: a Snapshot file against Snapshot files, and so on. This recognizes the file’s format; recognizing the same loans is a separate step, described below. Column Mapping shows one of four outcomes:
| What you see | When | What Vintage does |
|---|---|---|
| Matches a previous upload | The columns match an earlier upload exactly | Pre-fills the whole mapping from last time |
| Slightly different from a previous upload | Close to an earlier upload, with columns added, removed, or reading as a different type | Pre-fills what it recognized and splits the list into New or Changed Columns and Recognized Columns. Show changes lists what changed |
| New file format | You have uploaded before, but nothing matches | No earlier mapping is pre-applied; you map the group fresh from Vintage’s suggestions |
| Nothing | Your very first upload | You map each group; there is nothing to compare with |
The mapping carried forward includes the columns you excluded, so a column you excluded once is not asked about again. Vintage’s own check for personal information still runs on top and can exclude more. The two only add up: nothing re-includes a column that you or the check removed.
Your Loan ID and Tax ID columns play no part in format matching, since their scrambled values describe the scrambling, not the column. That is what lets the common rhythm keep matching exactly: a backfill file (your history, loaded at once) holding several months, then one file a month, all read as Matches a previous upload.
A draft you leave and resume shows the outcome it was given when its files were processed, even if someone has accepted another upload since.
A renamed column reads as one removed and one added
Section titled “A renamed column reads as one removed and one added”Vintage does not guess that one column was renamed into another; a new name can be any word at all, and a wrong guess would quietly carry the wrong mapping across. A renamed column therefore shows as a removed column plus a new one, and you map the new one.
Map it to the same Standard field and the history continues unbroken. A Custom attribute, though, is identified by its column name (ignoring capitalization and extra spaces), so a custom column under a genuinely new name becomes a new field.
A column that is no longer your Loan ID
Section titled “A column that is no longer your Loan ID”If a later upload designates a different column as its Loan ID, the old one is now ordinary data, with raw, unscrambled values, because it was not designated this time. Vintage treats it as a column it has no answer for: it suggests a mapping from scratch rather than inheriting the identifier mapping it had last month. You can still choose Custom attribute for it deliberately, but Vintage will not leave it to default there by omission.
Recognizing the same loan
Section titled “Recognizing the same loan”Rows from different files and uploads join into one loan when they share the same Loan ID. Vintage stores only the protected (scrambled) form of it, which is the same every time for the same Loan ID, so next month’s rows find this month’s loan. Before scrambling, it ignores whitespace, capitalization, and leading zeros, so 0012345, 12345, and 12 345 are one loan; see Removing personal information. A Tax ID, when you designate one, is protected the same way and serves as a fallback join key; Loan ID stays the primary key.
On the Review, loans this upload touches are counted as new or matched to your existing portfolio.
When two uploads disagree about a loan
Section titled “When two uploads disagree about a loan”Uploads overlap: a backfill and a monthly file can both cover the same month, an origination file and a snapshot can both report an origination date, and a corrected re-export can repeat a month. Vintage never adds two sources together. For each loan and field it picks one winning value, by what the value means, not by which file happened to arrive last.
| Kind of value | Examples | Which value wins |
|---|---|---|
| Current loan facts | Interest Rate, FICO Score, Term (Months), Maturity Date, and every Custom attribute on a Snapshot or Origination file | The value from the loan’s latest snapshot month. With no readable snapshot month, a value from an Origination file; failing that, the most recently accepted value |
| Origination facts | Origination Date, Original Loan Amount | The value from an Origination file; failing that, the latest snapshot month; failing that, the most recently accepted value |
| A month’s observations | Current Balance, Loan Status, a month’s payment and charge-off amounts | For the same loan, the same month, and the same field: the most recently accepted value. The loan’s current value is its latest month’s |
Three rules apply throughout:
- A blank never clears a known value. Blanks, placeholders, and cells that cannot be read as the field’s type mean “unknown”. A later upload that leaves a value empty does not erase the value an earlier upload supplied.
- An older month never overrides a newer one. Uploading January after March does not replace March’s interest rate with January’s. A single file holding several months ranks its own rows by month the same way.
- A row with no readable snapshot month never outranks one that has a month.
For example: your March snapshot gives a loan an Interest Rate of 7.25. Later you backfill January, which reports 7.00. The loan’s rate stays 7.25%, because March is the later month. If you then upload a corrected March file reporting 7.30, the rate becomes 7.30%: same month, more recently accepted.
A month is matched by its date, not its spelling
Section titled “A month is matched by its date, not its spelling”Each snapshot month is identified by the calendar date Vintage reads from it, not by the text in the cell. An export whose format drifts (2024-01 one year, Jan-2024 or 20240101 another) therefore never produces two copies of the same month, which would double-count it in your portfolio and your curves. The text as written is kept for display only.
Transactions are counted once
Section titled “Transactions are counted once”Transaction files often overlap from one upload to the next. Vintage recognizes a transaction it already has in one of two ways:
- With a Transaction ID. Rows for the same loan with the same Transaction ID are one transaction. When a later upload carries that ID again, the version from the most recently accepted upload is the one kept.
- Without one. Two rows are the same transaction only when they agree on the Loan ID, the transaction date (matched by calendar date, so a date format change does not matter), and every amount on the row: charge-off, recovery, payoff, and prepayment amounts alike. Rows that differ in any amount are separate transactions.
For a ledger read through Transaction Type, amounts are compared by the kind each row was classified as. And when a snapshot and a transaction file both report the same quantity (a charge-off, a recovery) for the same loan in the same month, the snapshot’s figure is used and the ledger’s is set aside, never added; see Charge-offs and recoveries.
Correcting a month you already accepted
Section titled “Correcting a month you already accepted”The rules above mean a re-upload on its own is not a full correction. Uploading a corrected file for a month you already accepted:
- does replace any value the new file supplies for the same loan, month, and field;
- does not clear a value the new file leaves blank;
- does not remove a loan that the new file leaves out, because the old file still reports it;
- does not remove a transaction without a Transaction ID whose amount was corrected, because both versions count.
So to correct a month’s data, delete the old file or upload first, in Upload History, and then upload the corrected export. The delete takes effect at once; the upload reads Removing… while its data is taken out of your portfolio, and the Portfolio and Modeling screens show that the portfolio is updating until it is done.
Not every mistake needs a re-upload:
| What was wrong | How to fix it |
|---|---|
| A column mapped to the wrong field | Reopen the upload from Upload History and correct its mapping; the change affects only that upload |
| What a status, flag, or type value means | Change it on the Fields page; your whole portfolio is re-read |
| A reporting basis or percent format | Change it on the Fields page; your whole portfolio is re-read |
| A date format | Set the right format on the upload’s mapping and save, upload the file again, then delete the earlier upload; see Declaring formats |
| The data itself | Delete the upload, then upload a corrected export |
Adding older history later
Section titled “Adding older history later”You can upload history in any order. A backfill of older months uploaded after your recent ones fills in the past without overwriting current facts, because an older month never outranks a newer one.
Your earliest month matters, though. Vintage can estimate a loan’s origination from its first appearance only for loans first seen after your earliest snapshot month; a loan already present in that earliest month, with no origination date, cannot be aged. So adding older months, or deleting the files that held your earliest months, moves the start of your data, and Vintage re-measures your whole portfolio to match. A loan that looked seasoned only because those early months existed is re-classified honestly once they are gone. See Origination and term.
One upload or several
Section titled “One upload or several”One upload can carry several files in each group, as long as every file in a group has the same columns (in any order). You map and review the group once for all of them, so a backfill of many monthly files in one layout is mapped once. A single file can also hold many months.
A few consequences help you choose:
- A change of layout needs its own upload. Files in one group must share their columns. If your export’s columns changed partway through your history, upload the two layouts separately; each upload’s layout can differ.
- Bring a snapshot and its transaction file together. A transaction row matches a loan that arrives on another file in the same upload, so the Review does not flag it as unmatched.
- Each upload is reviewed against your portfolio as it stands. A Review prepared while an earlier upload is still being added says its figures may change, and updates itself when the work is done.
- Uploads that finish together share one email. Several of your uploads landing together produce one “portfolio updated” email naming how many. See Finalizing and what happens next.