Renewals, deadlines and 'who hasn't paid': the software that reminds you of the money (not another due-date spreadsheet)

The renewal you discover when the client has already gone

There’s a precise moment when you understand your due-date sheet doesn’t work: it’s when the client says “oh, I thought I’d already cancelled” and you realise the contract had already expired two months ago. Nobody wrote to them. Nobody saw the date coming. The fee simply vanished from your revenue, and you notice at the end of the quarter when the numbers don’t add up.

Whoever lives on recurring revenue — a maintenance fee, a service subscription, a support contract, a policy, a membership, a rental — has a problem that whoever invoices “by project” doesn’t fully get: cash doesn’t disappear in one blow, it leaks drop by drop. A missed renewal here, a forgotten reminder there, a client who “said they’d pay” and then forgot. Each single case looks small. Added up, they’re someone’s salary.

The paradox is that almost everyone already has a “tool” to manage this stuff. It’s called a due-date Excel sheet. It has the columns: client, contract, start date, end date, amount, status. Some keep it updated well, some badly, and in both cases it has the same structural defect: it’s a sheet that doesn’t call you. It sits there, still, waiting for someone to open it at the right moment. And the “right moment” is exactly the one when you’re busy with something else.

This article is about how you go from “a sheet you wait to look at” to “software that reminds you of the money”: who has to pay, what expires when, who hasn’t paid yet, and what to say to each of them without burning the relationship. It isn’t a finance treatise. It’s the point of view of someone who builds these systems to measure and sees, every time, the same scene: healthy companies that lose cash not because clients don’t pay, but because nobody was in charge — or equipped — to remind them in time.

Contracts, fees, PEC, invoices: one thread, not four drawers

Try answering this question without opening anything: client Rossi’s contract, signed in March, with a quarterly fee — has it generated the three invoices due so far? Have they all been paid? And when does the renewal expire?

If to answer you have to open the ERP (for the invoice), the email folder (for the PDF contract), the bank statement (for the receipt) and maybe ask the person in accounts (for the “real” status), the problem isn’t that you’re missing a datum. It’s that the data exist but live in separate drawers that don’t talk. Contract here, fee there, PEC in an archive, invoice in the ERP, receipt at the bank. Four truths that should tell one story and instead each lives on its own.

The value of renewals-and-deadlines software isn’t “having a list”. You already have too many lists. The value is holding one thread that ties together:

• the contract (with its start date, duration, renewal mode — tacit or on confirmation — and the cancellation notice);
• the fee plan that contract generates (monthly, quarterly, yearly);
• the invoices actually issued against each fee;
• the receipts that close each invoice;
• the communications already sent (the renewal notice, the first reminder, the second, the formal PEC).

When these five elements sit on the same thread, something simple but powerful happens: the system knows on its own what state each client is in. Not just “the contract expires on the 30th”, but “the contract expires on the 30th, renewal is tacit with 60 days’ notice, so the cancellation window closes on the 1st of next month, and by the way the last two invoices don’t show as collected”. That’s a judgement, not a datum. And a judgement like that, today, lives in one person’s head in your company. If that person is on holiday, the company goes blind.

This is the first point where “ready-made” stops. An invoicing SaaS shows you invoices. A CRM shows you clients. A calendar shows you dates. None of the three holds the thread — because the thread is made of your logic: how you renew, with what notice, with what tone, with what exceptions for long-standing clients. That logic isn’t in a dropdown of a bought product. It’s in the owner’s head, and it’s exactly the part that has to be pulled out and put into a system.

What accounts needs to see and what sales needs to see

Here’s the most common error, and it’s worth stopping on it because it’s the difference between software that gets used and software abandoned after three weeks.

Whoever commissions the software (“I need to manage deadlines and reminders”) imagines one screen: the list of who has to pay. But in reality there are two different people looking at the same contracts with two opposite questions.

Accounts looks at the money. Their question is: who hasn’t paid, how late are they, how much does it weigh, and where is recovery? They want a cold view, by amount and by days overdue. They want to know that client Bianchi is behind €4,200 for 47 days and that two reminders have already gone out. They want to mark “promised payment by Friday” and see whether Friday arrived. They don’t care if Bianchi is likeable. They care about cash.

