Robô de Recebimentos

An autonomous agent that reconciles payments against open instalments and settles them in the ERP on its own.

chained pipeline stages: 6
of the import automated: 100%
risk of double collection: 0

From pain to result

Fig. 06 — Data flow 9 nodes · 8 edges

Source External Process Store Output

Before

Manual reconciliation across two screens. And the expensive mistake — settling the same instalment twice — went unnoticed.

Reconciling what landed in the bank account against open instalments was done by hand, across two screens. Repetitive, slow and prone to errors that only surfaced days later at closing.

And the expensive mistake is not a missed settlement — it is settling the same instalment twice, which quietly slips out of control.

How · 1/3

I built a six-stage Python pipeline: it syncs the project and bank-account registry, imports settled payments, fetches open instalments through the ERP API, matches payment to sale, posts the receipt and monitors discrepancies.

How · 2/3

Matching is the heart of the robot. Priority goes to the structured key extracted from the entry history; only when that fails does textual similarity between the project description and the payer name kick in, with a configurable minimum confidence score.

How · 3/3

Before confirming any receipt, the robot asks the ERP itself whether that instalment has already been received. That is the guard against the worst possible error here: collecting twice.

After

The robot figures out which payment settles which instalment, asks the ERP whether it was already received before writing, and emails what nearly matched.

6
chained pipeline stages: 100%
of the import automated: 0
risk of double collection

Reading the diagram

No human in the path. The step that decides everything is the match: without it the robot either leaves money unsettled or collects twice — which is why it confirms against the ERP before writing.

Technical highlights

1 Two-layer matching: structured key first, textual similarity as fallback — with a minimum score and an optional value-match requirement.
2 The receiving bank account comes from the project registry, not from the payment process. It looks like a detail, but it is what guarantees each project is credited to the right account even when accounting recorded a different one.
3 Every stage uses upserts, so re-running is safe. Work tables are only cleared if the whole pipeline succeeds — if it broke midway, the data stays for diagnosis.
4 The discrepancy stage is deliberately non-blocking: it emails near-misses (cents apart) for review without ever taking the pipeline down.