Tracking invoices and overdue payments: from receivables to the reminder

The situation

Take Nordica, a fictional B2B distribution company. Its customers range from key accounts to very small businesses, its invoices go out on 30 or 45 days, and its finance team tracks receivables in a spreadsheet rebuilt at the end of every month from two extracts: one from the invoicing database, the other from the CRM, where the accounts and the sales reps who own them live.

That spreadsheet answers the question it was built for. It says how much is owed. It rarely says why a customer is paying late, who should call them, or whether the delay is new. And it arrives once a month, when a three-week delay has already become a seven-week one.

The questions people actually ask

In a finance team, questions about late payments are never abstract. They look like these:

• What are our trade receivables today, and how much is overdue?
• How has our DSO moved since the start of the year?
• Which customers have invoices more than 60 days overdue, and who is their sales rep?
• Is this delay an oversight, or the sign of a dispute?

Each one crosses at least two sources. The last one in particular cannot be read from any table: it means matching an invoice with a conversation with the customer.

Asking the question in plain language

Nordica’s financial controller opens a conversation and writes her question the way she would ask a colleague, without knowing the names of the tables.

Before answering, the agent says what it computes: the period, the scope, the breakdown it uses. It relies on the business context gathered when the database was connected: what Nordica calls an overdue invoice, how it treats credit notes, the payment terms of each segment. That context does not need explaining again with every question. It was built once, with the team, and everyone benefits from it.

What it cannot guess, it asks

While exploring the invoices table, the agent notices that some overdue invoices carry the status “disputed”. Nothing in the data says whether they belong in the overdue amount to chase. Rather than decide on its own, it asks.

The answer, track them separately, goes into the workspace’s shared memory. The next person to ask about late payments will get the same scope, and therefore the same figure.

A receivables figure is only worth something if the whole team computes it the same way. That is what business context is for.

Reading overdue receivables by age

The answer comes with the figures and the chart. Out of €1.12M in receivables, €318k is overdue. Half of it is under thirty days late and part of routine follow-up; the €72k beyond sixty days, on the other hand, needs someone’s attention.

The figures do not come from the AI model: they are computed by the invoicing database itself, from the query the agent wrote and Azul checked before running it. An analyst can review that query in one click. The next question follows naturally: who is behind the oldest delays?

Cross-referencing with the CRM

This is where the invoicing database is no longer enough. Accounts, their sales reps and the history of exchanges live in the CRM, which Nordica has connected to Azul through its API. The agent queries both sources in the same conversation and brings their answers together.

The picture changes. Atelier Brisson has already been reminded; the choice now is to wait or to escalate. Maison Castel and Tessier et Fils, on the other hand, have had no recent contact while their invoices keep ageing. As for Norvia, its delay is not an oversight but a dispute, and chasing it like a bad payer would be a mistake.

Acting in the CRM

The financial controller asks for the logical next step: a reminder task for both accounts, assigned to their sales rep, with the invoice details. The agent creates it directly in the CRM.

That action is only possible because Nordica connected its CRM and authorised task creation. Which tools you connect and which actions you allow in them remain your decision, and every action is recorded in the audit log along with the conversation it came from. The invoicing database is never modified: Azul reads the invoices there, and writes nothing.

No more checking

A one-off analysis is not a follow-up. The useful charts, receivables, overdue by age, DSO, are pinned to a “Receivables” dashboard refreshed every day at 7 am. Everyone reads it with the morning’s figures, without waiting for month-end.

On the indicator that matters most, the finance team goes one step further and sets an alert: when a customer’s amount overdue beyond 60 days exceeds €25,000, Azul e-mails the finance team and the account’s sales rep. The alert goes out on the refresh that sees the threshold crossed.

A frozen statement for the board

That leaves the executive committee, which does not need a moving table but a position at a date. From the same conversation, the agent writes a report whose figures are frozen on the runs it was written from. It is the document you share, and the one you will find unchanged next quarter to compare against.

What changes for the team

• Follow-up becomes daily. Receivables are read every morning, not only at month-end.
• A delay comes with its context. The overdue amount arrives with the sales rep, the last contact, any dispute: the reminder goes to the right person, with the right argument.
• The same rules for everyone. Disputes, credit notes, payment terms: defined once, applied to every question.
• A new question is no longer a ticket. It is asked in plain language, on today’s data, by the person who needs the answer.

Where to start

The simplest way is to start from a question that matters today and has no quick answer: the amount overdue beyond 60 days per sales rep, for instance. Read-only access to the invoicing database is enough, or an export if you would rather start from a file. The CRM can be connected next, with only the actions you choose to authorise.