---
id: casos/inadimplencia
area: Finance
usage: widely used
effort: medium
grain: Bill or invoice x reference date; aggregated to customer (tax ID) x reference date
testado_com_agente: Oct 2026
---

# Overdue payment monitoring

Who owes, for how long and how much, in a daily snapshot that matches accounts receivable, without counting payment attempts or renegotiated debt twice.

## Executive summary

**For:** Finance, collections and leadership at companies that sell on credit, by boleto or by subscription.

**What it solves**

- The overdue balance in the report matches accounts receivable in the ERP or billing system.
- Each customer appears once, with the real debt, without repeated attempts or doubled renegotiations.
- The collections team gets the day's queue in priority order.

**Why it matters:** Delinquency grows without an alarm: billing issues the charge, the customer does not pay and nobody notices until cash gets tight. Each system holds a piece, and adding them without rules counts the same debt twice, mixes those who paid late with those who still owe and labels as delinquent a declined card that gets paid two days later. Acting in the short bucket recovers far more than chasing after 90 days.

**Business questions it answers**

- How much is overdue today and in which aging buckets?
- Who are the 10 customers with the largest overdue amount and for how long?
- Is this month's delinquency higher than last month's?
- How much of the failed charges was recovered without any action from the team?
- Which customers are due in the next 7 days and have been late before?
- How much revenue is stuck in collections by product or unit?

**What you need**

- ERP or billing connected to Nekt, with bills or invoices, settlements, customers and each bill's issue, due, payment and cancellation dates
- The company's collection policy: buckets, deadlines and what to do in each
- The collections CRM connected, if the team works there

**What you get**

- A daily snapshot per bill with days overdue, bucket and open balance
- Overdue balance by customer, bucket and month, with the delinquency rate
- A prioritized collection queue sent to the CRM or the team's channel
- An AI agent that answers about overdue payments with the right rule

## Detailed

### The problem

Billing shows each charge's current status, the ERP shows bills with a text status and the collections CRM shows only what someone copied there. Summing everything marked as late counts a declined card attempt as debt, keeps a renegotiation's old bill next to the new installments and mixes those who paid late with those who still owe. The number changes depending on when you look, and nobody can rebuild last month's delinquency.

### Business rules