Sales (or the owner who sells) looks at the relationship. Their question is: which renewal is coming, and is there a risk the client won’t renew? They want a warm view, by relationship. They want to know that Verdi’s contract expires in 45 days, that Verdi has been a client for six years, that last year they grumbled about the price, and that therefore that renewal needs a phone call, not an automatic PEC. To sales, a hard reminder sent to the wrong client does more damage than a late receipt.

That’s why “one list” isn’t enough. You need at least two views on the same data: one oriented to cash (by days late and amount) and one oriented to the relationship (by renewal window and churn risk). And they need different permissions: sales doesn’t necessarily have to see bank balances, accounts doesn’t necessarily have to touch reserved commercial notes.

A ready-made product gives you one view, the one its product manager decided was “the right one” for the average client. But you aren’t the average client: you have two departments with two questions. Building two views on the same data thread is trivial when you start from the data; it’s impossible when you start from a tool that has already decided what to show you. This distinction — starting from your data and your questions instead of screens someone else drew — is the heart of all the work I also describe in the owner dashboard: it isn’t “having a dashboard” that counts, it’s that it answers the question you actually ask yourself at eight in the evening.

The tone of reminders: if it’s ugly, you lose the client (even if they pay)

There’s a toxic belief behind many “automatic reminder systems”: that chasing payment is something unpleasant to automate so you don’t have to think about it. The result is those credit-collection office emails — “Please settle the overdue amount within 5 days or we will start the procedures provided” — sent automatically to a client of eight years who simply had a crooked month.

That client might pay. And then, at renewal, they don’t renew. Because you, in exchange for a receipt that arrived three days earlier, communicated something precise: I treat you as a number. The tone of the reminder is positioning. It isn’t administration, it’s retention marketing dressed up as administration.

A system done well doesn’t have “the reminder”. It has a scale of tones that changes based on two things: who the client is and how late they are.

• A gentle nudge, before the due date. It isn’t even a reminder. It’s an “I care that everything is in order”: “A reminder that the September fee is due on the 30th, you’ll find the invoice attached, write me if anything.” This, on its own, wipes out a huge slice of delays — because a share of missed payments isn’t bad faith, it’s forgetfulness. The client didn’t pay because they didn’t see it. Reminding them before it becomes a problem is the most profitable thing you can do, and it doesn’t require any hard tone.
• First reminder, relational tone. A few days after the due date: “I don’t see the September fee collected, it may be a timing crossover. Can you confirm?” It leaves a dignified way out. Nine times out of ten the answer is “you’re right, I’ll sort it today”.
• Second reminder, firm but professional tone. Here the register goes up, but without lawyer threats.
• Formal PEC, only when it’s really needed, and — crucial point — only on a human decision, not automatically. The step to a formal PEC is the one that can break a relationship: you don’t delegate it to a rule. The software proposes it (“this client is at the third level, do you want to proceed with the PEC?”), the person decides.

And here comes the part where a language model is actually useful, not as a gadget: writing the right message for that client. Not a template identical for everyone, but a text that starts from the data (name, amount, history, tone set for that client) and proposes a calibrated draft, which the person rereads and sends. AI here prepares and speeds things up — it knocks out in three seconds the “gentle” version, the “firm” one, the “formal” one — but whoever knows the client decides which to send and what to change. It’s the same principle I use when I talk about leads that die: the machine doesn’t replace commercial judgement, it takes the mechanical work off so that judgement applies where it counts.

The reminder, in a system built like this, stops being a chore to automate and becomes a watched relationship: gentle first, clear during, formal only at the last, always with a human holding the wheel at the moments that weigh.

Bank data and ERP: matching, not hope

Here we get to the technical part that makes the difference between a system that works and a toy. Deadline software is worth zero if it doesn’t know on its own who has paid. If every morning someone has to cross the bank statement with the invoice list by hand to tick “this one paid, this one didn’t”, you haven’t automated anything: you’ve only moved the Excel sheet inside a prettier screen.

The real heart is reconciliation (matching) between receipts and invoices. In practice: take incoming movements from the account — via statement, via bank file, or via the standard traces Italian banks expose — and hook them automatically to the right invoice. Sometimes it’s easy (the amount matches, the causal shows the invoice number). Often it’s dirty: the client pays two invoices with one transfer, or pays a round amount that matches no single invoice, or puts an unreadable causal.

A serious system handles the dirty case like this:

