AI-Agent Accounts Receivable and Payable Operations Automation: The Agent Reaches the Real Ledger, Not the Mirror

An internal AI assistant is only as useful as the data it can actually see — and a synced mirror table, refreshed once a day, tells an agent what was true yesterday morning, not what is true right now. A financial specialist that can only read a copy of one narrow slice of the ledger (in this case, just the client-facing boleto mirror) cannot answer a same-day question about total receivables, cannot draft an invoice, and cannot register a payment — every one of those requires reaching the actual source of truth, not its reflection.

The naive version of "let the agent see the finances" is a broad read grant plus an ad hoc write path built as each request comes up — which tends to accumulate exactly the kind of access nobody explicitly decided to grant: the agent quietly gaining a way to move money, approve its own request, or bypass whatever validation the product's own settlement logic enforces. The safer version requires deciding, tool by tool, exactly what an agent may read, exactly what it may create, and drawing a hard, named line around every action that has a real external effect — a real charge, a real payment approval — before a single tool is built, not after an incident.

The starting census, recorded directly in the migration's own header comment, was blunt about the gap: Gauge — invoices, boletos and Pix via Asaas, dunning, subscriptions, reconciliation, cash position, tax — has 120 tables and, before this migration, zero agent tools. The financial specialist agent could only operate `client_boletos`, a mirror table inside Axis fed by a once-daily 05:00 sync — the actual source system was invisible to it.

Eleven named tools replace that gap, each with an explicit read (`le`) or write (`escreve`) classification recorded in the same catalog row an agent reads before calling it. The six read tools cover a one-glance financial panel (receivables due and overdue, payables due, the next 7 days both ways, this month's collections, active subscription MRR, open issued documents, and whether the dunning sequence is even turned on), invoice listing by status or client, an aging view of who owes what and how many dunning emails they've already received, the dunning sequence's own state, issued fiscal documents, and a reporting view combining aging with the current month's totals.

The five write tools are deliberately narrow. Creating an invoice produces a Pending record only — issuing the real boleto or Pix charge against Asaas is a separate, human step inside the app, and the tool's own description states this explicitly. Registering a payment does not write to the invoice's status column directly; it calls the product's own atomic settlement routine (`gauge_receivable_settle`), the same routine a person uses from the app, which handles a partial payment by carrying the remainder as balance and an overpayment as credit rather than as two disconnected numbers. Because that routine's own authorization check requires the calling identity to be a member of the organization — and the agent's own database user is deliberately NOT a member, by design — the settlement tool borrows the organization owner's identity for the duration of that one transaction only, via a session-local `set_config` call, while recording the agent's own authorship in the settlement's notes field. The migration's own comment names this exact pattern as a reuse of an already-established design (Orbit's own stage-move mechanism, from an earlier migration) — a deliberate, repeated approach to the same underlying problem, not a one-off workaround invented for Gauge alone. Logging a payable, registering a supplier (deduplicated by name), and creating a recurring subscription round out the write side — the subscription tool creates the recurring schedule only; a separate daily worker generates each cycle's real invoice.

Every boundary is stated twice, not once: in the tool catalog's own `contrato` text an agent reads before calling it, and again in the specialist agent's own rewritten brief, which lists, in plain language, exactly what stays human — issuing a real charge, approving or paying an expense, turning on or configuring the dunning sequence, reconciling a bank statement, closing a financial period — and adds a rule with no exception: the agent never negotiates a discount, a waiver, or an extended deadline on its own authority. It prepares the case (how much, since when, what has already been tried) and hands it to the partners.

A client pays an invoice by Pix outside the automatic Asaas webhook flow — say, a direct bank transfer the team learns about by message. Someone asks the financial agent to register it. The agent looks up the invoice, confirms it isn't already marked Paid, and calls the settlement tool with the amount and date — which runs through the same atomic routine the app itself uses, so a partial amount is handled as a partial payment rather than silently marking the whole invoice settled.

The financial specialist agent can now answer a same-day question about receivables, payables, or an overdue account from the actual source of truth, not a once-a-day mirror — and it can act on straightforward, well-defined tasks (drafting an invoice, logging a payable, registering a known payment) without a person doing the manual entry. At the same time, every action with a real external effect — money actually moving out via a real charge, a payment actually approved — stays exactly where it was before: with a person, inside the app, deciding.

A team hoping an AI agent will issue real charges, approve payments, or negotiate collections terms autonomously will find the opposite here by design — every one of those actions requires a human step inside the app, with no override. A team wanting the agent's settlement tool to bypass the product's own atomic routine for a special case will find it always routes through the same logic a person's own manual settlement uses.

Giving an internal agent a once-daily mirror of one narrow table is safe but nearly useless — the agent can describe yesterday's picture but can't act on today's. Giving it a broad connection to the real financial core is useful but risky, unless every action is named and classified in advance. Centriu chose the narrower, safer middle: 11 explicitly classified tools, real settlement logic reused rather than reimplemented, and a boundary — no real charge, no payment approval, no discount, ever, from the agent alone — stated in two independent places rather than trusted to one.