---
id: financeiros/inadimplencia-aging-pdd
industry: Financial services
usage: widely used
effort: medium
grain: Receivable or installment x reference date (monthly snapshot)
---

# Delinquency by days-past-due bucket and PDD (loan-loss provision)

The overdue portfolio by days-past-due bucket and the provision at each close, reproducible month after month and without counting the same debt twice.

## Executive summary

**For:** Lending fintechs, FIDCs (receivables investment funds) and securitization companies, credit unions and BPO firms that close the portfolio every month.

**What it solves**

- The overdue balance by days-past-due bucket matches the administrator's or the ERP's report on the same date.
- The month's PDD comes out by bucket, by debtor and by assignor, with write-offs kept separate.
- Last month's close does not change when someone reopens the report.

**Why it matters:** Delinquency is the number that decides credit limits, portfolio purchases and the provision on the balance sheet. When the aging counts renegotiations twice or mixes paid receivables with open ones, the board stops trusting the dashboard and goes back to the spreadsheet. A reproducible close is also what investors and auditors ask for.

**Business questions it answers**

- How much of the portfolio is overdue today, and in which days-past-due bucket?
- How much do we need to provision at this close, and how much did it rise versus last month?
- Which debtors and assignors concentrate the risk?
- How many new contracts went overdue on the very first installment?
- What was the 31 to 60 days overdue portfolio at last month's close?
- Which receivables will move to a higher bucket next month if they are not paid?

**What you need**

- The source of receivables or installments connected to Nekt: lending core, fund system, ERP or portfolio file
- The bucket schedule and PDD percentages from the credit policy
- The date and cutoff time of the monthly close

**What you get**

- A monthly snapshot with one row per receivable, days-past-due bucket and PDD
- A dashboard of aging, PDD and concentration by debtor and assignor
- An AI agent that answers questions about delinquency with the right schedule
- Alerts for receivables about to move to a higher bucket

## Detailed

### The problem

Each system stores delinquency differently: days past due calculated in the core, status as text in the ERP, a ready-made PDD bucket in the administrator's file. Summing everything marked as overdue counts renegotiations twice, mixes already paid receivables with open ones and lands on a number nobody can reproduce the following month. Without the schedule written down, the AI agent also answers with the wrong bucket.

### Business rules

1. **Aging covers only what is open.** Aging covers only receivables without a settlement (empty settlement date). A settled receivable leaves the aging, even if it was overdue for months, and moves to the payment punctuality schedule (liquidity): days between the due date and the settlement, with early settlement counting as on time. The cutoff is the settlement date, not the open balance, which may not reflect the settlement in every case. (Avoid: Calculating aging over every receivable, paid and open.)
2. **Filter the current receivable before summing.** Receivables systems store receivables at several processing stages. Only the current stage goes into the schedules. In a real case, a non-current stage held most of the open value in the base and multiplied the portfolio. Canceled receivables come out of every sum. (Avoid: Summing the open balance of the entire receivables table.)
3. **Bucket by days past the actual due date.** Days past due = reference date minus the actual due date, including extensions. Buckets are contiguous and start at 1 day, for example: up to 5, 6 to 30, 31 to 60, 61 to 90, 91 to 120 and over 120. Receivables not yet due stay out of the overdue buckets; one due today is still not yet due. (Avoid: Loose limits, such as "greater than 1 and up to 29", which leave day 1 without a bucket.)
4. **Delinquency is overdue, not upcoming.** In the ERP, delinquency is the overdue status. A VENCER (not yet due) and VENCE HOJE (due today) do not count. CANCELADO (canceled) always comes out. In Conta Azul, RENEGOTIATED comes with a zero total and is replaced by the new installments, so it comes out too. (Avoid: Counting everything not yet received as delinquency.)
5. **Renegotiation must not double the debt.** When a debt is rescheduled, some ERPs keep the old receivables as overdue and create the new installments. For a debtor with an active renegotiation, use the negotiated amount from a curated base, and state in every analysis whether the number is gross or curated. The difference has exceeded 40% for individual clients. (Avoid: Summing the ERP's gross overdue amount.)
6. **PDD is the base times the bucket percentage.** Each receivable's provision is the calculation base times the bucket percentage in the credit policy. The policy may vary the percentage by the debtor's region; in that case, store the region on the receivable and pick the right column. If the administrator's portfolio file already includes the PDD bucket and amount, use those values and keep the schedule for auditing or for other sources. (Avoid: Recalculating on top of the PDD the administrator already delivered.)
7. **Drag effect by debtor.** If one of a debtor's receivables is in a high bucket, all of that debtor's open receivables, overdue or not yet due, are provisioned at the highest bucket. The rule applies from any bucket and is reassessed at every update: if the most overdue receivable is paid, the debtor's bucket is recalculated from the remaining ones. Group by the debtor's tax ID, not by name. (Avoid: Provisioning each receivable only by its own delay.)
8. **Write-offs stay out of the buckets.** A confirmed loss (write-off, such as the WOP and WOM buckets in fund portfolio files) is 100% provisioned and handled separately. The write-off variants differ only in when they were requested, so they are summed together, never inside the last bucket or in the PDD summary by assignor. (Avoid: Adding write-offs to the over-120-days bucket.)
9. **The close is a snapshot that does not change.** Store one snapshot per reference date. On day 1, an automatic pre-close takes the last load after the reconciliation cutoff time, so it does not capture the overnight portfolio before reconciliation. The manual close replaces only that month's slot. The table accumulates and no history is deleted. (Avoid: Reading last month's close from the current table.)