• when the match is certain (amount + reference coincide), it closes the invoice on its own;
• when it’s probable (right amount, ambiguous causal), it proposes the pairing and asks for confirmation;
• when it’s uncertain, it leaves the movement “to attribute” in a queue the person empties in five minutes, instead of reconstructing everything from scratch every day.

The keyword is the one in this paragraph’s title: matching, not hope. Without matching, the “paid/not paid” status is a hope updated by hand, therefore always late, therefore unreliable — and a system unreliable on payments is worse than nothing, because you risk chasing someone who already paid (the fastest way to infuriate a loyal client).

This is the point where you see why you need one hand that holds data + backend + frontend. Bank matching is data work (reading traces, normalising amounts and causals, handling edge cases). The logic of when to close automatically and when to ask for confirmation is backend (your rules). The two views for accounts and sales are frontend. And the reminder draft is LLM. If you hand each piece to a different supplier — one does “the bank integration”, one “the ERP”, one “the little site with the dashboard” — you spend half your time acting as traffic cop between suppliers who, when something doesn’t add up, blame each other: “it’s the bank sending a crooked file”, “no, it’s their system reading it badly”. The client in the middle is you, and you pay in hours for the lack of a single direction. I talk about it at length in what it costs not to digitise processes: the biggest cost isn’t the software, it’s the friction of coordinating pieces that weren’t designed to sit together.

When the ERP “already has deadlines” (and nobody uses them)

I have to be honest, because it’s the part software salespeople don’t tell you: many ERPs already have deadlines. There’s the due-date module, there’s the “reminders” section, there’s even the export. So the right question isn’t “do I need software that has deadlines?” — you probably already have it. The question is: why does nobody use it?

The answers, after seeing plenty, are almost always these three:

1. It’s awkward. The ERP’s due-date module is built for the accountant, not for the owner. You get there after six clicks, the screen is full of fields you don’t need, and to send a reminder you have to export, open Word, copy, paste. It’s technically possible and humanly unbearable. So nobody does it.
2. It doesn’t call you. The ERP knows the deadline is today, but it doesn’t tell you. You have to go and look. We’re back to the Excel-sheet problem: a passive tool, in a company taken by a thousand things, equals a tool that doesn’t exist.
3. It doesn’t talk to the rest. The ERP has the invoices but not the PDF contracts, not the commercial notes, not the tone you want to keep with that client. So even if you go in, you’re missing half the picture to decide.

From here the strategic choice, and it has to be made honestly: you don’t always need to build from scratch. Sometimes the right move is not to redo invoicing — which the ERP does well — but to build a thin layer on top: a system that reads deadlines and invoices from the ERP (via its export or its APIs), adds what’s missing (the contracts, the tone, the bank matching, the two views, the calibrated reminders) and puts them in a screen the owner actually opens. You don’t replace the ERP: you put a usable, active interface in front of it.

This is the kind of reasoning that saves months and tens of thousands of euro. A supplier who sells “the new ERP” will tell you to throw everything away and start over. One who sells “the module” will sell you the module. Whoever thinks as your ally asks first: what do you already have that works, and what’s actually missing? Often what’s missing is the 20% — active deadlines, the right reminders, the matching — and that 20% is the whole value. It’s the same principle behind when no-code isn’t enough for your company: ready-made and the standard module take you to 80%, and the last 20% — which is your specific logic — is exactly the part that decides whether the tool changes cash or ends up in a drawer.

Small project, big impact on cash

Good news, and it isn’t quote rhetoric: this is one of the projects with the best effort-to-impact ratio that exist. You aren’t rebuilding the ERP. You’re watching a flow you already have, giving it eyes and a voice.

Let’s do the inertia sums, in euro, with declared estimates (not promises: numbers I see repeating, to adapt to your case).

• Renewals lost to forgetfulness. Imagine a portfolio of 120 contracts with an average fee of €1,500/year. If even only 4% don’t renew out of pure inattention — nobody called in time — that’s about 5 clients, €7,500 a year that vanish without you having lost a pitch or lowered quality. They went out the service door.
• Collection delays. If on average €30,000 of fees circulate with 40 days of avoidable delay, you have a cash hole that costs you in interest, in overdraft, or simply in nerves. A nudge before the due date and a punctual first reminder shift a large part of those days towards zero. It isn’t magic: it’s that the client pays when you remind them at the right moment, with the right tone.
• Admin hours. Crossing statement and invoices by hand, preparing reminders one by one, answering “but I had paid”: put even only half a day a week. That’s ~24 days a year of a qualified person burned on work a machine does better. In euro, depending on who does it, that’s several thousands a year.

