Three files. Seven stages.
One closed book.
Rohan is a controller at a four-entity manufacturing company. It's close day. He uploads three files. Forty-seven minutes later the entity period is CLOSED, the audit trail is exported, and the recurring TDS pattern is permanently learned. Here's how it actually runs.
Five named agents do the work — same names you'll see in the chat agent and the audit log. Each one owns one or two stages of the close.
Three files at 8 AM on close day
Bank statement (CSV). AR aging (XLSX). GL extract (vendor-formatted CSV). Rohan uploads them as-is — no manual cleanup, no header renaming, no row pruning. The first reconciliation happens before his second coffee.
Schema detection — every file is identified
Iris recognises the AR aging shape (invoice number, customer, due date, balance, days outstanding) and the GL extract shape (journal_id, posting_date, debit, credit, account). Field roles tagged automatically. No manual column mapping.
Argus proposes a SUM_AGGREGATE rule
Source rows and target rows don't share 1-to-1 cardinality — the AR file has 248 rows and the GL has 14 journal entries. Argus surfaces this and proposes a SUM_AGGREGATE rule on the amount field with a counterparty partition. Rohan approves.
on_field: amount
partition_by: counterparty
tolerance: ₹100 + 0.5%
date_window: ±7 days
Subset-sum on the unmatched pool
ACRE runs L1 exact + L2 fuzzy + L3 LSH on the keyed fields. Then Stage 1.5 — the aggregation blocker — searches for subsets of AR rows summing to each GL JE within tolerance. Twelve invoices match the ₹25 lakh JE in 240 ms. Eight more groups land across the rest.
Want to see twelve of your AR invoices snap to one of your GL entries? Bring last month's extracts.
Run subset-sum on your ledger12 AR invoices, summed to one GL journal entry — in seconds, within tolerance.
Three stragglers, one TDS variance, one wrong vendor
After aggregation, 23 AR rows remain unmatched. Argus investigates: 18 are recurring late-payers (memory matches them to prior MISSING_TARGET fingerprints — flagged but expected), 3 await next month's settlement, 1 is a ₹2,847 TDS rounding diff inside an otherwise-matched group, 1 is a wrong-vendor entry to reverse on the GL.
The TDS pattern is now learned
Clio fingerprints the TDS rounding pattern by (counterparty, residual_band, direction) and tags this counterparty with LATE_SETTLER_AVG_4D after three consecutive cycles of confirmed matching. Next month, the same counterparty's late settlement auto-links to its prior MISSING_TARGET. The exception is closed before Rohan sees it.
TIE_OUT_PENDING flips to CLOSED
Rohan reviews the 9 AGGREGATION_CANDIDATE exceptions, confirms the subsets, signs off on the wrong-vendor reversal, and clicks Close. Hermes orchestrates: marks the entity period CLOSED, exports the audit-ready report (matched pairs, residuals, rule reasoning, reviewer/approver stamps), archives the run.
- Wall time
- 47 min
- Auto-matched
- 94.2%
- Reviewer
- Rohan K · Controller
- Approver
- Priya S · CFO
- rows processed
- 4,103
- aggregation groups
- 9
- exceptions investigated
- 23
- wall time
- 47 min
- audit bundle
- 1
What controllers actually ask after walking the journey
Is the controller (Rohan) approving every match by hand?
No. ACRE's aggregation candidates land in a review queue with a confidence score. High-confidence groups can be approved in bulk; only edge cases — wrong vendors, unexplained residuals outside tolerance — require a click. The 47-minute cycle includes the human review time, not just the engine time.
What happens if next month the SUM_AGGREGATE rule needs tweaking?
Argus surfaces tolerance drift when the residual band creeps. The rule is editable; every edit is versioned in the audit log with reviewer, timestamp, and reason. Old runs replay against their historical rule version — reruns stay deterministic.
Does the memory layer ever auto-close exceptions without me looking?
Only after three confirmed cycles of the same fingerprint pattern, and only when a counterparty is tagged (e.g. LATE_SETTLER_AVG_4D). The first auto-close on a new pattern lands as a notification, not a silent action — you can revoke the tag from the counterparty intelligence panel.
Can I run this journey on my own ledger before signing anything?
Yes. The Week-1 plan on the FinanceOps overview page is exactly that — replay your last closed period's AR-to-GL on ReconPe, compare match rate and time-to-close against your spreadsheet, and only commit if the numbers tie.
What about AP-to-GL, intercompany, and GSTR-2B?
Wave 1 ships AR-to-GL and Bank-to-GL. AP-to-GL, intercompany mirror matching, and GSTR-2B versus GL are on the Wave 2 roadmap with named quarters. We don't claim shipped what isn't.
Next month's close runs on this month's memory.
Every confirmed match, every approved subset, every learned pattern carries forward. Your close gets faster every period — without your team writing a single line of code.