1. **Delinquent means past due, unpaid, with positive delay.** A bill is delinquent on the reference date when its actual due date (with extensions applied) is before that date and it has not been paid. Not yet due and due today do not count. Cancelled is always out. A partial payment leaves only the remaining balance delinquent. In billing systems with automatic card charging, the invoice often has no due date: the actual due date is the date the invoice was finalized, when the first charge is attempted (in Stripe, `due_date` is null for `charge_automatically`; use `status_transitions.finalized_at`). (Avoid: Counting as delinquent everything with a pending status, including what is due today.)
2. **The measure is the snapshot on the reference date.** Official delinquency is a one-day picture: who owes on that date, how much and for how long. Having been late at some point in the month is a different metric, for history only. Store the daily or monthly snapshot in append mode so a past month's delinquency can be rebuilt exactly. Until a snapshot is stored, a past date can be rebuilt from each bill's status transition dates (issued, paid, cancelled, written off), never from the current status. In Stripe, these dates live in `status_transitions`. (Avoid: Flagging as delinquent for the month anyone who was late and paid days later.)
3. **Aging covers open items only.** Aging buckets cover only bills without a settlement. A paid bill leaves aging, even if it was overdue for months, and moves to the punctuality metric: days between due date and payment. Buckets are contiguous and start at 1 day, so the sum of the buckets equals the overdue balance. (Avoid: Computing days overdue for bills already paid and mixing them into the buckets.)
4. **Open balance is the amount minus settlements.** Each bill's balance is the bill amount minus recorded settlements. Before trusting the ERP's ready-made balance field, test it: in real cases it came empty or zero on most installments. Interest and late fees received are kept apart from principal. In billing systems the ready-made remaining amount also misleads: in Stripe, `amount_remaining` stays filled on voided (`void`) and draft (`draft`) invoices and on invoices paid outside Stripe (`paid_out_of_band`, with no `amount_paid`). Treat any bill with a payment date on or before the reference date as settled, and drop drafts and voided ones. Sum balances per currency, never different currencies together. (Avoid: Using the ready-made balance field without checking, adding voided or draft invoices, or using the face value of a partly paid bill.)
5. **Renegotiation does not double the debt.** When debt is rescheduled, the old bill is replaced by the new installments. A bill with renegotiated status (which some ERPs zero out) leaves, and only the new installments count. If the ERP keeps the old one as late, flag it by the renegotiation and take it out of the sum. In billing systems, renegotiating usually means voiding the invoice and issuing a new one (in Stripe, `void` plus a new invoice): the voided one leaves from its void date, and snapshots of earlier dates do not change. (Avoid: Adding the old late bill to the new installments of the agreement.)
6. **A payment attempt is not debt.** In billing systems, each declined card attempt becomes a row, and the same invoice can have several. The grain for delinquency is the invoice or bill, never the attempt. While an invoice is being retried and is past due, it shows in the snapshot in the first bucket, like any open bill; once paid, it leaves. Do not create an exception for invoices in retry. Recovery within the billing cycle is measured separately, in the recovery rate. (Avoid: Counting each declined charge as a delinquency case.)
7. **The debtor is the tax ID.** Group by normalized and validated CPF (individual tax ID) or CNPJ (company tax ID), 11 or 14 digits, not by name. A tax ID of the wrong length is treated as missing, so debt does not stick to the wrong customer. The payer can differ from the account holder (a parent paying for a student, a head office paying for a branch): link the bill to the contract by id, and use the payer's tax ID for collection. (Avoid: Grouping by customer name or linking bills by person without looking at the contract.)
8. **The source is the ERP or billing, not the CRM mirror.** When bills are copied into a collections CRM, the CRM has sync lag and a cutoff date: anything older than the integration is not there. Use the CRM to know which collection stage a customer is in, and the ERP or billing to know how much they owe. (Avoid: Answering how much a customer owes from the collections CRM.)
9. **What is not a customer leaves the portfolio.** Loans between partners, balances between group companies, companion bills for card prepayments and test charges are not delinquency. An old pending charge with no operational trace (no link, boleto, Pix QR Code or invoice) is not real debt either. (Avoid: Measuring delinquency over every registered receivable.)

### Aging buckets and what to do

Example of a policy with contiguous buckets. The company sets the cutoffs and actions.

- **Due in the next 7 days** → Preventive (`reminder before the due date`)
- **1 to 5 days overdue** → Automatic reminder (`days overdue 1 to 5`)
- **6 to 30 days overdue** → Contact from the collections team (`days overdue 6 to 30`)
- **31 to 60 days overdue** → Negotiation (`days overdue 31 to 60`)
- **61 to 90 days overdue** → Service or credit suspension (`days overdue 61 to 90`)
- **Over 90 days** → Credit bureau listing, protest or collection agency (`days overdue > 90`)
- **Paid, even if late** → Leaves aging (`moves to punctuality`)

### Definitions

| Metric | Definition |
|---|---|
| Overdue balance | sum of the open balance of bills with an actual due date before the reference date, excluding cancelled, replaced renegotiated and written-off bills, on the reference date, per currency |
| Days overdue | reference date minus actual due date, in calendar days, for open bills only |
| Aging bucket | contiguous interval, starting at 1 day, into which the bill's days overdue fall on the reference date |
| Delinquency rate | overdue balance beyond the policy cutoff (for example 30 days) / total open balance of the portfolio, on the same reference date |
| Delinquency by vintage | unpaid amount of bills from one due month, measured N days after that month |
| Recovery rate | invoices with at least one failed payment in the month that were paid within one billing cycle / invoices with a failure in the month |
| Punctuality | for paid bills, days between the actual due date and payment; zero or less is on time |
| Collection priority | queue order by the customer's number of overdue bills and then by overdue balance |
| Write-off (marked uncollectible) | amount of bills marked as uncollectible; they leave the portfolio on the write-off date (in Stripe, `status_transitions.marked_uncollectible_at`) and go to the period's write-off metric |

### Pitfalls