Add them up. A project like this, for a services SME, typically pays for itself in a few months, not years — precisely because it touches cash directly, not “productivity” in the abstract. And the impact continues: every month that passes, the system recovers its renewals and its receipts, while the cost of building it you paid once.

The point isn’t “spend on software”. It’s stop giving away cash that is already yours, by contract, and that you lose only because nobody was equipped to watch it.

What you actually see, on go-live day

Concretely, what you find in your hands. Not lines of code: screens and behaviours.

• A “cash” home you open in the morning: who’s late, by how much, for how many days, what’s already gone out to them, what you have to decide today. At the top, the three or four cases that weigh most.
• A “renewals” home for you or for sales: the contracts that expire in the next 30-60-90 days, with risk flagged (long-standing client, client who had grumbled, new client), so the important calls you make before, not after.
• The nudges and reminders that go out automatically for standard cases (the gentle pre-due-date one especially), and that for delicate cases arrive as a draft to approve, calibrated on the client.
• The bank matching that every morning has already closed the paid invoices and leaves you only the small queue of doubtful movements.
• A history per client: what you sent them and when, so you don’t chase them twice and you aren’t caught unprepared if they call.

All of this hooked to the real documents — the contracts, the invoices — so that from every row you get to the PDF without searching in ten folders. It’s the same principle as having software to manage cases and of finding company documents in PDFs: the value isn’t archiving, it’s that at the moment of the decision you have the right document in front of you without searching.

GDPR and tone: two words from an owner, not a treatise

I’m not a lawyer and this isn’t legal advice — it’s the common sense of someone who builds these systems and sees where people get hurt.

Two things to keep in mind, both about measure.

On privacy: you’re processing payment data and punctuality behaviour of your clients. It isn’t top-secret material, but it isn’t stuff to leave in a sheet shared with half the company either. The principle is banal: whoever needs to, accesses it, for what they have to do. Sales doesn’t need bank balances, an external collaborator doesn’t need the full registry. A system done well has the right permissions from the start, and keeps a trace of who saw and sent what. This isn’t “compliance” as a cost: it’s hygiene that protects you if tomorrow a client contests a reminder.

On tone: chasing payment is legitimate, it’s your right, but the how weighs legally and commercially. Disproportionate threats, intimidating tones, chasing someone who already paid: these are errors you avoid with the scale of tones above and with matching that keeps status up to date. Measure is the rule. A gentle nudge has never sued anyone; a threatening PEC sent by mistake to the wrong client, yes.

The rest — how long to keep, how to word the notice, the formal details of the PEC — you see with your consultant. The software only has to make it easy to do the right thing and hard to do the wrong one: sensible permissions, calibrated tones, no automatic send at the moments that burn.

It’s for you if / it isn’t for you if

It’s for you if:

• you live on recurring revenue — fees, subscriptions, support contracts, memberships, rentals — and you still watch them by hand or with a sheet;
• it’s already happened that you discovered a missed renewal late, when there was nothing left to do;
• you have the ERP that “has the deadlines” but nobody uses them because it’s awkward and it doesn’t call you;
• you lose time (and nerves) crossing statement and invoices by hand;
• you want two different views — cash for accounts, renewals for sales — on the same contracts;
• you care about the tone with which you treat clients, even when you have to ask for the money.

It isn’t for you if:

• you invoice only by project, one-off, with no recurrences: here a renewals due-date system counts little;
• you have very few contracts (about ten) and you keep them perfectly in mind: a system would be more weight than help — a good calendar reminder can be enough, and I tell you that honestly;
• you’re looking for the magic wand that “recovers credit on its own”: here automation watches and prepares, but the delicate decisions a person takes, and that’s right.

On the last point I insist because it’s the most misunderstood: if someone sells you “100% automatic reminders that recover everything”, be wary. The value isn’t taking the human out of payments; it’s taking the mechanical work off them — remembering, crossing, writing the draft — and leaving them the judgement on who to treat how and when to raise the tone.

An honest timeline and what happens after

No “live in a week” promise. Here’s how it actually goes, for a project of this size.

