How it works

A collection rule is a sequence of steps anchored to the charge's due date: a reminder 3 days before, a notice on the day, a firm email 5 days after, an agreement offer at 15 days, and so on. You design the sequence once and the engine runs it for every charge, every day, without anyone having to remember anything.

The daily cycle

An automatic check runs daily and, for each open charge (pending or overdue):

1. Recalculates the amounts — interest, fine, discount and days overdue.
2. Updates the status — a charge past its due date becomes overdue.
3. Assigns the default rule — a charge that arrived without a rule (spreadsheet, API, integration) automatically receives the rule marked as the organization's Default. This is what backs the promise "upload the spreadsheet and the collection rule runs on its own": no charge is ever forgotten.
4. Fires the steps that are due — compares today's date with each step's trigger (before due date, on the day, X days after) and executes the ones whose time has come. Each step runs at most once per charge.

What a step can do

Steps are not just messages. A step can:

• Notify the debtor by email, SMS or WhatsApp, using a template with variables (the voice channel is not dispatched yet — see Steps and channels);
• Create a negotiation offer that the debtor sees in the portal;
• Open a manual task for your team (e.g. call in person);
• Initiate credit bureau registration (negativação) or protest — which never happen on their own: they create a pending record and a mandatory human-review task;
• Escalate to legal, creating an urgent task.

The details of triggers, channels and actions are in Steps and channels.

Compliance before every send

Immediately before each send, the engine evaluates contact compliance: active suppressions, legal hold, the legal contact window of the debtor's state (including national holidays) and per-person contact limits. A send outside the window is rescheduled to the next opening — never silently dropped. This is the most important page in this section: Contact compliance.

Immediate interruption on events

The engine reacts to events instantly, not on the next cycle:

• Payment confirmed — the charge exits the rule successfully and every pending send is cancelled. Nobody collects a paid debt.
• "I already paid" — the debtor's claim pauses the rule immediately while the proof of payment is verified; confirmed, it ends; not confirmed, the rule resumes where it left off.
• Agreement accepted — the charge becomes negotiated and exits the rule (Agreements).
• Dispute opened — immediate pause and suppression of pending sends.
• Partial payment — settles the original charge (partial settlement) and creates a child charge for the remaining balance, which re-enters the rule from the start; interest now accrues on the remaining balance.
• Refund/chargeback — the charge reopens and restarts the rule from the beginning (a new cycle), resending the notices; active credit bureau registration/protest actions are not repeated.

As a last line of defense, there is a pre-send revalidation inside the worker itself: even if a send is already queued when the payment arrives, it is blocked using the freshest state from the database before going out to the provider.

Versions: whoever entered, entered a snapshot

Each charge enters a published version of the rule — an immutable snapshot of the steps. Editing the rule later does not change the plan of those already inside; the changes apply to future entries. Details in Versions and publishing.

Everything audited

Each step execution records what was sent, over which channel, when and — just as important — why something was not sent (suppressed, rescheduled, cancelled, with the reason). This telemetry feeds the evidentiary audit trail and the recovery report.