What happened before the controller arrived?
This is an illustrative scenario, not a customer account. The people and the company are invented; every event in it maps to a real mechanism on ftes.ai, named as it happens.
The company is a subscription business with one controller and a part-time bookkeeper. Overnight, the Finance Controller FTE read the bank feed, the payment processor's payouts, and the ledger through its dedicated, read-scoped connections, and did what its remit's Owns list says: it matched receipts to invoices, payouts to the invoices and fees they cover, and proposed each match with the source records attached. Exact matches under the threshold the controller set, a class promoted at last month's review under the Promotion Standard, were posted within bounds and logged. Everything else waits in the Approvals tab.
It also ran its detections. One fired: the processor's fee schedule changed at the start of the month, and the last three payouts show a difference the old schedule does not explain.
What does the morning brief say?
The controller opens the Today tab. The brief is in the first person: what the FTE did overnight, what is waiting, what it detected, and spend against the role's budget. Waiting on the controller first: a handful of partial matches with the unexplained difference isolated and named, and one payout flagged as a dispute. Then the detection: the fee schedule change, with the three affected payouts and the FTE's proposed explanation, which is that the new schedule accounts for the difference exactly. Then yesterday's summary and the spend line, which is well inside the per-role budget.
Five minutes, and the controller knows the shape of the day before opening a spreadsheet.
How do the approvals go?
In the Approvals tab, each waiting match shows the payout, the invoices it covers, the refunds and fees deducted, and the ledger entries proposed. The controller reads the attachments and approves most of them in seconds each; the evidence is the review. One partial match is sent back with a reason: the FTE treated a currency conversion difference as unexplained when the processor's own conversion line accounts for it. The reason is recorded, and it will show in the send-back log as a rules item, which means the remit gains a line about conversion lines at the next review.
The detection is approved as a memory change: the new fee schedule goes into the Brand Brain with today's date and the controller's name as provenance, and tomorrow's matches will use it.
- Approve: evidenced matches, seconds each
- Send back: one, with a reason that becomes a remit rule
- Detection: approved into memory with provenance
What happens with the dispute?
The flagged payout is a chargeback the processor recorded overnight. It is on the remit's Asks list, so it did not become a match; it became an escalation to the controller with a four-part summary: what the processor recorded, what the FTE found in the ledger and the order, why it did not resolve, and a suggested next step, which is to gather the fulfilment evidence before the processor's deadline. The controller forwards the summary to the account owner. The FTE has proposed the ledger treatment for the disputed amount, which the controller approves, and has drafted nothing to the customer, because contacting a customer about money without an approved draft is on the Never list.
The dispute is handled on the day it was filed rather than discovered at the close.
What does the afternoon look like?
Nothing from the FTE, which is the point. It runs on its schedule; the controller does the judgement work: the accrual for a contract that renewed mid-month, a question from the auditor about a prior period, the cash forecast. The bookkeeper, whose afternoons used to be matching, is reviewing supplier invoices against purchase orders, a class the controller plans to add to the remit once the Second-Role Test says the team is ready. The Pipeline tab shows tomorrow's work queued: the next payout batch, and a monthly reconciliation the FTE will propose on the first of the month.
If the controller were away, the proposals would wait. Nothing posts without a decision except the promoted class, within its bounds.
What does the record show at the end of the day?
The audit trail lists every proposal, every approval with the controller's name and the time, the send-back with its reason, the detection and the memory change, the escalation and its summary, and the entries the promoted class posted alone. The Performance tab shows the day's approval rate per class and the exception count, which the controller will read against the last two closes at the monthly review. The close, when the month ends, will begin from a matched ledger with a short exception list, and the controller will sign it.
The library's piece on how a Finance FTE works describes each of these mechanisms outside the story; the metric explainer on days to close describes what the monthly review will read.