← Use casesUSE CASE
§ USE CASE · FINANCE

Finance reconciliation

A governed agent suite that pulls bank movements, card settlements, SII tax documents and Buk payroll centralizations, matches them against the accounting system of record (Odoo, NetSuite, SAP), resolves the long tail of fuzzy matches with an LLM under explicit policy, and surfaces only the unresolvable cases for a human accountant. Every link, every ignore, every annotation is recorded in an immutable audit trail and round-trips into the ERP under the operator's user.

  • Finance
  • Accounting
  • SII
  • Banking
  • Audit
  • Reconciliation

Executive summary

Reconciliation is the slowest, most error-prone link in monthly close. Bank statements arrive in heterogeneous formats, card processors lump days of activity into a single deposit, the SII publishes documents on its own cadence, and payroll centralizations land as compound entries. Most teams handle it by hand, in spreadsheets, against the clock.

The Finance reconciliation suite runs four governed agents — one per source (bank, card, SII, Buk) — that each produce a typed link, ignore or pending decision, with the evidence behind it. Deterministic rules clear the obvious matches; the agent layer resolves the fuzzy ones with explicit policy bounds; the human reviews exceptions only.

The platform never posts to the ERP without a recorded approval. Each link is reversible, each agent decision expands into the underlying tool calls, and the audit log is exportable for external auditors and the SII review process.

What this case fixes

In a typical mid-market Chilean operation closing a single month touches four reconciliation surfaces — bank, card, SII and Buk — each with its own format, cadence and edge cases. The team spends days copy-pasting between spreadsheets and the ERP, and the long tail of fuzzy matches (a deposit that aggregates three invoices, a card settlement net of fees, a Boleta de Honorarios that lags the SII by 48 hours) consumes most of the effort.

Generic OCR and rule-based reconcilers solve the easy half and silently break on the rest. What the operation actually needs is a runtime that combines deterministic rules for the high-confidence cases, an agent layer that proposes resolutions for the ambiguous ones with traceable evidence, and a human queue for what remains — all under one audit log so external auditors and the SII can reconstruct any decision after the fact.

How it runs

Four agents (bank, card, SII, Buk) on the Xophia orchestration core, each implementing the same five-phase pipeline. The agents only ever read from the ERP and the source systems; every write — link, unlink, ignore, annotate, post — is gated behind an operator's approval and executed under that operator's user inside the ERP.

  1. 01DATA

    Ingest sources and ERP state

    Pulls daily bank statements (typed connectors per bank), card settlement files, SII libros (compras/ventas/honorarios), Buk centralization payloads and the open accounting state from the ERP. Read-only.

  2. 02AUTOMATION

    Apply deterministic match rules

    Exact-amount, exact-date and reference-number matches clear without LLM involvement. The bulk of routine activity (typically 60–80%) resolves here; nothing leaves this phase without a recorded match strength.

  3. 03AGENT

    Resolve fuzzy cases under policy

    For unmatched items the reconcile agent proposes a link or a typed ignore reason. Each proposal cites the source rows on both sides, the rule that flagged it, and the policy clause that allows the resolution. Confidence below the configured threshold routes to the exception queue.

  4. 04HUMAN

    Operator review of exceptions

    The accountant sees only the unresolved tail in the Xophia console: side-by-side source rows, the agent's proposed action, and a one-click approve / edit / reject. Bulk operations (e.g., approve all card settlements net of fees from processor X) are first-class.

  5. 05AUTOMATION

    Apply, post and audit

    Approved actions write to the ERP through the connector under the operator's user. Each action emits an immutable audit row: source ids on both sides, agent trace id, policy clause, operator id and timestamp. The reconciliation state machine advances and the audit row is exportable for the external auditor and the SII.

Systems and connectors

SystemRole
Odoo / NetSuite / SAPERP (system of record)
BCI · Santander · Itaú · BancoEstado · Banco de ChileBank statement connectors
Cardda · Transbank · WebpayCard settlement connectors
SIITax documents (compras, ventas, honorarios)
BukPayroll centralization
Xophia audit logCompliance and external audit

KPI targets

Auto-match rate

Baseline
40–55% of items matched without human intervention
Target
≥ 85% auto-matched (deterministic + agent), within configured confidence threshold

Count of source rows resolved via deterministic rule or approved agent proposal, divided by total reconcilable rows in the period.

Time-to-clear month-end

Baseline
5–10 business days after period close
Target
≤ 2 business days after period close

From the moment all source files are ingested for the period, to the moment 100% of items are in a terminal state (matched, ignored or escalated).

Exception backlog age

Baseline
Multi-week tails common
Target
p95 exception age ≤ 3 business days

Distribution of (now − exception_created_at) over items in the exception queue, measured daily.

Audit completeness

Baseline
Ad-hoc spreadsheets, partial trails
Target
100% of state transitions linked to an audit row with source ids, policy and operator

Audit-log check: every link, unlink, ignore and post must reference both source rows and an operator id; gaps trigger a compliance alert.

Sample execution trace

An anonymized run from a Tuesday morning bank reconciliation. Every line below corresponds to a row in the audit log; nothing is editorialized.

Daily run for legal entity LE-02. The bank statement contains 47 movements. Deterministic rules cleared 31; the agent proposed resolutions for 14 and routed 2 to the exception queue.

ToolInputOutput
bank.list_statement_movementsentity_id=LE-02, account=CL-BCI-1234, date=2026-05-0447 movements, total amount CLP 184,520,330
erp.list_open_invoicesentity_id=LE-02, status=posted, payment_state=not_paid, currency=CLP212 candidate invoices in the matching window
rules.deterministic_matchmovements=47, candidates=212, tolerance=CLP 131 exact matches, 16 unresolved (12 partial-amount, 3 fee-aggregated, 1 reversal)
agent.propose_resolutionmovement_id=BM-9087, signals=['fee_aggregated','same_processor']Suggest link to invoices INV-3041, INV-3052 net of CLP 12,400 processor fee. Confidence 0.93. Policy: card_processor.cardda.allow_fee_aggregation
agent.flag_exceptionmovement_id=BM-9112, signals=['no_candidate','amount_mismatch']No matching open invoice within ±5d window. Routed to exception queue with priority=normal.
console.publish_digestoperator_id=ACC-04, items=16 (14 proposed, 2 informational)digest_id=R-2026-05-05-LE-02-BCI awaiting review

Outcome. Operator approved 13 proposals and edited 1 at 09:42 UTC; remaining exception escalated to the controller. Approved items posted to Odoo as bank.statement.line.reconcile under operator user. Audit row R-2026-05-05-LE-02-BCI closed. Total agent cost: $0.078; latency p95: 8.4s.

Want to scope this for your stack?

30 minutes with engineering. We map the case to your CRM, your policies and your approval boundaries, and respond with a scoped estimate within 24 hours.

Request a working session