How a Payment Entry Is Coded on a Credit Report

Payment history is the single largest input into most general-purpose credit scoring models, yet the raw data behind it is not a simple yes/no field. Each payment event is translated into a structured tradeline entry by the furnishing creditor — typically a card issuer or lender — before it reaches a credit bureau's database. That translation follows an industry-standard coding framework called the Metro 2 format, maintained by the Consumer Data Industry Association.

This piece covers the mechanics of how a single payment event — on time, late by a few days, or severely delinquent — becomes a coded record inside a credit report. It does not cover what a scoring model does with that record once it arrives; that is a separate computational step. The focus here is the data structure itself: what fields exist, how they are populated, and what the resulting entry actually represents.

How a Single Payment Event Becomes a Tradeline Status Code

A furnisher — the entity that extended the credit — reports account data to one or more credit bureaus on a regular cycle, typically once per calendar month. The reporting cycle does not align with the consumer's statement cycle in any fixed way; a furnisher may report on the 15th of the month regardless of when the account's payment due date falls.

At the moment of reporting, the furnisher assigns an Account Status code to the tradeline. Under the Metro 2 framework, the most commonly used status codes for open revolving accounts are: 11 (current, paid as agreed), 71 (30–59 days past due), 78 (60–89 days past due), 80 (90–119 days past due), 82 (120–149 days past due), 83 (150–179 days past due), and 84 (180 or more days past due). A separate Payment Rating field captures a 0–9 scale, where 0 means current and each subsequent integer represents the next 30-day delinquency bucket.

The critical timing rule is that a payment is not coded as late until it is at least 30 days past the contractual due date. A payment made one day late — or even 29 days late — is not reportable as delinquent under the Fair Credit Reporting Act's accuracy standards. The 30-day threshold is the minimum unit of delinquency the system recognizes. This means a payment made 29 days after the due date produces no negative status code, while a payment made 31 days after the due date produces a "30-day late" entry, even though the practical difference between those two events is two days.

Once the furnisher assigns a status code for a given reporting month, that month's code is stored in the Payment History Profile — a rolling 24-month string of single-character codes appended to the tradeline. Each position in that string corresponds to one calendar month. The string moves forward each month, and the oldest month eventually drops off the visible window, though the underlying account history may remain on the report for the full statutory period.

Furnishers, Bureaus, and the Data Pipeline Between Them

The furnisher. A furnisher is any entity that provides consumer credit data to a credit bureau — card issuers, auto lenders, mortgage servicers, and some utility or telecom providers. The furnisher owns the source data: the account number, the credit limit, the balance at the time of reporting, the payment due date, and the actual date of last payment. It is the furnisher's system that produces the status code and Payment Rating, not the bureau.

The credit bureau. A credit bureau (also called a consumer reporting agency) receives the Metro 2 data file from the furnisher and ingests it into its own database. The bureau does not independently verify whether the code the furnisher assigned is accurate; it stores what it receives. If a furnisher reports an incorrect status code — for instance, coding an account as 60 days late when it was only 25 days past due — the bureau's record will reflect that error until the furnisher corrects it or a dispute process resolves it.

The Metro 2 format. Metro 2 is the data standard that defines every field and acceptable value in a furnisher's submission. It specifies not only the Account Status and Payment Rating fields but also fields for the Account Type (revolving, installment, open), the Terms Frequency (how often a payment is due), the Scheduled Monthly Payment Amount, and the Actual Payment Amount. Each of these fields contributes to how a bureau stores and presents the tradeline, and how a scoring model reads it.

Thin credit files. A thin credit report — sometimes called a thin credit history or thin credit score situation — arises when a consumer has fewer than three to five active tradelines, or tradelines with very short histories. Scoring models that require a minimum number of tradelines or a minimum account age may be unable to produce a score at all from a thin credit file. The coding mechanism itself does not change for thin files; the issue is that there are too few coded entries for the model's algorithm to generate a statistically reliable output. A thin credit score, where one can be produced, carries wider uncertainty bands than a score built on a longer payment history profile.

Where the Coding System Produces Unexpected or Disputed Results

The reporting-cycle lag. Because furnishers report on their own schedule rather than on the consumer's billing cycle, a payment made on time may not appear as current on the bureau's file for several weeks. Conversely, a payment that was late but cured before the furnisher's next reporting date may never generate a negative code — or it may, depending on whether the furnisher's system captures the status at the moment of the cycle cutoff or at the moment of actual payment.

Duplicate and conflicting entries. A single account reported to three bureaus may carry three slightly different payment history strings if the furnisher's data files are transmitted at different times or if one bureau's ingestion process encounters an error. A FICO credit report pulled from one bureau may therefore show a different history profile than the same consumer's report from a second bureau, producing different scores from the same underlying account.

Returned payments and status codes. When a payment is submitted and then returned unpaid by the consumer's bank, the furnisher may reverse the "payment received" entry in its system. If the reversal occurs after the monthly reporting cycle has already run, the account may have been reported as current for that month. The following month's report will then reflect the delinquency that the returned payment failed to cure. This creates a one-month gap in the delinquency record that does not reflect the actual payment timeline.

The 30-day cliff effect. The binary nature of the 30-day threshold means that two consumers whose payments are one day apart in timing can receive materially different coded entries. A payment 29 days late produces no delinquency code; a payment 31 days late produces a "30-day late" marker. Scoring models treat these two outcomes very differently, even though the underlying behavior differs by only 48 hours.

Aging and removal timelines. Negative payment history codes do not remain on a report indefinitely. Under the Fair Credit Reporting Act, most negative entries must be removed after seven years from the date of first delinquency. How a derogatory mark ages off a credit report follows a specific clock that starts at the original delinquency date, not the date the account was closed or charged off — a distinction that affects when the entry disappears from the Payment History Profile string.

What a Credit Report Actually Displays — and What It Omits

A consumer-facing credit report typically presents the Payment History Profile as a color-coded grid or a string of symbols, with each cell representing one month. Green or "OK" cells indicate a current status code; amber or red cells indicate a 30-, 60-, or 90-day late code. What the display does not show is the underlying numeric code (71, 78, 80, etc.) from the Metro 2 file, the exact dollar amount that was or was not paid, or the specific date within the month that the furnisher ran its reporting cycle.

The report also does not show the Payment Rating field separately from the Account Status field in most consumer-facing formats — they are collapsed into a single visual indicator. This means a consumer reading their report cannot easily distinguish between an account that was coded as 30 days late and immediately cured versus one that rolled progressively from 30 to 60 to 90 days late before being resolved.

For accounts that have been referred to a collection agency, the payment history on the original tradeline typically stops updating at the point of charge-off, and a separate collection tradeline may appear. How a collection account lands on a credit report involves its own coding fields — including the original creditor's name, the collection agency's name, and the date of first delinquency — which are distinct from the payment history string on the originating tradeline.

A FICO credit report — meaning a report accessed through a service that also delivers a FICO-branded score — presents the same underlying bureau data as a standard report. The score displayed alongside it is computed from that data at the moment of the pull; it is not stored on the report itself. The report shows the inputs; the score is a separate output calculated on demand. Neither the report nor the score reveals the specific weight assigned to any individual payment history entry by the scoring model's algorithm, as those weights are proprietary.

The payment history entry on a credit report is a data record produced by a pipeline of furnisher systems, standardized formats, and bureau databases — each step introducing its own timing rules, field definitions, and potential for discrepancy between what happened and what was coded.

Note: This explains how credit cards work as financial systems. It is not financial advice, it is not a recommendation of any card or provider, and it is not a substitute for the CFPB's own guidance. Check the cited sources for current regulatory detail.