Skip to content

Declaring formats

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

Some things about a column cannot be read reliably from one cell. 03/04/2024 could be the 3rd of April or March 4th. 8.25 in a rate column could mean 8.25% or 825%. A charge-off column could report this month’s charge-offs or everything charged off to date. Get any of these wrong and every value in the column is wrong the same way.

Vintage treats each as a declared fact about the column, not something to guess cell by cell. On Column Mapping, it reads the column’s values, suggests an answer, and lets you correct it. The answer applies to every cell in the column alike (for dates, to files read in after you declare it; see When a date format takes effect) and is remembered for your organization, so the next upload of that column asks nothing.

FactColumns it applies toIf Vintage can’t tell
Date formatEvery column mapped as a dateAssumes US Month/Day, marked Suggested; never blocks
Percent formatInterest Rate, and any numeric Custom attribute (a column kept under its own name) you format as a percentSuggests from how the values are written; Interest Rate defaults to Percent points
Reporting basisCharge-off, net charge-off, recovery, principal, payment, and ledger amount columnsAsks, and blocks until you answer

A date column’s Date format is the order its dates are written in. The choices are:

  • Year first (2024-07-04)
  • Month / Day / Year (07/04/2024)
  • Day / Month / Year (04/07/2024)
  • Month name (Jul 2024)

Forms that can only mean one thing are always read correctly whatever the declared format: 2024-07-04, 20240704, 2024-07, 202407, Jul-2024, July 2024, 4-Jul-2024, Jul 4, 2024. The declaration matters for dates written as two numbers and a year, where the first number could be the month or the day. Such a date fits only the two orders that name it: in a column declared Year first or Month name, a two-number date does not fit the declared format and is treated as no value.

How Vintage suggests it. Vintage looks at the column’s own values for proof. A value like 13/07/2024 can only be day-first, because there is no 13th month; a value like 07/31/2024 can only be month-first. When the values prove an order, that order is pre-filled and marked matches your data in the dropdown. When nothing in the column can tell the two orders apart, Vintage assumes US Month/Day order and pre-fills it marked Suggested, for you to confirm or change in one click.

The date chip shows only the label Date format and the answer. A Suggested badge means the order was assumed or carried over rather than proven. Unlike a reporting basis, an uncertain date order never blocks you; the effective order, declared or assumed, is saved with your mapping.

Cells that do not fit. A cell that cannot be read under the column’s declared format is kept but treated as no value for that field, never re-read in the other order. The Review counts the loans held out because a date could not be read, names the field, and says what would fix it.

Vintage applies a column’s date format as it reads a file in, which happens before you reach Column Mapping. Two things follow:

  • The format you confirm applies from the next file onward. Vintage remembers the declaration by column name and reads every later upload of that column with it.
  • Changing the format does not re-read files already read in, including the files of the upload you are mapping. To correct dates that were read in the wrong order, set the right format on that upload’s mapping and save it (for an accepted upload, reopen it from Upload History first), then upload the file again as a new upload. Once the new upload reaches Column Mapping, delete the earlier one. One case needs an extra step: for a date column kept as a new Custom attribute, the declaration is stored for your organization only when the upload is finalized, so finalize first, then upload the file again and delete the earlier upload.

A percent column can be written two ways, and the two differ by a factor of 100:

FormatWhat the numbers in your file mean8.25 in your file reads as0.0825 in your file reads as
Percent points (8.25 means 8.25%)The number is already a percentage8.25%0.0825%
Decimal fraction (0.0825 means 8.25%)The number is a fraction of one825%8.25%

The format is the reading instruction for the whole column, applied to every cell alike. A percent sign in a cell is decoration and is stripped; the column’s format decides what the number means. So in a column declared Decimal fraction, a cell written 5% reads as the fraction 5, that is, 500%. Whichever format your file uses, Vintage stores every percentage the same way and always shows it as 8.25%, so one field can never hold two scales.

How Vintage suggests it. The option that fits how your file’s values are written is marked matches your data in the format dropdown. When every value in the column carries a percent sign, the suggestion is Percent points, whatever the size of the numbers, because a column written 0.05% is already in percentage terms. For bare numbers, Vintage leans on their size. The mark is a recommendation; the format you pick is the one Vintage uses.

Interest Rate. The Standard field Interest Rate defaults to Percent points: most cores export rates as 8.36. If yours exports 0.0836, change it. On Column Mapping, the Interest Rate row carries Rate format (applies to all uploads). As the label says, this is an organization-wide setting, not a choice for this file: picking an option saves it for your organization at once.

Custom attributes. A new numeric Custom attribute offers the same two percent formats in its Format control, alongside Number and Currency. Number and Currency only change how values are displayed; the two percent formats change what the values mean.