Weeks 1-2 — understand your thread. How your contracts are made, which recurrences they generate, with what notice you renew, which tones you want to keep, what accounts must see and what sales must see. This phase is made of questions, not code, and it’s the one that determines whether the system will then get used or not.

Weeks 3-6 — build the core. The contract→fee→invoice→receipt thread, the two views, the pre-due-date nudges and the first reminders, the hook to the documents. At the end of this phase you have something that works on a real subset of clients.

Weeks 6-9 — bank matching and intelligent drafts. Reconciliation with receipts (the part that gives reliable “who paid”) and the calibrated reminder drafts. This is the part that has to be run in on the real dirty cases, yours, not on textbook examples.

Realistic total: two-three months for a solid version in use, with a first useful piece already in a few weeks. Whoever tells you less either hasn’t understood bank matching, or is selling you a demo that will collapse at the first cumulative transfer.

After go-live — and this counts as much as before — there’s maintenance, because reality changes: banks change traces, the ERP updates the export, you introduce a new contract type, you change the tone of a reminder after a case that went badly. A system like this isn’t “delivered and finished”: it’s a live tool that gets adjusted as the company changes. And it’s another reason why one hand that knows the whole system beats three suppliers: when in November the bank changes format, you know who to call, and that person knows where to put their hands without doing the investigation from scratch. All of this lives in the cluster I’ve gathered under documents and workflows — because renewals, deadlines and reminders aren’t an island: they’re a piece of the way your company holds documents, money and decisions together.

If you recognise yourself in the “renewal discovered too late” and you want to reason about how it would be made in your specific case, we always start from there: from your contracts and your recurrences. Look at the projects I’ve built or drop me a line and we talk it through, no commitment.

Frequently asked questions

Do I have to throw away my ERP? Almost never. In most cases the right move is to build a layer on top: read invoices and deadlines from the ERP you already have and add the missing part (contracts, matching, calibrated reminders, usable views). Redoing invoicing from scratch is rarely sensible.

How does the system know who has paid? With reconciliation between receipts (from statement or bank file) and invoices. Certain matches close on their own, ambiguous ones it proposes to you, obscure ones end up in a small queue to clear in minutes. Without this, the “paid” status is a hope updated by hand — unreliable.

Do reminders go out on their own? Don’t I risk offending a long-standing client? Gentle pre-due-date nudges yes, they go out on their own, and they’re the most profitable. Real reminders and the formal PEC arrive as a draft to approve: the machine prepares, you decide. No hard automatic send to the clients who count.

Can accounts and sales have different views? Yes, and that’s the point. A “cash” view by amount and days late, a “renewals” view by expiry window and risk, with different permissions on what each sees. One list for everyone doesn’t work.

What does AI actually do here? It prepares the message drafts calibrated on the client and speeds up the mechanical work. It doesn’t decide who to chase or with what tone to close a relationship: those decisions stay yours. AI takes effort off, not judgement.

How long does it take and how much does it cost to maintain? Two-three months for a solid version in use, with a first useful piece in a few weeks. After that you need maintenance, because banks, ERP and your processes change over time. It’s a live tool, not a closed package.

Is it compliant with privacy? The system puts the right bases in place — access only for whoever needs it, tracking of what was sent, measured tones — but the formal details (notice, retention times, PEC text) you see with your consultant. The software makes it easy to do the right thing; the legal part stays with the lawyer.

Why don’t I just take a ready-made reminders SaaS? Because ready-made gives you the 80%: the list and the standard send. The 20% that counts — your way of renewing, your tones, matching on your dirty receipts, the two views for your departments — is your specific logic, and that isn’t in the menus of a bought product. It’s exactly the piece that has to be built, and it’s the one that moves cash.

In one line

If you live on fees and renewals and you discover the missed ones when the client has already gone, you don’t need another due-date sheet: you need software that reminds you of the money — one thread from contract to receipt, two views (cash for accounts, relationship for sales), matching that knows who paid, and reminders with a scale of tones a human still steers. The ERP you already have often “has the deadlines”; nobody uses them because they don’t call you. A thin layer on top, two-three months, typically pays for itself in a few months — because it stops you giving away cash that was already yours.

If you recognise yourself in the renewal discovered too late, look at the projects I’ve built or drop me a line: we start from your contracts and your recurrences, not from a reminders catalogue.