Payments, contracts and records from the core and billing
Vintage by first payment, customer x month grid, end by stated status
Curves by vintage and MoB, retention and LTV
Committee, board, retention dashboard and AI agent
What it solves
- Each vintage is compared with the others at the same age, without mixing new and old vintages.
- Vintage revenue, active customers and delinquency come from what was paid and what fell due, not from what was billed.
- Average retention is no longer pushed up by those who are still active.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- The payments source connected to Nekt: lending core, subscription invoices or protection core invoices
- The start and end rules agreed with the business: which payment opens the vintage and which status closes it
- The first version of each customer's record (score, channel, employer) or a history starting now
What you get
- A customer x month table with vintage, MoB, active flag, revenue and past due
- Vintage curves ready to compare at the same age
- Retention per contract and realized LTV by region and product
- An AI agent that answers about vintages with the start and end rules
Where to activate
Curves of active customers, revenue and delinquency by vintage and risk tier at entry, side by side at the same MoB.
Answers revenue, delinquency and retention by vintage with the start, end and MoB rules already applied.
Retention of closed contracts, survival curve and 30 and 90-day churn by region, consultant and product.
The customer x month grid is simple. The work is agreeing on the start and end dates with the business and freezing the attributes at entry. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The contracts table says when each customer joined by sign-up date, not by first payment, and the current status rewrites the score and channel at entry. Whoever sums by calendar month mixes vintages of different ages. Whoever computes retention up to today for active customers and up to the last update for inactive ones gets an average that rises on its own and leaves out exactly those who canceled.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Vintage = month of the first confirmed payment: first paid subscription invoice, first disbursed advance or first paid monthly fee of the contract. Sign-up, proposal or contract signing date does not open a vintage, because some people sign up and never pay. State the rule in the context document and check that the code uses the same one.
Score, risk tier, channel, campaign and employer used to slice the curve come from the first version of the record (the oldest by update date) or the version valid on the entry date in the history. The current record changes later: the score goes up, the channel gets corrected.
Generate one row per customer and calendar month since the vintage, with zero where there was no payment. MoB = months between the vintage and the month. Months before the vintage and customers with a deleted account are flagged (MoB -1) and left out of the curves.
The same customer may have more than one account or contract. The curve is per customer (master id or tax ID), adding all accounts; the account shown is the first one. Subscription and advances may have different vintages: keep one MoB per product and say which one the curve uses.
Add only amounts actually paid: invoice with success status, fee with confirmed payment, amount collected on the advance. An open invoice is not revenue, not even when the paid amount is zero and the billed amount is filled. In protection, use only the monthly fee (monthly invoice type), without canceled invoices. A repeated invoice in the same month for the same subscription counts once.
In the reference month, separate what fell due and was not paid (collection date before today with an error or partial payment) from what is awaiting payment (collection in the future). Only past due enters vintage delinquency. Vintage delinquency at MoB k is the past-due unpaid amount / amount disbursed to the vintage, and the migration between buckets from one month to the next is the roll rate.
State which statuses close a customer (for example, inactive, canceled and canceled with pending items) and use the date of the change to that status. In subscriptions, end = cancellation, or the last paid month if later. Delinquent is not an end until it becomes canceled. Every final status counts: leaving plain canceled out removes exactly those who left.
Whoever is still active has open retention. Average retention is computed only among closed contracts, or with a survival curve (percentage still active in each month since entry). Never mix closed contracts with active ones measured up to today.
Compare MoB 3 of one vintage with MoB 3 of the others. Only customers who have had time to reach a MoB enter its denominator. The current month's vintage has not closed its first month yet. Churn in a rolling window (exits in the last 30 and 90 days) is another metric, recomputed on every run, and does not replace the curve.
What opens and what closes the vintage, by business
Rules real operations used. Pick one per product and write it in the context document.
Definitions
Pitfalls that already happened
The context document defined the vintage as the month of the first advance, but the table used the user's sign-up date, and the agent answered with the wrong rule.
Check the vintage column against the first payment on a sample before publishing.
Retention used today as the end for active customers, and the average grew by one day every day with nobody leaving or joining.
Retention only of closed contracts and a survival curve for the base.
Retention treated only inactive and canceled with pending items as an end; plain canceled contracts were left out of the calculation.
A closed list with every final status.
When the paid amount came as zero, the sum used the billed amount, and LTV counted monthly fees that were never paid.
Add only invoices with confirmed payment.
The vintage was sliced by the customer's current score, and the risk tier at entry looked better than it was.
Use the first version of the record or the one valid on the entry date.
Deals deleted from the CRM stayed in the customer journey vintages and created churn that did not happen.
Filter out deleted records before building the vintage.
Acceptance test
The case is done when every item passes.
- Each customer has exactly one row per month since the vintage, with no gaps and no months before it in the curves.
- The vintage of 5 randomly chosen customers equals the month of their first confirmed payment in the source.
- Total grid revenue for a closed month matches confirmed billing payments in the same month (difference below 1%).
- No active contract enters average retention; every contract with a final status does.
- The denominator of each MoB only has customers from vintages that have already reached it.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Vintages and retention - Table: <grid_table>, one row per customer and calendar month, with vintage, MoB, active flag, paid revenue and past-due amount. - Vintage = month of the first confirmed payment in product <product>. Do not use sign-up or contract date. - Vintage attributes (score, channel, campaign, employer) are those at entry, not the current ones. - MoB 0 is the vintage month. Rows with MoB -1 (before the vintage or deleted account) stay out of the curves. - Revenue = confirmed payments only. Open, canceled or zero-paid invoices are not revenue. - Vintage delinquency = past-due unpaid amount / amount disbursed. Upcoming amounts are not delinquency. - Final statuses: <inactive, canceled, canceled with pending items>. End date = date of the status change. Delinquent is not an end. - Average retention only with closed contracts. For active customers, use the survival curve. - Always compare vintages at the same MoB and only with vintages that have already reached it. Exceptions per client: - <client>: customer with several accounts consolidated by id <master_id>; the account shown is the first one. - <client>: funding vintage per development, from the first contribution to the last buyback, only contracted or completed operations.
Build the "Vintages and retention" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/financeiros/safras-permanencia.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
Slice the curve by the install or lead campaign and partner to compare each channel's return at the same MoB.
Migration of amounts between past-due buckets from one month to the next, broken down by vintage, to anticipate provisioning.
In funding and B2B, the vintage belongs to the partner (developer, firm) and measures tenure, first contribution and last buyback.