Changing it later. Because the format changes what the data means, changing it is a data change, not a display toggle. Vintage re-reads the field from the values you originally uploaded and re-measures your portfolio. On the Fields page, a rate-format change is confirmed before it saves: the confirmation names the factor (every stored value multiplied or divided by 100), shows a before-and-after built from your organization’s own highest stored rate, and states that switching back restores the original values exactly.

Amount columns that describe activity (charge-offs, recoveries, principal paid) can be reported three ways, and the reporting basis says which:

  • Amount for that month: each month’s figure is that month’s own activity.
  • Running total (life-to-date): each figure is everything to date.
  • Year-to-date (resets in January): each figure is everything since the start of the calendar year.

A running total read as monthly activity would count the same charge-off once for every month it stays in the file. That is why this is the one declared fact that can stop you.

Which columns ask. A column mapped to Charge-Off Amount, Net Charge-Off Amount, Recovery Amount, Actual Principal Paid, Actual Payment Amount, Scheduled Principal Due, Scheduled Principal Paid, or a ledger’s Transaction Amount. Other amount columns, such as Payoff Amount and Partial Prepayment Amount, are read as each month’s own figure.

Vintage reads the column’s month-by-month history for a sample of your loans and looks for shapes that settle the question. A single decrease anywhere in that sample settles it for the whole column, because a running total cannot go down; when the sample cannot settle it, Vintage asks rather than guesses.

  • Values that go down within a year cannot be a running total. Vintage pre-fills Amount for that month as a suggestion to confirm.
  • At most one value per loan carries no running-total signal, so it is pre-filled the same way.
  • Values that reset each January, and never go down at any other time, suggest Year-to-date, also to confirm.
  • Values that only ever climb, or repeat one non-zero figure unchanged, could be monthly amounts or a running total, and Vintage cannot tell which. When that shape appears on at least three loans (or on every loan with more than one value, in a book with fewer than three such loans), it asks, and blocks: you cannot continue past Column Mapping, and the upload cannot be finalized, until you answer. When the values repeat unchanged month after month, the question notes that this is usually a running total. A climbing series on only one or two loans in a book where every other loan is flat at zero reads as repeated monthly events, not as a running total.

Scheduled principal needs one more check, because on a level-payment loan the monthly scheduled principal also only ever climbs. For Scheduled Principal Due and Scheduled Principal Paid, Vintage compares the column with each loan’s own balance. When enough sampled loans, over at least four consecutive month-to-month changes each, report a figure close to that month’s drop in balance (never more than three times it, never above the scheduled payment, and not climbing month by month), and no loan in the sample looks like a running total, it pre-fills Amount for that month for you to confirm. Anything less clear still asks.

While an answer is still Vintage’s suggestion, the chip says so and asks you to confirm it. Once the answer is yours (chosen now, or carried in from your organization’s earlier declaration), the explanation says it came from you. Your declaration is never displaced by a later suggestion, and re-uploads of the same column ask nothing.

Before any measurement, Vintage turns every running-total or year-to-date column into monthly increments. For a loan whose column reports a total each month, the amount booked in month t is

Δt=max⁡(0,  Ct−max⁡s ≤ t−1Cs)\Delta_t = \max\left(0,\; C_t - \max_{s \,\le\, t-1} C_s\right)

where C_t is the total reported for month t and the inner maximum is the highest figure reported for that loan in any earlier month (for Year-to-date, any earlier month of the same calendar year, so January’s figure books in full). In words: each month books only what the total rose above its earlier high. For a total that only rises, the booked amounts add up to its final figure, so a charge-off books exactly once.

A running-total charge-off column reporting 0, 500, 500, 800 over four months books 0, 500, 0, and 300, a total of 800. If a running total ever falls, that month books nothing, and later months book only what rises above the earlier high.

One exception protects loans that began before your data does: the first figure Vintage sees for such a loan is activity that happened where Vintage could not see it, so it sets the starting level and books nothing. See Missing and unreported data.

The same normalization keeps prepayment speeds honest. The speed measure subtracts each month’s scheduled principal from the balance; a life-to-date scheduled principal read as monthly would subtract everything scheduled since origination, until a performing loan dropped out of the measure. Declared, each month subtracts only its own. See Prepayment speeds.

The How amounts are reported section on the Standard Fields tab of the Fields page lists every amount column your organization has mapped, with its reporting basis, editable in place. Each row says whether the setting is your answer, Vintage’s unconfirmed suggestion, or not set, in which case the column is being read as each month’s own amount. Saving a change re-measures your whole portfolio; you do not upload anything again.