- **The collections CRM did not have everything.** Leadership asked how much each customer owed and the answer came from the CRM mirror, which only had bills created after the integration started. Total debt looked much smaller. How to avoid: Amounts always from the ERP; the CRM only for the collection stage.
- **A ready-made balance that did not match.** In the ERP, the current balance field on installments came empty or zero on almost every bill, and delinquency computed from it was close to nothing. In billing the error went the other way: the remaining amount stayed filled on voided, draft and out-of-band paid invoices, and the direct sum came out several times larger than the real overdue balance. How to avoid: Compute the balance from the bill amount and settlements, settle by payment date, drop voided and draft invoices, and test the ready-made field first.
- **Write-offs that summed to zero.** The write-off amount came as an object with date and value, not as a number. Summed directly, total write-offs came out as zero, and zero looked like a result. How to avoid: Read the value field inside the object and distrust a total that is exactly zero.
- **Migration counted twice.** Bills migrated from an old system stayed open there and were settled in the new system, and the same charge appeared twice. How to avoid: Flag migrated bills and use only the system where settlement happens.
- **Pending charges with no trace.** The billing system kept old pending charges that never had a boleto, link or Pix issued, and they inflated the overdue balance. How to avoid: Exclude pending charges with no operational trace.
- **A wrong tax ID made debt stick.** Hundreds of records had a CNPJ field of the wrong length and started matching other customers. How to avoid: Normalize, validate 11 or 14 digits and treat the rest as missing.

Validated on real data: In Nekt's own Stripe account, declined charges were concentrated in a few invoices, with about three declined attempts per invoice, and 84% of those invoices ended up paid, with a median of 2 days between the first failure and payment. Counting each attempt as delinquency would triple the number and trigger collection for debts that resolve themselves.

### Acceptance test

- [ ] For a reference date, the sum of the buckets equals the total overdue balance and no overdue bill is left without a bucket.
- [ ] The overdue balance per customer matches the open and overdue invoices report of the ERP or billing system itself on the same date (difference below 0.5%), not another transformation built on the same table.
- [ ] No paid, cancelled, replaced renegotiated, not yet due or due-today bill appears as delinquent.
- [ ] Each invoice appears once in the overdue portfolio, whatever the number of payment attempts.
- [ ] Rebuilding the snapshot for a past reference date returns exactly the same overdue balance.

### Context document

```text
Overdue payment monitoring
- Delinquent = bill with an actual due date before the reference date and an open balance above zero. Not yet due and due today do not count. Cancelled is out.
- Actual due date = due date; if an automatically charged invoice has no due date, its finalization date (Stripe: status_transitions.finalized_at).
- The main definition is the snapshot on the reference date. Late at some point in the month is a historical metric and must be labeled as such.
- Aging covers open bills only. Paid bills go to punctuality (days between due date and payment).
- Buckets: <1 to 5, 6 to 30, 31 to 60, 61 to 90, over 90>. The sum of the buckets equals the overdue balance.
- Open balance = bill amount - settlements, zero if paid by the date. Interest and late fees are kept apart. Do not use the ready-made balance (Stripe: amount_remaining stays filled on void, draft and paid_out_of_band). Never add different currencies.
- Renegotiation: the replaced or voided bill leaves from its void date; only the agreement's installments count. Earlier snapshots do not change.
- A written-off bill leaves the portfolio on the write-off date and goes to the write-off metric.
- The grain is the invoice or bill. Declined payment attempts are not delinquency cases; a failure paid within one cycle is a recovery.
- Debtor = validated CPF or CNPJ. Never group by name.
- How much a customer owes comes from the ERP or billing. The collection stage comes from the collections CRM.
- Out of the portfolio: partner loans, intercompany, technical card prepayment bills and charges with no operational trace.
- Delinquency rate = overdue beyond <cutoff> days / open portfolio, on the same date.
Client exceptions:
- <client>: bills paid outside billing are settled in <system>; treat them as paid on the date recorded there.
- <client>: bills with flag <flag> came from system <old> and are settled in <new>; count them only in <new>.
- <client>: customers with a <product> contract are not suspended before <n> days overdue.
```

### Variations

- **Subscriptions and dunning:** Grain per recurring invoice, with recovery rate per cycle and a list of cards to update before the due date.
- **Installment or financed sales:** Installments adjusted by an index, delinquency by development or vintage and priority by number of overdue installments.
- **Loss provision:** A percentage per bucket over the overdue balance, with the debtor's longest delay applying to all their bills.