Algorithm Tour

Every month, over a thousand invoices arrive on the platform: one per franchisee, with amount, due date and reference. They come from different systems and spreadsheets, written in different ways — and the same obligation can appear twice.

First, deterministic matching: when two records carry the same identifier, they are the same invoice, with no uncertainty. It is the simplest rule and it resolves a good part of the portfolio.

For what is left, we compare attribute by attribute — store, amount, due date, document — and add up the similarities with weights. A score from 0 to 1 classifies the pair: duplicate, review or distinct.

Finally, each invoice gets a quality score: complete fields, plausible values, consistent due date. Bad data does not enter the collection ladder; it becomes a pending item for a person.

The network’s collection ladder does not treat on-time payers and late payers the same. For that, the portfolio is separated into operational segments — and each segment receives a different sequence of contacts, within the limits defined by the network.

A classifier, for example gradient boosting, adds up many small decision trees: each one corrects the error of the previous one. The inputs are characteristics of the invoice and the franchisee — punctuality history, amount, days overdue.

Instead of only asking “will they pay?”, we ask “when?”. Survival analysis deals with the time until payment: the probability of paying within t days comes from the survival curve.

A probability only helps if it is calibrated. Segments come from cutoffs on the calibrated probability and pass through the network’s policy before becoming action.

Everything here is demonstrative: the curves illustrate the method, they do not predict real payments.

For each invoice there are several possible actions: wait, remind by WhatsApp, send an email, propose renegotiation, call a person. The question is not which action is best in general, but which action is best among those permitted now, for this invoice.

Each action has an expected value: the chance of payment it produces times the invoice amount, minus the cost of the action — including the discount, when there is one.

But not everything is permitted. Zamp defines the policy: how much discount, how many contacts per week, when to escalate. Actions that violate a rule leave the set before the choice — it is a constrained optimization.

When there are many similar actions, a learned ranking (learning to rank) orders the candidates. Contextual bandits, as an experimental evolution, could test variations safely — always within the policy.

Each invoice lives in a state: issued, upcoming, overdue, notified, in negotiation, paid. A finite-state machine says which transitions are possible — a paid invoice never goes back to overdue — and each state change emits an event.

If we assign a probability to each weekly transition, the machine becomes a Markov chain: the next state depends only on the current state. It is an analytical model, not an exact description of what happens.

Put together, the probabilities form a matrix. Multiplying the portfolio distribution by the matrix, week after week, simulates how the set of invoices spreads across the states.

With this we can ask “what if?”: what if the notification goes out a day earlier? what if negotiation converts more? The ladder stops being a list of reminders and becomes something that can be studied.

The probabilities are editable in the lab and do not represent network data.

Collections arrive by WhatsApp and email, and the service desk runs 24 hours a day: in 100% of cases the first response goes out within one minute. Every message from the franchisee — question, proof of payment, request for more time — enters the same flow, through any channel.

A classifier estimates the intent: ask for a second copy, say they paid, negotiate, dispute, talk to a person. The output is not an answer: it is a probability distribution — and that is what makes it possible to know when to doubt.

To act, the assistant uses tools — look up the invoice, generate the second copy, record an agreement — and retrieves, from the network’s policies, what it may answer. This is called retrieval-augmented generation (RAG): the answer cites the policy instead of inventing.

Finally, a guard decides the destination: answer on its own, or escalate. A discount request beyond the limit is never granted by the AI; it goes to someone with authority. The AI executes within the policy; it does not rewrite it.

Each additional contact recovers less than the previous one: those who were going to answer already did, and insisting wears people out. In mathematical terms, the marginal gain is decreasing — and that is what creates an optimal point of effort.

The net expected value adds the return and subtracts the cost of acting. It rises while each contact earns more than it costs, and falls afterwards. The maximum of the curve is the intensity that pays off.

The optimum depends on the cost: a cheap contact justifies insisting more; an expensive one, less. By varying the cost per contact, a decision surface is drawn — and the best intensity runs along that surface.

In practice, there are constraints: the network’s policy limits the number of contacts per invoice. The optimization becomes constrained: choose the best intensity within what is permitted.

All values in this chapter are simulated.

The cycle only closes when the money that comes in is matched to the right invoice. Payments arrive by Pix, bank slip or transfer, not always with the full reference, and sometimes they pay part of an invoice or more than one.

The first rule is the simplest: if the payment carries the invoice reference and the amount matches within tolerance, the match is direct. No probability is involved.

When it does not match, cascading rules come in — amount, store, date window — and differences are classified: underpayment, duplicate payment, payment without reference. The platform classifies; it does not force a match.

Anomaly detection separates what is strange from what is merely different. A payment far outside the distribution goes to a person, with the evidence on screen; the final decision is human.

Not every decision should be automatic. A confidence threshold separates what the AI resolves on its own from what goes to a person. The finance team moved out of execution and now handles exceptions: it is the human who governs, the AI that executes.

To know whether the threshold is good, you have to evaluate: of the automatic decisions, how many were right; of those sent to review, how many errors were caught. Raising the threshold reduces automatic error and increases the human load — a trade-off that can be measured.

Active learning: when there are more cases than people, the most uncertain — those closest to the decision boundary — go first to review, because they are the ones that teach the model the most.

And the world changes. Drift detection compares today’s confidence distribution with the reference one: when it moves too far, the stability index (PSI) triggers an alert and the threshold needs to be reevaluated.

The platform has an AI agent that answers questions about the operation with the network’s consolidated position, with no spreadsheet or BI. For the answers to be reliable, each metric — overdue amount, collection rate, average delay, exceptions — is defined once, in a semantic layer.

Asking in natural language is just the tip: the model translates the question into a structured query — which metric, grouped by what, with which filter. Whoever does the math is a deterministic query over the data; the AI does not invent numbers.

That is why every answer can be checked: it shows the metric, the formula and the values that go into the sum. It is the difference between an assistant that chats and one that accounts for itself.

And observability closes the loop: time series of collections, bands of expected variation and alerts when something departs from the pattern — before anyone has to ask.

An operation that learns is a cycle: data become features; features feed models; models support decisions; decisions are executed; results are measured; evaluation returns to the data. Each turn builds on what the previous one taught.

Before any change, offline evaluation: train on the past and test on the future, in sliding windows, to see how the decision would have performed without risking the operation.

In production, three monitors watch the system: calibration (do the probabilities still hold?), drift (has the data changed?) and human feedback (do people agree?). When one fires, the model or the threshold is reevaluated.

To know whether a change really helps, controlled experimentation: two arms, one with the change and one without. With about a thousand invoices per month, the size of the effect you want to detect determines how many months the test takes.

It is important to separate what exists from what is a proposal. AI-driven collection ladder, WhatsApp and email communication, management agent and 24/7 service desk are on the platform. Predictive models, optimization and MLOps are a proposed evolution, to be validated.