### Schedules based on days relative to the due date

Liquidity and aging are operational, PDD is accounting. They use the same days and coexist.

- **Settled, settled by the due date** → On time (liquidity schedule) (`settlement date filled`)
- **Open, due today or later** → Not yet due: today, up to 5, 6 to 15, 16 to 30, 31 to 60... (`settlement date null`)
- **1 to 5 days overdue** → Bucket A (`PDD zero or minimal`)
- **6 to 30 days** → Bucket B (`policy percentage`)
- **31 to 60 days** → Bucket C (`policy percentage`)
- **61 to 90 days** → Bucket D (`policy percentage`)
- **91 to 120 days** → Bucket E (`policy percentage`)
- **Over 120 days** → Bucket F (`100%`)
- **Confirmed loss** → Write-off, outside the buckets (`WOP / WOM, 100%`)

### Definitions

| Metric | Definition |
|---|---|
| Overdue balance | sum of the open balance of current receivables, unsettled and with an actual due date before the reference date, by reference date |
| Days past due | reference date minus actual due date, in calendar days; negative = not yet due |
| Days-past-due bucket | the contiguous bucket the receivable's days past due fall into on the reference date |
| Receivable PDD | calculation base x percentage of the debtor's bucket (drag effect), on the reference date |
| Delinquency rate | overdue balance above the policy cutoff (for example 30 days) / total open balance of the portfolio, on the same reference date |
| FPD | a contract whose first installment came due and was not paid; flagged per contract and measured by origination month |
| Liquidity | for settled receivables, days between the actual due date and the settlement; zero or less is on time |
| Write-off | confirmed-loss receivables, 100% provisioned, summed as their own group |

### Pitfalls

- **Day 1 without a bucket.** A schedule written as "greater than 1 and up to 29" left receivables exactly 1 day overdue outside every bucket, and the total by bucket did not match the overdue balance. How to avoid: Test that the sum of the buckets equals the overdue balance.
- **Not yet due for ten years.** Recurring contracts generated receivables coming due well into the next decade. Summing everything described a long-term portfolio, not the risk or the quarter's cash. How to avoid: Filter the due date window before summing what is not yet due.
- **Dates and amounts as text.** Dates in dd/mm/yyyy stored as text sort alphabetically, and the MAX of the reference date returned the wrong month without any error. Amounts such as '1.234,56' converted directly turned into nulls. How to avoid: Convert Brazilian-format dates and numbers before any filter.
- **A key that becomes 123.0.** Contract ids read as decimal numbers arrived as '123.0' and did not join contracts to installments. How to avoid: Normalize the key as text, without the decimal suffix.
- **Empty receipt data.** In the ERP, the receipt block on the receivable came back empty for every receivable. Filtering by it said nothing had been received in the month. How to avoid: Received amounts come from the financial transactions, not from the receivables table.
- **Shareholder loans as portfolio.** Loans between partners and intercompany balances registered as accounts receivable inflated delinquency. How to avoid: Exclude shareholder loans and intercompany before measuring delinquency.

### Acceptance test

- [ ] For a closed reference date, the sum of the buckets equals the total overdue balance and no overdue receivable is left without a bucket.
- [ ] The open balance by assignor matches the administrator's or the ERP's report on the same date (difference below 0.5%).
- [ ] No settled, canceled or renegotiated receivable appears in the aging.
- [ ] Total PDD equals the sum of buckets A through F plus write-offs, and write-offs do not appear inside bucket F.
- [ ] Reprocessing a past month's close returns exactly the same balance and the same PDD.

### Context document

```text
Delinquency, aging and PDD (loan-loss provision)
- Source of receivables: <table>. Consider only current receivables (stage <x>) and never canceled ones.
- Aging covers only open receivables (null settlement date). Settled receivables go to the liquidity schedule (days between actual due date and settlement; zero or less = on time).
- Days past due = reference date minus actual due date. Buckets: A up to 5, B 6 to 30, C 31 to 60, D 61 to 90, E 91 to 120, F over 120. A receivable due today is not yet due.
- Delinquency in the ERP = overdue status. A VENCER (not yet due) and VENCE HOJE (due today) do not count. Canceled and renegotiated come out.
- For a debtor with an active renegotiation, use the curated base and say whether the number is gross or curated.
- PDD = calculation base x the policy's bucket percentage. If the administrator's portfolio file already includes the PDD bucket and amount, use those values.
- Drag effect: all of a debtor's open receivables use the highest bucket among them. Group by the debtor's tax ID.
- Write-off (WOP, WOM) is a confirmed loss, 100% provisioned, summed separately and never inside bucket F.
- Close: use the snapshot for the requested reference date. Pre-close on day 1, manual close afterwards. Never answer about last month with the current table.
- Convert dd/mm/yyyy dates and '1.234,56' amounts before filtering or summing.
- If the question does not say which entity (fund, securitization company or consolidated), ask before answering.
Per-client exceptions:
- <client>: PDD percentages from the column for the debtor's region <region>.
- <client>: current receivable stage = <code>; other stages stay out.
- <client>: active renegotiations come from the curated base <table>, not from the ERP.
```

### Variations

- **Provision projection:** Age each open receivable to the next close and calculate the PDD increase from bucket changes, already with the drag effect.
- **Vintages:** Delinquency and FPD by origination month and months since origination, using the first version of the customer record.
- **Monthly fee delinquency:** Credit unions and firms: contracts with a delinquent status by region and consultant, with tenure in days until cancellation.