What a finance AI agent actually does on a legacy Windows desktop

It sits in a Windows session next to a clerk's normal SAP GUI, Oracle EBS, or Jack Henry teller window, and replays a workflow that a human walked through once. The replay reads and writes the same fields the clerk would: invoice date, vendor, amount, tax code, cost center, reconciliation account. The runtime sequencer is deterministic. The model is not in the loop at execution time. Authoring is the part the model does, once, when the human walks the workflow with the recorder open. After that the workflow is a file on disk and the runtime replays it the same way every run.

On the SAP side: MIRO (invoice receipt), F-28 (incoming payments), FB60 (vendor invoice non-PO), XK01/XK02 (vendor master), FBL3N (G/L line items), F-44 (clear vendor). On the Oracle EBS side: Invoice Workbench (three-way match), Cash Receipts Workbench, the GL_INTERFACE upload form. On the banking side: Jack Henry SilverLake teller, Fiserv Premier and Signature, FIS IBS. The screens are the same screens the AP, AR, and treasury teams open every morning. The agent reads them through the OS accessibility surface (UI Automation on Windows), which means SAP GUIScripting being on or off does not matter, the surface is published either way.

List rate is $0.75 per minute of executor runtime. A clean MIRO post averages about 4 to 6 seconds of clicks once the OCR has the values; that is roughly $0.05 to $0.075 per invoice on the meter. A Vendor master create with multi-tab walks is closer to a minute and a half, $1.10 to $1.30. Cash app in F-28 is in the middle at $0.30 to $0.90 per remittance file. Where teams spend more is the document understanding step before the workflow starts: a complex utility bill with twelve cost centers takes more parsing time than a clean PO-matched invoice. The bill is the runtime telemetry multiplied by the rate. There is no per-seat license, no Robot fee, no Studio fee.

UiPath does some of this; the difference is in cost, time to production, and what happens when the SAP support pack lands. A typical UiPath enterprise deployment for the same SAP B1 chain we replaced was running about $267K per quarter in licenses (Studio Pro, Attended Robot, Unattended Robot, Orchestrator, Document Understanding, AI Center, Premium Support) plus a separate $185K implementation SOW. The CFO told the board they are saving 70% on costs after switching. The other piece is the maintenance economics. UiPath records an XPath-style selector against the GUI control; when SAP renames the field or moves the panel, the selector breaks and a developer has to re-record. The accessibility-tree approach the F&B chain moved to has a four-strategy fallback that absorbs most label renames and panel reorders without a re-record. That is what shifts the maintenance cost curve.

No, and this is the part most explainers get wrong. At authoring time, a human walks the workflow once with the recorder on. A model converts the recording into a deterministic workflow file: a sequence of accessibility-tree node references, conditions, and field bindings. At runtime, the executor replays that file with zero LLM calls in the hot path. You can grep the open-source executor at crates/executor/src/services/typescript_executor.rs in github.com/mediar-ai/terminator for 'gemini', 'openai', 'claude', or 'anthropic' and find zero matches. That is on purpose. Auditors and SOX reviewers do not have to certify a model's behavior; they certify a deterministic replay file. The model is a compiler, not the runtime.

Every run writes a row to workflow_executions in Postgres with workflow_id, status, started_at, completed_at, and execution_duration_seconds. The same row drives the bill (apps/web/src/app/api/billing/usage/route.ts groups by workflow and month and multiplies by the rate constant) and the audit trail. The agent runs as a named service account inside the customer's existing security perimeter, on a Windows session that the customer's IT controls. Mediar is SOC 2 Type II certified and HIPAA compliant. For SoD, the typical pattern is the same as any RPA control: the agent has the privileges of one role (AP clerk, cash app clerk), the controller approves above thresholds, and the workflow file plus the execution row plus the SAP document number form the three-way reconciliation an auditor will ask for. On-prem deployment is available for teams whose finance data is not allowed to traverse a vendor cloud.

Three categories. First, judgement work: exception triage on a $40K invoice variance, controller signoff, fraud screening on first-time vendors, anything where the right answer depends on knowing why a number looks off. Send those to a human with better context, not a faster agent. Second, free-form discovery in unfamiliar UIs the recorder has never seen; agents in production are recording-shaped, not exploratory. Third, workflows that already have a clean API. If your bank publishes an ACH origination API and your accounting system publishes a journal entry API, integrate them directly. The accessibility-tree agent is the right answer when the data lives behind a Windows GUI that has no API, which is most of legacy enterprise finance and almost none of the SaaS finance stack.

Two paths. The open path: the Terminator SDK at github.com/mediar-ai/terminator is MIT licensed. A finance-systems engineer can record a single workflow, ship it on one Windows session, and prove the unit cost on their own time. No procurement cycle. The sales-led path: the turn-key program is a $10K fee that converts to runtime credits with a small bonus, plus $0.75 per minute of execution. Most teams start with one workflow (cash app or MIRO post are the two most common entry points), measure the per-execution cost against the cycle-time savings, and only widen the rollout once the unit economics are on a dashboard the controller can read. We typically have a workflow in production inside two weeks.