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

Source

Receivables and installments from the core, the fund or the ERP

Rule

Only what is open, bucket by days past due, PDD by bucket

Outcome

Aging and provision by receivable, debtor and assignor

Activation

Close, dashboard, AI agent and collections

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.

Business questions it answers

Ask your agent these questions once the case is live.

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

Where to activate

Monthly close

Snapshot by reference date, with a pre-close on day 1 and a manual close that replaces only that month.

AI agent via MCP

Answers about overdue balance, PDD and concentration with the schedule and entity scope already applied.

Collections cadence

Sends days-past-due bucket, maximum delay and FPD back to the CRM or to the collections WhatsApp.

Ready to build?

The bucket schedule is simple. The work is in cleaning up statuses and renegotiations and building the versioned close. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.

See detailed view

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.

How it is usually done, and the rule

Each row is a mistake that already happened in practice.

The common wayThe rule

Calculating aging over every receivable, paid and open.

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.

Summing the open balance of the entire receivables table.

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.

Loose limits, such as "greater than 1 and up to 29", which leave day 1 without a bucket.

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.

Counting everything not yet received as delinquency.

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.

Summing the ERP's gross overdue amount.

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.

Recalculating on top of the PDD the administrator already delivered.

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.

Provisioning each receivable only by its own delay.

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.

Adding write-offs to the over-120-days bucket.

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.

Reading last month's close from the current table.

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.

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 dateOn time (liquidity schedule)settlement date filled

Open, due today or laterNot yet due: today, up to 5, 6 to 15, 16 to 30, 31 to 60...settlement date null

1 to 5 days overdueBucket APDD zero or minimal

6 to 30 daysBucket Bpolicy percentage

31 to 60 daysBucket Cpolicy percentage

61 to 90 daysBucket Dpolicy percentage

91 to 120 daysBucket Epolicy percentage

Over 120 daysBucket F100%

Confirmed lossWrite-off, outside the bucketsWOP / WOM, 100%

Definitions

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 that already happened

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.

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.

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.

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.

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.

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.

Exclude shareholder loans and intercompany before measuring delinquency.

Acceptance test

The case is done when every item passes.

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.

Agent package

Paste into Claude, ChatGPT or any client with the Nekt MCP connected.

Full Markdown

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.

Build the "Delinquency by days-past-due bucket and PDD (loan-loss provision)" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/financeiros/inadimplencia-aging-pdd.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.

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.